@umacloud/knowledge 1.0.1

package/incident/02-playbooks/postmortem-playbook.md

@@ -0,0 +1,398 @@
+---
+id: postmortem-playbook
+title: 事故复盘 Playbook (Postmortem Playbook)
+domain: incident
+category: 02-playbooks
+difficulty: intermediate
+tags: [incident, playbook, postmortem, smart, 事故恢复确认, 制定行动项, 基本信息, 时间线构建]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 事故复盘 Playbook (Postmortem Playbook)
+
+> 适用场景：生产事故复盘、重大故障分析、持续改进闭环建设。
+> 约束级别：所有 P0/P1 事故必须在恢复后 72 小时内完成复盘；P2 事故 5 个工作日内完成。
+> 核心原则：无责文化（Blameless）— 聚焦系统改进而非追究个人责任。
+
+---
+
+## 阶段 0: 事故恢复确认
+
+在启动复盘之前，确认以下前置条件：
+
+- [ ] 事故已完全恢复，用户影响已消除
+- [ ] 临时修复（Workaround）已到位，不会再次发生
+- [ ] 事故严重等级已由 On-Call 负责人确认（P0 / P1 / P2 / P3）
+- [ ] 事故通报已发送给相关干系人
+- [ ] 监控已恢复到正常基线，告警已解除
+
+---
+
+## 阶段 1: 会议准备（复盘前 1-2 天）
+
+### 1.1 指定复盘负责人
+
+- [ ] 指定一名非直接责任方的复盘主持人（Facilitator）
+- [ ] 主持人负责收集材料、组织会议、输出报告
+- [ ] 主持人已阅读本 Playbook 和无责文化准则
+
+### 1.2 参会人员
+
+- [ ] 事故响应的一线工程师（On-Call / First Responder）
+- [ ] 受影响系统的 Owner 和核心开发者
+- [ ] 事故期间的决策者（Incident Commander）
+- [ ] 相关的 SRE / DevOps / 安全团队成员
+- [ ] （可选）产品经理、客户支持代表
+- [ ] 参会人数控制在 5-10 人，避免过多旁观者
+
+### 1.3 材料收集
+
+- [ ] 事故时间线草稿已整理（从告警触发到完全恢复）
+- [ ] 监控截图、日志片段、告警记录已收集
+- [ ] 相关的 Chat / Slack / 飞书沟通记录已导出
+- [ ] 变更记录已拉取（部署、配置变更、数据库变更）
+- [ ] 影响范围数据已统计（受影响用户数、错误率、持续时间）
+- [ ] 相关的 On-Call 交接记录已收集
+
+### 1.4 会议邀请
+
+- [ ] 会议时间已预约（建议事故恢复后 48-72 小时，记忆新鲜且情绪平复）
+- [ ] 会议时长 60-90 分钟（P0 可延长至 120 分钟）
+- [ ] 议程已提前发送，参会者有时间回忆和准备
+- [ ] 会议房间 / 线上链接已确认
+
+---
+
+## 阶段 2: 时间线构建
+
+### 2.1 时间线模板
+
+时间线是复盘的核心事实基础，必须精确到分钟级。
+
+```markdown
+| 时间 (UTC+8) | 事件 | 操作人 | 来源 |
+|--------------|------|--------|------|
+| 14:23 | 监控告警: API 错误率 > 5% | 系统 | Grafana Alert |
+| 14:25 | On-Call 工程师 A 收到 PagerDuty 告警 | A | PagerDuty |
+| 14:28 | A 开始排查，查看 Dashboard | A | Slack 记录 |
+| 14:35 | 定位到数据库连接池耗尽 | A | 日志 |
+| 14:38 | 尝试重启服务实例 | A | K8s 操作记录 |
+| 14:40 | 重启无效，升级到 P1 事故 | A | Incident Channel |
+| 14:45 | DBA B 加入排查 | B | Slack 记录 |
+| 14:52 | 发现慢查询导致连接池占满 | B | 慢查询日志 |
+| 15:00 | 临时 Kill 慢查询，连接池恢复 | B | DB 操作记录 |
+| 15:05 | 服务恢复正常，告警解除 | 系统 | Grafana |
+| 15:10 | 客户沟通完成，事故通报发送 | PM | 邮件 |
+```
+
+### 2.2 时间线构建原则
+
+- [ ] 以客观事实为基础，不加入主观判断
+- [ ] 标注信息来源（监控 / 日志 / 聊天记录 / 个人回忆）
+- [ ] 区分"发现时间"和"实际发生时间"
+- [ ] 标注关键决策点和决策依据
+- [ ] 多人回忆有冲突时以系统日志为准
+
+### 2.3 关键时间指标
+
+- [ ] **TTD (Time to Detect)** — 故障发生到被发现的时间
+- [ ] **TTE (Time to Engage)** — 发现到开始响应的时间
+- [ ] **TTR (Time to Restore)** — 开始响应到服务恢复的时间
+- [ ] **TTN (Time to Notify)** — 发现到通知用户/干系人的时间
+- [ ] **Total Impact Duration** — 用户实际受影响的总时长
+
+---
+
+## 阶段 3: 根因分析
+
+### 3.1 5 Whys 分析法
+
+从直接原因出发，连续追问 5 次"为什么"，直到挖掘到系统性根因。
+
+```markdown
+**事故现象**: API 返回 503，持续 42 分钟。
+
+**Why 1**: 为什么 API 返回 503？
+→ 因为应用服务器连接池耗尽，无法获取数据库连接。
+
+**Why 2**: 为什么连接池耗尽？
+→ 因为有大量慢查询长时间持有连接不释放。
+
+**Why 3**: 为什么出现大量慢查询？
+→ 因为新上线的报表功能包含全表扫描的 SQL，未加索引。
+
+**Why 4**: 为什么全表扫描的 SQL 能上线？
+→ 因为 Code Review 时没有进行 SQL 性能审查，没有 Explain 分析。
+
+**Why 5**: 为什么 Code Review 流程缺少 SQL 审查？
+→ 因为没有建立数据库变更的强制审查门禁和自动化检测。
+
+**根因**: 缺少数据库查询性能的自动化门禁，依赖人工审查不可靠。
+```
+
+#### 5 Whys 原则
+
+- [ ] 每个 "Why" 的答案必须基于事实，不可臆测
+- [ ] 追问到系统/流程层面，而非停留在个人操作层面
+- [ ] 可能存在多条因果链，需逐一追溯
+- [ ] 避免在第 1-2 层就停止（过于表面）
+- [ ] 避免超过 7 层（过于发散）
+
+### 3.2 鱼骨图分析（石川图）
+
+用于系统化梳理多维度原因，适合复杂的多因素事故。
+
+```
+                         ┌─ 无慢查询告警
+              环境 ──────┤
+                         └─ 数据库连接池配置偏小
+                         ┌─ 全表扫描 SQL
+              技术 ──────┤
+                         └─ 无索引策略
+                                                          ──→ API 503
+                         ┌─ 无 SQL 性能门禁              42 分钟
+              流程 ──────┤
+                         └─ Code Review 未覆盖数据库
+                         ┌─ DBA 未参与报表功能评审
+              人员 ──────┤
+                         └─ 开发者缺少 SQL 优化培训
+```
+
+#### 鱼骨图维度
+
+| 维度 | 分析要点 |
+|------|----------|
+| 技术 (Technology) | 代码缺陷、架构缺陷、依赖问题、配置错误 |
+| 流程 (Process) | 变更管理、审查流程、发布流程、监控覆盖 |
+| 人员 (People) | 技能差距、沟通不畅、交接遗漏、培训不足 |
+| 环境 (Environment) | 基础设施、容量、网络、第三方依赖 |
+| 工具 (Tools) | 监控盲区、告警规则、自动化缺失、工具链问题 |
+
+---
+
+## 阶段 4: 制定行动项 (SMART)
+
+### 4.1 SMART 原则
+
+每个行动项必须满足 SMART 标准：
+
+| 维度 | 含义 | 示例 |
+|------|------|------|
+| **S**pecific（具体） | 明确要做什么 | "为 reports 表添加 created_at 字段索引" |
+| **M**easurable（可度量） | 完成标准可度量 | "慢查询从 15s 降到 < 200ms" |
+| **A**ssignable（可分配） | 有明确负责人 | "DBA 张三负责" |
+| **R**ealistic（可实现） | 在给定时间内可完成 | "不需要架构重构，加索引即可" |
+| **T**ime-bound（有时限） | 有明确截止日期 | "2024-03-15 前完成" |
+
+### 4.2 行动项模板
+
+```markdown
+### Action Item #1: 为 reports 表添加索引
+
+| 字段 | 值 |
+|------|-----|
+| 类型 | 修复 (Fix) |
+| 优先级 | P0 - 立即 |
+| 负责人 | 张三 (DBA) |
+| 截止日期 | 2024-03-10 |
+| 验收标准 | reports 表查询 P99 < 200ms |
+| 跟踪 Issue | JIRA-1234 |
+| 状态 | 进行中 |
+
+### Action Item #2: CI 添加 SQL 性能自动检测
+
+| 字段 | 值 |
+|------|-----|
+| 类型 | 预防 (Prevent) |
+| 优先级 | P1 - 本周 |
+| 负责人 | 李四 (SRE) |
+| 截止日期 | 2024-03-17 |
+| 验收标准 | 全表扫描 SQL 在 CI 阶段被拦截 |
+| 跟踪 Issue | JIRA-1235 |
+| 状态 | 待开始 |
+
+### Action Item #3: 数据库变更审查流程建设
+
+| 字段 | 值 |
+|------|-----|
+| 类型 | 预防 (Prevent) |
+| 优先级 | P2 - 本月 |
+| 负责人 | 王五 (Tech Lead) |
+| 截止日期 | 2024-03-31 |
+| 验收标准 | 含 SQL 变更的 PR 必须有 DBA Approve |
+| 跟踪 Issue | JIRA-1236 |
+| 状态 | 待开始 |
+```
+
+### 4.3 行动项分类
+
+| 类型 | 说明 | 时间要求 |
+|------|------|----------|
+| 修复 (Fix) | 直接修复本次事故的技术问题 | 24-48 小时 |
+| 检测 (Detect) | 增加监控和告警，更快发现类似问题 | 1 周 |
+| 预防 (Prevent) | 从流程和架构层面防止同类问题再次发生 | 2-4 周 |
+| 改进 (Improve) | 优化响应效率、降低影响范围 | 1-3 月 |
+
+---
+
+## 阶段 5: 编写复盘报告
+
+### 5.1 复盘报告模板
+
+```markdown
+# 事故复盘报告: [事故标题]
+
+## 基本信息
+
+| 字段 | 值 |
+|------|-----|
+| 事故 ID | INC-2024-0042 |
+| 严重等级 | P1 |
+| 影响时长 | 42 分钟 (14:23 - 15:05 UTC+8) |
+| 影响范围 | 全部 API 用户，约 12,000 请求失败 |
+| 复盘日期 | 2024-03-08 |
+| 复盘主持 | [姓名] |
+| 报告作者 | [姓名] |
+
+## 概述
+
+一句话描述事故：新上线的报表功能包含未优化的数据库查询，导致连接池
+耗尽，API 服务不可用 42 分钟。
+
+## 时间线
+
+[完整时间线表格]
+
+## 关键指标
+
+| 指标 | 值 | 目标 |
+|------|-----|------|
+| TTD (发现时间) | 2 分钟 | < 5 分钟 |
+| TTE (响应时间) | 5 分钟 | < 10 分钟 |
+| TTR (恢复时间) | 35 分钟 | < 30 分钟 |
+| 影响用户数 | ~3,200 | - |
+| 错误请求数 | ~12,000 | - |
+
+## 根因分析
+
+### 5 Whys
+[5 Whys 分析过程]
+
+### 贡献因素
+- 近因: 全表扫描 SQL 上线
+- 远因: 缺少 SQL 性能审查流程
+- 系统因素: 连接池无动态扩缩和慢查询自动 Kill
+
+## 行动项
+
+[行动项列表]
+
+## 经验教训
+
+### 做得好的
+- 监控告警在 2 分钟内触发，TTD 符合目标
+- 团队协作迅速，DBA 及时加入排查
+
+### 需要改进的
+- 缺少数据库变更的自动化门禁
+- 连接池配置过于保守，无弹性扩缩能力
+
+### 幸运因素
+- 事故发生在工作时间，响应迅速
+- 影响的是报表功能，非核心交易链路
+```
+
+---
+
+## 阶段 6: 行动项跟踪
+
+### 6.1 跟踪机制
+
+- [ ] 所有行动项已创建为 JIRA / GitHub Issue，关联事故 ID
+- [ ] 每周例会 Review 行动项进度
+- [ ] 逾期行动项自动升级通知
+- [ ] 完成的行动项需要验收确认
+
+### 6.2 跟踪看板
+
+```
+| 状态 | 行动项 | 负责人 | 截止日期 | 进度 |
+|------|--------|--------|----------|------|
+| Done | 添加索引 | 张三 | 03-10 | 100% |
+| In Progress | SQL 检测 | 李四 | 03-17 | 60% |
+| Todo | 审查流程 | 王五 | 03-31 | 0% |
+```
+
+### 6.3 闭环确认
+
+- [ ] 所有 P0 行动项已完成并验收
+- [ ] P1 行动项完成率 >= 90%
+- [ ] 复盘报告已归档到知识库
+- [ ] 行动项的效果已在后续事故中得到验证
+
+---
+
+## 阶段 7: 无责文化建设
+
+### 7.1 无责文化原则
+
+| 原则 | 说明 |
+|------|------|
+| 人不是根因 | 人犯错是系统允许错误发生的结果，改进系统而非惩罚个人 |
+| 信息透明 | 鼓励主动披露错误和近失事件（Near Miss），隐瞒比犯错更危险 |
+| 好奇心优先 | 用"我想了解当时发生了什么"替代"你为什么这样做" |
+| 安全心理 | 参会者可以坦诚分享而不用担心负面后果 |
+| 系统思维 | 关注流程、工具、环境等系统因素，而非个人能力或态度 |
+
+### 7.2 复盘会议用语规范
+
+| 避免使用 | 推荐使用 |
+|----------|----------|
+| "谁犯的错？" | "当时发生了什么？" |
+| "你应该知道..." | "当时有哪些信息可用？" |
+| "这太低级了" | "什么系统改进能防止这种情况？" |
+| "为什么不测试？" | "当时的测试策略覆盖了哪些场景？" |
+| "就不应该上线" | "发布流程中有哪些检查点？" |
+
+### 7.3 无责文化建设行动
+
+- [ ] 复盘报告中不出现个人名字（用角色替代：On-Call A、DBA B）
+- [ ] 鼓励自愿分享"当时我以为..."的思考过程
+- [ ] 管理层明确声明不会因事故对个人进行惩罚
+- [ ] 定期举办"事故故事会"，分享近失事件和教训
+- [ ] 将复盘质量（而非事故数量）纳入团队 KPI
+
+### 7.4 反面信号检测
+
+以下信号表明团队尚未建立真正的无责文化：
+
+- 工程师隐瞒操作失误或试图悄悄修复
+- 复盘会议气氛紧张，参会者不愿发言
+- 行动项总是"加强培训"而非改进系统
+- 事故数量下降但严重程度上升（小事故被隐瞒直到变大）
+- "没人愿意上线"或"没人愿意值班"
+
+---
+
+## 附录: 复盘报告评审标准
+
+| 评审项 | 通过标准 |
+|--------|----------|
+| 时间线完整性 | 关键事件均有时间戳和来源标注 |
+| 根因深度 | 5 Whys 至少深入到第 3 层 |
+| 行动项质量 | 每项均满足 SMART 标准 |
+| 行动项覆盖 | 包含修复、检测和预防三类 |
+| 无责文化 | 报告中无个人指责内容 |
+| 数据支撑 | 影响范围有量化数据 |
+
+---
+
+## Agent Checklist
+
+- [ ] P0/P1 事故在 72 小时内启动复盘流程
+- [ ] 时间线基于系统日志而非纯粹个人回忆
+- [ ] 5 Whys 至少深入到第 3 层，且追溯到系统/流程层面
+- [ ] 所有行动项符合 SMART 标准并创建为跟踪 Issue
+- [ ] 复盘报告已发布到团队知识库并通知相关方
+- [ ] 复盘过程遵循无责文化原则，无个人指责内容
+- [ ] 行动项完成后有闭环验收确认

package/incident/03-checklists/incident-readiness-checklist.md

@@ -0,0 +1,181 @@
+---
+id: incident-readiness-checklist
+title: 事故准备度检查清单
+domain: incident
+category: 03-checklists
+difficulty: intermediate
+tags: [agent, checklist, incident, readiness, 概述, 评分汇总]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 事故准备度检查清单
+
+## 概述
+
+本清单用于评估团队在生产事故发生前的准备程度。事故准备度决定了故障发生时的响应速度
+和恢复能力。建议每季度执行一次全面检查，每月抽查关键项。
+
+评分标准：每项 0-2 分（0=未实施, 1=部分实施, 2=完全就绪），总分 60 分满分。
+及格线：48 分（80%）。低于 36 分（60%）应立即启动改进计划。
+
+---
+
+## 一、告警体系（12 分）
+
+### 1.1 告警覆盖
+
+- [ ] 核心服务健康检查告警已配置（HTTP 探针/TCP 探针）
+- [ ] 关键业务指标告警已配置（订单量/支付成功率/登录量异常波动）
+- [ ] 基础设施告警已配置（CPU/内存/磁盘/网络）
+- [ ] 依赖服务告警已配置（数据库/缓存/消息队列/第三方 API）
+
+### 1.2 告警质量
+
+- [ ] 告警分级明确（P0-紧急/P1-高/P2-中/P3-低）
+- [ ] 告警阈值经过历史数据校准，误报率 < 5%
+- [ ] 告警收敛规则已配置（相同告警 5 分钟内不重复通知）
+- [ ] 每月回顾告警噪音，清理无效告警
+
+### 1.3 告警通道
+
+- [ ] P0/P1 告警通过电话+短信+IM 多通道触达
+- [ ] P2/P3 告警通过 IM/邮件通知
+- [ ] 告警通道冗余（主通道故障时备用通道可用）
+- [ ] 最近一次告警通道可达性测试在 30 天内
+
+---
+
+## 二、Runbook（10 分）
+
+### 2.1 覆盖度
+
+- [ ] 每个核心服务有对应的 Runbook
+- [ ] Top-10 历史高频故障场景有专项 Runbook
+- [ ] Runbook 包含：现象描述、影响范围、排查步骤、恢复操作、升级条件
+
+### 2.2 质量与时效
+
+- [ ] Runbook 最近 90 天内有更新或确认仍有效
+- [ ] Runbook 中的命令/脚本已在近期验证可执行
+- [ ] 新人可独立按 Runbook 完成 P2 级故障处理
+- [ ] Runbook 存储在团队统一平台（而非个人笔记）
+
+### 2.3 演练验证
+
+- [ ] 关键 Runbook 每季度至少演练一次
+- [ ] 演练结果记录并反馈到 Runbook 更新
+- [ ] 演练中发现的文档缺陷已在 5 个工作日内修复
+
+---
+
+## 三、On-Call 轮值（10 分）
+
+### 3.1 排班体系
+
+- [ ] On-Call 排班表已发布且覆盖未来 4 周
+- [ ] 每个时段至少有主备两人 On-Call
+- [ ] On-Call 人员具备处理该服务 P1 故障的能力
+- [ ] 换班流程明确，交接记录可追溯
+
+### 3.2 响应要求
+
+- [ ] P0 事故响应时间要求 < 5 分钟已明确告知 On-Call 人员
+- [ ] P1 事故响应时间要求 < 15 分钟已明确告知
+- [ ] On-Call 人员确认通讯设备 24h 可达
+- [ ] 升级路径明确（On-Call → TL → 架构师 → CTO）
+
+### 3.3 工具就绪
+
+- [ ] On-Call 人员拥有生产环境只读权限
+- [ ] 紧急操作权限可在 5 分钟内通过审批获取
+- [ ] VPN/堡垒机/监控面板等工具访问已预配置
+
+---
+
+## 四、通信渠道（8 分）
+
+### 4.1 事故沟通
+
+- [ ] 事故专用沟通群/频道创建流程 < 2 分钟
+- [ ] 事故沟通模板已预置（影响范围/当前状态/下一步/ETA）
+- [ ] 内部状态页或广播机制已就绪
+- [ ] 对外客户通知模板和流程已预置
+
+### 4.2 协作工具
+
+- [ ] 事故指挥官（Incident Commander）角色定义明确
+- [ ] 多团队协同作战的 War Room 流程已文档化
+- [ ] 事后复盘（Postmortem）模板和会议流程已标准化
+- [ ] 事故时间线记录工具已选定并团队熟悉
+
+---
+
+## 五、回滚能力（12 分）
+
+### 5.1 应用回滚
+
+- [ ] 应用部署支持一键回滚到上一版本
+- [ ] 回滚操作耗时 < 5 分钟
+- [ ] 最近一次回滚演练在 30 天内
+- [ ] 回滚不依赖原始构建产物仍可完成（镜像保留策略）
+
+### 5.2 数据库回滚
+
+- [ ] 数据库 Migration 支持 Down/Rollback
+- [ ] 破坏性 DDL（删表/删列）有延迟执行和确认机制
+- [ ] 数据修复脚本有模板和审核流程
+
+### 5.3 配置回滚
+
+- [ ] 配置中心支持版本对比和一键回滚
+- [ ] Feature Flag 可在 1 分钟内关闭特定功能
+- [ ] DNS/负载均衡切换操作已文档化且可快速执行
+
+### 5.4 流量控制
+
+- [ ] 熔断器已配置且阈值合理
+- [ ] 限流策略已配置（核心接口有独立限流）
+- [ ] 灰度发布支持按比例/用户分组控制
+
+---
+
+## 六、备份验证（8 分）
+
+### 6.1 备份策略
+
+- [ ] 数据库全量备份频率 ≥ 每日一次
+- [ ] 增量备份/Binlog 备份已启用
+- [ ] 备份存储与主库物理隔离（跨 AZ 或跨区域）
+- [ ] 备份保留周期符合业务要求（通常 ≥ 30 天）
+
+### 6.2 恢复验证
+
+- [ ] 最近一次备份恢复演练在 90 天内
+- [ ] 恢复耗时已测量并符合 RTO 要求
+- [ ] 恢复后数据完整性已验证（RPO 检查）
+- [ ] 备份失败有告警且最近 30 天无未处理的备份失败
+
+---
+
+## 评分汇总
+
+| 类别 | 满分 | 得分 | 状态 |
+|------|------|------|------|
+| 告警体系 | 12 | __ | |
+| Runbook | 10 | __ | |
+| On-Call 轮值 | 10 | __ | |
+| 通信渠道 | 8 | __ | |
+| 回滚能力 | 12 | __ | |
+| 备份验证 | 8 | __ | |
+| **总计** | **60** | **__** | |
+
+## Agent Checklist
+
+- [ ] 告警覆盖是否包含业务指标而非仅基础设施
+- [ ] Runbook 是否可被新人独立执行
+- [ ] On-Call 排班是否有主备冗余
+- [ ] 事故沟通模板是否预置且团队已熟悉
+- [ ] 回滚能力是否经过近期演练验证
+- [ ] 备份恢复是否在 90 天内做过实际演练
+- [ ] 评分是否达到 80% 及格线
+- [ ] 不达标项是否已生成改进计划和 Owner