《DevOps 实践指南》—— Gene Kim / Jez Humble / Patrick Debois / John Willis

[thzt]

我完全被“基础设施即代码”（infrastructure as code）的理念所折服了。
Luke一边喝着咖啡，一遍更详细的向我阐述了他的想法。
他告诉我，他相信运维人员的工作模式可能会变得像开发人员一样，
他们必须在源代码控制系统里维护系统的配置，并在工作中使用持续集成/持续交付（CI/CD）的模式。

DevOps不仅是自动化，就像天文学不只是望远镜一样。

今天，不管我们身处什么行业，想要获取客户并向客户交付价值的方式都要依赖于技术价值流。

每个公司都是科技公司，无论他们认为自己处在哪个行业。
银行也只是拥有银行执照的IT公司而已。

困于这种恶性循环中多年，特别是那些处于开发下游的人，经常感觉被困在一个注定失败的系统中，无力改变结果。
伴随这种无力感的是倦怠感，还有疲劳，愤世嫉俗，甚至是无助和绝望。

许多心理学家认为，创建一个让人感觉无能为力的系统，是我们能对人类同胞做的最具破坏性的一件事。
我们剥夺了他人控制自己成果的能力，甚至营造了一种文化，让人们因为害怕遭受惩罚，失败或危及生命而不敢做正确的事。
这创造了“习得性无助”的环境，人们变得不愿或无法采取行动来避免未来遇到同样的问题。

高绩效者要更加敏捷和可靠，这证明DevOps能够打破根本的，长期的冲突。

当项目延迟时，增加更多的开发人员不仅降低了单个开发人员的生产力，而且也降低了整体的生产力。

IT公司所特有的全部典型问题：项目预算超支，进度一再拖延，为了公司的存亡不得不上线。

---

精益的两个主要原则包括：
坚信前置时间（把原材料转换为成品所需的时间）是提升质量，客户满意度和员工幸福感的最佳度量指标之一；
小批量任务的交付是缩短前置时间的一个关键因素。

在敏捷宣言中，一个重要的原则是，
频繁的交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期。
并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。

精益社区中大多数企业都没有抓住精益的核心——改善套路（kata）。
所有企业都有日常工作流程，而这些日常工作决定了最终的产出。
通过设定目标，制定每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和改进的目的。

---

精益中的一个基本概念叫价值流。
价值流，指的是一个组织基于客户的需求所执行的一系列有序的交付活动。
或者是，为了给客户设计，生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值。

为了缩短和预测价值流中的前置时间，通常需要持续的关注如何建立一套流畅的工作流程，
包括减少批量尺寸，减少在制品（work in process，WIP）数量，避免返工等，
同时还需要确保不会将次品传递到下游的工作中心，并持续不断的基于全局目标来优化整个系统。

在制造业中加速物理产品加工流程的原则和模式，同样可以应用到技术工作（及所有知识工作）中。
在DevOps中，我们通常将技术价值流定义为，
把业务构想转化为向客户交付价值的，由技术驱动的服务所需要的流程。

---

通过持续加强工作内容的可视化，减少每批次大小和等待间隔，内建质量以防止缺陷向下游传递，从而增强流动性。
通过加速技术价值流的流动，可以缩短满足内部客户和外部客户需求的前置时间，进一步提高工作质量，
并使我们更加敏捷，能够比竞争对手更为出色。

技术行业的工作内容是不可见的，这是其与制造业价值流相比的一个显著差异。
相对于工业产品的生产过程而言，在技术价值流中很难发现工作过程的阻塞点，
例如，在哪里受阻了，在哪个环节产生了积压。

另一方面，技术工作的流转通过单击一次鼠标就可以完成，譬如将工单重新指派给另一个团队。
由于单击的操作太过容易，所以不同团队可能会因为信息不完整而将工作“踢来踢去”，
存在的问题也会被传递到下游工序，而这些问题完全是不易觉察的，直到无法按时向客户交付产品，或者应用程序在生产环境中出了问题。

为了能识别工作在哪里流动，排队或停滞，就需要将工作尽可能的可视化。

通过限制在制品数，还能更容易的发现工作中的阻碍。
例如，当限制在制品时，可能会发现居然没什么工作可干的，因为要等待其他人。

虽然进行一项新工作（即，干点什么总比什么都不干强）可能很诱人，
但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。

实际上，糟糕的多任务处理发生的原因，通常是同时给一个人分配多个项目，
造成了很多优先级冲突问题。

建立平滑而快速的工作流的另一个关键点，是通过小批量的模式完成工作。

在精益中，一个重要的经验是：
为了缩短前置时间和提高交付质量，应当持续不断的追求小批量模式。

理论上，最小的批量是单件流，也就是每次操作只执行一个单位产品的处理。

对于技术价值流而言，大批量的副作用和制造业一样。
我们制定了软件发布的年度计划，将一整年的开发成果一次性的都发布到生产环境中。
这种大批量的发布会造成突发的，大量的在制品，导致所有下游工作中心大规模的混乱，其结果是流动性变差，质量下降。

在技术价值流中，单件流可以通过持续部署实现。

即使在最好的情况下，有些信息或者知识也不可避免的在交接过程中丢失。
为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，
要么重新调整组织结构，让团队不必依赖其他人就可以独立的为客户提供价值。

因此，要通过减少队列中的等待时间以及非增值工作的时间来增加流动性。

为了缩短前置时间，提高吞吐量，我们需要不断识别系统中的约束点，提高工作产能。
在任何价值流中，总有一个流动方向，一个约束点，任何不针对此约束点而做出的优化都是假象。

如果我们优化约束点之前的那个工作中心，那么工作必将在这个约束点上更快的积压起来。
反之，如果优化约束点之后的工作中心，那么它还会处于饥饿状态，等待约束点处工作的结束。

浪费是业务兴盛的最大威胁，精益中对浪费的常用定义是，
使用了超出客户需求和他们愿意支付范围的任何材料或资源的行为。

浪费和困境是软件开发过程中导致交付延迟的主要因素。
我们的目标是将这些浪费和困境都可视化，并系统的进行改进，减轻或消除这些负担，从而实现快速流动的目标。

---

复杂系统的组件之间通常是紧耦合且紧密关联的，不能仅仅依据组件的行为来解释系统的行为。

Charles Perrow博士研究了三里岛核事故，他发现没有人能了解核反应堆在所有情况下的行为，以及在何种情况下会发生故障。
当核反应堆的一个组件出现故障时，很难将其与其他组件隔离，以不可预测的方式快速的流过阻力最小的路径。

复杂系统的另一个特点：相同的事情做两次，结果未必相同。
即便施行了有价值的静态检查和最佳实践，还是不足以防止灾难发生。

复杂系统中的故障是存在且不可避免的。

在安全的工作系统中，我们要不断的对设计和假设进行验证。
目标是更早，更快，以尽可能低的成本，从尽可能多的维度增加系统的信息流，
并尽可能清晰的确定问题的前因后果。

在制造业，如果缺乏有效的反馈机制，往往会酿成重大质量和安全问题。
在高绩效的制造业运营中，整个价值流里存在着快速，频繁和高质量的信息流，
每个工序的操作都会被度量和监控，任何缺陷或严重偏差都能被快速发现和处理。

Elisabeth Hendrickson说，
在我负责质量验证的时候，我将自己的工作描述为“建立反馈回路”。
而测试仅仅是一种反馈。

我们不应该绕开问题，也不应该用“有更多时间时再解决”来搪塞，
而要立刻群策群力修复问题。

触发了安灯绳时，我们就聚集在一起解决问题，停止开展任何新工作，直到问题解决。

---

在复杂系统中工作时，精确的预测出结果是不现实的。
因此，在日常工作中，即便未雨绸缪，小心谨慎，意外依然会发生，甚至有时还会发生灾难性的事故。

不公正的事故和意外处理会阻碍安全调查，让安全工作者感到恐惧，让整个组织更加官僚，
甚至还会导致信息封闭，责任逃避和滋生自我保全意识。

如果团队没有能力或者意愿去改进现有的流程，那么就会持续饱受眼前问题的困扰和折磨，
而且痛苦指数还会与日俱增。

就算不去优化现状，流程也不会是一成不变的，
由于混乱和无序，流程会随着时间的推移持续恶化。

比日常工作更重要的，是对日常工作的持续改进。

一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益。
换句话说，当单个团队或个人获得了独有的专业知识或经验时，我们的目标是把这些隐性知识（即很难通过文档或沟通的方式传递的知识）转换为显性知识，
从而帮助其他人吸取这些专业知识并在实践中应用。

在技术价值流中，我们也应该通过类似的机制建立全局知识库。

低绩效组织想方设法缓解问题，换句话说，他们疲于应付问题。
相对而言，高绩效组织则通过改善日常运营，持续的引入张力提高生产效率，同时在系统中注入更大的弹性，来实现或达到更佳的效果。

还可以通过演习的方式来预演大规模故障。
或者在生产环境中注入大规模故障，
如Netflix著名的“捣乱猴”，它会随机杀死生产环境中的进程和服务器，
来验证系统的可靠性是否达到了预期。

领导者通过“做出所有正确的决定”来领导团队。
然而，有证据表明，领导力的优秀并非体现在做出的所有决定都是对的。
相反，更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。

领导者必须强调解决问题的能力和学习的价值。

---

应用的年龄并不是影响性能的主要因素，
相反，性能取决于应用架构在当前（或重构后）是否具有可测试性和可部署性。

在每一个组织中，不同的团队或个人都会对创新持有不同的态度。
创新者 2.5%：技术爱好者，“试试看”
早期采用者 13.5%：有远见者，“走在潮流之前”
早期从众者 34%：实用主义者，“顺应潮流”
晚期从众者 34%：保守主义者，“经过验证才行”
落后者 16%：怀疑论者，“坚决说不”

创新者和早期采用者，往往能迅速接受新的想法，而其他人则较为保守。

我们不会花费太多时间去改变保守的群体，特别是在早期阶段。
相反，应该把精力在能创造成功且愿意承担风险的团队上，并以此为基础慢慢扩大范围。

即使取得了高层的支持，也要避免使用“大爆炸”的方式（即遍地开花式的开始），
而应该将精力集中于少数几个试点领域，确保它们取得成功，然后再逐步扩展。

不管如何选定切入点，都要尽早展示成果，并积极宣传。

变革需要勇气，尤其是当有人不断的挑战和抵制你的时候。

---

和所有核心干系人一起演练价值流映射，从而帮助团队梳理出创造价值的所有步骤。

无论价值流的复杂程度如何，其中都没有一个人能够知道为客户创造价值所要做的每一项工作，尤其是当工作由多个团队完成时。
因此，在选择好DevOps试点应用或服务后，必须确定价值流的所有成员，他们有责任共同为客户创造价值。

针对团队工作绘制价值流图
绘制价值流图的目标并不是记录所有的步骤和细节，
而是识别出阻碍价值流快速流动的环节，从而缩短前置时间和提高可靠性。

根据我的经验，这样的价值流映射演练总是让人大开眼界。
很多人通常是第一看到，为了向客户交付价值，到底需要完成多少工作。

根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作。
（1）需要等待数周甚至数月的工作
（2）引发或处理重大返工的工作

任何一个成功运作多年的组织都已经建立了符合自身的实践和运行机制。
同时，公司还采取各种措施延续和保护当前的运作流程。
虽然这对维持现状很有好处，但为了适应市场的变化，往往需要改变工作方式。
这需要颠覆和创新，必然会和当前负责日常业务和内部流程的群体产生冲突，而且后者往往会胜出。

两位博士的研究成果表明，应该组建专门的转型团队，并使之独立于负责日常运作的部门。

当背负沉重的金融债务时，组织只能还利息，从来都无法偿还贷款本金，而且很有可能陷入连利息都还不起的窘境。
同样，无法还清技术债务的组织也会发现，在日常工作中，应付老问题已经让自己不堪重负，根本无法开展新的工作。
换句话说，这些组织目前仅仅是支付技术债务的利息而已。

为了积极的管理技术债务，要确保至少把20%的开发和运维时间投入到重构，自动化工作，架构优化以及非功能性需求上，
例如，可维护性，可管理性，可扩展性，可靠性，可测试性，可部署性和安全性等。

Marty Cagan指出，如果组织不愿意支付这20%的税，那么技术债务将会最终恶化到耗尽所有可用资源的程度。

---

康威定律：系统设计受限于组织自身的沟通结构。
组织的规模越大，灵活性就越差，这种现象也就越明显。

软件的架构和软件团队的结构是一致的。
软件开发团队的结构对软件产品的架构和成果有着巨大的影响。

让问题变得更复杂的是，执行工作的人通常都不太理解自己的工作与价值流目标有什么关系，
“我之所以要配置这台服务器，是因为别人要我这么做。”
这样就无法让员工发挥创造性和主动性。

在高效能组织中，人们有着共同的目标。
保证质量，可用性和安全性，不是某个部门的职责，而是所有人日常工作的一部分。

实现高绩效的另一种方法是组建稳定的服务团队，持续提供资金，让他们执行自己的战略和计划。
在传统的开发模型中，开发团队和测试团队被分配到某一个项目中，
当项目完成或资金耗尽后，团队解散，他们又被重新分配到另一个项目中。

这种方式导致很多不尽人意的结果，
包括开发人员无法看到他们所做决策的长期效果（一种反馈形式），以及投资模式只注重和支付软件生命周期的初始阶段，
不幸的是，对于成功的产品或服务而言，初始阶段是成本最低的阶段。

不当的组织方式需要各个团队进行大量的沟通和协调，
但仍然可能导致大量返工，对需求定义有分歧，工作交接低效，以及由于等待上游人员完工而造成的人员闲置等。
在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，
从而避免过多不必要的沟通和协调。

在紧耦合的软件架构中，即使是微小的变更也可能导致大规模的故障。
因此，负责某个组件的开发人员不得不和负责其他组件的开发人员不断的协调和沟通，
包括走各种复杂的变更管理流程。

松耦合的架构意味着在生产环境中可以独立更新某一项服务，而无需更新其他服务。