Post-Mortem: 支付服务 OOM

📊影响范围 Impact

受影响服务

payment-service（支付网关）

故障类型

Out-of-Memory Kill → 服务不可用

用户影响

约 5% 用户支付请求失败 / 超时

业务影响

预估收入损失 ≈ ¥300,000

持续时长

23 分钟（14:20 – 14:43）

连带影响

下游订单服务出现排队积压

⏱时间线 Timeline

🔍根因分析 — 5 Whys

为什么支付服务不可用？

因为服务进程被操作系统 OOM Killer 终止——内存使用量超过了容器配置的上限（JVM heap + off-heap 超过 Pod memory limit）。
为什么会内存耗尽（OOM）？

因为瞬时请求流量约为日常峰值的 2.1 倍，内存需求急剧上升，但服务实例的资源配置（内存上限）未做相应调整。
为什么流量翻倍时服务没有自动扩容？

因为该支付服务未配置 Horizontal Pod Autoscaler（HPA）或 Vertical Pod Autoscaler（VPA）策略；集群层面的弹性伸缩只覆盖了部分服务，支付服务不在自动扩容白名单内。
为什么支付服务没有被纳入自动扩容策略？

因为在此前的容量规划评审中，团队评估认为当前 4 个副本足以覆盖未来 6 个月的增长，并且支付链路对一致性的敏感度较高，团队担心自动扩缩容引入的 Pod 调度延迟可能影响事务一致性——因此决定暂缓接入 HPA。
为什么容量评估结果与实际流量出现如此大的偏差？

根因在于：① 缺少定期的容量评审日历——上一次评审已是 11 个月前；② 内存使用率告警阈值（95%）过于宽松，未能在 OOM 之前发出预警；③ 上游营销活动产生的流量尖峰未提前同步至基础设施团队，缺乏跨团队的容量变更通知机制。

📐检测与响应指标

MTTD

~0 min

检测时间
崩溃即告警

MTTA

5 min

响应时间
14:20 → 14:25

MTTR

23 min

恢复时间
14:20 → 14:43

MTBF

待统计

同类故障间隔
需 ≥ 30d 数据

MTTD 为 0 是因为 OOM Kill 事件直接触发了进程退出告警，检测链路完整。MTTA 5 分钟在 on-call SLA（≤10 min）范围内。MTTR 23 分钟中，缓解动作（重启）占 15 分钟，主要耗时在诊断阶段——缺少标准化的 OOM 排查 runbook。

✅行动项 Action Items

优先级	行动	Owner	截止	状态
P0	接入 HPA — 为 payment-service 配置 Horizontal Pod Autoscaler，基于 CPU + Memory 双指标，min=4 / max=12 副本	SRE 团队	2026-05-18	进行中
P0	调整内存告警阈值 — 将 payment-service 内存使用率告警从 95% 下调至 80%（Warning）和 90%（Critical），并增加 OOM Kill 预测告警	SRE 团队	2026-05-16	进行中
P1	编写 OOM 排查 Runbook — 标准化 OOM 故障响应流程（内存 dump 采集 / GC 日志分析 / 快速回滚 / 重启决策树）	支付团队	2026-05-25	待开始
P1	建立容量规划定期评审 — 每季度一次容量评审会议，覆盖 QPS 增长、内存趋势、连接池水位	基础架构	2026-06-01	待开始
P2	跨团队流量变更通知机制 — 营销 / 运营团队发起的流量活动需提前 48h 通知基础设施团队做容量预检	PMO	2026-06-15	待开始
P2	混沌工程演练 — 将 OOM Kill 场景加入季度故障演练计划，验证自动扩容 + on-call 响应链路	SRE 团队	2026-07-01	待开始

📝经验教训 Lessons Learned

✅ What Went Well

进程退出告警即时触发，MTTD ≈ 0
On-call 工程师 5 分钟内响应，在 SLA 内
重启操作有效缓解故障，无二次伤害
故障未扩散至其他服务（熔断生效）

❌ What Went Poorly

缺少 OOM 标准化排查 runbook，诊断耗时过长
内存告警阈值过于宽松，未能在 OOM 前预警
容量规划评审滞后（上次 > 11 个月前）
营销流量尖峰未提前同步至 SRE 团队

💡下次怎么更好

1 把「容量假设」变成「持续验证」。 不再依赖年度评审得出的静态容量结论。将 HPA 作为所有关键路径服务的默认配置，用实际流量数据持续驱动扩缩容决策，让系统自己回答「够不够」。
2 告警要前移，不要等崩溃。 内存 95% 才告警等于没告警——那时离 OOM 只有一步之遥。将内存告警分层（80% Warning / 90% Critical），并接入趋势预测（线性回归 + 季节性），在 OOM 前至少 5 分钟发出预警。
3 故障响应不能靠「人记住怎么修」。 每个已知故障模式都应有标准化 runbook：症状 → 诊断步骤 → 缓解操作 → 验证。OOM 这种高频故障模式必须有文档化的决策树，降低 MTTR 的关键不是人更快，而是决策路径更短。

支付服务 OOM 故障复盘