腾讯游戏一直是腾讯最赚钱的部门，其蓝鲸体系以“独特”的方式承载着半个腾讯，也承载着国内游戏行业半数份额。
蓝鲸是腾讯游戏应用运维（ARE）技术生态体系的代号，由正在逐步产品化的六大运维平台和众多应用运维（含devops）、运营规划等人员构成。出自应用运维团队的蓝鲸体系，最初的设计理念，是希望能武装运维，使其可以提供更高维度的服务。例如为产品、策划、运营等岗位提供：自助化的运营工具；数据化决策支持；直接的用户体验改善等。
本文尝试以半叙事的方式，概述蓝鲸出现的背景，设计理念，和落地方式，希望业界广大应用运维同行们，在我们的发展历程中能找到自己现阶段的影子，共鸣共勉，共同努力，繁荣应用运维生态。
蓝鲸的背景：运维转型
十年前，我们的业务运维忙于这些工作：
服务器、网络、OS、DB、发布、变更、监控、故障处理、运营环境信息维护提取等等。
这些工作大多是被动的，或者说是“需求驱动型的“，运维大多数时候在被动的为产品、策划、运营、开发等合作岗位的同学提供操作服务，而且很多是重复性的操作服务。
五年前，我们的一个运维小组发起了转型尝试，目标是使我们的运维团队从“操作服务输出”，转型为“解决方案服务输出”。
三年前，也就是2012年，依据这个先行试点团队的效果评估，整个腾讯游戏的十余个运维团队（目前200+运维）走上了艰难的转型之路，作为落地承载方案的蓝鲸体系同时开始构建。
当年促使我们决心转型的原因，可以归结为以下三点。
原因1：业务红海化
行业竞争很激烈，精细化运营越来越重要。产品和运营人员忙于更贴近用户体验的业务设计和运营设计，开发团队忙于更快更可靠的实现，运维团队则希望为用户提供更高的可用性，不论是刮风下雨，还是发布变更，都能将业务可用性保持在无限接近7*24（此处省略几万字）。
在此之上，还需要能为产品策划运营等其它岗位提供各类运营工具以提高“产品运营”的效率（一直以来，腾讯运维的职能在内部被定义为“技术运营”，所有运维们所在的职级通道就叫做“技术运营通道”），甚至能为运营决策提供准确的数据依据。
原因2：“传统运维”生存空间塌缩
几年前我们预感到“传统运维”的职能空间会被逐步压缩：
比如一些新技术对运维的传统工作会有一些冲击（此处省略几万字），这一点到今天已经不用再展开说了，近一年运维领域各类危机言论开始满天飞了。
再比如开发团队出于追求更高可用性等原因，在运维不给力的情况下会直接涉足精细化运营领域。
虽然我们认为运维始终是不可或缺的，但也不得不承认传统运维的需求量会有一定的减少，岗位的萎缩对所有从业者都不是好消息，出于自救我们也要尝试转型。
原因3：我们太累了
那些年，腾讯游戏疯狂的增长，如果不转型，别提什么辅助决策这样的高级玩意儿，就是发布变更、故障处理之类的运维基础工作都会把我们拖死。
因此，运维转型的长远目标可以归结为：
将基础运维服务（发布变更、监控处理、数值调整、数据提取等）尽可能做到运维无人值守，运维提供解决方案（工具）;
同时负责随时调整解决方案，但不提供重复性的操作服务，由使用者自助或者外包团队操作；
运维分出一部分精力，尝试“用户体验优化”和“运营决策辅助”等运维增值服务。
蓝鲸的设计思想
和很多公司的情况不同，在腾讯游戏设计运维技术体系，有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作为自动化原子，让运维更轻松的调度更多节点，提升单个节点功能密度，升级拓展更多的流程，直到把流程升级到运维无人值守，升级到对产品、策划等岗位的闭环服务为止。
经过三年的发展，蓝鲸体系构建了六个平台，其中后四个都是直接或间接提供原子服务供运维集成的功能性平台：
1. 蓝鲸集成平台：包含PaaS、ESB、开发框架、web样例等模块，是运维制作工具APP的平台。
2. 蓝鲸移动平台：蓝鲸体系的移动端操作入口。
3. 蓝鲸作业平台：各种大小文件传输，含参脚本执行类的动作，可以在蓝鲸作业平台封装，通过接口操控。
4. 蓝鲸配置平台：从业务的各层分级结构到子节点的各类属性，都可以直观的存储于蓝鲸配置平台，通过接口存取。
5. 蓝鲸管控平台：一套基于海量标准设计的管控系统，为作业平台提供文件管道和任务管道，为数据平台提供数据管道等，整个蓝鲸体系对OS及容器单元、大数据的所有管控，只依赖管控平台的一个智能agent。
6. 蓝鲸数据平台：基于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的高弹性（现在还不大靠谱）及业务架构的高可用（假设他们做得到）轻松替代的话，那在第二个阶段就要付出一些成本了，毕竟是硬性增加了开发团队的建设及维护工作量。
而在第三个阶段，对业务开发来说就太为难了，也就是说应用运维们借助蓝鲸数据平台可以大量进行业务开发团队从成本上难以承受的工作——运营环境大数据分析，来进行产品运营的决策辅助。
所以，业界当前在担忧的运维危机，我们在几年前也担心过，而现在无所谓了。
“数据运维”在我们内部还属于优化推进阶段，蓝鲸数据平台也在逐步成熟中，我们希望协助产品策划人员，在红海竞争中通过我们对精细化运营的一些努力，为业务提升一点点竞争力。
我们希望为产品策划人员提供尽可能全面的辅助运营服务，或许当他们某一天离开腾讯后，会感觉各种不适应。
记得我们在杭州办蓝鲸沙龙那次，中间茶歇的时候，有个哥们跟我们说了一句话“我现在感觉腾讯游戏成功的背后有很多我们不知道的因素”。
虽然我们很清楚，在腾讯游戏发展的过程中我们所起到的必然不是决定性因素，可能只是其中很小很小的一部分，但他的这句话里所流露出来的那一点点意思，依然给了我们很大的鼓励。在腾讯的很多部门，即便是边角的支撑团队，也在为其所支撑的产品线的市场竞争力和口碑而倾尽全力。
蓝鲸服务
蓝鲸的服务可以分成两类：PaaS和SaaS。
上边提到的所有服务，都是PaaS：
比如蓝鲸集成平台，不管门槛多低，应用运维都需要自己去开发工具APP。
比如蓝鲸作业平台，应用运维需要自己上去写脚本。
再比如蓝鲸数据平台，运维需要自己用脚本写采集逻辑、用yaml写计算逻辑，如果需要结果的实时展示，还得在蓝鲸集成平台做展示APP。
对应用运维来说，PaaS服务是万能的，几乎没有场景限制，只要是原子能覆盖的流程，都能做得出来，非常灵活，还能最大化发挥应用运维的技能，体现其价值：
比如可以针对某一种发布做个蓝鲸APP
可以针对某个告警的处理逻辑做个“故障自动恢复”工具APP
针对某个场景，开发一个实时刷新的数据视图APP…
蓝鲸大力发展PaaS服务，也印证了我们的理念：即依靠运维，武装运维，使其能提供更高维度的服务，而不是取代运维，同时迎合了运营、开发、测试等岗位人员的需求。
用PaaS构建的服务工具，适配场景几乎无限制，高度的定制化使得体验最好，但有“重复建设”以及对于基础运维服务“难以统一化管理”的问题。
因此在很多高频场景，蓝鲸也联合应用运维团队，提供了不少SaaS。
比如针对发布变更场景，结合蓝鲸集成平台上大量的发布变更类工具，蓝鲸推出了“标准运维”APP，使得已经慢慢变成大多数应用运维负担的大量的花样繁多的“操作类APP”得以下架。
这样使得我们逐步的在应用层构建起了标准化场景组件，再允许大家从其他的APP调用“标准运维”接口，也就是说，进行更高层面的“场景调度”。
或者直接使用“标准运维”提供的APP Maker功能针对某一操作流程，拖拽生成类似于快捷方式的“轻应用”，以实现轻量操作类APP的免开发拖拽生成。这样，也使得蓝鲸生态在运维基础服务层面对业务来说更加安全可靠，面对运维人员的流动，抗风险能力更强。
再比如，在告警处理及故障恢复场景，为了避免运维制作大量针对不同业务的“故障自动恢复”类工具，蓝鲸团队提供了通用的“故障自愈”服务：
将基础告警及自定义告警的产生封装成了通用服务；
将告警处理中常用的一些节点封装成组件再集成为套餐供运维通过图形化界面选用。
当然为了适配个性化的场景，也提供了PaaS编辑器，允许运维用python语言自定义复杂的故障分析树。
蓝鲸核心功能
先构建开放式开发（PaaS）能力和集成能力（SOA），然后不断的建设和升级原子，以覆盖更多的场景，支持更多闭环的流程。
1）故障自动恢复怎么做的
过去，通用的，无人值守式的故障修复是大家的理想，而现在是基本要求：
故障，对业务的用户体验和收入有直接的影响，虽然IaaS具备一定的弹性，业务开发也或多或少会做一些架构方面的高可用，但实际上也只能覆盖一部分。因此运维会部署各类监控，来监测运营环境的异常，然后修复。
运维配置的“告警”分为两类：
一类是对业务有直接影响的“报警”，例如在线下降，服务器ping不通、业务进程崩溃、业务进程日志中出现致命字符串（和开发约好的）等。
另一种是“预警”，例如在线波动、CPU、内存异常等等。不管是报警还是预警，都分为处理型和分析型，处理型直接转交系统通过运维预定的逻辑进行自动恢复，分析型则要与事件库里前前后后一定时间区间内的事件（网络告警、DBA告警、发布变更事件、营销活动事件等等）做分析计算，分析是不是有异常，是哪种异常，是什么导致的，应该怎么处理，然后再处理或忽略。
第一类“报警”一般来说运维都有明确的处理预案，而第二类“预警”中的大部分都是简单分析一下就可以忽略掉的，越是精细化运营，越需要运维配置更全面，更细致的高敏感“预警监控”，而这一类往往是误告率最高的。
即使每个只看一眼，也够把运维累死。因此只有实现了通用的，自动处理告警的机制，运维才敢放开手脚大量配置高敏感度“预警监控”来应对精细化运营的要求。
简单的理解，告警的分析过程其实和发布变更没有太大区别，也可以抽象为“串状”或“树状”的逻辑因果关系图，叫FTA（Fault Tree Analysis）。
在蓝鲸体系的设计理念下，非常容易低成本的实现告警自动处理，但运维必须参与其中，配置并维护FTA逻辑图。
为了避免大家各自开发故障恢复类的APP（预计量会很大，后续维护会成问题），早期我们就在蓝鲸集成平台中提供了通用的SaaS形式的“故障自愈”app，运维可以选择对常见的，简单明了的报警直接以拖拽的方式生成一个故障逻辑树。
对于SaaS覆盖不了的需求，应用运维则可以通过前“故障自愈服务”提供的在线IDE自己编码出复杂的故障逻辑树。
当告警再次出现，“故障自愈服务”会代替运维按指定逻辑树进行分析、处理。
下图的例子是凌晨4:25出现的一个穿越火线端口告警，经故障自愈分析为进程异常僵死，重启进程后恢复，从告警到恢复，耗时1分13秒。
到目前为止，我们的运维每天通过故障自愈自动处理的告警，峰值高达十几万条。当然其中绝大多数是运维“任性配置的”高敏感度的“预警监控”，自动分析后，被判定为“目前无需干预”，不启动处理流程。
半年总结中，我们看到的数据是，2015上半年故障自愈系统为运维自动处理告警（报警+预警）331万，其中303万条预警成功率100%，28万报警，成功率94.25%。节省人力10214小时（预警不计算人力节省），保守估计相当于7个运维每天8小时三班倒值守。
2）游戏无人值守自动开区
玩游戏的同学都应该知道游戏分很多不同的大区，各大区除了数据不同之外，其他都是一样的，例如辽宁一区和辽宁二区。因为各种策略需要，每个大区的人数是有限制的，因此游戏常有开新区的需求，有些火爆的游戏，一天可能需要开放几十个甚至上百个大区 。
阶段1：自动化物理部署
对于之前的运维来说，主要的工作量都耗在新区的环境部署上，一般的开区是这样一个流程：
在蓝鲸体系下，应用运维就可在蓝鲸集成平台上写个工具，通过函数调用各原子组件完成这一流程：
有运营系统支持的节点，比如第一个资源调拨步骤，ESB平台已经对接了资源调拨系统；
没有运营系统支持的节点，例如部署svr，修改配置，按顺序启动svr进程之类的，运维就写成脚本封装进蓝鲸作业平台，也可以自制成自动化节点。
应用运维做好这个APP工具之后，下次开区就方便了，点一下，一个大区就部署好了。
后来，运维觉得这样不够闭环，只是自动化的物理部署是不够的。
阶段2：自动化环境部署
大区每次真正对外开放的时候，产品还是要找运维做一些新区的世界时间重置、测试数据清除、官网上增加一个大区，推荐区服改成这个新区等等，很繁琐的工作。
那运维就继续按照这个模式，修改app，升级流程，延长自动化链条。
这样一来，运维就解放了，每当要开一个新区，外包同事就可以代替运维操作一下这个app工具，帮助产品策划人员把新区开出去。
阶段3：自动化决策支持
再后来，产品策划同学找运维来帮忙，因为他们这个游戏什么时候开新区，主要是基于各种数据指标的简单运算结果，而且是产品策划人员用人盯着看，达到指标就通知运维外包同学开区，他们发现应用运维已经从这个流程中消失了，除非工具出问题或者由于版本变更开区流程发生变化，运维才出现一次。
所以，他们就和运维商量能否把他们的决策流程也自动化掉？
因为仅仅开区这一个场景就很消耗他们的人力，尤其是晚上，产品策划都不敢睡觉，怕大区承载超限，浪费拉新流量。
于是运维就再次升级流程，借助蓝鲸数据平台，从各IDC实时拉取各指标，通过实时计算自动触发决策，将开区的决策也封装进工具。
产品要做的，只是在运维提供的蓝鲸APP中设置好开新区的规则。
在调试期间，运维在大区正式开放的前一个节点，会嵌入一个“微信确认”的节点，让产品人工干预一下，避免因为工具bug导致开区失控。
而在稳定期过后，运维会将这个节点从流程中隐藏，这样，每天几十个大区的开放，就完全闭环，没有活人参与了。
在蓝鲸发展的早期，这类开区工具出现了很多，各个业务的开区工具都是运维基于第一个开区工具修改后实现，看上去都很类似，只是流程不同（因为真的没有两个游戏的开区流程是一样的……），先能用，然后再各自慢慢优化。
阶段4：通用开区工具
最后，当开区这个场景的工具达到一定数量后，运维精英们聚在一起根据各自已经实际跑顺的流程和交互的优秀元素，设计了通用的开区工具。
随着其逐步完善，越来越多的运维选择废弃掉自己曾反复雕琢过的，心爱的APP，接入通用工具。
这个过程看似曲折，但在我们这里却是必须的，因为如果没有各自开发的专用工具，很难凭借想象在早期就编出一种设计方案，让所有运维都满意，通过这种先自动化再标准化的方式打造的工具，才是真正的“出自实战”。
从更高的层面来看，这是我们在底层操作标准化、原子组件标准化之上，构建起的应用层标准化。
这一标准化将基础运维场景的“工具构建和操作”做了规范，这也是我在昨天的预热文章中提到的“逐级标准化”的最后一层。这一层，从应用层避免了误操作的发生概率，降低了基础操作工具的维护成本。
3) 自助发布变更
其他的场景例如扩容、缩容、发布、变更、配置修改等等其实和开区这个是类似的，就不一一举例了，思路和故障自愈、开区其实是一样的，不用担心业务是什么架构，什么技术实现，不用管是游戏还是电商还是金融或者什么其他类型，只要是“使用linux或windows作为操作系统平台，linux命令或脚本能覆盖操作需求”都可以支持，当然得有运维参与建设和维护这类工具。
这就是我们要达到的目的之一：应用运维不是操作工，不提供重复性的操作服务（临时帮忙可以），只提供解决方案：
蓝鲸早期，这类操作工具占据了90%的比例，而随着应用层标准化的推进，大量被下架，目前已经不足40%，而且目前凡是“有可能”直接影响业务的操作类工具的开发出于安全考虑已经开始限制。
除此之外，应用运维还大量提供了“产品运营”的辅助工具，这些工作原本不是运维的工作范畴，但为了分担业务开发团队的一些工作量，运维也会参与，而且应用运维基于PaaS构建这类工具，成本低廉效率高，还免维护。
4) 大数据辅助运营
数据运维，我们目前覆盖的场景还很有限，主要是两个方面：
1. 用于技术运营辅助决策：
多维度曲线监控，例如收集业务在线和登陆数据，对两种数据同时采用降幅变化异常判断，当在线升高同时发生登录下降的情况，则可以认为在线发生异常，触发告警。
扩容需求，每5分钟分别采集各模块所有机器的CPU负载和内网流量，以模块为维度每5分钟统一次该模块的CPU平均负载和内网流量总和以及总机器数，将数据合并，如果某个模块连续n次满足平均CPU负载高于x%且流量大于y兆的情况时，判断为需要扩容，扩容机器数量为：该模块机器总量 (平均CPU负载 - x%) / x%和模块机器数量(内网流量 - y) / y中的最大值，然后触发操作。
2. 用于产品运营辅助决策：
有时候一个产品要根据一些实际情况制定运营策略，设置与运营环境相关的一些参数，那需要运维来提供比如一个对局游戏，需要设置一个最高ping值，低于这个值的用户可以参与对局，高于的推荐到更合适的大区；
还有个重要的场景就是分析使用本业务的用户在使用过程中，在哪个节点发生了问题，比如从下载开始，哪些用户下载失败了，没下完就关闭了下载，在失败前按平均速度分组，根据不同速度的用户组做不同运营策略的挽回，根据地域分组，来分析区域性问题，或者分析哪些用户在下载后的安装、登录等过程中报了什么错误，如何定向解决。
新发布了一个版本，用户对某个更改特性的使用情况指标如何，或者游戏内某一数值（比如金币）的产生量除以当前人数的指标，可以通过数据分析来反映用户喜好程度或者是否有问题。
这些是我们内部已经实施的一些例子，不要问我那个公式怎么弄出来的，我也不知道，是那个游戏的业务运维们算出来的，据说准确度很高，但用于别的游戏就不行了，每个游戏都有自己的情况。
在精细化运营中，这类场景几乎是无限的。如果再附加上两个限定条件“秒级实时”和“T级别海量数据”，那大家再重新看一下这些需求，就会发现对业务的运营所起到的作用就不可同日而语了：
有的可以在致命问题刚发生时就被发现，避免大量的用户被伤害；
有的可以让产品一次性设置成最合理的参数，让更少的用户因为不喜欢业务策略而流失。
在精细化运营中，我们希望帮助产品尽可能多的将买来的流量沉淀在业务中，在业务的整个生命周期中，从下载，到快速甚至无感知发布变更、故障恢复，到精准及时的用户引导安抚，到数据化的运营决策辅助，以各种方式多多少少的挽回用户流失。
而从实现方式上，“秒级实时”加“T级别海量数据”的交集，是运维的实现瓶颈。而蓝鲸数据平台，解决了这个问题。
蓝鲸管控平台提用了高效的数据采集通道，运维只需要用熟悉的脚本语言在机器上写个采集逻辑，交给服务器上的agent，数据就会从各地的IDC实时汇集到kafka+storm集群，之后在蓝鲸数据平台提供的在线IDE上用yaml语言写好聚合逻辑，运算好的实时结果流就会输入到结果库。
这时候，就可以在蓝鲸集成平台中的PaaS平台上开发一个APP，来实时的展示这些数据，当然如果运维连开发APP的成本也不想付出，那也可以在市场中找到一个APP，配置出一套实时仪表盘（SaaS）。
这个图是我刚才截的，整个图是动态的，上边的曲线一秒左移一次，右下角的+10是不断从下方升起并消失的，可能这也算是微信分享的一个缺陷，一来对于实时曲线截图变成静态的，二来出于数据敏感的原因，也不能截太多数据类线上APP的图片。
这个工具中，如果鼠标点击黄色部分，就会将未完成下载就关闭下载器的玩家按关闭前的下载速度分组，并支持提取QQ号码包，这样就可以对高带宽玩家用推送礼包之类的营销活动拉回用户，对于低速玩家，可以给他们推荐加速方案等。
（本文源自高效运维，经作者同意做了合并整理）
作者介绍：党受辉（咖啡党）
腾讯游戏蓝鲸产品中心总监
目前负责腾讯游戏运维支撑体系（蓝鲸）的建设和运营，致力于打造行业级的基础运维无人值守解决方案，以及数据化增值运维解决方案，推动devops生态。
十余年来专注行业信息化及运维领域，做过多年运维团队管理，期间为不同类型的游戏及千万PCU级游戏平台设计过自动化运营系统。
查看原文
网友评论