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