研发运营一体化，下一代企业级操作系统

以下为演讲实录：

在腾讯互动娱乐事业群，不论是设计研发游戏的自研工作室，还是代理引进游戏的发行线，统称为“业务团队”。跟“业务团队”相对应的还有一支庞大的支持团队，支撑我们数十个业务团队的人员以及他们的数百款游戏，例如市场体系和公共研发运营体系等。我来自IEG的公共研发运营体系（CROS）下的蓝鲸产品中心。我们团队的职能是设计构建游戏“研发、运维、运营领域”的工具平台，并经营内部的工具文化生态。

我演讲的主题叫“研发运营一体化”。国内很少有企业会用这种标题来分享，因为不管是在哪个行业，企业内部的软件研发、智能运维、大数据运营三个环节不论是从岗位人员、团队还是从技术平台上来说都是割裂开的。

不论是企业内部员工使用的“内部运营系统”还是企业的“对外业务”的每一个版本，其生命周期都包至少括三段：持续集成（CI）、持续部署（CD）和持续运营（CO），在各企业中，负责这三段工作的往往是独立团队，有的保持手工操作，有的开发或采购了相应的工具系统，而由于组织架构的隔离及人性等因素，导致割裂开的三段之间难以高效协同，各自工具化的过程中又会出现很多重复造轮子的情况，致使IT系统烟囱林立。近些年，意识到问题的各大企业为了提升内部运营效率，都在梦想着研发运维一体化（DevOps）、运维运营一体化，甚至是研发运维运营一体化等概念。

被炒作的概念往往想法都是好的，但落地过程往往各有各的坎坷，每每谈及一个新概念，其落地往往需要三个要素：上层的支持（方向）、各级团队的配合（人）以及工具平台（工具）。而每次说到工具平台，第一想到的就是组建开发团队，或者整合开发团队，用传统方式一步一步的按场景化设计构建，但面对研发运营一体化这类大概念时，不论是从建设成本还是从组织成本来说，这都是一条死路，需要用跨代的技术体系和标准。

70多年来，编程的门槛一直在降低，最早的编程要通过打孔纸带或纸卡，受众很小，但至少解决了“计算”的瓶颈；后来出现了微型计算机和UNIX操作系统，编程成本降低，解决了写软件时和硬件层的分离；再往后，有了Windows、mac等图形化操作系统，编程的门槛又被降低，普及了框架化编程，分离了工程师和码农这两个群体。平均每隔二三十年，“编程”这一工种的生产力就会出现一次飞跃，如今，距离上一次变革又过去了二十多年，我们步入了云时代，面对云时代的各种问题，软件编程的又一次变革在已经发生了，我们在2012年验证并普及了基于PaaS技术（现在有人叫中台）的“组装式开发”。

我们先看一下在云时代，企业IT面临的问题。

由于互联网+，导致企业对外业务类“应用”增多
由于业务应用增多，导致内部运营管理系统增多，两者都开始从单体架构向微服务过渡
业务应用和运营管理系统极有可能是来自外部不同厂商或者内部不同团队，使用的技术架构不同，运维及管理方式不同
逐步出现“大业务集”的概念，抽象共性下沉，俗称业务中台，例如金融企业做金融中台，物流的做物流中台等
随着企业拓展业务线甚至并购，导致业务中台也不能统一，且各有各的工具系统，相互割裂
企业开始构建自己的私有云，并且购买不同云服务商的公有云，构成混合云，各云的操作方式及工具系统相互割裂，无法统一。
不论是IaaS中的操作系统数量，还是IaaS之上运行的应用数量，都趋于海量，人肉无法管理

针对这些背景，如果延续之前场景式的构建方式去落地研发运营一体化，会带来烟囱林立的后果，做得越多越久就走得越慢，治理成本甚至会高于构建成本，而且难以实现后续的模式升级，例如从自动化到数据化到智能化，因此是一条死路。

按场景切分团队，面向场景堆烟囱系统虽然边界清晰，团队闭环，见效快，但有三个严重的问题

1，各场景内闭环的系统中，相似的功能难以复用，各团队自造轮子

2，叠加场景在面对异构业务时，变成无限定制，团队陷入永远做不完的需求中

3，维护管理成本高

这里只画了四个烟囱系统来举例，但在实际情况中，企业中不同业务线，各个生命周期内的管理系统数量四十个都不止。我们在2008年至2012年之间就是以这种烟囱方式建设各种运营管理系统，但深感成本无法接受。而且在可预见的未来，维护管理模式升级等成本更让我们无法估算，因此在2012年转而开始验证基于PaaS的新模式，计划是先将CD领域内的所有运营系统PaaS化（后来叫中台化），之后再向CO和CI延展。

首先分析CD领域内数千条业务流程（工作场景），以大量的数据样本分析公共节点。

从场景中抽象出相对独立的原子能力，逐个开发成原子能力平台。

将原子平台下沉，构建服务总线层，在之上提供场景开发框架、研发流水线、托管服务等，用以轻量组装“工作场景”，实现组装式开发。从2012年至2015年使用的就是下图的架构，当时覆盖200余款游戏业务，200多运维人员，数千业务人员以及近十万台服务器，业务营收每年数百亿。这套架构已经对外免费开放部分开源，目前国内企业激活量在4万家左右，这套架构对外命名为“蓝鲸社区版”。

蓝鲸的第二代PaaS版本是2015年上线的，aPaaS中包含了完整的用于构建SaaS的DevOps流水线，基于容器的运行环境托管，以及SaaS的运营管理（CI-CD-CO一体化）。

iPaaS中包含了对已有原子平台的自动化管理，外部第三方系统的自动化接入，统一对上提供标准协议的SaaS组装能力等。

2015版完全实现了基于PaaS的组装式研发运营模式，基于IaaS的研运模式成为了历史。在基于PaaS模式构建运营系统的过程中，IaaS层对于软件开发者来说完全不可见，对他们来说，世上不再有linux这个概念。

这种改变在几十年前曾经出现过，当年由于写软件的时候直接控制不同厂家各不相同的硬件成本太高，因此在硬件和软件之间构建了操作系统这样一层，例如编写软件需要从硬件中读写数据的时候，并不是在QQ等软件的代码中直接去控制磁盘转速和磁头转角进行数据读写，而是用copy、delete等函数，通过操作系统上一个叫做“文件”的概念来实现，也就是说，作为中间层的操作系统层对下屏蔽了硬件层，对上为QQ之类的应用软件提供了开发环境、托管环境、运营环境、功能函数等服务，这种研发模式成就了半个多世纪的单机操作系统的时代。

今天，软件工程师们都把单机操作系统当做基础设施使用，写应用软件之前几乎没有工程师会冲动到看不起linux、windows而非要自己重写一套属于自己的操作系统。在未来，软件工程师们也会适应PaaS这种新一代的基础设施，而不会冲动到每个人都想自己写一套，毕竟业务软件工程师的价值主要在于快速实现“软件应用”本身的功能，例如游戏的版本，银行交易系统的版本，电力营销系统的版本等等。

十年前我们开始步入云时代，这个时代的主要问题前边提到了七点，要解决这些问题，我们需要比基于IaaS更先进的研发运营模式，基于PaaS。

PaaS本身不应该有属性，iPaaS中有哪些原子能力，SaaS层就可以拼出哪些场景。如果iPaaS中都是研发类部件，那上边就可以拼装出各种研发类的工具和运营系统（SaaS）；如果iPaaS中都是运维类的原子能力，那这就是一套运维PaaS，上边可以拼装出各种运维场景类的SaaS。

前边提到，在我们的认知里，落地一件事情需要三个要素：上层的支持（方向正确）、各级团队的配合（人）以及工具平台（工具），我们2012年的规划是“验证基于PaaS的新模式，先将CD（运维）领域内的所有运营系统PaaS化，之后再向CO和CI延展。”

在2012年，我们有了第一代的蓝鲸PaaS，同一时期，两百多人的运维团队开始学习基于PaaS的运营系统研发运营模式，让曾经不是全职研发人员的运维岗，也可以基于PaaS组装SaaS，使运维团队的工具建设能力井喷，到2015年就已经完成了数百款异构业务的一体化运维自动化，传统运维人员向运维开发岗位转型的比例高达60%，先后组装了上千个运维类SaaS应用，都托管在PaaS中而没有维护成本。

2015年之后我们开始实施第二步规划，将PaaS向CO和CI延展，同时在原有的CD领域开始纵向升级（自动化-数据化-智能化），也就是横纵两个方向同时进行。

第一个是横向扩展，将PaaS化的覆盖面从CD领域向前面的CI和后面的CO拓展，计划三年。

第二个是纵向升级，把整个PaaS体系从自动化，向数据化和AI升级，当然是先从已经完成自动化的CD段开始，计划五年。

如果不是以PaaS作为基础设施，这种一体化扩展和模式升级在烟囱林立的企业中几乎是不可能的，他们的团队会陷入异构业务的运维自动化建设中无法自拔，或者只能做单个点的数据化及AI升级。每个团队的构建成本，或者升级成本是随着烟囱的数量直线上升的。

但在Paas体系中就没有这个问题，以横向的CD+CO和纵向的AIOPS举例，只需要去构建一个数据计算平台和一个运维建模平台就可以了。当这两个原子平台做好了之后，只需要对接到iPaaS上，那这个PaaS体系就具备了数据计算能力和运维建模能力，SaaS的开发者就会发现一组新的sdk可用，瞬间升级原有的各类SaaS，例如原来需要点击一次才能刷新一下的静态监控视图，就会变成一秒一跳的实时的、动态的监控视图；过去的点击一次扩一次的扩容系统就可以升级为数据驱动的无人值守扩容系统。

这个时候我们就完成了从CD向CD+CO的过渡，我们的运维PaaS变成了运维+运营PaaS。想想前面还有一个CI，使用CI的群体主要是游戏开发工程师（全职业务开发）。由于D/O分离原则，他们无法接触到运营环境，因此就需要信息获取、自助操作、日志分析、持续集成之类的服务。和CO同样的道理，在CI领域，主要补充足够多的原子平台对接近iPaaS，就可以在SaaS层组装各种各样的研发类工具，在我们内部最具代表性的是一个叫“蓝盾”的SaaS，游戏开发必备的持续集成工具链。

至此，我们解决了传统烟囱模式的第一个问题，重复造轮子；但如何解决第二个问题：无限叠加场景的成本控制呢？在当前的竞争环境下，企业内部运营系统的丰富度是企业竞争的软实力，因此工具文化的理念也开始被广泛接受，但在传统烟囱式的构建模式下，同一个场景或者混合场景的需求由于不同业务方的诉求不同，系统建设方往往要付出成倍的代价，如果是找外包来做，那乙方公司基本上变成卖人头模式，难有复制效应。

在传统烟囱模式下，运营系统越定制，用户越满意，但建设成本就越高；反过来越通用，建设成本就越低，但用户就被强制统一习惯了，他们就不开心。这就是烟囱模式的一个巨大缺陷。

但在PaaS结构中刚好相反，定制的SaaS代码量，也就是成本可以做到更低。我们可以将SaaS分为两层，将基于iPaaS组装出来的通用类SaaS作为基础SaaS（一级SaaS），只提供给专业岗位人员使用；再利用基础SaaS的能力，拼装出二级的场景SaaS，提供给最终用户，有可能是非技术用户使用。场景SaaS（二级SaaS）的代码量更小，但数量可以很庞大。久而久之，企业内部会形成厚云薄端的IT结构。

拥有了这种厚云薄端的PaaS结构，企业内运营系统的单人构建能力会成本提升。在IEG内部，蓝鲸像是我们的研运操作系统，截止到目前，我们数百人的运维团队先后开发了两千多个SaaS，目前还没下架，仍在提供服务的就有七百多个。包括我们事业群的行政、秘书、HR等岗位都会有定制的SaaS提升工作效率，例如我们互动娱乐事业群的发文系统、业务星级评定系统、考核系统、经费管理系统、物资申请系统等等。

基于PaaS的研运模式我们对外做过分享，在2016年之后对腾讯IEG投资的公司提供过私有化部署的版本，中小型公司提供易安装维护的2012版，中大型公司提供2015版，这两个版本在2017和2018年分别更名为“蓝鲸社区版”及“蓝鲸企业版”，前者免费提供给社区，后者由严格筛选的蓝鲸服务商公司为甲方提供服务。