交付在云端-全云DevOps实践

自检：核心实践，成效佳？

DevOps是正向价值链，运营反馈是反向价值链，通过不断的度量，实现各方面的提升。在此我们主要关注的是持续交付的交付链。将一个需求变成线上的特性，测试人员在线上测试通过，即完成了正向交付价值。但是实际交付的效果可能并不好，就会造成用户流失，这是非常严重的状况。在正向交付负向反馈的同时，我们要不断地优化自身的能力，重新审视自己交付的能力和流程，是否从一个中等效率团队提升到高效率团队，甚至已经进入到精英团队的范畴，只有这样企业的竞争力才能不断的提升。

如何进行自检？

对于很多产品来说，产品形态还没有达到服务化或者云化的水平，需要用一些理论实践方法去引导他们达到这样一种新的开发能力水平和范围。所以需要有一个基本的引导方式。下图是整个开发的基本过程，列出了正向的交付链，针对每个过程中需要做的事情罗列出它所属的工程领域，例如开发工具或者交付工具、运维、反馈的工具领域，然后规划，以何种方式使用工具。正确的使用可以加快组织流程，用得不对，或者工具存在问题，可能会成为一个阻塞点。下图中红色部分是我们罗列的一部分能力，不是全部的。每个企业有自己软件交付的形式和方式，这里只是举一个例子，抛砖引玉。

观察：研发全云，境清奇？

进行企业DevOps能力自检之后，可能发现很多问题。

决定上云本身就是一个创新性的决定，很多企业对上云都是顾虑重重，为什么？首先，它是一个打破思想枷锁的过程，因为云上一切意味着不确定性、不安全性、不可知、风险，同时意味着大量的机会。在这个过程之中，我们首先要知道用全云端的工具意味着什么。

上图中左边有全云端的沙盘，从需求管理开始，紧接着要做实施和交付，开发、测试服务、构建、发布、部署、监控。后续还有一些基础服务，这些基础服务的实现实际上是为了衬托上层服务，如果没有代码托管、资源自动化、仓库服务，实施DevOps也只能是无水之田。右边是云化或者服务化的能力模型，下面三行是重中之重。大多数人做云化软件交付的时候可能不是云化，而是服务化。第一是自动化管理，管理流程不再有那么多人工过程了。第二是弹性扩展，不管是交付的软件也好，或者使用的工具也好，要有一个自动适应弹性扩展的能力，很方便的依托于现在公有云提供的能力，这种弹性扩展的能力并不难实现。第三要有一个足够的资源池，一般来说，公有云的服务商已经为大家打造了这样的平台，金字塔里面都满足了，可以说是云化服务，已经从服务化上升到云化的交付能力了。

然而实际做云化转型的时候是困难重重的。

从资源的角度来说，一般软件云化有三步：

• 第一是虚拟化，从实体服务器逐步转化成虚拟机。
• 第二是资源池化，有一个大的资源池可以实现动态的分配
• 第三步是自助服务，云端自助服务是能够实现快速运转的条件。

此外还有流程。如果线上发布过程和生产环境之间网络不通，应该怎么做呢？答案是工具并不能解决这个问题，因为这是流程问题。众所周知，华为公司有各种各样的安全红线，在做内部的云化服务化工具链落地实施的时候，最大的工作量集中在如何打破枷锁上，怎么把内网的一段代码或者一段测试用例或者二进制的安全文件快速传递到外网仓库，这一问题花了很长时间。举一个简单的例子，有一个流水线，其他步骤执行只需10分钟，最后会在发布审核的环节整整卡七个小时或者一周。我们做到提前审批到事后追查的能力，是做了最大的公关，等于说这是一个关键阻塞点的破除。一定要注意，当你准备做一个流程或者工具实施的时候，阻塞点不一定来自于技术和工具，很有可能是来自于流程。

部署方面，是否具备独立部署的能力，是否能够合理的使用资源组、容器镜像，类似于这种资源池进行管理的能力，都是限制我们服务的能力。经过很长时间的实践，我们发现很多产品线声称他们已经实现微服务架构，已经实现解耦，但是最后的结果是众多的微服务打包部署上线。这实际上还是要回到源头上去看一下整个服务架构是否做到了解耦，是否做到了微服务所要求的九大特征。

后面是编码问题，现在编码工具非常多，但是实现全云化的时候，实际上是要求我们把一种编码的能力移到云端去做。这件事情想起来很简单，做起来很困难。包括要实现后台运行、运维、测试、调试能力的支持，同时还希望和DevOps工具链打通。

再者是安全性，上云本身是一种思想的变革，没有绝对的安全，只要暴露在公众的眼光下，就有泄露的一天，就有被攻击的可能性。很多用户在使用我们的软件服务的时候，最大的问题是：“我们很关注安全性，请问你们有特别好的解决方案吗？”两条路，第一通过特殊化的定制、阉割、裁减一些本来应该很开放的能力来适应安全性，但是后果也显而易见，关在笼子里面的狮子怎么可能是强壮健康的呢？第二是说服用户，看他是否我的菜。举个典型的例子，我们从来没办法说服华为的海思来使用我们的服务，因为海思在华为内部是绝密。

聚焦：难把工具比仙子

接下来讲一下在企业实行全云化转型过程中面临的问题。下到十人团队，上到千人团队，各种各样的开发模式都有可能存在，怎么去做这样的转型？要先选一个合适的项目类型或者产品类型。这里列了几个基本的工具链的云化水平与其所匹配的软件开发或者项目服务能力的匹配表。

一般来说，我们在最开始只做大规模单体交付时，采用的都是本地化的工具，因为开源、免费，搭建比较方便，运维比较直接。但是当一部分服务已经开始进行混合产品交付的时候，例如华为的消费者云或者一些混合云和开发商混合的产品，里面有一部分是我们自己固定的组件，还有一部分是云端提供的服务接口，这时候就必须要把一些相应的交付能力挪到云端去，这样就实现了部分云化，主要适合混合型的产品。

接下来要把我们的能力全部云化，例如产品研发、测试、部署、构建、发布，都需要云化。

最后，服务变成一种纯Cloud Native，并不是它对本地没有任何要求，而是它所有的能力，包括弹性、各种快速响应，都是依赖云服务商提供的。这样就可以实现移动办公，轻松在家里喝咖啡办公。

实践：小步快跑，收支相宜

我们根据在各产品线转型的经验，第一步一定会选一个标杆产品，这个标杆产品一般来说会是一个服务化产品，或者是一个Cloud Native原生的产品。对架构解耦实现云服务化，对工具实现上云，对运维进行云提升。这是我们选取试点服务的方法或者准则、经验。

选好了一个服务后，就需要按部就班地转型。怎么做？实施敏捷的时候，敏捷有很多实践，要小步快跑，不断地见到成效。在进行迁移的时候也面临同样的问题，因为这本身也是一个项目，不可能一蹴而就，不是阶梯状的陡升。通过不断提升每一步的工具能力，来实现整体交付能力的提升。同时把整个转型工作的风险降到最低。

能力转化就如同是一个金字塔，金字塔尖一般来说是非常不容易达到的境界，金字塔的底端是入门团队需要做的事情。金字塔下面是沙子，第一件事情是打破思想，是我要做这件事情，要上云。这里一般是指上公有云，因为私有云的模式很难达到各种应变能力。

一般来说代码上云，就使很多企业避而远之，因为他们要的是代码的安全性。上图中右边每个层级列了两行，描述做这件事情主要的目的是什么、主要涉及到的工具是什么。代码上云主要的目的就是解放思想，把代码放到云端代码托管服务上来，把资产，例如软件开发的文档、积累的知识放到这里。

第二是管理上云，让我们的软件开发过程更加开放透明。有很多团队每周会发一个电子版进展表格，从一周的频度来说它是开放的，但是每天而言，它仍然是封闭的系统。把管理放到云端，目的是实现更好的开放协作。需求管理工具要有看板、相应的测试管理人员。

前两步实现之后，必然对效率有了要求，这个时候要构建自己在云端交付的能力，一般来说涉及的是构建、部署、流水线和自动化测试，当这些能力达到之后，这一步追求的提质增效的目标基本达成。

金字塔的顶端是开发上云，把所有的工作迁移到云端，目的是探索创新。此处为什么要把IDE迁移到云端？因为在云端可以得到更好的快速获取环境的能力，可以获得更好的协作能力、试错能力。当这些能力叠加在你面前的时候，你会发现在本地创建一个非常好用，但是搭建起来非常复杂的环境，不再有那么大的吸引力了，你会追求开发上云的境界。

下面给大家介绍几个在云化工具链转化过程中比较好的实践：

• 第一个实践，DevOps讲究的就是快速迭代、快速交付。它的主要收益不是为了快速的交付价值，而是为了帮助组织不断的纠正错误。产品经理抱怨交付团队交付效率永远达不到要求，就是因为管理过程中会存在各种各样的问题。所以每周一定要有一个迭代回顾，通过迭代回顾把迭代过程中的问题全部列出来，争取在下一个迭代中去改变一些，通过不断的改变，团队的效率得到提升，冗余的行为被去除。这是快速迭代敏捷开发的实践。

  

• 第二是微服务解耦。下图中左边部分，所有的服务都耦合在一起，虽然每个服务有自己的泳道，但发布的时候必须携手一起发布。例如一个很简单的服务，只有前台和后台，用于查询数据和刷新数据。经常会有前台升级的时候，要求后台跟着一起升级，后面后台升级了之后，前台工作了。这种情况就是解耦不充分造成的。一般来说，如果做得好会有特性开关、合适的导流、灰度测试等等。右边是一个比较好的例子，每个微服务有自己独立的泳道，同时已经实现了自己独立的交付节奏。

  

• 第三是持续交付流水线。这里列了一个流水线的基本流程，下面几点是我们总结出来的比较有意义的实际操作：

  流水线一定要体现出管理理念，流水线分广义和狭义，狭义指操作序列，从开始执行到结束，总体来说只执行的是操作序列一些任务的堆积，不是管理理念的构成。还有一种广义的流水线，从需求进入管道之后，整个管理起来，并且可视化，广义流水线决定了你交付价值的真正速度。

  任务要自动化执行，还要有质量门禁，这并不是华为的独创，实际上在所有业内的云交付公司都采取了这种方式。华为公司提供的质量门禁是基于Task的输入为大家设定的阈值。实际上质量门禁设置的最高境界是提供一个开放的茬口，在这里一切服务都可以作为门禁，它可以是一个手工的步骤，可以是一个服务请求的数据，也可以是一个测试系统的报告等等。这种开放的质量门禁才能够最大限度的体现出管理理念。

  最后一个叫做质量门禁的集中管控，流水线放在个人的手里，执行流水线的同事通常会由于权限过高或者发布压力，把流水线的门禁关掉或者故意设得比较低。一定要从企业或者组织的高度对流水线的门禁有一个较高的要求，这种情况下质量才能得到比较好的保障。

  

• 第四个实践叫做生产环境的自动化。出现了比较重大的质量事故后，当我们去追溯时发现，问题往往是由一两个工程师一个多余的操作造成的。怎么杜绝这个事情？只有自动化。只有没有人参与的过程才是不会犯错误的。在生产环境的自动化保证了高质量向用户交付的基本要求。

  首先，自动化的变更指的是当你决定向云端发布一个新版本的时候，从版本流出一直到线上功能的上线，直到用户可用的过程、审批必须都是自动化的，而不是说有手工环节在里面，只有这样，交付的前置时间才会缩到最短。

  紧接着是灰度发布，任何一个发布对用户都有影响，不一定友好。只有找一部分用户先来试用新的功能，才能降低发布风险。这里有两种，一种是特性，一种是升级的部署。同时还有失败回滚，当部署的新版本发生故障时候，你如何按照精英团队的标准，在一个小时以内把它回滚到健康的版本，保证它的能力。

  

• 第五，用户级灰度发布。我们通常会采用很多种技术，一般是采用流量分配的技术，我们一般会控制流量分配，在这个技术过程中，我们会保证一些用户使用到新版本，这个过程仁者见仁，智者见智，概念非常多，不赘述了。

  

• 第六是生产在线测试。如果是金融系统，涉及到钱，应该有相应的管理成本配置，否则怎么保障线上的系统是正确的？线上系统势必要做测试，任何系统的模拟数据都无法与真实数据相比，哪怕在真实系统只花一分钱，模拟交易量都不能替代它。应该用管理成本设置一个帐户，在里面实际的实现一些线上的支付，只有这样才能保证线上系统是真正可用的。华为线上有非常丰富的测试手段和机制，这里也提到了，告警机制是非常重要的。实现线上测试的目标是什么？第一是保证线上的质量，第二是对用户的承诺，我们交给用户的是一个服务，而不是光盘，这个服务必须是可用的，当它不可用时，要先于用户发现并解决它，这样的服务才是可靠，可信赖的。

  

蔓延：人心所向，大势已成

最后一条是基于组织的。

• 首先要有一个比较好的文化氛围。当组织对DevOps整个理念有高度认同度的时候，实践这样一种过程的改变会比较方便。
• 第二是自动化能力。我们可能机械化的去追求某些行为的自动化，但是必须把自动化这件事情刻到骨子里面去，每写一行代码都要思考能否自动化的机制保障它的成功。
• 第三是共享。在企业内部，很多团队有一些竞争，包括采用不同的理念，例如采用敏捷和采用精益的不同开发方法，分享知识与智慧是企业的宝贵资产。
• 第四，要有一个度量机制。必须要提到的是统计口径，这非常重要，度量应该是基于结果的度量或者基于事实的正向度量。因为我们现在所处的年代是一个飞速变革，发展非常快速的年代，在最近十年内所产生的技术变化可能抵得上过去一百年所产生的技术总量。
• 第五，企业内部要有一个好的培训机制和流程的导向。以华为公司为例，内部有一个比较著名的华为大学，华为创建这个大学的目的，就是为了让所有的员工在繁忙的工作交付的同时，能够有学习和深造自己的机会，同时也是为了把企业所赞同的一些核心价值观和方法向一线团队进行传播。所以会有很多培训班，针对DevOps的现场实践课，让一些从来没有机会去实践DevOps的团队，也有机会通过培训实际的方式参与进来，理解DevOps理念，慢慢地一定会在他所处的产品线或者所处的开发方向上发芽生根，以至于整个企业的氛围都是蒸蒸日上。