奇葩故障排查实录：修了7天都修不好的bug……

最近，小编在知乎上看到这样一个问题：

秉持着和平交流的学习态度，小编精选了几位高赞知乎网友的精彩回答，分享给大家学习交流（勿上升、勿引战）：

给客户配服务器，第二天客户说服务器卡得厉害。

远程维护一次，未解决问题。

把服务器拿回来，给供应商打电话咨询调试，未出现卡顿，送回客户公司。

第二天客户打电话还是说卡。带着供应商上门直接把服务器拆了，检查硬件，硬件完好，未解决问题。

客户继续要求维修服务器，领导背着笔记本亲自出马，半天时间问题解决。

我：怎么解决的？

领导：给他们放了个鼠标垫。

男友是某新能源汽车大厂中负责车机的一个it工程师。

上周六晚上他忽然要加班，陪我遛狗遛到一半也要走到一边一直打工作电话，回到家里游戏也不打了，一直看代码。

我问他发生了什么事，他说测试反馈了说网络不行，出错了，需要找原因。

然后他们部门好多个人又开始打电话，我只看到飞书上面的群聊会议好多个头像，也很多个人说话，空气中弥漫着焦虑的气息......

他们最后一个电话打了快半小时，折腾到将近十二点，终于找到原因：

测试的流量卡没流量了。

原来公司机房每隔三天就会卡死一次。检查了很多次都找不到问题。机器也是新的，不是老化。而且如此的规律简直不可思议。

后来意外的被发现了，保洁阿姨三天来清洁一次。

她会把挡道的线缆拔下来，扫完插回去。

这不可思议的是，她居然没有插错，不然早就发现了。

24年国庆后，供应商告诉我们说24Tb机械硬盘降价了，批发价格很美丽，问我们要不要搞点于是部门进了一批WD24TB容量的硬盘来做磁阵。

磁阵这玩意我们都很熟，硬盘到了就一块块硬盘往里插，做完初始化之后就可以上线用了，大家都没太在意。

但是，但是，但是。

在磁阵上线后，发现读写速度上不去，只有供应商承诺速度的50%左右，慢得出奇。

找了好多人，包括厂商供应商来看都没找出来问题所在，单快硬盘抽出来测试都是满速没问题，插入磁阵整体测试，速度就不行了。

折腾了半个月了，没解决。

于是我们就卡着没结款，说要等问题解决了再付款，否则退货，这批硬盘有问题。

有一天早上我往里面导数据集的时候，惊奇的发现，磁阵速度好像好了一些，达到了标称速度的80%左右，这样导数据就快了不少。

但同时我也接到了磁阵的告警，看起来是磁阵的风扇挂了一个。

这种故障需要尽快处理，于是我去机房给那个磁阵换了个风扇回来后发现磁阵的速度又降下来了。

我......

难道和风扇有关?

于是又跑到机房，把那个磁阵的风扇拔了一半。

然后一测试，磁阵的速度神奇的恢复到了满速(风扇只有一半，单个风扇的转速就会提升)。

好了，这回可以确定和风扇的数量或者转速有关。

但一半风扇肯定不行的。

把运维喊了过来，调试了很多次，最终确定把风扇转速调整到最高转速的85%左右(原来是动态的，开机后应该是60%左右)，磁阵的读写速度是不受影响的。

就这样了。

后来年前有个机会和华为存储+的工程师交流，看他们怎么解决这个问题。

他们说他们有个什么什么铁壳(当时没听清)存储实验室，注意到20TB以上的磁盘，空气传导+的风扇噪声会影响磁盘的磁头定位，进而影响磁盘的读写效率，长时间还会导致磁盘故障率高。

他们的解决方案就是要么用20TB以下的磁盘，要么就重新设计散热架构，用低速大扇叶风扇减少风，扇数量，降低噪音或者避开那个特定频率范围就好了(6个小的换成4个大的)。

哦豁，原来如此。

哈，这个我知道。

我曾经有某一个周一写代码写得很嗨，那天状态特别好，一口气写了六个小时，午饭都没吃。果然编译结束，就1个bug。

结束了，本周工作，哈哈哈哈，吃了个饭，泡了个咖啡，上了个厕所，摸了一条大鱼。

以下就是噩梦开始了，接下来的五天怎么也找不着那条bug，从头到尾重新捋了一遍，甚至写了三个副本，bug越来越多。给我愁的啊，双休两天都睡不着，在湖边边走边想，怎么也想不着，甚至还去办公室对着电脑发呆了两小时。

第二周周一一早，我泡着咖啡，拿着面包，正在思考周报咋写，改了一周的bug?

点开原文件，上下一看，这里怎么少了个)，添上，编译+，编译成功......

我.......

我师父斜着眼看着我，你是不是故意摸了一周的鱼?

交易管理系统，提交订单都是毫秒级的，但偶尔一个订单要花好几秒钟，下午出现比较多，因为是偶尔出现了再去查log，也找不到原因，断断续续查了一年，也没结果。

后来交给我，看代码没问题，测试负载比实际交易大10倍也无法再现，搞了一个星期，我说没办法了，只有连到生产环境查。不能直接在生产的机器上跑测试，在生产环境备用机上跑也是好的，备用机和生产环境共享SAN硬盘。

果然！每隔1分钟就出现一次！问领导，有什么东西在生产环境每隔一分钟跑一次吗？领导一拍脑袋说，有呀，运维团队写了一个监控程序，每一分钟搜索一下log文件，看看有没有报警。

事后查明，运维团队自己写的脚本分析log，log文件从头搜到尾，搜完把结果写入文件，防止下次重复报警，一写就占用硬盘好几秒，数据库也要写硬盘，写不了只好等。

偶尔发生，是因为订单和写文件要同时发生才会延迟。

下午发生多，因为到下午log文件大，延时就出现了。

根本原因，这个bug都不在我们的程序里，怎么查得出。