1. 先把 Caveman 这个词聊透很多第一次听到“caveman”的人第一反应是问这说的是石器时代的原始人吗在工程语境下还真有点这个意思。Caveman debugging穴居人式排障指的就是那种抛弃一切花哨工具、回归最朴素手段来定位问题的方法——直接看代码、打日志、逐段重启、把变量一个个打印出来。听起来很土但在生产环境爆炸、监控图表失灵、链路追踪断了的时候这套“原始人”方法往往比任何高端平台都管用。我最初接触这个词是在一次线上事故复盘会上。当时同事调侃说“我们没有可观测性平台只有print_r”大家会心一笑。后来我才意识到这种自嘲背后其实是一套完整的排障方法论。这篇文章想讲清楚三件事caveman 排障法到底解决什么问题、怎么做才算真正掌握了它、以及它在今天自动化工具环境下还有没有生存空间。适合谁来读刚入行一到三年的后端或全栈工程师遇到线上问题手忙脚乱只会重启服务的也包括那些已经被分布式追踪、指标监控“惯坏”遇到工具失效就彻底没辙的资深开发。读完之后你会收获一套在任何环境下都能兜底的排障基本功——它不需要任何商业订阅只需要你的脑子和一块能写代码的环境。另外如果你正好在评估团队的应急响应能力这篇文章也能给你提供一套低成本但有效的演练思路。2. 为什么“简单粗暴”反而能解决问题2.1 现代工具链的死角越高级越脆弱先说清楚一个反直觉的现象现代排障工具本身正在成为排障的障碍。链路追踪、全链路监控、APM、分布式日志平台这些东西的部署和维护成本都不低。正常情况下它们确实能帮你快速定位问题但有一个致命前提——它们必须部署正确、采样完整、Agent 版本和你的中间件兼容。一旦你遇到的问题恰好出在 Agent 自身、网络协议栈、或者容器网络层这些“高级工具”给出的数据本身就是错的。我经历过一次典型的“工具误我”事件。当时接口偶发超时监控平台显示 P99 从 200ms 跳到了 3s但看单机指标一切正常。团队花了一下午追查为什么监控数据和实际体验对不上最后才发现是新版 Agent 在特定内核版本下会漏采一部分事件导致数据出现空洞。而真正的根因——一台宿主机上邻居实例疯狂IO——反而是靠最笨的办法发现的逐台登录、手动敲命令观察load。这套笨办法就是 caveman 排障法在现代环境下的核心价值当你的工具链出现数据真空或数据误报时你的双手必须还能直接触达系统的原始状态。2.2 三种“原始手段”及其背后的原理caveman 排障法不是“乱试”它有三套固定的招法对应不同的系统层面你需要根据问题特征去选。第一招叫“原始观察”不看监控大屏直接登录生产机器用top、vmstat、ss这些最底层命令去看系统状态。这一招背后的逻辑是任何监控平台最终的数据源都来自这些系统调用你直接读取源头就绕过了中间所有可能出错的处理环节。比如有一次 MySQL 出现连接池耗尽监控面板上显示的活跃连接数是 500但手动ss -s一看TIME_WAIT 状态的实际socket超过 8000 个两者差距大到不像同一套系统。第二招叫“二分定位”把请求链路分段逐段确认哪一段出现了问题。它的核心不是“猜”而是用最少的检查次数快速收敛范围。对一个 A 调 B、B 调 C、C 调 D 的链路先检查 B 是否正常如果正常则问题在 C 或 D再检查 C……每次排除一半的候选范围。这个思路算法上就是二分查找但在实际排障中很多人一着急就乱跳这其实就是没有章法。第三招叫“最小化复现”把复杂场景压缩成一个最简单的脚本或一条命令确认问题能否稳定复现。很多生产问题难以定位是因为线上流量随机、数据多样你很难判断哪个变量是触发条件。手动构造一个最小样例将无关变量全部剔除一旦稳定复现根因就直接暴露在眼前了。2.3 什么样的问题才能真正靠它解决上面说了原理和具体怎么做但什么时候该用它这个边界得划清楚。我个人的经验是当问题涉及“系统状态”而非“业务逻辑”时caveman 方法胜率极高。业务逻辑问题往往可以通过代码 review 和单测解决但系统状态问题——文件句柄耗尽、网络重传率高、内存碎片化、conntrack 表爆掉——这些几乎都发生在运行时环境里光看代码看不出来必须到现场去“闻味道”也就是亲手敲命令。反过来如果问题是你新写的算法逻辑复杂、边界条件多那朴素排障法其实帮不上太大的忙老老实实写单元测试、用 IDE 调试器效率反而更高。所以这是一套“兜底”的方法论不是万能的排障理论。你得先判断问题的性质再决定用什么招。3. 核心环节记住这套操作的每一步3.1 完整实战一个接口偶发超时的排障过程前面说了一堆理论和思考接下来我会完整还原一次排障现场把从接警到根因确认的每一步都记录下来包括我当时在想什么、为什么做这个操作。这套动作我已经重复了几十遍了希望能给你提供一个可以“抄作业”的模板。某个周五下午运营反馈“用户上传头像偶尔超时”。描述是“偶尔”频率大概是每 10 次请求有 1 次响应超过 5 秒其余正常。我做的第一步不是看监控而是先自己复现。打开终端手动 curl 上传接口循环 20 次统计耗时分布。结果确实复现了17 次正常200ms 以内3 次严重超时4-6 秒。这一步很重要——确认能复现后面才有得查如果自己这边根本复现不了就得考虑增加自动化采样或者先去检查压测环境了。第二步确认网络路径。上传请求经过 Nginx、后端网关、对象存储三个节点。我在服务器上用curl -w加了时间拆解参数连接时间、TTFB首字节时间、总耗时分别统计。结果发现一个关键线索所有超时请求的 TTFB 都在 3 秒以上而正常请求的 TTFB 只有 50ms 左右。这说明问题大概率出在服务端处理环节而不是客户端网络。第三步看服务端日志。这里有个很容易被忽略的认知如果你的应用是同步线程模型接入了外部对象存储 SDK那么上传耗时会直接等于对象存储的响应时间加上重试时间。翻日志发现超时请求全都卡在了和对象存储交互的那一行而且 SDK 打印了“connection timed out”之后又重试了两次每次间隔也在 3 秒左右三项叠加起来正好是 5 秒左右。到这一步问题范围已经从“接口超时”收敛到了“应用与对象存储的访问超时”。3.2 使用“原始观察”确认真实连接状态接下来就是开始“原始观察”的部分了。我用ss -tnp看当前到对象存储服务的 ESTABLISHED 连接数量同时用netstat -s看整个系统的重传率。结果发现两个异常一是到对象存储的 TCP 连接数量远超正常水平最多时有 40 多条处于 ESTABLISHED 状态二是系统重传率数字明显偏高有很多 SYN_SENT 状态。这里我再补充一点排查 TCP 相关问题的经验单看连接数量高不一定是坏事必须结合重传率来看。如果你看到大量 SYN_SENT 状态意味着你的连接请求根本没到达对端或者对端的 backlog 已经满了如果看到大量 ESTABLISHED 但重传率高则要考虑网络丢包或者对端处理不过来。这次我们的情况比较典型连接数偏高重传率高基本可以判断为网络层面丢包或者连接数超限导致的新建连接排队。为了验证我在请求发出去的前后分别执行了三次ping和mtr对比丢包率。ping 的结果让我很意外ICMP 的正常率很高只有零星丢包。但这里有个很多新手容易犯的判断错误ICMP 正常不代表 TCP 正常。有些云服务商的负载均衡器对 ICMP 有单独的处理通道甚至直接禁 ping所以 TCP 层的重传率才是最贴近业务真实状态的证据。于是在这一步我这么判断问题不是出在“完全连不上”而是“连接资源在某些时间段内不够用导致 TCP 握手排队触发应用侧的超时重试”。“不够用”的原因有两个方向——要么是出口 NAT 并发连接数打满要么是本地框架连接池设置不合理。为了进一步收敛我又用ss -s统计了本地的 socket 状态分布发现大量 TIME_WAIT 聚集在特定端口区间且数值递增很快。到这里我几乎已经确定问题方向了但还是不想推翻对业务代码的判断于是用最后的“最小化复现”招法做了一个独立实验写了一个 30 行不到的 Python 脚本直接循环发起 HTTP 请求到对象存储不开业务框架不走鉴权链路纯粹测试连接性能。结果同样复现了偶发超时而且频率比业务路线更高。这相当于把业务代码层彻底排除了——问题就在网络通道、连接池或者对端连接能力。3.3 根因落地与最终修复方案确认了网络通道后继续用最小化脚本测同时用一个死循环采样ss -tn state established ( dport :443 )观察连接数变化。测试脚本同时发包的场景下观察到本地到对象存储的连接数能够飙升到 120 条而且大量请求被阻塞在底层 socket 写等待上。然后我去翻了服务端框架的连接池配置。Apache HttpClient 的默认配置是每个路由最多 5 条连接理论上连接数不该冲到 120。但我们的 SDK 版本比较老它内部默认使用系统级连接池而不使用框架池这导致连接生命周期完全由系统 TCP 栈管TIME_WAIT 状态积压严重导致新连接被反复重置。修复动作分三步落地升级对象存储 SDK 到新版使用上层连接池并设置 maxConnPerRoute 20。调整内核参数net.ipv4.tcp_tw_reuse1让 TIME_WAIT 状态的连接可以被安全复用同时降低net.ipv4.tcp_fin_timeout到 15 秒让半关闭连接更快释放。在业务侧增加了优雅降级——对象存储上传失败时先写入本地临时目录由异步任务补偿推送不再同步阻塞接口。最终实测循环 100 次上传P99 稳定在 300ms 以内超时彻底消失。整个排障过程耗时 2 小时其中真正写代码的时间不到 30 分钟其余全是在做“原始观察”和手工验证。这就是我理解中的 caveman 排障法不迷信任何一步到位的工具每一步都用最直接的方法确认过再往前走。4. 避坑指南Caveman 排障法的边界与误区4.1 三个最常见的误用方式很多人在听我分享完这套方法论后都会点头表示明白但实际去用的时候还是会跑偏。我观察到一个高频错误是“原始观察变成了无脑观察”。具体表现就是问题一发生不加思考地登上一堆服务器top、free、df各敲一遍把所有输出截图发工作群然后就没有然后了。这样做的效率极低因为你并没有带着假设去验证。正确的做法是什么呢每一次观察前先告诉自己我现在要验证什么比如我认为连接数可能打满那我就专门看ss -s我认为磁盘可能满了那我就专门看df -h。在敲命令之前就问自己这个命令的输出能够支撑或者推翻我的哪个判断如果回答不上来这个命令就不该敲。第二个常见误用是“最小化复现做得不够小”。很多人嘴上说要写最小化脚本结果为了图省事直接把生产代码的配置文件拷过来跑了一个半集成测试。这不是最小化复现而是带着一堆变量去碰运气。真正的最小化复现是去掉所有你能去掉的东西——不要带鉴权、不要带业务参数、不要走框架封装只用最底层的 SDK 裸发一个请求。只有这样当问题复现时你才能确定它和业务逻辑无关。第三个误用发生在排障结束后。找到了根因、修好了问题很多人直接把当时敲过的命令、读过的日志抛到脑后。这样下次遇到类似问题又要从头查一遍。我的习惯是每一次排障都要留一份“战报”写成几百字的文档记录原始现象、用过的关键命令、证据链走向、最终根因和修复动作。这个文档既是团队的财富也是你自己的排障肌肉记忆。4.2 常见时间浪费点对照表为了让大家少走弯路我把这些年见过的时间浪费场景整理成了一个速查表全部基于实际排障经历常见误区典型表现正确做法反复重启服务重启后正常一段时间过一会儿又挂先收集日志和状态快照再决定是否重启在生产环境乱试改了配置立即生效但没记录改了什么每个变更都要备份并在文档里记录变更时间与原因盲目更新工具版本以为新版本能解决一切升级后问题更隐蔽排障期内保持环境不变升级放到修复验证之后只看到单点指标看 CPU 高就加机器实际是连接泄漏把 CPU、内存、连接数、IO 四个维度数据放在一起看忽略系统时间一致性日志里时间混乱无法串联链路先统一 NTP确认各机器时间偏差在 100ms 以内这五条是我见过的高频雷区每个都足以让一个原本 1 小时可以定位的问题拖成加班一整天。特别是最后一条“系统时间一致性”很多团队直到排查日志才发现各个节点的日志时间对不上那前面的分析等于全废了。4.3 Caveman 排障法与自动化测试的关系有一个常见的误解是既然 caveman 排障法强调手工观察那是不是意味着自动化测试和监控体系不重要错而且错得很离谱。我理解更准确的关系是自动化测试负责在问题发生之前拦住它而 caveman 排障法负责在自动化失效之后兜底。两者分工不同不是互斥关系。况且大多数项目里监控平台与自动化用例只能覆盖已知的故障类型对未知的、偶发的、跨层的疑难问题最终兜底的还是人。另外自动化测试还有一个真正做到位了会发现它其实能大幅减少你使用 caveman 排障的频率。一个能快速跑通核心链路的集成测试套件配合精准的业务指标告警完全可以为你争取到宝贵的提前量。但要记住一点测试套件本身也可能成为问题源头——排查 panic 时你同样可以用最小化复现的思路先跑一个最简单的用例来判断是业务代码的问题还是测试框架的问题。所以高手从来不在两个方法之间二选一而是把两者放在一个完整的工具箱里用。5. 把 Caveman 思维变成日常习惯5.1 一套可落地的日常演练方案Caveman 排障法更像是一种身体记忆跟游泳或骑车一样你光看懂原理没有用得练到形成肌肉记忆。怎么练我推荐一种成本极低但效果极好的方式混沌演练。不需要引入什么复杂的攻击工具你只需要在测试环境里做几个最简单的动作把一台机器的磁盘写成满、把某个下游服务的超时时间调成 10 秒、把连接池上限砍到 1。然后要求团队成员不借助监控平台只用登录机器敲命令的方式去定位问题。演练结束后大家对照各自找到的证据链看看谁的排查路径最短、谁的判断最接近根因。我团队每个季度会安排一次类似的演练每次选一个不同的故障场景。刚开始几次大家的完成时间参差不齐最快的 20 分钟慢的能折腾两小时。练过四五轮之后再遇到线上问题绝大多数人已经会先确认连接数再去看日志不再像没头苍蝇一样乱撞了。5.2 一套“排障前 5 分钟”的固定动作这个习惯是我在一个故障频发的项目上总结出来的。每次接到告警、准备投入排障前先花 5 分钟做四件事第一件事确认当前时间。注意这里不是问几点而是确认你看到告警的时刻和问题实际发生的时刻差多久。比如监控图上曲线已经掉下去 20 分钟了才发现这时候你去追查实时状态往往是徒劳的必须直接去翻这个时间窗口内的历史日志。第二件事确认变更。回看最近 24 小时内的所有配置变更、发布事件、数据库迁移有 70% 以上的生产故障都能在这里找到线索。第三件事确认单点入口。不论问题多大先找出一个可以直接复现或者可以持续采样的具体接口或页面避免在浩瀚系统里大海捞针。第四件事建立证据链。打开一个空白文档把时间、现象、当前做的每一次操作全部记下来不要依赖记忆。这套动作在排障场景里省下的时间非常可观。它迫使你从“条件反射式地查看一堆指标”转变为“带着问题假设去验证”效率简直是从走路换成了骑车。有一次我在排一个诡异的内存问题团队已经排查了两个小时没有头绪结果我一翻他们的证据链发现系统时间有偏差把日志按真实时间轴重新排了一遍问题立刻清晰了。这说明即使是高手也会在慌乱时忽略基本项。5.3 给新手的一条最重要的心法如果你从头读到这里我只能记住一句话那我会选这句排障的胜负手不在你的工具多高级在于你有没有胆量直接面对最原始的证据。所谓原始证据就是操作系统的计数器、TCP 连接状态、进程里真实的线程数、磁盘和网络的实际吞吐。它们不经过任何层层封装的平台的加工不会因为你漏配了某个 Agent 而缺失更不会在你最需要它们的时候凭空消失。你唯一需要做的是把它们从系统底层读出来然后诚实地对照自己的代码逻辑。这不是一条容易修炼的路因为它对你的操作系统知识、网络协议知识都有实打实的要求。但反过来说恰恰是这些底层的、看似“原始”的知识才真正区分了能独当一面的工程师和只会调接口的“工具人”。也许 Caveman 这个名字不优雅但它代表了一种永不过时的、面向真相的排障姿态——当你愿意直接裸眼面对系统的时候那些藏在层层抽象之下的妖魔鬼怪都不会再有藏身之地。