作者简介：刘天斯，负责腾讯游戏大数据管理及运维工作，从事互联网技术运营工作近15年，曾荣获“华章最有价值作者”、“中国十大杰出IT博主”、“WOT十大优秀讲师”、“OpsWorld金牌讲师”、“TOP100优秀出品人”、 “中国数据质量杰出专家奖（2020）”、“DAMA中国数据治理专家奖（2020）”，IEEE与DAMA会员。曾参与国家《数据资产管理实践白皮书》、《数据标准管理白皮书》等多个标准的编写。热衷开源技术的研究，包括大数据资产管理及云原生等领域，擅长大数据治理，数据与业务中台建设、海量运维与规划等工作，曾出版个人著作《python自动化运维：技术与实践》、《循序渐进学Docker》等，个人发明专利10个。

随着公司自研上云战略如火如荼地进行，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公司，引入新技术与理念，声称已经将修路、加油站、交通控制等环节都打通了，形成了一体化服务能力，并邀请运维哥一起加入创业。在这个阶段，运维哥出去单干，大概率会翻车。

公司，运维的价值到底还有什么呢？因此，升级与转型是必然的，例如将普通国道升级成高速公路；实现客户在高速路上不停车换轮胎；贴近并理解客户，规划行程中所需的服务来提升客户体验；通过提升智能化水平，连接交通管制，缩短航程，避开损坏路段等等。相信大家心中已经有自己答案了。回到原点的灵魂拷问：“云原生背景下，运维不做转型会不会死？”，“运维要如何快速自救和升级？”。

1. 不会死，但未来整条价值交付链没有你什么事了；

2. 转型 SRE 是一种选择。

接下来介绍我们运维体系是如何进行转型升级的，首先我们的转型理论基础来源于DevOps框架，从中抽取出符合现阶段服务场景要求的模型，从文化与技术两大方向反复去实践与论证，也获取了非常好的效果。下图是Gartner于2015年发布的DevOps实践模型，放在2020年的今天来看，确实具有很强的前瞻性，不少观点经过我们的验证是正确的，例如：Feature

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

• 开发与运维成立FT虚拟团队，实现组织上的融合；

• 开发或运维侧的例会、技术分享、事件复盘，FT成员全程参与；

• 项目立项时，运维接口人需要做“左移”，即提前参与技术架构讨论，有助于运维的问题提前在方案讨论或开发阶段提前暴露，有效做好防范与规避；

• 建立收集各方反馈问题与建议的机制与渠道，有效将好的想法影响至平台下个版本的迭代中，实现持续改进与优化。

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

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

• 具备服务全链路质量监控覆盖，涵盖数据域与业务域

• 具备一定智能化的资源动态调度、伸缩机制

• 具备一定的故障预警、根因分析、问题定位能力

• 服务具备在交付不同阶段（测试、预发布、运营）抵御异常的能力

• 具备资源高效交付的流程机制与快速上线的能力

• 具备多云的资源编排与管理的能力

• 具备业务快速上云的机制，确保切换过程的高可用性

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

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

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

点个“在看”，一年不宕机