从检测到解决的生产故障处理结构化流程——涵盖严重性评估、团队协调、沟通模板和事后分析要求。
使用场景
- 生产服务不可用
- 部分用户受影响的局部中断
- 触发告警的性能下降
主要功能
- 评估严重性：P0（全面停机）、P1（主要功能故障）、P2（体验降级）、P3（轻微问题）
- 在 #incidents 频道声明故障，说明严重性、影响范围和你的姓名（事故指挥官）
- 组建响应团队：受影响服务的值班工程师、负责利益相关方更新的沟通负责人
- 立即缓解：回滚最近部署、禁用功能开关或激活熔断——优先恢复服务而非寻找根本原因
- 在声明故障后 15 分钟内通过状态页面通知受影响用户
- 同时进行根因调查和监控——使用仪表板和日志，而非推测
- 服务恢复后更新状态页面，并在 48 小时内召开事后分析会
- 撰写事后分析：时间线、根因、促成因素，以及带负责人和截止日期的行动项
相关推荐
相关推荐
3 收录条目
系统化调试
用假设—验证—最小复现替代拍脑袋，适合线上事故、构建抖动和难以复现的行为回归。
事故复盘触发与根因分布（附录 C）
依据 Google SRE Workbook「附录 C - Results of Postmortem Analysis」，说明为何需在组织内统一事故的「触发维度」与「根因类目」两组标签：附录基于大量历史复盘样本列出常见 outage 触发因素占比——如二进制推送约 37%、配置推送约 31%，以及用户行为、管线、提供商变更、性能衰退、容量、硬件等分项；并就根因给出软件缺陷约 41.35%、研发流程失效约 20.23%、复杂系统行为约 16.90%、部署计划约 6.74%、网络故障约 2.75%等分布（均为附录所述统计区间内的汇总）。落地时应沿用其分类颗粒度并结合自身事故库重算权重，而非照搬数字。
内容刷新
定期扫一遍旧工具、MCP、技能和资讯条目，处理过期价格、失效文档链接与弱摘要，不让目录慢慢变旧。