DevOps实践指南

译者序

冲刺的目标是要产生一个潜在可发布的产品增量，达到大家一致认可的完成程度

导言：展望DevOps新世界

现实

0. 在现实中，开发和IT运维是对立的，测试和信息安全活动总是在项目晚期才进行，这导致即使发现了问题也来不及修复
1. 产品和服务交付中的关键活动往往全都需要手动操作和互相交接，我们总是要等待其他人的工作完成才能进行自己的工作；
2. 在现实中，特性交付的周期一次次被拖延，质量也频频出现问题，特别是与生产环境部署相关的部分，进而对客户和业务造成了负面影响。
3. 工作需要更多的沟通、协调和审批；团队必须等待更长的时间，等待相关的工作完成；我们的工作质量持续恶化。
4. 自动化测试可以帮助开发人员快速发现错误（通常在几分钟之内），实现更快速的修复以及真正的学习。如果错误是在6个月后的集成测试中发现的，那时相关的记忆和因果关系早已消退，想从中学习是不可能的

应用了DevOps

0. 吞吐量指标； 代码和变更部署次数（频繁30倍）
1. 代码和变更部署前置时间（快200倍）
2. 可靠性指标
3. 生产环境部署（变更成功率高60倍）
4. 平均服务恢复时间（快168倍）
5. 组织性能指标
6. 生产力、市场份额以及营业目标（大约2倍以上）
7. 市值增长（3年内高出50%）

第一部分 DevOps介绍

DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果

技术价值流中，涉及产品管理、开发、QA、IT运维和信息安全专员等不同角色，在更低的成本和努力下，保障产品的高质量、可靠性、稳定性和安全性。

精益原则

0. 坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一
1. 小批量任务的交付是缩短前置时间的一个关键因素。

精益原则聚焦在如何通过系统性思考为客户创造价值，系统性思考的范围涉及建立持久目标，拥抱科学思维，创造流和拉动（而非推送）的协作模式，提倡从源头保证质量，以谦逊为导向，尊重流程中的所有个体。

第1章 敏捷、持续交付和三步法

精益中的一个基本概念叫价值流。我们先在制造业的场景中定义它，再讨论如何将它应用到DevOps和技术价值流中。

价值流两种定义：

一个组织基于客户的需求所执行的一系列有序的交付活动

为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值

在制造业的流程中，价值流随处可见，它始于接收到客户订单并将原材料发往工厂。为了缩短和预测价值流中的前置时间，通常需要持续地关注如何建立一套流畅的工作流程，包括减小批量尺寸、减少在制品（Work in Process，WIP）数量、避免返工等，同时还需要确保不会将次品传递到下游的工作中心，并持续不断地基于全局目标来优化整个系统。

在第一个阶段中，工作主要包括设计和开发，它和精益产品开发有很多相似之处：都具有高度的变化性和不确定性，不仅需要创意，某些工作还可能无法重来，这导致无法确定总体处理时间。在第二个阶段中，工作主要包括测试和运维，它类似于精益制造。相比前一个阶段，它需要创造性和专业技能，力求可预见性和自动化，将可变性降到最低（如短的和可预测的前置时间，接近零缺陷），并满足业务目标。

在精益社区里，前置时间与处理时间（有时候也被称为接触时间或者任务时间）是度量价值流性能的两个常用指标。

0. 前置时间：在工单创建后开始计时，到工作完成时结束；因为前置时间是客户能够体验到的时间，所以我们把重点放在缩短前置时间而不是处理时间上。
1. 处理时间：从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间

为了实现快速的流动并缩短前置时间，必须缩短工作在队列中的等待时间。

图1-1 部署工作的前置时间和处理时间

部署前置时间一旦变长，那么在价值流的每个阶段，几乎都需要“填坑”能手来补救

我们可以通过如下方式达到这个目标：

0. 向版本控制系统中持续不断地提交小批量的代码变更
1. 并对代码做自动化测试和探索测试
2. 然后再将它部署到生产环境中
3. 通过模块化、高内聚、低耦合的方式优化架构设计，帮助小型团队自治地工作。这样即便失败了，也能在可控范围内，而不至于对全局产生影响。

这样，我们就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复可能出现的问题

图1-3 前置时间为分钟级别的技术价值流

《凤凰项目》把三步工作法作为基础的原则，并由此衍生出了DevOps的行为和模式

图1-4三步工作法

0. 实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标。相关的实践包括持续构建、集成、测试和部署，按需进行环境搭建，限制在制品数量，构建能够安全地实施变更的系统和组织。
1. 在从右向左的每个阶段中，应用持续、快速的工作反馈机制。该方法通过放大反馈环防止问题复发，并能缩短问题检测周期，实现快速修复
2. 建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验

通过持续地缩短和放大反馈环，不仅能创造更安全的工作系统，也能承担更多的风险，并进行试验帮助自己比竞争对手改进得更快，从而在市场竞争中战胜他们。

第2章 第一步：流动原则

增强流动性

0. 持续加强工作内容的可视化
1. 减小每批次大小和等待间隔
2. 内建质量以防止缺陷向下游传递

为了能识别工作在哪里流动、排队或停滞，就需要将工作尽可能地可视化。可视化工作板是一种较好的工作方式，如在看板或Sprint计划板上，使用纸质或电子卡片将各项工作展示出来

图2-1 横跨需求、开发、测试、预生产和生产的看板示例

通过将每个工作中心的所有工作都放进队列中，并且可视化地展示出来，利益干系人更容易从全局目标出发，确定各项工作的优先级。这样，每个工作中心都能采用单任务的处理方式，从优先级最高的任务开始，依次完成所有工作，以增加工作中心的吞吐量。

技术价值流中的工作，显然要比分类几何形状复杂得多，所以多任务会导致更长的处理时间。 当使用看板管理工作时，可以限制多任务的出现，例如对看板的每一列或每个工作中心设置在制品数量的限制，并把卡片数量的上限标记在每一列上。

小批量

控制队列的长度（即在制品数）是一个非常强大的管理工具，因为这是影响前置时间的重要因素之一——对于大多数的工作条目而言，在它们完成以前，其实并无法预测到底需要多长时间。

通过限制在制品数，还能更容易地发现工作中的阻碍。例如，当限制在制品时，可能会发现居然没什么工作可干的，因为要等待其他人。虽然进行一项新工作（即“干点什么总比什么都不干强”）可能很诱人，但此时更好的做法是查明导致等待的原因，并协助解决那个等待的问题。

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

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

0. 在精益中，一个重要的经验是：为了缩短前置时间和提高交付物质量，应当持续不断地追求小批量模式。理论上，最小的批量是单件流，也就是每次操作只执行一个单位产品的处理。
1. 另一种方式是小批量策略（即“单件流”），即对每本宣传册顺序地执行所需的所有步骤，然后再开始处理下一本宣传册。换句话说，先折叠一张纸，将其插入信封，再给信封封口，之后盖章；然后，取下一张纸，并重复以上过程。
2. 为了缩短前置时间、提高吞吐量，我们需要不断地识别系统中的约束点，提高工作产能。

在DevOps的转型过程中，如果希望前置时间从月或季度缩短为几分钟，那么一般需要依次优化下面的约束点。

0. 环境搭建
1. 代码部署
2. 测试的准备和执行：如果每次代码部署都需要两周的时间来完成测试环境的准备和数据集的配置
3. 紧密耦合的架构：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可
4. 开发部门或产品经理。

浪费和困境

0. 半成品：它指的是价值流里任何还没有彻底完成的工作
1. 额外功能：在交付过程中构建的那些组织或客户完全不需要的功能（如“镀金”）。额外功能增加了功能测试和管理的复杂度和工作量
2. 任务切换：将人员分配到多个项目和价值流里后，他们需要进行上下文切换，并管理工作之间的依赖关系，这会在价值流中耗费额外的工作量和时间
3. 等待：由于资源的竞争而在工作之间产生了等待，这将增加周期时间，延迟了向客户交付价值。
4. 移动：信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，这时人员移动的浪费就产生了。另外，工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分。
5. 缺陷：由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认
6. 非标准或手动操作

我们的目标是将这些浪费和困境（任何需要填坑侠的场合）都可视化，并系统地进行改进，减轻或消除这些负担，从而实现快速流动的目标。

提升技术价值流流动性

0. 将工作可视化
1. 限制在制品数
2. 减小批量大小
3. 减少交接次数
4. 持续地识别和改进约束点
5. 消除日常工作中的困境

第3章 第二步：反馈原则

第一步工作法描述的原则，使得工作能够在价值流中从左向右快速地流动。

第二步工作法描述的原则，则使得在从右向左的每个阶段中能够快速、持续地获得工作反馈。

建立安全和可靠的工作系统

0. 这一点对于复杂的系统尤其重要，在这种情况下，发现和纠正错误的最早时机通常是灾难性事件发生时
1. 无法设计出绝对安全的系统

让复杂系统更安全地工作

0. 管理复杂的工作，从中识别出设计和操作的问题；
1. 群策群力解决问题，从而快速地构建新知识；
2. 在整个组织中，将区域性的新知识应用到全局范围；
3. 领导者要持续培养有以上才能的人。

在安全的工作系统中，我们要不断地对设计和假设进行验证。目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰地确定问题的前因后果。能排除的假设越多，定位和解决问题的速度就越快，从而提高我们的顺应力、敏捷性以及学习和创新能力。

群策群力

0. 仅仅检测出意外的发生是远远不够的。一旦问题出现了，我们还必须群策群力，发动所有相关的人员解决问题
1. 群策群力的目的是遏制住问题，防止蔓延，然后定位和处理问题，避免复发
2. 这样做可以让所有参与者都得到更深入的知识，理解如何管理系统，把无法规避的、早期的无知阶段变成学习的过程。
3. 只有尽可能在早期阶段，通过全民总动员的方式来解决小问题，才能把灾难性事故消灭在萌芽状态

第4章 第三步：持续学习与实验原则

0. 第一步：建立了从左到右的工作流
1. 第二步：建立了从右到左的快速、持续的反馈
2. 第三步：持续学习与实验；技术价值流的核心是建立高度信任的文化。它强调每个人都是持续学习者，必须在日常工作中承担风险；通过科学的方式改进流程和开发产品，从成功和失败中积累经验教训，从而识别有价值的想法，摒弃无用的想法。另外，所有局部的经验都会快速转化为全局性的改进，从而帮助整个组织尝试和实践新技术

组织类型学模型：组织如何处理信息

当单个团队或个人获得了独有的专业知识或经验时，我们的目标是把这些隐性知识（即很难通过文档或沟通的方式传递的知识）转换为显性知识，从而帮助其他人吸取这些专业知识并在实践中应用。

提高效率

0. 缩短部署的前置时间
1. 提高测试覆盖率
2. 缩短测试执行时间
3. 在必要时解耦架构

领导力的优秀并非体现在做出的所有决定都是对的。相反，更卓越的领导力其实是为团队创造条件，让团队能在日常工作中感受到这种卓越。换句话说，这需要领导者和员工们共同的努力，每个人都相互依存，缺一不可。