很荣幸参加IDCF组织的第6期DevOps案例深度研究，我们小组的分享主题为《牛转乾坤持续运维》，之所以定这样一个主题，是因为我们在讲DevOps的时候往往更多侧重于软件研发的过程，我们希望通过本次案例研究，带给大家更多关于运维的呈现和了解。

相信大家听得比较多的是“运维”、“IT服务”，而“持续运维”算是个新词儿，每个人对这个词都有不同的理解，所以我们首先要理解“持续运维”的定义，并达成共识，然后进而深入研究持续运维要处理好的三个阶段与层次：持续部署、持续运行、持续反馈与改进。

 

一、如何定义“持续运维”

我们不妨将“持续运维”拆开来看，先从运维的角度看其关注的内容与软件开发过程有哪些异同，然后谈谈我们对于“运维的持续”的理解，最后再尝试给出“持续运维”的定义。

1.1 当谈运维时谈些什么？

1.1.1 你眼中的运维

每个人看到的角度不一样，对运维也有不同的印象。在业务人员眼中运维是修电脑、装网线的，没有两把刷子干不了；运维人员认为自己就像救火队员、敢死队员，上游挖的坑，下游来填，妥妥的背锅侠。

运维圈还流行一句话“系统正常是正常的，系统不正常是不正常的”，怎么理解呢？就是说系统不正常也是一种正常，就像一个人不可能不生病，关键是我们如何去面对和治疗。延伸到系统，关键就在于我们如何发现和面对故障，改进才是最需要的，敢于面对失败，从中吸取教训，这也是DevOps提倡的。

1.1.2 运维的产生

先有IT建设，由于管理学上的专业化分工，专业的人做专业的事，运维逐渐从建设团队中独立出来成为单独的一拨人，形成运维部门。对于一些甲方单位，大部分需要外部IT部门进行建设，逐渐形成了甲方的IT部门，而这个部门主要承担的就是建设+运维的管理功能，具体的事务性工作由承建单位负责。

运维和开发是同样重要的，一个负责生，一个负责养，缺一不可，并不是说开发部署完就万事大吉了。

传统的项目一般是交付以后就进入运维期，运维主要是保证建设的内容能够持续地提供价值。现在很多互联网类的产品型公司，在某个业务领域进行产品型的迭代升级，运维也是一样，保证所有建设的内容都能够不衰减。

如上图所示，IT建设里不只是有软件研发，还有基础设施建设。IT建设是从0-1的过程，IT运维是保障1-∞的过程，运维可以根据建设的目的让建设的内容起到预想的作用。

1.1.3 IT建设内容 → IT运维资产 → IT服务资产

IT建设内容包括系统软件（机房）、环境动力硬件设备、操作系统、虚拟机、软件支撑系统等；到终端和用户这块，还包括各种灾备环境。到互联网时代用了云环境，很多工作可能就交给云服务商来做。

IT建设的目的是什么呢？当然是为了使用，而且希望能好用，于是我们建设的内容就成了需要IT运维去维护的资产。

上图列出了不少软件开发人员平时可能不太关注的CI（在运维中，CI是指配置项）。他们一般是由基础设施团队、集成团队来实施安装的。正所谓：千里之堤溃于蝼蚁，这些基础设施就如同大厦的地基一样，地基牢固了，才能建更高的楼。

再提升一个高度来看，这些内容可以作为IT服务资产，通过与人员、流程、工具等的整合，共同作为一种服务能力，保障业务的连续性。

1.1.4 运维的发展

IT技术的发展日新月异，从基础架构、运维方式及软件架构方面都有了飞跃式的发展，不能说哪个好哪个不好，每个发展都是适应了时代的需求。

一方面开发的技术和管理方法在发展。逐渐从瀑布到迭代敏捷型的开发，还有MVP等理论推动的精益创业这样先进的管理方法得以采用。

我们可以看到运维经历了从单一技术到服务管理的发展，从原来被动救火到主动通过人工智能手段提高解决问题的能力，工具也从传统的手工为主到现在的自动化智能化数字化，运维工作更高效有力，运维人员更轻松，运维部门也慢慢从成本中心向盈利中心转变。

原来的管理只需要管好单机、机房，现在要管理的是分布式、云架构等复杂多态的环境，为顺应这种变化，运维管理的方法论也在不断地升级。多种方法论的融合与实用，给运维部门提出了挑战和参考。

管理办法的发展脉络：

• 第一次IT故障：1968年圣诞节，阿波罗8号正在执行环绕月球飞行任务，三个宇航员中的罗威尔无意中触动P01键，导致所有导航数据将清零，系统即将崩溃。软件部临时任命玛格丽特.汉密尔顿为组长，她带领一支20人的小分队前去“灭火”。之前编写的程序派上了用处，连续奋战9小时后，错误信息被纠正，系统恢复运行。这是一次大的故障，也正是因为这次故障，运维被提上日程。

• ITIL概念出现于上世纪80年代，当时英国政府认为向他们提供的IT服务质量水平不够。由中央计算机和电信局（Central Computer and Telecommunications Agency，简称CCTA），现称为政府商业办公室开发一个IT服务框架，以在英国政府和私营部门内高效经济地使用IT资源。（ITSM：技术管理：技术是根本，技术是管理手段，更是管理的对象。）这是ITIL V1的发布。

• ITIL V2：用流程驱动人、用过程管理结果。

• ITIL V3：生命周期、持续改进。结合了COBIT等思想。

• ITIL 4：服务价值系统，结合了DevOps、敏捷精益等思想。

• 2003年，Google成立了Google SRE小组，是其内部运维的实践。

• 2009年，DevOps理念产生，至2015年11月发展成为一种文化、运动或实践，它强调软件开发人员和其他信息技术人员的协作和沟通，同时强调自动化软件交付和基础设施变更的过程。现在DevOps越来越庞大和宏观，从开发运维延伸到整个开发的全流程，包括业务、开发、安全、测试、运维等各个环节的协作。

1.1.5 ITIL-ITSM的最佳实践

说到IT服务管理，不能不提ITSM的最佳实践——ITIL。

ITIL V3是2007年发布的，吸收了V2的精华，从服务的生命周期看整个IT组织需要做的内容，包括26个流程和4个职能。原来的运维更多局限于被动操作，ITIL V3定义了运维需要更早地进入业务。

• 服务战略：可以认为是从甲方的视角看，首先有一个业务战略需求制定，然后有自己的IT需求管理，同时做服务组合，比如要做哪些业务类的事情、需要哪些IT支撑。服务战略是从业务战略到IT战略的转换。

• 服务设计和转换：首先是各种前期管理，然后是对运维环境进行容量连续性考虑，同时需要做从开发到运维的知识管理，如何交接、如何做激励方案，再之后还有发布和变更的管理。

• 服务运营：包括监控和运行中的问题如何处理、如何解决，如何从根本上杜绝这一类故障。

• 持续服务改进：即如何改进整个IT服务质量，主要包括两大块：服务测量和服务报告。这里引进了七步改进法，现在的情况是什么样的？如何改进？通过哪些数据去度量？

前文介绍过，这一方法论的提出者是英国政府商务部，它是一个甲方部门，更多是从甲方的交付考虑问题，比如在服务设计里有供应商管理，包括如何与供应商协作、整个过程设计和转化的时候需要考虑容量连续性等。

ITIL V4 结合了数字化转型等理念，从价值体系的角度出发进行阐述，并把ITIL V3的流程整合到34个实践中，主要包括以下5个维度：

• 创建、交付与支持

• 驱动利益相关者价值

• 高速IT

• 指导、计划与改进

• 数字化与IT战略

1.1.6 服务与产品的特性对比

在学习DevOps时，不知道大家是否关注过一个问题：开发和运维在工作时，解决问题的方法、工具都有很大的差别。即使使用同样的工具，其用法也可能存在差异。开发更多面向产品，要保证产品是否被人所需要，是不是符合质量要求，主要是对事；而运维更多是要将产品或者服务提供给人，主要是对人。

我们要把运维做好，决不能单单从产品的角度考虑问题，更应该注重服务的特点。想想海底捞为什么大家愿意为它买单，应该不只是其产品做得好，很重要的一点是它提供了优质的服务体验。

（服务与产品的特性对比）

从上表的对比中我们可以看出，服务是无形的，在服务里生产和消费是同步的，服务的过程管理更难度量和评价，而运维就是一个提供服务的过程。

1.2 当谈持续时谈些什么？

1.2.1 什么是持续运维？

说到持续，大家可能会想到持续集成、持续部署，我们不妨将视野放大一些，看看其它可持续发展目标，比如联合国制定了17个全球发展目标。

扯远了，说回到持续运维，其实很难和上图进行类比联想，毕竟我们认为的运维就是保证系统运行不出事就行了，而不是一个阶段一个阶段去提升，就像提升人类的物质精神文明。

我们来看从DevOps知识体系如何定义持续运维。

（图片来源：EXIN DevOps 白皮书 – 企业DevOps的成功之路）

如图所示，DevOps知识体系包括几个过程：敏捷管理、持续交付、IT服务管理，共同保证业务联系性。由此我们可以知道持续运维不是目标，而是一种手段。

说到这里似乎还不能得出持续运维的定义，我们换个角度，试着通过是与否的问题来找答案。运维不是什么？运维绝对不是杀鸡取卵、竭泽而渔，而是希望能够未雨绸缪、防患于未然，就是要更早地处理问题，让隐患没有机会发生。

我们查找了CI/CD/CT的定义：

工厂里的装配线以快速、自动化、可重复的方式从原材料生产出消费品。同样，软件交付管道以快速、自动化和可重复的方式从源代码生成发布版本。如何完成这项工作的总体设计称为“持续交付”（CD）。启动装配线的过程称为“持续集成”（CI）。确保质量的过程称为“持续测试”（CT），将最终产品提供给用户的过程称为“持续部署”。一些专家让这一切简单、顺畅、高效地运行，这些人被称为运维开发DevOps践行者。

至此，我们尝试给持续运维（CO）下一个定义：

为提升业务持续发展，对IT服务管理的总体设计，称为“持续运维”。

（内容来源：《什么是 CI/CD？ (持续集成/持续交付)》https://blog.csdn.net/guofangsky/article/details/89684857）

1.2.2 持续运维的三个层次

我们认为应该以服务为中心，开发整个运维的活动。运维作为服务最终用户的第一责任人，承担起把价值源源不断地交付给客户的任务。

因此我们定义了如下三个持续运维的层次：

• 作为与开发的接口，能够不断地转换新的服务到最终用户。——持续发布；

• 能够让最终用户满意地使用提供的服务、功能和功效。——持续运行；

• 需要建立业务开发的主动连接，能够根据运行中的反馈，持续反馈给整个服务组织，并进行持续改进。——持续反馈与改进。

 

 

二、持续部署

2.1 持续部署定义

从上图我们可以看出软件研发的几个阶段分别是持续集成、持续交付和持续部署， 持续部署是持续交付的下一步或者说更高阶段，指的是代码通过评审以后（或者是通过自动化测试以后）自动部署到生产环境。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。 

2.2 持续部署反模式

我们在实践持续部署的时候，会遇到很多反模式的存在，介绍两个典型的持续部署反模式：手工部署软件、开发完成后才向类生产环境部署。

2.2.1 手工部署软件

通常我们会有一份很详尽的文档，类似葵花宝典，然后通过人工验证、手工部署环境，然后烧香祈祷，而结果往往是不得不回滚，或遇到不可预见的问题。

2.2.2 开发完成后才向类生产环境部署

研发阶段开发一往无前，上类生产前一时刻将特性交接给运维人员，开发人员以为就是个小特性，不会出问题，正常下班后回家，而运维人员拿到变更需求，一脸懵，安装程序和配置文件不匹配，数据库没有回退脚本，部署文档少写了依赖，一连串的问题，导致无法正常上线。从此友谊的小船翻了~

2.3 持续部署中的重大问题

在很多优秀的企业中，从部署到生产环境都遇到很多问题。

• 第一个案例来自著名的代码资源托管平台GitLab，2017年2月1日，GitLab的一位工程师在维护数据时不慎删除约300GB的数据，当天凌晨，肇事系统管理员彻夜加班工作，当他疲倦不堪地进行数据库维护时，不慎用rm -rf命令对300GB生产环境数据执行了删除操作，当他清醒过来按下ctrl + c来停止删除操作时，却只挽留了4.5G的数据，其余所有数据消失殆尽。

• 第二个案例来自英国的TSB银行，数据大规模迁移至新的软件平台，造成了数周的大规模中断，激怒了该银行的500万客户，最终导致其首席执行官辞职。

• 最后一个案例来自谷歌公司，2020年12月14日晚间，Google服务器又一次全球宕机。这是近5个月来第3次全球宕机。Google旗下的YouTube、Gmail、Google Drive、Google Search等服务出现死机，用户无法正常使用，全球多个国家及地区用户均受到影响。Google随后发推文确认，由于内部存储配额问题，Google身份验证系统中断。

这三个血淋淋的案例带给我们的警示，代码诚可贵，特性价更高，若引生产倒，两者都不要~

2.4 如何做到持续部署 

为什么总是临门一脚却射不中呢？如何才能做到持续部署？我认为有三个方向可以努力：

• 更快速的交付，可以通过制品内容标准化，生产过程清晰化，上线过程轻量化来实现，也就是配置管理；

• 更安全的交付，通过代码安全、过程安全、制品安全和环境安全等安全管理手段实现；

• 更频繁的交付，意味着变更要流程化，工具要自动化，过程要可视化，也就是变更管理，通过配置管理、安全管理和变更管理，实现效率、安全、性能的目标，打通持续交付到持续部署的最后一公里。

2.4.1 配置管理

配置管理是指将所有与项目相关的产物，及它们之间的关系都被唯一定义、修改、存储和检索的过程。

它包括四个方面的工作：版本控制、依赖控制、软件管理和环境配置。

1）版本控制

也就是团队在写作开发代码的情况下，记录下代码每一次变更情况。这里以Git为例，要对所有的内容进行版本控制（源码、测试代码、构建脚本、部署脚本、数据库脚本），坚持频繁地提交代码到主干，并使用意义明显的提交注释。

2）依赖控制

就是记录应用依赖的二方、三方包，并进行管理，包括maven\npm\pip\gradle都是不同语言的依赖管理工具，在依赖管理中要做到在编译阶段创建二进制部署包，并上传到制品库；保证一致性，要按照GAV三元组（groupId/artifactId/version）唯一标识和引用一个对象；制品库可以按用途分为临时制品库和正式制品库。

3）软件管理

指配置中心化，配置与应用隔离，统一管理，优雅地解决了配置的动态变更、权限管理、持久化等问题。

软件配置有三种实现方式，分别是打包时注入、部署时注入和运行时拉取。

• 打包时注入是在打包的时候，构建脚本可以将配置信息与二进制文件一起注入到部署包中，通过不同的制品包部署到不同的环境上，这种模式的场景是在少量静态配置文件，或者配置每次随二进制程序变更；优点是打包和部署的过程比较简单，不同环境使用特定的部署包；缺点是环境、应用、配置紧耦合，灵活性低。

• 部署时注入是在进行部署时，部署脚本获取基础配置以及不同环境特定的配置项，动态生成每个环境所需的配置信息。相当于基于配置模板文件，在部署时再实例化为将要部署应用的具体环境的配置。这种模式的场景是大量的配置项，一些配置项在不同环境中存在差异；优点是可以使用部署脚本或工具，动态生成特定环境配置信息；缺点是需要维护应用与配置版本的匹配关系，增加了复杂度。

• 运行时拉取就是在应用启动或运行时，通过外部的配置服务拉取应用配置（如通过REST风格的接口）。现在很多使用容器部署的微服务架构系统，配置中心或配置服务都是其非常核心的组件之一。这种模式的场景是频繁变更配置项，或者需要动态加载应用配置；优点是部署包与配置彻底解耦，具备较高的灵活性；缺点是需要考虑配置中心的高可用性和配置变更的原子性。

(内容来源：张乐老师 https://blog.csdn.net/weixin_34228387/article/details/90583469)

（图片来源：QCon北京2017）

这两位老哥 1984 年在 IEEE 上发表了一篇论文，论文的题目就是《分布式系统的动态配置》。当时他们对分布式系统的理解可能还没有达到今天这个层次，他们可能也想象不到分布式系统后来发展到今天这么庞大，这么复杂。但他们对动态配置这个领域的问题看得比较清楚，就是在一个大型的分布式系统中，你没有办法把整个分布式系统停下来，去做一个软件、硬件或者系统的升级。 

接下来介绍几个阿里的实践案例。

（图片来源：QCon北京2017）

我们知道，当你的系统同时涌进来超过一亿人并发访问的时候，这个系统一定是扛不住的，一定会挂掉，在这个过程中我们讲大促有 3 大法宝：弹性、限流、降级。系统的限流和降级本质上来讲就是从日常的运行态切换到大促态的一个行为的动态调整，这个本身天然就是配置起到作用的一个相应的场景。

随着大促时间点的临近，这些分布式系统中，每个子系统会有大大小小的预案，这些预案其实都是以配置的形式存在的。配置中心会在这个时间轴上，定时地安排执行预案，每个系统哪些功能降级，在什么时候降级，什么时候开放哪些专门为大促存在的一些功能，在大促之前的时间点，整个应用发布会封盘，被禁止掉了，已经不允许做任何线上发布了，那在这个时候要切换系统的行为，就是靠配置中心发挥作用。

（图片来源：QCon北京2017）

最早淘宝配置中心产生的原因之一就是要解决大规模数据容灾的问题。

一般来说，为了高可用，业务可能部署在 2 个机房，现在一般同城双机房是标配。数据存储，比如像 MySQL，在生产上为了高可用，可能会配备一主几备，主库是可写的，备库可能是只读的。在生产上可能有几台机器坏了或者甚至一个机房坏了，出问题、故障了，基础设置（infrastructure）这块可能有一些事件冒泡到软件平台 PaaS 这一层，这个事件冒泡一般会到 DBA 团队的一些数据库高可用基础设施，DBA 会根据整个业务系统在机房的部署拓扑，找到这个坏掉的机房里的所有的主库，做一个主备库的切换，把备库切成可写。

在这个过程中，配置中心的作用就是跟 DBA 的高可用切换工具保持联动，DBA 工具负责数据库切换，产生数据源配置变更，所有应用基于配置中心监听各自的数据源配置变更，当产生主备库切换，配置中心会将数据源配置变更推送到应用，整个过程对应用是透明无感知的。

（图片来源：QCon北京2017）

现在一些大型的互联网系统，CDN 后面会有一个统一接入层，包括 PC 和移动端的流量可能都是从这个统一接入层进入到生产的机房。在这个过程中，统一接入层负责根据前端用户的属性，去分配用户的流量到后端不同的单元。当一个单元挂了之后，这些流量需要无缝地切到其它的业务单元里去，这个单元糅合了机房及业务域的一些划分，在这个过程中，配置中心要起到一个关键的作用：在统一接入的机器上，让它们对于全局的流量规则达成一个分布式共识，这实际上是分布式一致性的要求。

4）环境配置CMDB

我们运维的对象分两大类：一类是基础设施，包括机房、机架、服务器、网络设备、安全设备等；另一类是构建在基础设施之上的服务，包括应用程序、中间件、域名等等。

上图详细介绍了运维所面临的资源模型，包括基础属性、配置属性、运行状态、关联关系等。

环境配置的实现方式有两种：Agent 方式和ssh类。

Agent 方式

Agent 方式其本质上就是在各个服务器上执行subprocess.getoutput()命令，将每台机器上执行的结果通过request模块返回给主机API，主机API收到这些数据后放入到数据库中，然后通过web界面将数据展现给用户。

• 场景：服务器比较多。

• 优点：速度快。

• 缺点：需要为每一台服务器部署一个Agent 程序。

ssh类

CMDB管理员录入资产后，API从数据库中获取到未采集的机器列表，发送到中控机服务器中，中控机服务器通过paramiko模块登录到服务器上进行信息的采集，服务器采集完后再将结果返回给中控机，然后将从服务器中得到的信息通过 request模块发送给API，API通过主机名和SN作为唯一标识，将信息录入到数据中，再通过web界面将数据展现给用户。

• 场景：服务器较少。

• 缺点：依赖于网络，速度慢。

• 优点：没有Agent，不需要为每一台服务器部署一个Agent 程序。

介绍一个腾讯的实践案例。

腾讯的蓝鲸配置平台（CC）是一款面向应用的 CMDB，在 ITIL 体系里，配置管理数据库（CMDB）是构建其它流程的基础，配置平台做为面向业务层面的 CMDB，为蓝鲸体系的其它平台提供了各类运维场景的配置数据服务，存储与管理企业 IT 架构中设备的各类配置信息，它与全部服务支持和服务交付流程都紧密相联，支持这些流程的运转、发挥配置信息的价值，同时依赖于相关流程保证数据的准确性。

它将整个环境配置分成了四层：

• 资源层（store）。提供系统所需的资源存储、消息队列以及缓存系统服务。

• 服务层(service layer)。服务层划分为两大模块：资源管理模块，在配置平台中把资源类型进行了抽象，目前划分为主机、进程、通用对象三大类，支持横向扩展，每一类资源由一类微服务进程来管理；业务场景模块， 业务场景模块是基于资源管理模块的原子接口对应用场景的封装，基于操作的相关度，目前划分出admin、event、host、topo、process、datacollection几个微服务。

• 接口层(api)。这一层是系统的API服务网关。

• web层(web)。web层是系统提供的web服务。通过配置平台提供的web服务界面，用户可以进行资源的操作。

2.4.2 安全管理

1）安全现状

去年GitLab发起关于安全的年度调查，有29%的调查人员反馈安全和大家息息相关，那安全场景下的运维模式是怎样的呢？

（图片来源：GitLab 于 2020 年 1 月至 2 月 29 日对全球 21 个国家的 3650 多名软件专业人士进行了调查）

DevSecOps是DevOps的另一种实践，它将信息技术安全性作为软件开发所有阶段的一个基本点。安全性不仅涉及各种层次的隔离和合规性检查，还涉及从技术层面确保业务连续性。

（图片来源：DevSecOps（Development Security Operations））

2）DevSecOps

DevSecOps由 Gartner 咨询公司研究员 David Cearley 在 2012 年首次提出，它是一种糅合了开发、安全及运营理念的全新安全管理模式。

DevSecOps九大实践要素，其中“黄带”代表如何应对常见威胁来维护客户与品牌，“绿带”代表软件、网络、系统管理员、数据库管理员。其中的安全意识、团队工作协议、同业人员评审和安全评估均在强调企业组织对于DevSecOps的接受程度，以及整个企业文化中的安全意识，是影响DevSecOps实践的重要因素。技术能让安全融入DevOps过程，但人、流程以及文化才能推动DevSecOps常态化。

（图片来源：https://www.secrss.com/articles/13306）

DevSecOps实施难点：

• 安全性被认为是DevOps灵活性的一种阻碍。

• 企业安全意识缺乏。

• 开发和运营人员安全技能不足。

• 业务流程与安全工具的对接困难。

看一个小米的实践案例。

小米通过组织层面成立安全 BP 工作组，来强化安全团队和业务团队的沟通。基于安全 BP，让安全更加深入到业务中，更了解业务的流程和制定对应的安全方案，让业务真正感受到安全在帮助业务。

• 在指标和考核上，他们会关注漏洞按时修复率。为不同风险等级漏洞定义不同的修复周期，当漏洞出现需要对应工程师在修复周期内完成修复，而不是用漏洞数量等指标来考核，希望能够和业务站在一起，有助于提升安全意识和能力。

• 在安全意识宣传和安全培训方面，他们也做了很多工作，不仅有面向全体员工的基础培训，而且还有针对不同业务或不同角色的专项培训。

• 在技术上，他们为业务提供了多种自动化的系统或工具、安全 SDK，还会和业务的流程结合起来，让安全融入到业务流程中，同时避免人工过度参与阻碍业务流程。

2.4.3 变更管理

变更不仅仅是狭义的上线新版本代码，也应该包含配置变更、数据变更、操作系统变更、网络变更、基础设施变更等方面。变更是运维人员的主要工作内容，同时也是导致服务故障的主要原因。

据 Google SRE 统计，线上 70%的故障都是由某种变更而触发的。变更与所有运维人员是紧密相关的，运维背的所有锅也都与此有关。

为什么要做变更管理？因为要控制影响，包括范围、进度、成本、质量、风险、资源等，一般项目管理系统中都包括项目管理信息系统、配置管理系统，以及最重要的变更管理系统。

变更管理系统一般包括范围变更、进度变更、成本变更、合同变更等控制系统，同时还会成立一个专门的变更控制委员会。

• 范围变更控制系统定义项目范围变更的有关流程。它包括必要的书面文件（如变更申请单）、跟踪系统和授权变更的批准等级。

• 进度变更控制系统规定项目进度变更所应遵循的手续，包括书面申请、追踪系统以及核准变更的审批级别。

• 成本变更控制系统是一种项目成本控制的程序性方法，主要通过建立项目成本变更控制体系，对项目成本进行控制。该系统主要包括三个部分：成本变更申请、批准成本变更申请和变更项目成本预算。

• 合同变更控制系统包括四个组成部分：文书工作、跟踪系统、争议解决程序、审批层次。

• 变更控制委员会（Change Control Board, CCB）组成：项目双方项目管理人员（部门领导、高层经理、项目经理）、技术人员（开发人员、测试负责人、质量保证负责人QA）、商务人员。其主要工作：负责评估那些被提交上来的变更请求，针对这些变更的目的、要求和影响来决策：同意实施一项变更请求，并且在会议上安排相关的变更实施负责人和相关联的协作组织；拒绝某一项变更请求，给出拒绝理由。

（图片来源：https://www.ffeeii.com/1793.html）

看一个唯品会的实践案例。

唯品会提出了风险矩阵，他们做了一个SDK，这个矩阵用一句话形容就是“把原有的变更风险从对象和技术风险两个维度进行了拆分。”

（图片来源：王俊峰在GOPS全球运维大会2018深圳站演讲）

对象是指一个业务系统，可能是核心系统，也可能是重要系统，也可能是不重要的系统，可以对它进行画像和打分。这两者结合在一起，可以对所有变更有一个精准的打分。

标准变更模版库是指专家针对每个组件进行变更模板设计，组件基于专家设计的模板进行变更，不可天马行空地想变更方案。

关于生态打通方面，一开始的思路是比较宏大的，原来想的是设计一个完美的流程，把相关生态完全打通，后面发现很难把运维相关的工具体系打通。唯品会的思路是逐步实现这种能力，比如ABCD系统之间，先打通AB，然后打通CD，从而建设了非常灵活的自动化变更系统。

但这也是一把双刃剑，可能导致DevOps变更失控，变更流程得不到严格遵守，风险评估不准确，效率降低流程冲突、变更的质量控制也变得比较困难等问题。

真正要实现的变更打通设计思路：

• 首先，流程系统提供SDK给各自动化工具，提供变更的管控能力、变更的收集能力和SDK的自治能力；

• 第二，自动化能力平台，梳理变更风险矩阵集成SDK，上报变更风险矩阵；

• 第三，执行变更时，传入变更内容，SDK根据有效的规则配置进行计算，判定变更是否可以执行，审批结果的回调接口，对于部分变更可能会有后台流程配合。

（图片来源：王俊峰在GOPS全球运维大会2018深圳站演讲）

上图是唯品会的整体架构，中间是一个标准模版库，技术专家组设计了一套标准变更，SDK跟左边的关联是从负载均衡管理平台、定时任务管理平台、云平台、运维平台以及打通这些平台给开发人员赋能。

现在开发人员如果想做简单的线上业务配置，只需要在tools平台上提交一个申请，中央管控认为风险非常低就可以直接做完了。这一架构带来的收益也很明显：固话标准变更，简化流程，有效控制变更风险，同时赋能开发，提高效率。

2.5 最后一公里

在实现持续交付到持续部署的最后一公里时，

• 通过配置管理，实现制品内容标准化、生产过程清晰化、上线过程轻量化，让持续部署更快！

• 通过安全管理，实现代码安全、过程安全、制品安全、环境安全，让持续部署更安全！

• 通过变更管理，实现变更流程化、工具自动化、过程可视化，让持续部署更频繁！

 

三、持续运行

业务服务上线后就交给了运维，运维需要保障系统和服务健康成长，为社会创造价值，这就是持续运行。

3.1 SRE

为确保服务持续运行，即提高服务的可靠性，我们借鉴了谷歌提出的SRE工程体系。接下来展开介绍Mikey金字塔的可靠性层次结构。

 

 

Mikey七层金字塔围绕着沟通设计，每一层都建立在前一层的基础之上。它被沟通所包围，因为每一层都需要沟通才能成功。

• 第一层是监控。确保洞察系统、跟踪系统的健康状态、可用性，以及系统内部发生的事情。

• 第二层是事故响应。如果出现故障，该如何提醒大家并做出回应？

• 第三层是事后回顾。一旦发生服务中断，如何确保问题不会再次发生？

• 第四层是测试和发布软件。这个层级是Mikey金字塔中第一个专注于预防而不是事后处理的层级。预防是指尝试限制发生的事故数量，并确保在发布新代码时基础架构和服务能够保持稳定。

• 第五层是容量规划。这是关于预测未来和发现系统极限的。容量规划也是为了确保系统可以随着时间的推移得到完善和增强。

• 第六层是开发新工具和服务。SRE不仅涉及运维，还涉及软件开发，希望SRE工程师将花费大约一半的时间来开发新的工具和服务。我们知道对运维而言，尤其是在分布系统里，要做到高可用和高可靠，需要实现系统自动化，而自动化不能仅仅只靠开发人员和软件架构来实现，还需要运维能够有自主开发代码和工具的能力。

• 最后一层是用户体验，即确保用户获得良好的体验。

3.1.1 监控

监控是持续运行的基石。打个比方，我们一般都会通过体检采集各项身体指标来判断一个人是否健康，同样，对于部署到生产的应用系统，需要通过监控采集相关运行数据，判断系统是否处于正常健康的运行状态。

监控的目的一般分为两类：体检、急诊。

• 体检包括对系统进行容量和性能管理。容器管理，提供一个全局的系统运行时数据的展示，可以让工程师团队知道是否需要增加机器或其他资源。性能管理，可以通过查看大盘，找到系统瓶颈，并有针对性地优化系统和相应代码。

• 急诊包括对系统存在的问题进行定位和性能分析。定位问题，可以快速暴露并找到问题的发生点，帮助技术人员诊断问题；性能分析，当出现非预期的流量提升时，可以快速找到系统的瓶颈，帮助开发人员深入代码，找到并快速修复异常。

要实现对应用的可观测性和监控能力，需要采集和分析三个部分的数据：指标、应用跟踪、日志。

• 指标包括系统监控（USE）、应用监控（RED），通过系统的使用率、饱和度和错误数，应用的请求数、错误率和响应时间，看当前系统和应用，包括操作系统、中间件等，运行是否正常，是否存在瓶颈或异常。

• 应用跟踪包括应用进程的资源使用情况、程序之间的调用情况、程序内部核心逻辑的运行情况等，比如进程占用的 CPU、内存、磁盘 I/O、网络等，使用过多的系统资源，导致应用程序响应缓慢或者错误数升高，是一个最常见的性能问题；程序间调用的频率、错误数、延时等，由于应用程序并不是孤立的，如果其依赖的其他应用出现了性能问题，应用自身性能也会受到影响。还包括关键环节的耗时、执行过程中的错误等，由于这是应用程序内部的状态，从外部通常无法直接获取到详细的性能数据，更需要在应用内部进行埋点把逻辑执行的情况暴露出来。

• 日志包括流水日志和应用日志。流水日志一般就是整个交易的情况，通过对不同维度指标的聚合，可以对整个系统和业务的运行情况进行多维和下钻分析，当出现异常时，还可以进行具体的业务影响分析；应用日志记录业务或应用系统的运行情况，包括暴露的错误等，可以进行模糊查询，出现异常时，能够根据日志快速定位故障点。

再来看监控体系。

• 最下层是基础监控设施，包括基础服务、网络、机房。

• 往上一层是系统应用监控，包括进程、容量、性能等。

• 再往上是服务端和客户端业务监控，包括业务指标、端监控。

• 最上面是用户反馈系统，比如当前是否有大量客户投诉，是否存在舆情。

整个监控体系从上往下，上层是业务监控，下层是基础监控，根据经验统计，90%的基础监控发现约30%的问题，10%的业务监控发现约70%的问题。阿里的监控指标：1分钟发现问题，5分钟定位问题，10分钟恢复服务。

上图展示了如何利用开源工具和产品实现应用可观测性。

• 日志主要用ElasticSearch框架来做。Filebeat采集后通过Kafka传入LogStash里去做聚合和解析，然后放到ES里进行存储，并通过Kibana展示。

• 对于指标数据，现在比较流行的是用Prometheus或Jenkins来进行系统/应用基本指标数据采集。

• 对于跟踪数据，用Skywalking部署一个agent，对内部调用情况进行采集。

前面介绍了这么多监控到的数据维度，最终如何衡量一个系统是否稳定呢？以前是通过用异常时间除以总体时间得出一个值，比如4个9或5个9，也就是常说的SLO。现在来看以时间作为指标，粒度比较粗，不便于统计，比如一段时间之内发现了一些偶发性的错误，这个时间段到底算不算已经出现异常或故障的时间？

比较理想的指标是请求成功率。比如一个API被调用1万次，成功了9999次，可以认为它的SLO值是4个9，这样粒度更细也更精准。还可以根据SLO制定错误预算，即一个周期内（如4周）如果超过错误预算将不允许增加新功能，说明系统不稳定，应该优先解决生产问题，避免雪上加霜。

监控的目的是将问题通过告警的方式暴露出来。我们通过采集日志、指标等信息，并对每个信息设置阈值或关键字生成告警，告警的信息量很大，CPU、内存、关键字等每个点都是一个监控的风险点，并不是每个风险点暴露出来都是故障或问题，需要对告警信息进行分析和压缩，最后通知到工作人员对告警的问题进行处理和修复。

3.1.2 事故响应

收到告警即代表这时可能已经出现问题，我们需要对整个事故进行响应。

（图片来源：赵成《SRE实战手册》）

在SRE里，将整个运行周期分为两大部分，MTBF、MTTR。

• MTBF：Mean Time Between Failure，平均故障时间间隔，表示系统正常运行。

• MTTR：Mean Time To Repair， 故障平均修复时间，表示系统发生故障。

我们的目标是提升MTBF，降低MTTR。

MTTR可以进行流的拆分：

• MTTI：Mean Time To Identify，平均故障发现时间。

• MTTK：Mean Time To Know， 平均故障认知时间。

• MTTF：Mean Time To Fix，平均故障解决时间

• MTTV：Mean Time To Verify，平均故障修复验证时间。

理想状态是发生即发现，发现即定位，定位即恢复。

典型的故障排查过程：

• 最开始我们通过各式各样的预设报警发现异常（通常是Metrics/Logging） 。

• 发现异常后，打开监控大盘查找异常的曲线，并通过各种查询/统计找到异常的模块（Metrics）。 

• 对这个模块以及关联的日志进行查询/统计分析，找到核心的报错信息（Logging）。 

• 最后通过详细的调用链数据定位到引起问题的代码（Tracing）。

（图片来源：Grafana Loki）

上图展示的是排查思路，首先有告警，然后看大盘上显示哪个地方可能有红色报警点或曲线异常，针对异常曲线和报警点查询具体报错日志，再根据追踪深入代码，最后修复问题。当然这是一个比较理想的状态。

上图所示为整个事故的响应流程。通过舆情感知、监控告警、AIOps对海量数据进行异常检测发现故障；利用日志分析、链路跟踪、根因定位进行故障定位；采用容灾切换、服务降级、限流、熔断、重启扩容等手段，快速进行故障恢复；通过故障复盘、改进验收、故障模拟、混沌工程、容量压测等实现故障改进。

3.1.3 事后回顾

我们需要借助事后回顾来发现、解决、规避风险。经典的复盘黄金三问：

• 第一问：故障原因有哪些？

• 第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？

• 第三问：当时如果我们做了什么，可以用更短的时间恢复业务？

通过复盘总结的经验，可以作为后续的应急预案，也可以和告警进行关联，匹配对应场景，通过自动化平台实现故障自愈。

3.1.4 预防

要保障系统的持续运行，还需要做到预防。但故障是系统运行的常态，没有异常才是特殊状态。真正要做到预防也不是件容易的事，需要开发人员在设计架构时注意做到：

• Design For Failure。亚马逊提出的概念，即面向失败去设计，在架构设计的时候要考虑网络发生抖动或延迟等情况。

• 架构高可用。要避免出现单点故障（比如某个进程或服务器出现异常）导致整个服务不可用的情况。

• 监控可观测性。通过外部可观测系统内部具体运行的情况。

• 可运维性是应用系统的核心功能

• 非功能需求 != 非必要的功能需求

3.2 混沌工程

混沌工程：将故障注入系统以测试系统对其的响应。通过故障演练验证系统是否高可用。其好处是使公司能够为宕机做准备，并在宕机发生之前将其影响降至最低。 

故障演练：目标是沉淀通用的故障模式，以可控成本在线上重放，以持续性的演练和回归方式来暴露问题，不断推动系统、工具、流程、人员能力的不断前进，提高持续运行的能力。

3.2.1 故障注入

（图片来源：@我吃印度飞饼）

故障注入与业务系统的架构是贴合的，现在故障注入的能力越来越强，可以从网络层面，模拟网络抖动和丢包等；从存储的层面，模拟磁盘打满；从虚拟化的层面，直接把服务器宕机；还可以从操作系统层面、中间件层面、应用的runtime层面，注入相应故障，检测系统在这些情况下是否可用。

（阿里的ChaosBlade架构 图片来源：知乎@Java钢铁侠-马克5）

四、持续反馈与改进

4.1 反馈是什么

在广义概念上来讲，反馈是系统与环境相互作用的一种形式。在系统与环境相互作用过程中，系统的输出成为输入的部分，反过来作用于系统本身，从而影响系统的输出。

这句话听起来有点拗口，我们来举个生动的例子。看过《天龙八部》的同学一定知道“北乔峰、南慕容”，“以彼之道还施彼身”是慕容复的武学心得。也就是把你的武功绝学（输入）通过吸收学习后为我所用（输出）。

我们在生活中也随时感受着反馈。比如在京东或天猫等电商平台上买东西的时候，平台一般会给你优惠券或返减折扣，这也是反馈。

同时，根据反馈对输出产生影响的性质，可分为正反馈和负反馈。前者增强系统的输出；后者减弱系统的输出。

比如费曼学习法，就是利用试讲者与聆听者的交流反馈机制，在每次交流反馈后及时对下一次试讲的内容进行语言条理的优化、简化和精炼讲述，以达到在最短时间内深入理解知识点和增进学习的效果。

了解了什么是反馈后，我们来看反馈有哪些分类。

我们对于反馈分类的理解是基于不同视角和角色的。以互联网企业和软件产品的日常反馈举例：日常生活接触到的反馈场景，包括部门内部反馈、企业内部反馈，企业外部反馈及用户反馈等等。

通常，一个运维部门内部的日常反馈形式是：通过系统监控的报警、警告、Log日志等进行问题分析；通过系统日志和警告信息，分析排查问题发生的原因，从而对问题进行定位和修复。

企业的内部反馈较为行之有效的是借助监控平台和DevOps方法的落地实践，可以将用户故事通过合理的产品及功能点拆分，内置到系统配置、部署和构建运行的流水线中，以达到系统可以时时自动化发布，支持企业业务连续性的目的。

当然，企业除了内部的正常运转，还肩负社会价值和对外的价值输出，如股价、特殊日期的销售量，大家最熟悉的应该就是双十一和618的电商销量了。

用户反馈涉及到数据分析中的反馈收集。在数据分析中，行为分析是大家热衷的焦点之一。从长远来看，用户行为分析的主要目的是希望通过找到一些规律来预测用户未来的行为，比如我们找到了用户某种特性和用户流失之间的关系，就可以通过监控这一特性的变化及时挽留用户。

还可以通过用户行为分析来沉淀用户视角下的测试Case。我们收集的大量用户行为Case，其使用场景不仅仅是对新功能进行自动化测试，还可以针对用户进行标签化匹配。 

4.2 不反馈的问题！

不反馈会产生的问题包括：闭门造车、反馈不及时、造成人员和资源的浪费、重复的需求、过时的需求、客户需求的频繁改动，与客户预期的生产系统不一致、系统紧急任务和突发风险成几何基数增长，大量用户问题特定时间内集中爆发等。

不及时反馈和数据的关系：数据错误的出现数量和频率与数据传递的路径长度和传递时长成正比。

说到底，不反馈、无效反馈或者拒绝反馈，是负反馈放大的开始，它最终将导致企业和个人的价值流失和贬值。

4.3 如何建立反馈

4.3.1 建立反馈价值流动的闭环

对于软件公司来说，研发侧和运营侧的目标是统一的，就是为企业更加快速而高效地创造价值，同时提升客户的满意度和认可度。

如何有效达到反馈的目的呢？这里的“效”涵盖了两方面的含义：效果、效率。

• 提高效果侧重于如何使传达的信息被正确接受和执行。

• 提高效率侧重于如何用最少的时间和资源来传达信息。

我们认为的持续反馈是在质量、效率、安全、成本、创新价值的价值流动管理，核心是人与人的有效沟通，让反馈可以进行持续的流动。

 

上图可看到，左侧研发价值流转，从影响地图开始接触用户进行商业分析，到用户故事，包括产品精益画布设计，到CI/CI持续集成和持续交付，再到自动化流水线发布到正式环境；右侧是业务价值的监控分析，包括客户来源分析、成本控制管理、数据质量分析、安全性能监控，以及未来结合运营侧进行AI智能化运营，还可以结合用户使用时长系统，提出好的创意和想法，利用服务和利润，回到左侧的研发价值流，实现价值的闭环流动。

4.4 持续改善

持续改善（Kaizen）方法最初是一个日本管理概念，指逐渐、连续地增加改善。持续改善涉及每一个人每个环节连续不断地改进，从最高的管理部门到管理人员到工人。

 

PDCA戴明环也是主流的反馈改进指导方法论，如图服务7步法，更好地展现了螺旋上升的反馈过程。

反馈是一个持续优化的链路，包括从数据埋点到数字化运维到DevOps再到 AIOps的全链路。

4.5 反馈的案例及工具

接下来介绍传统的运维反馈工具，包括《IT运维服务报告》、可视化的监控大屏以及主动反馈和混动工程的回报。

4.5.1 反馈工具-《IT运维服务报告》

我们常见的运维反馈工具，如《IT运费服务报告》，是PDCA里面的C-Check，主要作用是从质量、效率、安全、成本四个维度进行的运维情况检查、审视与成果汇报。

它一般会包含多厂商、多协议和面向各种应用的体系结构，需要解决各类设备、子系统间的接口、协议、系统平台、应用软件等与子系统、机房环境、施工配合、组织管理和人员配备相关的面向集成的问题，通过运维报告进行情况说明。

如上图，运维的价值、反馈价值、用户端的价值是持续流动改进优化的。

DevOps有三个原则，分别是流动原则，即从业务侧向运维侧的交付流动；反馈原则，即从运维侧向业务侧反馈问题或异常；持续学习与实验原则，即持续试错、持续创新和持续学习，改善和提升组织效率。

持续反馈是DevOps的第二个原则，是建立各个环节的反馈机制。通过埋点、监控，将部署、测试、发布、运维、安全等环节需要监测的内容进行可视化展现，或者进行自动化关联分析，目的是为了能够让故障或问题在被用户发现之前被自己人发现。相关的指标如平均故障恢复时间（MTTR）、平均无故障时间（MTBF）。

运维对外价值主要体现为客户业务价值反馈。

比如基于特定项目和销售日的反馈：天猫双11和京东618。2020年是“双11”的第12个年头，受疫情影响消费习惯发生大幅改变以及直播电商的快速发展，双十一人们消费热情空前高涨。数据显示，2020年“双十一”全网销售额已经达到2673.65亿元。2020年的618大促落下帷幕时，天猫和京东累计下单金额分别达到6982亿元和2692亿元，双双创下新纪录。

4.5.2 持续反馈工具-监控大屏

运维另一种更加直观有效的工具就是监控大屏，直观可见各个运维参数指标，通过运维的数据进行指标度量和监控指标分析；可呈现社会价值和运营价值，如某县GDP和经济总产值、人口产业分部、累计生产总值、电子商务发展指数等；在疫情等特殊时期，民众可以在百度上查询获取疫情实时大数据报告。让每个人都可以随时了解身边的疫情情况，追溯和了解确诊人数、高风险地区和人群分布情况等。

4.5.3 《DevOps Handbook》反馈实践

持续反馈实践，主要是监控和告警能力的建设。持续反馈的非技术要素包括：组织、人员等软文化因素。

持续反馈三步工作法：首先从选择价值流入手；流动原则，打造持续部署流水线的基础；反馈原则，建立监控发现和解决问题；持续学习和实验原则，注入学习到日常工作中；最后要解决的就是集成安全、变更管理和合规性的技术实践。

4.5.4 主动反馈和混沌工程

前文提到的玛格丽特·汉密尔顿，是最早提出软件工程这一概念的人，也可以说是第一代的SRE工程师。汉密尔顿在阿波罗登月计划中负责软件系统的开发。有一次她女儿在模拟仓玩耍时不小心错按了按键。这让她开始思考，既然故障总是会发生，那么我们就有必要提前进行故障演练的场景测试。

在阿波罗8号之后，汉密尔顿开启了最早的故障场景模拟测试，我们可以理解为是混沌工程最早的雏形。

阿波罗13号的登月失败就是因为细节和故障的发生不可控、且非线性，几乎将三名宇航员困在太空，这一事件引发了历史上最雄心勃勃的救援任务。这里我想要强调的是我们生活的世界存在着非线性的风险和突发事件，我们必须具备面对和处理它的方法与技巧。混动工程就是一个很好的方案。

（图片来源见图上标识）

我们再看一下被动式IT运维服务和主动式IT运维服务的区别。从监控手段、异常出现的应对、异常信息的历史记录参考、运维有规范化的制度、运维人员从救火队员向急救员的转变；专业的运维报告、具有连续性和指导意义，工作可量化避免对运维专家的强依赖，这都是从被动运维向主动IT运维服务带来的好处。 

混沌工程的回报

关于混沌成熟度模型，Netflix 总结了两个维度：复杂度和接受度。前者表示的是混沌工程能有多复杂，而后者则表示的是混沌工程被团队的接受程度。

我们来看Netflix 2018年使用混沌工程的投入产出比。

• 2018年混沌工程提前发现了2次重大事故跟8次小事故，避免了整个组织大约70万美金的损失。

• 混沌工程团队，总共3个成员，薪水支出15万美金/人。

通过计算，得出其投资回报率52.17%，这是一个相当令人兴奋的结果，它的关键是风险提前发现和解决。

（图片来源：Netflix报告：The Business Case for Chaos Engineering.2018）

4.6 AIOps（智能运维）

4.6.1 什么是智能运维？AIOps

AIOps这一概念是在2017年由Gartner从基于大数据及算法扩充为基于人工智能的， 2018年举行的GOPS 大会上，AIOps还处于刚起步的阶段。

（图片来源：GOPS全球运维大会2018年.深圳站  《亿级用户百TB级数据的AIOps实践之路》周荣-华为消费者BG云运维部）

那么从传统运维到AIOps有哪些变化呢？

（图片来源：GOPS全球运维大会2018年.深圳站  《亿级用户百TB级数据的AIOps实践之路》周荣-华为消费者BG云运维部）

上图展示了运维的发展，从早期的传统运维，逐渐提高系统执行及决策的能力，到AIOps时代，大概要达到百分百系统执行，95%系统决策，仅有5%需要人工决策。 AIOps主要实现的功能包括：性能监控预警和自使用调整，故障诊断和自动恢复，性能趋势分析和自扩展，问题诊断和关键因子分析，异常告警等趋势和辅助决策分析等等。所以我理解的AIOps实际是在自动化运维的基础上，收集各种监控数据，基于数据规则研发算法，达到自适应、自动恢复、自扩展的目的。 

4.6.2 AIOps 落地挑战

AIOps落地面临一系列挑战，包括：数据获取、干扰数据过滤、算法准确性及性能、隐藏风险、研发投入与收益等。

4.6.3 AIOps 金字塔

DevOps 实现端到端的研发过程系统化，基于DevOps 、Iaas平台等做全链路监控，对监控预警做进一步的升级提炼，实现故障自动处理、容量自动优化、弹性扩缩容等；所有的运维监数据，做数据分析、梳理事件自动处理策略，然后通过机器学习赋能运维。

总结这样一个金字塔，是为了清晰地展示AIOps需要有一定的基础才能做，就像盖房子要有地基一样。

最理想的自动化状态是机器完全自动化分析和运行，如华伦·贝尼斯所说：未来的工程里只有一个人，一条狗。人是要喂狗，狗是要看住人，不让他碰机器。

五、总结

5.1 PDCA的持续运维

PDCA持续运维是一个价值流动的闭环：持续部署包括配置管理、安全管理、变更管理；持续运行包括SRE、监控、混沌工程，保证系统稳定性、高可用和反脆弱；持续反馈案例和工具包括AIOps、监控看板、度量等；持续改进环节包括主动反馈、复盘和OnCall等。

5.2 ITIL与DevOps的持续运维

ITIL V4是在需求输入和价值输出之间有一个闭环的改进过程。DevOps的三步工作法，第一步是从左到右快速的流动；第二步开始有从右到左的快速反馈；第三步是把整个持续的过程不断迭代。

最后用两个词对本次分享进行总结：简单、连接。

• 用简单的持续运维服务。避免繁琐的流程和复杂的架构带来不必要的影响和消耗。

• 去连接人、资源、产品。持续运维需要保持人、资源、产品的高效沟通和稳定运行。