devops - 反馈原则

第二步工作法是反馈的原则

我们的目标是建立安全和可靠的工作系统，不会发生重大故障。

通过在整个价流和组织中建立快速、频繁、高质量的信息流，包括反馈和前馈回路，可以让系统更安全。这样，就可以在规模较小，修复成本较代的情况下修复问题，在灾难发生前消除问题，前创造出组织性学习氛围。

复杂系统

工作系统应该属于复杂系统。复杂系统的一个重要特征是，不能依据组件的行为来解释系统的行为（组件的行为可以造成系统不可预知的结果；组件的小问题可能引起系统的大问题）；另一个特点：相同的事情做两次，结果未必相同。（即有时候不知道错误是怎么发生的）

复杂系统中的故障是存在且不可避免的。我们可能无法设计出绝对安全的系统，但是可以采取以下4项措施让复杂系统更安全的工作：

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

及时发现问题

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

我们要不断地对设计和假设进行验证，尽可能清晰地确定问题的前因后果。能排除的假设越多，定位和解决问题的速度就越快。

在技术价值流中，需要快速反馈机制，而小批量有助于形成快速的反馈机制。在瀑布型软件项目中，代码的开发可能花上一整年，在开始测试之前，我们得不到任何质量反馈，工作结果是很难达到预期的。

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

反馈回路能告诉我们如何防止问题的复发，因为我们从处理反馈信息的过程中了解到问题的前因后果，反馈不但提高了工作系统的质量和安全性，还创造了组织性知识。

反馈中客户的需求是最重要的一环。

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

这个原则的典范是丰田的“安灯绳”。在丰田制造工厂里，每个工作中心都有一条绳索，每个工人和经理都受过培训，他们会在出现问题是拉下安灯绳，比如，当零件有缺陷时，当需要的零件用光时，或者是加工时间比文档描述的时间长。

在安灯绳被拉动时，团队领导就能第一时间得知并立即着手解决问题。如果问题不能在指定的时间（如55秒）内解决，就会停掉整个生产线，调动整个企业一起协作，直到成功地找出解决问题的对策。

群策群力的原因如下：

• 如果问题出现了，流动到下游，在下游环节才确认问题必须修复，那修复的成本和工作量会呈指数级增加；
• 问题出现后，如果不停止，各个工作中心的工作状态会针对当前的工作不断变化，错误的原素将会渗透在工作中，以未知的方式，引起问题；在复杂系统里，由于人员、流程、产品、地点和境况中存在着很多意想不到的、特殊的相互作用，会出现很多问题。随着时间的推移，谁都不可能精确地重现问题发生时的场景。
• 问题不解决，问题还会再出现，需要更高的修复成本。

全民总动员让学习成为了可能。

我们需要创造出这样一种文化，让人们在发生问题时就去拉动安灯绳，并且这个行为是安全的甚至是受鼓励的。

在源头保障质量

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

从源头保障质量也指，在做某一些重要变更时，需论证必要性，让相关人员知道影响，指定合适变更时间，部署安全措施等；使用更多的自动化方式执行，如测试，部署。

信息安全并不是信息安全部门专属的工作，正如可用性不仅仅是运维部门的专属工作一样。

源头
在专门人员的控制领域里发现并解决问题。
同行评审
自动化测试
所有人负起了质量责任
快速反馈

为下游工作中心而优化

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

在技术价值流中，我们通过为下游工作中心（运维）做优化，开发如架构、性能、稳定性、可测试性、可配置性和安全性等非功能性功能，这些与用户功能同样重要，也是用户更好使用服务的基础。