《DevOps实践指南》- 读书笔记（一）-Toy模板网

这篇具有很好参考价值的文章主要介绍了《DevOps实践指南》- 读书笔记（一）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

Part 1 DevOps 介绍

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

流动原则：它加速了从开发、运维到交付给客户的流程。
反馈原则：它使我们能建设出更安全可靠的工作体系。
持续学习与实验原则：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。

精益运动

价值流映射、看板和全面生产维护这些实践起源于 20 世纪 80 年代的丰田生产系统。1997 年，精益企业协会开始研究如何将精益理念应用于服务业和医疗行业等其他价值流中。

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

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

敏捷宣言

敏捷宣言是在 2001 年由软件领域的 17 位顶尖大师共同提出的。他们希望用一套轻量级的价值观和原则体系，来优化那些沉重的软件开发流程（如传统的瀑布式开发模型）和方法论（如统一软件开发过程）。

在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。

在很多实施了敏捷的企业里，生产效率显著提升，敏捷也因此获得了越来越广泛的支持和认可。有趣的是，在 DevOps 的发展历程中，如下所述的几个关键活动都发源于敏捷社区或者敏捷大会

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

1.1 制造业价值流

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

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

1.2 技术价值流

“把业务构想转化为向客户交付有价值的、由技术驱动的服务所需要的流程”

流程的输入是既定的业务目标、概念、创意和假设，始于研发部门接受工作，并将它添加到待完成工作列表中。

应用程序或服务只有在生产环境中按预期正常地运行，并为客户提供服务，所有的工作才产生价值。

1.2.1 聚焦于部署前置时间

部署的前置时间是价值流的一个子集。

价值流始于工程师（包括开发、QA、IT 运维和信息安全人员）向版本控制系统中提交了一个变更，止于变更成功地在生产环境中运行，为客户提供价值，并生成有效的反馈和监控信息。

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

我们并不提倡在设计、开发中串行地完成了大批量的工作后，再转入测试、运维阶段（如使用大批量、基于瀑布模型的开发流程，工作在长生命周期的特性分支上）。恰恰相反，我们的目标是采用测试和运维与设计和开发同步的模式，从而产生更快的价值流和更高的质量。只有当工作任务是小批量的，并将质量内建到价值流的每个部分时，这种同步的模式才能实现。

定义前置时间和处理时间
在精益社区里，前置时间与处理时间（有时候也被称为接触时间或者任务时间）是度量价值流性能的两个常用指标。
- 前置时间在工单创建后开始计时，到工作完成时结束；
- 处理时间则从实际开始处理这个工作时才开始计时，它不包含这个工作在队列中排队等待的时间
常见的场景：为期数月的部署前置时间
通常，部署前置时间动辄需要好几个月。部署前置时间一旦变长，那么在价值流的每个阶段，几乎都需要“填坑”能手来补救。通常，
很可能是在项目结束前，将开发团队的变更合并到一起后，才发现整个系统根本无法正常工作，有时甚至会出现代码都无法通过编译和测试的情况。每一个问题可能都需要几天甚至几周的时间来定位和修复，因此导致了极其糟糕的客户体验。
我们的目标：分钟级别的部署前置时间
我们可以通过如下方式达到这个目标：向版本控制系统中持续不断地提交小批量的代码变更，并对代码做自动化测试和探索测试，然后再将它部署到生产环境中。这样，我们就能对代码变更在生产环境中的成功运行保持高度自信，同时还能快速地发现并修复可能出现的问题。

为了更容易地实现上述目标，还需要通过模块化、高内聚、低耦合的方式优化架构设计，帮助小型团队自治地工作。这样即便失败了，也能在可控范围内，而不至于对全局产生影响。

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

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

“要获取%C/A，可以询问下游客户他们有百分之多少的时间收到了‘真正有用的工作’，即他们可以专心做有用的工作，而不必修复错误信息、补充信息，或者澄清那些本该确定的信息。”

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

三步工作法
《DevOps实践指南》- 读书笔记（一）,# devops,devops,运维

第一步，实现开发到运维的工作快速地从左向右流动。
为了最大程度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标。

相关的实践包括持续构建、集成、测试和部署，按需进行环境搭建，限制在制品数量，构建能够安全地实施变更的系统和组织。
第二步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制。
该方法通过放大反馈环防止问题复发，并能缩短问题检测周期，实现快速修复。

通过这种方式，我们能从源头控制质量，并在流程中嵌入相关的知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并解决它。
第三步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。
通过主动地承担风险，不但能从成功中学习，也能从失败中学习。

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

作为第三步的一部分，我们能够让工作系统事半功倍，将局部优化转化为全局优化。另外，不管是谁参与了工作，所有经验都可以持续地积累，组织里的人都可以相互借鉴彼此的经验和智慧。

2. 第一步：流动原则

在技术价值流中，工作通常是从开发人员流向运维人员，也就是业务和客户之间的所有职能部门。

本章要描述的第一步工作法，就是建立从开发到运维之间快速的、平滑的、能向客户交付价值的工作流。要为这个全局目标进行优化，而非围绕一系列局部目标，如功能开发的完成度、测试中问题的发现率和修正率、运维维护的可用性等。

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

我们的目标是在缩短代码从变更到生产环境上线所需时间的同时，提高服务的质量和可靠性。实际上，我们可以在制造行业中找到价值流应用的相关线索，帮助我们将精益原则应用到技术价值流中。

2.1 使工作可见

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

为了能识别工作在哪里流动、排队或停滞，就需要将工作尽可能地可视化。可视化工作板是一种较好的工作方式，如在看板或 Sprint 计划板上，使用纸质或电子卡片将各项工作展示出来
《DevOps实践指南》- 读书笔记（一）,# devops,devops,运维

理想情况下，看板应该覆盖整个价值流；仅当工作到达看板最右侧时，才能算是已完成。开发完成某个功能不能算是“已完成”，只有应用程序在生产环境里成功地运行起来，并开始为客户提供价值的时候，才能算是“已完成”

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

2.2 限制制品数

技术工作通常是动态的——尤其是存在共享服务的情况下，团队必须要同时满足很多利益干系人的需求，这导致临时安排控制了日常工作。

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

当使用看板管理工作时，可以限制多任务的出现。通过限制制品数，还能更容易地发现工作中的阻碍。

2.3 减小批量大小

在精益中，一个重要的经验是：为了缩短前置时间和提高交付物质量，应当持续不断地追求小批量模式。理论上，最小的批量是单件流，也就是每次操作只执行一个单位产品的处理。

“模拟邮寄宣传册”的经典案例"
这个例子假设要邮寄出 10 本宣传册。邮寄之前，每本宣传册都必须经历 4 个步骤：折叠，插入信封，给信封封口，盖戳。

如果采用大批量策略（即“大规模生产”），我们会对每本宣传册按顺序执行上述 4 个步骤。换句话说，首先要将 10 张纸全都折叠完，再将每张纸分别插入信封，然后给所有的信封封口，最后全部盖章。

小批量策略（即“单件流”），即对每本宣传册顺序地执行所需的所有步骤，然后再开始处理下一本宣传册。换句话说，先折叠一张纸，将其插入信封，再给信封封口，之后盖章；然后，取下一张纸，并重复以上过程。

采用大批量和小批量策略之间的差异是巨大的。假设对所有 10 个信封都必须采取如上 4 个步骤，并且每一步操作需要 10 秒。如果使用每批 5 个的大批量策略处理，则完成第一个盖戳的信封需要用 310 秒。
《DevOps实践指南》- 读书笔记（一）,# devops,devops,运维

更糟糕的是，假设我们在信封封口操作中发现第一步的折叠做错了(假设只有在封口的时候才能发现)，在这种情况下，我们能发现错误的最早时间是在 200 秒之后，那样我们就不得不将这个批次的 10 个小册子再重新折叠并装回信封中。
相比之下，使用小批量策略时，仅用 40 秒就完成了第一封盖戳信的生产，比大批量策略快8 倍。如果第一步出错了，只需要返工一本小册子。小批量生产的在制品更少，前置时间更短，错误检测更快，返工量更少。

2.4 减少交接次数

在技术价值流中，如果部署的前置时间以月作为周期单位，通常是因为要将版本控制系统中的代码部署到生产环境需要数百甚至数千个操作。实际上，代码在价值流流转的过程中，需要各个不同部门的协同才能完成相关任务，包括功能测试、集成测试、环境搭建、配置服务器、存储管理、网络、负载均衡设备和信息安全加固等。

一项工作在团队之间交接时，需要大量的沟通——请求、委派、通知、协调，而且经常需要排优先级、调度、消除冲突、测试和验证。

为了减少这类问题的出现，要么努力减少交接次数，要么用自动化方式执行大部分操作，要么重新调整组织结构，让团队不必依赖其他人就可以独立地为客户提供价值。因此，要通过减少队列中的等待时间以及非增值工作的时间来增加流动性

2.5 持续识别和改善约束点

为了缩短前置时间、提高吞吐量，我们需要不断地识别系统中的约束点，提高工作产能。

“在任何价值流中，总是有一个流动方向、一个约束点，任何不针对此约束点而做的优化都是假象。”

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

解决方案：

识别系统的约束点；
决定如何利用这个系统约束点；
基于上述决定，考虑全局工作；
改善系统的约束点；
如果约束点已经突破了，请回到第一步，但要杜绝惯性导致的系统约束。

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

环境搭建
如果生产或测试环境的搭建总是需要数周或数月，则按需部署就无法实现。解决措施是按需建立完全自服务的环境，保证团队在需要环境的时候，能通过自动化方式创建
代码部署
如果代码的部署需要花数周或更长时间（譬如每次部署需要 1300 个手动、易出错的操作，涉及多达 300 名工程师），那么就无法按需部署。解决措施是尽可能自动化部署的过程，以便让任何开发人员都可以按需自动化地部署。
测试的准备和执行
如果每次代码部署都需要两周的时间来完成测试环境的准备和数据集的配置，手动执行所有的回归测试还需要另外四周时间，那么就无法实现按需部署。解决措施是实现自动化测试，这样才能在安全、并行地执行部署的同时，使测试的速度能跟上代码开发的速度
紧密耦合的架构
如果架构是紧密耦合的，那也无法实现按需部署，因为每次要做代码变更时，工程师都不得不从变更评审委员会里获得执行变更的许可。解决措施是创建松散耦合的架构，这样开发人员才能安全、自主地进行变更，提高生产力

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

精益中对浪费的常用定义是“使用了超出客户需求和他们愿意支付范围的任何材料或资源的行为”。

浪费和困境是软件开发过程中导致交付延迟的主要因素，部分类型：

半成品：它指的是价值流里任何还没有彻底完成的工作（例如，需求文档或尚未审核的变更单）、处于队列中的工作（如等待 QA 审核或服务器管理员审核的工单）。部分完成的工作会逐渐地过期，随着时间的推移最终失去了价值。
额外工序：在交付过程中执行的、并未给客户增值的额外工作，可能包括那些在下游工作中心从没使用过的文档，或是对输出结果做出的并不增值的评审或审批。额外工序不仅增加了处理的工作量，还增加了前置时间
额外功能：在交付过程中构建的那些组织或客户完全不需要的功能（如“镀金”）。额外功能增加了功能测试和管理的复杂度和工作量。
任务切换：将人员分配到多个项目和价值流里后，他们需要进行上下文切换，并管理工作之间的依赖关系，这会在价值流中耗费额外的工作量和时间。
等待：由于资源的竞争而在工作之间产生了等待，这将增加周期时间，延迟了向客户交付价值。
移动：信息或数据在工作中心之间移动的工作量。例如，在一个需要频繁沟通的项目里，团队成员实际上不在一起办公，无法坐在一起紧密协作，这时人员移动的浪费就产生了。另外，工作交接也会产生移动的浪费，需要额外的沟通来澄清所有歧义的部分。
缺陷：由于信息、材料或产品的错误、残缺或模糊，而需要一定的工作量来确认。缺陷的产生和被检测出来的时间间隔越长，解决问题就越困难。
非标准或手动操作：需要依赖其他人的非标准的或手动的工作，例如使用不能自动化反复重建的服务器、测试环境和配置。理想情况下，任何依赖运维团队手动完成的操作，都应该配置成自动化的、按需提供的，或者是自助服务。
填坑侠：为了实现组织的目标，不得不把有些人和团队置于不太合理的处境，这甚至会成为他们的家常便饭（如半夜两点生产环境出现事故，连夜给软件版本提交了上百个工单）

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

2.7 小结

提升技术价值流的流动性对实施 DevOps 来说至关重要。为此，我们需要将工作可视化，限制在制品数，减小批量大小，减少交接次数，持续地识别和改进约束点，以及消除日常工作中的困境。

3. 第二步：反馈原则

第一步工作法描述的原则（流动原则），使得工作能够在价值流中从左向右快速地流动。
第二步工作法描述的原则（反馈原则），则使得在从右向左的每个阶段中能够快速、持续地获得工作反馈。
我们的目标是建立安全和可靠的工作系统

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

复杂系统的一个重要特征是，无法将系统视为一个整体，去理解各个部分是如何组合在一起的。复杂系统的组件之间通常是紧耦合且紧密关联的，不能仅仅依据组件的行为来解释系统的行为

复杂系统中的故障是存在且不可避免的。因此，无论在制造业还是信息技术行业，我们都必须设计出一个安全的工作系统，让员工能无所畏惧地开展工作，确保早在灾难性后果（例如人员伤害、产品缺陷或负面的客户影响）发生之前，能快速检测出错误

我们可能无法设计出绝对安全的系统，但是可以通过采取以下 4 项措施让复杂系统更安全地工作：

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

3.2 及时发现问题

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

我们通过在工作系统中建立反馈和前馈回路的方式实现这一点

在高绩效的制造业运营中，整个价值流里存在着快速、频繁和高质量的信息流——每个工序的操作都会被度量和监控，任何缺陷或严重偏差都能被快速发现和处理。这些是保证质量、安全和持续学习与改进的基础。

我们的目标应该是在技术价值流的每个阶段（包括产品管理、开发、QA、信息安全和运维），在所有工作执行的过程中，建立快速的反馈和前馈回路。这包括创建自动化的构建、集成和测试过程，以便尽早检测出那些可能导致缺陷的代码变更。

我们还要建立全方位的监控系统，监控服务组件在生产环境中的运行状态，以便快速探测到服务的意外情况。监控系统还能帮助我们度量是否偏离了预期目标，并将监控结果辐射到整个价值流中，这样就能看到我们的行为是如何影响系统里的其他部分的

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

显然，仅仅检测出意外的发生是远远不够的。一旦问题出现了，我们还必须群策群力，发动所有相关的人员解决问题。

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

群策群力的原因如下：

防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增加，而且还会欠下技术债；
防止工作中心启动新的工作，那样可能会在系统中引入新的错误；
如果问题还没有得到解决，那么工作中心在下一次操作中，可能还会遇到相同的问题，需要更高的修复成本。

3.4 在源头保障质量

质量控制无效的例子如下：

需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务，这些任务本应该由需求方自己采用自动化方式完成。
需要那些远离实际工作场所且公务繁忙的人批准，迫使他们在不了解工作情况和潜在影响的情况下做出决策，或者仅仅是例行公事式地盖章批准。
编写大量含有可疑细节，且在写后不久就过时了的文档。
将大量工作推给运维团队和专家委员去审批和处理，然后等待回复。

在日常工作中，我们需要价值流中的每个人在他们的控制领域里发现并解决问题。通过这种方式，可以把质量控制、安全责任和决策制定都置于开展工作的场景里，而不是依赖于外围高层管理者的审批。

3.5 为下游工作中心而优化

精益定义了我们必须为两类客户而设计：外部客户（最有可能为我们提供的服务付费的人）和内部客户（紧随我们立即接收和处理工作的人）。根据精益原则，我们最重要的客户是我们的下游。为他们而优化我们的工作，需要我们对他们的问题给予同情心，从而更好地识别出会阻碍快速和平滑流动的设计问题。

在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。

3.6 小结

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

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

第一步建立了从左到右的工作流（流动原则）
第二步建立了从右到左的快速、持续的反馈（反馈原则）
第三步要建立持续学习与实验的文化（持续学习与实验原则）

通过应用三步工作法能够持续提升个人技能，进而转化为团队和组织的财富。

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

为日常工作的改进预留时间，从而进一步促进和保障学习。通过不断向系统加压的方式，来强化持续改进。在可控的情况下，我们甚至通过在生产环境里模拟或者注入故障来增强弹性（resilience）

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

在技术价值流中，通过努力打造安全的工作系统，我们能建立起生机文化的基础。在意外和故障发生时，关注如何重新设计系统，从而防止事故复发，而不是去追究人的问题。

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

在技术价值流中，为了防止灾难性事故的发生，团队陷于实施各种临时解决方案的工作中，反而没有时间去完那些有价值的工作。因此，用临时方案解决问题的模式往往还会导致问题和技术债务的累积。

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

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

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

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

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

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

高绩效组织则通过改善日常运营，持续地引入张力提高生产效率，同时在系统中注入更大的弹性，来实现或达到更佳的结果。

通过在日常工作中持续不断地实验，他们能够持续地提高产能，并且不需要增加任何新设备或人员。引入这种类型的改进不仅提高了生产效率，而且还提高了弹性，因为组织总是处在紧张和变化的状态中。

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

4.5 领导层强化学习文化

领导者和一线工作者之间是互补的工作关系，必须互相尊重。这种关系是必要的，因为谁都无法独立解决问题——领导者不会
亲自从事解决问题所需的一线工作，而一线工作者也不了解大的组织环境，或不具备在工作领域以外做出改变的权力。

在这些战略目标的指导下，我们建立相互嵌套的迭代的短期目标，然后在价值流或工作中心级别设立目标条件（如在接下来的两周里缩短 10%的前置时间），以实现这些目标。这些目标条件构成了科学实验的框架：清晰地描述出要解决的问题，对解决方案所做的假设，验证假设的方法，对结果的解释，以及如何利用经验进行下一个迭代。

领导者可以使用下列问题来帮助和辅导实验者：