数据库故障复盘落地实战：从救火记录到根因闭环与防复发清单

dbaai

数据库故障复盘落地实战：从救火记录到根因闭环与防复发清单

一、具体的问题

凌晨 02:17，业务库磁盘写满，写入全部失败，值班同学从告警到恢复花了 47 分钟。第二天早上人倒是都到齐了，复盘会开了四十分钟：运维说监控有报但群里没人看，开发说日志涨那么快为什么不告，DBA 说清理脚本写了但没上定时。最后结论是"大家以后多注意"，散会。

三个月后，同一个实例、同一个原因，又挂了一次。

这不是个例。我见过的数据库团队里，复盘普遍有三种死法：

• 复盘会开成批斗会：全程在问"谁改的配置""谁没盯告警"，人人在自保，没人关心链条哪里断了；
  
• 复盘会开成故事会：讲了一遍故障经过，很精彩，然后呢？没有文档、没有行动项、没有验证，两周后只剩记忆碎片；
  
• 复盘文档写了没人看：模板填完了归档进网盘，下次故障时没人翻它，同样的坑再踩一遍。
  

救火能力靠的是临场，防复发能力靠的是复盘后的落地。前者大家练得多，后者几乎没人真正做成体系。这篇就把"故障复盘怎么落地"拆成可执行的步骤。

二、核心原理

复盘的目的只有一个：把单次故障的经验，转化成系统性的防线。人在，是防线；人不在，防线塌了——所以复盘的产出必须是"机器和流程扛得住"的东西，而不是"大家记住教训"。

三条底层原则：

1. 对事不对人（blameless）。 事故几乎从来不是单点人祸，而是一串防御层依次失效的结果。监控没响、告警没人看、权限没收敛、脚本没上定时——每层都有机会拦住它。追责会让每个人只交代对自己有利的部分，时间线就拼不完整。复盘会上只允许问"什么让我们当时没法更早发现/更早拦住"，不允许问"是谁干的"。

2. 根因要追到防御层，不能停在直接原因。 直接原因是"磁盘满了"，用 5 Why 往下追：为什么满——日志暴涨；为什么暴涨——上游改了批量任务；为什么没发现——磁盘使用率告警阈值 95% 太晚；为什么没拦住——日志目录没配配额、没进清理任务。追到能落成一个具体动作（配额+定时清理+阈值调整）才算到底。根因分析的终点是一个可验证的行动项，不是一句总结。

3. 行动项必须有 owner、期限、验证方式。 "加强监控""完善流程"这类行动项等于没写。合格的行动项长这样："10 月 31 日前，由张三在所有生产库日志目录配置 size 配额，验证方式为抽查 5 台机器 ls /etc/projects/*/limit.conf。"没有验证方式的行动项，三个月后完成率通常不到三成。

三、实例参考（动手步骤）

步骤 0：确认现状基线

动手改流程之前，先摸清自己团队的复盘现状。三件事：

2. # 1. 过去半年有没有复盘文档？在哪？多少篇？
3. #    （能找到的数量，往往比想象中少得多）
5. # 2. 找一篇翻翻：行动项有多少条？带验证方式的占多少？
6. #    （用 grep 粗查"验证"两个字出现的次数）
8. # 3. 回忆最近一次故障：修复动作里，有多少是上次故障就做过一遍的？
9. #    （重复出现 = 复盘没闭环，这是最硬的证据）

复制代码

假设摸底结果是：文档 3 篇、行动项 11 条、带验证方式的 2 条、重复故障 1 次。这就是改进前的基线，改完要拿它对比。

步骤 1：48 小时内冻结时间线

故障修复后 48 小时内（趁记忆新鲜），把时间线拼出来。素材来源要多样化，不能只靠回忆：

2. # 监控数据：拉故障时段的关键指标曲线（磁盘、QPS、错误率、连接数）
3. # 告警记录：什么时候发的、发给谁、有没有已读
4. # 操作日志：谁在什么时间执行了什么命令（sudo log、数据库审计日志）
5. # 应用日志：异常的第一条出现时间，比告警早多久
6. # IM 群记录：值班响应的每一步时间点

复制代码

时间线格式建议（每行一条，精确到分钟）：

时间	事件	来源
01:50	批量任务上线，日志量开始暴涨	应用日志
02:03	磁盘使用率越过 85%（有数据无告警）	监控曲线
02:17	磁盘 100%，写入报错，首个用户告警电话	应用日志/客服
02:22	值班同学看到群里告警（阈值 95% 此时才触发）	告警记录
02:41	定位到日志目录，开始手工清理	sudo log
03:04	清理完成，写入恢复	监控曲线

步骤 2：根因分析追到防御层

用 5 Why 顺着时间线追，每层问"为什么这一层没拦住"：

• 为什么写入失败？——磁盘写满。
  
• 为什么写满？——批量任务日志量是日常 40 倍。
  
• 为什么暴涨没人知道？——日志量没有监控，磁盘告警阈值 95% 触发太晚且只发群里。
  
• 为什么日志没被拦住？——目录无 size 配额，清理脚本存在但没配定时任务。
  
• 为什么脚本没上定时？——上线时只有口头交接，没有"清理任务必须有定时+验证"的发布检查项。
  

追到这里，得到四个可落点的防御层：日志量监控、告警阈值与通道、目录配额、发布检查项。

步骤 3：形成行动项清单

每条行动项按「动作 + owner + 期限 + 验证方式」写死：

#	行动项	Owner	期限	验证方式
1	日志目录统一配 size 配额	张三	+7 天	抽查 5 台机器配置文件
2	磁盘告警阈值 95%→85%，且同时发电话渠道	李四	+3 天	人工触发测试告警
3	清理脚本全部挂上定时并做执行日志	王五	+14 天	crontab -l 批量核查脚本
4	批量任务上线检查单新增"预估日志量"项	赵六	+14 天	下次上线走一遍检查单

步骤 4：沉淀防复发清单

把这次的教训抽象成通用条目，进入团队的"上线前/巡检时"清单，让下一个项目天然受益。比如本次沉淀出：任何会写大盘的进程，上线前必须确认其输出目录有配额或轮转策略。这条进清单后，跟这次故障同类的十种花样都会被提前拦住。

治理前后对比

维度	治理前	治理后（30 天后）
复盘文档	半年 3 篇	每次故障 48h 内必出，2 篇
行动项带验证方式比例	2/11（18%）	8/8（100%）
行动项按时完成率	无法统计（无跟踪）	8/8（100%，周会跟踪）
故障发现耗时（同指标）	14 分钟（02:03→02:17）	目标 <2 分钟（85% 阈值+电话）
同类重复故障	3 个月内 1 次	0（配额+定时清理兜底）

四、实操检查清单

• [ ] 故障修复后 48 小时内完成复盘文档，时间线精确到分钟且每条有数据来源
  
• [ ] 时间线素材至少覆盖：监控、告警、操作日志、应用日志、IM 记录五类中的四类
  
• [ ] 根因分析至少追问到第三个"为什么"，终点是一个可落地的防御层动作
  
• [ ] 每条行动项四要素齐全：动作、owner、期限、验证方式，缺一不收
  
• [ ] 复盘会全程禁止出现具体人名的追责表述，只讨论防御层失效
  
• [ ] 行动项进入周会固定跟踪项，逾期未完成的当众升级
  
• [ ] 本次教训抽象出的通用条目已写入团队上线检查单/巡检清单
  
• [ ] 30 天后做一次"回头看"，逐条核验行动项的验证方式真的执行过
  
• [ ] 半年内同类故障重复出现时，强制升级复盘规格（跨团队、更高层参与）
  

几个容易踩的坑

• 复盘会开成追责会。哪怕Leader只是语气重一点，下次大家就会在时间线上"选择性记忆"。规矩要提前讲死：会上只谈链条，不谈个人。
  
• 行动项写成愿望。"加强""完善""重视"开头的行动项，一律打回重写，直到出现可核验的动作为止。
  
• 只复盘大故障。小故障不复盘，等于放走一半的学习机会——而且大故障的根子往往在之前被忽略的小异常里。可以按影响分级，但不能免复盘。
  
• 根因停在"人为失误"。到这一层就停，等于宣布"此人不再犯错即可"，什么防线都没加。任何"人为失误"背后都该有"为什么流程允许这个失误直接抵达生产"的追问。
  
• 文档归档即终点。复盘文档的价值在使用不在存档：防复发清单不进日常流程，文档写得再漂亮也只是墓志铭。
  
• 回头看缺位。行动项"做完了"和"做完了且有效"是两回事，30 天回看时要用验证方式实际测一遍，测不过的重新开项。