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