前言

随着公司自研上云战略如火如荼地进行，IEG-增值服务部作为较早一批响应的团队，截止目前自研上云已完成1/3的流量切换，日PV超百亿。切云的服务大量采用了云原生的应用与技术架构，作为公司第一批面临云原生环境的业务运维，深切感受到云原生给运维工作带来的机遇与挑战，运维模式的转型已经迫在眉睫，此篇文章最大的价值在于将我们的转型思路、方法与实践，提供给后面更多面临同样挑战的团队借鉴与参考。下面我将从业务场景、运维转型之道、云端收益等几个方面来跟大家一起来探讨。

一、业务服务场景介绍


DataMore是IEG增值服务部为游戏项目组提供的一站式智能游戏运营方案平台，基于游戏日志数据，利用实时与离线计算打造数据营销能力，为业务提供以解决运营问题为目标的数据运营服务方案。与传统的游戏运营体系不同，DataMore游戏数据运营平台具有脱离游戏版本，对研发侧依赖小，计算能力与精细化运营能力强的特点，可以为游戏业务带来更低成本、更快速高效的精细化运营，并提供丰富的游戏运营方案。DataMore在各个生命周期，多种游戏品类上沉淀了许多运营方案以及工程化的运营系统，覆盖新进、活跃、流失、留存、付费和传播等多个阶段，包括邀请好友、任务中心、砍价拼团、低活跃干预、流失召回等多种数据运营方案，使得游戏业务可以快捷的找到适合自身游戏阶段、针对特定运营问题的解决方案。部分方案截图：




DataMore在技术架构上采用了微服务设计的理念，采用服务型开发架构，将数据营销服务拆分成独立、通用的服务能力，同时构建了应用和服务中台，能够通过组合这些通用服务快速而轻松的构建专属应用服务。DataMore活动覆盖了互娱几乎所有的游戏，落地场景非常多，每天都有新活动上线，而且周期短，节奏快，活动周期一般只持续一两周，日PV超过200亿，QPS峰值超过20+万，落地场景覆盖王者荣耀、和平精英在内的所有游戏及周边应用（如助手、微信游戏中心等）。


二、基于云原生环境开发者平台


相信大家对云原生的概念已经不陌生，但很难精准地去解释云原生具体是个什么东西，原因是云原生没有很确切的定义，且不断在发展演变当中。Pivotal 公司的 Matt Stine 于2013年首次提出云原生（CloudNative）的概念，旨在说明云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。2015年云原生计算基金会（CNCF），对云原生的定义为：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”。目前形成云原生理解上的最大共识概括为4个核心要点：DevOps+持续交付+微服务+容器，即基于这”4件套”构建的应用我们暂且认为就是云原生应用了。同时可以享受到云端极为丰富的PaaS组件，如业务后续使用到的数据库、缓存、中间件、存储、CDN等等，并且具备无缝在不同云厂商间透明迁移的能力。为适配云原生环境的数据营销服务的需求，部门推出了奇点（ODP）平台（基于腾讯游戏数据&营销服务能力，以微服务架构为基础，构建的集代码管理、服务开发、运维发布、服务运营为一体的一站式开发运营平台）实现了真正意义上的DevOps服务闭环，贯穿了服务交付的CI、CD、CO环节，得益于公司内外部更多优秀组件的集成，包括TKE、蓝盾、QCI、Envoy等。


三、云原生运维转型、挑战、目标与实践


1、云原生运维转型思维


这几年运维界听到最多的几句话：“云计算会淘汰掉运维！整个运维行业可能被干掉！再不转换运维就要丢饭碗”，诸如此类。那真相到底是什么？行业有一个共识，即运维工作本身交付的是一种服务，下面举一个可能不太恰当的例子，或者可以帮助大家找到答案。云计算时代好比组装一辆汽车，根据客户的需要，通过PaaS能力选择匹配的引擎、车轮、离合器、 悬架、车控制系统等进行拼装。客户不用关心汽车各元部件的实现原理，最终获得是一辆满足自身要求的汽车。光有了汽车是玩不转的。还需要有修路、加油站、交通控制等服务体系，运维就是承担这个角色。相比传统运维，确实是少了自己采购元组与组装的工作。到了后云计算时代（云原生），出现了一个DevOps公司，引入新技术与理念，声称已经将修路、加油站、交通控制等环节都打通了，形成了一体化服务能力，并邀请运维哥一起加入创业。在这个阶段，运维哥出去单干，大概率会翻车。但加入 DevOps 公司，运维的价值到底还有什么呢？因此，升级与转型是必然的，例如将普通国道升级成高速公路；实现客户在高速路上不停车换轮胎；贴近并理解客户，规划行程中所需的服务来提升客户体验；通过提升智能化水平，连接交通管制，缩短航程，避开损坏路段等等。相信大家心中已经有自己答案了。回到原点的灵魂拷问：“云原生背景下，运维不做转型会不会死？”，“运维要如何快速自救和升级？”。

我的观点：

• 不会死，但未来整条价值交付链没有你什么事了；
• 转型 SRE 是一种选择。
  

接下来介绍我们运维体系是如何进行转型升级的，首先我们的转型理论基础来源于DevOps框架，从中抽取出符合现阶段服务场景要求的模型，从文化与技术两大方向反复去实践与论证，也获取了非常好的效果。下图是Gartner于2015年发布的DevOps实践模型，放在2020年的今天来看，确实具有很强的前瞻性，不少观点经过我们的验证是正确的，例如：Feature Teams(特性团队)、Developer Self-Service(开发者自助服务)、Infrastructure as Code(基础设施即代码)、Integrated Tool Chains(集成工具链，CI-CT-CO)、One-Step Build，Test，Deploy(一键程序构建，测试，部署)等等。下面从文化与技术两个层面来剖析：



1）文化层面

以下几点是我们中心内部实行的几个机制，供作参考，因不同团队间存在一定差异，此处不展开说明。

• 开发与运维成立FT虚拟团队，实现组织上的融合；
• 开发或运维侧的例会、技术分享、事件复盘，FT成员全程参与；
• 项目立项时，运维接口人需要做“左移”，即提前参与技术架构讨论，有助于运维的问题提前在方案讨论或开发阶段提前 ，有效做好防范与规避；
• 建立收集各方反馈问题与建议的机制与渠道，有效将好的想法影响至平台下个版本的迭代中，实现持续改进与优化。
• 
  

2）技术层面


下图是个人绘制的传统运维到云原生运维的价值过渡，很明显的一个特性是往更高阶领域去涉足，传统运维投入将大幅度减弱。目标意指将更贴近业务、理解业务、通过数据与AI的能力，提升业务持续服务的能力及用户体验，同时确保整个价值交付链的畅通与高效。





在云原生背景下，我们对运维体系进行了升级，在原有基础运维能力之上确定了以下几个目标：

• 具备服务全链路质量监控覆盖，涵盖数据域与业务域
• 具备一定智能化的资源动态调度、伸缩机制
• 具备一定的故障预警、根因分析、问题定位能力
• 服务具备在交付不同阶段（测试、预发布、运营）抵御异常的能力
• 具备资源高效交付的流程机制与快速上线的能力
• 具备多云的资源编排与管理的能力
• 具备业务快速上云的机制，确保切换过程的高可用性
  

确定了运维能力升级指导思想：基于运维编排的云原生实例化。广义而言，运维的本质就是多个运营事件的有机串联，来达到质量、效率、成本、安全多维收益，而编排是实现有机串联的有效手段，除了可以沉淀运维经验外，还可以有效实现共享。

2、云原生运维转型平台化建设


在运维平台化建设方面，我们在构建原云生运维平台能力–玄图。积极拥抱公司开源协同的机制，通过集成现有优秀平台或组件，如有河图元数据管理平台（CMDB）、蓝鲸标准运维平台、PCG-混沌工程实验平台、蓝鲸服务流程管理平台等等，避免重复性建设，结合我们的服务场景，发挥平台服务效能最大化。思路上借鉴了“瑞士军刀”，我们通过微服务的架构，将云资产（CMDB）管理作为底座，也就是“刀把”。再将剪刀、平口刀、开罐器、螺丝起子、镊子等等集成进来，通过定义资源与上层平台的总线协议，将各类平台工具进行组装，犹如瑞士军刀一样，将轻、快、实用、因地制宜发挥到极致。下面将我们的体系能力进行介绍：

2.1 云原生资产管理公有云/私有云的各类云资源管理，我们叫做资产管理（所有的资源/应用/数据都在资产范畴）。我们知道，传统的大多数cmdb只能管理服务器信息（如ip地址/机架/机房等），在云原生环境下，我们将面对复杂多变的、新生的应用和场景，随之会产生越来越多的管理配置项，这就要求资产管理能够满足各种需求的扩展和未来业务的变化，例如腾讯云的CLB、CDB、COS、Ckafka等等，没有自定义模型属性的CMDB难以将这些云产品纳入管理范畴。在资产管理方案调研的过程中，我们发现资产管理需求与元数据管理十分契合，因此，资产管理，作为河图元数据系统的应用场景落地，通过元数据定义资产管理的模型、属性、组合关系，玄图对元数据的加工、应用实现通用的可灵活调整的业务级资产管理。在我们常见的kafka集群资产管理的场景下，通过河图元数据定义相关的集群、主机模型以及属性，定义他们的组合关系，达到资产管理的要求。




模型代表着一类云资源，模型的属性从各个方面分别描述这一类云资源，模型的属性可以根据场景自由定义和扩展。集群模型，当前的属性包括集群名、cc_set等，主机模型，当前的属性包括ip、类型、区域等，随着业务不断发展变化，我们后续可能会对集群和主机的信息进行不断的扩展，也可能集群下还要管理如CLB等其他类型的云资源信息，采用云资源管理，能很好地适应这种变化。




遵循MOF元对象设施建设标准规范为基础的云资源管理平台，能自由方便地表示所有模型间的关系，包括组合关系、依赖关系和继承关系。组合关系描述了一种组成关系，代表某个模型由另外的模型组成，依赖关系主要用于管理模型之间的依赖，继承关系则可以用来表示一种父子关系。kafka集群和主机的关系我们就可以用组合关系来表示，集群依赖的业务可以用依赖关系来表示，也可 以定义一个主机模型的父类，再派生出不同的子类代表不同的主机类型，但具有父类公共的属性定义。资产管理的数据将直接存储在河图元数据系统中，玄图平台在保留元数据管理灵活自定义的前提下，简化元数据操作管理，适配资产管理的需求，提供高效的查询、检索、变更的能力，以有效管理云资产。


2.2 云端一切操作皆可编排


云原生环境下，运维面临各种不同的公有云/私有云环境和各种跨云/跨平台的操作，给运维操作管理带来了巨大挑战。因此，我们继续构建云原生环境的编排能力，即运维编排，通过开发、封装可编排的组件和插件，提供灵活、可定制、可管理的模板化运维能力，覆盖运维任务的管理、审批、决策、执行、通知等功能，最终实现自动化、智能化运维。我们将运维编排分为三层，即：基础设施层、容器服务层、应用层。





如上图所示：

• 云资源编排，编排对象是各类云资源，包括公有云、私有云等，采用terraform来实现多云基础设施的编排，可以覆盖腾讯云、阿里云、AWS、私有云等等。
• kubernetes编排，编排对象是k8s集群资源，采用Helm/YAML进行编排。
• 作业编排，编排对象主要是主机节点，对应的操作任务编排，调用现有的蓝鲸job作业平台。
  

运维编排三层之间如何串联？我们采用了开源的蓝鲸标准运维作为编排引擎，将不同的三层编排串联，打破从前跨云、跨平台各种割裂的操作界限，提升运维效率，一切皆编排，并能将编排任务沉淀为能力模板传承交接。




例如上图的场景，我们需要扩容一个现网的TKE业务集群，从基础设施层的资源采买，到容器服务初始化部署，和一些集群特性作业操作等均一站式运维编排完成，操作时长从4小时优化到30分钟内，而且集群再次扩容只需简单修改几个编排参数执行，避免了繁琐重复的操作。在玄图平台能力中将通过自助开发可编排的原子（包括操作、接口、算法等），一切操作皆编排。


2.3 DataOps助力运维转型


2.3.1 TKE资源动态调度


K8S的特性是资源一旦分配给工作负载，就会被独占，即使是空跑状态，其他工作负载也不能复用。一般来说用户申请的资源会远超实际需求，Pod规格和副本数设置很大，或者HPA最小副本数设置很高，并且不会主动去释放资源。这样会导致K8S集群存在大量的空闲资源，集群的总体资源使用率不高。为了解决这个问题，我们需要主动对工作负载做资源动态调度。如下图所示，预测模型通过TKE自带的hpa-metrics-server拿到workload当前使用的CPU核数并落地DB，通过API-Server拿到workload当前分配的CPU核数。调度器Scheduler根据预测模型的预测值动态调整workload的副本数。




动态调度模型使用过去一个时间周期内同一时间点的负载数据拟合得到CPU核数预测值，为了保证资源充足，模型会根据当前实际使用的CPU核数再预留一倍的冗余，并且至少保留一个副本，结合目前已经分配的核数得到最终预估分配核数。最后，调度器根据模型的预估分配核数动态修改workload的副本数，释放空闲资源。






执行资源动态调度后收益非常明显，集群空闲资源被释放出来，可以承载更多的workload，在总核数为1万核的集群实践，可以释放一半的空闲CPU，集群整体CPU利用率从15%提升到28%。


2.3.2 TBDS资源动态调度


经过统计我们发现腾讯云TBDS数据仓库集群CPU的总体使用率仅为55%左右。如下图所示，蓝色线是分配的资源，绿色线是使用的资源，大部分应用组资源池，存在空闲时间段，而且相互错峰的情况。我们累计有500+个应用组，抽取几个大应用组统计其繁忙时间段，发现存在明显的错峰情况。




为了进一步提升资源使用率，需要对资源做动态分配，简单的说，当资源使用少的时候，就少分配些，当资源使用多的使用，就分配多些，分配使用动态调整。动态分配算法模型，大体上分两步，第一步，先计算出每个应用组的预估分配核数。因为总分配核数一定，所以还需第二步根据预估分配核数的占比情况算实际分配核数。预估分配核数怎么算呢？首先，pt0是基线，目前用线性回归来拟合，但拟合的结果会波动很大，所以根据实际的任务要求，根据当前的资源使用核数，给拟合结果设置了下限，又根据应用组总资源池不能过大实际要求，跟拟合值设置了上限。所以，分配模型的特点有动态的上下限，另外，这里给当前的使用值翻倍预估，目的是当任务需要资源时，分配的资源可得到快速增长，从而不会影响任务的执行，特别是大任务。




执行动态调度后收益非常明显，集群资源利用率从55.4%提升到79.5%。从动态分配前后的对比图可以看到，总成本降低了1/3。其次是任务执行效率也有提高，经过对4000+个分析计算任务的执行统计，平均执行时间从27.5分钟降低到18.1分钟，执行效率提升52%。.





2.4 云原生应用监控


服务正式上线之后，我们需要掌握其运营状况，比如QPS、成功率、响应延迟、容量负载水位等指标。一般是通过代码埋点输出日志，然后统计日志获得，或者是程序主动上报网管系统获得，不管是哪种方式成本都不低。我们需要在TKE集群部署Prometheus主动采集workload负载指标和用户自定义指标，随着集群规模不断扩大，Promethues不支持容灾部署，不支持分布式，单实例容量瓶颈等问题也凸显出来，最后我们放弃了原生的Prometheus，转而使用Thanos（灭霸）实现了分布式、高可用容灾部署和数据长期存储。Thanos Query 可以对数据进行聚合与去重，所以可以很轻松实现高可用：相同的 Prometheus 部署多个副本(都附带 Sidecar)，然后 Thanos Query 去所有 Sidecar 查数据，即便有一个 Prometheus 实例挂掉过一段时间，数据聚合与去重后仍然能得到完整数据。




Thanos支持将数据上传到各种对象存储（比如COS）以供长期保存 (Prometheus TSDB 数据格式)，对于需要长期存储的数据，并且使用频率不那么高，最理想的方式是存进对象存储，不限制容量，价格非常便宜。




基于Thanos，我们业务平台实现了高并发、海量的数据采集上报和存储。首先，因为所有流量都会经过网关，Thanos主动采集网关的这些指标到并将其可视化。如下图所示，只要服务接入了业务平台， QPS、耗时、成功率等一目了然，这些指标都无需额外开发即自动获得，对代码0侵入，节省了大量的开发成本。




同时，业务平台也会使用Thanos主动采集负载指标生成服务容量负载水位视图，包括CPU，内存，流量等，如下图所示。




如果服务有额外的指标也可以通过平台的自定义指标采集上报到Thanos，并用Grafana绘制图表。接入平台后，服务运行、负载等运营指标全部自动可视化，节省了开发成本，提升了开发和运营效率。




2.5 云原生业务全链路跟踪（血缘关系链）




随着业务的不断纵深发展，技术服务链条也随之拉长，导致出现异常时定位问题困难，且无法快速评估影响面，因此我们通过构建数据血缘和业务血缘的组合来提升发现问题的能力。数据与业务血缘关系链构建过程，覆盖了数据服务交付的完整生命周期，通过采集每个交付节点的数据流向上下游关系，最终形成一张完整的血缘关系链。在数据交付过程中，主要通过统一血缘上报规范，并与数据开发流程深度集成，做到对数据开发流程无侵入性。在数据服务交付过程中，则主要利用服务网格技术，自动采集微服务之间的服务调用链关系。




血缘关系构建好后，可以应用于血缘可视化检索、影响面评估、故障回溯、根因分析、评估数据价值等很多方面，还可以结合云原生的其他特性，发挥出更大的作用。如结合云原生应用监控系统，在血缘关系链中叠加压测指标、服务负载等多维度分析，可以为资源容量评估提供准确的依据，也可以分析出调用链上的瓶颈点在哪里，提供为某些非核心服务配置服务降级策略和限频限流策略的依据，避免突发流量影响核心服务体验。如下图所示为一个典型的血缘应用场景，当运营人员收到告警马上可以知晓，故障影响到哪些接口，哪些应用，哪些项目，哪些指标等。通过精准的影响面评估，可以提早与业务侧沟通相应的应急预案。



2.6 云原生环境下的混沌工程


混沌工程是一种在软件或服务中进行各种试验来验证系统稳定性和健壮性的实验方法。Adrian Cockcroft给出了另一个定义则是：混沌工程是一种确保失败所带来的影响能够被减少的实验。在我们的微服务场景下，相对于单体应用，服务链路更长更复杂，任何一点的异常都可能影响全局服务，如何让业务团队更加了解系统可靠性，对服务更有信心呢？我们需要混沌工程，来进行有预期、有计划的故障模拟，验证业务服务的健壮性，提早发现风险隐患和薄弱之处，并进行修复，避免线上真正故障时手忙脚乱。当然,业务集群上存在大量的服务，没有目的性的随意破坏，“爆炸半径”失控，将影响整个业务集群，因此混沌工程需要经过精心设计，在可控的环境中进行。目前我们已加入公司内部混沌工程开源协同OTeam，搭建起第一版的混沌工程实验平台，进行实验设计，这里以云服务平台，注入CPU负载实验测试。实验目标，可以包括云服务平台和非云服务。




实验配置，即设计实验，当前的原子包括cpu、内存、io、状态等，最后监控配置，是可选项，我们直接使用集群本身的监控视图观察。实验设计配置完成后，启动实验，观察相关监控视图。




这里我们TKE集群中的服务设计了CPU负载注入演习，启动实验后，CPU按预期提升，当CPU持续高负载时，服务正常且触发自动扩容，无请求超时用户无感知，符合预期，加深了团队对系统可靠性的理解和认知。


2.7 DevOps 的持续集成与交付


一个稳定运营的运维体系必然有相应的服务持续集成与交付方式与之配套，在云原生体系下我们构建了基于Kubernets/Docker技术工具链的服务CI/CD工作流，同时最大力度支持公司现有CI/CD服务组件，从而实现服务的快速构建、高效集成和部署交付。以下是CI/CD的整体流程图：

2.7.1 数据营销开发者平台-奇点（ODP）中CI的设计与实践经验

1）构建镜像构建镜像是指业务代码打包或者编译打包所需的环境，包括编译工具、编译命令、编译参数等部分，所有的构建任务都是在使用构建镜像的容器内完成的。是业务代码变成制品的必须依赖。构建的镜像主要分为以下两种类型：

• 公共镜像：奇点针对通用的场景，提供了一系列的公共镜像，如 tlinux、go、php、nodejs等。
• 自定义镜像：某些业务服务构建打包，有特殊的库依赖或者环境依赖，已有的公共镜像满足不了业务需求，此时可以通过提交自定义构建镜像加入到编译环境中选择。
• 
  
  

2）CI流水线引擎目前支持公司已有的CI流水线引擎来配置流水线和执行构建任务(如蓝盾、QCI、Orange CI)，也支持业界主流工具(如jenkins、Travis CI、jfrog)，通过“模板+参数化”的方式满足业务服务编译的需求场景。3）CI任务触发方式目前CI任务触发方式支持“人工触发模式”、“自动触发模式”、“流水线模式”、“快速发布模式”等多种模式。人工触发模式：使用者可以在奇点的部署列表中选择分支或tag以及构建流水线（奇点支持同一服务配置多条流水线）自动化完成构建、部署。该方式可以灵活操作，如未修改代码时，调整编译命令重新验证可以通过人工触发的方式来完成，如下图所示:

• 自动触发模式：奇点服务创建时，需要关联git地址或者创建全新的git项目，此时会自动注册webhook，监听push事件自动触发流水线构建、部署或者快速发布到测试环境
• 流水线模式 ：跟人工触发一样，会自动发起CI构建任务和自动部署测试环境
• 快速发布模式：快速发布流程如下图所示，针对非编译型服务，如PHP或者Python等服务，修改某个静态文件或者脚本文件，无需重新执行一遍流水线，将变更的文件下发到容器内对应位置，最快的速度方便开发同学调试和验证.对于编译型的服务，也支持快速发布，前提条件是：编译出的二进制文件必须能在linux上运行(例如golang的服务可在windows下交叉编译为linux可执行程序)，并配置好重启命令即可( 任务发布时会自动打包和下载解压到容器内，并且执行指定的重启命令 )。
  

2.7.2 奇点(ODP)中的 CD 设计与实践经验

1）可运行多种镜像镜像是服务运行所依赖的环境，包括第三方库以及操作系统版本。目前也支持公共运行镜像和业务自定义运行镜像，可以在集成配置页面选择运行镜像

2）支持修改/增加系统环境变量服务编译构建时、服务启动时，需要根据当前部署版本来做相应的参数配置或者配置加载，此时需要通过环境变量来标识。奇点中根据用户自定义配置，生成yaml文件时会注入到container中；同时kubernetes自身的部分参数，也以环境变量的方式注入到container中，方便业务程序获取pod自身信息，如POD名称以及当前POD的IP信息等。

3）支持自定义启动命令支持自定义的业务进程路径、启动参数、启动前置处理等命令集合，为兼容启动参数中的特殊字符，会把启动命令中写入到shell脚本然后执行。另外，启动命令必须确保拉起的进程是常驻进程以及前台模式。


4）健康检查健康检查对线上业务来说，是保证服务的正常、稳定运行的重要手段。Kubernetes提供了以探针为主的健康检查方式，对于故障服务会被及时自动下线，通过重启服务的方式尝试使服务自动恢复。目前主要支持以下两种方式：

• Liveness探针：用于判断 Container 是否处于运行状态，非 running状态，kubelet 会 kill 掉 Container，然后根据其设置的 restart policy 进行相应操作。
• Readness 探针: 用于判断服务是否已经 ready，对外提供服务，如果检测未通过，服务所在的 Pod 的 IP 地址会从服务的 endpoints 中被移除，不会接受或响应任何请求。
  

此外，奇点中支持用户定义健康检查规则，这样会自动生成对应的Liveness和Readness配置。


5）服务部署使用CI流水线的方式构建和部署，推荐基于tag来部署（可溯源）。




四、业务上云收益


从自研上云开始，我们就确定了云原生的上云方案，经过持续迭代，已经建立了一套比较完整的云原生运维体系，王者荣耀、和平精英等全部游戏的数据运营活动已经All IN 云原生。云原生的效能优势和技术红利不断释放出来，我们实现了低成本、高效率构建支持高并发场景的在线服务，又快又稳的支撑游戏运营活动。


1、成本方面腾讯云产品开箱即用，对于一些创新业务想做技术调研非常方便，用完即销毁，成本很低。另外云产品都是免运维自行托管在云端，如TKE的Master和etcd都是托管腾讯云，可以节省人工运维成本，让我们更专注于做核心业务。


2、稳定性方面云原生上云后，服务获得了快速扩容、弹性伸缩的能力，抗压能力增强，让我们可以更加从容面对各种突发流量，机器故障后TKE自动迁移Pod让服务获得故障自愈的能力。此外，TKE将各类资源定义成描述文件，整个应用环境通过容器的方式统一，避免了环境不一致的风险。


3、效率方面借助跟云产品的深度集成，方便开发人员完成一站式研发、运维工作。从业务需求立项到拉分支开发，再到测试环境功能回归验证，再部署到预发验证及最后上线，整个持续集成可以做到分钟级。相较于传统DO分离的运营模式，发布耗时从小时级缩短到分钟级，效率提升数倍。日常工作包括扩缩容、单机故障处理、机房裁撤等被降维简化，运维变得更加简单可信赖。

4、赋能业务云上产品非常多，涵盖了计算、存储、大数据等诸多领域，可以节省业务创新带来的技术成本。我们在用的包括TKE、CFS、COS、CKafka、VOD等20多个产品都是直接开箱即用，分钟级交付，极大的方便了业务新需求的调研和上线。


五、总结


云原生给运维体系带来的是挑战更是机遇，如何在这波云计算浪潮中，寻找运维的定位与价值，我想是每一位运维人应该思考的问题。本文是个人近几年的所见、所闻、所思做个小结，提出的观点不一定正确，希望能给大家多一个思考的方向，也欢迎批评指正。最后，也将我们的转型思路、方法与实践分享于此，提供给后面更多面临同样挑战的团队借鉴与参考。我们的转型之路还在路上，未来我们将继续扎根业务，深耕云原生环境运维，通过数据、编排、DevOps、AIOps等能力，进一步提升服务水平与用户体验。

前言

随着公司自研上云战略如火如荼地进行，IEG-增值服务部作为较早一批响应的团队，截止目前自研上云已完成1/3的流量切换，日PV超百亿。切云的服务大量采用了云原生的应用与技术架构，作为公司第一批面临云原生环境的业务运维，深切感受到云原生给运维工作带来的机遇与挑战，运维模式的转型已经迫在眉睫，此篇文章最大的价值在于将我们的转型思路、方法与实践，提供给后面更多面临同样挑战的团队借鉴与参考。下面我将从业务场景、运维转型之道、云端收益等几个方面来跟大家一起来探讨。

一、业务服务场景介绍


DataMore是IEG增值服务部为游戏项目组提供的一站式智能游戏运营方案平台，基于游戏日志数据，利用实时与离线计算打造数据营销能力，为业务提供以解决运营问题为目标的数据运营服务方案。与传统的游戏运营体系不同，DataMore游戏数据运营平台具有脱离游戏版本，对研发侧依赖小，计算能力与精细化运营能力强的特点，可以为游戏业务带来更低成本、更快速高效的精细化运营，并提供丰富的游戏运营方案。DataMore在各个生命周期，多种游戏品类上沉淀了许多运营方案以及工程化的运营系统，覆盖新进、活跃、流失、留存、付费和传播等多个阶段，包括邀请好友、任务中心、砍价拼团、低活跃干预、流失召回等多种数据运营方案，使得游戏业务可以快捷的找到适合自身游戏阶段、针对特定运营问题的解决方案。部分方案截图：




DataMore在技术架构上采用了微服务设计的理念，采用服务型开发架构，将数据营销服务拆分成独立、通用的服务能力，同时构建了应用和服务中台，能够通过组合这些通用服务快速而轻松的构建专属应用服务。DataMore活动覆盖了互娱几乎所有的游戏，落地场景非常多，每天都有新活动上线，而且周期短，节奏快，活动周期一般只持续一两周，日PV超过200亿，QPS峰值超过20+万，落地场景覆盖王者荣耀、和平精英在内的所有游戏及周边应用（如助手、微信游戏中心等）。


二、基于云原生环境开发者平台


相信大家对云原生的概念已经不陌生，但很难精准地去解释云原生具体是个什么东西，原因是云原生没有很确切的定义，且不断在发展演变当中。Pivotal 公司的 Matt Stine 于2013年首次提出云原生（CloudNative）的概念，旨在说明云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。2015年云原生计算基金会（CNCF），对云原生的定义为：“云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格（Service Mesh）、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。”。目前形成云原生理解上的最大共识概括为4个核心要点：DevOps+持续交付+微服务+容器，即基于这”4件套”构建的应用我们暂且认为就是云原生应用了。同时可以享受到云端极为丰富的PaaS组件，如业务后续使用到的数据库、缓存、中间件、存储、CDN等等，并且具备无缝在不同云厂商间透明迁移的能力。为适配云原生环境的数据营销服务的需求，部门推出了奇点（ODP）平台（基于腾讯游戏数据&营销服务能力，以微服务架构为基础，构建的集代码管理、服务开发、运维发布、服务运营为一体的一站式开发运营平台）实现了真正意义上的DevOps服务闭环，贯穿了服务交付的CI、CD、CO环节，得益于公司内外部更多优秀组件的集成，包括TKE、蓝盾、QCI、Envoy等。


三、云原生运维转型、挑战、目标与实践


1、云原生运维转型思维


这几年运维界听到最多的几句话：“云计算会淘汰掉运维！整个运维行业可能被干掉！再不转换运维就要丢饭碗”，诸如此类。那真相到底是什么？行业有一个共识，即运维工作本身交付的是一种服务，下面举一个可能不太恰当的例子，或者可以帮助大家找到答案。云计算时代好比组装一辆汽车，根据客户的需要，通过PaaS能力选择匹配的引擎、车轮、离合器、 悬架、车控制系统等进行拼装。客户不用关心汽车各元部件的实现原理，最终获得是一辆满足自身要求的汽车。光有了汽车是玩不转的。还需要有修路、加油站、交通控制等服务体系，运维就是承担这个角色。相比传统运维，确实是少了自己采购元组与组装的工作。到了后云计算时代（云原生），出现了一个DevOps公司，引入新技术与理念，声称已经将修路、加油站、交通控制等环节都打通了，形成了一体化服务能力，并邀请运维哥一起加入创业。在这个阶段，运维哥出去单干，大概率会翻车。但加入 DevOps 公司，运维的价值到底还有什么呢？因此，升级与转型是必然的，例如将普通国道升级成高速公路；实现客户在高速路上不停车换轮胎；贴近并理解客户，规划行程中所需的服务来提升客户体验；通过提升智能化水平，连接交通管制，缩短航程，避开损坏路段等等。相信大家心中已经有自己答案了。回到原点的灵魂拷问：“云原生背景下，运维不做转型会不会死？”，“运维要如何快速自救和升级？”。

我的观点：

• 不会死，但未来整条价值交付链没有你什么事了；
• 转型 SRE 是一种选择。
  

接下来介绍我们运维体系是如何进行转型升级的，首先我们的转型理论基础来源于DevOps框架，从中抽取出符合现阶段服务场景要求的模型，从文化与技术两大方向反复去实践与论证，也获取了非常好的效果。下图是Gartner于2015年发布的DevOps实践模型，放在2020年的今天来看，确实具有很强的前瞻性，不少观点经过我们的验证是正确的，例如：Feature Teams(特性团队)、Developer Self-Service(开发者自助服务)、Infrastructure as Code(基础设施即代码)、Integrated Tool Chains(集成工具链，CI-CT-CO)、One-Step Build，Test，Deploy(一键程序构建，测试，部署)等等。下面从文化与技术两个层面来剖析：



1）文化层面

以下几点是我们中心内部实行的几个机制，供作参考，因不同团队间存在一定差异，此处不展开说明。

• 开发与运维成立FT虚拟团队，实现组织上的融合；
• 开发或运维侧的例会、技术分享、事件复盘，FT成员全程参与；
• 项目立项时，运维接口人需要做“左移”，即提前参与技术架构讨论，有助于运维的问题提前在方案讨论或开发阶段提前 ，有效做好防范与规避；
• 建立收集各方反馈问题与建议的机制与渠道，有效将好的想法影响至平台下个版本的迭代中，实现持续改进与优化。
• 
  

2）技术层面


下图是个人绘制的传统运维到云原生运维的价值过渡，很明显的一个特性是往更高阶领域去涉足，传统运维投入将大幅度减弱。目标意指将更贴近业务、理解业务、通过数据与AI的能力，提升业务持续服务的能力及用户体验，同时确保整个价值交付链的畅通与高效。





在云原生背景下，我们对运维体系进行了升级，在原有基础运维能力之上确定了以下几个目标：

• 具备服务全链路质量监控覆盖，涵盖数据域与业务域
• 具备一定智能化的资源动态调度、伸缩机制
• 具备一定的故障预警、根因分析、问题定位能力
• 服务具备在交付不同阶段（测试、预发布、运营）抵御异常的能力
• 具备资源高效交付的流程机制与快速上线的能力
• 具备多云的资源编排与管理的能力
• 具备业务快速上云的机制，确保切换过程的高可用性
  

确定了运维能力升级指导思想：基于运维编排的云原生实例化。广义而言，运维的本质就是多个运营事件的有机串联，来达到质量、效率、成本、安全多维收益，而编排是实现有机串联的有效手段，除了可以沉淀运维经验外，还可以有效实现共享。

2、云原生运维转型平台化建设


在运维平台化建设方面，我们在构建原云生运维平台能力–玄图。积极拥抱公司开源协同的机制，通过集成现有优秀平台或组件，如有河图元数据管理平台（CMDB）、蓝鲸标准运维平台、PCG-混沌工程实验平台、蓝鲸服务流程管理平台等等，避免重复性建设，结合我们的服务场景，发挥平台服务效能最大化。思路上借鉴了“瑞士军刀”，我们通过微服务的架构，将云资产（CMDB）管理作为底座，也就是“刀把”。再将剪刀、平口刀、开罐器、螺丝起子、镊子等等集成进来，通过定义资源与上层平台的总线协议，将各类平台工具进行组装，犹如瑞士军刀一样，将轻、快、实用、因地制宜发挥到极致。下面将我们的体系能力进行介绍：

2.1 云原生资产管理公有云/私有云的各类云资源管理，我们叫做资产管理（所有的资源/应用/数据都在资产范畴）。我们知道，传统的大多数cmdb只能管理服务器信息（如ip地址/机架/机房等），在云原生环境下，我们将面对复杂多变的、新生的应用和场景，随之会产生越来越多的管理配置项，这就要求资产管理能够满足各种需求的扩展和未来业务的变化，例如腾讯云的CLB、CDB、COS、Ckafka等等，没有自定义模型属性的CMDB难以将这些云产品纳入管理范畴。在资产管理方案调研的过程中，我们发现资产管理需求与元数据管理十分契合，因此，资产管理，作为河图元数据系统的应用场景落地，通过元数据定义资产管理的模型、属性、组合关系，玄图对元数据的加工、应用实现通用的可灵活调整的业务级资产管理。在我们常见的kafka集群资产管理的场景下，通过河图元数据定义相关的集群、主机模型以及属性，定义他们的组合关系，达到资产管理的要求。




模型代表着一类云资源，模型的属性从各个方面分别描述这一类云资源，模型的属性可以根据场景自由定义和扩展。集群模型，当前的属性包括集群名、cc_set等，主机模型，当前的属性包括ip、类型、区域等，随着业务不断发展变化，我们后续可能会对集群和主机的信息进行不断的扩展，也可能集群下还要管理如CLB等其他类型的云资源信息，采用云资源管理，能很好地适应这种变化。




遵循MOF元对象设施建设标准规范为基础的云资源管理平台，能自由方便地表示所有模型间的关系，包括组合关系、依赖关系和继承关系。组合关系描述了一种组成关系，代表某个模型由另外的模型组成，依赖关系主要用于管理模型之间的依赖，继承关系则可以用来表示一种父子关系。kafka集群和主机的关系我们就可以用组合关系来表示，集群依赖的业务可以用依赖关系来表示，也可 以定义一个主机模型的父类，再派生出不同的子类代表不同的主机类型，但具有父类公共的属性定义。资产管理的数据将直接存储在河图元数据系统中，玄图平台在保留元数据管理灵活自定义的前提下，简化元数据操作管理，适配资产管理的需求，提供高效的查询、检索、变更的能力，以有效管理云资产。


2.2 云端一切操作皆可编排


云原生环境下，运维面临各种不同的公有云/私有云环境和各种跨云/跨平台的操作，给运维操作管理带来了巨大挑战。因此，我们继续构建云原生环境的编排能力，即运维编排，通过开发、封装可编排的组件和插件，提供灵活、可定制、可管理的模板化运维能力，覆盖运维任务的管理、审批、决策、执行、通知等功能，最终实现自动化、智能化运维。我们将运维编排分为三层，即：基础设施层、容器服务层、应用层。





如上图所示：

• 云资源编排，编排对象是各类云资源，包括公有云、私有云等，采用terraform来实现多云基础设施的编排，可以覆盖腾讯云、阿里云、AWS、私有云等等。
• kubernetes编排，编排对象是k8s集群资源，采用Helm/YAML进行编排。
• 作业编排，编排对象主要是主机节点，对应的操作任务编排，调用现有的蓝鲸job作业平台。
  

运维编排三层之间如何串联？我们采用了开源的蓝鲸标准运维作为编排引擎，将不同的三层编排串联，打破从前跨云、跨平台各种割裂的操作界限，提升运维效率，一切皆编排，并能将编排任务沉淀为能力模板传承交接。




例如上图的场景，我们需要扩容一个现网的TKE业务集群，从基础设施层的资源采买，到容器服务初始化部署，和一些集群特性作业操作等均一站式运维编排完成，操作时长从4小时优化到30分钟内，而且集群再次扩容只需简单修改几个编排参数执行，避免了繁琐重复的操作。在玄图平台能力中将通过自助开发可编排的原子（包括操作、接口、算法等），一切操作皆编排。


2.3 DataOps助力运维转型


2.3.1 TKE资源动态调度


K8S的特性是资源一旦分配给工作负载，就会被独占，即使是空跑状态，其他工作负载也不能复用。一般来说用户申请的资源会远超实际需求，Pod规格和副本数设置很大，或者HPA最小副本数设置很高，并且不会主动去释放资源。这样会导致K8S集群存在大量的空闲资源，集群的总体资源使用率不高。为了解决这个问题，我们需要主动对工作负载做资源动态调度。如下图所示，预测模型通过TKE自带的hpa-metrics-server拿到workload当前使用的CPU核数并落地DB，通过API-Server拿到workload当前分配的CPU核数。调度器Scheduler根据预测模型的预测值动态调整workload的副本数。




动态调度模型使用过去一个时间周期内同一时间点的负载数据拟合得到CPU核数预测值，为了保证资源充足，模型会根据当前实际使用的CPU核数再预留一倍的冗余，并且至少保留一个副本，结合目前已经分配的核数得到最终预估分配核数。最后，调度器根据模型的预估分配核数动态修改workload的副本数，释放空闲资源。






执行资源动态调度后收益非常明显，集群空闲资源被释放出来，可以承载更多的workload，在总核数为1万核的集群实践，可以释放一半的空闲CPU，集群整体CPU利用率从15%提升到28%。


2.3.2 TBDS资源动态调度


经过统计我们发现腾讯云TBDS数据仓库集群CPU的总体使用率仅为55%左右。如下图所示，蓝色线是分配的资源，绿色线是使用的资源，大部分应用组资源池，存在空闲时间段，而且相互错峰的情况。我们累计有500+个应用组，抽取几个大应用组统计其繁忙时间段，发现存在明显的错峰情况。




为了进一步提升资源使用率，需要对资源做动态分配，简单的说，当资源使用少的时候，就少分配些，当资源使用多的使用，就分配多些，分配使用动态调整。动态分配算法模型，大体上分两步，第一步，先计算出每个应用组的预估分配核数。因为总分配核数一定，所以还需第二步根据预估分配核数的占比情况算实际分配核数。预估分配核数怎么算呢？首先，pt0是基线，目前用线性回归来拟合，但拟合的结果会波动很大，所以根据实际的任务要求，根据当前的资源使用核数，给拟合结果设置了下限，又根据应用组总资源池不能过大实际要求，跟拟合值设置了上限。所以，分配模型的特点有动态的上下限，另外，这里给当前的使用值翻倍预估，目的是当任务需要资源时，分配的资源可得到快速增长，从而不会影响任务的执行，特别是大任务。




执行动态调度后收益非常明显，集群资源利用率从55.4%提升到79.5%。从动态分配前后的对比图可以看到，总成本降低了1/3。其次是任务执行效率也有提高，经过对4000+个分析计算任务的执行统计，平均执行时间从27.5分钟降低到18.1分钟，执行效率提升52%。.





2.4 云原生应用监控


服务正式上线之后，我们需要掌握其运营状况，比如QPS、成功率、响应延迟、容量负载水位等指标。一般是通过代码埋点输出日志，然后统计日志获得，或者是程序主动上报网管系统获得，不管是哪种方式成本都不低。我们需要在TKE集群部署Prometheus主动采集workload负载指标和用户自定义指标，随着集群规模不断扩大，Promethues不支持容灾部署，不支持分布式，单实例容量瓶颈等问题也凸显出来，最后我们放弃了原生的Prometheus，转而使用Thanos（灭霸）实现了分布式、高可用容灾部署和数据长期存储。Thanos Query 可以对数据进行聚合与去重，所以可以很轻松实现高可用：相同的 Prometheus 部署多个副本(都附带 Sidecar)，然后 Thanos Query 去所有 Sidecar 查数据，即便有一个 Prometheus 实例挂掉过一段时间，数据聚合与去重后仍然能得到完整数据。




Thanos支持将数据上传到各种对象存储（比如COS）以供长期保存 (Prometheus TSDB 数据格式)，对于需要长期存储的数据，并且使用频率不那么高，最理想的方式是存进对象存储，不限制容量，价格非常便宜。




基于Thanos，我们业务平台实现了高并发、海量的数据采集上报和存储。首先，因为所有流量都会经过网关，Thanos主动采集网关的这些指标到并将其可视化。如下图所示，只要服务接入了业务平台， QPS、耗时、成功率等一目了然，这些指标都无需额外开发即自动获得，对代码0侵入，节省了大量的开发成本。




同时，业务平台也会使用Thanos主动采集负载指标生成服务容量负载水位视图，包括CPU，内存，流量等，如下图所示。




如果服务有额外的指标也可以通过平台的自定义指标采集上报到Thanos，并用Grafana绘制图表。接入平台后，服务运行、负载等运营指标全部自动可视化，节省了开发成本，提升了开发和运营效率。




2.5 云原生业务全链路跟踪（血缘关系链）




随着业务的不断纵深发展，技术服务链条也随之拉长，导致出现异常时定位问题困难，且无法快速评估影响面，因此我们通过构建数据血缘和业务血缘的组合来提升发现问题的能力。数据与业务血缘关系链构建过程，覆盖了数据服务交付的完整生命周期，通过采集每个交付节点的数据流向上下游关系，最终形成一张完整的血缘关系链。在数据交付过程中，主要通过统一血缘上报规范，并与数据开发流程深度集成，做到对数据开发流程无侵入性。在数据服务交付过程中，则主要利用服务网格技术，自动采集微服务之间的服务调用链关系。




血缘关系构建好后，可以应用于血缘可视化检索、影响面评估、故障回溯、根因分析、评估数据价值等很多方面，还可以结合云原生的其他特性，发挥出更大的作用。如结合云原生应用监控系统，在血缘关系链中叠加压测指标、服务负载等多维度分析，可以为资源容量评估提供准确的依据，也可以分析出调用链上的瓶颈点在哪里，提供为某些非核心服务配置服务降级策略和限频限流策略的依据，避免突发流量影响核心服务体验。如下图所示为一个典型的血缘应用场景，当运营人员收到告警马上可以知晓，故障影响到哪些接口，哪些应用，哪些项目，哪些指标等。通过精准的影响面评估，可以提早与业务侧沟通相应的应急预案。



2.6 云原生环境下的混沌工程


混沌工程是一种在软件或服务中进行各种试验来验证系统稳定性和健壮性的实验方法。Adrian Cockcroft给出了另一个定义则是：混沌工程是一种确保失败所带来的影响能够被减少的实验。在我们的微服务场景下，相对于单体应用，服务链路更长更复杂，任何一点的异常都可能影响全局服务，如何让业务团队更加了解系统可靠性，对服务更有信心呢？我们需要混沌工程，来进行有预期、有计划的故障模拟，验证业务服务的健壮性，提早发现风险隐患和薄弱之处，并进行修复，避免线上真正故障时手忙脚乱。当然,业务集群上存在大量的服务，没有目的性的随意破坏，“爆炸半径”失控，将影响整个业务集群，因此混沌工程需要经过精心设计，在可控的环境中进行。目前我们已加入公司内部混沌工程开源协同OTeam，搭建起第一版的混沌工程实验平台，进行实验设计，这里以云服务平台，注入CPU负载实验测试。实验目标，可以包括云服务平台和非云服务。




实验配置，即设计实验，当前的原子包括cpu、内存、io、状态等，最后监控配置，是可选项，我们直接使用集群本身的监控视图观察。实验设计配置完成后，启动实验，观察相关监控视图。




这里我们TKE集群中的服务设计了CPU负载注入演习，启动实验后，CPU按预期提升，当CPU持续高负载时，服务正常且触发自动扩容，无请求超时用户无感知，符合预期，加深了团队对系统可靠性的理解和认知。


2.7 DevOps 的持续集成与交付


一个稳定运营的运维体系必然有相应的服务持续集成与交付方式与之配套，在云原生体系下我们构建了基于Kubernets/Docker技术工具链的服务CI/CD工作流，同时最大力度支持公司现有CI/CD服务组件，从而实现服务的快速构建、高效集成和部署交付。以下是CI/CD的整体流程图：

2.7.1 数据营销开发者平台-奇点（ODP）中CI的设计与实践经验

1）构建镜像构建镜像是指业务代码打包或者编译打包所需的环境，包括编译工具、编译命令、编译参数等部分，所有的构建任务都是在使用构建镜像的容器内完成的。是业务代码变成制品的必须依赖。构建的镜像主要分为以下两种类型：

• 公共镜像：奇点针对通用的场景，提供了一系列的公共镜像，如 tlinux、go、php、nodejs等。
• 自定义镜像：某些业务服务构建打包，有特殊的库依赖或者环境依赖，已有的公共镜像满足不了业务需求，此时可以通过提交自定义构建镜像加入到编译环境中选择。
• 
  
  

2）CI流水线引擎目前支持公司已有的CI流水线引擎来配置流水线和执行构建任务(如蓝盾、QCI、Orange CI)，也支持业界主流工具(如jenkins、Travis CI、jfrog)，通过“模板+参数化”的方式满足业务服务编译的需求场景。3）CI任务触发方式目前CI任务触发方式支持“人工触发模式”、“自动触发模式”、“流水线模式”、“快速发布模式”等多种模式。人工触发模式：使用者可以在奇点的部署列表中选择分支或tag以及构建流水线（奇点支持同一服务配置多条流水线）自动化完成构建、部署。该方式可以灵活操作，如未修改代码时，调整编译命令重新验证可以通过人工触发的方式来完成，如下图所示:

• 自动触发模式：奇点服务创建时，需要关联git地址或者创建全新的git项目，此时会自动注册webhook，监听push事件自动触发流水线构建、部署或者快速发布到测试环境
• 流水线模式 ：跟人工触发一样，会自动发起CI构建任务和自动部署测试环境
• 快速发布模式：快速发布流程如下图所示，针对非编译型服务，如PHP或者Python等服务，修改某个静态文件或者脚本文件，无需重新执行一遍流水线，将变更的文件下发到容器内对应位置，最快的速度方便开发同学调试和验证.对于编译型的服务，也支持快速发布，前提条件是：编译出的二进制文件必须能在linux上运行(例如golang的服务可在windows下交叉编译为linux可执行程序)，并配置好重启命令即可( 任务发布时会自动打包和下载解压到容器内，并且执行指定的重启命令 )。
  

2.7.2 奇点(ODP)中的 CD 设计与实践经验

1）可运行多种镜像镜像是服务运行所依赖的环境，包括第三方库以及操作系统版本。目前也支持公共运行镜像和业务自定义运行镜像，可以在集成配置页面选择运行镜像

2）支持修改/增加系统环境变量服务编译构建时、服务启动时，需要根据当前部署版本来做相应的参数配置或者配置加载，此时需要通过环境变量来标识。奇点中根据用户自定义配置，生成yaml文件时会注入到container中；同时kubernetes自身的部分参数，也以环境变量的方式注入到container中，方便业务程序获取pod自身信息，如POD名称以及当前POD的IP信息等。

3）支持自定义启动命令支持自定义的业务进程路径、启动参数、启动前置处理等命令集合，为兼容启动参数中的特殊字符，会把启动命令中写入到shell脚本然后执行。另外，启动命令必须确保拉起的进程是常驻进程以及前台模式。


4）健康检查健康检查对线上业务来说，是保证服务的正常、稳定运行的重要手段。Kubernetes提供了以探针为主的健康检查方式，对于故障服务会被及时自动下线，通过重启服务的方式尝试使服务自动恢复。目前主要支持以下两种方式：

• Liveness探针：用于判断 Container 是否处于运行状态，非 running状态，kubelet 会 kill 掉 Container，然后根据其设置的 restart policy 进行相应操作。
• Readness 探针: 用于判断服务是否已经 ready，对外提供服务，如果检测未通过，服务所在的 Pod 的 IP 地址会从服务的 endpoints 中被移除，不会接受或响应任何请求。
  

此外，奇点中支持用户定义健康检查规则，这样会自动生成对应的Liveness和Readness配置。


5）服务部署使用CI流水线的方式构建和部署，推荐基于tag来部署（可溯源）。




四、业务上云收益


从自研上云开始，我们就确定了云原生的上云方案，经过持续迭代，已经建立了一套比较完整的云原生运维体系，王者荣耀、和平精英等全部游戏的数据运营活动已经All IN 云原生。云原生的效能优势和技术红利不断释放出来，我们实现了低成本、高效率构建支持高并发场景的在线服务，又快又稳的支撑游戏运营活动。


1、成本方面腾讯云产品开箱即用，对于一些创新业务想做技术调研非常方便，用完即销毁，成本很低。另外云产品都是免运维自行托管在云端，如TKE的Master和etcd都是托管腾讯云，可以节省人工运维成本，让我们更专注于做核心业务。


2、稳定性方面云原生上云后，服务获得了快速扩容、弹性伸缩的能力，抗压能力增强，让我们可以更加从容面对各种突发流量，机器故障后TKE自动迁移Pod让服务获得故障自愈的能力。此外，TKE将各类资源定义成描述文件，整个应用环境通过容器的方式统一，避免了环境不一致的风险。


3、效率方面借助跟云产品的深度集成，方便开发人员完成一站式研发、运维工作。从业务需求立项到拉分支开发，再到测试环境功能回归验证，再部署到预发验证及最后上线，整个持续集成可以做到分钟级。相较于传统DO分离的运营模式，发布耗时从小时级缩短到分钟级，效率提升数倍。日常工作包括扩缩容、单机故障处理、机房裁撤等被降维简化，运维变得更加简单可信赖。

4、赋能业务云上产品非常多，涵盖了计算、存储、大数据等诸多领域，可以节省业务创新带来的技术成本。我们在用的包括TKE、CFS、COS、CKafka、VOD等20多个产品都是直接开箱即用，分钟级交付，极大的方便了业务新需求的调研和上线。


五、总结


云原生给运维体系带来的是挑战更是机遇，如何在这波云计算浪潮中，寻找运维的定位与价值，我想是每一位运维人应该思考的问题。本文是个人近几年的所见、所闻、所思做个小结，提出的观点不一定正确，希望能给大家多一个思考的方向，也欢迎批评指正。最后，也将我们的转型思路、方法与实践分享于此，提供给后面更多面临同样挑战的团队借鉴与参考。我们的转型之路还在路上，未来我们将继续扎根业务，深耕云原生环境运维，通过数据、编排、DevOps、AIOps等能力，进一步提升服务水平与用户体验。