DevCloud如何做DevOps转型

华为云DevCloud是一个DevOps一站式平台，它是典型的云化互联网产品。DevCloud是从公司内部孵化出来的创业产品，和创业公司很像，生存过程也很艰难：创业团队一开始只有部长和他手下的一个人，共计两人，没有资源和团队，只有证明商业价值才能得到资源和团队；经历两年多的时间，才发展成为百人以上的团队，这个发展历程非常像创业公司。

作为一个互联网创业团队，什么时候开始引入DevOps做工程能力的建设？不要从第一天就开始。任何一个创业产品都会经历这样几个阶段：一开始，目标客户还不明确，需要寻找目标客户，处于问题和解决方案适配的阶段，那时候只有创始人和他的合伙人，这个阶段不需要做工程实践，只需定位目标客户，寻找目标客户的痛点。之后设计一系列的最小可行化产品去验证产品是否打中了目标客户的痛点，是否达到了产品与市场适配，只有达到了适配之后才会大规模招聘员工组建团队。接下来就是寻找渠道做营销，达到产品与营销渠道匹配之后，规模化复制，最后到达成熟期。

整个创业历程非常的艰辛，一定要一步一步来。很多创业公司的死亡都是在错误的阶段做错误的事情，导致现金断裂而死亡，DevCloud也是按照这些步骤来的。一开始只有领导和他手底的一个人，去抓资源，抓一个小团队做产品。

DevCloud是从内部孵化出对外的，是有基础的，不是从0开始的，华为内部本身就有DevOps平台。但是内部和对外产品不一样，内部的业务场景非常复杂，因为内部的产品线都是500人到1000人甚至更多的规模，而外部所面临的目标客户群体都是小公司或者是中型企业，一个项目只有几个人最多几十个人，所以对内部的平台不能直接拿出来对外，一定要把它简化，适应目标客户群，然后再组建一个20多人的小团队，设计了一系列MVP，达到产品与市场匹配。而百人以上规模的团队是达到这个点之后建立的。

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

华为DevOps一体化平台框架

框架并不只是平台本身，既包括理念又包括管理流程，工具只是DevOps的一部分。如果只有工具其实是不够的，最终还是人去工作。

华为的管理流程上应用了Scrum、看板，在内部产品线还用了规模化敏捷，在华为叫产品级敏捷。华为的Scrum和书上的Scrum有区别，华为没有Scrum Master，没有完全复制Scrum。并不是说标准Scrum有什么问题，而是应该结合自身进行取舍。

组织结构上，华为实施的是全功能团队，华为所有的产品线都在做全功能团队，端到端地覆盖全部流程环节，从0到1。团队初期，成员人数少、工作内容全面繁杂，从研发到拜访客户、跟政府洽谈，想办法为产品找到市场，后期规模化后依然保证团队是全功能团队。

在工程实践上，与各个公司相差无几。在平台上，使用华为云DevCloud：DevOps一站式平台。

正如康威定律：系统的架构受制于组织结构的沟通方式。在很多公司里的实际情况是，由于组织结构决定了系统架构，而系统架构又很难改变，所以当试图改变组织结构的时候，发现组织结构又受制于系统架构而很难改变。当尝试DevOps转型的时候，最后总是因为架构的原因很难走到下一步。

以DevCloud团队为例，在达到产品和市场适配之前采取微服务架构恰如其分，因为其不需要建设复杂的组织结构，微服务架构完全能支持组织的规模化。但是对于很多传统企业来说，有很多层次化、职能化分工的组织结构。如果能把架构服务化，就会逐渐发现：很多层次的决策人员、管理人员的价值淡化了。

在华为，这一点很多产品都发现了，华为的很多产品线都采取微服务，至少做架构服务化。原先很多的经理做团队之间的对齐、计划、协调，召集所有的Scrum团队在一起一周开几次会对齐节奏。采取微服务后，这些活动变得并不是那样必要，甚至这些角色的价值也淡化了，因为每个团队都非常独立，不需要再找中间人拉通对齐。现有传统的组织结构，其存在有它必然的历史原因，但并非存在即合理。本质上如果把架构做服务化，那现有的组织结构中的很多层级实际上就慢慢不再需要了。

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

构建全功能团队

华为用的是全功能团队，华为对全功能团队有自己的定义。华为有这样的特点：任何一个方法论，在华为有自己的定义，这个定义跟业界的定义可能不完全一样。

总的来说，全功能团队在华为的定义是：能够对特性、部件或者架构完整的实施规划、需求、设计、开发、测试并独立交付、运维的项目型团队。在华为所有产品都在向这个方向发展。从前一个大型产品线所有决策都是一层一层往上升级报告，现在就是往全功能团队发展，产品经理决定全权决定产品做什么，什么时候做，什么时候上线，产品的规划是什么，产品的竞争力在哪里，目标客户群在哪里。团队负责把产品交付出来。

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

管理流程实践

DevCloud现在的管理流程是一周一个迭代。

在做DevOps转型和DevOps微服务之前，产品是三周一个迭代，团队没有采用瀑布，而是采用持续交付。

转型后，发布周期由三周变为一周，一共十个服务，每个服务一周一个迭代，一个迭代发布一次，所有服务不在同一天发布，因此对客户的感知是每天都有新版本上线。每周迭代过程与Scrum类似，但是又不完全一致。因为当一个团队达到持续交付能力的情况下，Scrum的一些流程性工作就变得不是特别重要。产品经理一周之内做两次验收，第一次是在转测环境验收，检查开发内容是否与当时沟通的一样，第二次验收是线上环境验收。另外，关于用户故事点的估算，当团队能达到这样的快速交付的速度后，故事点的故事也不是很必要，因为产品经理很清楚团队吞吐率是多少，比如，团队有十个人，按照历史吞吐率团队一周能做差不多十到十五个story，按照这样的吞吐率做迭代计划就可以了。

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

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

DevOps Handbook整本书其实只有三句话：实施DevOps有三步。

从工程实践来说，刚才介绍的是第一步：从左到右建立价值流。不只是管理流程上建立，还要从技术实践上建立。

实施DevOps的第二步是：从右到左建立快速的持续反馈。由于每个服务都以全功能团队为单位组建，因此每个团队都可以建立自己的持续交付流水线，能够快速获得反馈。

此外，还要建立用户数据反馈。一开始做产品的时候，不需要太多的用户数据，因为客户量非常少，还在验证产品是不是打中客户的刚需，客户离开产品会不会觉得不爽，在很长一段时间之内靠人力就能够获得反馈。比如，几个产品经理一段时间都去客户那办公，坐到客户办公室里，观察客户怎么用产品，有什么问题，白天吐槽，吐槽之后赶紧让团队改。这个阶段不需要数据也是可以的，但是过了这段时间之后，比如产品做大规模的市场拓展，跟很多城市的政府签了合作协议，与很多高校也签了合作协议，同时拓展了大量企业。收到很多吐槽、反馈，这时候没有数据就不行了。

因此，一定在达到这个阶段之前建立用户数据分析系统，从而指导产品决策。如果没有系统指导产品决策，就只能通过客服反馈。如此一来，通过碎片化的反馈，每天需求都像洪水一样涌来，没办法做出高质量的决策。必须通过量化方式指导产品决策，在产品规模化推广之前搭建数据分析系统，如果在之后做会非常痛苦。

DevOps实施的第三步：建立高度信任的持续学习和实验的文化。文化看似虚无缥缈，实则非常重要。实际上文化并不是做DevOps转型就能建立的，文化是这个企业自带的基因，文化是企业创始人个人价值观的放大和延展。每天的工作实际上都在渗透价值观，如果想将文化固化在企业里，必须要在每天工作中得以渗透，否则文化就只能停留在纸面上。

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

DevOps转型策略

华为是如何实施规模化的精益DevOps转型呢？

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

变革大师约翰科特写过一本书《领导变革》，里边介绍了变革八步曲，《DevOps Handbook》里有一章专门讲DevOps转型策略，其实就是将约翰科特的变革八步法应用在了DevOps转型领域。变革八步法可以用在任何组织变革，而且这八步是顺序，不能逆序，也不能跳跃。做转型跟八步法有相似之处，但也不完全一样，如果严格一步步实施这八步法就要花很长的周期，这样做变革满足不了时代对我们的要求，所以转型一定要像做敏捷一样小步快跑。

华为的变革策略是：

• 第一步，把危机感和紧迫感植入组织的血。华为本身就有很强的危机感和紧迫感，需要不断植入，时刻唤醒大家的危机感和紧迫感。每当团队觉得自己做的很好，马上就会有更高的目标要求团队，牵引团队做得更好。
• 第二步，做大规模转型时，发布红头文件，在产品线试点的时候，产品线的最高领导要签署文件，表态团队要做这个事，全员都要配合。如果想推进变革，第一件事情就是要得到最高领导的认可，在华为基本上这一步走到了，后面就能够顺利开展。
• 第三步，自上向下设定能力提升目标。做转型一定要有明确的量化目标牵引，如果没有这样目标的牵引，基本上得不到团队成员的支持，在转型的过程中也要时刻监控量化的结果。

剩下的几步需要迭代进行。

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

作者：王明兰