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