业务报错如何定位解决

wen 开源项目 2026-06-25 31

本文目录导读：

业务报错如何定位解决

业务报错（尤其是线上环境）的定位和解决，是一个从现象到根因再到方案的系统工程,高质量的定位能力是区分初级和高级工程师的关键。

下面是一个通用的 “四步定位法” ，结合了分层排查的思维和具体工具,帮助你系统性地解决问题。

第一步：定性：这是谁的错？

当看到报错信息时，先别急着看代码,先问自己三个问题：

快速定位的黄金三件套：日志 + 监控 + 链路追踪

看日志（ELK/Loki/Graylog）：
- 关键动作： 立刻搜索报错中的关键ID（订单ID、用户ID、requestId/traceId）。
- 看堆栈： 找到第一行报错（Caused by），而不是最下面那一堆，是空指针（NPE）？还是数组越界？还是超时异常（TimeoutException）？
看监控（Prometheus + Grafana / Zabbix）：
- 关键指标： CPU、内存、磁盘IO、网络IO、GC（垃圾回收）情况。
- 模式： 如果业务报错的同时，CPU飙高，大概率是死循环、大对象、高并发资源争抢。
看链路追踪（Skywalking / Jaeger / Zipkin）：
- 关键动作： 看一次请求在各微服务之间的耗时分布。
- 判断： 哪个环节耗时最长？是数据库查询（慢SQL）？还是调用外部服务超时？

不要一头扎进最复杂的业务逻辑代码里，建议按照 “入口层 -> 数据层 -> 业务层” 的顺序来排查。

现象： 请求直接超时、响应慢、大量502/504。
原因：
- Nginx配置问题（proxy_read_timeout 设置过短）。
- Web服务器（Tomcat/Jetty）线程池耗尽（Too many open files 或 Connection refused）。
- 排查方法： netstat -anp | grep <port> 看连接数；检查Nginx error.log；看Tomcat的 access.log 的响应状态码。

现象： 数据库连接池满、死锁、慢查询、Redis OOM（内存溢出）。
排查方法：
- MySQL： 运行 SHOW PROCESSLIST; 看有哪些长时间未完成的查询，使用 EXPLAIN 分析慢查询SQL，检查 InnoDB 死锁日志（SHOW ENGINE INNODB STATUS\G）。
- Redis： INFO memory 看内存使用，SLOWLOG GET 10 看慢命令。
- 消息队列： 检查积压数量（Backlog）,消费者是否断连或死掉。

现象： 特定业务逻辑失败,但外围一切正常。
排查方法：
- 核心假设： 数据库里的数据和代码假设不匹配，某个字段本应是数字，但数据库里存了“N/A”；某个ID本应存在,但被删除了。
- 边界条件： 循环内的 list.get(i) 超出了 list.size()？多线程环境下共享变量没加锁？
- 代码复用： 最近有没有人修改过公用工具类（如日期处理、JSON解析）？

当抓住几个关键报错日志后,开始深入挖掘证据链。

入参是什么？ 把能复现问题的用户的入参（JSON/表单）记录下来。
当时的状态是什么？ 数据库里的 order_status 是否是 INVALID？缓存里的 token 是否过期？
机器环境差异？ 测试环境没问题，生产环境报错？检查配置中心（apollo/nacos）的配置项是否一致，比如数据库连接地址、第三方API的Secret。

找到根因后,修复方案需要分等级处理。

快速止血（Hotfix）：
- 如果用户报错影响业务，立刻回滚到上一个稳定版本。
- 如果因数据导致，直接修改数据库（有风险，需审批）或回滚事务。
- 如果依赖的外部服务挂了，开启熔断（Hystrix/Sentinel）或降级（返回默认值）。
彻底根治：
- 代码层面： 增加判空、边界检查、增加重试机制。
- 数据层面： 增加唯一约束、增加数据校验Job、修复历史脏数据。
- 架构层面： 引入分布式锁、优化慢SQL（加索引、拆表）、改为异步处理。

场景： 用户反馈“下单”按钮点击后一直转圈，最终报“系统繁忙”。

定位过程：

定性： 不是所有用户都报错，只有一批老用户报错。不是通用问题。
看日志： 搜索该用户的 userId 和 orderId，日志堆栈显示 TimeoutException 从 StockServiceClient（库存服务客户端）抛出。
看监控： 库存服务机器的CPU和内存正常，但该服务的 average_response_time 高达 20秒（正常是 50ms）。
看链路追踪： 发现库存服务内部调用了数据库查询，这个查询耗时 15秒,定位到慢SQL。
分析数据： 发现慢SQL SELECT * FROM stock WHERE product_id IN (...) AND status = 1。product_id 字段没有索引，针对 这批老用户，商品ID列表特别长（几百个）。
根因： 数据库 stock 表的 product_id 没有索引，老用户购物车商品多，导致SQL全表扫描，锁住大量行,进而导致超时。
修复：
- 止血： 手动给 product_id + status 加联合索引,用户恢复。
- 根治： 修改代码，限制一次最多查询50个商品ID；如果超过,分批查询。
- 预防： 将此SQL加入慢查询日志,并设置告警。