腾讯蓝鲸运维体系架构设计Word下载.docx

腾讯蓝鲸运维体系架构设计Word下载.docx

《腾讯蓝鲸运维体系架构设计Word下载.docx》由会员分享，可在线阅读，更多相关《腾讯蓝鲸运维体系架构设计Word下载.docx（16页珍藏版）》请在冰豆网上搜索。

我们受邀于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.提供了数据字典供运维针对个性化的业务选用实时数据组合来做“运维自动决策”或者“辅助运营决策”。

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

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

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

一般来说，分三个阶段.

阶段1：

运维基础工作自动化

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

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

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

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

阶段2：

辅助产品运营自动化

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

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

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

不同业务的管理端，功能大多各不相同，在过去往往是业务开发兼做管理端，自己找服务器、搭环境、写代码、部署、最可怕的是产品用的不习惯，整天改改改……

这对业务开发来说简直是噩梦，因为他们的本职工作（业务功能开发）不会因为一个管理端而减少，而且业务开发团队的人手永远是不够的，所以大多数业务开发团队都会让新手做这类“永远做不完”的工作。

现在运维能干这类工作，而且不用考虑工具自身的高可用和运维（PaaS是免运维的），用业务开发的话讲，“现在的运维真是帮上大忙了”。

在我们内部的某些产品团队，每当设计一个新产品，业务开发和应用运维团队会各自收到来自产品策划人员发来的需求设计，运维的那一份是《运营工具交互设计文档》。

而在我们内部，个别团队的业务开发在应用运维忙不过来的时候偶尔会自己跑到“蓝鲸集成平台”开发“后台