故障排查方法

第一步：控制影响

确认受影响的用户、业务、区域、版本和开始时间。需要时先隔离、降级或回退，止损优先于寻找完整根因。

第二步：建立时间线

记录最后一次正常时间、首次异常时间以及期间发生的发布、配置、数据、证书、网络和依赖变化。

第三步：形成假设

每个假设必须能被一个观察或实验支持或否定。优先验证概率高、影响大且验证成本低的假设。

第四步：分层定位

用户入口 → DNS/CDN → 网络 → 应用 → 依赖服务 → 数据库 → 数据 → 外部接口。一次只改变一个变量，避免制造新的不确定性。

第五步：验证恢复

修复后验证技术指标、核心业务、历史数据、告警状态和持续稳定性。不能以“错误日志不再出现”代替业务验证。

故障案例模板

故障现象 → 影响范围 → 时间线 → 证据 → 假设与排除 → 根因 → 临时处置 → 永久修复 → 验证 → 预防措施。

可证伪的诊断表

现象	假设	检查	排除条件
用户等待但任务成功	前端状态未刷新	对照任务状态与请求时间	任务本身仍未完成
所有草稿变慢	模型或共享依赖退化	拆分链路耗时	耗时集中在本地排队
只有一类手册无答案	版本过滤或解析失败	对照批次与候选片段	片段存在且进入候选
写入重复	超时后重试未幂等	同业务键追踪请求	只有一个实际写入

合成故障时间线

10:00 激活候选索引；10:05 部分旧设备问题无结果；10:08 暂停扩大流量；10:12 发现型号字段归一化错误；10:20 恢复上一仍获授权的索引。以上时间为教学示例，不是真实事故记录。

复盘区分触发因素、直接机制与组织改进：索引切换是触发，字段丢失是机制，缺少旧型号回归是待改进控制。不能只把根因写成“人为失误”。

练习与完成标准

保留变更前后证据，写出至少两个被排除的假设，并由他人复核恢复后的用户任务。使用故障复盘模板指定行动负责人和验证日期。

参考阅读与使用边界

• OpenTelemetry：可观测性基础：相关概念与方法的延伸阅读，访问核验日期 2026-10-14。本站练习、流程与指标为自主编排，不属于来源机构认证。
• 学习路线 · 项目实战 · 可下载模板

本页为基础指南；生产操作需结合实际版本、授权环境与审核证据验证。