1. 故障排查总纲：稳定性问题的定义、分类与排查方法论

1.1 到底什么是稳定性问题？

做SRE这些年，我见过太多人把「系统挂了」和「稳定性问题」划等号。其实没那么简单。

稳定性问题，说白了就是系统偏离了预期行为。这个「预期」很关键——你想想看，一个电商系统在大促期间响应慢3秒，算不算问题？如果SLA里写的是5秒，那就不算。但如果平时只要200毫秒，那这就是个典型的稳定性隐患。

我个人习惯把稳定性问题定义为：系统在承受压力或发生变更时，无法持续提供符合SLA的服务能力。注意，这里强调了「持续」和「SLA」两个关键词。

我在项目中遇到过最典型的案例：一个支付服务，平时每秒处理200笔交易，一切正常。结果双十一流量涨到2000 TPS，数据库连接池直接打满，整个服务雪崩。这其实就是弹性不足导致的稳定性问题。

1.2 稳定性问题的四大分类

做故障排查，第一步不是查日志，而是先搞清楚你面对的是哪一类问题。我一般把它们分成四类：

分类	典型特征	排查方向
容量类	流量高峰时出现，平时正常	资源瓶颈、限流降级
变更类	上线或配置变更后出现	版本回滚、配置比对
依赖类	下游服务或中间件异常	调用链追踪、熔断检查
代码缺陷类	特定场景复现，有规律	日志分析、代码走查

嗯，这里要注意：很多问题其实是混合型的。比如变更引发了代码缺陷，代码缺陷又导致了容量问题。所以分类只是帮你缩小范围，不是让你死磕。

1.3 排查方法论：我的「三板斧」

做故障排查这么多年，我总结了一套自己的方法论。说白了就三步：

第一板斧：止血

别急着找根因。先让系统恢复，哪怕只是临时恢复。我记得有一次线上数据库挂了，我第一反应不是查慢查询，而是直接切读库。先让用户能用，再慢慢查问题。

第二板斧：定位

止血之后，才是真正的排查。我习惯用「时间线法」——把故障发生前后的所有事件按时间列出来。你想想看，很多时候问题不是突然出现的，而是有预兆的。

举个例子：

14:00:00 - 发布新版本 v2.3.1
14:15:00 - 开始出现少量 502
14:30:00 - 502 比例上升到 5%
14:45:00 - 告警触发，值班人员介入
15:00:00 - 全站不可用

看到没？从发布到全站挂，有整整45分钟的窗口期。如果能早一点发现，根本不会酿成大祸。

第三板斧：根因分析

定位到问题范围后，就要深挖根因了。我常用的方法叫「5W法」——连续问五个为什么。

比如：

1. 为什么502？因为请求超时。
2. 为什么超时？因为数据库连接池满了。
3. 为什么连接池满？因为有个慢查询占着连接不放。
4. 为什么有慢查询？因为新版本改了SQL，没走索引。
5. 为什么没走索引？因为代码评审没发现这个变更。

你看，根因根本不是「慢查询」，而是「代码评审流程有漏洞」。

1.4 排查工具链：你的武器库

光有方法论不够，还得有趁手的工具。我一般把工具分成三层：

• 基础设施层：CPU、内存、磁盘、网络监控（Prometheus + Grafana）
• 应用层：日志（ELK）、调用链（Jaeger）、APM（SkyWalking）
• 业务层：业务指标监控、用户行为分析

我个人习惯是：先看业务层，再看应用层，最后看基础设施层。为什么？因为业务指标最能反映用户感受。如果用户没感知，那系统再「异常」也不是紧急问题。

1.5 排查的黄金时间窗口

做SRE久了你会发现，故障排查有个「黄金15分钟」。什么意思？就是故障发生后的前15分钟，你能获取的信息最多、最准确。

过了这个窗口，很多现场信息就丢失了：

• 日志被滚动覆盖
• 内存快照被回收
• 连接池状态被重置
• 现场被重启操作破坏

1.6 总结：排查的底层逻辑

说了这么多，其实核心就一句话：稳定性问题排查，本质是信息差的问题。你不知道系统在干什么，所以你觉得它「不稳定」。当你把所有的信息都串起来——日志、指标、调用链、变更记录——问题自然就浮出水面了。

嗯，最后分享一个我自己的习惯：每次排查完故障，我都会写一份「事后复盘」，不光写技术原因，还要写流程原因。然后把它归档到团队的「故障知识库」里。下次遇到类似问题，直接搜关键词就能找到解决方案。

这才是SRE该有的工作方式，不是吗？