johsnon
218 lines
6.2 KiB
Markdown
218 lines
6.2 KiB
Markdown
# 操作手册：事故响应
|
||
|
||
> **模式**：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 | 财务追踪员 + 工作室制片人 | 业务影响评估 |
|