腾讯蓝鲸如何打造出无可替代的运维团队？
导语
上一篇《腾讯蓝鲸是怎样在腾讯诞生的？》一文中，我们谈到了腾讯蓝鲸的转型背景和设计思路。其实在腾讯游戏的内部，有多个应用运维中心，十几个应用运维组，他们各自支持着不同的业务，各自处于不同的发展阶段和能力水平。
出自应用运维团队的蓝鲸团队，在与他们不断的磨合中持续改进着各个平台，武装应用运维逐级提升服务能力，运维团队逐步走入业务运营的核心流程。
总结来说，可以分为如下三个阶段：
运维阶段一
运维基础工作自动化
“晚上可以好好睡觉了。”
全业务、多角色、全流程、统一外包工作模式
我们“尽量”将重复性的，由“运营环境”触发的基础工作，例如缩容、扩容、开区、合服、告警处理、故障处理等做成全自动化的无人值守，业务架构或者业务需求有变化的时候才去调整解决方案，这算是解放了应用运维自己，至少晚上可以好好睡觉了。
这类运维基础服务，应用运维必须做好，为此要付出的成本和代价，产品策划和开发团队或许并不在意，但运维经理或运维总监却必须要在意。不但要在意团队做这类工作的质量成本和效率，还必须在意做的方式。
在一个组织架构下，运维工作必须是相对标准化的，绝不能是一个人搞一套，走一个员工就要对单个业务的单个场景工具做交接或者推倒重来。
在蓝鲸智云体系下，不论业务版本是由多少厂家提供的，业务架构有多复杂多大的差异化，其基础运维工作必须是标准化的，主要的实现方式就是场景与原子的分离。差异化的运维操作场景是由大量相同的原子组件经过差异化的编排集成出来的。
运维阶段二
辅助产品运营自动化
“现在的运维真是帮上大忙了！”
我们将“人”（产品、策划、开发等）触发的工作，例如发布、变更、配置调整、日志或数据提取等工作封装成蓝鲸PaaS平台（又名蓝鲸集成平台）上的自助运营系统（蓝鲸的App工具），由产品自己操作或者转给外包操作。
这样既进一步解放了应用运维自己，也让相关岗位的同事不用再看运维脸色、等运维排期，自己就能随时做“产品运营”。
做到这一步，应用运维就算是切入业务运营核心流程了。因为越是竞争激烈的重点产品，在“运营”过程中越需要频繁的做重复性的、不涉及业务架构的功能或配置调整，例如改数值、改图片、上传加载新脚本等等，其实就是业务的“后台管理端”。
不同业务的管理端，功能大多各不相同，在过去往往是业务开发兼做管理端，自己找服务器、搭环境、写代码、部署。
最可怕的是产品用的不习惯，整天改改改改改……这对业务开发来说简直是噩梦！因为他们的本职工作（业务功能开发）不会因为一个管理端而减少，而且业务开发团队的人手永远是不够的，所以大多数业务开发团队都会让新手来做这类“永远做不完”的工作。
现在运维能干这类工作，而且不用考虑工具自身的高可用和运维（被托管的应用免运维是PaaS的基础属性之一），用业务开发的话讲，“现在的运维真是帮上大忙了”！
在我们内部的某些产品团队，每当设计一个新产品，业务开发和应用运维团队会各自收到来自产品策划人员发来的需求设计，运维的那一份是《运营工具交互设计文档》。
而在我们内部，个别团队的业务开发在应用运维忙不过来的时候偶尔会自己跑到“蓝鲸集成平台”开发“后台管理端”，然后再和应用运维商量后续修改维护谁来做，很有联合Team的感觉。
满足不同岗位差异化的运营工具需求，其实就是在落地企业工具文化，贯彻“能用工具的地方不用人，必须用人的地方要用工具辅助人”的工具文化思想。而其落地过程中必须解决工具的构建与维护成本问题。
蓝鲸智云内的PaaS平台（蓝鲸集成平台）通过aPaaS的运营时环境托管和iPaaS提供的云API体系完美扫除了阻碍运维团队实现企业工具文化的障碍。一个普通的应用运维，经过两至三周的培训就可以转型为运维开发，借助python这一大多数运维都可以接受的技术，华丽转身。
达到这个阶段，应用运维实际上已经在支持“产品自动化运营”了，从事这类工作的运维有了一个新名字，运维开发。
运维阶段三
数据化运维
“运维危机时代？不存在的。”
2016年，蓝鲸团队将大数据实时/离线计算能力（蓝鲸数据平台）作为原子服务并入蓝鲸智云体系，应用运维的职能翻开了新的一页，也就是第三个阶段--数据化运维。
在传统模式下，应用运维如果想做运营环境大数据分析，需要自己写脚本采集日志或OS指标、传输、入库、交叉查询计算，再搞几个页面展示出来。虽说有开源的东西能做一部分，但一来承载有限，二来易用性不够，最关键的，核心指标达不到运维场景的要求：实时、无损、时序、海量。
而让业务开发团队做这个，比做“管理端”更为难。他们大都在忙于做“经营类数据分析”，而且人手永远“不够用”，很少有舍得用业务开发给运维团队做运营环境数据分析的。应用运维们可能更多的在底下做这些数据平台的“运维”工作，而不是在使用大数据平台。
蓝鲸数据平台是参照运维的技能树量身设计的，运维人员做运营环境大数据分析，只需要做三件事：
第一件事
- 在蓝鲸数据平台页面上标明或选择数据来源
而后各Svr上部署的“蓝鲸管控平台Agent”会进行实时数据汇集，把各地海量Svr上的数据汇集到Kafka集群。
第二件事
- 拖拽或者用SQL描述计算任务（聚合、转换等清洗计算流程）
而后蓝鲸数据平台会选用适当的数据计算引擎进行实时或离线计算（Storm、Spark、Flink、Heron）。
第三件事
- 在蓝鲸集成平台上用APP来展示实时数据视图或者用于某类自动任务的触发
比如，通过各地的服务器日志实时分析用户的登录、注册、消费等各种指标，找出区域性的用户使用问题。
再比如，上了一个新功能，可以通过和研发约定的日志分析用户的使用情况和各种用户行为，或者为了某个营销活动或者新版本，临时的专项设置一些精细化监控，或者为了定位某个问题。
应用运维一般来说都是对口服务某个业务的，对自己的业务形态以及对从用户的角度如何使用都很熟悉，这就决定了：运维是可以理解产品运营策略的，也有能力推测出哪些数据经过怎样的处理，是有辅助运营价值的。
蓝鲸数据平台的出现，降低了运维使用大数据的门槛，直接推动了“运维增值服务”的拓展。
在我们应用运维团队内部，催生了很多由应用运维团队主导的，基于大数据的运维服务化项目，比如“云梯项目”“用户体验优化项目”等。也就是说在这个阶段，“数据化运维”、“大数据运维”等说法，在蓝鲸体系中不是说着玩的，而是很普通的日常工作，从事这类工作的运维有了一个新名字，运维数据分析师。
从应用运维“岗位价值”的角度来说（我们认为一个岗位的价值可以从被其他岗位替代的成本来衡量），当蓝鲸体系将应用运维武装到第三个阶段，就算是逆天了。
如果说第一个阶段的运维工作，开发等团队可以通过IaaS的高弹性（现在还不大靠谱）及业务架构的高可用（假设他们做得到）轻松替代的话，那在第二个阶段就要付出一些成本了，毕竟是硬性增加了开发团队的建设及维护工作量。
而在第三个阶段，要替代运维，对业务开发来说就太为难了。应用运维们借助蓝鲸数据平台可以大量进行业务开发团队从成本上难以承受的工作——运营环境大数据分析，来进行产品运营的决策辅助。
被切分成不同产品线的业务开发很难各自搞一套数据平台，而合并到一起的专业数据团队即使在分析营销数据之余还有精力，也难以同时具备理解业务用法、掌控业务数据与运营环境数据、熟悉产品运营思路三个要素，只有应用运维同时拥有这三种属性。
所以，业界当前在担忧的运维危机，我们在几年前也担心过，而现在，不存在了。
在腾讯的很多部门，即便是边角的支撑团队，都在为其所支撑的产品线的市场竞争力和口碑而倾尽全力。
通过数据化运维，我们希望协助产品策划人员，在红海竞争中通过我们对精细化运营的一些努力，为业务提升一点点竞争力。我们希望为产品策划和运营人员提供尽可能全面的辅助运营服务。
或许当他们某一天离开腾讯后，在新的公司会感觉各种不适应。
◆ ◆ ◆ ◆
更高级的阶段
智能化运维
◆ ◆ ◆ ◆
数据化运维之上，我们还希望能达到更高级的运维阶段：智能化运维，基于智能算法的机器自我学习，训练机器智能运维模型，实现无人值守和智能的运维与运营。
这一点，目前腾讯内部也正处于建设和逐步成熟的阶段，暂时还不能透露太多，对于蓝鲸团队来说，在这一阶段为应用运维团队构建的核心基础设施，是蓝鲸挖掘平台。
通过蓝鲸智云研发运营一体化平台的支撑，运维团队实现了数据化运维，进入到业务运营的核心流程，成为了业务运营中无可替代的重要一环。
而腾讯蓝鲸团队也秉持着开放共赢的态度，逐渐将蓝鲸智云体系开放出来，构建生态、武装运维，加速非互联网企业的运维转型。敬请期待下一篇文章。
作者介绍：党受辉
腾讯蓝鲸产品中心总监，T4专家工程师
加入腾讯后负责QQ游戏平台运维团队管理，2012年起负责腾讯游戏技术支撑体系（蓝鲸智云）的设计、建设和运营。
结合微服务、云、大数据等理念及前沿技术，构建独立部署的技术运营PaaS平台，通过SaaS化产品助力应用运维团队的转型升级，推动DevOps生态和智能化运维，致力于改变中国的运维行业。
2017年带领的蓝鲸团队获得了腾讯公司2017下半年技术突破唯一金奖和年度技术突破奖。