3. 故障排查流程：从发现到复盘，一个都不能少
故障排查这件事，说白了就是一场与时间的赛跑。我在团队里带过不少新人，发现大家最容易犯的毛病是——一上来就急着定位问题，结果连故障到底影响多大都没搞清楚。
我个人习惯把整个流程拆成五个阶段：发现、响应、定位、恢复、复盘。这五个阶段环环相扣，少一个都不行。你想想看，如果跳过复盘，同样的故障下个月还会再来找你。
核心原则：故障处理不是个人英雄主义，而是标准化流程。每个阶段都有明确的目标和产出物。
3.1 故障发现：别等用户来骂你
故障发现这件事，我踩过最大的坑就是——监控覆盖不全。有一次线上数据延迟了整整两个小时，监控没报，最后还是业务方打电话来问，我们才知道出了问题。嗯，那次复盘会开得很难看。
所以我现在对监控的要求很简单：能自动发现的，绝不等人报。常见的故障发现手段包括：
- 指标监控：延迟、吞吐量、错误率、成功率。这些是基础，必须配阈值告警。
- 日志监控：ERROR 级别日志的实时聚合。我建议把日志接入 ELK 或 Loki，配合关键字告警。
- 端到端拨测：模拟用户行为，定时探测数据产品的核心链路是否可用。
- 业务指标异动：比如日活突然下降 30%，这往往是数据质量出问题的信号。
我的习惯：每个数据产品至少配 3 层监控——基础设施层、应用层、业务层。缺一层，你就可能漏掉故障。
3.2 故障响应：黄金 5 分钟
故障一旦被发现，响应速度直接决定了 SLA 能不能保住。我个人习惯把响应阶段分成三步：
- 确认告警：先看一眼是不是误报。我曾经遇到过半夜被告警吵醒，结果是监控阈值设得太低。
- 评估影响面：影响多少用户？影响哪些业务？影响等级是 P0 还是 P1？这个判断决定了后续的响应力度。
- 拉起应急群：把相关方拉进群，同步故障等级、影响范围、当前状态。记住，信息透明是减少恐慌的最好方式。
| 故障等级 | 定义 | 响应时间要求 | 恢复时间要求 |
|---|---|---|---|
| P0 | 核心功能完全不可用，影响全部用户 | ≤ 5 分钟 | ≤ 30 分钟 |
| P1 | 核心功能部分不可用，影响大量用户 | ≤ 15 分钟 | ≤ 2 小时 |
| P2 | 非核心功能异常，影响少量用户 | ≤ 30 分钟 | ≤ 8 小时 |
| P3 | 体验问题，无功能影响 | ≤ 4 小时 | ≤ 24 小时 |
注意：响应阶段不要急着修问题。先搞清楚影响面，再动手。我曾经见过有人一上来就重启服务，结果把现场证据全丢了，定位花了更长时间。
3.3 故障定位：别靠猜，靠数据
定位阶段是最考验功力的。我的经验是——先看监控大盘，再看日志，最后看代码。这个顺序能帮你快速缩小范围。
具体来说，我会按这个思路走：
- 看时间线：故障是什么时候开始的？那个时间点附近有没有变更？发布？配置修改？数据源切换？
- 看依赖链路：数据产品通常依赖多个上游系统。是上游挂了，还是中间件出了问题，还是我们自己的代码有 bug？
- 看关键指标：CPU、内存、IO、网络、GC 情况。很多故障其实就藏在这些基础指标里。
- 看日志：重点看 ERROR 和 WARN 级别的日志，配合 traceId 把一次请求的全链路串起来。
# 快速定位脚本示例：检查最近5分钟的ERROR日志
grep "ERROR" /var/log/data-product/app.log \
| grep "$(date -d '5 minutes ago' '+%Y-%m-%d %H:%M')" \
| awk '{print $1, $2, $5, $NF}' \
| sort | uniq -c | sort -rn | head -20避坑指南：我曾经遇到过一个故障，定位了 2 小时才发现是上游 Kafka 集群的磁盘满了。从那以后，我要求所有依赖系统的健康状态必须实时展示在运维大盘上。
3.4 故障恢复：先止血，再根治
恢复阶段的核心原则就四个字：先止血，再根治。别想着一步到位把问题彻底修好，SLA 在倒计时呢。
常见的恢复手段包括：
- 回滚：如果是发布导致的故障，第一时间回滚到上一个稳定版本。
- 切流：有多机房部署的话，把流量切到备用机房。
- 降级：关闭非核心功能，保证核心链路可用。
- 重启：有些内存泄漏或连接池耗尽的问题，重启能临时解决。
注意：恢复操作一定要在应急群里同步。我曾经见过一个人偷偷重启了服务，结果其他人还在定位，现场全没了。恢复操作必须「先通报，再执行」。
3.5 故障复盘：别让同样的坑绊倒两次
复盘是很多人最容易忽略的阶段。但我跟你说，复盘才是最有价值的环节。没有复盘，故障就白出了。
我主持复盘会时，通常会问三个问题：
- 根因是什么？ 不是表面原因，是真正的根因。比如「代码写错了」是表面原因，「代码 review 流程缺失」才是根因。
- 为什么监控没发现？ 如果监控覆盖了，故障本可以更早被发现。
- 怎么防止再发生？ 需要改代码？加监控？优化流程？
复盘结束后，一定要输出一份故障报告，包含：
| 项目 | 内容 |
|---|---|
| 故障编号 | 唯一标识，方便追溯 |
| 故障等级 | P0/P1/P2/P3 |
| 时间线 | 从发现到恢复的完整时间轴 |
| 根因分析 | 5 Why 分析法得出的根因 |
| 影响范围 | 受影响用户数、业务损失 |
| 改进措施 | 具体可执行的 action item |
| 责任人 | 每个 action item 的 owner 和 deadline |
我的经验：复盘不是为了追责，是为了改进。如果复盘会开成了批斗会，下次出故障就没人敢说了。记住，没有 blame 的文化，才有真正的复盘。
好了，以上就是故障排查的五个阶段。每个阶段都有它的价值，缺了任何一个，你的故障处理能力都会打折扣。下次遇到故障，不妨按这个流程走一遍，你会发现——原来故障处理也可以有条不紊。