腾讯蓝鲸运维体系架构设计

腾讯蓝鲸运维体系架构设计引子蓝鲸是腾讯游戏应用运维（ARE）技术生态体系的代号，由正在逐步产品化的六大运维平台和众多应用运维（含devops）、运营规划等人员构成。

在应用运维这一领域，蓝鲸以“独特”的方式承载着半个腾讯，也承载着国内游戏行业半数份额。

出自应用运维团队的蓝鲸体系，最初的设计理念，是希望能武装运维，使其可以提供更高维度的服务。

例如，为产品、策划、运营等岗位提供：1.自助化的运营工具；2.数据化决策支持；3.直接的用户体验改善等。

我们受邀于7月16号晚上在高效运维1号群做一次专题分享（届时将有多个群转播，超过1500人在线收看、互动），本文是为保障群内分享效果而提前撰写的背景和概要介绍。

本文尝试以半叙事的方式，概述蓝鲸出现的背景，设计理念，和落地方式，希望业界广大应用运维同行们，在我们的发展历程中能找到自己现阶段的影子，共鸣共勉，共同努力，繁荣应用运维生态。

1. 蓝鲸的背景：运维转型十年前，我们的业务运维忙于这些工作：服务器、网络、OS、DB、发布、变更、监控、故障处理、运营环境信息维护提取等等。

这些工作大多是被动的，或者说是“需求驱动型的“，运维大多数时候在被动的为产品、策划、运营、开发等合作岗位的同学提供操作服务，而且很多是重复性的操作服务。

五年前，我们的一个运维小组发起了转型尝试，目标是使我们的运维团队从“操作服务输出”，转型为“解决方案服务输出”。

三年前，也就是2012年，依据这个先行试点团队的效果评估，整个腾讯游戏的十余个运维团队（目前200+运维）走上了艰难的转型之路，作为落地承载方案的蓝鲸体系同时开始构建。

当年促使我们决心转型的原因，可以归结为以下三点。

原因1：业务红海化行业竞争很激烈，精细化运营越来越重要。

产品和运营人员忙于更贴近用户体验的业务设计和运营设计，开发团队忙于更快更可靠的实现，运维团队则希望为用户提供更高的可用性，不论是刮风下雨，还是发布变更，都能将业务可用性保持在无限接近7*24（此处省略几万字）。

在此之上，还需要能为产品策划运营等其它岗位提供各类运营工具以提高“产品运营”的效率（一直以来，腾讯运维的职能在内部被定义为“技术运营”，所有运维们所在的职级通道就叫做“技术运营通道”），甚至能为运营决策提供准确的数据依据。

原因2：“传统运维”生存空间塌缩几年前我们预感到“传统运维”的职能空间会被逐步压缩：比如一些新技术对运维的传统工作会有一些冲击（此处省略几万字），这一点到今天已经不用再展开说了，近一年运维领域各类危机言论开始满天飞了。

再比如开发团队出于追求更高可用性等原因，在运维不给力的情况下会直接涉足精细化运营领域。

虽然我们认为运维始终是不可或缺的，但也不得不承认传统运维的需求量会有一定的减少，岗位的萎缩对所有从业者都不是好消息，出于自救我们也要尝试转型。

原因3：我们太累了那些年，腾讯游戏疯狂的增长，如果不转型，别提什么辅助决策这样的高级玩意儿，就是发布变更、故障处理之类的运维基础工作都会把我们拖死。

因此，运维转型的长远目标可以归结为：将基础运维服务（发布变更、监控处理、数值调整、数据提取等）尽可能做到运维无人值守，运维提供解决方案（工具）;同时负责随时调整解决方案，但不提供重复性的操作服务，由使用者自助或者外包团队操作；运维分出一部分精力，尝试“用户体验优化”和“运营决策辅助”等运维增值服务。

2. 蓝鲸的设计思想和很多公司的情况不同，在腾讯游戏设计运维技术体系，有4个天然的难处。

1.在运维眼里，这里几乎有着互联网行业中所有的业务类型：有重客户端游戏，网页游戏，各类官网，移动终端游戏，大型游戏平台（平铺式架构，拓扑关系复杂，模块数量上百，服务器数量几千）……2.这里几乎有着互联网行业中所有的流行技术，因为腾讯游戏300多款业务中，大多数是由世界各地开发商开发出来，由腾讯独家代理的所谓“独代游戏”。

因此，这些游戏所使用的开发语言、开发框架、操作系统、数据库等技术组合，是没有直观规律的。

而且由于游戏从签订代理合同到上线运营之间的间隔时间越来越短，开发商很难为了运维体系而对架构或技术做大规模的修改。

3.300多款游戏相互之间是没有关系的，发布变更、故障处理等运维操作场景和操作流程是没有直观规律的，即便是同一个游戏，也可能因为上了一个新版本，新增了几种后台server，或者改变了表结构，而导致运维操作流程发生改变。

4.这些游戏的服务器数量，也就是操作单元，有十余万，而随着容器技术的普及，操作单元的数量还会暴涨。

因此，蓝鲸的设计，不能侵入业务架构，不能依赖业务架构，不能依赖业务所使用的技术，不能依赖有统一的运维操作流程甚至，也最好别指望开发商为你做什么改造，还得支持海量场景（最好能支持十万级操作单元并发）。

最终，我们总结出来的共同点是：运维通过linux命令，可以搞定所有“发布变更故障处理等”运维操作流程。

虽然只有这一点，但也足够了，这至少说明，运维的基础服务，不论是发布变更还是告警处理，都是可以分步骤的，步骤可能是串行的，也可能有分支结构。

蓝鲸的设计思路是：尽可能将单个步骤抽象为原子，再将原子自动化，而后通过任务引擎连接成“串”或者“树状分支结构”实现全自动化。

这种参照SOA的设计，其最大优点在于不依赖业务类型，不依赖架构，不依赖场景，只要运维手工能做的，都可以做成无人值守。

运维需要做两件事，将原子自动化和将原子集成为工具，这两件事也正是蓝鲸体系武装运维的切入点。

1）将原子自动化：运维通过命令可以做的步骤，在蓝鲸作业平台上封装个脚本，就变成了可集成的自动化原子，而运维通过其他运营系统页面操作的步骤，由蓝鲸集成平台中的ESB平台与其对接好接口之后，也变成了可集成的自动化原子。

2）将原子集成为工具：运维/运营工具的开发对传统运维是有一定障碍的，蓝鲸通过几方面的工作来解决这个问题。

在“蓝鲸集成平台”（蓝鲸体系目前有6个平台）中构建了一个PaaS模块，业务运维（devops）无需关注找服务器、部署环境（各种包、mysql、nginx等）等步骤，只需要写好工具本身的逻辑代码上装到PaaS容器就行了，同时还免除了工具的运维成本（高可用、故障修复等）。

基于docker技术，工具的部署也是一键式的。

其次是开发了一套工具代码框架，内置了统一登录、权限、tag等通用功能，更重要的是，不需要一个一个去对接各个系统的接口（原子），因为ESB模块都封装好了，只要写个函数就可以调用这些原子。

再有就是解决运维的前端开发难题——前端样例库。

提供了“从各种页面元素到不同类型的运维工具的页面组合套餐”，减少了运维消耗在前端开发上的时间。

最后，还为蓝鲸开发者提供培训，一般来说，新进毕业生在通过四周以内的培训之后，就可以独立在蓝鲸集成平台中构建APP工具。

到此，蓝鲸已经基本解决了运维构建工具高门槛的问题，而且可以随时低成本的根据业务变化（例如新增了模块，导致发布变更、告警处理流程都变了）调整工具。

运维在“转型”的过程中，需要补充或者需要强化的技能，只有python（Django）和shell及初浅的web开发，这对大多数运维来说，都是可以接受的。

在这种设计模式下，蓝鲸团队的建设方向就很清晰了：1.继续降低工具本身的开发成本，提高PaaS模块的可靠性；2.扩展原子服务，找出运维海量操作流程中，重复度最高的一些原子，构建成平台，封装接口提供给PaaS作为自动化原子，让运维更轻松的调度更多节点，提升单个节点功能密度，升级拓展更多的流程，直到把流程升级到运维无人值守，升级到对产品、策划等岗位的闭环服务为止。

经过三年的发展，蓝鲸体系构建了六个平台，其中后四个都是直接或间接提供原子服务供运维集成的功能性平台：蓝鲸集成平台：包含PaaS、ESB、开发框架、web样例等模块，是运维制作工具APP的平台。

蓝鲸移动平台：蓝鲸体系的移动端操作入口。

蓝鲸作业平台：各种大小文件传输，含参脚本执行类的动作，可以在蓝鲸作业平台封装，通过接口操控。

蓝鲸配置平台：从业务的各层分级结构到子节点的各类属性，都可以直观的存储于蓝鲸配置平台，通过接口存取。

蓝鲸管控平台：一套基于海量标准设计的管控系统，为作业平台提供文件管道和任务管道，为数据平台提供数据管道等，整个蓝鲸体系对OS及容器单元、大数据的所有管控，只依赖管控平台的一个智能agent。

蓝鲸数据平台：基于kafka、storm构建的供应用运维使用的实时计算平台，为上层蓝鲸集成平台上的智能决策类工具族、数据视图类工具族、辅助决策类工具族提供大数据处理及实时计算能力。

Storm之类的技术早已不新鲜，但供运维“使用”的比较少见。

上述平台大多是由运维“维护”的，为了适应运维的技能树，蓝鲸数据平台包括如下特性：1.提供了在线IDE，运维可以用相对熟悉的yaml语言描述运算逻辑，而不需要学习java；2.通过各种渠道对接了大量常用的运营环境数据（客户端数据、服务端数据、网络数据、自定义数据源、在线、登陆、发布变更、营销活动、故障等运营事件）;3.提供了数据字典供运维针对个性化的业务选用实时数据组合来做“运维自动决策”或者“辅助运营决策”。

目前已有的这六个平台的组合，给了应用运维近乎无限的发挥空间。

我们内部有三个运维中心，十几个应用运维组，他们各自支持着不同的业务，各自处于不同的发展阶段和能力水平。

出自应用运维团队的蓝鲸团队，在与他们不断的磨合中持续改进着各个平台，武装应用运维逐级提升服务能力。

一般来说，分三个阶段.大家“尽量”将重复性的，由“运营环境”触发的工作，例如缩容、扩容、开区、合服、告警处理、故障处理等做成全自动化的无人值守，业务架构或者业务需求有变化的时候才去调整解决方案，这算是解放了应用运维自己，至少晚上可以好好睡觉。

因为这类运维基础服务，应用运维必须做好，至于付出的成本和代价，产品策划和开发团队其实并不在意。

或许只有运维经理或运维总监在意，不但在意团队做这类工作的质量成本和效率，还在意做的方式，至少在一个组织架构下，必须是相对标准化的，绝不能是一个人搞一套，走一个员工就要对单个业务的单个场景工具做交接或者推倒重来。

至少在蓝鲸体系下，这类工具用的都是相同的原子组件，相同的集成方式。

将“人”（产品、策划、开发等）触发的工作例如发布、变更、配置调整、日志或数据提取等工作封装成蓝鲸集成平台上的自助APP工具，由产品自己操作或者转给外包操作。

这样既进一步解放了应用运维自己，也让相关岗位的同事不用再看运维脸色，等运维排期，自己就能随时做“产品运营”。

如果做到这一步，应用运维就算是切入业务运营核心流程了，因为越是竞争激烈的重点产品，在“运营”过程中越需要频繁的做重复性的不涉及业务架构的功能或配置调整，例如改数值、改图片、上传加载新脚本等等，其实就是业务的“后台管理端”。