《DevOps实践指南》笔记：第3章
第3章 第二步：反馈原则
在复杂系统中安全地工作
复杂系统特征：1）无法将系统视为一个整体，去理解各个部分是如何组合在一起的。2）复杂系统的组件之间通常是紧耦合且紧密关联的，不能仅仅依据组件的行为来解释系统的行为。3）相同的事情做两次，结果未必相同。
如何让复杂系统变得安全？管理复杂的工作，从中识别出设计和操作的问题；群策群力解决问题，从而快速地构建新知识；在整个组织中，将区域性的新知识应用到全局范围；领导者要持续培养有以上才能的人。
及时发现问题
我们要不断地对设计和假设进行验证。目标是更早、更快、以尽可能低的成本、从尽可能多的维度增加系统的信息流，并尽可能清晰地确定问题的前因后果。能排除的假设越多，定位和解决问题的速度就越快，从而提高我们的顺应力、敏捷性以及学习和创新能力。
整个价值流里要有快速、频繁和高质量的信息流——每个工序的操作都会被度量和监控，任何缺陷或严重偏差都能被快速发现和处理。建立全方位的监控系统。
反馈回路不但能让问题的快速探测和修复成为可能，而且还能告诉我们如何防止问题复发。反馈至关重要，因为它是我们工作的向导。我们必须不断地验证目标，验证实施是否满足了客户的需求，而测试仅仅是一种反馈。”
群策群力，战胜问题获取新知
群策群力的原因如下：
❏ 防止把问题带入下游的处理环节，否则不但修复的成本和工作量会呈指数级增加，而且还会欠下技术债；
❏ 防止工作中心启动新的工作，那样可能会在系统中引入新的错误；（单件流）
❏ 如果问题还没有得到解决，那么工作中心在下一次操作中，可能还会遇到相同的问题，需要更高的修复成本。
循环（即PDCA环）——计划（Plan）、实施（Do）、检查（Check）、改进（Act）
在源头保障质量
通常因为清晰度和及时性不足，自上而下的官僚主义和控制系统变得无效，导致了“应该做事的人”和“实际做事的人”之间存在巨大差异。
质量控制无效的例子如下：
❏ 需要其他团队帮忙完成一系列乏味、易出错和手动执行的任务，这些任务本应该由需求方自己采用自动化方式完成。
❏ 需要那些远离实际工作场所且公务繁忙的人批准，迫使他们在不了解工作情况和潜在影响的情况下做出决策，或者仅仅是例行公事式地盖章批准。
❏ 编写大量含有可疑细节，且在写后不久就过时了的文档。
❏ 将大量工作推给运维团队和专家委员去审批和处理，然后等待回复。
为下游工作中心而优化
在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。