★ FEATURED ARTICLE 前阵子我追一个线上问题追到凌晨两点各种链路追踪、APM、实时监控面板全开了一轮最后救我的居然是最朴素的打印日志加手工二分。做技术这么多年我一直有种越来越强的感觉当系统复杂到一定程度反而是那种看起来“笨”、完全没有自动化包装的原始方法能让你最快看清真相。这个思路我管它叫 caveman 模式——不是说你真的退化成原始人而是主动选择回到最简单、最可手动复现的排查方式把花哨工具带来的噪声全部剥掉。这篇文章想聊聊我在实际项目中反复用到 caveman 思路的场景和方法。内容包括它到底是一种什么样的做事方式、为什么在复杂系统里反而常常最快、一次完整的手工排障复盘以及我在这个过程中踩过的坑和总结的判断标准。无论你是刚入行的后端开发、运维还是带团队的技术负责人只要经常跟“查不出原因”的线上问题打交道我觉得这套思路都值得放进你的工具箱。1. 我理解的“caveman”到底是什么先说一个很典型的场景。业务方反馈订单创建偶尔变慢监控上曲线几乎是一条直线Trace 系统里每个 Span 的耗时都正常数据库、缓存、消息队列各项指标也都在水位以下。你打开四五个面板来回切越看越懵。最后你怎么查出来的把单量最大的那台机器上的原始日志拉下来用 grep 带上下文慢慢翻发现某个第三方接口在特定并发下会偶发超时而超时又把线程池拖满了。就这么简单的问题藏在几十个图表和几百个 Span 里反而看不见了。我当时在群里发了句吐槽“查了半天最后还是 caveman 式排查救了我。”队友居然秒懂——所有人都在类似时刻有过同样的体验。后来我把这个词在团队里推广指的是一种主动降级到原始工作方式的方法论核心有四点。第一工具链越短越好。现代可观测性平台很强大但也是巨大的信息过滤器。指标聚合了Trace 采样了日志被结构化清洗了你看到的是系统想让你看到的而不是系统真实发生的。caveman 方式要求你直接面对原始输出日志文件、进程状态、网络包、甚至 CPU 占用率这种最底层的东西。信息密度高噪声也大但至少不会失真。第二一切步骤可手动复现。用平台一键回滚很容易但你不一定能说清楚它内部做了什么。caveman 要求你把回滚拆成一条条可执行的命令每条命令跑完看得到输出每步都留得下记录。这个过程会强迫你真正理解系统各个部分的状态关系。第三一次只改变一个变量。这是排查问题的基本纪律但恰恰是高级工具最容易破坏的纪律。很多工具面板上按钮太多你下意识会同时调整几个参数结果问题消失了也不知道是哪个动作起效。caveman 模式下你手上能用的东西很少反而自然而然地遵守了这个原则。第四接受“慢即是快”。手工翻日志确实比一条 PromQL 查询慢很多但它能带来真正的因果判断而不是相关性猜测。很多线上问题用自动化工具五分钟出结果但结果可能是错的之后你绕的弯路可能长达五小时。caveman 模式的好在于它慢在前面快在后面。这套方法不是要否定工具而是给你一种在工具失效时兜底的能力。它更像是一种调试哲学在对系统理解不够深的时候尽量不跳步沿着最朴素的信息路径走到底。1.1 为什么会出现“工具很多反而查不出问题”的怪象我做过的项目里观测体系越完善这种怪象反而越常见。原因其实很简单工具链本身也成了系统复杂度的一部分。采集器要配采样率要调告警规则要维护数据模型要设计这些工作本身就可能引入新的故障点。而一旦工具链出问题你面对的就不再是业务问题而是工具问题。有一次排查内存泄漏我们用 Grafana 看堆内存趋势明明看到曲线一路往上但 dump 出来的堆文件却找不到大对象。后来发现是监控平台自己的 Agent 为了省内存把大对象的引用给截断了我们一直在追一个不存在的对象。关掉 Agent、换成手工 jmap 连续采样三次就定位到了。工具越复杂离真实数据越远这是物理法则。所以 caveman 思路的第一条价值就是重新建立人和真实数据之间的直接连接。你不用相信任何中间层的二次加工你只看最原始的字节流。2. 为什么“笨办法”常常最快我要讲讲原理这套思路的有效性其实可以拆成几个技术层面的原因。首先原始日志保留了严格的时序信息。聚合监控丢掉了细节之间的先后关系而排查问题最依赖的就是先后关系是先有连接数上涨还是先有响应变慢先有队列堆积还是先有 CPU 飙高手工翻日志时你能看到一行行的真实时序可以逐步重建事件链。这种因果链是任何仪表盘都给不了你的。其次手工操作会强迫你建立心智模型。你用 jstack 打线程栈、用 netstat 看连接数、用 curl 打请求每一步都是在给系统建模现在到底有多少线程在跑它们在等什么网络连接是不是已经堆积。这个过程会逼着你回答“为什么”而不是停留在“是什么”。工具自动化之后这个建模过程就被遮蔽了你只看得到最终分数却不知道分数怎么来的。第三手工方法天然隔离了“监控系统失真”这个变量。工具链越重你越难判断一个异常是业务真异常还是工具误报。caveman 方式直接绕过所有中间层不给你怀疑监控 Agent 的机会省掉一整类排查分支。下面这张表是我自己平时做选型时的判断依据纯经验总结不一定放之四海皆准但大多数时候能帮我快速决策。场景自动化工具的优势caveman 方式的价值我的建议已知指标类如 CPU、内存、QPS秒级聚合、趋势清晰原始数据可靠、可复核优先看面板有问题再查原始文件未知根因、偶发类问题可能给出相关性线索能重建因果链不会失真直接看日志和进程状态别过度依赖图表高并发下的性能问题快照工具可能引入额外开销手工低开销采样更安全先用 stat 类命令观察再决定是否上 profiler跨系统调用链路Trace 能串起全局通过时间戳和日志 ID 手动串联两者结合Trace 定位大方向日志确认细节2.1 用生活类比理解“caveman”为什么有效你想象一下家里的灯忽明忽暗。你可以请一个智能家居工程师来把整个房子的电力系统接入监测平台看电压曲线、看功率波形、看所有智能设备的状态上报。这当然好但很可能你等工程师配好那一堆传感器问题已经不出现了。更实际的做法是什么你先站到电箱旁边看哪个回路的空开在跳把那个回路上的电器一个一个拔掉拔到某一个时灯不闪了原因就找到了。这就是 caveman 方式你看的是开合跳闸这种最原始的信号做的是单变量实验。它不高级但它直接、可靠。排查分布式系统问题很多时候缺的不是更复杂的分析工具而是你愿意蹲到“电箱”旁边把问题回路上的组件一个个拔掉。3. 一次完整的 caveman 式实战从手工定位到谨慎回滚光讲道理不行我来复盘一次真实的排障过程。这套流程我后来整理成了团队内部的标准动作每次遇到疑难问题都会照着走一遍。背景是这样的一个订单服务发版后灰度集群的创建成功率从 99.98% 掉到 99.91%看起来很低但因为是灰度环境总量不大绝对失败数其实只有几千。监控面板的聚合图上成功率只是“薄薄一条缝”的下探告警阈值得调得很低才能触发。链路追踪的采样率是 1%那几个失败请求全都漏过去了。于是团队分头查了半天没有结论。我当时拍板把自动化分析停掉进入 caveman 模式只留三样东西——原始错误日志、进程状态命令、一条一条手工执行的排查命令清单。3.1 第一步直接读原始错误日志不对内容做任何加工我们找到灰度集群其中一台机器直接把错误日志文件拉到本地用 grep 配合上下文查看。这一步要忍住不要急着写脚本统计先肉眼看最近几百行的失败记录长什么样。肉眼读日志的价值在于你能注意到那些“没被统计字段覆盖”的蛛丝马迹。日志里出现了大量类似这样的记录2025-01-10 14:23:01.123 ERROR [http-nio-8080-exec-7] o.s.s.TaskExecutor - RejectedExecutionException: Task java.util.concurrent.FutureTask rejected from java.util.concurrent.ThreadPoolExecutor 2025-01-10 14:23:01.125 ERROR [http-nio-8080-exec-9] o.s.s.TaskExecutor - RejectedExecutionException: Task java.util.concurrent.FutureTask rejected from java.util.concurrent.ThreadPoolExecutor线程池拒绝异常——这说明任务提交的速度超过了线程池的处理能力任务队列也满了。但这跟你业务量曲线的平缓表现是矛盾的单量没有明显上涨为什么会突然满带着这个矛盾进入第二步。3.2 第二步过程状态采样用 jstack 连续抓三次线程栈线上问题最怕只抓一次快照因为可能刚好碰到瞬时状态看不出规律。我让同学对着同一台机器连续执行了三次 jstack每次间隔 5 秒输出保存成三个文件。这种手工采样的方式虽然没有大型 profiler 那么精确但胜在开销低、完全可控不会因为采集动作本身压垮服务。三次线程栈都出现了同一个现象绝大多数工作线程卡在一个第三方客户端的调用上状态是 WAITING。更关键的是线程名字后面跟着的队列长度数字一直在涨。这就把因果关系串起来了某个下游接口越来越慢导致线程池里的线程全部阻塞新任务无法处理开始拒绝。用命令统计调用栈中出现频率最高的一行可以这样快速验证for i in 1 2 3; do jstack $PID jstack_$i.txt sleep 5 done # 提取出现次数最多的线程状态关键字 grep -E java.lang.Thread.State jstack_*.txt | sort | uniq -c | sort -rn输出会非常明显地告诉你WAITING 状态的线程占了绝对多数。这个命令很土但十五秒内就能给出一个相当可靠的结论。3.3 第三步手工构造最小复现确认根因而不是只确认现象线程池满的原因还需要进一步确认。我们写了一个最简单的压测脚本固定并发数持续打一个会调用该第三方接口的测试端点。同时手工抓这个第三方连接池的状态。这里的关键参数是并发线程数 50、每个请求的超时时间 3000ms、下游平均响应时间已经从 200ms 涨到 2800ms。通过计算可以判断——50 个线程乘以 2.8 秒的阻塞时间意味着每秒最多只能处理不到 18 个请求而实际每秒进入该接口的请求是 30 个左右。这个计算不复杂但它彻底解释了为什么线程池会满50 个并发线程 / 28 个请求每秒 每个请求排队等待约 1.8 秒 队列容量 200 / 30 每秒 约 6.7 秒后队列满 6.7 秒 请求处理时间 2.8 秒 ≈ 9.5 秒后开始拒绝从日志里看报错确实是业务量上来大概十秒左右开始出现的跟这个推算完全吻合。根因也清楚了下游服务变慢把线程池拖死而不是线程池配置本身有错。3.4 第四步手工回滚每一步都留证据定位到根因之后团队面临一个决策要不要回滚新版本因为新版本本身没有直接引起问题它只是把流量引到了变慢的下游服务上。但线上成功率已经受影响先恢复业务最重要。我没有用发布平台的一键回滚。原因很简单一键回滚会同时改配置、切流量、重启容器动作太多如果回滚后问题还反复就很难判断是哪个动作没生效。所以我用 caveman 的方式手工执行回滚从负载均衡上把这台灰度机器的权重调成 0观察 2 分钟确认没有新流量进来已有请求慢慢排空备份当前版本的可执行文件和配置文件到指定目录记录 md5 值停掉服务进程把旧版本文件替换回去校验 md5 一致后再启动先在本地回环地址上 curl 一次健康检查接口确认服务起来了再手工发一个真实的测试订单确认核心链路通过最后才把权重逐步从 0 调到 10、50、100每步观察一分钟。每一步的输出都保存成文本文件附带当时的时间戳。这样整套过程是可审计的万一出了问题我可以明确指出是哪一步造成的。最后回滚完成成功率恢复。整个过程没有用任何自动化发布工具但每一步的逻辑都非常清楚。这次复盘让我深刻体会到一件事如果你能用手工命令完整复现一次发布和回滚你才算真正理解了你的发布系统。手动回滚之所以听起来“原始”是因为它的确逼着你理解每一个步骤的本质而不是把理解交给平台。4. 常见误判与避坑经验——什么时候该用 caveman什么时候要果断放弃任何方法论都有适用范围盲目坚持都是另一种幼稚。我在实际操作中积累了几条比较重要的判断经验分享出来。4.1 一上来就手动是一种反面偏执有段时间团队被我说得过分迷信原始方法新同事遇到问题第一反应就是登机器翻日志连现成的告警面板和日志检索平台都不愿意看。这是不对的。如果一个问题的指标特征已经很明确比如 CPU 飙升、内存溢出自动化工具直接给出方向你就该用工具别为了追求“纯手工”浪费时间。我的习惯是先给自己设置十五分钟的工具排查时间这段时间内只看面板和检索平台尽量多收集线索。十五分钟没有方向立刻切换成 caveman 模式。这叫时间盒也叫止损线。4.2 伪 caveman手工但没有任何记录最可怕的是嘴上说手工做起来却不留痕迹。有人拿着 jstack 抓线程栈抓完看了一眼就关掉到写完结论时发现数据已经没了有人手动改配置改完忘了备份原文件回滚时找不到原始值。真正的 caveman 方式必须像考古一样对待每一个证据文件命名要带时间戳命令输出要重定向保存修改前先复制一份原文件到 backup 目录。看起来多花几秒钟但这是整套方法可靠性的底线。4.3 手工操作容易忽略“观测者效应”当你手工抓线程栈、手工查看日志时这些命令本身也会消耗系统资源。在高峰期对一台核心机器频繁执行 jstack 和 jmap可能让服务变得更慢。我后来规定采样类命令每次最多连续执行三次每次间隔不小于三秒做完立刻停手分析不搞无意义的长轮询。尤其是在大内存应用上jmap 的 full GC 触发风险是真实存在的。我见过同学为了分析堆内存连续执行了几次 jmap -dump直接把服务弄到 Full GC 频率激增最后不得不重启。手工方法也要控制操作频率和操作粒度。4.4 回滚顺序不要拍脑袋永远先断流量再动代码第四点是我回滚经验里最核心的教训。很多人回滚时习惯先替换文件再重启觉得这样“一步到位”。但如果你在流量还没摘掉的情况下做操作重启瞬间会有新请求继续打到这个正在变化的实例上出错概率会大增而且如果服务起不来流量就直接摔在地上了。正确顺序永远是先摘流量、再等存量请求排空、接着备份文件、然后替换代码、验证实例健康、最后慢慢放量。每一步之间要留观察窗口不要图快。这个顺序我自己踩过坑后来写成团队操作规范再没出过问题。4.5 排查时只测成功路径漏掉了失败路径的参数变化手工验证时很容易犯的错是只盯“订单创建成功”这个主路径。但实际上有些问题恰恰只影响失败分支。比如同样的订单请求成功时返回 200失败时返回 500但你在手工验证时用的测试数据永远是成功的根本触发不了 500 分支。正确做法是准备正常数据、异常数据、边界数据三组用例分别验证。正常数据看主链路异常数据看错误处理链路边界数据看参数解析和容量限制。手工模式下这不过是一组 curl 命令的事情但很多人偏偏省掉了异常分支这一组。4.6 常见排查场景速查表症状首选方式什么时候切 caveman主要风险CPU 持续飙高现成的 CPU profiler 火焰图火焰图打不出来或采样失败采样工具本身占用 CPU内存缓慢上涨监控面板看趋势dump 后离线分析dump 文件与实际对象不符dump 触发 Full GC影响现网接口偶发超时全链路追踪定位耗时瓶颈Trace 采样率太低抓不到失败请求手工日志量太大耐心耗尽线程池满、拒请求jstack 连续采样人工数线程状态线程栈文件巨大靠肉眼分析太慢jstack 抓取间隔选错错过峰值发布后成功率微降对比新旧版本日志输出差异指标变化太小面板看不出来新版本引入日志框架变化干扰对比这张表是我在团队内部做分享时用的指导思想很简单能用现成工具快速得出结论的绝不刻意手动自动化工具给不出可靠结论时立刻切换成最朴素的方式。两个方向不矛盾关键是根据问题特征做好切换时机。关于 caveman 的一些延展思考这套思路不止用于排查故障。我后来做系统设计时也经常问自己一个问题如果所有自动化工具和框架明天都不能用了你还能不能用最原始的方式完成这件事发布可以那就说明你真正理解了发布链路回滚可以说明你理解了状态管理扩容可以说明你理解了资源模型。凡是回答不了的问题就是你知识体系里的短板也是迟早会在线上爆雷的地方。另外我个人觉得 caveman 模式并不是终点它的后半段是自觉。某一次手工操作如果做了两遍以上就说明这是重复劳动条件成熟时应该把这件事固化成脚本或工具。最好的团队不是天天手工救火而是每个人都能在必要时用手工方式救火救完之后把经验沉淀成新的自动化能力。这种循环——亲手做、理解它、做成工具——才是我心目中 caveman 思路最完整的样子。
阅读完成 · 觉得有帮助？
