《DevOps实践指南》第一部分

第一部分　DevOps 介绍

• DevOps 的三步工作法：流动、反馈以及持续学习与实验

简史

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

精益运动

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

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

敏捷宣言

• 在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布

• Mike 得出了结论：精益社区中大多数企业都没有抓住精益的核心——改善套路（Kata）

---

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

---

1.1　制造业价值流

• 精益中的一个基本概念叫价值流

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

1.2　技术价值流

• 在DevOps中，我们通常将技术价值流定义为“把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”

• 不但要快速地交付，同时还要保证部署工作不会产生混乱和破坏，如中断客户服务、性能下降或者信息安全不合规等问题

聚焦于部署前置时间

• 部署的前置时间是价值流的一个子集，也是本书讨论的重点。价值流始于工程师1（包括开发、QA、IT运维和信息安全人员）向版本控制系统中提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息

• 目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。只有当工作任务是小批量的，并将质量内建到价值流的每个部分时，这种同步的模式才能实现

• 定义前置时间和处理时间

• 前置时间与处理时间（有时候也被称为接触时间或者任务时间）3是度量价值流性能的两个常用指标

• 前置时间在工单创建后开始计时，到工作完成时结束；处理时间则从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间（见下图）

• 常见的场景：为期数月的部署前置时间
• 测试和生产环境的前置时间很长，并且严重依赖于手动测试，或者需要各种审批流程，情况更是如此

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

• 我们的目标：分钟级别的部署前置时间

• 在DevOps的理想情况下，开发人员能快速、持续地获得工作反馈，能快速和独立地开发、集成和验证代码，并能将代码部署到生产环境中（自己部署或者他人部署）

• 为了更容易地实现上述目标，还需要通过模块化、高内聚、低耦合的方式优化架构设计

关注返工指标——%C/A

• 技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比（%C/A）。该指标反映了价值流中的每个步骤的输出质量

1.3　三步工作法：DevOps的基础原则

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

• 第一步：实现开发到运维的工作快速地从左向右流动。为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过加快技术价值流的流速，缩短满足内部或者外部客户需求所需的前置时间，尤其是缩短代码部署到生产环境所需的时间，可以有效地提高工作质量和产量，并使企业具有更强的外部竞争力
• 第二步：在从右向左的每个阶段中，应用持续、快速的工作反馈机制。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它
• 第三步：建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。通过主动地承担风险，不但能从成功中学习，也能从失败中学习

1.4　小结

• 价值流概念
• 重要量度指标——前置时间
• 三步工作法（支撑DevOps的原则）

---

第 2 章　第一步：流动原则

• 就是建立从开发到运维之间快速的、平滑的、能向客户交付价值的工作流

2.1　使工作可见

• 技术行业的工作内容是不可见的，这是其与制造业价值流相比的一个显著差异
• 由于点击的操作太过容易，所以不同团队可能会因为信息不完整而将工作“踢来踢去”，存在的问题也会被传递到下游工序，而这些问题完全是不易察觉的，直到无法按时向客户交付产品，或者应用程序在生产环境中出了问题
• 为了能识别工作在哪里流动、排队或停滞，就需要将工作尽可能地可视化。可视化工作板是一种较好的工作方式，如在看板或Sprint计划板上，使用纸质或电子卡片将各项工作展示出来

• 通过将每个工作中心的所有工作都放进队列中，并且可视化地展示出来，利益干系人更容易从全局目标出发，确定各项工作的优先级

2.2　限制在制品数

• 但是技术工作者很容易被打断，因为对所有人而言，这个中断的后果似乎是不可见的，例如，将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本

• 当使用看板管理工作时，可以限制多任务的出现，例如对看板的每一列或每个工作中心设置在制品数量的限制，并把卡片数量的上限标记在每一列上

• 例如，将测试工作的在制品数量上限设置为3。当测试队列中已有3张卡片时，除非某张卡片完成了，或将3张中的一张退回到前一个队列（左侧的那一列），否则禁止添加新卡片

• Dominica DeGrandis是在DevOps中运用看板的专家之一，他指出：“控制队列的长度（即在制品数）是一个非常强大的管理工具，因为这是影响前置时间的重要因素之一——

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

2.3　减小批量大小

• 建立平滑而快速的工作流的另一个关键点，是通过小批量的模式完成工作
• 在精益中，一个重要的经验是：为了缩短前置时间和提高交付物质量，应当持续不断地追求小批量模式。理论上，最小的批量是单件流，也就是每次操作只执行一个单位产品的处理

• 这种大批量的发布会造成突发的、大量的在制品，导致所有下游工作中心4大规模的混乱，其结果是流动性变差，质量下降
• 在开发（或DevOps）流程中，批量大小是工作产品在不同阶段间移动的单位数。对于软件而言，最容易看到的是代码。当工程师签入代码时，他们就批量地处理了一定数量的工作
• 在技术价值流中，单件流可以通过持续部署实现。其中，每一个提交到版本控制系统的变更都会集成、测试并部署到生产环境

2.4　减少交接次数

• 在技术价值流中，如果部署的前置时间以月作为周期单位，通常是因为要将版本控制系统中的代码部署到生产环境需要数百甚至数千个操作

• 当依赖不同价值流共享的资源（例如集中式操作）时，就会出现工作等待

• 即使在最好的情况下，有些信息或者知识也不可避免地在交接过程中丢失

• 为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立地为客户提供价值

2.5　持续识别和改善约束点

• 在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象
• 优化约束点之后的工作中心5个关键步骤
• 识别系统的约束点
• 决定如何利用这个系统约束点
• 基于上述决定，考虑全局工作
• 改善系统的约束点
• 如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束
• 在DevOps的转型过程中，如果希望前置时间从月或季度缩短为几分钟
• 环境搭建：如果生产或测试环境的搭建总是需要数周或数月，则按需部署就无法实现。解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方式创建
• 代码部署：如果代码的部署需要花数周或更长时间（譬如每次部署需要1300个手动、易出错的操作，涉及多达300名工程师），那么就无法按需部署。解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署
• 测试的准备和执行：如果每次代码部署都需要两周的时间来完成测试环境的准备和数据集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署。解决措施是实现自动化测试，这样才能在安全、并行地执行部署的同时，使测试的速度能跟上代码开发的速度
• 紧密耦合的架构：如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力
• 如果能突破以上的约束点，那么接下来的约束有可能是开发部门或产品经理

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

• 浪费和困境的部分类型

• 半成品：它指的是价值流里任何还没有彻底完成的工作（例如，需求文档或尚未审核的变更单）、处于队列中的工作（如等待QA审核或服务器管理员审核的工单）

• 额外工序：在交付过程中执行的、并未给客户增值的额外工作，可能包括那些在下游工作中心从没使用过的文档，或是对输出结果做出的并不增值的评审或审批

• 额外功能：在交付过程中构建的那些组织或客户完全不需要的功能（如“镀金”）

• 任务切换：将人员分配到多个项目和价值流里后，他们需要进行上下文切换

• 等待：由于资源的竞争而在工作之间产生了等待

• 移动：信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，另外，工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分

• 缺陷：由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认

• 非标准或手动操作：需要依赖其他人的非标准的或手动的工作，例如使用不能自动化反复重建的服务器、测试环境和配置

• 填坑侠：为了实现组织的目标，不得不把有些人和团队置于不太合理的处境（连夜给软件版本提交了上百个工单）

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

---

第 3 章　第二步：反馈原则

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

3.1　在复杂系统中安全地工作

• 复杂系统的一个重要特征是，无法将系统视为一个整体，去理解各个部分是如何组合在一起的
• 复杂系统的另一个特点：相同的事情做两次，结果未必相同
• 采取以下4项措施让复杂系统更安全地工作
• 管理复杂的工作，从中识别出设计和操作的问题
• 群策群力解决问题，从而快速地构建新知识
• 在整个组织中，将区域性的新知识应用到全局范围
• 领导者要持续培养有以上才能的人

3.2　及时发现问题

• 在所有工作执行的过程中，建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更
• 我们还要建立全方位的监控系统，监控服务组件在生产环境中的运行状态，以便快速探测到服务的意外情况。监控系统还能帮助我们度量是否偏离了预期目标，并将监控结果辐射到整个价值流中，这样就能看到我们的行为是如何影响系统里的其他部分的

3.3　群策群力，战胜问题获取新知

• 一旦问题出现了，我们还必须群策群力，发动所有相关的人员解决问题

• 群策群力的目的是遏制住问题，防止蔓延，然后定位和处理问题，避免复发

• 让所有参与者都得到更深入的知识，理解如何管理系统，把无法规避的、早期的无知阶段变成学习的过程

• 群策群力的原因如下：

• 防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增加，而且还会欠下技术债

• 防止工作中心启动新的工作，那样可能会在系统中引入新的错误

• 如果问题还没有得到解决，那么工作中心在下一次操作（如55秒后）中，可能还会遇到相同的问题，需要更高的修复成本

• 这种全民总动员的做法似乎违背了常规管理方法，因为局部问题扰乱了整体的运营。然而，全民总动员让学习成为了可能

• PDCA环——计划（Plan）、实施（Do）、检查（Check）、改进（Act）

• 只有尽可能在早期阶段，通过全民总动员的方式来解决小问题，才能把灾难性事故消灭在萌芽状态

• 为了在技术价值流中实施快速反馈，我们必须建立等同于安灯绳和全民响应的机制

• 触发了安灯绳时，我们就聚集在一起解决问题，停止开展任何新工作，直到问题解决。4这给价值流中的每个人提供了快速反馈（特别是那个导致系统故障的人），让我们能够快速地隔离和定位问题，避免出现更复杂的状况，导致问题的因果关系变得模糊

3.4　在源头保障质量

• 质量控制无效的例子
• 需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务，这些任务本应该由需求方自己采用自动化方式完成
• 需要那些远离实际工作场所且公务繁忙的人批准，迫使他们在不了解工作情况和潜在影响的情况下做出决策，或者仅仅是例行公事式地盖章批准
• 编写大量含有可疑细节，且在写后不久就过时了的文档
• 将大量工作推给运维团队和专家委员去审批和处理，然后等待回复
• 尽可能多用自动化方式执行通常由QA和信息安全人员来进行的质量检查。按需执行自动化测试，而无需开发人员向测试团队请求或发起测试工作。这样，开发人员能够快速地测试自己的代码，甚至把代码的变更部署到生产环境中

3.5　为下游工作中心而优化

• 精益定义了我们必须为两类客户而设计：外部客户（最有可能为我们提供的服务付费的人）和内部客户（紧随我们立即接收和处理工作的人）。根据精益原则，我们最重要的客户是我们的下游

3.6　小结

• 建立快速的反馈机制，对于实现技术价值流中的高质量、可靠性和安全性至关重要。为此，要在问题发生时识别问题，群策群力解决问题并构建新的知识，在源头控制质量，并且不断地为下游工作中心做优化

---

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

4.1　建立学习型组织和安全文化

• 三种类型的企业文化
• 病态型：病态型组织的特点是组织中存在大量恐惧和威胁。由于政治原因，个体为了保全自身利益，通常会隐瞒真相或者歪曲事实。在这种组织中，故障和事故经常被隐瞒
• 官僚型：官僚型组织的特点是规则和流程僵化，所有部门通常都“自扫门前雪”。在这种组织中，通过评判系统处理事故，结果往往恩威兼施
• 生机型：生机型组织的特点是积极探索和分享信息，让组织更好地履行使命。在这种组织中，整个价值流中所有的员工共同承担责任，对事故进行积极反思，并进行真正的根因调查

• 在意外和故障发生时，关注如何重新设计系统，从而防止事故复发，而不是去追究人的问题
• 例如，可以在每次事故发生后进行不指责的回顾，对事故发生的原因和过程做出客观解释，并就优化系统的最佳措施达成一致

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

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

• 通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。可以在每个开发周期的间歇中预留一段时间，或者安排改善闪电战（kaizen blitze）时段，让工程师通过自组团队的方式来解决他们感兴趣的问题

• 对于技术价值流而言，让工作系统更加安全也一样有助于发现和解决潜在风险。例如，一开始我们可能只是对影响客户服务的事故做不指责的事后调查，随着时间的推移，我们将逐渐地识别其他潜在风险

4.3　把局部发现转化为全局优化

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

• NR以恪守标准化流程而闻名于世，出现任何流程或操作偏差都要写故障报告，以便积累经验。不管故障信号强弱，或者风险大小如何，都会基于这些经验持续地更新流程和系统设计

• 这样带来的结果是：在任何一组新船员出海时，他们都能迅速地从集体长期积累的智慧中获得成长

• 在技术价值流中，我们也应该通过类似的机制建立全局知识库。例如，把所有事故报告转化成可搜索的知识库，让有需要的团队能更加方便地使用它去解决类似问题，同时建立起组织级的共享源代码库，让所有人可以方便地使用整个组织的代码、库和配置。这些机制有助于把个人的专业知识转化为服务更多成员的集体智慧

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

• 在技术价值流中，通过缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时解耦架构，都属于在系统中引入类似张力的做法，也都能够提高开发人员的生产效率及可靠性

4.5　领导层强化学习文化

• 领导者可以使用下列问题来帮助和辅导实验者
• 上一步做了什么？发生了什么？
• 你从中学到了什么？
• 现状如何？
• 下一个目标条件是什么？
• 当前工作有什么阻碍？
• 下一步做什么？
• 期望的结果是什么？
• 什么时候能进行复查？
• 领导者帮助一线工作者在日常工作中发现并解决问题，这种方式实际上就是丰田生产系统的核心，也是学习型组织、改善套路和高可靠性组织的核心

4.6　小结

• 三步工作法的第三步原则实现了学习型组织，实现了职能部门之间的高度信任和跨部门合作，接受了“复杂系统中总会发生故障”的事实，并鼓励谈论任何问题以建立一个安全的工作系统

4.7　第一部分总结

• 探讨了DevOps组织转型的三步工作法：流动原则、反馈原则和持续学习与实验原则

---

书籍

• 《丰田套路：转变我们对领导力与管理的认知》
• 《第五项修炼：学习型组织的艺术与实践》
• 《探索吧！深入理解探索式软件测试》
• 《看板方法：科技企业渐进变革成功之道》
• 《精益思想》
• 《第五项修炼：学习型组织的艺术与实践》
• 《丰田套路》
• 《精益企业》
• 《走动管理》