DevOps前军：腾讯研发管理实践体系与工具平台的探索--孙辰星

黄晓轩

讲师 | 孙辰星
编辑 | 黄晓轩

讲师简介

孙辰星
毕业于浙大数学系，现任腾讯CODE平台产品负责人，曾就职于北京联众、7K7K等公司，具备10多年技术、产品、研发管理、团队管理经验，加入腾讯后负责腾讯代码管理平台的产品工作，主导了腾讯Git等项目，致力于腾讯代码管理系统与DevOps链条的结合。

前言

DevOps是很全的概念，他牵扯了从研发过程中最早的产品需求，产品从测试到开发，再到最后运维，甚至说客服，所以他把整个产品的过程都串了起来。其实每一步，每个不同的角色，他的视角是不一样的。对于腾讯来说，我们也是。我们有很多很多不同的部门，这和很多企业内部的结构是一样的。
我今天分享的主题是腾讯DevOps全链路方案的分享。我负责是研发管理和需求敏捷，这也是我本次分享的重点。

腾讯研发

我来自于腾讯的研发管理部，研发管理部是腾讯一个很老的部门，负责整个腾讯的工线，就是研发的管理、效率加强。腾讯的研发管理部归到腾讯的TEG，这个BG也对腾讯整个公司的研发提供支持和文化上的帮助。

腾讯有非常多的产品，这张图中的图标肯定还没列全。如果让小马哥自己去数腾讯有多少产品，他肯定自己数不清楚，如果让高管去数，估计一两周也不一定能数清楚。腾讯有特别多的业务，所以我从研发管理部角度特别佩服腾讯的工程师和产品团队，做了这么多东西。
在这些海量的业务中，这张图中最多产品的BG就是SNG。全腾讯的代码库都由研发管理部管理，但是这么长的产品线背后，腾讯有多少员工呢。腾讯的技术人员有15000人，当然这个技术人员里面不仅仅是开发，还包括测试、运维，所以真正写代码的要少于这个数。产品人员有6000人左右，这里不仅仅是产品经理，还包括运营、游戏策划、项目经理，产品经理大约2000人的规模。腾讯用这样的人数去支撑腾讯集团产品线，其实在BAT来讲效率是非常高的。实际上目前在BAT中，腾讯还是处于一个低位的，从总人数来讲是一个低位的水平，尤其到大公司这个级别来说，腾讯真的是一个很低位的水平。这么少的人做了这么多的东西，从这个统计角度来说，还真的是可以能够解读到腾讯自己内部产品的研发效率是非常高的。

研发效率高，我们所认为的原因有四点：

1. 人的因素，杰出的产品经理和研发人员。因为我们有非常好的人，我们有很强的，很杰出的研发人员和产品人员。所以这样对我们整体的人均效率会有整体的提升。其实想一想这个道理，可能一些二线公司和我们比起来，我们一个开发人员的course可能是他的2倍或2倍以上。
2. 自组织的敏捷。
3. 研发工具体系去中心化，自动化程度高。
4. 科学高效的质量控制能力。

敏捷过程

先来看敏捷，在研发过程当中主要有两种角色：产品经理和研发团队。

这张图是Scrum基本的一些元素，我把他简单列了4个元素。他是一个Scrum的模式，从需求到形成迭代，迭代好之后团队leader进行任务的分配，然后开发的过程当中或者开发结束之后，来做缺陷反馈，这是一个scrum的基本模式，我并没有列的很细。

我们把研发过程再展开，把配置管理的工作也加进去，你会发现一下子又多了很多节点，一下子这张图从敏捷的方法变得更复杂了。这张图 我已经做的非常非常抽象。但是我们回想起来一个事情，真真正正互联网开始的原点是什么样子的。互联网开始的时候可不是这个样子的。
大家想一个问题，小马哥1998年和托尼几个人开发最初版QQ的时候，他关心这些事实吗？他知道什么叫迭代吗？所以，其实回想起来研发项目效率在最高的时候真的是原点那个时代，就是第一代程序员。第一代程序员是什么样子？就是一个人做了很多事情。小马哥腾讯五虎将写了第一版QQ。放在今天来看，今天的软件工程就没有当时那么简单。为什么会出现这么多理论，敏捷的方法论、配置管理的方法论、软件工程的方法论等等。是因为互联网软件的规模、难度、模块，还有功能都是越来越复杂、越来越强大的。现在人越来越多，引出的最直接的问题是什么问题？最开始一个人的时候没有问题，两个人的时候开始逐渐有问题，10个人、100个人、1万个人的时候就变成了关键性问题，就是沟通的问题。

敏捷和DevOps的共性本质

我们回想一下敏捷的方法论：Agile、XP、Scrum，他所做的是对你的团队做了一个沟通上的行为规范。他给你制定一个行为规范，你一开始要跨需求，要做需求沟通会，要划分迭代，每日要开站会，要用看板的模式在团队之间进行密切的沟通。讲了什么东西？讲了沟通。
实际上从Scrum来说，Scrum到现在有20多年历史了，真的非常非常久。Scrum的理论到现在来说一直维持20多年前差不多的理论，他没有太大的变化。很多的敏捷教练和敏捷专家，在这个理论上耕耘了几十年。当然可能在一些周边的领域衍化出一些新的度量方案，或者新的实施方案，但是他的本质上还是一样的。本质上就是给我的团队去拟定和规范一个沟通的流程，一个沟通的方法。
对我来说，我是腾讯客户平台的产品经理，产品经理有一个职责是要找到这个事情的本质。我今天在这里跟大家做这个分析，把这个事情的本质跟大家提出来，敏捷是和沟通有关的。实际上DevOps也是和沟通有关的，我们知道DOIS主会场，主办方颁布了一个叫“研发运营一体化标准”。研发运营一体化，研发和运维开心的在一起。他实际上还是在解决研发和运维当中沟通所带来的效率损耗。通过自动化，通过方法论来实现这个沟通效率的加强。当然DevOps的沟通效率和敏捷的沟通效率还有一点点不一样。敏捷所强调的沟通都是人和人的沟通，产品经理和研发团队的沟通，研发团队和研发团队内部的沟通，研发团队和测试人员的沟通。但是DevOps不仅仅是人和人之间的沟通，他还涵盖了人和机器，机器和机器之间的沟通。

优化沟通

从沟通效率的角度上来说，我是从腾讯的工线角度负责整个集团代码的管理。实际上我也是从产品经理角度，我要解决整个集团效率的问题，我首当其冲首先想到的是解决整个集团沟通效率问题。研发管理部有两大产品，我觉得腾讯在沟通的效率上走了三步，我觉得是非常重要的，就是三点其实腾讯目前来说已经做的非常好。

1. 组织上减少职务鸿沟。组织上的敏捷，组织上来减少你每个人和人之间的一个职务鸿沟。这块不应该今天来讲，这是企业管理的问题，我们今天先把他略过。
   
2. 全面信息化。腾讯很早实现了全面的沟通工具的信息化。
   
   
   
   
   大家看一下传统敏捷和腾讯敏捷，传统文档和腾讯文档。
   我提这四张图，电子化和信息化这个事情提出来这个概念很久了。但目前来说我们观察很多公司，还在贴黑板。从我的角度来说，贴黑板并不是有错，从Scrum角度来说一个小团队你做看板模式，贴纸条，没有问题。但是对于腾讯这样的集团，这样的大型公司来说，我们的场景是多样化的，我们不能让我们的团队，每个团队都去贴黑板。
   我随便举一个例子，比如工蜂团队和腾讯云在合作，就没办法贴黑板。因为我们开发人员都不在一个办公楼，我怎么做？腾讯很多办公楼都有白板，实际上真正在实际操作的时候，大家还不是通过经典的看板模式，经典的敏捷模式说一定要团队每天贴这个小纸条，完成了一个任务，把这个小纸条从这边移到那边。其实想想人都是懒的，开发工程师都是懒的，他能用电子化系统搞定的事情，他为什么还要写小纸条，还要贴上去，贴完了还要撕，最后还要用碎纸机。每年腾讯2万多人全都去贴纸条，大家算一算这个纸条费用是多少？所以在整个的过程当中，腾讯从需求来说，很早就是电子化。TAPD已经有10年的历史了，腾讯的一个员工出去创业，他很喜欢用这个TAPD。他要求公司给我开放一个外网的版本，让我可以继续使用TAPD，为什么呢？因为他已经形成了习惯，他的敏捷已经完全通过一个电子化的系统实现了一个统一的沟通方式。
   代码这一块我们也是一样的。我们的代码库是以Git为基础的代码管理工具。代码的沟通是开发和开发、开发团队和开发团队之间的沟通。他通过文档、源代码、API进行沟通。
   很多的企业用文档有一个痛点是：你的软件先更新，还是你的文档先更新。你开发人员是要写代码的，很多开发人员不愿意写文档，他希望代码库就是我的文档，我的代码库上提交记录能够直接生成文档。这样减少他的工作量，实际上加强你企业文档电子化的过程。你如果从一个流程上去限制，比如你要提交一个代码，你必须写一个word文档，他要花费双倍的工作。这一块腾讯从很早来说，亲文档的一个敏捷过程，腾讯并不强调文档，但是文档非常有用。你内部的项目在相互沟通，特别是你内部关键组件给别的团队使用的时候，需要有足够的接口文档、说明以及安装说明，这些才能让其他团队无缝的，不需要咨询，也不需要产生额外沟通工作量来实现一个跨团队的合作和沟通。这是从一个集团整体来说提升你集团的研发效率的一个方式方法。对某一个团队来说，比如你就是5人、10人、20人团队，你都坐在一个办公室里，可能没有什么效果。但是你放在一个大型的集团，一千人、一万人的时候，就成为了你这个效率关键优化的关键点。
   
   信息化目前有一个趋势，随着移动互联网的发展，现在是一个叫做办公无疆界的概念。腾讯从IT设施来说，还有从我们研发系统设施来说，也逐渐的在实现这个办公无疆界。以前我们是用PC，我们联网发邮件，发邮件之后开始有了ERP，类似于这种办公的OA系统，开始有了审批单，审批单现在不够，要有移动端。
   我举一个例子，我生病在家，我是知道我团队人提交的情况的。因为我开着我手机上的企业微信，我们工蜂的代码管理系统在提交合并的时候，他的信息是通知到企业微信的，而且只通知和我有关系的，不会通知和我没关系的东西。所以我是非常清楚我团队的变更状态和更新状态，包括他们提出的一些问题，对于设计方案提出的一些问题。TAPD也是通过企业微信提供的一个push服务，在腾讯内部就是用的很舒服，有的人比如下班回家，回家的路上其实都可以反馈问题，都可以回复别人反馈的问题。这是一个办公无疆界的体现。
   在这一块的话，实际上会加快你每个团队的沟通效率。他无时无刻可以看到和他工作相关的东西，而且他可以自主的控制我是想看还是不想看。从这一点来说也不会给人造成工作狂的状态或者骚扰的状态。这样你晚上7点钟可以解决的问题，你何必拖到明天，或者你刚好赶到周五，就下周。办公无疆界对企业内部研发系统、OA系统都是一个很强的加成。我们的工蜂系统和TAPD在腾讯内部都和企业微信做了集成，已经打通了这种实时的信息流，现在在对于开放的版本，对于TAPD的公有云版本，和我们工蜂的公有云和私有云版本，我们以后也会逐渐开放和企业微信或者微信服务号打通的能力。
   这一块我从产品经理角度来说，我觉得是非常重要的。这不像以前传统的软件那样，就是我安装在那里，他什么样我不知道，我通过邮件来收他状态的更新。我不经常收邮件呢？我基本上我的手机都是开着微信的，同时开着企业微信。所以这是一个很大的变化。
   回想在这20年来，敏捷是没有发生变化的，敏捷的理论是没有太大的变化的，Scrum理论从20年前就提出来，到现在还叫Scrum，也没有提出来Scrum+，但是什么改变了呢？这20年发展历程中真的是翻天覆地，以前我兜里不会揣手机的，现在我随身的都是移动端。信息化从最初大家收邮件，变到了大家使用微信，这是翻天覆地的变化。所以这个过程才是这20年当中，特别是腾讯这家互联网公司自身对自身能力享有的一个加成。在这一点来说，其实很多企业，你比如你做敏捷，你采用20年前的方案，你要想想你采用20年前的方案和现在新一代的方案，你有什么区别？你要抓住这个本质。这是我从产品经理角度来表达这个观点。
   
3. 统一沟通体验。腾讯在统一沟通体验上非常的执着。以前我们内部沟通统一都是用RTX，随着公司的战略，现在总办决定大家开始用企业微信，现在腾讯几乎所有都在用企业微信。其实在切换企业微信的时候，很多人提出了这个问题，为什么不能让RTX和企业微信并行运行？这里面就解答了这个问题。因为从管理者的角度来说，他希望集团是采用完全统一的沟通体验。他宁可说砍掉RTX的团队，也要让企业微信铺设在全公司，通过统一的体验实现整个内部的沟通，当然这是OA的沟通。我今天讲的是研发管理系统统一的体验。

腾讯内部研发的工具非常的广泛，是一个去中心化的结构。这个结构可以说每一个事业群，每一个部门，很多的部门都会有自己一套的开发工具链和运维工具链。但是你会发现腾讯做了这么多东西，他还是保持了一定程度的集中性，什么是集中的呢？就是需求管理系统和代码管理系统，是总办要求一定是要集中的，强制你所有的团队必须要使用这两个系统。为什么？因为从整个集团企业的角度来说，使用同一份统一体验的、基础的沟通工具，对你的整个集团来说，你的效率是完全可见的，你可以感受得到的。
我举一个例子大家就明白了，比如我一个同事从我的部门转岗到微信去，他使用的代码系统是一样的，他使用的需求管理系统是一样的，是一致的，不需要任何的成本代价的切换。
再举个例子，如果我的一个团队，要和微信的团队进行合作、协作，我怎么样去做？如果我和微信用两套需求管理系统和代码管理系统的话，意味着我们之间互相要学习。但是现在不用，我的代码管理系统和微信使用的代码管理系统是一致的，是完全一样的，都是腾讯同一份，需求管理系统也是同一份。

这是腾讯研发管理部从研发管理角度来说对整个腾讯提供了统一的沟通体验的两个平台。一个是腾讯的TAPD，TAPD负责的是产品规划、迭代计划、测试管理等等，这样一个敏捷的管理系统。工蜂Git是我们研发管理部研发新一代的代码管理平台，一定会替换目前所用的SVN，然后统一腾讯内部源代码的沟通体验。整个腾讯的源代码都在我这个部门负责，我现在所做的事情是在把这个腾讯内部的一些老的平台逐渐的替换掉，推动我们的业务团队更新他自己的研发管理使用的经验，换到我们新的工蜂Git平台。软件代码、资源文件、分支管理、审查、质量管控研发管理平台是腾讯统一体验的。

DevOps系统如何再腾讯内部集成

腾讯有那么多和DevOps有关的系统，如何在腾讯内部进行集成呢？这块我们讲一个概念是松耦合。我们知道在研发过程当中，他有很多的步骤，每个步骤都可能形成非常专业和有他自己特色的平台。我们也很清楚，任何一个平台比如Jenkins，这是一个开源平台，基于这个开源平台新开发或二次开发，他也很难去满足所有团队的需要。这么多种多样的研发工具，怎么样做集成？集成的方式我们提供的思想和方案就是松耦合。松耦合就是我支持你，但是我不依赖你，我可以独立你而存在。

举例1：内置的集成方式

我们和TAPD内部集成松耦合的方式。这是TAPD的一个界面，TAPD的项目设置当中有一个关联git项目按纽，他实现的是一个从需求关联代码库、关联代码分支提交的这么一个功能。

他只需要进行三步的操作，在这里面点关联Git项目，然后通过Authorize认证，第三步选择他要关联的项目。这样三步点确定，这个代码仓库就和这个需求池绑定在一起了。在提交的时候，只要带着bug_id的串号，需求和代码就直接绑定上。这个功能其实设计的很简明，体验也很好，但是这个理想很丰满，现实很骨感。现实很骨感的原因就是其他的研发团队更喜欢自己定制的方案。

举例2：研发团队偏爱的方式

微信这个项目很具有典型性，因为他没有太多的研发人员，没有上千的研发人员。他只是一个几百人的团队，所以很多的其他公司，比如说传统行业的公司，你的一个核心产品大约也就是这么一个团队的规模。所以微信实际上在迭代的过程当中，研发管理过程当中他的经验是可以深层次借鉴的。他每月一个版本，我们平时使用微信客户端的时候每月一个版本，大约是300-500左右的需求。(微信安卓客户端)核心研发团队大约40人左右，有3个Feature Team，平均每个人要做10个需求每个月。
他使用了TAPD管理他的需求，他整个产品经理团队都是用TAPD提需求。他使用的就是腾讯的工蜂Git管理他的代码、分支和分支发布。

咱们快速看一下。这是他的分支管理，我们可以从这张图上很清晰的看出，微信他的管理模式是采用了一个是功能分支的协作模式。

他的团队所要做的事情是把他的需求和代码库要关联在一起，有三点：

1. 他的迭代关联了代码库的默认分支，这个默认分支每一个迭代会有一个新的默认分支，会把这个默认分支重新设一遍。
2. 他把版本会每个月做一个版本规划，会通过git系统上分支和Tag，管理他待发布的版本。
3. 他的需求是和他的Feature分支来绑定的，他日常的Feature分支大约500个，是几个月干的事情。

这是微信在TAPD项目的一个截图，他的迭代从需求管理系统上的命名和代码管理系统上他默认分支的命名是完全一致的。这也是他后面为什么可以做自动化。

这是我们工蜂系统合并请求单的一个截图，可以看到他贴的是一个TAPD单，他贴TAPD单目的是要绑定他的需求。

在这一点上，他们实现了自动化。如果这个TAPD单没有贴，或者贴的不对，他会自动的提示：您的提交因为缺少了TAPD的单号所以阻止被合并。一旦他的需求没有关联起来的话，我从代码分支上不允许他合并。直接规范他自己的研发人员一定要和这个需求进行绑定。

这也是另外一个他们自己实现的Feature。他的产品人员，会在TAPD上面做一个标志，标志这个需求在这个月能不能被合入到这个分支上。他实际上也是一个自动化的检测，他通过调用TAPD的接口和Code平台的接口，来实现自动化。这张图都是我们工蜂系统的动态墙，这个动态墙是按照时间顺序来的。过几个月回溯时，他可以清晰的知道我什么时候解决了这个问题，什么时候重新绑定了这个需求。

他们也实现了代码和质量测试的一个集成的自动化。这是另外一个项目的流程，实际上微信使用的流程也是差不多的。右边是一个Jenkins Plugin的一个方式，微信他的客户端是用Jenkins做日常检测。左边是我们工蜂系统，他通过调用工蜂的接口，还有自己去进行CI，自己去进行UI的检测和代码风格的检测，来实现整条自动化的链路。

实现的效果就是像这个图这样子，直接在他的代码管理系统，就是我们工蜂平台上。当这个开发人员提交了代码到这个代码库上，然后想要往这个月的发布分支合并的时候，他一旦提交合并，所有的自动化检测、编译检测、UI测试，这一系列自动化的操作，在合并提出的瞬间就完成了，来给他的分支决策人一个在我们代码管理系统上的反馈意见。下面是一个通过的，上面是一个拒绝的。

咱们举完微信的例子，再来谈谈腾讯对于内部系统的要求。在代码管理这一块，对于企业级研发平台来说，我觉得我们的要求会比在座的各位要求会更多。从存储上来看，我们如果要去用一套代码管理工具，我们一定是要求他无限大的。腾讯有一个特点，他有很多的大项目，我们知道游戏资源非常大，我们的代码管理工具一定要支持大流量和大容量的项目，这两点上是没有商量的。
人员的管控从管理上来说，也一定会要求我的系统是一定要和公司人员管理有关联，而且要做到人员可控，如果他转岗，如果他离职，人员的权限和项目的权限还有人员的帐号都必须做到可控，这个也是没商量的。
腾讯有多个办公地，在北京、上海、成都、深圳、广州很多地方，最早做SVN的时候，很多团队要求他的版本库就在他的本地。因为网络光纤费用还蛮贵的，而且还有电信和联通线路的问题。所以从我们角度来说，以前做SVN系统的时候就实现了多地部署。现在放在我们工蜂系统上来说，也是一定要实现多地部署的。就是你成都的团队访问成都的版本库，但是你不管是北京的人还是成都的人，还是深圳的人，从这个网站上，从这个管理系统上看到的是统一的一个界面，完全统一的一个界面。这一点上，我们也是实现了一个就近访问的能力。
在安全上对于腾讯来讲也是没有商量的。你企业内部的一些敏感操作的日常记录，你一些异常操作的恢复。我举一个例子，现在外面的开源软件，比如说他的开发人员可以删项目，他删完以后这个项目就没了。这种情况在腾讯是绝对不能发生的，我们不允许这种事情发生，在这个基础上我们一定要做很多的定制。

在这些要求下面，工蜂系统就诞生在这些苛刻的环境条件下面。

同时，还支持了比较新的研发的一些思想，我把这些新的思想归结为5部分：

1. 代码检视。腾讯有Code Review文化，在2016年我们做了一个统计，Code Review人数占到技术人员总数的40%-50%。Code Review这个文化是一个质量前置，就是你尽可能少的去做黑盒测试、功能验证，然后黑盒测试和功能验证尽可能多的通过自动化去做。但是质量交给研发团队，通过代码检视的方式，来实现他的质量提升。这个思想是从顶尖的互联网公司来的，主要是从Google来的。腾讯之前有很多从Google来的人，带动了腾讯内部代码检视文化。在很多团队是强流程的，比如我们支付的团队，他要求每一段提交的代码，想要上线必须通过两个不同的人看过每一行，看过之后才能发。
2. 分支管理。现在要交付的内容越来越多，越来越复杂，交付的版本也越来越多。照理说微信就一个版本的产品，实际上他要管控多个分支，因为线上很多人不愿意更新还用老版本，所以一定要支持大规模分支管理的能力，而且分支的成本一定要低。
3. 会话式开发。这是一个比较新的概念。在沟通上，所有沟通的过程呈现在系统当中，这也是以后AI发展的一个趋势，人工智能介入的方式一定是数据。你在开发过程当中从需求沟通，再到代码阶段的沟通，再到接口沟通，一个合并发布出去，遇到了什么问题都在工蜂系统上面呈现。这一块有不少团队采用了这种方式，目前使用下来还是不错的。
4. 集成和定制。为了支持我的松耦合能力，我的每一个功能都要提供API和触发器，才能够实现深度松耦合。这样我们每做一个新功能，我的API一定是同时做出来的。
5. 审查和监控。必须从企业级别加强我自己安全的保障。在这部分，腾讯对游戏团队的要求是非常高的，因为他们自己内部的竞争很激烈。

腾讯是一个非常大的企业，从自身的动机来讲，从集团角度来说，满足每个人挑剔的需要。他们有的人会挑安全的问题，老板有时候会挑你稳定性的问题，从这方面我们做了很多的优化和定制。

我们是腾讯的研发管理部，我们会和腾讯云的同事一起来给大家提供企业级别DevOps解决方案，非常欢迎大家来参与我们的讨论。我今天的分享就到这里，感谢大家。