Thread by @insutantow

#Reading #DevOps
《DevOps实践指南》第三章·第二步: 反馈原则
反馈原则使得价值流在从右向左的每个阶段中能够快速、持续地获得工作反馈。
1.及时发现问题
2.群策群力，战胜问题获取新知
3.在源头保障质量
4.为下游工作中心而优化

Steven Spear的论文认为，我们可能无法设计出绝对安全的系统，但以下措施能让复杂系统更安全地工作：
管理复杂的工作，从中识别出设计和操作的问题；
群策群力解决问题，从而快速地构建新知识；
在整个组织中，将区域性的新知识应用到全局；
领导者要持续培养有以上才能的人。
mitsloan.mit.edu/shared/ods/doc…

及时发现问题:
在技术价值流的每个阶段（包括产品管理、开发、QA、信息安全和运维），建立快速的反馈和前馈回路。包括创建自动化的构建、集成和测试，尽早检测出可能导致缺陷的代码变更。
建立全方位的监控系统，快速探测服务的意外情况。度量是否偏离了预期目标，并将监控结果辐射到整个价值流。

群策群力:
我们不应绕开问题，也不应该用“有更多时间时再解决”来搪塞，而要立刻群策群力修复问题。全民动员的做法似乎违背了常规管理方法，因为局部问题扰乱了整体的运营。然而，全民动员让学习成为了可能。它还能防止由于记忆模糊和情况变化导致的关键信息遗失，这在复杂系统中显得尤为重要。

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

为下游工作中心而优化:
在技术价值流中，我们通过为运维而设计来为下游工作中心做优化，包括运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。
这样，我们就在源头保障了质量，并形成了一套非功能性需求，可以主动地将它们集成到构建的所有服务中。