Last reviewed 2024-12-30 UTC
Google Cloud Well-Architected Framework 的可靠性支柱中的这一原则提供了一些建议，可帮助您在发生故障和突发事件后进行有效的事后分析。
此原则与可靠性的学习 重点领域相关。
原则概览
事后分析是对突发事件、其影响、为缓解或解决突发事件而采取的措施、根本原因以及为防止突发事件再次发生而采取的后续行动的书面记录。事后分析的目的是从错误中学习，而不是追究责任。
下图显示了事后分析的工作流程：
事后分析的工作流程包括以下步骤：
- 创建事后分析
- 捕获事实
- 确定并分析根本原因
- 规划未来
- 执行方案
在发生重大事件和非重大事件（例如以下事件）后，进行事后分析：
- 用户可见的停机时间或性能降幅超过一定阈值。
- 任何类型的数据丢失。
- 值班工程师的干预措施，例如回滚版本或重新路由流量。
- 解决时间高于定义的阈值。
- 监控失败，通常意味着需要手动发现突发事件。
建议
在突发事件发生之前定义事后分析标准，以便每个人都知道何时需要进行事后分析。
如需进行有效的事后分析，请考虑以下各子部分中的建议。
进行无责备的事后分析
有效的事后分析侧重于流程、工具和技术，不会将责任归咎于个人或团队。事后分析的目的是改进您的技术和未来，而不是找出谁有罪。人人都难免犯错。目标应该是分析错误并从中学习。
以下示例展示了指责性反馈与无指责性反馈之间的区别：
- 指责性反馈：“我们需要重写整个复杂的后端系统！过去三个季度，它每周都会出现故障，我相信我们都厌倦了零散地修复问题。说真的，如果我再收到一次寻呼，我就自己重写…"
- 无责反馈：“重写整个后端系统的行动项实际上可能会阻止这些页面继续出现。此版本的维护手册非常长，很难完全掌握。我相信，我们未来的随叫随到工程师会感谢我们！
确保所有目标受众群体都能阅读事后分析报告
对于您计划在报告中包含的每条信息，请评估该信息是否重要且必要，能否帮助受众群体了解发生了什么情况。您可以将补充数据和说明移至报告的附录中。如果审核者需要更多信息，可以提出要求。
避免使用复杂或过度设计的解决方案
在开始探索问题的解决方案之前，请评估问题的重要性和再次发生的可能性。为解决不太可能再次发生的问题而增加系统复杂性可能会导致系统稳定性下降。
尽可能广泛地分享事后分析
为确保问题得到解决，请向广大受众群体发布事后分析结果，并获得管理层的支持。总结报告的价值与总结报告后发生的学习成正比。当更多人从突发事件中吸取经验教训时，类似故障再次发生的可能性就会降低。