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

而第二部工作法描述的反馈原则，则是让工作从右向左的每个阶段，能快速、持续地获得反馈。

第二步工作法的目标是建立安全可靠地工作系统，这一点对于复杂的系统非常重要。

在复杂的系统中，往往只有在灾难性事件发生时才能发现和纠正错误，例如制造业中，工人在在工作中受伤后，才想办法解决问题。

而在技术行业， 我们的工作几乎都发生在灾难性后果如影随形的复杂系统中。

技术行业与制造业类似，通常只有发生重大故障时才能发现问题，比如遇到大规模用户服务终端，或安全漏洞导致客户数据泄露。

反馈原则就是我们要在整个价值流和组织中，建立快速、频繁且高质量的信息流，包括反馈和前馈回路，这些都可以提升系统的安全性。

通过反馈原则，可以在问题规模较小、修复成本较低的情况下发现并修复问题。

反馈原则能让我们在灾难发生前消除问题，创造出组织型学习的氛围。

同时我们要把失败和事故的发生，看作是宝贵的学习机会，而不是惩罚和责怪某人的理由。

为了实现上述目标，我们要探索复杂系统的本质，找出能让复杂系统更安全的解决方案。

1. 在复杂系统中安全地工作

复杂系统的一个重要特征是，无法通过系统看作是整体，去可理解系统的各个部分是如何组合在一起的。

复杂系统的组件之间通常是高度耦合且紧密关联的，不能依据组件的行为解释系统的行为。

Steven Spear 博士在他的博士论文中揭示了丰田生产系统背后的因果机制，Steven 认为我们无法设计出绝对安全的系统，但是下面 4 种能力让复杂系统更安全地工作：

• 管理复杂的工作，从中识别出设计和操作问题；
• 群策群力解决问题，快速构建新知识；
• 把局部的新知识应用到整个组织中；
• 领导者要持续培养有以上才能的人；

接下来我们将介绍前 4 种能力的实现方法和它们的重要性，同时还会探讨其他领域实现这些能力的方法，包括技术价值流。

1.2 反馈机制

在安全的系统中，通过在系统中建立反馈和前馈回路，我们能不断验证设计和假设，目标是更早、更快、用更低的成本、从尽可能多的维度增加系统的信息流。

并且能尽可能清晰地确定问题的前因后果，我们排除的对问题的假设假设越多，定位和解决问题的速度就越快。

从而提升我们的顺应力、敏捷性以及学习和创新能力。

Peter Senge 博士在《第五项修炼》一书中，描述了反馈回路是学习型组织和系统思维的重要组成部分，反馈和前馈回路，能增强或削弱系统内各个部件之间的关系。

在制造业，如果缺乏有效的反馈机制，往往会导致重大的质量和安全问题。

比如通用汽车的弗里蒙特工厂，该工厂没有有效的机制检测装配过程中的问题，没有明确的解决问题步骤。

导致如发动机倒置、汽车缺少方向盘或轮胎，甚至根本无法启动，结果汽车不得不拖出装配流水线。

相比之下，在高绩效的制造业运营中，整个价值流中存在快速、频繁和高质量的信息量。

每个工序的操作都会被度量和监控，任何缺陷都能快速发现和处理。

这是保证质量、安全与持续学习和改进的基础。

在技术价值流中，如果缺少快速反馈机制，往往会得到糟糕的工作结果。

比如在采用瀑布开发模式的项目中，可能会投入一年时间进行开发，在开始测试或发布软件前都得不到任何反馈。

在反馈少且慢的情况下，工作质量往往不达标。

相反，DevOps 的目标是在技术价值流的各个阶段，包括产品管理、开发、QA、信息安全和运维阶段，在所有工作执行的过程中，建立快速的反馈和前馈回路。

包括自动化构建、集成和测试工作，以便尽早检测出可能导致缺陷的代码变更。

此外还要建立全方位的监控系统，监控服务组件在生产环境中的运行状态，以便快速探测服务的意外情况。

监控系统能帮助我们度量是否偏离了预期目标，并把监控结果传播到整个价值流中，这样就能看到我们的行为对系统其它部分的影响。

反馈回路不但能让我们快速检测和修复问题，而且还能告诉我们如何防止问题复发，提升了工作系统的质量和安全性，还建立了组织性知识。

1.3 安灯绳

只发现意外是不够的，一旦出现问题，我们还要群策群力，发动所有相关人员解决问题。

Spear 博士认为，群策群力的目的，是遏制住问题，防止蔓延，然后定位和处理问题，避免复发。

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

这个原则的典范的丰田的安灯绳（安灯按钮），在丰田工厂中，每个工作中心都是一条绳索。

每个工人和经理都受过培训，比如当零件有缺陷时、需要的零件用光时、加工时间比文档描述的长等问题出现时，他们就会拉下安灯绳。

当安灯绳被拉动后，团队领导就能第一时间得知并立刻想办法解决问题。

如果问题不能再指定时间内解决，比如 55 秒内，就会停掉整个生产线，让整个企业一起合作，直到找出解决问题的办法为止。

在发现问题时，一般的企业会用“时间不够”这个借口来逃避问题，而实践 DevOps ，意味着我们接下来在遇到问题时，要立刻群策群力解决这个问题。

立刻解决问题有下面几个好处：

• 减少修复成本

  防止把问题带到下游，否则修复问题的成本会剧增，而且还会带来技术债；

• 避免引入错误

  防止工作中心启动新的工作，因为问题可能会把新的错误引入系统中；

• 避免重复损失

  如果没立刻解决问题，那下一次操作时很可能还会遇到类似的问题，导致更大的损失、更高的修复成本；

这种全民动员的做法与常规的管理方法不同，因为局部问题扰乱了整体的运营，但是这种方式让大家都能从问题中学习到知识。

立刻解决问题，能防止记忆模糊和情况变化导致的关键信息丢失，关键信息对于修复复杂系统中的问题很重要。

在复杂系统中，人员、流程、产品、地点和情况都存在很多意料之外、特殊的相互作用，随着时间的推移，往往很难再重现问题发生时的场景。

Spear 博士的看法是，全民动员是实时识别、定位和处理问题循环的一部分。

这个循环就是统计质量控制之父休哈特提出的 PDCA 循环：

• 计划（Plan）
• 实施（Do）
• 检查（Check）
• 改进（Act）

PDCA 循环后来由质量管理专家戴明推广并得到了广泛的应用。

只有通过全民动员，尽早地解决小问题，才能把灾难性事故扼杀在萌芽阶段。

要想在技术价值流中建立快速反馈的机制，我们就要建立类似于安灯绳和全员响应的机制。

我们要树立一种文化，鼓励大家在发生问题时拉动安灯绳，无论是生产事故还是价值流的早期出现错误，这个行为是安全的。

比如当有人提交代码导致持续构建或测试失败，触发安灯绳时，我们就可以聚集在一起解决问题，停止开展任何新的工作，直到问题解决了为止。

这快速地给价值流中的每个人提供而反馈，尤其是提交了导致构建失败的代码的人。

使用安灯绳机制，能让我们快速地定位问题，避免出现更复杂的情况，导致问题的因果关系变得模糊。

组织开展新工作，有助于实现持续集成和部署，也就是技术价值流中的单件流。

通过持续构建和集成测试的所有变更，都可以部署到生产环境。

任何导致测试失败的变更，都会触发安灯绳，而且会把大家聚集起来一起解决问题。

1.4 在源头保证质量

基于对意外和事故的处理模式，我们可能会在无意中，把某种不安全的工作系统固化下来。

在复杂系统中，通过加入更多的检查步骤和审批流程，不但不会降低故障率，甚至可能导致故障率上升。

这是因为作出决策的地方，往往远离执行工作的地方，导致审批流程的有效性下降。

建立更多审批流程，不仅降低了决策质量，还增加了决策周期，削弱了因果关系之间的反馈强度，降低了在成功和失败中学习的能力。

即使在一些较小的简单系统中，也存在这种情况，一般是因为清晰度和及时性不足，自上而下的官僚主义和控制系统变得无效，导致应该做事的人和实际做事的人存在巨大差异。

质量控制无效的例子：

• 非自动化

  需要其他团队帮忙完成一系列乏味、易出错和需要手动执行的任务，这些任务本该由需求方采用自动化的方式完成。

  比如测试人员需要开发人员才能打包，而不是通过 Jenkins 自己调整配置，自动打包。

• 远离现场

  现场指的是执行工作的场所。

  当决策需要远离实际工作场所，并且工作繁忙的领导批准时，往往会出现领导在不了解工作情况和潜在影响的情况下，作出低质量的决策，又或者只是例行公事地盖章。

• 无效文档

  编写大量含有有歧义的细节，并且在写后不久就过时的文档。

  一般的需求文档都存在这个问题，这个问题可以用 BDD 的方式来解决。

• 等待

  将大量工作推给运维团队或其他团队进行审批和处理，接下来只能等待回复。

在源头保证质量，意味着不论是质量控制还是安全责任，决策都要由执行工作的人作出，而不是依赖于高层领导的审批。

根据同行评审评定变更，确保变更将按照设计运行，以自动化的方式进行质量和安全性检查。

有需要的人可以按需执行自动化测试，不需要开发团队向测试团队请求或自己发起测试工作。

这样开发人员就能快速测试自己的代码，并把通过测试的代码变更部署到生产环境中。

在源头保证质量，要能让所有人都为自己的工作质量负责，而不是由某个部门负责。

1.5.5 服务好内部客户

在制造业，一般产品的设计会把大多数精力都放在外部客户的体验上，忽略了内部利益相关人，比如生产线工作。

而在 20 世纪 80 年代提出的可制造设计（Designing for Manufacturability）原则，该原则的目的是设计零件和工艺过程，让成品能以最低的成本、最高的质量和最快的流程生产出来。

比如设计非对称的部件，避免装反，设计螺丝紧固件，避免部件被拧得太紧，需要时难以拧下来。

精益要求我们的设计要为两类客户服务：

• 外部客户

  有可能为我们的服务付费的人；

• 内部客户

  组织内部接收和处理工作的人；

根据精益原则，我们最重要的客户是我们的下游工作中心。

比如我们是开发团队的，我们的下游是测试团队，那测试团队就是我们最重要的客户。

我们要服务好下游工作中心，解决他们遇到的问题，找出阻碍快速和平滑流动的设计问题。

在技术价值流中，我们通过为运维为下游工作中心的工作做优化。

包括运维的非功能性需求，如架构、性能、稳定性、可测试性、可配置性和安全性，这些非功能性需求，和产品功能的可用性是同样重要的。

1.5 小结

建立快速的反馈机制，对于实现技术价值流中的高质量、可靠性和安全性非常重要。

所以在遇到问题时，我们要群策群力地解决问题，并从中获得新的知识。

并且在源头控制质量，不断为下游工作中心提供更好的服务。