复盘的目的是改系统，不是找责任人

# 故障复盘：[简短描述]

**事件编号**：INC-2026-0812-01
**严重等级**：P1
**影响时长**：2026-08-12 14:23 - 15:07（44 分钟）
**影响范围**：订单提交接口成功率降至 32%，约 8600 名用户受影响
**复盘会时间**：2026-08-14 10:00
**参与人**：[列出所有参与者]

---

## 一、影响

| 维度 | 具体影响 |
|------|----------|
| 用户 | 大量用户下单失败，部分重试后成功 |
| 业务 | 订单损失按当日均值估算，数据填在内部复盘表 |
| 数据 | 无数据丢失或错乱 |
| 对外 | 发布了服务异常公告，收到一批客诉 |

## 二、时间线

| 时间 | 事件 | 备注 |
|------|------|------|
| 14:18 | 运营发布大促活动，流量开始上涨 | 未提前告知技术团队 |
| 14:23 | 订单服务错误率告警触发（P1） | 自动电话通知值班 |
| 14:26 | 值班确认，拉响应群，指定 IC | 响应耗时 3 分钟 |
| 14:31 | 定位到数据库连接池耗尽 | Performance Insights |
| 14:38 | 尝试提高连接池上限，未生效 | 应用需重启才能生效 |
| 14:45 | 决定启用 RDS Proxy 做连接复用 | 无需重启应用 |
| 14:58 | Proxy 生效，错误率开始下降 | |
| 15:07 | 错误率恢复正常，业务方确认 | 恢复耗时 44 分钟 |
| 15:40 | 观察期结束，关闭事件 | |

## 三、根因分析

### 直接原因
订单服务的数据库连接池上限设为 50，大促流量下并发请求超过 50，
新请求无法获取连接，超时后返回 500。

### 深层原因（逐层追问）

1. **为什么连接池配成 50？**
   这是三年前上线时的默认值，之后业务量增长了 8 倍，配置从未复审。

2. **为什么没有提前发现？**
   连接池使用率没有纳入监控。我们只监控了数据库侧的连接数，
   没监控应用侧连接池的饱和度。

3. **为什么大促流量没有提前告知？**
   运营发活动不需要经过技术评审，流程上没有这个环节。

4. **为什么修复花了 34 分钟？**
   第一次尝试的方案（改连接池上限）需要重启应用，
   在故障期间重启风险大，犹豫了一段时间才换方案。

## 四、做得好的地方

- 告警准确及时，3 分钟内有人响应
- 止损优先的原则执行到位，没有陷入排查根因的坑
- RDS Proxy 方案选得对，避免了重启带来的二次影响

## 五、改进项

| # | 改进项 | 类型 | 负责人 | 期限 | 状态 |
|---|--------|------|--------|------|------|
| 1 | 所有服务的连接池使用率纳入监控，80% 告警 | 检测 | [姓名] | 08-20 | 进行中 |
| 2 | 全量复审连接池配置，按当前流量重新设定 | 预防 | [姓名] | 08-25 | 待开始 |
| 3 | 核心服务全部接入 RDS Proxy | 预防 | [姓名] | 09-15 | 待开始 |
| 4 | 建立运营活动技术预告流程 | 流程 | [姓名] | 08-30 | 待开始 |
| 5 | 编写连接池耗尽的处置 Runbook | 响应 | [姓名] | 08-22 | 已完成 |
| 6 | 大促前的容量压测纳入 checklist | 预防 | [姓名] | 09-01 | 待开始 |

## 六、经验沉淀

配置项的「默认值」会随着业务增长变成隐患。
建议对所有影响容量的配置项建立年度复审机制，
而不是等出事才发现三年没改过。