华为云DevCloud百人大规模精益DevOps转型案例

大家好，我非常高兴看到在现在这个时间还有这么多同事在这里学习，大家也很辛苦。

我今天跟大家讲华为的经验，我在华为入职两年零六个月，之前做咨询，大家如果百度的话能看到很多我的介绍，我不过多介绍我自己。我在华为两年半时间做了两件事，第一件事指导华为的大多数产品线实施精益开发，同时打造了华为内部的精益开发平台，第二件事是作为产品经理参加了华为对外的商业化DevOps平台产品的打造。我今天给大家介绍的是华为怎么做大规模DevOps转型，以及我的产品怎么去做的，如果你的团队很大，企业很大，那么比较适合听这个话题的。

1.华为研发历程

先回顾一下华为研发历程。在业界大家都知道软件工程有三代，第一代是软件作坊时代，那时候没有规范的流程，刚有软件，第二代进入了过程控制时代，到2001年进入了敏捷、精益和DevOps时代。这三个时代每个时代历时20年。在华为我们也经历了三个时代历程，但我们的进程快，从1998年之前，华为实际是小作坊模式，那时候我们叫“游击队”，没有什么流程，就是靠人肉来铺，八年之后，华为认识到和业界相比，我们人均产出要低，老板意识到必须要从国外引入先进的流程，因此从IBM花上亿元引入了IPD流程，于是从1999年开始我们进入了重型控制时代。

从2008年开始引入敏捷，华为做敏捷已经做了十年时间，可能很多人都不知道，我记得华为之前招我时，我很诧异，因为这样的公司给我的印象是一个传统的、保守的、生产方式也不是很先进、靠人加班、靠人来铺的企业，可能还是主要以硬件为主，我一直对华为是这样的印象。经历了半年时间，我去华为交流多次才发现，外面的世界不懂华为，公司一直比较低调，我们出来分享是要经过层层审批的，公司鼓励文化是不要对外吹牛。我们做了十年敏捷，这第三个时代我们称为特种兵时代。基本上华为所有的先进方法大师、国际大师都在华为做过顾问。我2015年加入华为时，已经在绝大多数产品线部署了持续交付流水线，而DevOps从那时候开始的。

2.DevOps的定义

关于DevOps的定义，我上午没有参加，不知道那些老师怎么定义的。我理解DevOps没有标准化的定义，而是又很多定义。华为也有自己的定义，华为对DevOps的定义写到了2014年的年报里。DevOps对华为来说是什么？不只是覆盖软件研发，尽管DevOps是从软件研发模式开始发展起来，DevOps会超越软件行业，DevOps会成为很多传统制造业的商业模式的变革，这是华为的定义。为什么？因为很多传统行业的厂商希望从做设备向做服务转型，如果没有DevOps就很难做到，DevOps能够赋能这些传统企业实施这样的转型，从而实现商业模式的变革。对华为也是一样的，我们想做ICT转型、云化转型，没有DevOps是无法实施的，所以DevOps在2014-15年开始在全公司范围内发展。到现在为止大部分产线都应用DevOps，尤其是云产品。

3.DevOps转型

接下来，我介绍我自己的产品怎么做DevOps转型。我自己的产品华为云DevCloud是一个DevOps一站式平台，它是典型的云化互联网产品。我们的产品是从公司内部孵化出来的创业产品，和外面的创业公司很像，生存过程其实也很艰难。为什么这么说？我们的创业团队一开始只有两个人，就是部长和他手下的一个人，没有资源也没有团队，为什么公司愿意给你资源，为什么给你这么多人？都要证明你的商业价值才能得到资源和团队。我们经历两年多的时间，才发展成为百人以上的团队，这个发展历程非常像外面的创业公司。作为一个互联网创业团队，什么时候开始引入DevOps做工程能力的建设？不要第一天就开始。任何一个创业产品都会经历这样几个阶段：第一个阶段，你的客户还不清楚，在寻找客户，处于问题和解决方案适配的阶段，那时候只有创始人和他的合伙人，这个阶段你做什么工程实践？什么都不需要，只需要定位你的客户，寻找你客户的痛点；这个阶段之后设计一系列的最小可行化产品去验证产品是不是打中了客户的痛点，是不是达到了产品与市场适配，只有达到了适配之后才会大规模招聘员工组建团队；接下来做的是寻找渠道做营销，达到产品与营销渠道匹配之后，规模化复制，最后到达成熟期。

整个创业历程是非常的艰辛，一定要一步一步来。很多创业公司的死亡都是在错误的阶段做错误的事情，导致现金的断裂而死亡，我们也是按照这些步骤来的。一开始只有领导和他手底的一个人，去抓资源，抓一个小团队做产品，我们的产品是从内部孵化出对外的，是有基础的，不是从0开始建的，华为内部本身就有DevOps平台。但是内部和对外产品不一样，内部的业务场景非常复杂，因为内部的产品线都是500人到1000人甚至更多的规模，而外部所面临的目标客户群体都是小公司或者是中型企业，一个项目只有几个人最多几十个人，所以对内部的平台不能直接拿出来对外，一定要把它简化，适应我们的目标客户群，然后再组建一个20多人的小团队，设计了一系列MVP，达到产品与市场匹配。百人以上规模的团队是达到这个点之后建立的。

什么时候开始做DevOps？过早投资DevOps会造成很大的浪费，因为产品和市场还不匹配，还需要探索商业模式，但也不能过晚，如果达到这个产品与适配点之后很长时间还没有投资DevOps，你就没有办法规模化扩张团队，如果没有办法规模化团队的话，就没有办法满足你正在爆发的市场。所以，我们做的很正确的一点，是在达到产品和市场适配点之前，投入了微服务的建设，投入了DevOps建设，这个决定是当时做的很正确的一个决定，尽管那段时间非常痛苦，因为团队既要交付特性，压力很大，加班很多，同时还要做工程能力的建设，那时候我们从一个团队做试点开始。在华为，做试点并不是说让这个团队试一试有没有效果，有效果之后再铺开。效果肯定会有的，因为这是业界探索成熟的东西。我们试点没多长时间所有团队就全部开始做。

4.华为DevOps一体化平台框架

现在介绍一下华为DevOps的一体化平台框架是什么。框架并不只是平台本身，既包括理念又包括管理流程，工具只是DevOps的一部分，如果只有工具其实你也什么都干不了，因为人都不会干。在华为来说，管理流程上，华为用了Scurm、看板，在内部产品线还有用了规模化敏捷，在化为叫产品级敏捷。我自己的产品没有用产品级敏捷，待会儿会介绍一些我们自己的实践。华为的Scurm和书上的Scrum也不一样，华为没有Scrum Master。我们没有把书上的Scrum照搬来，并不是说标准Scrum有什么问题，只是我们没有按照那个做。

从组织结构上，我们实施的是全功能团队，华为所有的产品线都在做全功能团队，有些产品线很难做到端到端地覆盖全部流程环节，但是我们团队就可以，因为我们是从0到1的团队，一开始只有几个人的时候就什么都干，虽然是研发人员，但都去拜访客户，去找市场，跟政府洽谈，想办法为产品找到市场，后来规模化后也是全功能团队。

在工程实践上，所做的跟各个公司差不多。在平台上，我们就用自己的开发平台，就是华为云DevCloud：DevOps一站式平台。

大家都知道康威定律：系统的架构受制于组织结构的沟通方式。在很多公司里的实际情况是，由于组织结构决定了系统架构，而系统架构又很难改变，所以当想改变组织结构的时候，发现组织结构又受制于系统架构而很难改变，这是我深刻体会到的。当你做DevOps转型的时候，最后总是总是因为架构的原因让你很难走到下一步。

拿我们的团队来说，在达到产品和市场适配之前做微服务是非常好的时间点，因为我们不再需要建设复杂的组织结构，我们的微服务架构完全能支持组织的规模化。但是对于很多传统企业来说，有很多职能化分工的组织结构，然后有很多层次化，如果能把架构做服务化，这样的组织就会逐渐发现：很多层次的决策人员、管理人员可能价值都没那么大了。这一点在华为的很多产品都发现了，华为的很多产品线都在做微服务，至少做架构服务化，做了之后就发现原来很多的经理做团队之间的对齐、计划、协调，召集所有的Scrum团队在一起一周开几次会对齐节奏，这些获得变得并不是那样必要，包括这些角色的价值也没有那么大了，因为每个团队都非常独立，不需要再找中间人把大家拉通对齐。现有传统的组织结构，其存在有它必然的历史原因，但并不是存在就是合理，本质上如果把架构做服务化，那现有的组织结构很多层级实际上就慢慢不再需要了，这是在这个过程中我们发现的。

5.规模化敏捷

这是大规模敏捷框架SAFe，华为的大部分产品线都以这个框架开展规模化敏捷，华为称为产品级敏捷。因为华为的组织结构和这个框架里的组织结构一层一层匹配，每一层都有管理决策，架构的决策，跟华为正好匹配上，华为当时选SAFe是因为这个框架非常合适做从上到下的大规模转型。这些人的角色保留，工作没有丢，只是换一种方式找到自己的位置，这是愿意接受变革的前提。在我们做DevOps的过程中发现实际上慢慢不是特别需要这个角色了。拿我们DevCloud产品来说，我们从第一天就没有用这个大规模敏捷框架，因为我们是从0到1爆发式增长过程走过来的，一开始就不是以这个为基础来做转型的，我们现在已经百人以上，没有用这种框架，我们做的也很好。所以我的结论是，这个框架并不是必须的。

我们用的是什么？我们就是全功能团队，华为对全功能团队有自己的定义。我们公司有这样的特点，任何一个方法论，在我们公司有自己的定义，这个定义跟业界的定义可能不完全一样，在我们公司、我们的业务情况下、我们的文化里有自己的定义。总的来说，全功能团队我们的定义是能够对特性、部件或者架构完整的实施规划、需求、设计、开发、测试并独立交付、运维的项目型团队。在华为所有产品都在向这个方向发展。从前一个大型产品线所有决策都是一层一层往上升级报告，现在就是往全功能团队发展，这个全功能全权决定产品做什么，什么时候做，什么时候上线。拿我来说，我是DevCloud的产品经理，我的规划是什么，产品的竞争力在哪里，我的目标客户群在哪里，这些都是我决定的范围，团队负责把产品交付出来。

我们DevCloud产品共有十个服务，拿任何一个服务来说，比如项目管理这个服务，组织结构是什么样的？这个团队的组织结构有一个产品经理，我就是一个产品经理，还有运营人员、开发工程师、架构师、测试工程师、UED设计师。在我们一个服务的规模差不多有10人左右规模。每个服务是不一样的，有的规模大一些十几个人，有的服务规模小，只有几个人，不管规模大小，所有的职能角色都是全的。并不是说团队里的人都是全栈的，比如说UED、运营没有配备给团队的全职人员，他们属于公共资源，只是为某几个服务工作。

我们的管理流程是一周一个迭代，在做DevOps转型和DevOps微服务之前，我们产品是三周一个迭代，因为我们之前本身就有比较好的基础，不至于从瀑布走过来，是从华为的持续交付的基础走过来的，原来是三周现在一周发版。我们一共10个服务，每个服务一周一个迭代，一个迭代一次发布，大家又不是同一天发布，因此对客户的感知是每天都有新版本上线。我们每周迭代过程跟Scrum类似，但是没有把Scrum书上的东西完全搬过来，因为当一个团队达到持续交付能力的情况下，Scrum的一些流程性工作就变得不是特别重要。我作为产品经理,一周之内做两次验收，第一次是在转测环境验收，检查开发做的是不是跟我们当时沟通的一样，第二次验收是上线之后，我去线上环境验收。另外，关于用户故事点的估算，当我们团队能达到这样的快速交付的速度后故事点的故事也不是很必要，因为我很清楚团队吞吐率是多少，比如，团队有十个人，按照历史吞吐率团队一周能做差不多十到十五个story，按照这样的吞吐率做迭代计划就可以了。

介绍一下我们的迭代三重奏实践，指的是产品经理计划两周的需求、UED设计人员设计一周、开发人员开发一周。为什么要做迭代三重奏的过程？本质原因是我们的团队在很长的一段时间里受制于一个约束：UED设计。根据约束理论，一个系统的效率受制于这个系统的约束环节，约束环节可能不只一个，约束环节决定整个系统的产出效率。我们团队的UED设计师属于公共资源，不专属于为一个服务工作。当我们团队实施了DevOps，交付效率提升之后，但是其它环节没有提升，而没有提升的环节自然就成为约束环节，比如说UED设计师的设计速度不能像开发人员每周上线特性一样快，所以设计人员的效率是没有办法跟上团队的脚步的。这种情况下怎么解决这个问题？把设计和开发人员的节奏错开，设计师需要专注，设计是一个创造性的过程，尤其是大特性的设计需要给她们专注的时间做设计，我们给UED一周的时间专注设计，设计产出隔一周给开发人员做输入，从而解决了瓶颈，同时没有添加设计师的。

再介绍一个管理流程实践：全价值流看板。由于我们每个服务都是全功能团队，不依赖其他团队，每个服务都建立自己的看板，设计、开发、测试、上线，所有流程，到了什么环节所有人都看得非常清楚。作为产品经理，我每天就可以盯着看板上的需求流到了什么环节，如果到了转测我就到转测环境里验收，如果已经上线了我就在线上环境再验收一遍每个服务都会有自己的看板。做了微服务和全功能团队之后，服务之间偶尔会有依赖时，如果完全没有依赖就不能成为一个产品，偶尔会需要另一个服务提供接口，这时候只需要点对点沟通就可以了。比如说我是项目管理服务团队，张乐是编译构建服务团队，他需要我提供什么接口，我们不需要把所有服务的人员召集起来开大会，这实际是浪费大家的时间，实际只需要做点对点的对齐即可。

从工程实践来说，刚才我介绍了以全功能为单位建立价值流。DevOpsHandbook整本书其实只有三句话：实施DevOps有三步。我刚才介绍的实际是第一步：从左到右建立价值流。不只是管理流程上建立，还要从技术实践上建立。

实施DevOps的第二步是：从右到左建立快速的持续反馈，由于我们每个服务都以全功能团队为单位组建，因此每个团队都可以建立自己的持续交付流水线，能够快速获得反馈。此外，还要建立用户数据反馈。一开始我们做产品的时候，我们不需要太多的用户数据，因为客户量非常少，我们还在做验证我们产品是不是打中客户的刚需，客户离开我们产品会不会觉得不爽。在很长时间之内用人肉就能够做到，比如，我们几个产品经理一段时间都去客户那办公，就坐到客户办公室里，看他怎么用产品，有什么问题，白天吐槽，吐槽之后赶紧让团队改，就这样。那个阶段不需要数据也是可以的，但过了那段时间之后，比如今年我们做大规模的市场拓展，跟很多城市的政府签了合作协议，与很多高校也签了合作协议，同时拓展了大量企业。收到很多吐槽、反馈，这时候没有数据就不行了。因此，一定在达到这个阶段之前建立用户数据分析系统，从而指导我们做产品决策。如果没有这样的系统指导我做产品决策，就只能通过一个个客服反馈，这个需求什么时候做，客户说了觉得不爽，一天我接十几个电话。通过这样碎片化的反馈，每天需求都像洪水一样涌来，没办法做出高质量的决策。必须通过量化方式指导我做产品决策，而一定要在产品规模化推广之前搭建数据分析系统，如果在之后做会非常非常痛苦。

最后讲讲文化，文化这个东西听起来比较虚实际非常重要。DevOps实施的第三步：建立高度信任的持续学习和实验的文化。实际上这样的文化并不是DevOps转型就能建立的，文化是这个企业自带的基因，文化是企业创始人个人价值观的放大和延展。可能大家都听说华为有“奋斗者”的文化，其实还有“长期坚持自我批判”的文化，这个我在入职培训时学过，我们参加入职培训，每天早上6点多起来跑步，当然不光是跑步，每天做价值观培训，实际上就是洗脑J。但是这个培训结束之后洗脑并没有完成，只是个开始，每天的工作实际上都在渗透价值观，如果想将文化固化在企业里，必须要在每天工作中得以渗透，否则文化就只能停留在纸面上，这是我得到的体会。

我们公司有两个重要的关于“长期坚持持续自我批判”的文化的实践。一个是质量回溯：当发现质量问题时马上召开质量回溯会议，团队在一起讨论发生了什么，本质原因是什么，下次怎么避免。第二个实践是事后回顾，回顾这个迭代哪些做的好需要保持，哪些需要改进。我们做这个事跟敏捷并没有什么关系，只是敏捷给我们提供了一个反馈机制让我们把这个事做得更频繁。从前可能一个版本结束后才做事后回顾，现在迭代结束之后就开始做，两周、一个月，每个产品线不一样。自我批判不只是这样两个实践，一定是深入骨髓的，一定是不断学习实践。

最后介绍一下DevOps转型策略。华为是如何实施规模化的精益DevOps转型呢？在华为， 所有的项目都在尝试着某些能力提升的实践，比如我们十年前就开始做敏捷，过去十年一章在尝试各种能力提升的实践，到现在全面开展DevOps。为什么要强调“所有的项目”？因为很多公司在尝试任何转型时，总是有大部分项目都说自己没有时间，因为进度紧张、交付压力大，以此为由不做。但在我们公司所有的项目都做，为什么？没什么原因，就是自上而下要求。为什么会有这样的要求？因为我们有自上向下传递的危机感，必须要保持自己企业的业界领先地位。我一直有这样的观点：一个企业如果不在自己的行业里处于第一、第二位，那么实际上就等于死，只是个时间的问题。因此，我们必须持续保持自己的领先地位。怎么去平衡改进和交付的压力呢？我们既要保证业务交付，也要同时造血，提升自己的研发能力，拿我们DevCloud的经验来说，我们是用70%时间交付产品，30%时间改进，即便我们已经实施了DevOps仍然还在做改进，架构还在持续重构，产品经理也愿意给团队30%的时间做投资在能力提升上。

变革大师约翰科特写过一本书《领导变革》，里边介绍了变革八步曲，《DevOps Hanbook》里有一章专门讲DevOps转型策略，其实就是将约翰科特的变革八步法应用在了DevOps转型领域。变革八步法可以用在任何组织变革，而且这八步是顺序，不能逆序，也不能跳跃。我们做转型跟八步法有相似之处，但也不完全一样，如果严格一步步实施这八步法就要花很长的周期，这样做变革满足不了时代对我们的要求，所以转型一定要像做敏捷一样小步快跑。我们的变革策略是：第一步，把危机感和紧迫感植入组织的血。我们公司本身就有很强的危机感和紧迫感，需要不断植入，时刻唤醒大家的危机感和紧迫感。每当团队觉得自己做的很好，马上就会有更高的目标要求团队，牵引团队做得更好。第二步，做大规模转型时，发布红头文件，在产品线试点的时候，产品线的最高领导要签署文件，表态我们要做这个事，全员都要配合。如果想推进变革，第一件事情就是要得到最高领导的认可，在我们公司基本上这一步走到了，后面就能够顺利开展。第三步，自上向下设定能力提升目标。我们做转型一定要有明确的量化目标牵引，如果没有这样目标的牵引，基本上得不到大家的支持，在转型的过程中也要时刻监控量化的结果。

剩下的几步需要迭代进行。产品线领导自上向下沟通、贯彻，产品线领导要决定做这个事，就要全员沟通这个决定，鼓励大家都要去做，没有什么选择；产品线领导自上向下沟通、贯彻，产品线自己全权负责：怎么做，什么时候做；然后，产品线决定试点适合哪个部门做，有效果之后马上全部铺开。这个过程不会慢慢地做好几年，试点团队有了初步效果之后马上全面铺开；接下来，横向传播，横向往另一个产品线传播，其它产品会受试点产品线的影响来转型，而受影响的力度更大，因为大家会问：效果怎么样？挺好的，那我们也做吧。就这样，最后一步固化实践形成文化，如果这个过程中间某一步做的不够好马上返回到上一步，可能再去跟产品线领导去沟通，保证领导的支持力度一定要长期存在。这就是我们的转型步骤。

我今天分享就到这，谢谢大家。