火端文库
当前位置:首页 » 蓝鲸体系 » 正文

蓝鲸体系

2015-12-14 14:30:37

腾讯蓝鲸体系架构及设计思想
腾讯蓝鲸体系架构及设计思想蓝鲸体系

作者讲解党受辉(咖啡党)腾讯游戏 蓝鲸产品中心总监目前担负腾讯游戏运维支撑系统 (蓝鲸) 的建造和运营, 努力于打造行业级的基础运维无人值守处置方案, 以及数据化增值运维处置方案,推进 devops 生态。

十余年来专注行业信息化及运维范围,做过多年运维团队管理,时期为不同类型的游戏及千万 PCU 级游戏 平台设计过自动化运营系统。

引子最近,在运维圈里看到触控科技的萧总提出的一个概念“运维 2.0”,学习之后,感受颇多,和几年前腾 讯游戏的运用运维团队发起的“运维转型”战略项目神似,那个项目在数年间几乎重塑了“运用运维”在 腾讯游戏的定义,而在进程中带动并承载这次转型的详细完成,叫蓝鲸。

蓝鲸是腾讯游戏运用运维(ARE)技术生态系统的代号,由正在逐渐产品化的六大运维平台和众多运用运维 (含 devops)、运营规划等人员构成。

在运用运维这一范围,蓝鲸以“共同”的方式承载着半个腾讯,也承载着国际游戏行业半数份额。

出自运用运维团队的蓝鲸系统,最终来的设计理念,是希冀能武装运维,使其能够提供更高维度的效劳。

例 如,为产品、谋划、运营等岗位提供:  自助化的运营工具; 数据化决策支援; 直截了当的用户体验改善等。

本文尝试以半叙事的方式, 概述蓝鲸浮现的背景, 设计理念, 和落中央式, 希冀业界宽阔运用运维同行们, 在我们的停顿历程中能找到自己现时期的影子,共鸣共勉,分歧努力,兴盛运用运维生态。

1. 蓝鲸的背景:运维转型

十年前,我们的业务运维忙于这些任务:效劳器、网络、OS、DB、发布、变卦、监控、缺点处置、运营环境信息维护提取等等。

这些任务大多是主动的,或许说是“需求驱动型的“,运维大少数时辰在主动的为产品、谋划、运营、开 发等协作岗位的同窗提供操作效劳,而且格外多是反复性的操作效劳。

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

三年前,也一定是 2012 年,依照那个先行试点团队的成效评价,整个腾讯游戏的十余个运维团队(目前 200+ 运维)走上了困难的转型之路,作为落地承载方案的蓝鲸系统同时末尾构建。

当年促使我们决计转型的缘由,能够归结为以下三点。

缘由 1:业务红海化行业竞争格外猛烈,精致化运营越来越严重。

产品和运营人员忙于更贴近用户体验的业务设计和运营设计, 开垦团队忙于更快更牢靠的完成,运维团队则希冀为用户提供更高的可用性,不管是刮风下雨,依然发布 变卦,都能将业务可用性坚持在有限接近 7*24(此处省略几万字)。

在此之上, 还需求能为产品谋划运营等其它岗位提供各类运营工具以提高 “产品运营” 的成效 (时常以来, 腾讯运维的职能在外部被定义为“技术运营”,全部运维们所在的职级通道就叫做“技术运营通道”), 甚至能为运营决策提供准确的数据依照。

缘由 2:“传统运维”生活空间塌缩几年前我们预见到“传统运维”的职能空间会被逐渐紧缩:比如一些新技术对运维的传统任务会有一些冲击 (此处省略几万字) , 这一点到改日曾经不用再展开说了, 近一年运维范围各类危机言论末尾满天飞了。

再比如开垦团队出于追求更高可用性等缘由,在运维不给力的状况下会直截了当涉足精致化运营范围。

尽管我们感觉运维一直是不可或缺的,但也不得不供认传统运维的需求量会有一定的增加,岗位的萎缩对 全部从业者都不是好旧事,出于自救我们也要尝试转型。

缘由 3:我们太累了那些年,腾讯游戏疯狂的增长,假设不转型,别提啥辅佐决策如此的初级玩意儿,一定是发布变卦、缺点 处置之类的运维基础任务都会把我们拖死。

因此,运维转型的久远目的能够归结为:1. 将基础运维效劳(发布变卦、监控处置、数值调整、数据提取等)尽能够做到运维无人值守,运维提供解 决方案(工具); 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 作 为自动化原子,让运维更轻松的布置更多节点,提升单个节点功用密度,晋级拓展更多的流程,直到把流 程晋级到运维无人值守,晋级到对产品、谋划等岗位的闭环效劳为止。

经过三年的停顿,蓝鲸系统构建了六个平台,其中后四个基本上直截了当或直截了当提供原子效劳供运维集成的功用 性平台: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 的高弹性(如今还不大靠谱)及业务架构的高可 用(假定他们做失掉)轻松交换的话,那在第二个时期就要付出一些本钞票了,终究是硬性添加了开垦团队 的建造及维护任务量。

而在第三个时期,对业务开垦来说就太犯难了,也一定是说运用运维们借助蓝鲸数据平台能够大批停止业务 开垦团队从本钞票上难以同意的任务——运营环境大数据分析,来停止产品运营的决策辅佐。

因此,业界往后在担忧的运维危机,我们在几年前也担忧过,而如今无所谓了。

“数据运维”在我们外部还属于优化推进时期,蓝鲸数据平台也在逐渐成熟中,我们希冀协助产品谋划人 员,在红海竞争中经过我们对精致化运营的一些努力,为业务提升一点点竞争力。

我们希冀为产品谋划人员提供尽能够周全的辅佐运营效劳,或许当他们某一天分开腾讯后,会觉得各种不 顺应。

记得我们在杭州办蓝鲸沙龙那次,中间茶歇的时辰,有个哥们跟我们说了一句话“我如今觉得腾讯游戏成 功的面前有格外多我们不了解的要素”。

尽管我们格外明晰,在腾讯游戏停顿的进程中我们所起到的必然不是决策性要素,能够只是其中格外小格外小的 一部分,但他的这句话里所透显露来的那一点点意义,照旧给了我们格外大的鼓励。

在腾讯的格外多部门,即 便是边角的支撑团队,也在为其所支撑的产品线的市场竞争力和口碑而倾尽全力。

3. 蓝鲸效劳蓝鲸的效劳能够分红两类:PaaS 和 SaaS。

上边提到的全部效劳,基本上 PaaS:  比如蓝鲸集成平台,不管门槛多低,运用运维都需求自己去开垦工具 APP; 比如蓝鲸作业平台,运用运维需求自己上去写脚本; 再比如蓝鲸数据平台,运维需求自己用脚本写采集法规、用 yaml 写计算法规,假设需求结果的实时展现, 还得在蓝鲸集成平台做展现 APP。

对运用运维来说,PaaS 效劳是万能的,几乎没有场景限制,只假设原子能掩盖的流程,都能做得出来,非 常灵敏,还能最大化发扬运用运维的技术,表现其价值:

  比如能够针对某一种发布做个蓝鲸 APP, 能够针对某个告警的处置法规做个“缺点自动恢复”工具 APP, 针对某个场景,开垦一个实时刷新的数据视图 APP„蓝鲸大肆停顿 PaaS 效劳,也印证了我们的理念:即依赖运维,武装运维,使其能提供更高维度的效劳,而 不是取代运维,同时迎合了 运营、开垦、测试等岗位人员的需求。

用 PaaS 构建的效劳工具,适配场景几乎有限制,高度的定制化使得体验最好,但有“反复建造”以及关于 基础运维效劳“难以一致化管理”的成绩。

因此在格外多高频场景,蓝鲸也结合运用运维团队,提供了许多 SaaS。

比如针对发布变卦场景,结合蓝鲸集成平台上大批的发布变卦类工具,蓝鲸推出了“尺度运维”APP,使得 曾经渐突变成大少数运用运维担负的大批的名堂单一的“操作类 APP”得以下架。

如此使得我们逐渐的在运用层构建起了尺度化场景组件, 再赞同大伙儿从其他的 APP 调用 “尺度运维” 接口, 也一定是说,停止更高层面的“场景布置”。

或许直截了当运用“尺度运维”提供的 APP Maker 功用针对某一操作流程,拖拽生成相似于快捷方式的“轻应 用”,以完成轻量操作类 APP 的免开垦拖拽生成。

如此,也使得蓝鲸生态在运维基础效劳层面临业务来说愈加安全牢靠,面临运维人员的活动,抗风险才干 更强。

再比如,在告警处置及缺点恢复场景,为了幸免运维制造大批针对不同业务的“缺点自动恢复”类工具, 蓝鲸团队提供了通用的“缺点自愈”效劳:1. 将基础告警及自定义告警的发作封装成了通用效劳; 2. 将告警处置中常用的一些节点封装成组件再集成为套餐供运维经过图形化界面选用。

固然为了适配特性化的场景,也提供了 PaaS 编辑器,赞同运维用 python 言语自定义复杂的缺点分析树。

4. 扫尾

运维是一个被压制了太久的岗位。

内行业的一些交流中,格外多公司的运维说他们尽管掌控着运营环境,却 在慢慢地被排斥出业务的要紧流程中,感到对未来格外迷茫。

我只能说,没有充分应用运维的价值,这是他们整个公司的损失,每个业务基本上有专职运维的,运维了解 运营环境,了解业务架构,了解产品本身,有着丰厚的想象力。

而蓝鲸,一定是要让运维的想象力暴收回来,并施加到业务上。

蓝鲸,是腾讯游戏的运维们从实战中“总结、提炼、设想、设计、建造”出来的系统,其设计初衷是武装 运维,使其能提供更高维度的效劳,而不是取代运维,同时迎合了运营、开垦、测试等岗位人员的需求。

在所谓的“运维危机”时期,我们更懂得,并成功验证了运维对业务的价值。

蓝鲸曾支撑腾讯游戏走过了不同层级的尺度化、自动化时期,往后正在和运用运维一齐探求效劳化。

而我 们自己也在慢慢的将各平台逐渐产品化,以支援腾讯的投资公司以及自己部署在私有云上的业务和我们的 协作同伴。

希冀在经过更多的磨合及历练之后,有一天我们能够和大伙儿一齐走的更远。

一个周末写下这些,关于在高效运维群的分享做背景和概要讲解应该足够了,其他更详细的内容和案例, 我们本周四 (16 号) 群里见, 固接着续我们还会在各地组织蓝鲸沙龙, 和业界同行分歧探索运用运维 (ARE) 的停顿方向。