DevOps实践指南

【美】Gene Kim; Jez Humble; Patrick Debois; John Willis

导言：展望DevOps新世界

在制造业革命前，制造厂的平均交货周期为6周，能按时交货的订单不到总量的70%。随着精益实践的广泛实施，到2005年，产品的平均交货周期缩短到3周以下，按时交货的订单超过总量的95%。而那些没有实施精益实践的厂商，不但渐渐失去了市场，有的甚至破产了。

公司对不同部门的考核和激励不同，阻碍了公司全局目标的实现。 这种冲突造成了一种恶性循环，阻碍了业务目标的实现，不但波及IT公司的内部，而且还会影响外部。这些长期冲突常常导致技术工作者交付出质量低劣的软件和服务，打造出糟糕的客户体验，每天都要采用临时解决方案、应对紧急情况。以上情景在产品管理、产品开发、QA、IT运维和信息安全管理中不断上演。

正如软件开发高管和早期的DevOps记录者之一Christopher Little所说：“每个公司都是科技公司，无论他们认为自己处在哪个行业。银行也只是拥有银行执照的IT公司而已。”

2.2 限制在制品数

正如《看板方法：科技企业渐进变革成功之道》的作者David J. Anderson所说：“停止开始，开始结束。”

2.6 消除价值流中的困境和浪费

浪费和困境是软件开发过程中导致交付延迟的主要因素。 下面是该书中描述的关于浪费和困境的部分类型。

• 半成品
• 额外工序
• 额外功能
• 任务切换
• 等待
• 移动
• 缺陷
• 非标准或手动操作
• 填坑侠
  我们的目标是将这些浪费和困境（任何需要填坑侠的场合）都可视化，并系统地进行改进，减轻或消除这些负担，从而实现快速流动的目标。

4.2 将日常工作的改进制度化

《精益企业》的作者Mike Orzen说：“比日常工作更重要的，是对日常工作的持续改进。”

6.3.3 为非功能性需求预留20%的开发时间，减少技术债务

为非功能性需求预留20%的开发时间，减少技术债务。
Marty Cagan指出，如果组织不愿意支付这“20%的税”，那么技术债务将会最终恶化到耗尽所有可用资源的程度。

第7章 参考康威定律设计组织结构

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

7.3 组建以市场为导向的团队（“速度优化”）

为了实现以市场为导向，不需要进行自上而下的大规模重组，那样往往会造成大范围的破坏、恐惧和停滞。相反，将工程师及其专业技能（例如运维、QA和信息安全）嵌入每个服务团队，或者向团队提供自助服务平台，其功能包括配置类生产环境、执行自动化测试或进行部署。

7.4 使职能导向有效

尽管看似诱人，但其实无法通过重组的方式获得持续的改进和适应性。起决定性作用的并不是组织形式，而是人们的行为和反应。

7.5 将测试、运维和信息安全融入日常工作

一个经典的案例是Facebook。2009年，Facebook正经历着飞速的增长，同时在代码部署方面也遇到了重大问题。虽然并非所有问题都会直接影响到客户，但团队始终处于没完没了的救火状态中。生产工程总监Pedro Canahuati描述了这样一次会议：与会人员全是运维工程师；有人提议除了正在处理故障的人以外，其他所有人都合上笔记本电脑，但是没有一个人能做到。

为了提升部署效率，Facebook采取的最有效的一个措施就是让所有工程师、工程经理和架构师轮流值班，负责他们自己构建的服务的运维工作。

7.7 投资于服务和产品，而非项目

不幸的是，对于成功的产品或服务而言，初始阶段是成本最低的阶段。

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

在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。

9.2 应用统一的代码仓库

相比于对代码进行版本控制，为什么对环境进行版本控制能更好地预测IT效能和组织绩效呢？ 实际上，几乎在所有情况下，环境的可配置参数都要比代码的可配置参数多出好几个量级。所以，环境最需要使用版本控制。

9.3 使基础设施的重建更容易

Bill Baker是微软的一名资深工程师。他曾有一番妙语，称我们过去对待服务器就像对待宠物：“我们给它们起名字，并在它们生病时悉心照料。现在，我们对待服务器更像对待牲畜：给它们编号，在它们生病时把它们干掉。”

第13章 降低发布风险的架构

这就是演进式架构原则，正如Jez Humble所说：“任何成功的产品或公司，其架构都必须在生命周期里不断演进。”

13.1 能提高生产力、可测试性和安全性的架构

另一个例子是Google Cloud Datastore，它是世界上最大的一个NoSQL服务，但其支持团队只有大约8个人，这主要是因为它是构建在一层层可靠的基础服务之上的。”（见图13-1）

13.3 安全地演进企业架构

通过创建绞杀者应用，可以避免运用新架构或新技术复制已有功能。现有系统本身的特点使得业务流程变得过于复杂，因此复制现有流程不可取（通过研究用户，往往能够重新设计业务流程，用更简单的流程来实现业务目标）。

15.1 用均值和标准差识别潜在问题

标准差的常见用途是，定期检查数据集的某个度量，如果与均值有显著差异就告警。例如，当每天未经授权的登录次数比均值大三个标准差时就告警。只要这个数据集呈高斯分布，我们就预计只有0.3%的数据点会触发告警。

15.2 异常状态的处理和告警

Tom Limoncelli是《云系统管理：大规模分布式系统设计与运营》的作者之一，也曾是谷歌的站点可靠性工程师。他讲述了以下关于监控的故事：“当人们问我需要监控哪些对象时，我开玩笑说，在理想的世界里，我们会删除目前监控系统里所有的告警。然后，在每一个用户业务中断以后，我们会问什么指标能预测这个中断，然后再把这些指标加入到监控系统中，并根据需要告警，再不断重复上面这一过程。这样，我们就只会收到预防中断的告警，而不是在故障发生以后遭到报警信息的轰炸。”

16.2 开发和运维共同承担值班工作

为此，我们会让开发人员、开发经理和架构师轮流和运维团队共同值班，就如Facebook的生产品工程总监Pedro Canahuat在2009年所做的一样。这确保了价值流中的所有人能够就他们所做的上游架构和编码决策得到直接的反馈。

以上实践还帮助开发管理人员意识到，每一项产品功能都标记为“完成”并不代表业务目标已经实现。相反，所有功能都在生产环境中按照设计正常地运行，没有引起重大的故障，也没有引发计划外的运维或开发工作，才是真的“完成”。

16.4 让开发人员自行管理生产服务

这种机制对于运维人员来说就像是减压阀，它确保运维团队不会陷入这种境地：不得不管理脆弱的服务，同时技术债务不断累积，局部问题扩大为全局问题。这一机制还有助于保障运维部门拥有足够的能力去开展改进工作和预防性项目。

回传这一实践在谷歌由来已久，也许这是开发和运维工程师互相尊重的最佳体现。

谷歌的很多实践都是令人称奇的，其一是他们对运维工程师有一个职能定位，即“站点可靠性工程师”（Site Reliability Engineer，SRE），

18.1 变更审批流程的危险

建设高度信任的文化可能是未来10年最大的管理挑战。

18.2 “过度控制变更”的潜在危险

传统的变更控制可能会导致意想不到的后果，例如延长交付时间，降低部署过程中反馈的强度和即时性。丰田生产系统的核心理念之一是“最了解问题的人通常是离问题最近的人”。组织越依赖变更审批，它在稳定性（平均服务恢复时间和更改失败率）和吞吐量（部署前置时间、部署频率）方面的表现就越差。

18.6 利用结对编程改进代码变更

Hendrickson很快注意到，许多组织能正常地执行代码评审，他们靠的是一种文化，即认可评审代码的价值不低于编写代码的价值。当尚未建立这种文化时，在过渡时期，结对编程可以作为一种宝贵的实践。

第19章 将学习融入日常工作

这就像Steven Spear博士所说的“可恢复型组织”，能够“熟练地发现问题，解决问题，并通过在整个组织中提供解决方案来扩大经验的效果”。这些组织具有自我愈合的能力。“对于这样的组织，应对危机并不是什么特殊的工作，而是每时每刻都在做的事情。这种响应能力是可靠性的源泉。”

19.1 建立公正和学习的文化

学习型文化的先决条件之一是，当发生事故时（这是毫无疑问的），对待它的反应要“公正”。正如Etsy首席技术官John Allspaw所说：“我们在Etsy的目标是从学习的角度看待错误、报错、失误、过失等。”

19.4 降低事故容忍度，寻找更弱的故障信号

我们所做的全部工作都是潜在的重要假设和数据来源，而不是重复的例行公事或对过去实践的验证。不能将技术工作看成是完全标准化的，力图实现流程合规。相反，必须持续不断地寻找越来越弱的故障信号，进而更好地理解和管理运维中的系统。

19.8 小结

正如Peter Senge所说：“组织唯一的可持续竞争优势就是比对手更快的学习能力。”

22.6 确保软件供应链的安全

作为开发人员，“我们不再编写自定义软件，而是组装所需要的开源组件，这已经成为我们非常依赖的软件供应链了”。

报告里有如下惊人的发现： 一个典型的组织依赖于7601个构建工件（即软件供应商或组件）并使用18 614个不同版本（即软件构件）； 在这些用到的组件中，7.5%存在已知漏洞，其中超过66%的漏洞已经存在两年以上，并且尚未修复。