神聊《DevOps HandBook》第一期，DevOps精要及三步工作法

大熊

导言

大家好，我是张乐。
今天是DevOps拆书联盟第一季活动的第一期，由我为大家分享《DevOps Handbook》这本书的前言和第一章的内容：“DevOps精要及三步工作法”，今天我的分享主要有以下三个部分。
第一部分：《DevOps Handbook》整书介绍，这本书的内容体系是怎样的，为什么值得我们花一些时间去研究它，以及是否可以把它里面精华的东西摘取出来。
第二部分：DevOps的信念，首先会介绍本书的几个大神作者：Gene Kim，Jez Humble，Patrick，John Willis，他们个人发展轨迹是怎样的，为什么都不约而同的转到DevOps的阵营当中，以及他们的Aha Moment；其次会对DevOps常见误区进行解读。有些朋友对DevOps不熟悉或有一些不准确的理解，比如是不是只有互联网公司可以仅仅，是不是与ITIL不兼容，是不是做DevOps就不能同时保证质量和效率等，我们会对这些常见误区进行分析。然后我们讲讲Dev和Ops如何能够组成DevOps，也就是我们目前碰到的这些问题的根本原因是什么，哪些因素导致了我们的效率、质量无法跟上业务的发展速度，DevOps方法和实践是怎样解决这些问题的。
第三部分：介绍这本书的核心 -- 三步工作法。《DevOps Handbook》全书就是从三步工作法的思路出发，进行知识体系的组织和实践的编排，这部分是今天的重点内容。我会介绍三步工作法是什么，如何通过三步工作法来指导DevOps的整体实施，以及它的核心思路和基础原则。

一、整体介绍

1.1、《DevOps Handbook》整书介绍

其实大家从书名已经可以看出，《DevOps Handbook》这本书的出发点，是希望写成DevOps解决方案的指南，所谓指南就是从不太了解DevOps，或者只了解部分相关实践的人，能够根据书中的体系、方法、实践的逐步导入，成功推动DevOps的实施，它的定位是一个指导性的手册。这本书有四位大神作者，Gene Kim，Jez Humble，Patrick，John Willis。

Gene Kim大家可能会比较了解，今天我看有朋友在群里在分享《凤凰项目》这本书的读书笔记，Gene Kim就是《凤凰项目》的主要作者，他以小说的方式描述了我们在日常工作场景里碰到的问题以及如何通过DevOps的方式进行解决。这本书在亚马逊上是4.5分，是比较高的评分了，一些朋友读完之后都觉得对理解DevOps很有启发，另外Gene Kim也是DevOps企业峰会主要的组织者之一。

Jez Humble是我个人非常欣赏的一位专家级人物，《持续交付》这本书就是2010年时由Jez Humble和另外一个同事共同编写的。这本书英文版2010年出版，距今已经有7年时间，但是翻开这本书，其中很多总结、提炼的知识点，很多内容到今天依然非常适用，我觉得这是一本非常经典的，甚至超越当时大环境的书，即使到现在都是DevOps从业者必读的书之一。

Patrick是DevOps运动最早的发起人，他举办了DevOpsDays大会，DevOps这个词也从这个大会的名称里演化出来。今年3月18日在国内首次DevOpsDays大会里，我们也把Patrick先生请过来给我们做了一场很精彩的分享。

John Willis，很可惜3月份他没能如期来到国内，他在DevOps领域里也非常活跃，之前在Docker，是很资深的技术专家。

这四位大神花了五年时间编写了这本《DevOps Handbook》，他们花了累积2000个小时，整理了很多方法、案例，把它们提炼出来写成这本书。我认为DevOps从业者研究这本书会非常有帮助。那这本书为什么要做拆书活动？因为它里面不光是方法和理论，还有很多案例的研究。官方介绍书里有数十个DevOps案例，包括Amazon、Etsy、CapitalOne、Google、Facebook、美国保险公司等，这些案例已经都融入到这本书里不同章节，另外在一些章节里会有一个单独的“Case Study”环节，完整描述的案例也有20多个。通过这本书的阅读或者解读，分析一些案例，会知道这些公司成功的背后到底是做了什么样的努力。这本书400多页在讲DevOps应用、案例学习以及how-to，我们不应该仅看到这些成功企业的光环，更要去关注这些光环背后到底是如何做到的 -- how to do DevOps。另外2016年这本书也被评为“年度最佳DevOps图书”。

下面看看这本书的逻辑结构，共有六个组成部分，第一部分是三步工作法，也是今天我会花比较大精力跟大家介绍的部分，这里会谈敏捷、精益、持续交付与DevOps的关系，以及整个书的核心 -- 三步工作法，如何通过流动的原则、反馈的原则还有持续学习和实验的原则去实现DevOps闭环实践。这是比较High Level去谈整个DevOps实施的，开篇给大家一个整体的思路。我们拆书联盟的活动，这本书可能需要拆很多次，不是一次就能把它完全读透，计划有六期到八期读书分享。我们今天是第一期，给大家整书全貌以及对方法论、体系的介绍，后面每个部分都会有单独一期跟大家详细解读里面的一些细节和案例。从今天开始，每周会有一期拆书活动，下周是第二期 -- 从哪里入手，如何选择价值流，如何根据康威定律构建组织和架构。第三期是三步工作法的第一步 -- 流水线原则，包括如何打造持续部署流水线，如何做自动化测试分级，如何启动持续集成实践，如何控制发布的风险。第四期讲工作法第二步 -- 反馈原则，包括如何做更好的监控、如何更好通过监控预测问题以及如何通过假设驱动开发，通过AB测试降低发布风险。第五期是持续学习和实验原则，建立在技术之上考虑组织如何做演进，如何形成一个学习型组织。第六期是和安全、合规性相关的技术实践，包括如何将信息安全嵌入到日常工作，以及保护部署流水线，保证流水线的安全合规性。再往后可能还会安排一些特别篇的分享，我们今天先看第一部分。

1.2、DevOps 拆书联盟及活动介绍

简单说一下拆书联盟的活动，目前有几位小伙伴一起做拆书活动，首先由我做来第一期，然后是石雪峰，他是乐视配置管理和持续交付部门总监，他会给大家带来第二期拆书活动，后面还有王磊、大梁、景韵、赵班长等同学，都会参与到读书分享过程中。如果大家有兴趣可以联系我们，继续扩大阵容。

二、 DevOps 的信念

2.1、四位大神作者的 Aha! Moment

Gene Kim，他是《凤凰项目》的作者，他在1999年就开始研究高绩效组织如何成功的要素。最早的发现是：跨越开发、IT运营和信息安全等不同职能的边界对成功至关重要。他在2006年做了一个大型航空公司订票服务外包项目，这个项目可能做得比较痛苦，大型、以年为单位的发布，每次发布会导致大量外包商的混乱和破坏。而且因为这个项目最后做的效果没有达到SLA的要求而遭到处罚，有影响客户中断的事故产生。因为项目做得不太好，整个公司利润率下滑，裁掉很多有经验的员工。剩下的人要做大量的返工和救火，所有人觉得这个项目已经无法挽救，马上就要失去合同。他一直在考虑一个问题，一定会有一个更好的方法来让整个软件交付过程做的更好。2009年Velocity Conference这个大会非常有名，他在这上面听到了flicker关于每天部署10次的演讲以及很多相关案例的精华，他感到可以通过架构、技术实践和文化规范实现让人震惊的结果。他说他自己非常兴奋，终于找到了一直在寻找的The Better way。于是，他坚定走上了DevOps之路，也变成DevOps运动主要的推手之一，同时编写了《凤凰项目》这本书。以上就是Gene Kim的个人转型之路。

Jez Humble，2000年他作为他们公司两个技术员工中的一员，他负责所有事情，类似于全站工程师，包括做网络、编码、线上问题支持、管理、大服务器等。直到2004年他加入到ThoughtWorks，与70个人共同工作。他作为8人团队中的一员，主要工作是部署系统到准生产环境。几个月后，他把原来需要2周的手工部署转化为需要1小时的自动化部署，极大提升了效率。通过蓝绿部署，可以在业务时段中以毫秒级进行升级或回滚，在工程能力上是非常成功的一项改进。这个项目的经历促使他编写了《持续交付》和《DevOps Handbook》。他说，“无论什么地方你觉得会有约束，你永远可以做得更好”。

Patrick，2007年做数据中心迁移项目，当时跟敏捷团队一起工作，他说他很妒忌开发的高生产率，能在短时间内完成大量工作。所以他在下一个项目，在运维团队里使用看板方法做一些实践，并且看到这个团队很明显的效率提升。在2008年多伦多的敏捷会议上他提出一篇关于敏捷基础设施的论文。在2009年Velocity Conference上他看到了每天部署10次的演讲，他发现我们其实可以做更多的事情，于是说服一些志同道合的人举办了DevOpsDays大会，也意外创造了DevOps这个词。这些年DevOps不断推陈出新，有新的方法和实践出来，不断传播开来，影响巨大，很多人把他称为DevOps教父。

John Willis，他2008年在做一个大规模遗留IT系统配置管理和监控的项目，那时他遇到了Puppetlab创始人Luke，他说听了短短几十分钟的演讲，发现过去20年对配置管理的做法都是错的，Luke描述的是第二代CM，就是我们现在说的基础设施即代码的方式。Luke认为运维需要转变为跟开发者一样的行为，包括把配置纳入版本控制，采用CI/CD交付模式。慢慢他也进入到DevOps阵营里，他也是在比利时根特第一届DevOpsDays唯一受邀的美国嘉宾，用他自己的话说，从这次活动以后，DevOps已经融化在血液中。

这是几位大神的Aha！Moment，恍然大悟的时刻。希望通过我们社区的分享，所有的小伙伴都可以慢慢找到一些自己的问题和优化的解决方案，也许从这一天开始，大家突然发现DevOps就是可以指导我们解决现在困境最好的方式，我们一起逐步把DevOps引入和落地。

2.2、 驱散谬见-常见DevOps误区解读

在DevOps推广过程中有非常多的声音，有人说DevOps只适合特定的公司、特定的企业、特定的文化，他们的公司很难去推广DevOps活动。所以在《DevOps Handbook》中专门有一个章节来谈一谈常见的DevOps误区，结合我的理解，我为大家做一下解读。

• 误区一

第一个常见的误区：DevOps只适合于初创型的互联网公司，这也是很多人经常会表达的一个观点。DevOps实践确实是被那些互联网独角兽公司所倡导，包括优秀的公司比如谷歌、亚马逊、Netflix、Etsy，这些公司都在倡导DevOps相关的方法实践，虽然也许他们不把它称为DevOps。实际上，这些公司并不是生来如此的，每个公司成长过程都是一样的，都会经历很多问题、坎坷，也经历过IT跟不上业务的发展导致业务停滞的风险。我们把他们叫做独角兽公司，因为在神话里独角兽是一种长着犄角和翅膀的白马，这些公司都是从普通的"马驹"公司进化成了独角兽公司，他们也会遇到传统公司所碰到的问题，包括高危代码导致的灾难性的失败、不能快速发布功能、不能应对市场上竞争的变化、不能扩大规模，以及开发和运维相互对立而不能相互信任等。但是这些公司采用了一些比较好的方法和实践，促进他们成功完成了转变。这里我收集了一些资料，这些公司都或多或少都进行了很多架构上的、技术实践上的，以及文化的转型。

 - 亚马逊在2001年时，他们那时的系统叫做奥比杜斯，奥比杜斯是亚马逊流域下游一个很有名的城市，他们这个的系统就以此命名。这个系统是一个很大的单体应用，面临很多系统的问题。2002年的转型大家都非常熟悉了，他们CTO说我们必须要转成SOA的架构，所有不按这个原则工作的人都要被fire掉，他们通过强力的转型，开启了SOA架构的路线。现在亚马逊被认为是在技术领域非常成功的公司，因为他在很久之前就开始做这些技术转型的工作。

 - 2009年推特也遇到了很复杂的情况，他们把前端巨石架构的Ruby on Rails系统花了一年多时间做重构。

 - Etsy是手工艺制品销售网站，为了提升工程能力，公司在2009年花很大的代价，用两年时间去解耦原来一个叫做Sprouter的系统。这个案例我们在第二期会进行详细分析。

 - Facebook经历了快速成长后，在2009年运维已经接近崩溃，无法跟上用户的增长，到处救火，于是开始进行技术和文化上的变革。

- 2011年领英在IPO之后同样面临了很大的困境，技术已经无法完全跟上业务和用户的发展，他们做了一个决策，整整两个月时间，不做任何新功能的开发，而是去解决环境部署和技术架构的技术债。

类似的案例其实非常多，可以说这些成功的公司背后都经历了很多也许不为人知的努力，他们因为改变了技术架构、技术实践，改变了文化的氛围，才有可能不断走向成功。DevOps不仅是初创公司可以使用，它其实是一种普适技术，所有类型的公司都可以采用DevOps的方法和实践帮助取得比较好的成果，后面会逐步看到这些方法和技术实践是什么。以上是第一个误区。

• 误区二

第二个误区，DevOps Replaces Agile，有些人认为是不是DevOps就会替换掉Agile。正确的说法应该是DevOps的方法和实践是与敏捷相适应的，我们认为DevOps是敏捷之旅的一种逻辑延伸。敏捷是DevOps的使能者，因为做了敏捷，具备小团队快速发布和持续交付的能力，才能进一步做好DevOps。但是DevOps实际上是在超越敏捷的，大家读过《敏捷宣言》，有一句是"可工作的软件大于面面俱到的文档"，每个迭代结束之后它会得到一个潜在可交付的版本，但是我们认为DevOps已经在超越这个目标，把目标扩展为"让代码一直处于可部署的状态"。通过每日频繁的签入代码到主干上，经过一系列的构建、自动化测试，能够很快在类生产环境甚至生产环境看到这次变更所带来的影响。DevOps不是替换敏捷，而是敏捷之旅的延伸，把目标做进一步的扩展。

• 误区三

第三个误区，DevOps与ITIL不兼容，这可能是很多做运维的朋友最大的困惑。1989年提出的ITIL是非常经典的方法论，影响了一代又一代运维实践者。有很多世界级IT运维流程横跨整个服务的策略、设计和支持等很多方面，但是我们认为DevOps的实践实际上可以与ITIL流程做兼容。具体有三个方面，第一，为了支持更短的前置周期和更高的部署效率，很多ITIL流程需要自动化，通过自动化的方式提升效率。第二，为了解决配置和发布管理流程方面的一些问题，我们强调DevOps需要保持配置管理数据库以及软件库的及时更新。第三，DevOps需要快速探测和恢复故障，在这个背景之下ITIL里关于服务的设计、事故、问题管理的这些流程其实是仍然适用的。ITIL与DevOps其实是可以兼容的，之前有一个文档《企业级DevOps成功之路》，里面谈到DevOps里有很多组成部分，包括敏捷、持续交付、精益，还有轻量级的ITSM，如何把ITIL流程做效率上的优化，与DevOps频繁发布变更的模式相匹配等，所以我们认为本质上二者是可以兼容的。

• 误区四

第四个误区，DevOps和信息安全、合规性之间不兼容。很多人觉得DevOps缺乏传统的控制方式，比如职责隔离，不同人有不同权限、做不同事情，DevOps讲究跨界，鼓励开发人员自服务的方式做环境申请、部署和发布。又比如说传统的控制方式有很严格的变更审批的流程，以及在整个项目末尾人工进行非常完善的安全review的活动。DevOps没有这些活动，但是不代表没有安全控制，反过来，很多做DevOps的公司的安全性、合规性甚至会超过原来传统控制方式的公司。因为DevOps其实是把原来项目末尾做的安全和合规性的检查注入到了每个阶段，变成日常工作的一部分。我们经常说在DevOps里是没有单独的测试阶段的，但是它把测试已经融入到每个阶段，测试在DevOps场景里是每个阶段都要做的实践，而不是一个单独的阶段。没有传统的控制方式，并不意味着DevOps没有安全和合规性的要求，反而它会更强。

• 误区五

第五个误区，DevOps没有Ops或者说排斥了IT运营。诚然在DevOps场景里IT运营或者运维的职责会发生一些变化，但是这种角色仍然是非常重要的。我们的运维更早的会介入到软件生命周期里，可能会与开发一起工作。反过来，开发也会在代码部署到生产之后，与运维一起去持续工作。变化是我们更强调自动化，通过自动化替代原来手工处理工单的一些工作。运维最大的变化是通过一系列自服务平台的创建和开发，能够把自己原来基于人工的环境的建设、维护、发布、部署等等这些能力赋能给开发，通过赋能给开发的方式，提升流程生产效率。从这个角度讲，IT运营或运维其实更像是一种开发，开发的产品是一个平台，让开发人员可以快速、安全、可靠的用这个平台去完成经常操作的场景，比如部署、环境分配等。从这个角度讲，并不是说没有运营或运维，反过来运维的职能会有些变化，更强调赋能给开发，提升自服务能力。

• 误区六

第六个误区，DevOps仅仅是基础设施即代码。因为很多人在谈DevOps强调的是自动化，强调的是Puppet、Chef、Ansible这种工具，我们认为这远远不够。很多DevOps模式确实需要自动化，但是那些成功的公司不仅仅有技术范畴的改进，更有公司组织结构的调整、文化氛围的调整，让整个共享目标在IT的价值流里快速交付，这已经远远超出了自动化的范畴。这里有一句很经典的话："DevOps不仅是自动化，就像天文学不仅是望远镜那样"。我们要超越技术的范畴去看更广阔的改进空间。

• 误区七

第七个误区，DevOps只为开源软件服务。很多成功的故事都是用LAMP技术栈，比如Linux、Apache、MySQL、PHP，但是这些其实与取得DevOps的成果是无关的，我们看到很多成功案例可以用微软.Net、大型机系统、SAP软件，或者是一些嵌入式软件等，都可以做DevOps转型，在《DevOps Handbook》这本书里也提到很多，包括ATM机这种复杂的嵌入式的系统也可以做DevOps转型。

以上谈到了七个误区，希望大家通过我的解读慢慢去理解，DevOps实际上是一个普适的概念，它不仅仅是自动化，不仅仅是一种流程，可以跟我们日常的工作场景相兼容。

2.3、Dev and Ops Become DevOps

首先描述一个理想的世界，业务、开发、测试、运维一起协同工作，保证组织成功，他们朝共同的目标努力，达到世界级的稳定性、安全性、可靠性。跨职能团队严格测试业务的假设，哪些功能能够满足用户和企业的需求。整个工作过程是安全的，每个小的团队都可以独立快速做开发、测试、部署。而我们真实世界里的现实情况是，工作的系统是破碎的，开发和运维通常是对手，测试和信息安全只在项目结尾进行，大多数关键活动需要手工交接，大量工作都要等待下游去完成，经常排队，经常有些问题解决不了，需要上升到管理层做介入和决策。系统部署时间非常长，客户和业务影响非常消极。这是现实生活的场景，就像Gene Kim讲的，我们一定会有一个更好的方式，我认为DevOps就是这个更好的方式。

DevOps是不是真正能够帮助我们成功，它的潜能在哪里？书中做了一个对比，在1980年代的制造业革命，精益从那时发展起来，很多公司开始采用精益的原则和实践，帮助他们提升生产效率，缩短客户前置时间，提升质量和满意度。数据表明，在精益运动之前，平均制造的前置周期是6周，70%可以按时交付。2005年普遍应用精益实践后，产品前置周期少于3周，缩短50%以上，95%是按时交付的。但是没有采用精益实践的组织正在逐步消亡、退出市场，这是制造业的革命。于此对应的IT革命是在软件交付过程中技术和产品的革命，在1970到1980年代，大多数的新需求需要1-5年时间才能开发完成，成本消耗数千万美元。2000年由于技术发展，互联网的爆发，敏捷应用慢慢扩大规模，让开发周期缩短到数月到数周，部署生产环境时间也大大缩短。2010年DevOps已经提出，随着DevOps引入以及云和软件的PaaS化、SaaS化，很多功能的开发都非常快，甚至很多互联网公司可以做到按周做迭代，部署时间非常短，数分钟到数小时之间。这些组织可以通过快速的实验去验证商业的想法，尤其在互联网时代讲究"唯快不破"的背景下，如果企业能更快的开发系统、更快的试错、更快找到方向，企业的竞争能力和优势是不言而喻的。DevOps在今天已经在很多公司里取得成功，DevOps的实践已经让他们可以实现每天成百上千次安全的变更，这就是对企业竞争优势最明显的体现。

我们逐步往下深入分析，刚才说DevOps很好，但这些传统的组织里为什么不能达到这么好的效果，这里有一些问题是需要解决的，我们把它叫做核心、长期的冲突。开发和运维之间内在的冲突导致了下行螺旋。开发和运维有相互冲突的目标，比如开发强调快速响应变更，运维强调稳定、可靠和安全性，他们之间有不同的激励机制、不同的仓筒间度量和激励会阻碍整个组织目标的达成。精益里面有很多精华的思路，比如我们要同时关注资源效率和流动效率，保证流动效率很高的情况下，我们再去提升资源效率。不要仅仅关注资源效率的优化，过度的局部优化会导致全局过程的劣化。下行螺旋的产生具体来讲有三个步骤。首先，应用和基础设施复杂、缺乏记录，导致很多问题产生。我们常常承诺解决一些技术债务，但是这些技术债务一直被新的需求、新的计划压制，从来没有解决技术债务的那一天，解决技术债务更多变成一种无法兑现的承诺。因为系统的复杂性，产生了技术债务，这是下行螺旋的第一步。下行螺旋的第二步会让问题更加严重，因为我们有的产品经理、有的业务部门，为了给客户呈现更多超预期的功能，他会承诺一个可能比实际能力更大的目标，而不太注意技术可行性。这导致了一个不正常的状态，项目只要提到IT部门就是紧急项目，所有问题都是紧急问题。为了支撑这种紧急项目，IT的应对办法只有"走捷径"。我之前在做程序员的时候深有体会，如果给我一天时间让我开发一个应用逻辑或实现一个类，和给我一个礼拜去实现同样的逻辑，做法是完全不一样的。为了压缩周期，为了更快实现，无形之中就会注入更多的技术债务。下行螺旋第三步，因为以上情况工作会变得更困难，大家更忙，工作时间更长，沟通更慢，队列更长，整个工作更紧耦合，小问题会导致更大的失败。这就导致部署时间更长，更多的救火，不停的恶性循环，会进一步剥夺解决技术债的能力。整个IT交付过程可能不断会有新的问题产生，会导致永远无法解决技术债，永远无法做改进。这些下行螺旋最终导致的结果，就是按月甚至按季度发布。我原来在传统IT公司做顾问的时候，发现这种例子很多，业务可能发布的时候经常需要中断，习惯性的救火和英雄主义的行为，这种下行螺旋的危害非常大。但是有句话很有意思，说其实每个公司都是技术公司，银行只是拥有银行营业许可的IT公司，那么只要IT做得不好，整个公司就不会好，这是说问题的严重性。

谈了这么多问题，我们也要抬头看看是不是会有更美好事情发生。很多转型比较成功的公司都认为DevOps实际上是帮助他们取得成功的关键因素，比如小团队可以独立开发功能，在类生产环境做验证，代码可以更快、更可靠的发布到生产环境里，代码的部署更有节奏感。运维人员在这十年里终于可以跟别人一样有正常工作时间了，因为他们不用周五午夜熬夜进行发布，然后整个周末都在解决问题。部署是在工作日进行，客户是无感知的，使用灰度发布、蓝绿部署、金丝雀发布的模式。变更只要提交到代码库，会自动做很多测试验证，反复确认代码是符合预期设计，并且是安全、可部署的。自动化测试做得很快，可以分钟级反馈。生产上即使有问题也不可怕，因为我们有很好的监控措施，可以快速发现生产环境的问题，快速解决这些问题。重要的产品都使用灰度发布的技术，比如马上到双十一了，双十一的这些功能和代码相信提前就会部署到生产环境了，进行不断调整和优化，直到特定时间点通过功能开关开启，这些新的功能才会对用户可见。这是一种很典型的灰度发布技术，通过灰度去控制风险。还有很多DevOps组织有良好的学习文化，高度信任、相互协作，每个人保证他自己工作的质量。如果出现问题会采用免责的事后故障分析，后面讲DevOps的组织文化里专门有一个章节讲免责文化，通过免责文化促进组织学习。以上这些描绘大家可能会觉得有些遥远，以我在大型互联网公司工作的经验来看，有很多产品已经完全做到了上面这些效果，所以通过我们的努力这些都是可以实现的。

关于DevOps的业务价值，前几个月我做过一次分享，解读《2017年DevOps现状调查报告》，这个报告每年都会有一个新的版本，今年已经是第六年。报告里面提到DevOps有很多优势，比如代码变更能快30倍，代码从提交到运行到生产环境快200倍，采用DevOps的公司他们的市场占有率逐步上升，他们花费更少的时间去补救安全性的问题。

实施DevOps还有一些额外的好处。我遇到过很多传统企业，当团队很小的时候，一切都还比较正常，但是当企业变大之后，很多问题就出来了。比如当开发人员增多的时候，整体的效率并没有随着人数的增加而提升，而是人多了但效率却下降了。很多大公司都有所谓的"大公司病"，部门之间的沟壑和过多的交接导致了更多的跨部门协作的开销，就像《人月神话》里讲的，当项目延迟的时候仅增加更多的开发人无法提升整体生产效率，而且随着每个人的生产效率下降，整体的生产效率也会下降。反过来，为什么我们说DevOps能破除这个问题，当我们有正确的架构，在正确的技术实践道路上，做正确的文化转型，小团队可以快速、安全的进行开发、测试、部署，如果我们能做到这样，大型组织依然会有非常高的生产效率，我们可以看到很多像谷歌、亚马逊这种公司，公司规模已经非常大了，但是他们的生产效率就跟我们初创公司是一样的。虽然有数千人的开发人员，但是他们的架构和实践允许他们像小团队一样有极高的生产效率。通过图中的曲线可以看到，传统公司人数提升了，但公司整体的生产效率没有提升，但是对于采用DevOps的公司来讲，随着开发人员数量增长，生产效率也会同步提升。这也是DevOps能够帮助我们很关键的因素，实现开发者生产效率的规模化。

三、Part I 三步工作法

3.1、DevOps与其他管理运动

我们再来看一下DevOps与精益、敏捷和其他的管理运动的关系。首先是精益，它是源自1980年代的丰田管理系统（TPS），关键实践包括价值流、看板和统一生产率维护方法等，目标是提升效率、减少浪费，通过小批量的工作缩短整个Lead Time。精益的原则聚焦在如何通过系统思考为用户创造价值。再来看下敏捷，2001年提出了《敏捷宣言》，敏捷里强调轻量级软件开发，小批量、增量式的发布，小的团队提升组织的效率。然后是2009年Velocity大会，这个会上Flickr公司提出Dev和Ops如何做更好的协作，实现每天10次线上发布。很多人包括Gene Kim、Patrick、John Willis都参加了这次大会，然后组建起来DevOps阵营。持续交付是2009年由Jez Humble和David Farley共同提出的，把持续集成做逻辑上的延展，形成持续交付的新方法。持续交付的核心概念是部署流水线，就是我们经常讲的Pipeline，Pipeline可以让我们确保代码和基础设施一直处于可部署的状态，所有签入到Trunk的代码都可以在安全的环境里部署。还有一个运动大家提得比较少，是2009年的TOYOTA KATA运动，这里面提出一个困惑，这么多公司去学习丰田，但是没有一个学习丰田精益实践的组织能够复制丰田工厂观察到的高效。大家都在学丰田，为什么我们回来用他们的方法实践，却达不到丰田的高度呢？实际上我们遗漏了一个最重要的实践：improvement kata，就是改进的模式。丰田之所以成功，因为他把改进作为日常工作的一部分，我们如果只是静态学习，别人有什么实践，我学习什么实践，这样不能达到卓越，我们需要保持持续改进。DevOps本身的方法以及它的技术、架构、文化实践都参考了这些优秀的管理方法、管理运动、管理哲学，DevOps是以上这些方法的集大成者。

3.2、IT价值流与三步工作法

下面我们来具体看看如何提升效率，在说具体方法之前先解释一个概念，什么叫做价值流。图中左边是生产价值流，指的是生产制造领域中设计、开发和交付产品所需要的活动，包括信息和材料的双重流动。聚焦在创造平顺和流式的工作，关注小批量，避免返工，减少在制品等。右边是技术的价值流，也就是IT的交付过程，从需求提出到开发、测试、部署、发布、运营整个的过程。我们认为技术的价值流同样可以采用在生产制造价值流中经过验证有用的技术。技术价值流关注从商业的假设提出，到把它转化成技术辅助服务，最终交付价值给用户。技术价值流的重点在于如何聚焦和缩短部署的前置时间，这里面有两个部分。首先是上游，设计、开发的部分。其次是下游，测试、运营的部分。我们认为在设计、开发部分是精益产品开发过程，特点是高度的易变性和不确定性，需要有深度创新的工作。下游的测试和运营，我们希望它有更好的预测性和机械性，以最小的易变性完成工作。怎么达到这个目标？有两个核心方法，一个是避免大批量工作从设计、开发价值流传递到测试、运营价值流，如瀑布流程或长分支。另外一个是，让测试、运营与设计、开发同时进行，确保价值流快速流动和高质量。

如何加快速度，我们要关注Lead Time和Process Time。Lead Time是前置时间，从需求提出到需求被满足的整个周期。Process Time是从开始工作到工作结束，不包含在队列里等待的时间。Lead Time和Process Time之间的比率是非常重要的衡量效率指标，快速流动和缩短前置时间最重要的一个抓手就是要缩短队列中的等待时间，这可能是我们日常工作中非常容易忽略的。

下面是两个常见的场景，一个是传统的项目管理场景，大型复杂组织，紧耦合、单体应用，很稀有的集成测试环境，很长的测试和生产环境Lead Time，高度依赖手工测试，有特别多的审批流程。类似这种的大型项目基本结果都是一样的，整个周期时间很长，普遍数周甚至数月。另外一个场景，被认为是DevOps的典范，就像很多互联网公司做到的一样，在分钟级就可以完成从代码提交到上线的整个过程，包括从提交到自动化构建、自动化测试、手工探索性测试以及生产部署，所有这些事情可以很快完成。如何做到？需要开发提交代码之后快速收到验证反馈，可以让这个反馈更快的指出什么地方被破坏了、什么地方存在问题，可以持续将小批量代码签入代码库，执行自动化测试，可以自动化做发布、自动化部署。又因为整个系统模块都充分解耦，所以小团队可以高度自治，可以快速完成端到端流程。今天谈的是比较高阶的思路，如何从更宏观的角度去解决问题，我刚才提到的每个部分，包括如何做技术架构解耦，如何做自组织的适配，如何做到开发的自服务，这些内容在后面的分享里都会有详细的展开。

下面我们进入到三步工作法最核心的部分。整个DevOps实施可以分解为三步：第一步是从左到右快速流动，第二步是从右到左快速反馈，第三步是在整个过程中持续学习。每个部分我都做了一张总图，把核心思路做了梳理。

3.3、三步工作法的核心思路

第一部分是Flow，让价值快速流动，其中有六个实践，分别是：可视化、限制在制品、减少规模、减少交接数量、持续识别和拓展约束，以及在价值流中消除浪费。

让工作可视化。技术价值流和生产制造价值流的区别是工作不可视，工厂里面有物料的流动和堆积，如果发现大量堆积，说明这里有瓶颈、有排队。而IT交付价值流里看不到显而易见的堆积，很多问题被隐藏掉，直到最后爆出更大的问题。在DevOps领域里，包括敏捷、精益的理念，都在提可视化，通过可视化去管理价值流动。图中左下角是一个典型的看板，看板里把整个软件的生命周期分成需求调研、需求就绪，开发进行中、开发完成，测试过程中、测试完成，以及UAT测试、准生产、发布等不同的列。通过这些列的划分，管理工作单元的流动，快速发现问题和解决问题。通过看板可以让工作可视化、管理流动，并度量整个交付周期，看板一定要跨越整个价值流。在这里推荐一本书，何勉老师最近编写的《精益产品开发》，前一个月刚上市，我认为是在国内做看板比较权威和完整的理论与实践相结合的书，强烈推荐大家阅读，里面会讲很多看板的方法和原则，如何建立、如何实践。这里还要强调，做工作的可视化要考虑全局而不是局部，如果仅仅度量开发的完成率、度量测试发现了多少缺陷、度量系统的可用性，这些都是局部的目标。我们更关注全局、端到端的价值流动，如何整体加快从需求提出到生产部署的时间，去增加服务的可靠性和质量。精益里讲全局的改进大于局部的优化。这是可视化的概述，看板也有很多方法和实践，后面的分享里再逐步分解。

限制在制品。刚才讲了很多Handbook里面的内容，下面讲两个小的故事，来理解在制品的概念。第一个故事是“束水攻沙”，黄河千年以来都是由上游流下来很多泥沙，因为上游主要是在黄土高原，植被稀疏，泥沙不断流入黄河，导致黄河的河床不断抬高，所以我们叫黄河地上河，经常会有洪灾。明朝时一个很有名的水利专家叫潘季驯，提出“束水攻沙”的治黄方针，通过收紧河道，利用水的冲击力去冲击河底的泥沙，从而达到清淤防洪的目的。更科学的理解，如果我们把河道的横截面收窄，水流的量是固定的，河流的河道收窄，河流的速度会加快，会提升水流携带沙的能力，解决泥沙淤积的问题。“束水攻沙”，约束河道宽窄，把泥沙冲走，加快流速。在看板里很关键一个实践就是限制在制品，通过限制并行的任务数量，可以加速价值流动速度，并且帮助我们快速发现和解决问题。第二个故事是“水落石出”，这个词最早出现在苏轼的一首诗里，另外我们也可以把它演绎成湖水岩石效应。当一个湖里有很多水，水面很高，湖中的石块都被这些水覆盖，这时即使有大的暗礁人也看不到。当水量逐步减小，一些大的石块暴露出来，如果水量进一步减少，中等石块、小石块也逐步被发现。举一个亲身的例子，几年前我去一个银行参加他们新一代核心系统建设的工作，当时要求所有人996工作制，全银行包括外包都是怎么做的。但在具体执行的时候，虽然工作确实是早9点到晚9点，有些员工中午吃饭后去散散步，晚上去游游泳，保证时间跨度是在12个小时，但实际产出是不一样的。从领导的角度来讲，要求所有的员工996，可能很难看到哪块有瓶颈、哪块有问题，因为从表面上看所有人都很忙。更好的思路也许是稍微降低一下工作的负荷，从996加班慢慢恢复到一个正常水平，之后可能会发现有的部门比较轻松正常的完成工作，有的部门还在不断的堆积工作，在主动的加班，这时候瓶颈就发现了。我们叫“水落石出”，意思是说你降低了水面，问题自然就暴露了。限制WIP的概念给我们一个启示，如果限制了我们正在并行处理工作的数量，可能自然而然会产生排队，可以看到问题到底在哪里。今天这两个故事“束水攻沙”和“水落石出”，希望大家能够更形象的理解，对大家去实施看板里的限制在制品会有一些帮助。

我们来看一个实际的看板，为什么要限制在制品？因为我们的工作来自于很多渠道，尤其是那些共享的职能部门，比如开发中心、测试中心、运维中心，我们有正常的任务，有工单、有邮件、有电话，也有老板临时派下来的紧急任务，日常工作经常会被打断，切换成本非常高。以前有过一个大致的统计，如果同时做两个任务，每个任务所花的时间并不是50%，而是40%，因为有20%在做任务的上下文切换。如果同时在做三个任务，花在每个任务上的时间只有20%，因为有40%的时间在做任务的切换。参照“束水攻沙”的思路，限制在制品，增加流速，让整个流动速度加快，并且更快的发现问题。参照“水落石出”的故事引申，因为限制了在制品，会发现某些下游环节（可能是测试、或者部署等）发生排队，发现了阻塞就可以针对性的去解决问题。图中右上角还有一些tips，如果已经产生堆积，这时候你处理的策略是什么？这里面有非常经典的一句话，"Stop starting，Start finishing"，我们要暂缓开始、聚焦完成。我前一阵在北京的望京工作，这边有个大山子十字路口，这个路口经常会堵车，那么如果交警发现双向车道已经堵死，他会怎么处理？我相信交警第一步处理的动作是暂缓开始，所有的车不要再进入这个路口，然后他要把中间已经堆积的车一辆一辆疏通掉。这就是一个暂缓开始、聚焦完成的例子。

减少批量规模。这里面有一个简单的实验，如果有十封信要发，每封信制作需要四个步骤，分别是折纸、插入信封、封口、贴邮票。有两种制作的方式，第一种方式是大批量，先折完十张纸，把十张纸统一插入信封，统一封口，再把十个封口的信封统一贴上邮票。这么做下来，所有事情完成是310秒。但如果后期发现错误，比如在第200秒要做第四个步骤的时候，才发现与之前的步骤不匹配，那么这个时候前面所有的东西都要返工。第二种方式，小批量策略，第一封信做完四个步骤再开始制作第二封信，以此类推，那么第一封信全部做完所有步骤只花费40秒时间，比方式一第一次完成交付要快8倍。如果第四个步骤发现前面的步骤有错，只需要把第一个信封的几个步骤重做，就可以在代价非常小的情况下修正错误。所以很多人认为敏捷是一种快速交付软件的技术，其实并不是很准确，应该说它是一种能够更早交付价值的技术，让我能够更早的交付软件、灵活应对变化。图中右上角有一些tips，小批量给我们很多好处，更快的前置时间，更快的发现错误和解决问题，更少的返工。通过这个小的实验，类比到IT交付价值流里，我们关注的方法叫做单件流，持续部署就是单件流的一种实现，只要代码提交入库，就自动做编译、测试、部署与发布，只要在我们的流水线里完成了所有验证，我们就认为这是一个潜在的可发布的版本。我们要减少批量的规模，频繁提交代码、频繁集成和验证，才能更早的进行交付。

减少交接数量。这也是非常关键的一个实践，代码从提交版本库到运行在生产环境要经历很多过程，有很多部门要跨越。部门之间交接是非常痛苦的事情，交接意味着有人要发出请求，有人要去响应，要做很多解释、说明，要做排期、排序，要解决冲突、做测试验证等等，整个过程是非常耗时并且痛苦的。过多的交接一定会导致整体效率的下降，只要压力一上来，各个部门都是满负荷运作，一定会出现排队，就会导致前置周期加长，为了按时交付就需要向上升级，找到老板干涉项目，临时调整优先级，这会造成更多混乱。DevOps怎么解决这个问题？最有效的方法是右下角这个图，即实现自服务，我们要建设一个自服务的平台赋能给开发。要提高整体生产效率，开发需要通过API和自服务的方式，自助完成常见的场景，比如申请环境、部署上线等。在技术价值流里关注两个词，自动和自助，自动是系统或平台自动化的帮你完成日常操作，自助是给上游的开发人员赋能，让他愿意用运维做的系统或平台完成一些任务。之前看到一个挺不错的文章，说DevOps分成四个阶段，第一个是只有Dev没有Ops，所有的事情开发自己搞定。第二个阶段是有Dev也有Ops，他们相互独立，Ops承接了开发代码之外所有的工作。第三个阶段叫Dev+Ops，Ops做了一些自动化的工具提升效率，但主要是给自己去用，开发不用。第四个阶段才是DevOps，在上游工作的开发愿意使用下游的运维提供的系统或平台，通过API自助、自动的完成相应的工作。这个描述非常容易理解，大家可以记住右下角这张图，通过自服务和自助化，破解过多交接带来的消耗。

持续识别和拓展约束。为了缩短前置时间并增加吞吐量，我们需要找到瓶颈点，只有在瓶颈点处的改进才是真正有效的。我们来看一个视频，这个视频在模拟日常工作场景，每个人有不同的容量，有的人工作容量高，有的人低一些。经常会发现工作会堆积在整个价值流里工作容量最低的那个人或者部门头上，比如这里的3号工作人员，他的在制品不断堆积，他是整个价值流的瓶颈。到了第五天时，这个人最终崩溃了，无法继续完成工作。这是约束理论带给我们的启示，我们需要找到和解决瓶颈，一般分为如下步骤。第一步，识别瓶颈。找到队列最长那个人，刚才讲到的可视化、限制WIP都是找到瓶颈的关键方法。第二步，考虑如何拓宽约束。找到能够拓宽约束点的办法，挖尽潜能。比如在瓶颈点人员很疲惫的时候有替代人员支持，或者通过自动化，人休息了但机器不停歇等。第三步，协调整个组织配合上述决策。如果有了工作堆积，按刚才讲的策略是暂缓开始、聚焦完成，上游不要再急于推过来新的工作，而是把已经堆积的工作逐步完成。第四步，提升系统约束。比如在最薄弱的环节增加资源，从本质上拓宽约束。第五步，如果这个约束解决，回到第一步，但不允许惰性导致系统约束。就是说当一个约束点解决，下一个约束点可能就暴露出来，要持续解决约束。

上面是约束理论中解决约束的方法，我们再结合实际情况，看一下IT价值流中如何解决约束。在IT价值流中，约束一般按以下四个阶段演进。首先是环境的约束。比如测试和生产环境通常需要向另外一个团队申请，可能数天数周才能搭建好。那么解决这个约束的对策，就是按需、完全自动化、自服务的方式申请环境。如果环境问题解决了，大多数情况下第二个约束会到代码的部署，经过很多手工、易错的过程才能完成代码的部署。解决这个约束的对策，就是自动化部署，目标是实现部署过程的自服务化。瓶颈点逐步转移，环境问题、部署的问题解决之后，通常瓶颈会转移到测试，测试有时候是由另外的质量控制部门去做，有可能花两周时间去准备环境和数据，然后再花另外四周做手工回归，这是无法满足快速交付要求的。解决这个约束的对策是自动化测试，让测试速度跟上代码部署速度，并且能平行进行。后面会讲到，通过持续集成、持续交付流水线，每次代码提交都会触发一个流水线的实例，这个实例运行自动化测试的时候可以并行做下一个功能的代码开发，尽量让测试的过程自动化，并且能够跟开发过程并行。测试瓶颈解决之后，可能约束点就转移到了紧耦合的架构，代码的变更都需要工程师找到经理的审批，因为大家的代码是紧耦合的，一处变更可能会影响别人，所以需要整体控制。解决这个约束的对策是架构解耦，让变更以独立、自治的方式安全进行，从而提升开发效率。架构解耦、自组织团队是DevOps里非常关键的环节，虽然之前大家谈得更多是怎么实现自动化环境配置、自动化部署、自动化测试，实际上，解耦才是大型企业处理复杂问题的前置要素。

在价值流中排除浪费。传统的制造业里有七种浪费，分别是传输浪费、动作浪费、过度生产浪费、过度加工浪费、等待浪费、库存浪费和缺陷浪费，后来又增加了一个创造力浪费。在价值流里要提升效率，就要看到软件交付过程中的浪费。这里也列举了八种，第一是部分完成的工作，比如未评审的需求文档和变更单。第二是额外的流程，比如下游不使用的文档或者不增值的审批流程。第三是额外的功能，精益创业里面有一句话，软件开发过程中最大的浪费就是构建没有人在乎的东西，也就是说范围镀金会增加不必要的复杂性、带来浪费。第四是任务切换，前面为什么说要限制在制品，因为要尽量减少任务切换的浪费。第五是等待浪费，包括等待工作所需要的资源等，这增加了周期时间。第六是动作浪费，包括需要频繁沟通的人不在一地办公。之前我走访过一些企业，有的组织启动敏捷转型的一个必要条件，就是团队的成员必须要集中在一起办公，最大化的消除异地沟通中的浪费。第七是缺陷浪费，如错误、缺失、不清晰的信息导致的缺陷。第八是非标准的工作，比如手工操作、不可重建的环境等。在价值流中要识别和解决八种浪费，才能加快价值流的流动速度。

刚才把三步工作法的第一步 -- 流动原则讲完了，下面来看第二步 -- 反馈原则。这里有四个实践，第一是在出现问题时及时发现，第二是密集解决问题、构建新的知识，第三是将质量向源头推进，第四是为下游工作进行优化。

先给大家一个背景的认知，我们工作在复杂系统之上。Cynefin框架描述了组织所处的环境。组织所处环境有五种类型，分别是简单、繁杂、复杂、混沌、失序。简单是指，因果关系是清晰可见的。繁杂是指，因果关系明确，但是需要专家研究和解决。复杂是指，因果关系可以被回溯，但不可能提前预知，这是绝大多数企业所处的状态，这里有一个关键词是Emergent，翻译过来是浮现，即解决方案是慢慢浮现出来的，而不是一次性就明确的，所以需要不断探索、不断试错、不断迭代。我们所处的环境就是复杂的环境，出现问题是不可避免的，我们要做的是在问题发现时，快速发现和解决问题。

左边的图指出，需要持续测试我们的设计和运营假设，要不断做验证，提升问题发现的速度，增加恢复能力。要建立向前的反馈循环，比如原来采用瀑布模型，有可能花费一年的时间开发一个产品，到最后一个月测试才发现有重大问题，这种反馈是非常慢的。我们建议的方式是快速迭代，持续集成、持续交付的方式。代码提交之后几分钟就能得到一个反馈，这次提交的代码如果存在错误，能快速发现、快速解决。右边的图是密集解决问题，最典范的例子是安灯拉绳，丰田在生产汽车之前生产了丰田的织布机，丰田织布机里一个非常有用的装置就叫做安灯拉绳，也就是说发现问题的时候及时通报并解决问题。在精益生产过程中都会有安灯拉绳的装置，参观汽车生产线时，可以看到有的车架上会有一个安灯拉绳装置，出现问题时可以被触发，立即发现问题而不是绕开问题。因为如果选择绕开问题，修复成本会几何上升，不断提升的技术债，让下游工作更难完成。

在DevOps实践中，持续集成是很关键的一个部分。之前业界大师Jez Humble和Martin Fowier提出了一个经典的测试，验证是不是在做持续集成。有些人说我用Jenkins，所以我在做持续集成，实际上这并不充分。这个测试有三个问题。第一，是不是每个开发人员每天都向共享的主干提交代码；第二，是不是每次提交都会触发流水线自动化的构建和执行；第三，如果构建失败，是不是可以在10分钟之内修复。为什么举这个例子，因为刚才讲了很多，有些听起来貌似是生产制造领域的一些理念，而实际上这些理念同样是持续集成里最关键的原则。比如第一个问题，每个开发人员每天至少向主干提交一次代码，这对应小批量原则，把工作批量变小，不是积累一个礼拜的代码一次性提交，而是每人每天都尽量提交他的代码，通过减少批次，提升流动效率。第二，每次代码提交触发一个自动化构建和流水线执行，刚刚讲自动化是提升效率、减少交接很关键的方法，如果每次代码提交都自动触发流水线，我们可以做到一定程度上的测试和开发并行。第三，如果构建失败在10分钟内修复，这符合安灯拉绳的原理，第一时间发现问题并解决问题，这样修复成本才是最低的。刚才我讲的这些原则或实践，就是我们每天所做的技术工作中都应该参照和映射的。

保持将质量向源头推进，并为下游优化。这里面一个很关键的点，审批流程的有效性会随着决策远离工作执行处而降低。我们倾向于工作由下游的人去审核审批，但是如果我们下游的人根本不了解我们工作的情况，这种审批就是不增值和无效的。有一些无效审批的例子，比如需要跨越另外一个团队去执行手工的任务，需要远离工作执行处、最繁忙的人进行审批，强迫审批人在缺少足够信息的情况下做决策，以及编写大量的文档，但其中很多细节在写完后会很快过期，这些都是无效的质量控制。有效的质量控制的例子，比如通过Peer Review确认变更是否符合设计，就像谷歌的代码文化，他们要求进入代码库经过非常严格的自动化测试和代码评审，另外自动化尽可能多的质量检查，就像传统由测试和信息安全部门做的那样，让开发人员可以快速测试自己的代码，甚至自己部署生产环境。图中右上角列举了一些tips，我们需要价值流中的每个人在他们控制的领域里找到并解决问题，作为日常工作的一部分。质量和安全责任要在工作执行处得到保障。精益里面有一个实践叫做JKK，就是每个工作单元100%的完成和保证自身质量，戴明博士提出的内建质量也是这样含义，质量不是测试出来的，而是在整个过程中内建进去的，我们要将质量向源头推进。

三步工作法最后一步是持续学习和实验原则。这里面提了四个实践，第一是开启组织学习和安全文化，第二是让日常工作的改进做到制度化，第三是将局部发现转为组织全局改进，第四是在日常工作中注入恢复模式。

开启组织学习和安全文化，因为我们工作在复杂系统中，不可避免会经常出错。出现错误时，很多公司处理的方法是：Name , Blame , Shame。出现错误时是一种责备和追责为主的文化。这样会导致组织内形成一种恐惧感，如果团队成员都很恐惧，怕做错事受到责备，就会选择把小的问题隐藏掉，直到问题积累到一定程度最终灾难性的爆发。Westrum模型提出组织文化的三种类型，分别是病态型组织、官僚型组织和生机型组织。病态型组织的特点是大量的恐惧和威胁，倾向于隐藏失败；官僚型组织的特点是严格的规则和流程，每个部门各扫门前雪；生机型组织是积极寻找和共享信息，责任共享，失败引发反思。在DevOps的范畴里应该构建生机型的文化，引导一个免责的故障事后分析机制，让学习过程变成良性的循环。下面这段文字我觉得非常有启发，消除责备就会消除恐惧，消除恐惧就会得到诚实，诚实才能形成预防措施。从Name , Blame , Shame转变为免责文化，收获的是能够找到问题的根因。有一个很好例子，今年1月31号晚上GitLab发生了非常重大的事故，某个运维人员在凌晨删除了数据库，大概有6小时的数据丢失，包括合并请求、评论等，而且是永久性丢失。有707位用户、5037个项目受影响。官方视频直播了恢复过程，他们主要做的是问题根因分析，采用了5W（五个为什么）的方法，分析问题并制定改进措施。但是官方也表态，造成问题的运维人员不会被解雇，而是被迫看一个很无聊的视频作为处罚。这个例子反映出DevOps提倡的是免责的文化，重点并不在追责，而是转移到根因分析和对于恢复过程的改进，这是生机型组织的明显特征。

改进制度化，局部发现转为全局改进。举两个案例，Linkedin 2003年成立，当时核心业务运行在叫做Leo的Java单体应用上，多年发展后，2010年Leo外围有100个系统，问题是核心的Leo系统经常宕机，难以发布新代码。于是Linkedin做出一个决定，通过两个月时间，完全不做新的功能开发，完全聚焦在非功能需求上，将之前积累近十年的技术债务一次性偿还，相信这是一个非常艰难的决定。这个案例给我们的启示，比日常工作更重要的，是改进日常工作，我们要把改进融入到日常的工作中。右图是将局部发现转为全局改进的案例，平安科技有一个“看板大巡游”的活动，在组织级推动看板时，每个团队会选一个人参加看板巡游活动，由一个敏捷教练带队，像导游一样带着大家到各个团队看板处观摩，评价每团队的看板，相互学习。最终巡游完成后，他们集中讨论哪个地方好，哪个地方可以借鉴，最后把学到的成果用于自己的改善。这就是很典型的例子，把局部发现转化为全局改进，比如可以让整个组织都能检索到事故分析报告，可以共享代码，让代码横跨整个组织被所有人都能搜索到。百度前几年工程能力建设的重要部分，就是建立了基于Git的代码托管平台，除了可以更容易进行代码库和分支管理之外，很重要的一点是代码的全局搜索，在权限范围内可以让更多人都搜索到所需的代码片段，促进组织的知识复用。

在日常工作中注入恢复模式。这里也有一个例子，丰田的一个顶级供货商有两条生产线，但是在Slow Day的时候会把所有的制造放在一条生产线上，用来实验增大压力、扩充容量是否会导致失败，增强反脆弱的能力。在技术价值流里也有这种模式，比如Game Day演习，模拟大范围失败，或者在生产环境注入大范围失败。经典的例子是Netflix的Chaos Monkey工具，会在生产环境随机杀进程，用来确保整个系统有强大的恢复能力。还有一个金句，“避免失败的最好办法是经常失败”，Martin Fowler也提出过，“If it hurts，do it more often”，如果某个事情让你感到痛苦，解决方案就是频繁的做。

回顾一下，今天DevOps拆书联盟活动第一期，首先介绍了《DevOps Handbook》这本书的知识体系，然后分析了DevOps的常见误区，以及理想的DevOps模式是什么样的。接下来，重点介绍了DevOps的三步工作法，分别是流动、反馈、持续学习和改进。三步工作法是DevOps实施过程所采用的底层原理和方法，后续所有的技术实践都将围绕三步工作法组织和展开。

今天的直播接近两个小时，目前已经有数千的朋友在观看，真的非常感谢大家，也希望我的分享能对大家有所帮助。请大家继续跟我们一起，建立自己的DevOps知识体系，提升技术和实践能力，在各自的组织中更好把DevOps推动落地。谢谢！