超级管理员
楼主
排查了这么多年问题，我发现大部分人的困难不是不会用工具，而是没有一个稳定的思路。分享一个我自己用的分层框架。
第一层：确认现象 这一步看起来简单，但被跳过的概率最高。
要回答的问题：
- 具体表现是什么？「系统很慢」不是现象，「P99 从 200ms 涨到 3s」才是。
- 影响范围？所有用户还是特定用户？所有接口还是特定接口？
- 什么时候开始的？精确到分钟。这个时间点前后的变更是什么？
- 能不能复现？稳定复现还是偶发？
关键动作：把「系统很慢」翻译成可度量的指标。做不到的情况下，任何后续分析都是在猜。
第二层：定位环节 有了明确现象，下一步是缩小范围。
常用方法：
- 分层排除。从外到内：DNS/CDN → 负载均衡 → 应用 → 缓存 → 数据库 → 外部依赖。每层加一个探针，看哪一层开始异常。
- 对比法。正常的请求和异常的请求差在哪？同一个接口，不同的参数、不同的用户、不同的时间。
- 变更回溯。出问题的时间点前后，上线了什么？配置改了什么？流量有什么变化？经验上超过一半的线上问题和变更相关。
- 二分法。对代码或数据做二分，快速定位到具体位置。
关键动作：先做减法，确定不是什么，比确定是什么更快。
第三层：找到根因 定位到某个模块还不算完。
要追问：
- 为什么这个模块会出问题？是容量不够、逻辑错误、还是依赖异常？
- 这个错误为什么之前没暴露？
- 监控为什么没提前发现？
- 类似的问题还会在哪里出现？
第五个问题最重要。修好一个 bug 只是及格分，找到同一类问题的其他实例才算完成。
几个反模式
- 一上来就改代码。没确认现象就动手，大概率改错地方，还引入了新问题。
- 只看平均值。平均响应时间正常不代表没问题，P99 可能已经炸了。
- 忽略日志的时间戳。分布式系统里时钟不同步会让你得出完全错误的因果推断。
- 没有保留现场。急着重启恢复服务，结果证据全没了。先抓快照（线程栈、内存、请求采样）再恢复。
一条经验 每个排查结束的问题，都应该产生三样东西：一个修复、一个监控项、一条文档。没有后两样的话，同样的问题还会再来一次。
本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。