云时代的腾讯运维团队转型：ECUG 10周年大会演讲

编者按：运维职能越来越多被云平台取代，运维如何转型 DevOps，以便继续为业务提供快速、低成本的支撑工具、运营系统？来自腾讯蓝鲸的产品总监党受辉在 ECUG 十周年大会上分享了腾讯运维团队的实际案例，本文由 ECUG 授权高可用架构发表。

讲师：党受辉（腾讯蓝鲸产品中心总监）

一、云时代的背后

身边的运维们

在腾讯，蓝鲸支撑着腾讯内所有自研、代理的游戏运维，目前大概有 300 多个（游戏）。腾讯一半的收入都来自于游戏，这个体系支撑了半个游戏行业，也支撑了半个腾讯。这里面有个最大的问题，即各游戏业务的架构是不一致的。

互联网公司（除了腾讯）所有事业群、事业部门业务都是自己开发，只要有自己的开发，就有自己的开发框架，沿着开发框架做一个规范，沿着规范再做一套运维。但是在腾讯不可能，腾讯游戏的业务大部分都是代理的，全球上百家厂商开发好代码后给到腾讯，腾讯游戏的运维人员无法左右这款游戏的架构、语言、操作系统，只能做差异化的运维，没有标准化的运维。

传统运维的工作

发布、变更、故障处理。

传统运维的危机

图 1

这三项工作（图 1 ）在云时代会有危机，云平台出现后，大多数公司其实不需要那么多运维了，传统运维的岗位，比如 IDC 运维不需要自建那么大的机房，有一部分可以租用。即便是私有云，目前也出现定制云，云厂商按照网络架构定制好基础设施，再交付给客户或者帮客户代维。各个公司中 IDC 运维、 DBA 等岗位都会萎缩，公司类似的岗位会减少。所以，传统运维工作中有些就没有了。

运维的对象

在云时代，运维的对象有三个：第一个是 VM 。早期是物理机，后来出现了 VM ，一个物理机会虚出十几个，以前手工做得很爽，变成一百台物理机就很难做完。第二个是容器的出现，build-ship-run 的发布形式完全突破了传统的运维发布模式，运维还要同时兼顾以前的物理机、VM的操作管理，这对运维的技能又提出更大的挑战。第三个是应用，业务竞争比较激烈，运维以前的身份是：这个业务可以出问题，只要不是运维造成的，这个责任就是产品、策划、开发的。以前只需要负责这个业务的发布、变更、故障处理等基础运维工作，现在需要因为运维的存在而让业务指标往上走，必须把精力和注意力从设备上转移到应用上。

传统运维系统

以前做一个发布系统、监控系统等，步骤是从底层往上做，最后做界面。后来发现，这个运维系统横向打通会出现问题。对于传统企业来说并不存在这个问题，他们由 IBM 、CA 等厂商提供平台，基本上不管运维。但对于互联网公司来说就会有问题，机器上可能有好几个 Agent ，例如做监控的团队做一个监控的 Agent ，做大数据的会做一个大数据采集的 Agent，做发布的做一个发布的 Agent 等等。

运维服务的转型

转型的主要有三个层次：运营保障、运营工具、运维决策。以前运维在发布、变更、故障处理做完之后就没有责任了，在腾讯内部不可以这样。因为前面提到的诸多原因，腾讯必须要做输出和服务。例如，在做到运维保障的同时，需要做运维工具。DevOps 本质上是开发和运维的结合，要么开发懂运维，开发把运维的工具做出来，这个平台最终要落成一个平台系统让别人用，才能持续地沿用这个理论，否则只停留在概念理论。

在腾讯的理念中，运维如果能够给开发做工具，能够快速把开发和测试的岗位串联在一起，每天实现一万次发布，那就是 DevOps 。但是太窄了，要给产品、策划、运营、老板所有岗位做工具，这是腾讯的思路。在运营工具方面，运维需要转型，能够给公司各个岗位构建运维工具。同时，运维需要做一些辅助决策，通过大数据技术帮助产品如何拉升业务指标等。

二、运维的转型

自动化

从手工操作到脚本自动化、Web 自动化，把一部分自动化不单独在 CRT 上点，还要分担到页面上，这部分由外包做，把正聘运维岗位从操作中撤掉。

图 2

调度自动化，很多工作需要跨系统操作，如果公司中有很多发布系统、变更系统等系统，运维做发布时，可能需要在不同的系统之间来回切换，这很浪费时间，如果要让一个发布无人值守，就必须要打穿各个系统。运维的操作流程要么是链状的，要么是树状的（图 2 ）。

自动化的两级调度

图 3

原来是 tar、文件分发、修改配置文件、启进程，后来发现不对，这个操作链很长，运维只覆盖了很短的部分，怎么样把它串起来？通过调度自动化，运维就是要把自己的岗位提升，不能只操作这种配置服务或者方案服务。

蓝鲸的前三个平台

配置平台

作业平台

作业平台，运维的操作有一个问题，一旦操作对象变多了，没有工具便来不及操作。所以需要有一套东西能够同时操作 20 万以上的设备，而且效率必须比操作原来的 10 台还要快，因此腾讯做了这个管控系统（图 4 ）。

图 4

这个系统的好处是运维可以把脚本定制到里面，由它代运维执行，运维可以忽略操作数量。腾讯在行业里办的运维挑战赛，每个周期都会弄几万台云服务器给几个队伍，每个队一开始想 1 万台，后来改成 5 千台、3 千台。第一次比赛，例如盛大、携程、去哪儿等都参加过，腾讯用这个平台做现场验证，例如跑 1 万台服务器，2、3 秒必须跑完。

这两个东西都需要对 IaaS 有操作，为了使架构合理，单独开发一套管控平台来对接。网络模式有的只用自己的内网。第二种是公有云，买了五家公有云，不可能所有公有云的服务器都开公网 IP，管控的时候可能开一个，只有一两台机器有公网 IP ，通过一个 Agent 进行管理。如果是全球管控，例如管理全球 11 个国家的业务，需要专线和操作路径能够指定。有三种不同的连接模式，包括开发不同的管道、传文件用一套管道、发命令用一套管道、采集大数据用一套大管道。对 1 万机器做操作的话，必须 5 秒内全部完成，这些是硬指标。

图 5

解决了运维的操作部分，比如传文件、发指令，这一块能够到 Web 上执行，下一步就是要把不同的 Web 连起来，不同的应用系统打通。这个时候要用到 20 年前的一种技术 SOA（图 5 ），SOA 把各种各样孤立的原子系统，核心服务开 API 出来再对接，在总线层做服务的发现、注册、路由、协议转换、监控等等，再往上开发运维系统。这个时候再开发一个发布系统，所有的原子部分下面都有了，只需要做原子重组。这时能够把运维成本降到 50% 。

上层系统 SaaS 化

图 6

让运维不用经过全职培训就能够开发运营系统，第一种是把运维能力往上提，第二种是把开发运维系统的门槛往下降，两个同时做就可以完成。降到 50% 以后怎么继续降？运维人员开发一个运维系统的时候用的是 PaaS 技术，PaaS 能够全托管运维环境，要实现各种 API，在开发内部系统的时候，代码不会到处迁移，所以构建一套私有化即可。以前开发一个应用工具可能是先有需求，买一台机器，布署环境，各种包装好，写代码，代码管理，监控，日志，不断地改 Bug 。在云时代下，用户只要进入开发者中心编写工具本身的很少一部分核心逻辑代码（图 6 ），代码上传到 PaaS，PaaS 自动帮用户构建、分配环境、运行，运营环境全托管。

图 7

运营系统已通过 SOA 拆解（图 7 ），没有必要为了单个运营系统而再做服务化拆解成多个模块，那是平台需要做的事情。在上面构建的运营系统，足够小到用一个项目就可以装下。一个容器一个系统，容器之间不需要交互，可以做得更轻一些。

图 8

实际上，只剩下编写核心逻辑这点工作量，核心成本可以降低。这个时候如果有了 PaaS，上面的运营系统就可以称之为 SaaS 了，怎么样把 SaaS 的成本再降到 10% 以下？运维有一个问题，大多数运维没有经过前端培训，后台也不够强。这时需要再继续拆解（图 8 ），前端最早把各种页面元素（导航、按钮）全弄一起，分类放在那里，运维要用的时候直接用就可以了。后来发现不行，运维调一个按钮可能会花费一个上午，便改为调七八十种套餐，运维开发人员使用习惯后又不想和别人页面类似，又进一步提出前端是否能够做得更好，所以又继续开发出了我们的 Magicbox，让运维能够直接拖拽生成他想要的页面。腾讯内部已经把运营系统的 SaaS 开发成本降低到 10% 以下，一个普通的本科毕业生经过三周的培训，如果还开发不了运营系统就会被开除，近三年只有一个人没有达到标准。

腾讯内部的运维三百多，把其中一百个培养成 DevOps ，能做运营系统运维即可。构建价值、构建成本是没有价值的，使用才有价值，其他岗位的人不会在乎这个系统怎么来的，只会关注这个系统是否好用。从 2013 年开始到现在培养了 200 多个运维，100 多人都可以开发。在腾讯内部的蓝鲸，现在有 500 多个运营系统，它的用户群覆盖了内部的秘书、开发、老板、测试、运营等等岗位。

如果内部的蓝鲸挂了，几乎等同于办公区停电，因为大家各种各样的工具都在上面。上面可以按照小时为单位开发一个运维工具或者系统，能够解决企业工具文化的问题。现在有很多工作室的开发也在上面做，在开发团队中运营系统开发是最没有价值的，他们一般会找团队里刚毕业的学生去做。开发的责任是把产品的设计开发出来，原样开发出来，所以开发不愿意做，他们非常希望有运维这样的岗位帮他们做好。2013 年，一份产品在上线时会做两份方案，一份给开发，一份给运维，这样运维上升到第二层面帮助企业落地工具文化。

落地企业工具文化

体现工具文化的不是几个大型运营系统，而是无处不在的小工具。工具有维护成本，哪怕是一个秘书，每个月申请物资，要所有的员工填写，申请 U 盘需要发邮件，两天时间就没有了。这个时候提出一个需求，帮助做出一个 SaaS 小工具，所有的事情都在上面填，自动整理成 Excel 可以导出来，2 分钟就做完了。

工具只有在自己用的时候前途最大，所以把工具的门槛降低，让所有人都能做，腾讯内部有很多业务开发，因为避免做运营系统耽误时间，也在蓝鲸上做。目前蓝鲸上开发的运营系统有 560 多个。

运维参与运营

DevOps 在出现的早期是为了有一种机制能够把开发、运维、测试串一起。互联网中一个版本顺利发布是企业最低的需求，这个东西为什么那么火？按照我们的理解，有人认为开发者要有运维意识，在开发版本的同时顺手就把运维工具做出来，运维只需要点击使用即可。如果一个公司真走到这个份上来，由开发来做运维，当这个项目完成之后，运维开始离职。

现在有很多创业公司或者国外著名的一些互联网公司的人出来讲 DevOps ，都是因为他们的公司由开发做运维工具，运维没有事做，这种做法把运维弄走了，而且对公司来讲很恐怖，一旦运维岗位没有提起来，后面没有一个岗位能够支撑公司的精细化运营。什么叫精益化运营？需要面向用户，用户在哪些环境体验不好、如何丢失的，这些东西需要什么岗位做呢？技术岗、懂运维环境、掌控运维环境的人，因为需要拿运维数据环境（服务器数据、网络数据、用户每一个阶段体验的日志数据）、这个人需要有充足的时间、懂得如何使用业务（要知道映射到哪个模块上、是哪个模块的问题、不需要知道具体懂代码怎么写，但必须要知道用户的使用流程卡在哪儿等等），这样才能做精细化运营。

那么，除了运维之后并没有适合的岗位能做这个工作。开发只顾自己的模块，因为开发的工作没完成，产品两句话，开发两个礼拜。开发最重要的工作永远是把版本做出来，不是做旁枝末节。开发比运维贵，产品对运营环境完全不知道，数据哪儿来的都不知道。所以，一旦大公司的运维萎缩了是很恐怖的情况。运维不能明显地拉升指标，但是它可以让你的业务一瞬间消失掉。

腾讯眼里的 DevOps

图 9

腾讯是由运维开始，让运维团队做 DevOps 项目的同时，把运维能力稍微提一下，让运维可以覆盖 DevOps 所有平台。例如要做一个发布系统（图 9 ），做一个集成系统，持续集成、持续交付、持续部署这些系统由运维来做，让运维来支持开发。开发只需要写一份逻辑，怎么部署其实开发不在乎，都让运维完成。在我们眼里，DevOps 是让运维转型成为一个技术团队，给开发做工具、给测试做工具、给所有需要的人做工具。

当开发做完了持续集成工具之后，因为他的工具已经自动化了，如果开发跑去给测试做工具、给秘书做工具，他就不是业务开发了，他就属于一个公司里面支撑开发了。按照我们的理解，做平台这部分应该和运维合在一起，叫做技术运维团队。

运维能做毛的运营？

图 10

游戏中有互联网所有的先进架构（图 10 ），同一个游戏给两个公司开发，可能玩法一模一样，使用的语言、平台、框架完全不同，这取决于这个公司的开发人员擅长什么技术，取决于这个公司的技术创始人用什么技术。公司的技术创始人会用自己最擅长的技术向下推，如果使用一个他完全不懂的技术，这个位置以后不好坐。

当业务上线之后需要有人分析，从流量开始一直到用户引入、用户整个过程体验，有哪些问题？用户是怎么怕的？不单是这个渠道的转化率到达 10% 就结束了，一百万用户最后发现付费的只有 10% ，渠道的转化率是 10% ，不清楚剩下的 90% 去哪儿了。但是在腾讯的运维需要把整个链条梳理完，最早是引流，官网上别人不知道从哪儿点击的广告链到官网下载游戏、安装、注册、创建角色、进入副本、玩游戏。每一个点都要梳理出有哪些细节，用户是怎么丢的。

运维为什么有时间做这些工作？因为运维的发布、变更、故障处理在上一层已经全部自动化，架构不变就不需要改了。一旦业务变了，以前发布工具不方便使用了，脚本需要改、配置需要改、SaaS 需要改，这个时候运维就再出来，把它改好再交付。所以运维只做方案，但是不做操作服务，因为运维太贵了。

例如下载服务里面有一个加速，最早买流量的时候发现有很多用户点了下载器，在下客户端的过程中流失了，因为客户端过大，5G、10G、20G，家里的网速没有那么快，怎么办？在加载器上报两个数据，一个是是否下载完成，一个是如果没有下载，用户的下载速度是多少。没有下载完成之后，运维给用户安全速度分组，这部分的玩家速度超过 800K ，理论上一定能够下载，客户端很大，如果一个月没有玩的话需要更新半个小时，用户就不玩了。用户家里的速度足够快，推个包送他一些道具，用户会接着下载。如果家里网速太慢，下载不完，以前的笨办法是给用户寄一个光盘，现在简单，直接调电信的 API 把用户的网速改了。

图 11

分析给哪些玩家发礼包、什么时候发这个礼包，最后结论是：下载速度大的时候，当下载进度为 5% 、已经下载 10 分钟的玩家，在进度 8%、15%、30% 发送礼包，用户关掉下载界面的概率最低。找 100 万、200 万用户 A/B test ，结果如图 11 所示。这个项目做完之后，玩家下载的成功率提升了 20% ，玩家下载的时长降了 60% 。提速、拆包、减少下载的东西、带宽速度快，下载的时间缩短很多。这个时候，整体的转化率从 10% 提升到 20% ，最后转化出来的 10% 等同于广告费用 5 亿。即运维可以量化自己的项目，到底给公司赚了多少钱。在安装、登录服务等等链条中，只要运维具备大数据使用能力，就可以做这些事情。

赋予运维大数据的使用能力

以前业务量小的时候不用大数据，写一个脚本就行，但在腾讯的体量下这样绝对不行，腾讯每天动不动上百 T ，需要思考大数据怎么实时地采集、汇集、计算、展示。腾讯由数据平台采集，大数据平台做用户营销、用户画像，传统大数据丢 1% 、2% 不影响结果，反正是做趋势分析。但是运维不一样，运维大数据平台首先必须要实时，因为要做决策，到底扩不扩容需要决定，如果数据丢 1% ，决策就会出现错误。实时、海量、污损，数据量是不能丢失的，每天跑 100T ，也不能丢一条。运维大数据平台的构建成本更高，从 2013 年起蓝鲸数据平台，到现在已经三年多了，基本上解决了海量、实时和亏损，这三个指标单独拿出来做一个数据平台很简单，一个月足够，但是把三个条件放在一起就不一样了。

运维写不了 Java 的运算逻辑，把运维转为 DevOps ，也要考虑运维的接受能力。如果只有 10% 的运维能够接受，那这个策略是失败的。让运维学 Python ，Python 既能做运维，也能做 Web 开发，而且 Web 的编程就一个框架。运维有些用过 Yaml ，内部有些运维不会写 Yaml ，就开发一套 SQL 引擎，做出图形化拖拽。这样运维就具备了大数据的能力了。

三、蓝鲸模式

蓝鲸体系的工作模式

图 12

集 SOA 、大数据、云计算等一体的技术运营体系，不单可以做运维，它是一整套体系（图 12 ）。分不同的平台，每一个平台都可以独立使用，当然也可以插在一起使用，插在一起使用效果最好。下面都是原子，中间是集成平台，上面是 SaaS ，这个成本还不到原来的 10% 。

蓝鲸团队在内部不断地开发原子，运维就找还有哪些点没有自动化，把操作的流程梳理，每一个节点是一个点，用线连起来。当发现有这个原子缺失没有东西可以调的时候，蓝鲸就要看是否为公共需求，如果是公共需求就开发出这个东西给他们调用，他们只需要在上面配置需要采什么、多少力度、植入计算机任务、得到结果实施。运维不断地开发上面的 SaaS ，贴近不同岗位的需求构建 SaaS 。

现在《变形金刚 4 》上映之后出现了大力神，组合金刚，每一个机器人可以独立作战，但是在一起更牛，蓝鲸就是这个思路。原子平台，运维不断地开发 SaaS 。

四、开放

为运维行业的繁荣贡献：咨询方案、成熟产品、开源代码

腾讯希望做一点贡献，2015 年出去分享经验，是运维业的领航者。最早企业 IT 、上市公司的总裁出去讲“做企业级的蓝鲸”，早期是给大家提供咨询方案，告诉大家如何做。腾讯投资的公司不满足，要求干脆把它用出来，后来就把腾讯内部的产品功能大量裁减，弄成独立搭建的版本给他们使用。运营系统上的图一定是真实的，很多公司不大接受公有的 PaaS 做财务系统。怎么办呢？后来开发了独立版本。腾讯主要的任务是支撑大半个腾讯、支撑半个游戏主业，后面继续改，把几个部分开放出来，不断升级。

最早的时候是腾讯云，后来是给腾讯投资的公司提供方案，再后来是蓝鲸校园。培养学生，从大一开始扶植一些大学内的社团让他们接触和学习蓝鲸，从中直接招人，直接绕过招聘季的竞争，提前把学生锁定，再进行社区版开放。

开放了公有云版有 1 万多用户使用，但是留存只有 2000 ，后来调研说这个东西做得很好，他们就自己抄了，因为互联网公司不敢用公有云上的东西。开发免费版，尽量做成免维护，独立搭建版本运维自己搭会碰到很多问题，整个蓝鲸运营组整天应付这些问题，蓝鲸的思路是把点和面连接起来。从去年底开放，相信 2017 年能把这个数字做到 1 万家，腾讯以前只搞 2C ，现在也试试 2B 。

把腾讯的技术交给合作伙伴

顶级互联网公司的技术 + 专注于运维服务的厂商 + 能力交付 = 多赢。把腾讯的技术交付给服务商，让服务商去赚钱，这样成就我们的名声。以前传统的交付都是要把软件卖给甲方，收后面的费用，甲乙方会产生矛盾。现在要求服务商把一定的能力交给他们，这样就可以解决问题，以这种模式给传统行业输出东西。

例如中间件巡检、VM 的生成、装机，他们给传统的客户调研，在上面开发 SaaS 。这样能够扶持一批企业挤进软件开发行列，以前软件开发都是 CRM 、ERP ，以前代维都是代维通用的东西，一个企业很难想象把核心业务运维外包给别人，除非是运营商才可以，大多数企业并不能接受。服务商的优势在于有客户，有一对一做服务的耐心，我们有技术，合作点切得比较好。

蓝鲸的理念是低成本的 SaaS 定制，很多软硬企业最大的矛盾在于为了成本低，尽量做通用的东西卖，但是通用的东西用户体验一定差；定制的东西体验好但是贵。蓝鲸解决了低成本定制和完全免维护，PaaS 就不存在运维的成本。

更多深度技术分享，可关注本月七牛组织的架构师实践日－大数据与机器学习的最佳实践，点击阅读原文进行报名。

云时代的腾讯运维团队转型：ECUG 10周年大会演讲相关推荐

圆桌对话：云时代下，企业运维面临的挑战与机遇
简介:四位企业运维大咖展开对话,讨论"云时代下,企业运维面临的挑战与机遇". 编者按:上云,已经成为了企业势不可挡的选择.云计算所拥有的"软件定义一切"的特性, ...
献礼724运维日 | 首届腾讯运维技术开放日讲了啥? (附演讲PPT领取方式)
你以为996就是互联网人的极致吗?有这样一个神秘工种,7×24随时随地待命,全年无休,以至于把7.24过成了他们的专属节日--这就是运维. 作为服务数十亿用户的互联网公司,腾讯运营着亚洲最大的网络.服 ...
传统运维团队转型应该注意哪些问题？
2018年已经接近尾声,回顾这一年,国内企业都在进行数字化转型,大家越来越关注如何提升效率.在这一过程中,颠覆性的IT技术正在加速落地:容器技术.Kubernetes的使用已经越来越普及,云计算和大数 ...
AcrelCloud-1000变电所运维云平台一个智能的、适应时代变化发展的运维管理系统
AcrelCloud-1000变电所运维云平台浙江固特成套设备有限公司的应用安科瑞崔远航 [摘要]:随着电力行业信息化的迅速发展,电力运维涉及的信息系统越来越多,为了保证电力系统运行的安全性与稳 ...
【转】腾讯十年运维老兵：运维团队的五个“杀手锏”
---------------------------------------------------------------------------------------------------- ...
腾讯十年运维老兵：运维团队的五个“杀手锏”
回顾运维十年,如有一次重来的机会,什么才是最重要的?什么才是团队需要优先做的?才能在未来支撑我们更好的前行. 赵建春赵建春,腾讯社交网络运营部助理总经理.技术运营通道会长.专家工程师.04年加入腾讯 ...
大牛书单 | 腾讯运维大咖陪你过724
导读:读书,伴随技术人的一生.技术人通过读书增长见闻.精进技术,提升人生境界.7·24运维日即将到来,我们特别邀请该领域的腾讯技术大咖推荐曾经读过的好书佳作,以飨读者. 推荐人介绍推荐人介绍周纪海 ...
首届腾讯运维技术开放日！对外报名正式启动！
服务不停歇,运维不休息. 运维的工作长达7*24 小时,故而每年的 7月24日被视为运维日,代表着运维全天候的保障系统稳定.维护业务正常运行.时刻准备着一线工作的召唤. 腾讯运维技术开放日是由腾讯云, ...
云原生背景下的运维价值思考与实践
作者:刘天斯,腾讯游戏高级工程师前言随着公司自研上云战略如火如荼地进行,IEG-增值服务部作为较早一批响应的团队,截止目前自研上云已完成1/3的流量切换,日PV超百亿.切云的服务大量采用了云原生的 ...

云时代的腾讯运维团队转型：ECUG 10周年大会演讲

云时代的腾讯运维团队转型：ECUG 10周年大会演讲相关推荐

最新文章

热门文章