9月21日，由腾讯游戏学院举办的第三届腾讯游戏开发者大会（以下简称TGDC）召开。在技术分论坛上，腾讯互动娱乐蓝鲸产品中心总监党受辉作了「研发运营一体化，下一代企业级操作系统」主题演讲。
以下为演讲实录，内容有删减：
在互动娱乐事业群，不论是设计研发游戏的自研工作室，还是代理引进游戏的发行线，统一称为“业务团队”。
跟业务团队相对应还有一个庞大的支撑团队，作为整体来支撑我们数十个业务团队以及他们开发出来的几百款游戏。比如市场线、公共研发运营体系等都属于支撑团队。我来自腾讯互动娱乐事业群，公共研发体系蓝鲸产品中心。
我们团队的职能是设计和构建研发、运维和运营领域的工具平台，我的演讲主题叫“研发运营一体化”。国内很少有公司用这种标题来分享，因为不管在哪个行业，企业内部的运营系统和对外业务，都是需要经历三段生命周期的，而普遍的情况是各个公司的这三段不管从岗位人员、团队还是从技术平台上都是割裂的，无法做到一体化，这也是为什么行业这几年开始推一个叫DevOps的理念，主张研发运维协同，工信部信通院最新的Dvops成熟度模型里面已经把持续运营、CO也纳入了。
我们讲业务的全生命周期就包括了CI、CD、CO全段，作为我们这个团队来讲，实际上十几年来一直致力于把这三段打通。大家都讲DevOps是研发运营打通，我们要做是研发、运维到运营全面打通。不管是从人员的配合上还是从基础架构平台上都要做到一体化，还要进行同步的升级。升级的意思是说要从最基础的三段的自动化，向数据化、AI去迈进。
回顾一下软件的构建的历史，70多年来软件研发的成本一直在降低，最早的编程是通过纸带或纸卡打孔的方式，受众很小。
后来，出现了微型计算机，对软件推动最大的是单机操作系统的出现，编程成本降低了很多。再往后，图形化操作系统出现，编程门槛又被降低了。
所以说，随着时代的变化，每个时代为了解决那个时代的问题都会有对应的技术的出现，而且对应的技术都不会是一个厂家做，很多厂家都会从事这样的东西来实现软件研发模式的飞跃。在我们看来今天大多公司无法实现研发运营一体化和高效协同，是因为目前大家无法突破这种单机操系统带来的瓶颈。
我们如果想突破这种瓶颈必须用下一个时代新的技术。从时间上来讲，每二三十年一代，现在是云时代。云时代的特征是控制点指数级上升。所以我们需要探索在这个时代的操作系统形态。
作为游戏公司来讲，不管你是自研的还是做发行的或者你是混合都做的，所面对的业务类型可能是这样的一个特征，业务大量异构。
作为支撑我们所面对的IaaS有可能也不统一，在国内我们用自己的私有云、腾讯云都比较顺，但在全球分发控制的时候发现我们的云不一定能覆盖这个世界上的每一个角落，所以我们还需要去借助其它云供应商的支持，甚至有的游戏会使用公有云上的一些PaaS服务。
所以在我们的视角看来，我们上面的游戏是非标的或者是异构的，作为我们这个团队来讲就必须能够支撑腾讯数百款腾讯这款异构类的游戏，整个研发、运维、运营的链条。如果是代理游戏的话可能只有CD、CO在我们这儿，如果是自研游戏CI也在我们这。
如果一个公司的游戏超过3款而且不是一个团队做出来的，基本上你都会碰到这样的情况。这种情况下作为一个支撑团队如果你不想靠手工来操作、运营的化，你就提供工具，但大部分公司的工具都是这么提供的:找了一帮人，比方说从游戏工作室抽了一帮人说你们几个人做工具，或者干脆从各个游戏工作室都抽一部分人统一形成一个研发部或者什么运营部这样的机构，然后开发出一个叫DevOps系统，给这些团队的中的工程师群体写完代码之后自动编进去扫描等等一些动作，就会开发下面的场景。
把下面模块的功能都实现之后，基本上你就可以拼出一个DevOps系统，对于研发团队来讲是有工具用了。对应的运维团队可能会开发自己的发布系统，有的公司监控都是独立的，还有另外一波人开发了监控系统，还有一些人开发了数据分析系统。乍一看没什么问题，但是企业里边的研发、运维、运营领域的工具系统可远远不止有4个，40个都不止，有些团队甚至针对不同的游戏在某一个单独场景内都无法做到统一。
比方说有的公司代理发行3个游戏，这3个游戏分别有有三套不同的发布系统，或者有三套不同的监控、故障处理等等系统，你有多少游戏，你的游戏数量乘以场景数量就等于你有了运营系统数量，你们企业的运营环境基本上就是一团乱。
即便你做到这种程度也会有一个大问题，我们的各个系统内部的很多很多的功能都是重复开发的，甚至为了做到这样的一个能力使用的是不同的技术站。比方说容器控制有的用的是k8s，有的用mesos，每一个系统之间都是隔离的，我们有一个比较好的词句去描述这种浪费叫做系统内闭环。
一个团队一般来讲面向一个场景，比如说有几个人做监控的，他们就开发监控系统。监控系统内部所用到的所有的能力点他们团队都要自己完成，都不愿意用别人东西，这样就会在企业内形成各种各样的“烟囱”，这些“烟囱”之间如果需要互连的话需要通过API打通。如果打通的时候没有任何规矩的随便打通就会连成一张网，有点规矩的话可能会连成星型，还能稍微好一点。总之这种浪费是现实存在的，大多数的游戏公司都不在乎，因为有钱。
但是，还有一点是有钱也搞不定的，就是叠加场景。比如说你服务于三个游戏工作室。第一个游戏工作室老板说，我上个礼拜提的需求怎么样了。这哥们想想说上个礼拜的需求做完了，到这个系统里一看果然被做完了，但是被测试打回了，原因写的很清楚。你看这个游戏是这样的，你的需求是这样的，已经做完了，改改下个礼拜就能发了。老板说非常好，我上个月提的需求呢？想想应该已经发出去了，跑到这里找发布系统，发现北美发完了，南美发完了，下个礼拜发欧洲，把这拿给老板看，你上个月提的需求已经发了半个球了，另外半个地球下个礼拜发。
老板说为什么是在两个系统里面看，能不能统一，谁做呢，如果第一个系统做，那就需要第二个系统把API打开数据给他，在第一个系统里面会多几个页面叫做版本视图。反过来一样，或者单独再开发一个版本管理系统，对接前两个系统，这样也就形成了第五个烟囱。
这在企业内部非常常见，因为企业内部以前做运营系统都是面向场景的，为了这个场景实现这个场景就要把这个场景所需要的核心功能列出来然后开发出来形成一个团队，形成一个“烟囱”自己闭环。
在这种情况下，这种叠加场景就会带来无限的需求，如果你服务于三个工作室。第一个工作室提的需求用了，第二个工作室要推的时候他有自己的想法跟第一个工作室的需求是不一样的，有矛盾就要考虑是花人进去弥合需求差异化用讲理的方式接受统一的一种模式，还是说你要提供更多开发把这个页面变成可配置化来实现两个团队都可以展现不同的效果，还是说你干脆就做多套。你的游戏越多需求就越多，带来的异构就会导致你的开发成本直线上升。
所以说很多内部的系统越做越复杂，越做页面越多，越做后台越轻，头重脚轻结构。越往后需要投入的人越多，有的系统甚至结项了做完了人还撤不出来，感觉支撑体系完全是无底洞。
新的方式应该怎么做，我们从2012年开始做一个尝试，我们用运维场景作为例子，把运维所用到的工作场景列出来，一个游戏没有多少。版本发布、变更，扩容，故障处理等。
你有100个游戏乘一下就有多少场景，你可以把这种大量的样本进行抽象分析，你发现不同的游戏由于他的架构不一样，所以同一个场景的流程是完全不同的。但是，中间用的节点相似，我们就把这些相似的节点都抽出来，形成这种共性的原子。
针对这种共性的原子我们开发出一个平台，比方说配置管理平台，以及作业平台等。这些原子平台上面是不能做场景的，最大的创新点是场景和平台的分离，以前我们的场景跟平台是一回事，比方说我要做一个监控平台它是面向监控场景的，今年是一个监控平台，明年还是一个监控平台。我要做一个发布平台，面向发布场景今年是一个发布平台，明年还是一个发布平台，它的场景不可能增加。
在这个模式下，平台就变成了一个单一功能的东西，用他们来拼装出我们所需要的场景，比方说《英雄联盟》的发布流程是这样的，《王者荣耀》是那样的，你就拼出不同的运营系统在上面，只不过是用下面的不同能力组成出来的。
这是2012年的结构，大家可能有听说过蓝鲸有一个社区版。是2012-2015年互动娱乐事业群的生产版本，当时控制我们十几万台服务器，差不多一两百个游戏就是用这个架构。
到了2015年蓝鲸升级到了PaaS结构。PaaS实际上就是中台，我们对Paas的定义也参照了Gartner的定义，aPaaS和iPaaS。aPaas就是application PaaS，能够实现应用的研发流水线，iPaaS 是integration PaaS，主要作用是集成。
以前我们已经实现了把各种各样的单点原子能力放在下面做平台，在这个场景里面我们把这个平台里面所有的API都标准化，向上翻译成SDK，你的运维或者说你的研发人员在做工具的时候通过FaaS的方式调用某一原子功能，这样的话，就能够实现我们的运营系统不再是开发出来，而是拼装出来的，以这种方式构建出我们整个运维PaaS体系。
PaaS本身不应该有属性，你下面有哪些部件就可以拼用哪些场景，如果你下面都是研发的部件你应该能拼命出去研发的路线或者各类研发工具。如果都是运维类的，就应该做成运维PaaS。
这种PaaS模式里面最大的特点就是我们内置的一条流水线，它为我们的运维开发使用提供了方便。运维大家知道并不是一个全职开发岗位，没有经过全职开发训练，但是这些人懂业务，懂业务结构，懂旁边团队的工作模式，他们深知这些工具场景应该如何设计，所以说如果我们能想办法把这些运维变成工具开发的话，我们整个团队就会有几百人一夜变成工具建设人员。
从2012年到2015年之间差不多三年，我们的运维团队里的50%以上的人转型成运维开发。运维开发这个词就是我们提出来的。
运维PaaS之后就要考虑如何把这个PaaS升级，升级分两种：
第一种是横向扩展，从CD向前面的CI和后面的CO拓展。
第二种是纵向升级，把整个体系自动化，向数据化和AI去拓展。
烟囱式的升级就带着这样的问题，每个团队的构建成本，或者升级成本是随着你烟囱的数量成直上升的，但是如果再Paas体系的话就没有这个问题，你只需要去构建一个数据平台，如果你还想搞AI的话，比如说你要运维的AIOps，你只需要做出一个建模平台
当这两个原子平台做好了之后，只需要在PaaS里升级好了，基于原来我们已经有的运维PaaS你就可以把这个数据能力补充进去，对于iPaas来讲，就多了一组api，对于上面的aPaaS来讲，就多了一组Sdk，那么你原来的可能是点一下，刷一下的这种静态的监控视图，就会变成一秒一跳的实事的，动态的这种监控视图。你以前的扩容系统可能就会变成数据驱动的自动化扩容系统
这种情况下我们就有了一个从CD向CD+CO的过渡，我们的运维PaaS便成了我们的”运维+运营PaaS。前面还有一个CI，服务的群体主要是我们的游戏开发工程师。那他们需要什么服务，因为游戏公司有D/O分离原则，如果是代理游戏的话由于是开发商和发行商是两个公司，所以天然的有D/O分离。开发商是不能随便进入发行商的运营环境，开发商要各种各样的运营环境信息都必须经过腾讯的运维才拿到，比如说我们代理游戏的开发商你想跟腾讯游戏要查看日志和资源分布详情都需要找腾讯的运维才能拿到，内部的游戏开发工程师也一样，因为D/O分离的原则开发同学不能进入生产环境，所以需要运维来提供。
前三个需求用之前的运维PaaS能力就可以轻易组装出来，第四个需要补充这些原子平台。到这个为止我们基本上就可以说我们已经实现了我们的研发、运维、运营一体化的中台，有效解决了烟囱架构中，不同场景平台内的重复建设问题。
烟囱模式的第二个问题，叠加场景怎么办？因为这种叠加场景一旦你公司你的游戏数量变多了，那么它就是成倍增长的，你有多少研发都不够，这个时候你就要用到Paas的第二个特性。因为我们内部不单单是叠加场景，有很多大腿级的游戏，就是支撑团队完全惹不起的游戏，它会要这种运营门户，我不单单是要一个发布视图，一个版本视图，我要的是你运营体系里边十几个平台的混合视图。这个不同的游戏部分不同的工作室由于人不一样，由于性质不一样，喜好不一样，可能需求完全不同。
这种时候这种混合格式的这种门户，或者说这种运营控制面板的这些运营系统需求，如果你按照烟囱式构建，你是绝对做不出来的，因为你的开发成本和维护成本都是无法承受的。在传统模式下，运营系统越定制，用户越满意，但建设成本就越高。越通用我们建设成本越低，但用户就被强制统一习惯了，他们就不开心。这就是烟囱模式的一个巨大缺陷。
但在PaaS里边完全相反的，我们可以基于原来的技术PaaS在上面构建我们的场景SaaS，基于基础SaaS构建场景SaaS或者叫一级SaaS和二级SaaS，我举个例子，比如说标准运维是我们不同的游戏做发布变更这串接链条的这么一个系统。不管是什么游戏它的发布链条可能都不一样，在这里边都可能串起来。
也就是说你在这个系统里边几乎点任何一个按纽就可以操作任何一个游戏的某一个场景工作，从前到尾一箭式串完。监控系统里边有各种游戏的不同的立体化监控，如果有一个工作室说我看监控系统看的非常开心，我想在旁边加个按纽直接出发一个动作，可不可以，答案是在基础SaaS或者一级SaaS绝对不可以。一级SaaS不会为任何一个工作室，任何一个游戏的个性化的工作做任何的修改，因为它是一个业领域的SaaS就是做监控的，这就是做出发动作的。你如果想要一个混合的东西，那么就在上边再拼一下。
也就是说基于一级SaaS可以拼二级SaaS，二级SaaS做得比较机制的话它就是一个好一二三，一层皮而已。这个特征就跟以前的烟囱式的头重脚轻完全不同，这样架构用得越久你企业内部就户出现一种厚云薄端结果。越往下平台越重代码量越大，更新越少，越往上代码量越小，它的数量越多。也有是说越定制的系统成本反而越低，这就是PaaS最恐怖的地方。
一旦你企业实现的这种结果你就会出现一种建设能力井喷的现象。在内部蓝鲸是我们的运营操作系统，我们几百人的运维团队在2012年到2015年开发了数百个运营系统
甚至在我们内部包括我们的行政，像我们的秘书，HR等等这样的一些岗位，其实都会用到一些不同的SaaS，放我们整个互动娱乐事业区的发文系统，我们的业务的星级评定系统，我们的考核系统，我们的经费管理系统，我们的物资申请系统等等的这些。
在这个时代为了解决基于硬件开发软件效率太低的问题，很多公司都开发了操作系统这样的东西，现在是云时代，在云时代我们面临的问题就是说我们的云资源膨胀爆发，我们可能要面对不同的云管理体系和云主机爆发数量，我们企业内又从无纸化办公进入到各种各样信息化、一体化的运营模式。也就是说，我们企业内部需要大量的运营系统，在这个情况下，我们基于Linux这种研发运营模式是不是已经落后了，在这个时代我相信很多公司都去尝试去研发一种叫做研运PaaS的东西，或者叫研运中台来实现我们的组装式运营系统开发。
这种模式在腾讯落地之后，我们大概从2017年之后把版本输送给到腾讯的一些投资企业。比如说像Riot、SEA乐逗等，之后对全行业开放了社区版和企业版，在国内与嘉为科技等企业合作，为使用蓝鲸的公司做支持服务。
截止到2017年，国内激活蓝鲸社区版的企业超过了一万家，其中有很多不单单是使用平台，还开发了自己的SaaS，我们开始经营社区，组织评奖，这些是历年来获奖的个人及作品。也就是说，研运操作系统或者是下一代操作系统，已经被各个行业广泛接受。
回顾这个历程，在每一个时代，看到那个时代的问题、尝试解决那个时代问题的企业都不止一个。比如说Unix的同时代，还有这些类似产品。
在图形化操作系统的领域里除了你熟知的Mac和Windos外，还有很多厂商也在做，但是这些厂商都从先驱变成了先烈。
我们现在有两个纠结点：
第一，下一代的操作形态到底是不是这种模式，其实我们并没有把握。
第二，虽然我们先走了一步，但是在国际上会不会有更强大的公司把我们变成先烈，这个也不好说。
所以说我们只能去精心打造每一个版本，持续巩固我们对于研发运营体系的理解，这个是蓝鲸目前的一个架构图。
