事故管理
目的
定义当用户或生产系统受影响时，团队如何响应。
工具
| 需要 | 工具 |
|---|---|
| 事故房间 | Slack/Lark channel |
| 告警 | Grafana / Sentry / Datadog / PagerDuty |
| 时间线 | 事故群 thread + postmortem 文档 |
| Action items | Linear/Jira |
| Runbook | Repo docs 或 Notion/Lark Wiki |
严重度
| 等级 | 定义 | 响应 |
|---|---|---|
| SEV1 | 大范围用户不可用、数据或安全事故 | 立即全员响应 |
| SEV2 | 关键功能不可用或显著客户影响 | 当天响应 |
| SEV3 | 降级但有 workaround | 正常优先级但必须跟踪 |
| SEV4 | 小问题或内部问题 | backlog |
角色
| 角色 | 负责 |
|---|---|
| Incident Commander | 协调和优先级 |
| Tech Lead | 诊断和修复 |
| Communications Owner | 同步相关方 |
| Scribe | 时间线和 action items |
小团队可以一人多职，但角色分配必须明确。
三角色事故分工
| 角色 | 事故中负责 | 复盘中负责 |
|---|---|---|
| 产品负责人 | 用户影响判断、客户 / 运营 / 销售沟通口径 | 用户补偿、产品 action、反馈回流 |
| 技术负责人 | 技术判断、止血方案、修复优先级 | 根因、技术债、质量门禁调整 |
| 平台 / 资深工程师 | 监控、日志、发布、回滚、runbook | 告警、排障脚本、自动化和文档修复 |
流程
发现
-> 判断严重度
-> 开事故群
-> 分配角色
-> 缓解用户影响
-> 验证恢复
-> 写 postmortem
-> 跟踪 action items
事故复盘
使用 templates/事故复盘-postmortem.md。
规则：
- 无责复盘。
- 具体时间线。
- 根因和促成因素。
- 哪些做得好。
- 哪些失败了。
- Action items 必须有 owner 和截止时间。
后续 Agent 就绪要求
这一节在人类事故响应流程稳定后再看。
Agent 可以总结时间线和提出 action items。严重度、对外沟通和最终根因仍由人类负责。
下一步阅读
读完或填完这份文档后，通常继续看：
- 事故复盘-postmortem.md：事故处理后，用复盘模板沉淀行动项。