复盘第一件事是锁定“谁在什么时候干了什么”，需精确到秒重建可验证时间线，杜绝模糊表述，并通过命令锚定commit、镜像、日志等上下文。
复盘第一件事：锁定“谁在什么时候干了什么”
事故复盘不是写检讨，是重建可验证的时间线。必须精确到秒——比如 2026-01-28T14:22:03+0800 第一条 Prometheus 告警触发，14:22:17 服务 HTTP 5xx 率从 0% 跳到 92%，14:25:41 执行回滚命令。模糊表述如“大概下午两点左右”会直接断掉证据链。
关键动作要带上下文：
• git log -n 1 --oneline 记下发布 commit ID
• kubectl get deploy -n prod lb-svc -o yaml | grep -A3 "image:" 锁定镜像版本
• journalctl --since "2026-01-28 14:20" -u nginx --no-pager | head -20 提取告警前日志片段
根因不能止于“Redis连不上”，要穿透四层
看到 Connection refused 日志，别急着重启 Redis。按顺序问：
• 触发层（What）：ss -tulnp | grep :6379 显示 Redis 进程根本没监听，还是监听了但被防火墙 DROP？
• 技术层（Why-1）：查 systemctl status redis 发现启动失败；再看 journalctl -u redis -n 50，发现报错 Can't open /var/lib/redis/dump.rdb: Permission denied
• 流程层（Why-2）：变更清单里没包含 SELinux 上下文校验项；压测环境用的是 root 启动，线上却用 redis 用户
• 组织层（Why-3）：SRE 团队未将 restorecon -Rv /var/lib/redis 加入部署后检查脚本
改进项必须能被“一键验证”
“加强监控”“完善流程”等于没说。每条改进都要明确执行人、时间点、命令和验收标准：
• ✅ 运维组在2026-02-05前为所有 Redis 部署单元增加 systemd unit 文件中的 ExecStartPre=/usr/bin/restorecon -Rv /var/lib/redis，上线后执行 systemctl cat redis | grep ExecStartPre 验证
• ✅ 开发组本周起 CI 流水线中加入 check-secontext.sh 脚本，对 /var/lib/redis 目录做 ls -Z 断言，失败则阻断发布
• ❌ “提升配置管理意识”——无法执行，也无法证伪
经验沉淀的关键：把故障变成“即插即用”的决策卡片
复盘报告写完就扔进 Confluence 是最大浪费。真正有用的是知识卡片，比如针对 systemd-journald OOMKilled：
• 症状：journalctl --disk-usage 显示超 2GB，dmesg | tail -10 出现 Out of memory: Kill process 1234 (journald)
• 第响应：journalctl --vacuum-size=500M 快速释放空间
• 高危操作：rm -rf /var/log/journal/* 会破坏 journal 索引，必须用 --vacuum- 系列命令
• 验证恢复：journalctl --disk-usage 回落到 400MB 以下，且 systemctl is-active journald 返回 active
复杂点往往藏在“看起来没问题”的地方：比如 curl 探测脚本引发的 dentry 泄漏，进程 RSS 没涨、OOM Killer 没触发，但 slabtop -o | grep dentry 里占比持续飙升——这种内核对象泄漏，得靠 /proc/meminfo 里的 SUnreclaim 值异常才露头。
