DevOps 文字培训
应如何建立 DevOps 反馈机制？
在 IT 生态中，客户需求和请求不断变得更难满足，你和 DevOps 团队需要持续改进工作质量。为此，应在价值流中建立从右向左快速、持续且可靠的反馈循环。
这些反馈循环能帮助你趁障碍还小、消除成本低且易于处理时，迅速解决问题。它们还能帮助你在工作中建立组织学习文化。问题出现时，你和 DevOps 团队会把它当作学习机会，用来改进软件产品和服务的质量。
为什么需要借助 DevOps 反馈循环实现内置质量？
凭借软件工程行业的经验，你应该很清楚：在复杂系统中，谁也不可能知道一切。即便同样的工作原封不动地做两次，结果也可能不同。任何企业都无法容忍这种程度的结果不确定性，因此组织往往依靠质量保证机制实施控制，例如使用核对清单、审计、合规、质量保证专业人员和事无巨细的管理。然而，这些措施有时仍不足以避免错误。
因此，要建立能把质量融入工作的组织，首先要接受错误是日常工作的一部分。
营造安全工作体系文化
营造一种以安全工作体系为基础的文化。DevOps 团队没有人害怕犯错，因为大家知道，错误会在还很小的时候迅速得到发现和修复，避免造成重大缺陷、服务中断和客户差评等严重后果。
营造安全工作体系文化后，你、DevOps 团队以及整个 IT 和业务组织都会得到以下好处：
- 系统的复杂性将得到控制，因此设计和运维中的问题可以很快被发现。
- 问题尚小时即可迅速解决。解决问题的过程会自然积累新的组织知识和经验。
- 新知识和经验得以在整个组织中传播和分享。
- DevOps 组织的领导者培养其他领导者，由他们建立并持续改进安全工作体系。
问题一出现就识别
如果组织的反馈机制缓慢、不频繁而且滞后，就会错过及时预防不良结果的机会，预防成本也会升高。过去按瀑布式方法交付软件时，团队花一年构建应用，才第一次给客户看，然后再花一年重写。如今没有企业能负担得起这种工作方式。
你的目标是建立快速反馈循环。工作在价值流中从左向右推进时，应不断从右向左提供反馈。在 DevOps 组织中将质量融入工作，关键就在于建立快速反馈循环。引入问题后，DevOps 团队在它首次出现在价值流中时就能识别。你和团队迅速修复问题，并持续确认你的实现是否符合客户期望。这里的客户包括内部客户、外部客户，以及价值流中受工作影响的其他所有利益相关方。快速反馈循环不仅能帮助你迅速修复问题，也能帮助你从中学习，避免日后重犯同样的错误。
趁修复更容易、更快且成本更低时消除错误
快速发现问题，也就能快速修复问题。否则，
- 修复错误的成本和工作量会呈指数级增长，而且你会任由技术债务（在临时解决办法上再叠加临时解决办法）不断累积。
- 错误会传递到价值流中的下游工作中心，很可能引发其他错误。
- 错误会在远离其最初引入位置的工作中心反复出现，需要你花费更多精力进行修复和消除。
- 人们会逐渐忘记错误最初为什么发生，导致错误的情况也会改变。如果错误引入数月后才首次被发现，就很难找出真正的根本原因，更糟的是也无法从中学习。你只能用临时解决办法应付眼前问题，接着转向下一个临时解决办法。你已经知道，这正是采用 DevOps 所要避免的。
鼓励自己和 DevOps 团队主动发声，建立持续反馈机制，以识别并迅速修复错误。切勿在有错误的工作上继续叠加有错误的工作。也就是说，别让团队在修复会妨碍新功能开发的错误之前，就开始构建这些功能。持续提升工作质量，并在错误发生时持续消除错误，就能确保你打造出所在市场上最好的软件产品与服务。
让质量控制决策留在实际开展工作的地方
如果把质量控制决策推到离实际工作更远的地方，就会降低质量、延长交付前置时间、削弱因果之间的反馈，并降低你从错误中学习的能力。
简单来说：
- 对于可以自动化的质量控制工作，无需要求团队手动完成。
- 无需要求对所做工作几乎或完全不了解的忙碌人员审批。
- 无需为审批编制大量文档，这些文档会因工作性质而很快过时。
- 不要将大批量工作提交给审批人员。
DevOps 团队的每位成员都应在自己能掌控的范围内发现、修复、分享和讨论错误，并传授相关经验。通过结对编程、同行评审、自动化测试、检查代码提交、设置内部检查点和频繁演示，让质量保证成为每个人的责任，而非专门的质量保证部门的责任。
总结
你和 DevOps 团队始终清楚，你们的报酬来自为客户服务。因此，应始终以内部和外部客户的最大利益为出发点。
同时，价值流中的下一个工作中心尤其重要。应设身处地为他们优化你的工作，并与他们建立快速可靠的反馈机制，使价值流快速、顺畅且高质量地运行，让 DevOps 团队尽快识别和解决问题。
