系统异常如何快速排查

本文目录导读：

1. 第一阶段：应急止血（1-3分钟）
2. 第二阶段：快速定位（5-15分钟）
3. 第三阶段：深度定位（对症下药）
4. 第四阶段：经典排查工具集（通用）
5. 核心心法

系统异常（如服务崩溃、响应超时、内存溢出等）的快速排查，核心在于“由外到内、分层隔离、优先止血”,以下是一套标准化的快速排查流程：

第一阶段：应急止血（1-3分钟）

在找到根因前，先恢复服务,以免造成更大损失。

1. 重启大法：对于偶发性异常（如死锁、线程卡顿）,快速重启服务往往最有效。
2. 回滚/切流：如果是新发布的版本导致的异常，立即回滚到上一个稳定版本,或通过负载均衡将流量切到健康节点。
3. 降级/限流：如果是因为流量突增，触发限流保护，检查是否开启了手动降级（如关闭非核心功能）。

第二阶段：快速定位（5-15分钟）

遵循“异常现象 -> 可能模块 -> 对应日志 -> 根因”的路径。

先看监控大盘（全局视角）

• CPU/内存/磁盘/网络：确认是硬件资源耗尽还是代码逻辑问题。
  • CPU 100%：极可能是死循环或密集计算（如正则回溯、GC线程）。
  • 内存飙升：极可能是内存泄漏（如未关闭的连接）或大对象分配。
  • 磁盘满：日志文件未轮转、数据库binlog过大。
  • 网络丢包：带宽跑满或防火墙策略。
• 业务指标：QPS、成功率、耗时，如果成功率骤降,通常是数据库或上游接口出了问题。

接着看日志（精准定位）

• 错误日志（error级别）：直接搜索 ERROR 或 Exception，查看堆栈信息。
  • NullPointerException：某个对象未初始化。
  • SQLTimeoutException：数据库慢查询或锁等待。
  • OutOfMemoryError：Java堆溢出,需用MAT或JProfiler分析dump文件。
• 慢日志（slow query/request）：如果响应慢，排查DB的慢查询日志，看是否有全表扫描、索引失效。
• 访问日志（access log）：看链路上哪个节点返回了5xx或4xx。

再看链路追踪（分布式环境）

• 如果有APM工具（如SkyWalking、Zipkin、Jaeger）：
  • 直接看全链路拓扑，找到红色或红色的节点,那就是故障点。
  • 查看单个请求的耗时分布（Span）：哪个阶段拖慢了整体时间（如RPC调用、数据库查询、第三方API）。

第三阶段：深度定位（对症下药）

根据第一阶段的线索,深入具体模块排查：

第四阶段：经典排查工具集（通用）

CPU/内存/进程

# Linux 下基础排查
top                    # 实时看进程资源占用
htop                   # 更直观的top
ps -aux --sort=-%cpu   # 按CPU排序进程
free -h                # 内存使用情况
df -h                  # 磁盘使用情况
dmesg | tail -20       # 查看内核报错（如OOM Killer杀进程）

Java应用（如果技术栈是Java）

jps -l                 # 查看Java进程ID
jstack <pid>           # 导出线程堆栈（查死锁、卡住）
jstat -gcutil <pid> 1000  # 每1秒看一次GC情况
jmap -dump:format=b,file=heap.hprof <pid>  # 导出堆转储（需谨慎，会卡顿）

网络

netstat -anp | grep <port>  # 查看端口监听和连接状态
ss -tlnp                    # 更快的netstat
curl -v --connect-timeout 3 <url> # 测试接口耗时
ping -c 3 <ip>              # 测试网络连通性

核心心法

1. 不要猜测，要验证：先看监控和日志，再下结论，主观猜测（“是不是代码改了？”）往往不准确。
2. 时间戳对齐：异常发生的时间点非常关键，先查那个时间点前后的日志、监控曲线、发布记录、数据库慢查询。
3. 优先恢复，后治本：遇到生产严重故障，先把服务恢复（重启、回滚、切流）,再下来慢慢分析根本原因。
4. 写复盘报告：排查完后，记录下“异常现象 -> 根因 -> 解决步骤 -> 改进措施”,这对自己和对团队都很重要。