# 操作手册：事故响应

> **模式**：NEXUS-Micro | **时长**：分钟到小时 | **智能体**：3-8

---

## 场景

生产环境出问题了。用户受影响了。速度很重要，但不能乱来。这个手册覆盖从发现到事后复盘的全流程。

## 严重度分级

| 级别 | 定义 | 举例 | 响应时间 |
|------|------|------|---------|
| **P0 — 紧急** | 服务完全挂了、数据丢失、安全事件 | 数据库损坏、DDoS 攻击、认证系统挂了 | 立即（全员响应） |
| **P1 — 高** | 主要功能挂了、性能严重下降 | 支付处理挂了、50%+ 错误率、10 倍延迟 | < 1 小时 |
| **P2 — 中** | 次要功能挂了、有临时方案 | 搜索不能用、非关键 API 报错 | < 4 小时 |
| **P3 — 低** | 样式问题、小不便 | 样式 bug、错别字、小的 UI 问题 | 下个 Sprint |

## 按严重度的响应团队

### P0 — 紧急响应团队
| 智能体 | 角色 | 行动 |
|--------|------|------|
| **基础设施运维师** | 事故指挥官 | 评估范围、协调响应 |
| **DevOps 自动化师** | 部署/回滚 | 需要的话执行回滚 |
| **后端架构师** | 根因排查 | 诊断系统问题 |
| **前端开发者** | 前端排查 | 诊断客户端问题 |
| **客服响应者** | 用户通知 | 更新状态页、通知用户 |
| **高管摘要生成器** | 利益相关方通知 | 实时高管更新 |

### P1 — 高优响应团队
| 智能体 | 角色 |
|--------|------|
| **基础设施运维师** | 事故指挥官 |
| **DevOps 自动化师** | 部署支持 |
| **相关开发智能体** | 修复实现 |
| **客服响应者** | 用户通知 |

### P2 — 中等响应
| 智能体 | 角色 |
|--------|------|
| **相关开发智能体** | 修复实现 |
| **证据收集者** | 验证修复 |

### P3 — 低优响应
| 智能体 | 角色 |
|--------|------|
| **Sprint 排序师** | 加到待办列表 |

## 事故响应流程

### 第一步：发现与分诊（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 个用户/百分比流量]
原因：[已知/排查中] — [如果已知的简要描述]
行动：[正在做什么] — 预计恢复时间 [时间估计]
影响：[业务影响——营收、用户、声誉]
下次更新：[时间戳]
```

## 升级矩阵

| 条件 | 升级给谁 | 行动 |
|------|---------|------|
| P0 超过 30 分钟未解决 | 工作室制片人 | 增派资源、找供应商升级 |
| P1 超过 2 小时未解决 | 项目牧羊人 | 资源重新分配 |
| 怀疑数据泄露 | 法务合规员 | 评估监管通知义务 |
| 用户数据受影响 | 法务合规员 + 高管摘要生成器 | GDPR/CCPA 通知 |
| 营收影响 > $X | 财务追踪员 + 工作室制片人 | 业务影响评估 |