华为微服务转型DevOps实践

       近年来软件开发领域热点不断，服务化、云计算、大数据、微服务、人工智能、区块链……不胜计数，对应于开发和运维的对象变化，研发模式也在逐步发生演进。

       以华为而言，华为是一家17万员工的ICT企业，开发人员12万，有众多业绩出色、产品丰富、人员众多的产品线，耳熟能详的比如无线、路由器、终端。

在这些组织里，几十人甚至上百人的交付团队比比皆是，所交付的产品经常是大型解决方案，故我们把在这些中大型组织内部推行持续交付的实践，称之为规模化持续交付。

2012年之前，华为内部对于持续集成已经非常普及；

2013年开始随着大规模解决方案和版本化的需要，我们开展了系统的持续交付能力建设；

2014年ICT融合势不可挡，服务化转型驱使华为研发体系开始深入的了解和应用DevOps；

2015年之后，云化、云原生（CloudNative）和微服务这些概念的提出与兴起，华为研发再次针对微服务进行DevOps的一些有益实践。 

规模化持续交付

在这里我们主要讨论规模化持续交付能力建设过程中的几个核心实践：

第一个，节奏小批量快速迭代。华为2007年开始实践敏捷，快速迭代在团队中已经有比较好的基础，

第二个，层分级自动化流水线。这包括几个关键字：分层分级、自动化、流水线，自动化是为了提高效率，流水线流动的是交付价值。

第三个，短单点耗时。华为做了大量的工作，从极速编译，到并发测试，再到基于PaaS的快速部署，都是为了节约关键路径时间。

第四个，自动化持续部署。这是持续交付的核心实践。

第五个，质量防护网。做质量保障的持续交付就是伪命题了，每一级的价值流转必须保证高质量，传递的是价值不是缺陷。

第六个，可视化。过程可视化才能做到掌握和优化，没有度量也就没有优化的空间，所以要做可视化。           

对于规模化的持续交付，从个人提交代码到最后版本生产交付，需要多级流水线的配合。个人提交代码，启动个人级流水线，实现持续集成和单元测试；项目组件集成验证，启动项目级流水线，实现开发测试和集成功能验证；版本集成打包验证，启动版本级流水线，实现版验证和相应的兼容性、性能、专项测试等。每一级流水线都会形成交付物，可以是提交的代码，可以是用于构建的组件二进制包，可以是用于集成打包的可执行二进制包等等。每一级流水线向上一级交付时，都必须实现质量保障，也就是质量门禁的检查，这样才能将缺陷和问题尽早发现，减少解决问题的成本。 

      图上左边的漏斗是应用质量门禁之前的结果，越集成问题越多，总是在最后版本验证中发现大量基础问题；右边的圆锥是应用多级质量门禁之后的结果，大量问题都在底层门禁被拦截和修复，版本集成只会存在少量问题，大大节约了解决问题的代价。

服务化转型促进DevOps

华为从2014年开始逐步进行ICT融合转型，越来越多的业务开始以服务的方式提供给用户（内部的/外部的），这就迫切的需要新的研发流程来适配产品转型，于是内部有团队开始实践DevOps。 

DevOps在不同书本有不同的解释，这里是从华为年报中摘录的华为公司对于DevOps的理解。不论如何定义，DevOps的核心实践都包括主体：PPT（People，Process，Tool），以及三个核心实践：正向交付价值，反向反馈结果，和持续的改进优化。

首先我们的组织开始发生变化，以华为云的软件开发服务团队为例。在组件初期，我们是以项目为单位的，人员分为项目管理、架构、开发、测试、版本、运维等多个组，所有的服务都是统一开发。发现这样效率低下之后，开始进行组织转变，以服务为单位组建全功能团队，内含产品经理、用户设计、开发代表、运营代表、架构师、开发、测试、运维各职能，通常一个人是身兼数职的，当然这对人的能力提出了比较高的要求。最开始的时候，这其中有一个团队最难被拆分，那就是运维团队，因为基础设置自动化能力不足。

从流程上，认真遵循敏捷开发的过程，高速迭代，小步快跑。每一个迭代周期，PD会和SL开发代表确定计划，周一完成需求串讲，周中开发交付，认真履行每日站会进展和问题通报，周末完成迭代回顾和功能演示。下一周进入单元、集成、性能、专项测试过程，实现双周迭代的滚动交付。

工具层面，为了保证正向的价值持续交付，引入了项目管理、开发IDE、编译构建、部署、发布、测试、流水线等众多工具服务；为了保证运营运维质量数据的反馈，引入了监控、分析反馈服务；作为所有的基础，代码托管、软件仓库、云化环境服务，这是必不可少的。

这些所有工具的出现都是为了保证DevOps核心实践中的两个重点，正向价值交付与反向效果反馈。开发人员完成代码提交后，通过单级或者多级流水线，通过工具链将代码承载的价值（就是需求、特性、缺陷修复等），通过流水线的运行，最终实现在生产环境的部署升级。当然流水线只是一个载体，需要代码仓库、编译构建、测试、部署、发布等各个工具的支撑。同理，反向的反馈通道上，现网运行有大量的日志、运维数据、运营数据、用户反馈信息，通过反向通道，就是通过监控工具、反馈工具、VOC信息通道、数据分析平台，返回到研发手里，对我们下一轮的价值交付起到指导和修正的作用。

微服务场景下的DevOps

2014年Martin Fowler与James Lewis共同提出微服务概念，华为从2015年开始有团队在业务中去实践微服务开发，2015到2016年微服务开发在华为内部形成了蓬勃发展的势头。一方面是我们众多产品线、业务线在实践和尝试实践服务化和微服务化转型，另外一方面，华为开始进军云端业务，正式成立了云BU（华为云），催生针对微服务的DevOps能力进一步优化和演进。

在工具层面，我们主要做了两个重要的演化：

一是工具云化。从我们最初实践持续交付的时候，部分工具还是依赖本地化，能够实现服务化的工具已经是比较好的结果，工具基本还是单点、孤岛，使用的可靠性、效率、性能还不能让人满意。进入微服务的时代，微服务（MicroServices）和云原生（CloudNative）是一对相辅相成的概念，应用都要云原生了，那么工具势必要求云化和链化。工具上云、环境上云是我们的一个重要演进。

二是增加针对微服务的设计和创建、管理工具。微服务一般都是通过接口实现外在交互，同步的、异步的，那么在微服务接口设计、依赖设计、框架创建标准化、微服务集中管理方面，工具做了一些有益的支持，提升创建、实现、管理微服务的方便性和效率。

进入了微服务时代，不得不说一下微服务拆分。

这两张图，左边是我们进行微服务拆分之前的状态，服务对外统一呈现，内部通过部件或者组件高度耦合（所以大家都是蓝色的），部件组件之间的信息交互不做规范化定义。结果就是每一次服务的版本发布，所有组件都必须同步发布。这就存在互相牵制的问题，跑得快的组件被跑的慢的组件拖后腿，特性在交付周期不能满足快速增加的用户需求。我们这个时期有个高频词汇，叫版本火车。顾名思义，火车按站停车，定时开车，计划性购票，效率比较稳定但是不够高。之后，我们进行了架构解耦和微服务拆分，右边这张图，不都是蓝色了，五颜六色，每个解耦出来的微服务都规范化接口定义，自己控制节奏，实现独立发布，再也没人拦着了。版本火车不复存在，但是服务快照是可以记录的。特性的交付周期大大缩短，最快的交付实践从代码修改到特性上线只需要1小时。

软件开发服务是华为云的一个部分。大家知道华为云在国内东北、华北、华东、华南都是有运营区域的。每一个微服务的上线，都是要同步的想全国多个区域发布运行实例，这个过程不可能通过手工来完成，对每一个区域的实例进行升级都是通过部署流水线来实现，实现无业务中断的版本实例上线过程。统一实现了特性开关机制，向目标用户推动新功能、新体验，在得到有效反馈、有效测试结果、有效运营数据支持之后才会逐步的将新特性放开，这样在保证用户体验的同时也保证了运营运维的稳定性。

经过上面所提到的众多实践，实现了从最初项目式的持续交付，向服务化的DevOps，以及微服务化条件下的DevOps开发流程的演进，实现了高用户体验、高产品质量、高效率交付、高凝聚力团队建设多个方面的统一。

一个规模化的组织，要想从原有无组织或者弱组织或者简单组织的开发流程中摆脱出来，投入DevOps的怀抱，总结为八个步骤：
      1、迫切感：要看到大趋势，将危机感和紧迫感植入组织血液；

      2、领导力：变革需要高层领导的支持，联合工作组，高层签署文件等；

      3、愿景：要知道变革带来的效果，自顶向下制定效率提升的目标；

      4、沟通：各级领导自上向下沟通、贯彻，包括如何打破部门墙；

      5、授权：各基层组织得到充分授权，What、How、Result；

      6、试点：在重点团队试点能力建设，见效后可以大规模推广；

      7、深入：横向，组织间互相传播和交流；纵向：延伸价值链覆盖的范围；

      8、固化：固化核心能力和优秀实践，形成业务习惯和企业文化。

      总体来说，也可以精简成四点：

      第一，要有坚定的意志，从开始变革到有序再到最终融入企业文化，需要一个长期过程，需要很大的投入；

      其次，在工具要有所投入，不是说买软件，是指为了实现价值正向交付和结果反向反馈，需要投入力量去解决自动化和联调的问题；

      第三，要勇于实践和善于度量，制定有效的优化目标，并不断深入扩大联调覆盖范围，才能逐渐有所收益；

      第四，要乐于分享，企业内部有标杆示范和经验共享的机制和氛围，不断增强企业文化。