第一部分 DevOps介绍
第1章 敏捷、持续交付和三步法 4
1.1 制造业价值流 4
1.2 技术价值流 4
我们通常将技术价值流定义为“把业务构想转化为向客户交付价值的、由技术驱动的服务所需要的流程”。
1.2.1 聚焦于部署前置时间 5
价值流始于工程师”(包括开发、QA、IT运维和信息安全人员)向版本控制系统中提交了一 个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。
我们并不提倡在设计、开发中串行地完成了大批量的工作后，再转入测试、运维阶段(如使用大批量、基于瀑布模型的开发流程，工作在长生命周期的特性分支上)。恰恰相反，我们的目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。
前置时间与处理时间(有时候也被称为接触时间或者任务时间)。是度量价值流性能的两个常用指标。
前置时间在工单创建后开始计时，到工作完成时结束:处理时间则从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间(见图1-1)。
因为前置时间是客户能够体验到的时间，所以我们把重点放在缩短前置时间而不是处理时间上
在DevOps的理想情况下，开发人员能快速:持续地获得工作反馈、能快速和独立地开发、集成和验证代码，并能将代码部署到生产环境中
可以通过如下方式达到这个目标:向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试然后再将它部署到生产环境中。
为了更容易地实现上述目标，还需要通过模块化、高内聚、低耦合的方式优化架构设计，
1.2.2 关注返工指标——%C/A 7
除了前置时间和处理时间外，技术价值流中的第三个关键指标是完成时间和精确的总花费时间的百分比(%CIA)。该指标反映了价值流中的每个步骤的输出质量。
1.3 三步工作法：DevOps的基础原则 7
第一步，实现开发到运维的工作快速地从左向右流动
第二步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制
第三步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。
1.4 小结 8
第2章 第一步：流动原则 9
2.1 使工作可见 9
为了能识别工作在哪里流动、排队或停滞，就需要将工作尽可能地可视化。可视化工作板是一种较好的工作方式，如在看板或 Sprint 计划板上，使用纸质或电子卡片将各项工作展示出来。工作通常从左侧发起（从待办事项中拉取），然后从一个工作中心拉取到下一个工作中心，最后到达工作板的最右侧，而这一列也通常被标记为“完成”或“已上线”。通过这种方式，不仅能将工作内容可视化，还能有效地管理工作，加速其从左至右的流动。
理想情况下，看板应该覆盖整个价值流；仅当工作到达看板最右侧时，才能算是已完成（见图 2-1）。开发完成某个功能不能算是“已完成”，只有应用程序在生产环境里成功地运行起来，并开始为客户提供价值的时候，才能算是“已完成”。
通过将每个工作中心的所有工作都放进队列中，并且可视化地展示出来，利益干系人更容易从全局目标出发，确定各项工作的优先级。
2.2 限制在制品数 10
将一个工程师同时分配到多个项目里，他不得不在多个任务、认知规则和目标之间来回切换，付出重新进入角色的成本。多任务会导致更长的处理时间。
当使用看板管理工作时，可以限制多任务的出现，例如对看板的每一列或每个工作中心设置在制品数量的限制，并把卡片数量的上限标记在每一列上。
例如，将测试工作的在制品数量上限设置为 3。当测试队列中已有 3 张卡片时，除非某张卡片完成了，或将 3 张中的一张退回到前一个队列，否则禁止添加新卡片。
控制队列的长度（即在制品数）是一个非常强大的管理工具，因为这是影响前置时间的重要因素之一——对于大多数的工作条目而言，在它们完成以前，其实并无法预测到底需要多长时间。
2.3 减小批量大小 11
大批量导致在制品的暴涨，最后导致前置时间长、产品质量差的后果——如果发现了一个车身板有问题，整个批次都必须报废。
为了缩短前置时间和提高交付物质量，应当持续不断地追求小批量模式。理论上，最小的批量是单件流，也就是每次操作只执行一个单位产品的处理。
小批量和大批量之间的巨大差异，通过“模拟邮寄宣传册”的经典案例进行了说明。这个例子假设要邮寄出 10 本宣传册。邮寄之前，每本宣传册都必须经历 4 个步骤：折叠，插入信封，给信封封口，盖戳。
如果采用大批量策略（即“大规模生产”），我们会对每本宣传册按顺序执行上述 4 个步骤。换句话说，首先要将 10 张纸全都折叠完，再将每张纸分别插入信封，然后给所有的信封封口，最后全部盖章。
另一种方式是小批量策略（即“单件流”），即对每本宣传册顺序地执行所需的所有步骤，然后再开始处理下一本宣传册。换句话说，先折叠一张纸，将其插入信封，再给信封封口，之后盖章；然后，取下一张纸，并重复以上过程。
采用大批量和小批量策略之间的差异是巨大的（见图 2-2）。假设对所有 10 个信封都必须采取如上 4 个步骤，并且每一步操作需要 10 秒。如果使用每批 5 个的大批量策略处理，则完成第一个盖戳的信封需要用 310 秒。
更糟糕的是，假设我们在信封封口操作中发现第一步的折叠做错了，在这种情况下，我们能发现错误的最早时间是在 200 秒之后，那样我们就不得不将这个批次的 10 个小册子再重新折叠，并装回信封中。
对于技术价值流而言，大批量的副作用和制造业一样。这种大批量的发布会造成突发的、大量的在制品，导致所有下游工作中心①大规模的混乱，其结果是流动性变差，质量下降。即对生产环境的变更越大，问题的定位和修复就越困难，修复时间也就越长。
2.4 减少交接次数 13
代码在价值流流转的过程中，需要各个不同部门的协同才能完成相关任务，包括功能测试、集成测试、环境搭建、配置服务器、存储、管理、网络、负载均衡设备和信息安全加固等。
一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证。
上述流程中的每个环节都有其潜在的队列，当依赖不同价值流共享的资源时，就会出现工作等待。这些请求的前置时间通常会很长，从而导致那些本应按期操作完的工作持续地延期。即使在最好的情况下，有些信息或者知识也不可避免地在交接过程中丢失。
为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立地为客户提供价值。
2.5 持续识别和改善约束点 14
在 DevOps 的转型过程中，如果希望前置时间从月或季度缩短为几分钟，那么一般需要依次优化下面的约束点。
环境搭建：解决措施是按需建立完全自服务的环境，能通过自动化方式创建。
代码部署：解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署。
测试的准备和执行：解决措施是实现自动化测试，这样才能在安全、并行地执行部署的同时，使测试的速度
能跟上代码开发的速度。
紧密耦合的架构：解决措施是创建松散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力。
我们的目标是让小型开发团队可以独立、快速、可靠地开发、测试和部署，并持续为客户创造价值
2.6 消除价值流中的困境和浪费 15
2.7 小结 16
提升技术价值流的流动性对实施 DevOps 来说至关重要。为此，我们需要将工作可视化，限制在制品数，减小批量大小，减少交接次数，持续地识别和改进约束点，以及消除日常工作中的困境。
第3章 第二步：反馈原则 17
3.1 在复杂系统中安全地工作 17
第一步工作法描述的原则，使得工作能够在价值流中从左向右快速地流动。第二步工作法描
3.2 及时发现问题 18
我们的目标应该是在技术价值流的每个阶段（包括产品管理、开发、QA、信息安全和运维），在所有工作执行的过程中，建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更。
还要建立全方位的监控系统，监控服务组件在生产环境中的运行状态，以便快速探测到服务的意外情况。
3.3 群策群力，战胜问题获取新知 19
3.4 在源头保障质量 21
根据同行评审来评定所提出的变更，确保这些变更会按照设计运行。尽可能多用自动化方式执行通常由 QA 和信息安全人员来进行的质量检查。按需执行自动化测试，而无需开发人员向测试团队请求或发起测试工作。这样，开发人员能够快速地测试自己的代码，甚至把代码的变更部署到生产环境中。
3.5 为下游工作中心而优化 22
3.6 小结 22
第4章 第三步：持续学习与实验原则 23
4.1 建立学习型组织和安全文化 23
第一步建立了从左到右的工作流，第二步建立了从右到左的快速、持续的反馈，第三步要建立持续学习与实验的文化。
可以在每次事故发生后进行不指责的回顾，对事故发生的原因和过程做出客观解释，并就优化系统的最佳措施达成一致。在理想情况下，这不但能防止问题复发，还有助于实现更快的故障定位和恢复。消除指责能够有效实现学习型组织.
4.2 将日常工作的改进制度化 25
如果团队没有能力或者意愿去改进现有的流程，那么就会持续饱受眼前问题的困扰和折磨，而且痛苦指数还会与日俱增。
用临时方案解决问题的模式往往还会导致问题和技术债务的累积。比日常工作更重要的，是对日常工作的持续改进。
通过明确预留时间来改善日常工作，包括预留时间来偿还技术债、修复缺陷、重构和优化代码和环境。可以在每个开发周期的间歇中预留一段时间，或者安排改善闪电战时段，让工程师通过自组团队的方式来解决他们感兴趣的问题。
4.3 把局部发现转化为全局优化 26
一旦在局部范围内取得了成果，就应当把它分享给组织里的其他人，让更多的人从中获益。
出现任何流程或操作偏差都要写故障报告，以便积累经验。不管故障信号强弱，或者风险大小如何，都会基于这些经验持续地更新流程和系统设计。
4.4 在日常工作中注入弹性模式 27
还可以通过演习的方式来预演大规模故障，比如关闭某个数据中心。或者在生产环境中注入大规模故障（如 Netflix 著名的“捣乱猴”，它会随机杀死生产环境中的进程和服务器），来验证系统的可靠性是否达到了预期。
4.5 领导层强化学习文化 27
4.6 小结 29
4.7 第一部分总结 29
探讨了 DevOps 组织转型的三步工作法：流动原则、反馈原则和持续学习与实验原则。
第二部分 从何处开始
第5章 选择合适的价值流作为切入点 32
5.1 绿地项目与棕地项目 34
在技术领域，绿地项目是指全新的软件项目。从零开始，所以对已有的代码库、流程和团队没有太多顾虑。
DevOps 绿地项目通常是指一些试点项目，用于证明公有云或私有云方案的可行性，或者尝试采用自动化部署工具或相关工具等。
DevOps 棕地项目是指那些已经服务客户长达几年甚至几十年的产品或服务。这种项目通常背负大量的技术债务，譬如无自动化测试、运行在无人维护的平台上等。
5.2 兼顾记录型系统和交互型系统 35
5.3 从最乐于创新的团队开始 36
我们的目标是找到那些相信 DevOps 原则和实践，并有意愿和能力对现有流程进行创新和改进的团队。在理想情况下，这些群体将是 DevOps 转型的拥趸。
我们不会花费太多时间去改变保守的群体，特别是在早期阶段。相反，应该把精力集中在能创造成功且愿意承担风险的团队上，并以此为基础慢慢扩大范围。
即使取得了最高层的支持，也要避免使用“大爆炸”的方式（即遍地开花式的开始），而应该将精力集中于少数几个试点领域，确保它们取得成功，然后再逐步扩展。
5.4 扩大DevOps的范围 37
不管如何选定切入点，都要尽早展示成果，并积极宣传。将大的改进目标分解成渐进式的小步骤。这样做不但能提高改进速度，还可以在错误选择价值流后及早发现。
基于已经取得的成功，逐步扩大 DevOps 计划的应用范围。遵循低风险的顺序，有条不紊地提高可信度和影响力，并获取支持。
如何基于已获得的支持扩大影响。
(1) 发现创新者和早期采用者：这些同事最好受人尊重，并对组织中的其他人有着很大的影响力。他们的支持有助于提升创新的可信度。
(2) 赢得沉默的大多数：在下一阶段，力求将 DevOps 实践扩展到更多的团队和价值流，目标是建立更稳固的群众基础。
(3) 识别“钉子户”：只有在获得大多数人的支持并建立起足够稳固的群众基础后，才考虑如何应对这个群体。
5.5 小结 38
第6章 理解、可视化和运用价值流 39
6.1 确定创造客户价值所需的团队 40
在选择好 DevOps 试点应用或服务后，必须确定价值流的所有成员，一般来说，包括以下这些成员。
产品负责人：作为业务方的代言人，定义系统需要实现的功能。
开发团队：负责开发系统功能。
QA 团队：给开发团队提供反馈，并确保系统功能符合需求。
运维团队：负责维护生产环境，并确保系统能够良好地运行。
信息安全团队：负责系统和数据的安全。
发布经理：负责管理和协调生产环境部署以及发布流程。
技术主管或价值流经理：（根据精益方法论的定义）负责“从始至终地保障价值流的产出
满足或超出客户（和组织）期望”。
6.2 针对团队工作绘制价值流图 40
确定了价值流的相关成员之后，下一步是深入理解工作方式，并用价值流图进行记录。
绘制价值流图的目标并不是记录所有的步骤和细节，而是识别出阻碍价值流快速流动的环节
根据价值流参与团队所提供的全部信息，应该重点分析和优化下面两类工作：
需要等待数周甚至数月的工作，例如准备类生产环境、变更审批流程或安全审查流程等；
引发或处理重大返工的工作。
价值流图的初始版本应该只包含重要的流程模块。
每个模块至少应包括工作项的前置时间和处理时间（分别为图 6-1 中的 LT 和 VA），以及由下游消费者测量的%C/A。价值流图中的度量指标可用于指导改进工作。
一旦确定了想要改进的度量指标，绘制理想化的价值流图，并以此作为下一阶段的改进目标。
6.3 组建专门的转型团队 42
应该组建专门的转型团队，并使之独立于负责日常运作的部门，最重要的是，这个团队应该负责实现明确定义的、可度量的、系统级的目标（例如，将“从提交代码到部署至生产环境”这一过程的前置时间减少 50%）。为了做到这一点，应该采取以下措施：
转型团队的成员专门执行 DevOps 转型工作（而不是让他们继续做之前的工作，但要花20%的时间来做 DevOps 转型）；
选择熟悉多个领域的通才作为团队成员；
选择与其他部门长期保持良好关系的人作为团队成员；
如果可能，为团队找一个独立的办公区域，使各位成员尽可能多地相互交流，并和其他部门保持适当的距离。
如果可能，要将转型团队从诸多现有的规则和规定中解放出来。
6.3.1 拥有共同的目标 43
6.3.2 保持小跨度的改进计划 44
在任何 DevOps 转型项目中，都需要保持小跨度的改进计划，应该努力在数周内（最差也应该在数月内）获得可度量的改进成果或者可用的数据。
6.3.3 为非功能性需求预留20%的开发时间，减少技术债务 44
为了积极地管理技术债务，要确保至少把 20%的开发和运维时间投入到重构、自动化工作、架构优化以及非功能性需求（有时也称为“质量属性”）上，例如可维护性、可管理性、可扩展性、可靠性、可测试性、可部署性和安全性等。
通过这 20%的投入，开发人员和运维人员可以为日常工作中所遇到的问题提供长久的对策，并保证技术债务不会妨碍快速、安全地开发和运营。
6.3.4 提高工作的可视化程度 47
6.4 用工具强化预期行为 47
开发人员和运维人员不仅有着共同的目标，而且还有同一份任务列表。在理想情况下，任务列表存储在公共的工作系统中，
可以创建共享的工作队列，而不是使用不同的工具（例如，开发人员使用 JIRA，运维人员则使用 ServiceNow）
当生产事故在开发人员的工作系统中可见时，人们能清楚地知道事故会在什么时候影响到其他工作，这在使用看板图时尤为明显。
共享队列的另一个好处是统一了任务列表，每个人都能从全局的角度思考优先级最高的事情，在发现技术债务时，如果不能立即解决，可以将它添加到任务列表中。对于待解决的问题，可以使用为非功能性需求预留的 20%的时间进行修复。
6.5 小结 48
第7章 参考康威定律设计组织结构 49
7.1 组织原型 51
7.2 过度职能导向的危害（“成本优化”） 51
传统的 IT 运维组织往往采用职能型结构，根据专业领域组织团队。数据库管理员被归在一组，网络管理员被归在另一组，服务器管理员被归在第 3 组，等等。这种方式显然会延长交付周期，特别是在像大规模部署这样复杂的活动中，不得不向多个团队发出一堆工单并且对工作的交接情况进行协调，这导致每一个步骤都面临长时间等待。
除了导致长时间等待和交付周期延长以外，这种情况也会导致糟糕的交接、大量的返工、交付质量下降、瓶颈和延期等问题。
7.3 组建以市场为导向的团队（“速度优化”） 52
在极端情况下，以市场为导向的团队不但要负责特性开发，而且在整个应用生命周期中还要负责测试、安全、部署和生产环境的运维。这些跨职能团队可以独立运作
为了实现以市场为导向，将工程师及其专业技能（例如运维、QA 和信息安全）嵌入每个服务团队，或者向团队提供自助服务平台，其功能包括配置类生产环境、执行自动化测试或进行部署。
这使每个服务团队能够独立地向客户交付价值，而不必提交工单给 IT 运维、QA 或信息安全等其他部门。
7.4 使职能导向有效 53
只要服务团队能够快速（最好是按需）从运维团队获得可靠的帮助，那么集中式的职能型运维组织也可以实现高效运转，反之亦然。包括谷歌、Etsy 和 GitHub 在内的许多著名 DevOps公司都保留了职能型运维团队。
只要价值流中的所有人都能意识到客户和组织的目标，不管他们在组织中处于什么位置，都可以通过职能导向取得所预期的 DevOps 成果。
这些组织的共同之处是拥有高度信任的文化，所有部门都能够有效地协作，所有工作的优先级设置都是透明的，并且系统预留了足够的容量，能够迅速完成高优先级的工作。这在某种程度上是依靠自动化的自助服务平台实现的，它保证了产品质量。
7.5 将测试、运维和信息安全融入日常工作 54
7.6 使团队成员都成为通才 54
一种对策是让每一位团队成员都成为通才（见表 7-1）。给工程师提供学习必要技能的机会，让他们有能力构建和运行所负责的系统，并定期让他们在不同的职位间轮岗。
通过交叉培训和提高相关技能，通才能比专业人才做更多的工作，同时通过减少队列中的任务和等待时间改善整体工作流程。
多技能交叉培训非常有利于员工的职业发展，也能让所有员工的工作变得更有意思
7.7 投资于服务和产品，而非项目 56
7.8 根据康威定律设定团队边界 56
当团队处于不同的楼层、不同的办公楼甚至不同的时区时，建立并维持共同目标和相互信任变得更加困难，这不利于有效协作。当主要的沟通机制是工单或变更请求时，团队协作很难有效地进行。
不合理的团队组织方式可能产生不良后果。这些不当的方式包括按职能划分团队（例如将开发人员和测试人员安置在不同的办公地点，或者完全外包测试人员），以及按架构层次拆分团队（如应用层、数据库层等）。
不当的组织方式需要各个团队进行大量的沟通和协调，但仍然可能导致大量返工、对需求定义有分歧、工作交接低效，以及由于等待上游人员完工而造成的人员闲置等。
在理想情况下，软件的架构应该保证小团队能够独立运作，彼此充分解耦，从而避免过多不必要的沟通和协调。
7.9 创建松耦合架构，提高生产力和安全性 57
如果架构能够支持小团队独立、安全、快速地进行开发、测试和部署，就可以提高和维持开发人员的生产力，并改善部署质量。面向服务架构SOA，就具有这种特征。它是一种支持独立测试和部署服务的架构方式，其典型特征是由具有限界上下文的松耦合服务组成。
松耦合的架构意味着在生产环境中可以独立更新某一项服务，而无需更新其他服务。
限界上下文是开发人员应该能够理解和更新服务的代码，而不必知道其对等服务的内部逻辑。各服务严格通过 API 交互，因此不必共享数据结构、数据库模式或对象的其他内部表示。限界上下文确保服务被划分成独立的部分，并具有明确定义的接口，这也使测试更加容易。
7.10 小结 60
第8章 将运维融入日常开发工作 61
集中式运维团队如何取得以市场为导向的成果。以下是 3 个通用的策略：
构建自服务能力，帮助开发人员提高生产力；
将运维工程师融入服务团队；
如果运维工程师人数紧张，则可以采用运维联络人模式。
8.1 创建共享服务，提高开发生产力 62
运维部门若想取得以市场为导向的成果，一种做法是创建一套集中式的平台和工具集服务，让所有开发团队都能够通过使用这套平台和服务来提高生产力，开发团队就能够把更多的精力和时间用在功能构建上，而不是消耗在获取交付和支持生产环境特性所必需的基础设施上。
在理想情况下，运维提供的所有平台和服务应该是全自动化的，并且能按需提供，不需要开发人员提交工单，然后再等待运维团队手动处理，这能保证运维不成为客户的瓶颈
8.2 将运维工程师融入服务团队 63
若想取得以市场为导向的成果，另一种做法是通过融入运维工程师使产品团队能自给自足，从而降低对集中式运维的依赖程度。
通过将运维工程师融入开发团队，他们的工作优先级几乎完全受所在产品团队的目标驱动。
不过面试和聘用决策可能还是由集中式运维团队来完成，以确保一致性和员工的素质。
对于新的大型开发项目，可以在启动阶段就融入运维工程师。他们将参加开发团队的相关讨论，如计划会议、每日站会以及新特性的演示，随着开发团队对运维知识和能力的需求逐渐降低，运维工程师就可以转移到其他的项目或者工作中，
8.3 为每个服务团队分派运维联络人 64
由于各种原因（如成本或者资源不足），可能无法给每个产品团队都分派运维工程师，但可以给每个产品团队指定一位运维联络人，
集中式运维团队依然管理着所有环境，负责确保它们的一致性。派遣的运维工程师的责任是理解下列：
新产品的功能是什么，为什么要开发这个产品；
它是怎样工作的，可运维性如何，可扩展性和监控能力如何（强烈建议以图示说明）；
怎样监控和收集指标，如何确认应用的功能正常；
架构和模式是否与以往的做法不同，这样做的理由是什么；
是否对基础设施有额外的需求，它的使用对基础设施容量的影响如何；
特性的发布计划。
运维联络人也要参加团队的站会，把团队的需求纳入整体的运维计划，并且在必要的时候执行相关任务。在发生资源竞争或优先级冲突时，团队依赖运维联络人推进问题的解决。
相比融入运维工程师的模式而言，分派运维联络人的方式能支持更多的产品团队。我们的目标是确保运维不会成为产品团队的瓶颈。如果发现由于运维联络人的工作量过大而导致产品团队无法实现目标，那么就可能需要减少每个联络人所支持的团队数量，或者临时将运维工程师融入某些产品团队。
8.4 邀请运维工程师参加开发团队的会议 65
8.4.1 邀请运维工程师参加每日站会 65
每日站会是 Scrum 所推崇的形式。这是速战速决的会议，每个人都要向大家讲清楚三点：昨天做了什么？今天要做什么？遇到了什么难题？
通过参加会议的运维工程师，运维部门可以充分理解开发团队的活动，从而更好地进行规划和准备。例如，当产品团队正在计划两周内推出一个重要特性时，运维团队可以保证部署和发布所需的人员和资源提前就绪，或者加强需要进行更多沟通和准备的方面（例如创建更多的监控点或自动化脚本，例如进行数据库后台调优，例如搭建更多的环境用于集成测试和性能测试
8.4.2 邀请运维工程师参加回顾会议 66
回顾会议。在每个开发周期结束时，团队成员聚在一起讨论：哪些方面是成功的？哪些方面还需要改进？怎样把所取得的成功和改进应用到下一个迭代或项目中？
当回顾的时间段里正好有部署或发布时，运维工程师应该向大家汇报结果，并给产品团队提供反馈。这样做可以改进未来工作的计划和执行方式，提高工作的质量。
我们必须提醒所有人，改进日常工作其实比日常工作本身更重要，所有团队都必须为此预留时间（例如，每个周期都分配 20%的时间用于改进工作，安排每周一天或每月一周，等等）。如果不这样做，在偿还技术债务的巨大压力之下，团队的生产力肯定会遭到破坏。
8.4.3 使用看板图展示运维工作 66
运维工作是价值流的一部分，所以应该将它和与产品交付相关的其他工作一起呈现在看板图上。