Linux事故复盘核心是将故障转化为可复用能力，聚焦“系统为何未拦截错误”；需锚定时间、影响、证据链三类结构化事实；用四层归因模型（触发/技术/流程/组织）穿透表象；改进项须明确责任人、时限、动作与验证标准；知识须提炼为可执行卡片并嵌入工具与演练。
Linux事故复盘不是写完报告就结束，而是把一次宕机、一次丢包、一次OOM变成团队可复用的能力。关键不在“谁错了”，而在“系统为什么没拦住错误”。
一、从故障现场快速提取结构化事实
复盘前必须完成信息锚定，避免后续讨论被模糊描述带偏。重点不是还原“全过程”，而是锁定可验证的硬指标：
- 时间锚点：精确到秒的首次告警时间、服务不可用起始时间、恢复时间（不是“处理完”的时间，而是监控指标回归基线的时间）
- 影响量化：受影响进程名+PID、CPU/内存/磁盘I/O峰值、TCP重传率、核心接口P99延迟增幅、用户请求失败率（不是“部分用户受影响”这种话）
- 证据链闭环：/var/log/messages + dmesg输出 + top -b -n 1采样 + netstat -s统计 + 对应时段的Prometheus指标截图，四者能相互印证
二、用四层归因模型穿透表象
拒绝停留在“Redis连不上”或“磁盘满了”这类描述。每层追问必须有依据，不靠猜测：
- 触发层（What）：比如“systemd-journald进程RSS达4.2GB后被OOM Killer终止”——这是日志和cgroup数据直接给出的
- 技术层（Why-1）：journal日志轮转配置缺失（MaxRetentionSec未设）、应用疯狂刷DEBUG日志（grep -r "DEBUG" /var/log/journal确认频率）
- 流程层（Why-2）：变更检查清单里无日志策略核查项；压测环境未开启journal持久化，导致线上行为不可预测
- 组织层（Why-3）：SRE团队无日志治理SLA；新人上岗未接受日志规范培训；技术债看板中“日志膨胀风险”已挂起6个月
三、把改进项变成可执行、可验证的动作
“加强监控”“完善流程”是无效改进。每个措施必须满足：red">谁在什么时间前，用什么命令/配置/脚本，达成什么可观测结果：
- ✅ 有效：“运维组在2025-01-15前上线logrotate强制策略，覆盖所有/var/log子目录，通过ansible-playbook -t logrotate_check验证每台机器生效”
- ✅ 有效：“开发组下周起所有新服务Dockerfile中加入ENV JOURNAL_RATELIMIT_INTERVAL=30s，CI流水线增加grep校验步骤”
- ❌ 无效：“提升日志管理意识”“优化变更流程”
四、让经验真正流动起来，而不是锁在文档里
事故记录只是原料，知识库需要的是“即插即用”的决策单元：
- 把“journald OOM”抽象为知识卡片：症状（systemd-journald进程RSS突增+OOM Killer日志）、第一响应（journalctl --disk-usage → journalctl --vacuum-size=500M）、高危操作（不要直接rm /var/log/journal/*）、验证恢复（journalctl --disk-usage
- 将卡片嵌入运维手册对应章节，同时注入ZSH自动补全：输入
fix journal回车，自动提示上述操作序列 - 每月抽取1张卡片做“盲测演练”：给值班工程师只给症状描述，限时5分钟写出完整处置步骤，检验知识是否真可落地
