把一次排查变成下一次的捷径
排障经验最常见的流失方式是只留在当事人记忆里：同一个人下次遇到同样问题还能快速处理，换个人或过半年就得从头再来。沉淀的价值在于把「现象到判据到处置」的链条固定下来，让第二次遇到相同现象时不必重新推导。有效的沉淀不是写一篇经验总结，而是产出结构化、可检索、能验证的条目，并且有明确的维护方式。
基本信息
| 适用对象 | 值班排障、变更事故与预案演练的经验整理 |
|---|---|
| 条目要素 | 现象、判据、原因、处置步骤、验证方式 |
| 检索要求 | 关键词包含错误原文与组件名称 |
| 适用边界 | 标明适用的系统版本与环境前提 |
| 维护要求 | 内容过时需标记或更新，避免误导后续排查 |
值得沉淀的内容
- 高频现象：出现频率高但每次都要重新查一遍的问题
- 误判陷阱：看起来像 A 实际是 B 的情况，写明区分判据
- 判据命令：能快速区分两种可能性的具体命令与预期输出
- 处置步骤：有序的操作步骤与每步的验证方式
- 边界条件：哪些版本、哪些环境适用，哪些情况下不适用
- 失效信号：什么迹象表明这条经验已经不再适用
条目结构示例
条目结构示例
# 现象：任务在多台主机上同时失败，报连接被拒绝
# 判据：ss -lntp 显示端口未监听，服务单元处于失败状态
# 原因：配置变更后端口冲突，服务进程未能启动
# 处置：确认占用进程后停止，重启服务，验证监听与健康检查
# 验证：curl -sf http://127.0.0.1:8080/health 返回 200
# 适用：systemd 托管服务环境，容器编排环境另行处理沉淀方式对比
| 方式 | 可检索性 | 主要问题 |
|---|---|---|
| 个人笔记 | 低，仅本人可见 | 人员变动即流失 |
| 聊天记录 | 低，难按现象查找 | 关键结论埋在日常对话里 |
| 工单记录 | 中，按事件可查 | 缺少提炼，判据与结论混在一起 |
| 结构化条目 | 高，按现象与关键词可查 | 需持续维护避免过时 |
| 检查清单 | 高，可直接执行 | 需随环境变化同步更新 |
沉淀的时机比完整度更重要：在复盘与预案演练结束后立即整理，此时时间线、判据与处置细节都还清晰；隔一两周再补写，关键判据往往已记不全，条目会退化成模糊的经验描述。
条目要能被搜索到，关键词必须包含原始报错文本与组件名。用当时的实际报错片段、命令名与路径作为关键词，比用概括性的词语更能命中下一次的查询。