没有解不了的bug，讲讲我做某大型系统的几次修复重大bug的逸事

来源: aguafresh 于 2022-05-18 14:49:48 [档案] [旧帖] [给我悄悄话] 本文已被阅读：次 (3158 bytes)

写程序实现用户要的功能只是最基本的，大型系统里面的代码，有一半都不是为了实现用户可见的功能的，而是为了维护、管理、升级、查bug、评估等等而写的。

- Log & OM

在程序的关键点一定log，要不然死机以后毫无线索。Log占用空间很多，要能分级、分类打开关闭。还要有自动清除的机制。一个新来的coder时想不了这么多，就让平台组根据本系统的复杂程度做好log的机制，其他人调用就是了。printf的底层机制很多人都不清楚，新手用printf把系统吊死的事情太多了。

另外，不可能在所有地方都有log，这时OM就发挥作用。OM是统计各种情况发生的次数，比如做了什么操作、收到某类信息的次数，分类越细越好。

我当时要求所有代码都要有Log和OM，交叉检查时发现没有Log和OM的代码一律枪毙。我的Team里面有个元芳，他写的代码里面有各种OM，记录了自己的代码的各种运行情况，所以他的程序的bug早就清除的比其他人的干净。更神奇的是，他的代码里还有很多OM记录了和他打交道的模块的各种信息，分类有时比原模块还详细。如果现场出了什么神秘的bug，大家在自己的OM里找不到信息，都会问：元芳，你怎么看？

一次我们公司的另一个系统A在某地出了故障，都上新闻了。这是公司另外一个分部做的，他们查了几个小时没有头绪。本来和我没什么关系，但是我的部门也有一套系统在同一地点，我就问：元芳，你怎么看？他调出他的OM，居然有数据表明系统A在死机前的有异常消息路过我们这。把情况告诉兄弟部门，帮他们迅速定位了bug。

- 联想能力

我们的系统是个集群，涉及的操作系统有Unix, Windows和VxWorks。有一段时间，连续几个星期天的下午，技术支持会收到用户投诉，系统响应慢到不可忍受。但是在排查过程中，系统又好了。周末开发工程师休息，被叫来远程登陆，故障已经不在了。从我们的Log 和元芳的 OM看来，是VxWorks操作系统出了问题。VxWorks的供应商说，上火星的Pathfinder都是用这个操作系统，不太可能有影响这么大的bug。

我分析：每次投诉的是不同地方的客户，都是星期天下午，如果是和星期天有关，全国上百套系统，不会每次只有一两个系统有问题。突然想起，N年前看过一则新闻，Windows NT的某个版本，如果停留在登录界面49.7天不动，系统就会自己崩溃。

而我们给客户升级系统，都是在星期六晚上，49.7天后，就是星期天下午。我就让Wind River公司（VxWorks的开发商）那边查，IP Stack里面以毫秒为单位的32bit counter。他们果然发现，里真的有一个这样的counter溢出处理不对，造成网络堵塞。

大家都觉得神奇，我这边没看代码都能定位bug。