上周处理一个线上异常，日志量显示127万条，落库只有119万。8%的数据凭空消失，团队群里开始甩锅。
我开了个Bash窗口，按老习惯先扫一遍中间文件。结果在/tmp目录发现7个未清理的临时切片，加起来正好8万多条。问题不是丢数据，是重复计数了。
一个可复现的排查流程
那次之后我把操作固定成三步：提取信号、核对数量、清理现场。听起来像流水线质检，但Bash里没有撤回键，顺序错了就得重来。
提取信号用的是最朴素的grep -c，先确认原始日志总行数。核对数量时我用wc -l交叉验证，中间文件和最终入库数字必须能对上。最后一步最容易漏——rm掉所有临时产物，包括你以为没生成的那些。
有同事问为什么不直接用ELK看板。看板是结果，Bash是过程。当数字对不上的时候，你需要的是能一步步回放的操作链，不是聚合后的图表。
那个让我栽过的坑
之前写过一个字段映射脚本，逻辑没问题，跑完却少了几千行。复盘时发现，我在循环里用了同名临时文件，上一轮的数据污染了下一轮。Bash不会报错，它只是安静地覆盖掉。
现在我的每个脚本开头都带时间戳命名：tmp_$(date +%s)_$$.log。PID和时间戳双保险，冲突概率低到可以忽略。
清理环节我加了显式确认，ls一遍再rm。多按两次回车，换的是下次排查时不用猜哪些文件是自己的。
为什么坚持手写命令
工具链越来越厚，但 incident 现场往往只剩一个终端。GUI 依赖的接口可能挂掉，脚本依赖的环境可能缺失，Bash 是最后的兜底。
我把常用片段存成模板，遇到同类问题直接粘贴改参数。不是偷懒，是保证每次操作的可复现性——下周的你，或者接手的同事，能跑出一样的结果。
那位丢数据的同事后来问我：如果当时没发现临时文件，你会怎么定位？我说我会把三步再走一遍，因为流程本身就会暴露问题。他沉默了一会儿，说现在他的脚本里也加了清理检查。
你的排查流程里，最容易被跳过的那一步是什么？
热门跟贴