📚 课程目录第1章故障排查概述与基本原则

1. 故障排查概述与基本原则

故障排查，说白了就是系统出了问题之后，我们怎么找到根因、把它修好。我在项目里见过不少新人，一上来就瞎猜、乱改参数，结果越搞越糟。其实这一行有套路，有章法。这一章我就把底层的思路和原则拆开讲清楚。

故障排查不是玄学。它是一套系统性的证据收集、假设验证、根因定位的方法。无论你面对的是服务器宕机、网络丢包、应用报错还是硬件冒烟，底层的逻辑都是一样的。

  核心目标就三个字：快、准、稳。

  快：缩短MTTR（平均修复时间）

  准：不要误杀，不要修了一个症状却留下真正的雷

  稳：修复后系统不再复发

我自己总结了一个七步法，这些年一直用，几乎覆盖了我遇到的所有场景。你想想看，任何故障都可以套进这个框架里。

我把这个流程画成了一幅图，方便你记住它们之间的关系。

光有流程还不够，你得有原则来约束自己的行为。不然很容易被表象带偏。

原则	说明	我踩过的坑
从外到内	先检查网络、配置、权限等外围因素，再深入代码或硬件内部。	有一次数据库挂了，我直接查SQL执行计划，结果发现是防火墙把端口给封了。
从简到繁	先排除最常见、最简单的原因（重启、缓存、超时），再考虑复杂场景。	曾经怀疑是底层驱动bug，折腾两天，最后发现只是磁盘空间满了。
一次只改一个变量	每次只改一个参数或组件，改完就验证。否则你根本不知道什么起了作用。	我年轻时同时改了三个配置，结果问题好了却找不出根因，上线后复发。
备份先行	修改任何关键文件、配置、数据之前，必须留一份原始副本。	曾经没备份直接替换了Nginx配置，回滚花了半小时，期间服务全挂。
可重复性	排查过程中的每一步都要能复现，不能靠碰运气。	“重启一下就好”是假象，你要能稳定触发故障才能定位。

我的个人习惯：在开始排查之前先花三分钟写个“当前状态快照”：时间、观察到的现象、最近一次变更、影响范围。这能帮你把模糊的感觉变成可追溯的数据。

故障排查最大的敌人往往不是技术，而是你自己的大脑。下面这几个坑我几乎都跳过。

锚定效应：一旦先入为主认定是某个原因，后面收集信息就会自动筛选支持这个结论的证据。我见过有同事一口咬定是缓存问题，结果查了三天才发现是代码逻辑写死了返回值。
确认偏误：只找能证明自己猜想的日志，忽略反例。我的经验是——故意去找“为什么这个故障不可能是我现在猜的这个原因”的证据。
过度假设：还没看日志就给问题定性。“肯定是网络波动”“肯定是数据库慢查询”——嗯，这种话一出口，大概率要走弯路。
忽略现场：一上来就重启，把现场的上下文全丢了。尤其生产环境，第一个动作一定是保留现场——dump、日志级别、线程栈，能抓的都抓了再说。

⚠ 特别提醒：不要在故障高峰期做分析。先切流/降级/止血，再慢慢查。我自己的血泪教训——有一年线上故障，我顶着压力排查了40分钟，其实5分钟切回旧版本就能恢复。原则永远是：恢复优先于排查。

很多时候团队吵“排查快不快”是因为没有统一标准。我建议至少盯三个数字：

当然，这些数字不是死的。但是你想想看，如果你连这三个数值都说不出来，复盘的时候拿什么量化改进？

我记得刚做运维那会儿，全靠记忆和直觉。后来发现这事不靠谱。现在我每到一个团队，第一件事就是整理一份“排查工具箱”清单：

  诀窍：把“我遇到过”的案例写成标准化排查步骤（SOP）。下次再遇到类似的问题，直接按SOP走，省得又从头猜。

嗯，这一章的内容就是这些。故障排查的本质是用结构化思维对抗混乱。流程给你框架，原则约束你动作，指标帮你衡量效果，工具箱让你不用每次都造轮子。把这几个东西刻在脑子里，后面每一章都是具体场景下的应用。