严重度分级

按严重度的响应团队

P0 — 紧急响应团队

P1 — 高优响应团队

P2 — 中等响应

P3 — 低优响应

事故响应流程

第一步：发现与分诊（0-5 分钟）

触发条件：监控告警 / 用户报告 / 智能体检测到

基础设施运维师：
1. 确认告警
2. 评估范围和影响
   - 多少用户受影响？
   - 哪些服务受影响？
   - 数据有没有风险？
3. 确定严重度（P0/P1/P2/P3）
4. 激活对应的响应团队
5. 创建事故频道/线程

产出：事故分级 + 响应团队已激活

第二步：排查（5-30 分钟）

并行排查：

基础设施运维师：
├── 检查系统指标（CPU、内存、网络、磁盘）
├── 查看错误日志
├── 检查最近的部署
└── 验证外部依赖

后端架构师（P0/P1 时）：
├── 检查数据库健康
├── 查看 API 错误率
├── 检查服务间通信
└── 定位故障组件

DevOps 自动化师：
├── 查看最近的部署历史
├── 检查 CI/CD 流水线状态
├── 需要的话准备回滚
└── 验证基础设施状态

产出：根因已确定（或缩小到某个组件）

第三步：止血（15-60 分钟）

决策树：

如果是最近的部署引起的：
  → DevOps 自动化师：执行回滚
  → 基础设施运维师：验证恢复
  → 证据收集者：确认修复

如果是基础设施问题：
  → 基础设施运维师：扩容/重启/故障切换
  → DevOps 自动化师：配合基础设施变更
  → 验证恢复

如果是代码 bug：
  → 相关开发智能体：实现热修复
  → 证据收集者：验证修复
  → DevOps 自动化师：部署热修复
  → 基础设施运维师：监控恢复情况

如果是外部依赖问题：
  → 基础设施运维师：启用降级/缓存
  → 客服响应者：通知用户
  → 等待外部恢复

全程：
  → 客服响应者：每 15 分钟更新状态页
  → 高管摘要生成器：向利益相关方通报（仅 P0）

第四步：修复验证（修复后）

证据收集者：
1. 验证修复解决了问题
2. 截图证据证明系统正常
3. 确认没有引入新问题

基础设施运维师：
1. 验证所有指标恢复正常
2. 确认没有级联故障
3. 修复后监控 30 分钟

API 测试员（如果是 API 相关的）：
1. 对受影响的端点跑回归测试
2. 验证响应时间恢复正常
3. 确认错误率回到基线

产出：事故解决确认

第五步：事后复盘（48 小时内）

工作流优化师主持事后复盘：

1. 时间线重建
   - 问题什么时候引入的？
   - 什么时候被发现的？
   - 什么时候解决的？
   - 用户受影响的总时长

2. 根因分析
   - 什么坏了？
   - 为什么坏了？
   - 为什么没有更早被发现？
   - 5 个 Why 分析

3. 影响评估
   - 受影响的用户数
   - 营收影响
   - 声誉影响
   - 数据影响

4. 预防措施
   - 什么样的监控能更早发现？
   - 什么样的测试能提前拦住？
   - 流程上需要什么改变？
   - 基础设施上需要什么改变？

5. 行动项
   - [行动] → [负责人] → [截止日期]
   - [行动] → [负责人] → [截止日期]
   - [行动] → [负责人] → [截止日期]

产出：事后复盘报告 → Sprint 排序师把预防任务加到待办列表

通知模板

状态页更新（客服响应者）

[时间戳] — [服务名称] 事故

状态：[排查中 / 已定位 / 监控中 / 已解决]
影响：[对用户的影响描述]
当前行动：[我们在做什么]
下次更新：[预计下次更新时间]

高管更新（高管摘要生成器 — 仅 P0）

事故简报 — [时间戳]

现状：[服务] [挂了/降级]，影响 [N 个用户/百分比流量]
原因：[已知/排查中] — [如果已知的简要描述]
行动：[正在做什么] — 预计恢复时间 [时间估计]
影响：[业务影响——营收、用户、声誉]
下次更新：[时间戳]

升级矩阵