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

腾讯蓝鲸运维体系架构设计引子蓝鲸是腾讯游戏应用运维（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命令，可以搞定所有“发布变更故障处理等”运维