你不曾听过的最强debugging故事

调试| 2016-01-17

英文：The Best Debugging Story I’ve Ever Heard

那还是80年代初期，我爸爸在一家存储设备公司工作，这个公司现在已经不存在了，它生产磁带机和驱动这些磁带高速运转的气动系统 —— 这是那个时代的产物。

(Used under license from Laughing Squid. 原始图片可以在这里找到。)

他们技术改造了磁带驱动器，使得你可以只有一个中心驱动器 —— “A”盘 —— 由它连接着数个“B”盘，在跟A盘连接的内存里驻留这一个小型的操作系统，负责代理所有B盘的数据的读写操作。

每次当你启动A驱动器，你需要在外围驱动器里插入一张软盘，操作系统会把A盘加载到内存里。这个操作系统简单的出奇 —— 它的处理能力全部从一个8字节的微型控制器产生。

这种设备的目标用户是拥有大量数据的企业 —— 银行，杂志等等 —— 他们需要打印大量的地址簿或银行帐目。

有个客户出现了一个问题。在打印的过程中，有个别的驱动器会停止工作，导致整个打印过程终止。为了重载驱动器，值班人员必须重启所有驱动 —— 如果这种事情发生在一个6小时的打印任务中，大量宝贵的计算机使用时间都会浪费，整个任务将不能按时间完成。

公司派出了技术人员。技术人员尽了他最大的努力也不能在测试环境复制出这个问题：这个问题似乎只会出现在打印大量任务的过程中。尽管问题出在硬件上可能性微乎其微，他还是更换了所有的设备 —— 内存，微处理器，磁盘驱动，所有跟磁带机相关的部件 —— 但问题仍然出现。

于是技术人员打电话给总部叫来了一位专家。

专家要了一把椅子和一杯咖啡，坐在了计算机房 —— 那个时候他们已经专门为计算机提供了机房 —— 值班人员准备了一大堆的打印任务，他就在旁边看着。他等着，一直到机器崩溃。机器果真崩溃了，所有人都看着专家 —— 专家没有发现任何的线索。他命令把打印任务重新执行一次，所有的值班人员和技术人员都回各自岗位工作。

专家又在椅子上做下来，等着机器崩溃。这一等就是六小时，但真的又发生了。专家仍然没有弄清是什么导致了崩溃 —— 除了有一点他注意到，崩溃总是发生在屋内人比较多的时候。他命令再打印一次，重新坐下，等着。

当第三次崩溃时，他发现了一件事情。崩溃总是在值班人员更换其他没有关联的启动盘时发生的。进一步研究，他意识到当一个值班人员走过某块地板时崩溃就会发生。

地板是由铝制的板块拼成，下面有6 到 8 英寸高的隔空层，计算机所使用的大量的电缆都走地板下，这样可以避免值班人员无意间踢到它们。地板块间拼合的很紧密，这是为了保证垃圾不掉进电缆通过的空间。