Postmortem 文化：从故障中学习的工程实践

故障发生 → 紧急修复 → 松一口气 → 不了了之 → 类似故障再次发生

复盘主持人："谁负责这次发布的？为什么没有做灰度？"
发布工程师：（紧张防御）"时间紧，产品催得急，测试也通过了……"
→ 焦点转向辩护和推卸，技术根因被掩盖

复盘主持人："当时发布流程中，是什么因素让直接全量发布看起来是合理的？"
发布工程师：（坦诚）"灰度发布需要手动配置权重，比较麻烦，
              而且之前几次直接发布都没问题，所以判断风险不大。"
→ 焦点转向流程缺陷（灰度操作成本高），根因浮现

故障恢复 → 24-48 小时内：完成 Postmortem 初稿
         → 3-5 个工作日内：召开复盘会议
         → 会议后 48 小时内：定稿并归档

配置错误 → 连接池耗尽 → 服务超时 → 上游级联失败 → 用户报错

Q1: 为什么主从切换失败？
A1: 因为从库的复制延迟超过 30 秒，切换时数据不一致。

Q2: 为什么从库复制延迟超过 30 秒？
A2: 因为主库在大批量写入，从库的 binlog 应用速度跟不上。

Q3: 为什么主库有大批量写入？
A3: 因为凌晨有一个数据迁移任务在执行大批量 INSERT。

Q4: 为什么数据迁移任务在凌晨执行却没有限制写入速率？
A4: 因为迁移脚本没有做限流，且任务调度没有考虑数据库复制延迟。

Q5: 为什么迁移脚本没有限流、调度系统不考虑复制状态？
A5: 因为数据迁移工具缺乏"写入速率限制"功能，且调度系统与数据库监控是两个独立系统，
    没有集成的健康检查机制。

                        ┌─ 人员：值班人员不熟悉该服务
                        │
                        ├─ 流程：变更审批未覆盖配置项
                        │
  故障：服务不可用 ──────┼─ 技术：配置中心无灰度发布机制
                        │
                        ├─ 环境：测试环境与生产环境配置不一致
                        │
                        └─ 工具：配置校验工具未覆盖此字段

# Postmortem: [故障标题]

## 基本信息

| 字段 | 内容 |
|------|------|
| 故障时间 | 2026-07-10 14:30 ~ 15:15（45分钟） |
| 故障级别 | SEV1 |
| 影响范围 | 支付服务不可用，约 12% 用户受影响 |
| 故障负责人 | 张三（On-Call Engineer） |
| 复盘日期 | 2026-07-12 |
| 状态 | 已定稿 |

## 故障摘要

什么时间、什么服务、出了什么问题、影响了多少用户、持续多久。

## 影响评估

- **用户影响**：约 12% 的支付请求失败，预计影响交易额 XX 万元
- **业务影响**：支付服务 SLI 从 99.97% 降至 99.82%，7月 SLO 预算消耗 35%
- **数据影响**：无数据丢失/不一致

## 时间线

| 时间 | 事件 | 负责人 |
|------|------|--------|
| 14:30 | 告警触发：支付服务错误率 >5% | 自动告警 |
| 14:32 | On-Call 工程师响应，开始排查 | 张三 |
| 14:35 | 确认为数据库连接池耗尽 | 张三 |
| 14:40 | 尝试重启连接池，未恢复 | 张三 |
| 14:45 | 升级到 DBA 团队，发现主库连接数达上限 | 张三 → 李四 |
| 14:52 | 定位到异常 SQL 来自报表服务 | 李四 |
| 14:58 | 限流报表服务，连接数下降 | 李四 |
| 15:05 | 支付服务恢复正常 | 张三 |
| 15:15 | 确认全量恢复，关闭事件 | 张三 |

## 根因分析

### 直接原因
支付服务的数据库连接池被报表服务的异常 SQL 耗尽，导致支付请求无法获取数据库连接。

### 5 Whys 分析
（此处展开 5 Whys 分析链条）

### 根因
报表服务与支付服务共享数据库，且报表服务缺乏查询超时和并发控制。

## 什么做得好

- 告警在 2 分钟内触发，响应及时
- DBA 团队在升级后 3 分钟内定位问题
- 限流措施快速生效，避免了更长时间的影响

## 什么做得不好

- 报表服务与支付服务共享数据库（架构缺陷）
- 报表服务无查询超时限制（代码缺陷）
- 告警仅提示错误率，未关联数据库连接数（监控缺陷）
- 排查初期未查看变更记录，浪费了 5 分钟（流程缺陷）

## 改进项

| # | 改进项 | 类型 | 负责人 | 截止日期 | 优先级 |
|---|--------|------|--------|---------|--------|
| 1 | 报表服务与支付服务数据库隔离 | 架构 | 王五 | 2026-08-10 | P0 |
| 2 | 报表服务增加查询超时（30s）和并发限制 | 代码 | 赵六 | 2026-07-20 | P0 |
| 3 | 告警增加数据库连接数关联指标 | 监控 | 张三 | 2026-07-17 | P1 |
| 4 | 故障排查 Runbook 增加"检查变更记录"步骤 | 流程 | 张三 | 2026-07-17 | P2 |

## 经验教训

1. 共享数据库是可靠性隐患——核心服务应有独立的数据库实例
2. 所有查询都应有超时限制——数据库查询超时是基本防御措施
3. 告警应有关联上下文——单维度告警不利于快速定位
4. 排查应从"最近变更"开始——90% 的故障与变更有关

复盘会议 → 改进项录入跟踪系统 → 定期 Review（每周/每两周）
         → 到期验收 → 关闭/延期

# 改进项状态统计示例
postmortem_action_items:
  total: 47
  completed: 32          # 68% 完成率
  in_progress: 10
  overdue: 5             # 5 个逾期

  by_priority:
    P0: { total: 8, completed: 8, overdue: 0 }    # P0 必须 100% 按时完成
    P1: { total: 20, completed: 16, overdue: 2 }
    P2: { total: 19, completed: 8, overdue: 3 }

  avg_close_time_days: 18   # 平均关闭周期 18 天
  target_close_time_days: 30

1. 主持人宣读 blameless 原则（2分钟）
   → 设定基调，明确这是学习而非追责

2. 故障指挥概述事件经过（5-10分钟）
   → 时间线回顾，确保所有人理解事件全貌

3. 逐段时间线讨论（15-20分钟）
   → 对每个关键时间点追问"为什么"
   → 记录所有"做得好"和"做得不好"

4. 根因分析讨论（15-20分钟）
   → 用 5 Whys 或鱼骨图推导根因
   → 确认根因的共识

5. 改进项讨论（15-20分钟）
   → 头脑风暴改进措施
   → 现场分配负责人和截止日期

6. 总结（5分钟）
   → 主持人回顾根因和改进项
   → 确认记录员 48 小时内完成定稿

postmortem/
├── 2026/
│   ├── 01/
│   │   ├── 2026-01-15-payment-db-connection-exhausted.md
│   │   └── 2026-01-22-cache-cluster-failover.md
│   ├── 02/
│   │   └── 2026-02-05-cdn-config-error.md
│   └── 07/
│       └── 2026-07-10-report-sql-overflow.md
├── templates/
│   └── postmortem-template.md
└── index.md    # 索引文件，按服务/根因分类

# Postmortem 索引

## 按服务分类

### 支付服务
- [2026-01-15 数据库连接池耗尽](2026/01/2026-01-15-payment-db-connection-exhausted.md)
- [2026-07-10 报表SQL导致连接耗尽](2026/07/2026-07-10-report-sql-overflow.md)

### 缓存集群
- [2026-01-22 主从切换失败](2026/01/2026-01-22-cache-cluster-failover.md)

## 按根因分类

### 数据库相关问题
- 连接池耗尽 × 2
- 主从切换失败 × 1

### 配置变更问题
- CDN 配置错误 × 1

# 2026 Q2 Postmortem 聚合分析

## 概览
- 总故障数：23（SEV1: 3, SEV2: 8, SEV3: 12）
- Postmortem 完成：11/11（SEV1+SEV2 全覆盖）
- 改进项完成率：72%（目标 80%）

## 根因分布
| 根因类别 | 次数 | 趋势 |
|---------|------|------|
| 配置变更 | 7 | ↑ |
| 容量不足 | 4 | → |
| 依赖故障 | 3 | ↓ |
| 代码缺陷 | 3 | → |
| 网络问题 | 2 | ↓ |

## 关键发现
- "配置变更"连续两个季度上升，需要加强配置变更管控
- 上季度部署的"连接池告警"改进项有效，数据库类故障下降 50%

复盘前 6 个月：平均每月 SEV1+SEV2 故障 4.2 次，MTTR 45 分钟
复盘后 6 个月：平均每月 SEV1+SEV2 故障 2.1 次，MTTR 28 分钟
→ 同类故障下降 50%，MTTR 缩短 38%

故障恢复 → 自动创建 Postmortem 工单 → 设定定稿截止日期
         → 自动从告警系统提取时间线
         → 自动关联相关变更记录
         → 复盘完成后自动通知相关团队

# 从告警系统自动提取事件时间线
def generate_timeline(alert_ids, start_time, end_time):
    timeline = []
    for alert_id in alert_ids:
        alerts = query_alertmanager(alert_id, start_time, end_time)
        for alert in alerts:
            timeline.append({
                "time": alert["starts_at"],
                "event": alert["annotations"]["summary"],
                "severity": alert["labels"]["severity"]
            })

    # 关联变更记录
    changes = query_changes(start_time, end_time)
    for change in changes:
        timeline.append({
            "time": change["timestamp"],
            "event": f"变更: {change['description']}",
            "severity": "INFO"
        })

    return sorted(timeline, key=lambda x: x["time"])

# 根因推荐规则示例
recommendations:
  - pattern:
      symptoms: ["数据库连接超时", "连接数告警"]
      services: ["payment-service"]
    likely_causes:
      - "连接池配置不足"
      - "慢查询耗尽连接"
      - "连接泄漏"
    related_postmortems:
      - "2026-01-15-payment-db-connection-exhausted.md"
      - "2026-07-10-report-sql-overflow.md"

# 改进项到期检查
def check_overdue_action_items():
    items = query_action_items(status="open")
    for item in items:
        if item["due_date"] < datetime.now():
            # 逾期通知
            notify(item["owner"], f"改进项逾期: {item['title']}")
            # 升级到负责人
            if item["days_overdue"] > 14:
                notify(item["manager"], f"改进项逾期超过14天: {item['title']}")