1. 故障排查概述
故障排查，说白了就是跟线上问题抢时间。你想想看，系统挂了、页面打不开、数据写不进去……每一分钟都是钱，都是用户体验。我做了这么多年运维，最深的感受就是：排查的速度决定了故障的伤害半径。
但很多人一上来就瞎查。不看分类、不问阶段、不讲原则。这就像进了医院不挂号直接找手术室，能行吗？这一章我就把基本功掰开揉碎，跟你聊聊故障分类、故障生命周期和排查原则。这三样东西，是你能稳住阵脚的前提。
1.1 故障分类
碰到故障，第一步不是急着查日志。你得先搞清楚：这到底是什么级别的故障？我个人习惯把故障分成三个维度来看。每个维度对应不同的处理方式。
为什么分类这么重要？我在项目中遇到过很多次，团队因为分不清故障类型，把硬件问题当软件问题查，浪费了大把时间。你想想看，分类错了，排查方向就偏了，后面的所有动作都是白费。
| 分类维度 | 类型 | 说明 | 典型示例 |
|---|---|---|---|
| 按影响范围 | 单机故障 | 单台机器或实例异常 | 某台服务器磁盘写满 |
| 局部故障 | 某个机房或集群部分不可用 | 可用区B网络抖动 | |
| 全局故障 | 整个系统或核心链路瘫痪 | 数据库主库宕机 | |
| 按故障类型 | 硬件故障 | 物理设备损坏或性能衰减 | 内存ECC报错、硬盘坏道 |
| 软件故障 | 代码Bug、配置错误、版本兼容 | 空指针异常、连接池泄漏 | |
| 网络故障 | 连通性、丢包、延迟、DNS解析 | 交换机环路、公网BGP抖动 | |
| 安全故障 | 入侵、DDoS、数据泄露 | Redis未授权被勒索 | |
| 按可恢复性 | 可恢复故障 | 通过重启、回滚、扩容能恢复 | 应用进程假死 |
| 不可恢复故障 | 需数据恢复或人工重建 | RAID卡损坏导致数据丢失 |
close()的Bug。如果当时当硬件故障去排查，至少要多花半小时。
1.2 故障生命周期
每一个故障，从出生到死亡，都有固定的节奏。我个人习惯把故障生命周期分成五个阶段。理解这个周期，你就知道当前该做什么，下一步要准备什么。
- 发现阶段 — 通过监控告警、用户反馈、巡检等方式感知异常。发现得越早，损失越小。
- 定位阶段 — 收集信息、分析日志、确认根因。这个阶段最考验技术功底。
- 修复阶段 — 执行预案、回滚配置、扩容重启。目标是快速恢复服务。
- 验证阶段 — 确认修复生效，监控指标回归基线，业务恢复正常。
- 复盘阶段 — 整理时间线、分析根因、制定改进措施。这是防止同类故障再犯的关键。
记得有一次半夜三点，电商大促期间，支付链路突然超时飙升。我当时按这个周期来：发现（监控告警）→ 定位（日志显示Redis集群主从切换卡住）→ 修复（强制切换并重启节点）→ 验证（支付成功率恢复99.9%）→ 复盘（发现是内存碎片率过高触发异常切换，后续加了碎片整理定时任务）。按周期走，就不会慌。
重点提醒：很多人跳过"验证"和"复盘"。服务恢复了就以为结束了？大错特错。不验证，你不知道修复是不是真的生效；不复盘，同样的坑下次还得踩。我见过太多团队在同一个故障上反复栽跟头，就是因为生命周期走不完整。
1.3 排查原则
排查的时候，什么先查、什么后查，是有讲究的。你不能拿着锤子看什么都像钉子。我总结了四条原则，说白了就是排优先级、省时间。
| 原则 | 说明 | 优先级 | 什么时候用 |
|---|---|---|---|
| 先外后内 | 优先排查外部依赖（DNS、CDN、云厂商、第三方API），再查内部代码 | ⭐⭐⭐ | 突发大面积不可用 |
| 先软后硬 | 先查配置、版本、代码逻辑，再查物理设备 | ⭐⭐ | 系统行为异常但无硬件告警 |
| 先主后次 | 优先恢复核心链路和主功能，边缘功能暂缓 | ⭐⭐⭐ | 故障影响核心业务时 |
| 先快后慢 | 先止损（重启、降级、限流），再查根因 | ⭐⭐⭐ | 故障持续造成损失时 |
这四条原则不是死规矩，要灵活用。举个例子：有一回线上突然大量502，我按先外后内先查了SLB和后端服务器连通性，发现都正常。接着按先软后硬查了Nginx配置，果然发现有人改错了upstream的weight。先主后次让我只修核心域名，其他次要接口稍后处理。先快后慢让我先回滚配置恢复服务，再去看是谁改的、为什么改。
避坑提示：我曾经在一次故障中死磕"先软后硬"，查了半天代码和配置，最后发现是机房空调坏了导致服务器降频……嗯，从那以后我学乖了：原则是指导，不是教条。如果你发现软的方向查了两轮还没头绪，果断切到硬件方向看看。灵活切换，才是真本事。
总结一下这一章的核心：分类让你看清故障的本质，生命周期让你知道当前该做什么，排查原则让你少走弯路。这三样东西，是你成为故障排查高手的起点。后面几章我们会深入到每个阶段的具体方法和工具，但基础打得牢，后面才能跑得快。