|
引子
最近，在运维圈里看到触控科技的萧总提出的一个概念“运维2.0”，学习之后，感触颇多，和几年前腾讯游戏的应用运维团队发起的“运维转型”战略项目神似，那个项目在数年间几乎重塑了“应用运维”在腾讯游戏的定义，而在过程中带动并承载这次转型的具体实现，叫蓝鲸。
蓝鲸是腾讯游戏应用运维（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.提供了数据字典供运维针对个性化的业务选用实时数据组合来做“运维自动决策”或者“辅助运营决策”。
目前已有的这六个平台的组合，给了应用运维近乎无限的发挥空间。
我们内部有三个运维中心，十几个应用运维组，他们各自支持着不同的业务，各自处于不同的发展阶段和能力水平。
出自应用运维团队的蓝鲸团队，在与他们不断的磨合中持续改进着各个平台，武装应用运维逐级提升服务能力。一般来说，分三个阶段.
阶段1：运维基础工作自动化
大家“尽量”将重复性的，由“运营环境”触发的工作，例如缩容、扩容、开区、合服、告警处理、故障处理等做成全自动化的无人值守，业务架构或者业务需求有变化的时候才去调整解决方案，这算是解放了应用运维自己，至少晚上可以好好睡觉。
因为这类运维基础服务，应用运维必须做好，至于付出的成本和代价，产品策划和开发团队其实并不在意。
或许只有运维经理或运维总监在意，不但在意团队做这类工作的质量成本和效率，还在意做的方式，至少在一个组织架构下，必须是相对标准化的，绝不能是一个人搞一套，走一个员工就要对单个业务的单个场景工具做交接或者推倒重来。至少在蓝鲸体系下，这类工具用的都是相同的原子组件，相同的集成方式。
阶段2：辅助产品运营自动化
将“人”（产品、策划、开发等）触发的工作例如发布、变更、配置调整、日志或数据提取等工作封装成蓝鲸集成平台上的自助APP工具，由产品自己操作或者转给外包操作。
这样既进一步解放了应用运维自己，也让相关岗位的同事不用再看运维脸色，等运维排期，自己就能随时做“产品运营”。
如果做到这一步，应用运维就算是切入业务运营核心流程了，因为越是竞争激烈的重点产品，在“运营”过程中越需要频繁的做重复性的不涉及业务架构的功能或配置调整，例如改数值、改图片、上传加载新脚本等等，其实就是业务的“后台管理端”。
不同业务的管理端，功能大多各不相同，在过去往往是业务开发兼做管理端，自己找服务器、搭环境、写代码、部署、最可怕的是产品用的不习惯，整天改改改……
这对业务开发来说简直是噩梦，因为他们的本职工作（业务功能开发）不会因为一个管理端而减少，而且业务开发团队的人手永远是不够的，所以大多数业务开发团队都会让新手做这类“永远做不完”的工作。
现在运维能干这类工作，而且不用考虑工具自身的高可用和运维（PaaS是免运维的），用业务开发的话讲，“现在的运维真是帮上大忙了”。
在我们内部的某些产品团队，每当设计一个新产品，业务开发和应用运维团队会各自收到来自产品策划人员发来的需求设计，运维的那一份是《运营工具交互设计文档》。
而在我们内部，个别团队的业务开发在应用运维忙不过来的时候偶尔会自己跑到“蓝鲸集成平台”开发“后台管理端”，然后再和应用运维商量后续修改维护谁来做，很有联合team的感觉。
达到这个阶段，应用运维实际上已经在支持“产品自动化运营”了。
阶段3：数据化运维
接下来，当蓝鲸团队将大数据实时汇集计算的能力作为原子服务并入蓝鲸体系的时候，应用运维的职能翻开了新的一页，也就是第三个阶段。
在传统模式下，应用运维如果想做运营环境大数据分析，需要自己写脚本采集日志或OS指标，传输，入库，交叉查询计算，再搞几个页面展示出来，虽说有开源的东西能做一部分，但一来承载有限，二来易用性不够，最关键的，实时性、稳定性、完整性等都有欠缺。
而让业务开发团队做这个，也真是为难了，比做“管理端”更为难：
因为相对于单个项目开发团队来说，实现实时计算所投入的成本相对太高了。所以很多公司选择在支撑团队内，为所有的业务部门专门组建“商业智能组”或者“数据挖掘组”之类的公共服务团队。
但这类团队大都在忙于做“经营类数据分析”，而且人手永远“不够用”，很少有舍得用他们给运维做运营环境数据分析的，应用运维们可能更多的在底下做这些数据平台的“运维”工作，而不是在使用大数据平台。
蓝鲸数据平台是参照运维的技能树量身设计的，运维做运营环境大数据分析，只需要做三件事：
1.写脚本描述采集内容，给svr上部署的“蓝鲸管控平台agent”，管控平台会进行实时数据汇集，把各地海量svr上的数据汇集到kafka集群；
2.用yaml描述所上报数据的计算逻辑，用于storm实时计算；
3.在蓝鲸集成平台上用APP来展示实时数据视图。
比如，通过各地的服务器日志实时分析用户的登录、注册、消费、等各种指标，找出区域性的用户使用问题。
再比如，上了一个新功能，可以通过和研发约定的日志分析用户的使用情况和各种用户行为，或者为了某个营销活动或者新版本，临时的专项设置一些精细化监控，或者为了定位某个问题。
应用运维一般来说都是对口服务某个业务的，对自己的业务形态以及从用户的角度如何使用都很熟悉，这就决定了：运维是可以理解产品运营策略的，也有能力推测出哪些数据经过怎样的处理，是有辅助运营价值的。
蓝鲸数据平台的出现，降低了运维使用大数据的门槛，直接推动了“运维增值服务”的拓展。
在我们应用运维团队内部，催生了很多由应用运维团队主导的，基于大数据的运维服务化项目，比如探索中的“云梯项目”。也就是说在这个阶段，“数据化运维”、“大数据运维”等说法，在蓝鲸体系中不是说着玩的，而是很普通的日常工作。
从应用运维“岗位价值”的角度来说（我们认为一个岗位的价值可以从被其他岗位替代成本来衡量），当蓝鲸体系将应用运维武装到第三个阶段，就算是逆天了。
如果说第一个阶段的运维工作，开发等团队可以通过IaaS的高弹性（现在还不大靠谱）及业务架构的高可用（假设他们做得到）轻松替代的话，那在第二个阶段就要付出一些成本了，毕竟是硬性增加了开发团队的建设及维护工作量。
而在第三个阶段，对业务开发来说就太为难了，也就是说应用运维们借助蓝鲸数据平台可以大量进行业务开发团队从成本上难以承受的工作——运营环境大数据分析，来进行产品运营的决策辅助。
所以，业界当前在担忧的运维危机，我们在几年前也担心过，而现在无所谓了。
“数据运维”在我们内部还属于优化推进阶段，蓝鲸数据平台也在逐步成熟中，我们希望协助产品策划人员，在红海竞争中通过我们对精细化运营的一些努力，为业务提升一点点竞争力。
我们希望为产品策划人员提供尽可能全面的辅助运营服务，或许当他们某一天离开腾讯后，会感觉各种不适应。
记得我们在杭州办蓝鲸沙龙那次，中间茶歇的时候，有个哥们跟我们说了一句话“我现在感觉腾讯游戏成功的背后有很多我们不知道的因素”。
虽然我们很清楚，在腾讯游戏发展的过程中我们所起到的必然不是决定性因素，可能只是其中很小很小的一部分，但他的这句话里所流露出来的那一点点意思，依然给了我们很大的鼓励。在腾讯的很多部门，即便是边角的支撑团队，也在为其所支撑的产品线的市场竞争力和口碑而倾尽全力。
3. 蓝鲸服务
蓝鲸的服务可以分成两类：PaaS和SaaS。
上边提到的所有服务，都是PaaS：
比如蓝鲸集成平台，不管门槛多低，应用运维都需要自己去开发工具APP；
比如蓝鲸作业平台，应用运维需要自己上去写脚本；
再比如蓝鲸数据平台，运维需要自己用脚本写采集逻辑、用yaml写计算逻辑，如果需要结果的实时展示，还得在蓝鲸集成平台做展示APP。
对应用运维来说，PaaS服务是万能的，几乎没有场景限制，只要是原子能覆盖的流程，都能做得出来，非常灵活，还能最大化发挥应用运维的技能，体现其价值：
1.比如可以针对某一种发布做个蓝鲸APP，
2.可以针对某个告警的处理逻辑做个“故障自动恢复”工具APP，
3.针对某个场景，开发一个实时刷新的数据视图APP…
蓝鲸大力发展PaaS服务，也印证了我们的理念：即依靠运维，武装运维，使其能提供更高维度的服务，而不是取代运维，同时迎合了
运营、开发、测试等岗位人员的需求。
用PaaS构建的服务工具，适配场景几乎无限制，高度的定制化使得体验最好，但有“重复建设”以及对于基础运维服务“难以统一化管理”的问题。
因此在很多高频场景，蓝鲸也联合应用运维团队，提供了不少SaaS。
比如针对发布变更场景，结合蓝鲸集成平台上大量的发布变更类工具，蓝鲸推出了“标准运维”APP，使得已经慢慢变成大多数应用运维负担的大量的花样繁多的“操作类APP”得以下架。
这样使得我们逐步的在应用层构建起了标准化场景组件，再允许大家从其他的APP调用“标准运维”接口，也就是说，进行更高层面的“场景调度”。
或者直接使用“标准运维”提供的APP Maker功能针对某一操作流程，拖拽生成类似于快捷方式的“轻应用”，以实现轻量操作类APP的免开发拖拽生成。
这样，也使得蓝鲸生态在运维基础服务层面对业务来说更加安全可靠，面对运维人员的流动，抗风险能力更强。
再比如，在告警处理及故障恢复场景，为了避免运维制作大量针对不同业务的“故障自动恢复”类工具，蓝鲸团队提供了通用的“故障自愈”服务：
1.将基础告警及自定义告警的产生封装成了通用服务；
2.将告警处理中常用的一些节点封装成组件再集成为套餐供运维通过图形化界面选用。
3.当然为了适配个性化的场景，也提供了PaaS编辑器，允许运维用python语言自定义复杂的故障分析树。
4. 收尾
运维是一个被压抑了太久的岗位。在行业的一些交流中，很多公司的运维说他们虽然掌控着运营环境，却在逐渐地被排挤出业务的关键流程中，感到对未来很迷茫。
我只能说，没有充分利用运维的价值，这是他们整个公司的损失，每个业务都是有专职运维的，运维了解运营环境，了解业务架构，了解产品本身，有着丰富的想象力。
而蓝鲸，就是要让运维的想象力爆发出来，并施加到业务上。
蓝鲸，是腾讯游戏的运维们从实战中“总结、提炼、构想、设计、建设”出来的体系，其设计初衷是武装运维，使其能提供更高维度的服务，而不是取代运维，同时迎合了运营、开发、测试等岗位人员的需求。
在所谓的“运维危机”时代，我们更懂得，并成功验证了运维对业务的价值。
蓝鲸曾支撑腾讯游戏走过了不同层级的标准化、自动化时代，当前正在和应用运维一起探索服务化。而我们自己也在慢慢的将各平台逐步产品化，以支持腾讯的投资公司以及自己部署在公有云上的业务和我们的合作伙伴。
希望在经过更多的磨合及历练之后，有一天我们可以和大家一起走的更远。
一个周末写下这些，对于在高效运维群的分享做背景和概要介绍应该足够了，其他更详细的内容和案例，我们本周四（16号）群里见，当然后续我们还会在各地组织蓝鲸沙龙，和业界同行共同探讨应用运维（ARE）的发展方向。 |
