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