DevOps Handbook

本文译自gene kim和jez humble的"Devops Handbook"，仅用于个人学习。

image.png

更新

2017.7.26 本周更新

CH12 自助部署

CH14遥测

CH1 三个方法

引言

引言

想象下，如果产品负责人、开发、测试、运维、信息安全等相互之间不再只是相互帮助信息共享，而是作为一个整体一起工作保证整个组织的目标实现。他们通过快速的对应，迅速地部署，实现了一流的稳定性/可靠性/安全性的系统服务。

在这里，跨职能的团队的合作并不仅仅是为了实现用户要求的功能，还关心积极保障价值流中的工作平滑高频流动，而不会给IT运营及内外客户带来中断和混乱。

QA(这里指测试)、运维、信息安全等人员会一起工作降低摩擦而使得开发人员更有效率。通过给测试/运维/信息安全人员提供自动化的自助服务，过去那些必须各个团队的骨干在一起才能解决的问题通过这些工具和平台来实现，在每日的工作中，各个团队彼此之间倚赖性大大降低，这种情况下极大地提升了效率。

这使得一个小型的团队也能够快速独立的完成开发/测试/发布，将开发快速/安全/可靠地为客户做价值的转化。这使得组织能够最大化开发者的生产效率，提升员工满意度，在市场竞争中脱颖而出。

这些是DevOps所带来的结果。而在更多的现实世界中，不存在一个整体，到处是割裂的碎片。 开发和测试是水火不容的，仿佛双方都是为了证明愚蠢的是对方而存在。测试和信息安全行为的结合只是在项目的结束才会引入，一般都已经太晚基本上是走个过场，或者大体解决面上的问题。 留给我们很多手工去处理的余地，以及这些不稳定性所带来的各种副作用。不仅仅是交付时间变长，更多的是这些工作的质量往往是不可控的，因为在这种情况下，现实情况已经成为最终出场救火队员必须担负这些割裂所能带来的如同大厦将倾的趋势，在现实的世界中这些救火队员不断的扮演奇迹，但是也有很多很多的失败。成功的救火往往也能留下各种隐患，潜在以及时而出现的由此引起的问题给项目带来很大的影响，而且无法避免地影响到顾客和业绩。最终的结果就是，项目在短期目标上的失败，整个组织对IT的各种不满，以及由此带来的预算收紧，同时众多面对各种变更和不可知的质量部署的郁闷和无助的运维人员。

为了更好的理解DevOps的变革，让我们把目光投射到上世纪八十年代制造业的变革上。通过践行精益原则，制造业组织成功地极其显著地提升了生产效率，降低了交付时间，提高了产品质量以及客户满意度，成功的企业在残酷的市场中赢得了一席之地。

在这场改革开始之前，制造行业平均交付时间为6周，而且只有少于70%的订单能够按时交付。而到2005年，随着精益实践的广泛推行，平均交付时间已经少于三周，而且95%的订单能够按时交付。那些没能跟上的组织失去了市场份额，他们之中的很多最终被淘汰出局。

软件行业是如此的相似，在上世纪七八十年代，大多数项目需要一到五年才能实现完成开发和部署，经常伴随着极其高昂的成本，而失败也是会带来极其严重的影响和后果。

随着Agile的践行，新功能的开发已经降到周或者月为单位了，但是部署到生产仍然需要数周甚至数月，而且经常还会伴随灾难性的后果。

接下来随着软件和硬件的不断升级，带来了永不停息的服务的普遍实施的可能性，而Cloud更是将其全面推展开来。

DevOps的引入更是使得这些需要部署到生产的服务变成了以小时甚至以分钟计的寻常操作，很多企业在这轮变革中已经先行，部署对他们来说已经是日常和低风险的的作业。借助于DevOps，这些企业甚至能够在实际的环境下现行验证他们的Idea，以确认哪些Idea能够带来最大程度的效益，以此来决定所要开发的功能，而这些功能最终将非常安全地被部署到生产环境之中。

image.png

时至今日，DevOps原则的践行已经在一日部署上百甚至上千变更。举个极端的例子Amazon在2011年每天大约能够完成7000部署，而到了2015年这个数字上升到了13万次每天。

跟上个世纪八十年的的制造业变革何其相似，这个时代的软件行业已经在变革。快速的市场对应以及不懈的探索和努力已经成为必备的要素。无法实现的企业注定要付出失去市场的代价。就像2016年DORA的DevOps调研报告的研讨会中提到的那样，你可以不相信那些看起来好像不太符合常规逻辑的速度，但是这些确确实实的发生在我们的身边。

这个时代，不管在哪个领域中进行的商业竞争，对价值的交付最终都将依赖于科技价值流的实现。说得再简单一些，就像通用电器的CEO Jeffrey Immelt曾经说过的那样，“任何一个领域和公司，如果他们还未曾将软件引入到他们的核心业务，他们注定会被颠覆”。这不是危言耸听，技术对于任何组织都是用于赢得竞争一席之地或者生存下去的极为重要的工具。

了解了所有的这一切，让我们来看一下这些问题的征兆，以及为什么会发生这些问题，为什么没有强有力的干预，这些问题会随着时间变得愈发严重

我们需要改进

大多数企业需要数周甚至数月的准备来部署他们的产品，他们也不能定例地低风险地交付部署新的功能特性，甚至他们中的很多都认为，这么快的部署需求本身就是一件很哗众取宠的事情。但是和当初制造业的变革一样，这场革命实际上已经无声无息地展开了，在这个时代快速和高水准的服务已经是必要条件，已经有很多优秀的企业先行一步，掀起了变革的浪潮。没有危机意识的企业在上个世纪八十年代应该也有很多，没有奋起直追的大多数在那场变革中已经消失在滚滚洪流之中。部署只是海面上的冰山，从工具到流程，从组织结构到文化，有太多的环节需要注意，而改善也已经刻不容缓。

长期且核心的冲突

几乎在每一个IT组织中，开发和运维之间都会产生一个“下行的恶性循环”，使得产品或功能交付的时间增加，质量下降，更为糟糕的是那与日俱增的技术债务。

技术债务是Ward Cunningham最初提出来的一个术语，像财务债务一样，技术债务描述了我们所做的决策可能会引起的逐渐累积的问题，随着这些债务的不断增加，解决这些问题也会花费越来越多的成本和时间。

开发和运维产生隔阂的原因在于分工和目标的不同。IT组织需要满足很多目标，其中有两个必须同时满足：

应对快速变化的市场态势

给客户提供稳定、可靠、安全的服务

开发团队为快速将产品推向市场作出努力，当然稳定和安全等也是必要的，在现实的世界中，这些更多是作为非功能性要素不会出现在大多数的开发人员的视线范围，而且在大部分情况下这些也不是交付的要素。运维则需要负责稳定这个要素，两个团队，两个目标，两套KPI，相互冲突，无论是在这个地球的哪个国家，类似的隔阂和问题都一直在出现。

制造业变革运动的奠基者之一的Goldratt将这种情况称之为核心的固有冲突（the core, chronic conflict）, 正是这种冲突带来了螺旋下行的恶性循环。

下行螺旋

这种螺旋下行的恶性循环产生在现实世界中往往有下面三个简单要素。

运维的目标是保持应用程序和基础框架持续运行以使得组织能够交付服务给到最终顾客。但是由于应用程序和基础框架及其复杂，缺少文档，以及难以置信的脆弱，这使得运维人员每天都必须面对和处理的事情。当我们救火的时候总是想再抽空顺便就把这些个问题修复，但是一直没有抽到空，而这样的技术债务则在不断地增长。

而且，当这些日渐脆弱的系统所支持的是创造利润的关键业务时，问题会变得更加复杂，本来能够对应的问题也会因为担心和忧虑以及没有非功能性机能的保障而信息不足。问题越积越多，一个小小的改动，最终都可能引起多米诺骨牌效应。所以每次只能最少限的修改，只能头痛医头，脚痛医脚。CSA根本问题分析对应？分析后有钱改么？敢改么？这样的结果造成了大家每日都在接触到的现实世界的一幕一幕。

理想的项目，缺钱给钱，缺人给人，项目范围稳定，变更管理有序，在Q（Quality）C（Cost）T(Time)三角进行管理的经验丰富的PM也游刃有余。

而现实的世界是，很多项目是要钱没有，资源有限，根本无变更管理。即使是这样的项目也在抢着做的情况下，基于各种场景，很多难以兑现的许诺就这样被添加了。比如项目管理上称之为镀金的行为，实际的项目中往往是给强势的外部以真金白银的无底线自残。

然而最终这些许诺会压到开发团队那里，给原本就不太宽裕的项目进度狠狠地来上一刀。这些任务的往往兼具难度大/工期紧/经费少/人手不足等诸多明显标志，完成任务已经是精疲力竭，至于技术债务，自然会进一步的积累不断升高。

螺旋下行的恶性循环还差最后一根稻草。只需要在来一点，每件事情都复杂一点点，每个人都再忙一点点。一点一点，每个人都变得越来越忙，工作时间越来越长，交流时间越来越短，任务列表越堆越高。每个人的工作都和别人的工作紧密相关，一个小的动作都可能带来很大的失败，自然而然，对变更充满畏惧和排斥。工作需要更多的沟通/协调/批准，各个团队必须等待更长一点时间以确保所依赖的部分已经完成。扯皮和吵架变成为了自保的必备生存技能。

这种情况下，部署的时间越来越长，更要命的是，开始变得容易出问题了，而对这些问题的救火行为消耗了大量的时间和成本，使得原本可以着手对付那高垒的技术债务的最后一丝机会也丧失殆尽。到了这个时候，就是英雄辈出的时代，对待那基本上已经困难重重的系统，非常规的能力出众的个人或者小的团体的非常规的努力，保证系统能够运行的同时继续推高系统的技术债务，为下一次爆发提供了良好的条件。

为何会形成下行螺旋

这种情况对我们来说是如此常见，知道了下行的恶性循环是如何发生的，但是为什么会这样普遍存在呢？

每个IT组织都有快速和稳定两个相反的目标，最终形成了Goldratt所说的核心的固有冲突，为这种存在提供了基础。

另外还有一点，现代社会中，不管被意识到与否，各行各业的任何一家公司都是科技公司，科技在各个行业的渗透已经超出了大多数人的想象，思维方式的转变势在必行。

正如一位资深的软件负责人所言：“所有的公司都是科技公司不管他们自己认为他们自己在什么领域。一家银行也只是有着银行营业许可的IT公司而已。”在作咨询的时候，我们也经常会跟客户说, 在这个时代，”Your software is not part of your business, it is your business”，其实都是一样的道理。是否最终的发展像Jeffrey Immelt所说的那样可能还需要时间的检验可以拭目以待，但是对任何企业来说这都是一场输不起的赌博。

由此导致的成本

在下行的恶性循环中的很多人，被迫面对怪兽一般的系统，那种忧郁/孤立无援/无助甚至绝望的心情估计只能是如人饮水，冷暖自知了，由此带给个人家庭的伤害也是无法估量的。但是这个世界花在IT上的成本确是清楚的。比如IDC和Gartner都曾发布过，2011年全球花在IT上的钱大体是GDP的5%，这个数字高达3.1万亿美元。试想一下即使一个很小的比例与这3.1万亿一起计算，在经济上付出了多大的成本不言自明。

DevOps道德规范：有更好的方法

与传统方式不同，DevOps协调各个部门向着组织共同目标协同努力同时改善工作的环境和文化，正是因为如此，它才能在这么短的时间内得到了众多人群的青睐而得到了迅速的发展。

用DevOps打破下行螺旋

理想状况下，小型的开发团队也能实现自己的机能特性，在类生产环境中验证正确性，能将他们的代码快速安全地部署到生产环境。代码的部署是可预期的日常行为，部署不再是必须等待到周五下班然后开始倒计时在周一开始之前必须完成的噩梦。运维人员终于可以在工作日进行例行的部署作业。而客户对此一无所知，只有在他们发现新的可用机能或者被修改好了的bug时，才会意识到部署的动作已经完成。

在整个过程之中，每个操作都需要有快速的反馈，每个人都能快速地看到他们的动作所带来的影响和结果。当变更的代码提交到版本库中之后，自动测试开始在类生产环境中运行以确认此次变更是否达到能够部署到生产环境中的标准。

自动测试帮助发现更多的问题而不致于留下很多的技术债务，通过自动测试的确认，发现的技术债务立即解决而不是等待日后再行处理。

不同于传统的非黑即白的部署，经过测试的代码，可以早早的放到生产环境之中，除了内部用户和一些被选择的特定用户，其他所有用户均此时均不会意识和看到或者使用到此部分部署的机能，而且也不会被此部分功能所影响。这样在生产环境通过内测或者小部分用户的试行方式极大的提高了信息安全相关的保障。

即使出现问题，也可以快速回滚到上一个版本以避免无法对外提供正常服务。整个部署是可控的，可预测的，可回滚的，低风险的。

相比于畏惧出错/重于惩罚的文化，高度信任和协作的文化更加被推崇。只有这样，有些问题点才会被提出来而不是装作不知道被藏起来。毕竟，我们只有先看到问题才能去解决这些问题。同时即使当问题发生的时候，启动的也不是问题追责机制，而是无追责的事后检讨或者反省活动，不是为了惩罚某人，而是为了避免下次同样的问题再次出现，组织级别的学习和成长使用这种方式不断展开。这是一个理想的状况，各种企业都在使用自己的方式去实现自己的DevOps。

DevOps的业务价值

正如DevOps调研报告中所提到的那样，通过对多达25，000职业技术人员的调研，发现践行了DevOps的高效能人员相比于低效者，在很多方面都展现出很大的优势。比如:

流量指标

代码和变更部署效率(频率高30倍以上)

代码和变更部署前置时间

可靠性

生产部署成功率

平均恢复时间

生产效率、市场份额、利润目标

市值增长

规模开发线性等效(DEVOPS HELPS SCALE DEVELOPER PRODUCTIVITY)

当开发人员的数目增加的时候，由于规模效应所增加的沟通/协作等额外作业不可避免的对个体开发者产生比较明显的影响。就像人月神化中所解释的那样，当项目迟延时，增加开发者时，不但会降低个体开发者的效率，同样会降低整体的效率。

而DevOps则从另外一个角度，告诉我们，当我们有合适的架构，合适的技术实践，合适的文化氛围，小的团队也能高效地完成作业。同时，大规模的团队也同样适合DevOps，正像google前管理者Randy Shoup在google中所观察到的那样，“数千人的团队，架构和实践依然能使得小团队像初创公司那样产生不可思议的超高效率”。

2015年DevOps报告清晰地展示了当人数上升时候践行DevOps的高效能人员所组成的团队依然能够保证着小团队的线性增长效率。

image.png

方案的普适性

大量证据显示上述问题和解决方案是普适的。

第一部分 三个方法

CH1 敏捷、持续交付和三个方法

制造业中的价值流

在精益中一个最基础的概念就是价值流。价值流的定义是“the sequence of activities re-quired to design, produce, and deliver a good or service to a customer, including

the dual flows of information and material”。

在制造业中，从接到客户订单的那一刻起，价值的流动用眼睛就能清晰地看到。碓在工厂里面的原料，开来开去的叉车，精益运动带来的价值流改善甚至直接能够从堆放的WIP半成品的高度来进行确认。

技术价值流(THE TECHNOLOGY VALUE STREAM)

==注: 下文都用IT价值流代替技术价值流==

在科技领域看到的堆放的原料和叉车告诉我们价值流动的无处不在。在软件开发等科技领域，价值流同样存在，而且制造业的原则和经验同样适用。同样是接到由业务部门提供了的明确的需求定义，开发，测试，部署，交付给运维，最终价值的流向同样流向了客户。区别于传统制造业的产品，一般科技领域的价值流最终交付的形式更多是以服务的形式进行的。

价值的体现只有在我们开发/测试了的软件运行在面向最终客户的生产环境之上时，在IT领域价值的流动才最终完成，在那之前也都只是WIP而已，这个就是为何我们一直在强调交付时间。而这些也是在最近十年之内互联网公司诸如Amazon作的比较好的一个地方。

虽然交付时间非常重要，在DevOps中，交付时间也不是全部。“快”很重要，但是可靠性/稳定性/扩展性/安全性同样重要。DevOps追逐的快速价值流动，是建立在不会因此而带来服务中断/安全事件等混乱性事件的基础之上的。

聚焦在部署前置时间

image.png

定义前置时间(Lead Time)和处理时间(Processing Time)

客户感知的是lead time, 因此lead time才是核心指标。process time可以体现处理效率，但仍然会因为队列、等待等各种原因导致很长的lead time。

deployment lead time是指从代码提交到上线之间的时间。

一般情况部署前置时间需要数月

image.png

devops理想情况是分钟

image.png

C/A指标

C/A: Complete / Accurate .是一个用来衡量REWORK的指标。一般在DevOps实践中，比较常见的会计算出在某一个交付周期之内，所作的全部的Story Points和被客户接受了的Story Points，而没有被接受的则表明由于各种原因将会产生的REWORK。

DevOps三个基本方法

在《凤凰项目》中总结的三个方法是在DevOps实践中提炼出来的基本原则。

image.png

第一个方法 流动

从左到右，从业务需求到交付客户，贯穿着从开发到运维的这条正向的通路。在这条原则的使用中，我们经常使用很多方式进行实践以期达到交付价值的单位时间最大化。这些实践包括工作可视化、减少批次和工作间隔，内建质量减少缺陷，持续全局优化等。

第二个方法 反馈

The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and

recovery. By doing this, we create quality at the source and generate or embed knowledge where it is needed—this allows us to create ever-safer systems of work where problems are found and fixed long before a catastrophic

failure occurs.

第三个方法 组织学习

化方面主要从两个方面进行推进，持续试验和持续学习。在DevOps实践极大降低了生产环境中的实验性的尝试可能带来的风险的前提下，鼓励勇于尝试和创新以及高度信任的企业文化，持续试验结合持续学习，推动整个企业一个整体的方式不断推进。

本章小结

略

CH2 流(flow)的原理

快而且平滑

可视化

软件开发和制造业的价值流在可见性方面差别很大。制造业的库存/存货移动的时候是可见，费力而且相对较慢的。而软件开发移动不可见，而且非常简单，只要点点鼠标。这样在哪个工作中心(work center)阻塞或堆积就不容易发现。而且因为简单，工作可以在不同工作中心见来回反复，或者将问题带到下游，甚至到生产才能发现问题。

看板就是很好的可视化手段，工作可视化后，就容易管理，以加快流动速度。看板可以覆盖整个价值流，工作完成的标志是上线运行，因此看板代表的是整体价值。而干系人也容易确认工作的优先级。

image.png

限制在制品(WIP)数量

制造业的工作相对常态化，根据计划安排生产。而软件开发通常动态程度高的多，因为要满足不同干系人的要求，各种渠道进来的请求，和各种紧急任务。

制造业的工作中断是高可见和高成本的，因为要中断现有工作，清理半成品并启动新的工作。因为可见，所以会致力于尽可能减少中断。

而软件开发的中断的后果不是显而易见的，因而更容易被终端，哪怕成本可能比制造业还高。比如工程师的多任务切换，因为要重建上下文，包括认知规则和目标，会带来很大成本。

有研究显示，高度认知复杂性的工作切换，效率损失是非常大的。

因此限制在制品数量是非常重要的，可以减少上下文切换，加快流动，并让阻塞可视化。

小批量

大批量导致了WIP的层次抬高，流动的变异性扩大。因此会延长lead time，和推迟问题的发现。越早发现问题，返工成本越低。此外，批次（变更）越大，诊断问题和修复也越难。制造业的理想是单件流，对应软件开发的持续交付，即每次代码提交，都能触发集成、测试和部署到生产。

image.png

减少跨团队交接

工作夸团队交接需要大量的沟通。

每一项依赖其他团队的工作都会造成潜在的排队，造成lead time的延长。

移交还会造成知识的丢失

解决办法是组成能够独自完成交付的cross-function团队，自动化绝大部分工作。这样通过减少排队和无价值工作提高流动速度。

持续识别和解决约束

不在瓶颈出的改进都是幻觉，事实上可能让瓶颈变得更加严重。非瓶颈资源的利用水平不是由自身潜力所决定，而是由系统的约束来决定。瓶颈损失1小时，相当于整个系统损失1小时。非瓶颈上节约开1小时，无实际意义。

约束理论五步法：

第一步，找出系统中存在哪些约束。

第二步，寻找突破（Exploit）这些约束的办法。

第三步，使企业的所有其他活动服从于第二步中提出的各种措施。

第四步，具体实施第二步中提出的措施，使第一步中找出的约束环节不再是企业的约束。

第五步，回到步骤1，别让惰性成为约束，持续不断地改善

devops转型中的主要约束

环境创建，解决办法是按需创建环境和自助服务

代码部署，解决办法是自动化部署操作，知道全部自动化，开发可以自助发布

建立测试环境和运行，解决办法是自动化和并行测试

紧耦合的架构：解决办法是将架构松耦合，以便让变更更安全和自主，提高开发生产率。

消除价值流中的艰涩和浪费

软件开发中的浪费

部分完成工作

额外的过程，不创造价值的过程，如没用的文档和评审

额外的特性

任务切换

等待，延长了cycle time(cycle time常指process time，即到了工作中心还要等在资源以便完成工作)

移动

缺陷

非标准或人工工作，比如不可重建的服务器、测试环境和配置。理想情况下，==所有对运营的依赖，都应该被自动化、自服务，按需获得==。

英雄主义或超常发挥

CH3 反馈的原理

技术工作大都是面对复杂系统，处于随时遇到严重后果的风险中。我们常常在直到发生生产系统重大故障时才发现问题，在客户数据丢失时才发现有安全漏洞。

因此我们需要一个覆盖端到端价值流和整个组织的，快速、频繁和高质量的信息流，包括反馈(feedback)和前馈(feedforward)循环。以便我们在问题还小时，修复代价低而且容易时即使发现和修复，避免问题导致严重后果，并创造能融合到未来的工作中的组织学习。这样失败和事故发生时，我们视为机会，而不是惩罚和指责的理由。

在复杂系统中安全地工作

复杂系统就是组件的交互导致的系统行为，无法单纯地用组件本身的行为来描述（注：比如蚁群和蚂蚁）。在复杂系统中，两次同样的行为，没法预测到或必然会有同样的结果。因此静态的检查表和最佳实践，对于防止灾难的发生是不够的。

复杂系统中的失败是内在和不可避免的，因此我们要创建一种安全的工作环境，能够免于恐惧，相信错误会很快发现，在造成严重后果很早以前，比如工伤、产品缺陷或者负面的客户影响。

我们没法构造一个彻底安全的环境，但如果满足以下四个条件，那我们在复杂系统中的工作就会安全些。

复杂工作收到管理，设计和运营中的问题得以暴露

问题一拥而上解决，新知识得以迅速构建

新的局部知识对整个组织利用

培养持续提升这些能力的领导

在问题发生时就看到

在安全工作中，我们必须持续地测试设计和操作假设。以此创造一种信息流，全面、及时、快速地反映情况，并尽可能清晰地反应因果关系。越快地验证假设，就能越快发现和修复问题，增加我们学习和创新的弹性、敏捷和能力。

在彼得圣吉的第五项修炼中，描述了反馈环是组织学习和系统思考的关键部分。高 绩效的生产运营，总有快速、高频、高质量的信息流伴随价值流。每个操作都被度量和监控，每个缺陷或显著偏差都被即使发现和处理。这是形成组织学习和提高的基础。

传统的软件开发，反馈周期太长。我们的目的是要建立一个涵盖所有阶段和所有角色的反馈、前馈环。这包括自动化的构建、集成和测试，还包括普遍的“遥测”技术，以便快速获知生产系统运行出现预期之外的情况。快速反馈不仅仅是为了快速发现和解决问题，还有利于未来规避重复产生问题。这样才能提高我们工作系统的安全性和质量，以及创建组织学习。

拥抱和解决问题以构建新知识

显然，仅仅检测预料之外的情况发生是不够的，当问题发生时，我们得一拥而上，动员所有需要的人来解决问题。

阻止问题流向下游，因为这会导致修复成本上升和技术债务累积。

阻止工作中心开始新的工作，因为这会给系统引入新的错误。

如果问题没解决，工作中心在后续操作中会出同样的问题，导致更多的修复工作

这个实践有点违背管理尝试，即我们会在局部问题发生时停止整个生产线。（注：对应持续交付管道出问题时，干系人都要停下手头工作来解决）。然而，swarming 使能学习。它避免关键信息随着记忆的淡忘和环境的改变而丢失。这一点在复杂系统中尤其关键，因为问题的发生纠缠在人员、过程、产品、位置、环境等各种因素的交互中，时间久了，难以重建当时问题发生时的情况。

Swarming 是实时识别、诊断和处理问题的原则，也是一种PDCA循环。

参"Implementing Lean Software Development From Concept to Cash"

Autonomation (Jidoka) ==work is organized so that the slightest abnormality is immediately detected, work stops, and the cause of the problem is remedied before work resumes. Another name for this critical concept, and one that is perhaps easier to remember, is "stop-the-line." Autonomation means the organization has reflexes in place that will respond instantly and correctly to events without having to go to the brain for instructions.条件反射==

不断推动质量向他的源头靠近

不是指价值流的上游下游，而是指谁负责执行工作，内建质量就要放到哪里。实际上指自己完成工作，自己检查，自己修复，这依赖大量的自动化和自服务。客观上就是指工作向开发转移，因为开发就是源头。

低效的质量控制

让另一个团队完成枯燥、易错、手工任务（本来可以自动化并有自己团队完成）

让远离战场并不了解情况的”忙人“做决策

生产大量文档，而这些文档很快就过时了

将一大坨工作交给其他团队处理货审核，然后就干等反馈

我们需要在价值流中所有人把在他们自己领域发现和解决问题作为他们的日常工作。这样，我们才能推动质量、安全职责、决策到工作执行的地方，而不是依靠“远处”的主管的审核。我们用同行评审来保证设计质量，我们将大部分原来由QA或安全部门执行的质量检查自动化，这样开发人员 就不需要请求或计划这些测试，而只要按需执行，这样开发人员可以迅速执行他们自己的代码，甚至部署到生产系统。

这样，质量成为大家共同的责任，而不是不同部门的各自的职责。信息安全不只是信息安全部门的工作，就像可用性也不只是运维人员的工作。

让开发人员共担他们所建设系统的质量职责，不仅提升了产出，还加快了学习。

为(流水线)下游客户做优化

精益将客户分成两类，外部客户和内部客户。精益认为我们的下游是我们重要客户。

在技术价值流中，我们是通过为运营做设计实现为下游做优化，这样非功能运营需求优先级和用户特性是一样高的。

本章小结

在技术价值流中，创建快速反馈对获得质量、可靠性和安全是非常关键的。我们通过在发生时立即发现问题、一拥而上解决问题构建知识、将质量推向源头，并为下游做优化来实现。

CH4  持续学习的原理

在制造作业中，工作是严格定义好的，工人没有能力将提升和学习融合到日常工作中，他们的提高方向是成为一块块没什么区别的砖头。这样的环境通常伴随这恐惧和低新人，犯错误是要被惩罚的，提建议会被当做刺头。但在高绩效的组织中，却需要积极推动学习，工作不是严格定义的，而是动态的。

在技术价值流中，我们的目的是创造高度信任的文化，告诉大家我们都是在日常工作中需要承担一定的风险的终生学习者。我们从成功和失败中学习，识别不起作用的措施，强化起作用的措施。同时，局部的学习会转化成全局的提升，新的技术和实践会被整个组织应用。

我们为日常化的持续提升、学习预留时间。我们向我们的（工作）系统中施加持续提升的压力，甚至在受控条件下注入失败到生产服务中，以提高弹性。

通过创建持续和动态的学习系统，我们让团队快速和自动适应永远在变化的环境，这帮助我们获得市场成功。

学习型组织及安全的文化

在复杂系统中工作，我们无法对我们行为的后果进行完美的预测。这就是我们会不期而遇各种预期之外的事件甚至严重故障，哪怕我们很谨慎。

我们要创建一种免于指责的事后分析。

略。。。

对日常工作的改进行为制度化

团队通常没能力或者不愿做过程改进。这不仅导致团队持续受害，而且情况还会恶化。==因为混沌和熵增，过程如果不改进，就会随着时间推移而退化，而不是保持不变。==

我们通过显性地保留时间来偿还技术债，修复缺陷，重构和改善有问题的代码和环境，以提升日常工作。我们在每个开发间隔中留有时间或计划改善行动(kaizen blitzes)，期间工程师会在团队中自组织修复他们想修复的任何问题。

这些时间的结果是，每个人都在日常工作中发现和修复他们控制领域问题。经过数月（或年）积累，我们开始有精力处理不那么明显的问题。通过就检测和修复不那么明显的失败信号，不仅我们修复问题容易而且成本低，而且影响也小。

==注：这就是我们说的，消除技术债务要显性地安排，上看板。==

将局部的发现变成整体的改进（不做局部优化）

我们需要有一种机制，将局部的学到和发现的知识传播开，使得整个组织收益。即，我们需要将个人或团队通过经验变得专业的隐形知识，变成明确和显性的知识，以便让他人通过实践也变得专业。

在技术价值流中，这些机制包括让无指责时候分析报告容易搜索，创建共享的代码库，以此共享内嵌了组织最佳知识稽的代码、库、配置，而且容易应用。

==注：将大部分操作性工作都自动化，团队或个人可以自服务，这样积累在自动化过程汇总的知识就得到了传播、应用。==

在日常工作中注入弹性模式

低效的组织通过增加buffer来避免中断。比如为了避免工作中心空闲，就通过在每个工作中心增加库存。这导致了WIP增加。为了避免设备故障导致中断，又要购买更多固定设备和雇佣更多的人。

而高效的组织，是通过不断提升日常运营水平，持续引入提升的绩效的张力，同时在系统中导入更多弹性来达到同样甚至更好的结果。这就是反脆弱性(antifragility)。

在技术价值流中，我们也可以导入同样的张力到系统中，以寻求持续降低部署前置时间，提升测试覆盖率，降低测试时间，甚至必要时进行重构，从而提升开发效率和可靠性。我们还可以"game day"练习，以此演练大规模失败，比如数据中心断电。也可以在生产系统中注入越来越大的失败（如chaos monkey，随机杀进程和服务器)来保证我们有所希望的弹性。

注：系统有一定的弹性应对冲击、突发事件。日常的工作就像割草，高的割掉后逐渐越割越低。

Leader应该强调学习文化

传统领导的职责设置目标、分配资源，以及建立关联的激励机制。领导者通过“制定正确决策”来领导。越来越多的证据显示，光靠领导者指定正确决策无法获得伟大，而是应该通过领导角色创造一种让团队发现伟大的环境。领导者和一线团队成员互相需要，前者不够靠近具体工作，没有做所有决策需要的细节。而后者没有足够宽的组织背景，以及推动他们工作领域外的变革。

领导者必须提升学习的价值，教会别人解决问题。Mike Rother将这个方法正式化，并称之为“coaching kata”。包括设立目标，并通过迭代的方法解决问题和障碍，以达到这个目标。（参考《丰田套路》第三部分 改善套路 第四部分 指导套路，在丰田讨论中，重点说明了目标状态和目标的区别，要达到的目标状态而不是目标，而本书没有对此进行区分。）

目标状态和目标.png

领导者可以通过问这些问题来指导大家：

你最后一步做了什么，发生了什么

你从中学到了什么

你现在具备什么样的条件了

你下一个目标条件是什么

你现在正在努力移出什么障碍

你下一步要做什么

你期望的产出是什么

我们什么时候能check产出

本章小结

第三种方法的原理说明了组织学习的价值，建立高信任和跨职能的信任， 接受失败总会发生在复杂的系统中，并使之成为可以接受的问题进行讨论，这样我们就可以创建一个安全的工作系统。同事，还需要将改善日常工作制度化，局部的学习变成组织学习，以使整个组织可以使用。 不断地向我们的日常工作注入张力，将日常工作中进行改进制度化。

虽然不断学习和尝试是第三种方法，但和第一第二中方法，流和反馈交织在一起。建立流和反馈也需要迭代和科学的方法。

结果是更好的绩效，更好的弹性，更高的工作满意度，提升的组织适应性。

第一部分小结

略。

第二部分 从哪里开始

怎样决定我们在哪里开始devops转型？哪些人要参与？怎样组织团队、保护他们的工作容量、最大化他们成功的机会？第二部分就是回答这些问题。

CH5 选择从哪个价值流开始

新项目还是遗留项目

都可以，也都需要。

System of record 还是 System of engagement

==systems of record==, 运行我们业务的ERP类的系统（如MRP, HR, 财报系统), 交易和数据的准确性最重要。

==systems of engagement==，面向客户的系统如电商系统，性能最重要.

前者聚焦在doing it right，后者聚焦在 doing it fase。这两者通常是冲突的，但从devops报告上看到，高绩效的组织同时满足高流量和高可靠性。

实际上这两类系统往往相互依赖，所以现在不区分这两者，都要又快又好。

找到有创造性和同理心的团队

不要一开始全面铺开，找原因采纳新想法的团队，参技术应用曲线，跨越鸿沟。

技术应用曲线-跨越鸿沟.png

推广到整个组织

找到有创造力的早期采纳者

推广到更多团队，吸引跟风

识别阻抗

本章小结

从小范围开始，重点突破，形成支持团队。扩大实践，获得认可，吸引跟风，以此推广到整个组织。

CH6 理解我们的价值流，使之可见，并扩展到整个组织

本章初略过一下，当看完全书后再决定是否要细看。

找到支持我们价值流的团队

画出价值流映射以便看清工作

成立专注的转型小组

对目标达成共识

控制提升计划尽可能短小

小步快跑，好处很多。

调整优先级甚至重排计划很容易

减少工作和改进的间隔，缩短反馈环

更快将所学知识应用到下个迭代

减少提升所需的激活能量

尽快实现改进让日常工作变得有意义

减少项目还没来得及展示成果就被关闭了

预留20%的人力给非功能需求和减少技术债务

用户不可见的价值.png

提升工作可见性

利用工具规范行为

人类学家将工具描述为文化产物。 在发明了火之后，任何关于文化的讨论都必须与工具有关。DevOps也一样，需要用工具塑造文化和加速行为改变。

统一的backlog

chat rooms(有这么重要吗？难道和我们现在用的IM工具有不一样特性和用法？)

==注：chat rooms有好处，也会导致团队成员工作频繁被打断。要平衡利弊。==

本章小结

CH7 如何用康威定律设计我们的组织和架构

组织原型

问题常常由职能组织引起

鼓励市场导向的团队(为速度进行优化)

让职能线面向工作

测试、运营和安全是每个人每天的工作

鼓励团队成员成为通才

以服务和产品为导向，而不是项目导向

根据康威定律设计团队边界

创建松耦合的架构

本章小结

CH8  如何将运营整合到日常开发工作中，以提高产出

具体方法包括：

为服务团队中的开发人员提供自服务能力，以提高开发效率

把维护工程师内嵌到服务团队中

如果做不到嵌入，则为服务团队指定联络人

为提高开发人员效率创建共享服务

将运维人员嵌入到服务团队

给服务团队指定联络人

将运维集成到开发仪式中

邀请运维参加开发站立会

邀请运维参加开发回顾会

让相应的运维任务在看板上可见

本章小结

第二部分小结

第三部分 流(flow)的技术实践

参《持续交付 发布可靠软件的系统方法》

CH9 创建持续部署流水线(pipeline)的基础

为了创建从开发到运维的快速、可靠的流，我们需要在价值流的任何阶段使用类似生产的环境。更进一步，这些环境要能够自动化地创建，理想情况是用版本库中的脚本和配置信息，按需创建，完全地自服务，不需要运维的手工操作。我们的目标是确保我们能够依靠版本库重建生产环境。

很多情况下，我们检查在类似生产环境下应用如何执行的唯一时机是部署到生产--这对解决问题已经太晚了，很难避免影响客户。

按需创建开发、测试、生产环境

为整个系统创建唯一事实的仓库

以前版本库是给开发用的，用于存储源代码和文档。但是给客户交付价值既包括代码，也包括环境。因此环境也需要进行版本管理。换句话说，版本管理是价值流上每个角色都要做的。通过将生产制品纳入版本控制，版本库可以让我们能够重复可靠地重建生产系统的所有组件，包括应用、生产环境、准生产环境。

为了保证能够在重大事故后能够重复、快速地恢复生产环境，需要检查以下几点：

所有应用代码和依赖，如库、静态内容等

所有创建数据库模式的脚本，应用引用的数据

所有环境创建工具和制品，如虚拟机镜像、puppet或chef的recipes

所有自动化测试和人工测试脚本

所有用于代码打包、部署、数据库迁移和环境开通的脚本

所有项目制品，包括需求文档，部署过程，版本说明等

所有云配置文件（如有使用公有云的话）

创建提供各种服务的基础设施所用脚本和配置信息(如企业总线、数据库管理、DNS zone file、防火墙配置规则，以及其他网络设备)

可以有多种类型的仓库 用存储不同的对象和服务。

我们不仅要能够恢复生产系统，还要能恢复预生产系统和构建过程，所以还要将构建过程依赖的所有东西都放入版本库，比如构建工具和其所依赖的环境。

对环境进行的版本控制是IT绩效的预测因子。因为对应用和环境进行版本控制，不仅有利于看到变更，有利于定位问题，更有利于故障恢复。而且环境中可配置的内容大于代码，因此环境更需要做配置管理。

让基础设置重建比修复来的更简单

将开发完成的定义修改成包含在准生产环境运行的内容

本章小结

CH10 快速和可靠的自动化测试

在这个点上，开发和QA在日常工作中就会用类生产环境。我们将代码提交后的特性验收，集成到了在类生产环境的自动化测试中。

自动化测试不仅仅是获得快速反馈（容易定义问题），而且还解决另一个问题，即随着业务代码的增加，用于测试我们代码的时间和成本原来越大，这对任何技术组织来说都是不可扩展的业务模型。

持续构建和测试，将代码和环境集成起来

我们通过将开发运行自动化测试作为日常工作，实现内建质量的目的。实现的手段是部署流水线(deployment pipeline)。部署流水线确保每次提交代码将自动地在类生产环境中构建和测试。通过这个手段，我们可以在变更引入时就发现构建、测试或集成错误，确保我们快速解决问题。我们因此确保总是除以可部署和发布状态。

我们需要一个专门的环境用于运行自动化构建和测试过程。这很关键，理由...

图13

部署流水线和版本控制一样，都是最基本的基础设施。

构建信息还可以用于审计和合规检查，因为这些报告在日常工作中一直在产生。

在持续部署流水线基础设施中，我们要实践持续集成，要点有3：

完整可靠的自动化测试，用于验证(validation)我们处于可部署状态

如果验证失败，中断整个生产线

小批量、主干开发，而不是长期特性分支

创建快速可靠的自动化验证(validation)测试套件

为什么得这么做？因为即使是每天夜间构建（自动化测试），也是不够及时的。比如夜间构建失败，次日才发现，需要花时间检查，从几分钟到几个小时。而且既可能是代码，也可能是测试环境的问题，这样追溯问题，发现又是很多次提交了（比如整个白天的提交），快速反馈被打破了。

就是这三类测试，从快到慢依次是：

单元测试：代码片段测试，数据库也是被stub out的

验收测试：比如验证user story正确实现，功能的回归等

集成测试：跨生产系统和服务能够正确交互

注：此书将集成测试定义为跨生产系统的集成，因此比验收测试慢，流程也长。

面对deadline的压力，我们常常牺牲单元测试，这需要通过将覆盖率可视化，甚至在完成定义中设置覆盖率阈值，低于阈值构建就失败。

==本节最后引用 martin folwer的说法，构建包括测试要在10分钟完成，测试大部分是单元测试。并说明含数据的的功能测试可能要数个小时。==

在自动化测试中尽早捕捉错误

图 测试金字塔

确保测试运行快速（必要时并行）

测试驱动开发

尽可能多地将人工测试自动化

将性能测试集成到测试套件中

将非功能需求测试集成到测试套件中

部署流水线中断时拉制动闸

为何我们需要紧急制动

本章小结

CH11 持续集成

略。

來源：简书

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。