在线业务的常见全栈故障种类与定位手段
在线系统的稳定性和可靠性是企业数字化转型成功的关键。然而,由于云环境和系统演进的复杂性,故障的发生几乎不可避免。本系列文章将对在线系统可能遇到的全栈故障进行分类,并结合网上的案例分析,对比常规分析诊断手段与Originx推理引擎是如何能够轻松找到全栈故障的根因。
本文为该系列的第一篇,主要介绍常见故障以及全栈故障定位的难点,后续系列文章将重点介绍如何使用Orginx高效定位故障。
常见故障分类与常规的分析定位手段
应用程序故障
代码缺陷导致应用崩溃或错误
○ 案例:2023年双11期间,某汽车在线订单平台的Tomcat服务节点出现了严重的线程池耗尽问题。事发当天上午10点多,随着大促活动的用户流量激增,结算服务的响应时间明显下降。到中午时,大量来自北京地区的用户反馈在提交订单结算时,页面卡顿严重,部分直接超时失败。经过一天的紧张排查,最终发现是Java结算模块存在循环等待的死锁问题。该模块中存在太多的锁粒度,再加上连接池等配置不合理,并发压力下更容易发生死锁。临时解决方案是扩容结算服务的资源,并重启Tomcat释放线程。次日即行修复死锁代码,并持续优化相关模块的并发能力。这次事故虽然只持续了一天,但给用户造成了极差的下订体验。
○ 定位方法:人为分析日志,分析代码,对线程池进行监控,对代码定制化锁的监控(很难实现,没有办法覆盖所有场景)
资源不足(CPU、内存、磁盘)
○ 案例:2023年5月12日,一家大型商业银行的新版网上银行系统在上线后不久遭遇了某些业务场景执行超时的错误。由于代码中存在一个未被发现的逻辑错误,导致在特定参数组合场景下,系统会重复执行某项业务逻辑,造成CPU使用率异常飙升。这种情况在测试环境中难以复现,因此未被及时发现。故障发生后,客户在进行转账和查询等操作时遇到了明显的延迟,严重时甚至导致服务不可用。银行紧急协调开发团队进行排查,在生产环境中利用jstack等工具查找CPU飙升的原因,最终在4小时内定位到了问题源头。通过快速发布补丁修复了BUG,并重新部署了服务。此次事件导致银行损失了大量客户交易,并对其声誉造成了一定影响。
○ 定位方法:借助java分析工具,在故障能复现的时机,人为分析问题