9.5 实战故障复盘

会排障，只能说明你能把问题处理掉；会复盘，才说明你能让同类问题越来越少。一次成熟的故障复盘，不只是把“谁改坏了”找出来，而是把“症状为什么会一路放大到用户可见”讲清楚，再把结论转化为可执行的工程改进项。Google SRE 的 Postmortem 实践长期强调两件事：坚持无责复盘，以及使用标准化模板沉淀根因、触发因素和改进动作，这样才能做趋势分析并持续提升系统韧性::cite[274]。

9.5.1 从一次服务不可用事件开始复盘

这一章我们用一个典型案例来演示完整复盘过程。

案例背景

某电商系统中的 payment 服务在一次日常发布后出现不可用：

• 时间：14:03 开始异常
• 影响：订单支付接口大量超时
• 用户表现：前端下单后卡住，部分请求返回 502
• 持续时间：约 18 分钟
• 处置结果：14:21 恢复

现场症状

值班同学最先看到的是告警和业务反馈：

• Ingress 5xx 激增
• payment Service 请求耗时飙升
• Deployment 副本数正常，但 Pod 不稳定

第一反应如果只是“支付服务挂了”，这个信息还不够。复盘时应该把现场证据还原成时间线。

还原第一轮排查动作

kubectl get pods -n prod -l app=payment -o wide
kubectl describe pod payment-7f6d5c8b4d-abcde -n prod
kubectl logs payment-7f6d5c8b4d-abcde -n prod --previous
kubectl get svc payment -n prod
kubectl get endpointslices -n prod -l kubernetes.io/service-name=payment
kubectl get events -n prod --sort-by='.metadata.creationTimestamp'

从这些命令里，团队拿到了几条关键信息：

1. Pod 在不断重启
2. readiness probe 多次失败
3. Service 存在，但可用后端数量持续波动
4. 日志里出现数据库连接超时

这一步非常重要，因为它决定了复盘不是“凭印象回忆”，而是基于真实证据。

9.5.2 从症状到根因的推理路径

优秀的复盘，不会直接跳到“根因是数据库连接池配置不合理”，而是会完整呈现推理链路。

先看症状，不提前下结论

复盘中的症状链大致如下：

用户下单失败
  -> Ingress 返回 502 / 上游超时
  -> payment Service 后端实例减少
  -> payment Pod readiness probe 持续失败
  -> 应用启动后访问数据库超时
  -> 新版本连接参数配置错误

为什么是 readiness 失败，而不是单纯应用变慢？

因为排查过程中看到：

• Pod 并没有全部退出
• 但 probe 不通过，导致 Pod 被移出 Service 后端
• EndpointSlice 中可用端点数下降
• 入口层因此拿不到足够健康后端

也就是说，用户看到的是入口 502，本质上是后端可用实例被 readiness 机制摘除。这和“Pod 全部 CrashLoop”是两种不同路径。

为什么会误判成网络问题？

因为最初的现象是：

• 下游调用超时
• Service 可访问性不稳定
• 某些请求偶发成功

这类表现很容易让人先怀疑网络。但真正的证据来自：

kubectl describe pod payment-7f6d5c8b4d-abcde -n prod
kubectl logs payment-7f6d5c8b4d-abcde -n prod --previous
kubectl exec -it debug-client -n prod -- wget -S -O- http://payment:8080/healthz

当日志明确显示数据库连接初始化失败，而健康检查接口返回失败时，排查方向就应该从“网络路径”收敛到“应用依赖启动条件”。

一个好的复盘，要把“触发因素”和“根因”分开

在这个案例里，可以这样区分：

这样写的好处是：团队不会只盯着“改错参数的人”，而是能看见系统为什么没有把错误拦在更早阶段。

9.5.3 复盘结论如何转化为工程改进项

很多复盘之所以价值有限，是因为最后只停留在一句话：

• “以后注意配置检查”
• “加强测试”
• “优化监控”

这些话听起来正确，但没有执行力。Google SRE 的实践强调，标准化 Postmortem 不只是记录根因，也要沉淀可追踪的行动项，并通过后续趋势分析识别系统性的薄弱点::cite[275]。

一个好的改进项应该满足什么条件

至少要满足这 4 点：

1. 可执行：明确做什么
2. 可验收：完成标准是什么
3. 有负责人：不是“团队一起做”
4. 有优先级和截止时间：避免长期悬空

结合案例给出改进项

改进项不要只写“技术动作”

很多故障真正暴露的问题，不只有代码或配置，还包括流程：

• 发布检查项缺失
• 回滚决策太慢
• 责任边界不清
• 值班手册不完整
• 监控指标覆盖不全

因此复盘的改进项，最好按 3 类拆开：

• 技术类：代码、配置、架构、容量
• 流程类：发布、回滚、审批、变更检查
• 知识类：SOP、培训、案例沉淀、值班手册

9.5.4 建立团队级故障复盘模板与知识库

一份好的复盘模板，会大幅降低团队沉淀经验的门槛。Google SRE 也明确提到，统一的 postmortem 模板有助于一致地记录根因和触发因素，并据此进行趋势分析::cite[275]。

推荐的复盘模板

下面这份模板可以直接用于团队内部：

# 故障复盘：<事件标题>

## 1. 基本信息
- 事件编号：
- 发生时间：
- 恢复时间：
- 持续时长：
- 影响范围：
- 发现方式：告警 / 用户反馈 / 巡检
- 事件等级：

## 2. 用户影响
- 哪些用户受影响：
- 影响表现：超时 / 错误码 / 功能不可用
- 影响比例：

## 3. 时间线
- 14:03 发布开始
- 14:05 首次告警触发
- 14:07 值班确认故障
- 14:12 发现关键线索
- 14:18 完成回滚
- 14:21 业务恢复

## 4. 检测与处置
- 使用了哪些告警、日志、监控、kubectl 命令：
- 临时止血动作：
- 回滚 / 降级 / 隔离动作：

## 5. 根因分析
- 直接原因：
- 触发因素：
- 放大因素：
- 为什么没有被更早发现：

## 6. 结论
- 根因：
- 证据：
- 影响总结：

## 7. 改进项
| 序号 | 改进项 | 类型 | 负责人 | 优先级 | 截止时间 | 状态 |
| --- | --- | --- | --- | --- | --- | --- |

## 8. 附录
- 相关日志
- 关键截图
- 事件链接
- 变更记录

复盘文化的关键点：无责，但不无结论

“无责复盘”常被误解成“不要追责，所以大家随便说”。其实它真正的意思是：

• 不把复盘变成情绪化指责
• 不让个人成为系统缺陷的唯一承担者
• 关注机制、流程和防线是否缺失

但这并不意味着复盘可以含糊。相反，高质量复盘应该更清楚地回答：

• 为什么错误能进入生产
• 为什么监控没有更早发现
• 为什么影响范围会扩大
• 为什么恢复用了这么久

如何建立团队知识库

建议把复盘内容按固定标签沉淀到知识库：

• 故障类型：Pod / 网络 / 节点 / 存储 / 权限
• 根因类型：配置错误 / 资源不足 / 发布变更 / 外部依赖 / 代码缺陷
• 处置动作：回滚 / 扩容 / 驱逐 / 切流 / 降级
• 影响等级：P1 / P2 / P3

这样做的价值在于：

1. 新人能快速学习典型案例
2. 值班时可以用“相似问题”反查处理方式
3. 团队能按季度统计系统性薄弱点

复盘完成后的闭环动作

真正让复盘产生价值的，不是文档写完，而是后续闭环：

• 改进项进入任务系统
• 高优问题进入迭代计划
• 更新值班手册和 SOP
• 对重复性故障做趋势分析
• 在团队内进行短分享

Google SRE 的示例复盘也强调，好的 postmortem 应该包含清晰时间线、影响范围、根因与行动项，而不是一段模糊的“事故说明”::cite[273]。

一份适合值班同学的复盘检查清单

每次故障结束后，建议至少检查以下问题：

• 我们有没有把用户影响写清楚？
• 时间线是否能还原关键决策点？
• 根因、触发因素、放大因素是否区分清楚？
• 改进项是否具体到负责人和截止时间？
• 是否更新了 SOP、监控或发布检查项？
• 这次事件有没有资格进入“典型案例库”？

本章小结

实战复盘的重点，不是把事件写成流水账，而是完成下面这件事：

• 从现场症状还原真实时间线
• 从证据出发推导根因
• 区分触发因素、放大因素和用户影响
• 把结论转化为可执行、可追踪的工程改进项
• 用统一模板和知识库，让团队持续复用经验

当团队开始认真做复盘，故障就不再只是一次被动应对，而会逐渐变成系统能力建设的输入。

📝 版权声明：本文为原创技术博客，转载请注明出处。

如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！