两个经典的排障故事

很久之前就在某杂志上看过，不久前在知乎 有哪些让你目瞪口呆的 bug 里面又见到了；我觉得这两个troubleshooting的case有很深的道理在里面，记一下。

电子邮件无法发送到500英里以外

这个故事最早出现于2002年11月24日，而且每过若干年，它就会在不同的系统管理技术社区中再次出现，并且引发人们的热议和关注。有人对这个故事给出了这样的评价：

这个故事大约每过三年或四年就会在系统管理社区出现，每次我读到它，都觉得很值得一读。即便在正常环境下已经做过检查，甚或经过片刻思考之后，我还是高度怀疑这种事情是否会发生在自己身上。

这是一个真实的故事。如果你想要进一步了解它的相关信息，可以访问这个 FAQ – 一个关于本故事的常见问题列表，由本故事作者 Trey Harris 编写。

这个故事听起来有点儿天方夜谭的感觉… 我已经有些后悔把这个故事分享给大家了，因为它很可能会沦为众人茶余饭后的谈资。:–) 为了保护自己的内疚感，我对故事做了稍许改动，省略了无关紧要以及无聊的细节，总之让故事变得更加生动有趣了。

几年以前，我在一家运营校园邮件系统的公司工作。有一天，我接到了来自统计部主任给我的电话。

“我们的邮件系统存在一个问题。”

“什么问题？” 我问道。

“我们不能发送超过500英里距离的邮件，” 主任解释说。

我被手中的拿铁咖啡呛着了。“再说一遍？”

“我们不能把邮件发送到超过500英里距离的地方，” 他重复道。“真的，哪怕再远一点点。只能到达520英里，不能再远了。”

“嗯…通常来说，邮件真的不是按照这种方式来发送的，” 我说道，并尽力让自己的声音平静下来。一个人与部门主任谈话时通常不会带有恐慌情绪，即使是一个相对无实权的部门如统计部。“是什么让你认为邮件不能发送超过500英里之外的？”

“并非我这么认为，” 主任不耐烦地回答道。“你瞧，几天之前我们就发现了这一现象…”

“你等了好几天了？” 我打断他的话，声音有些颤抖地问道，“这段时间你都不能发送邮件吗？”

“我们能发邮件，只要不超过…”

“500英里，是吧，” 我替他补充道，“我知道了。但是为什么你不早点给我电话呢？”

“好吧，问题是直到刚才，我们才收集到足够的证据确定这一现象的发生。” 也对，他是统计部主任。“总之，我让一名地理统计人员去调查了这件事情…”

“地理统计人员…”

“是的，她制作了一张地图，地图上显示我们能发送邮件的区域半径比500英里多那么一点点。即便如此，这个半径区域之内的有些地方也不能发送，或者偶发性地能发送，但是在半径区域之外从来没有发送成功过。”

“我明白了，” 我说道，“何时开始的？你说几天之前，那么这段时间内系统发生什么改变了吗？”

“是的，技术服务人员来过，给服务器打了补丁然后重启了系统。但是我给他去过电话，他说他没碰邮件系统。”

“好的，我先看看吧，然后再给你打过去，” 我说，几乎不相信我也会来虚与委蛇这一套。今天不是愚人节啊。我试着去回忆，是不是有人欠我一个恶作剧。

我登进他们部门的服务器，发了一封测试邮件。这是发送到北卡罗莱纳州的三角研究实验，测试邮件很顺利地到达我的邮箱。同前面一样，我又发送到里士满、亚特兰大、华盛顿，还有普林斯顿（400英里），都能顺利到达。

但是当我尝试发送邮件到孟菲斯（600英里）时，却失败了。发往波士顿，失败了。发往底特律，同样是失败。我拿出我的地址薄，开始试图缩小范围。纽约（420英里）可以发送，但是普罗维登斯（580英里）就失败了。

我开始困惑，是不是我失去了理智。我试着给我一位居住在北卡罗来纳州的朋友发送邮件，他的 ISP（网络服务提供商）在西雅图。谢天谢地，发送失败了。如果这个问题只和收件人的居住位置有关，而不是和他（她）的邮件服务器有关的话，我想我真该泪奔了。

问题得以确认，尽管令人难以置信，但问题确实存在而且可以重现。我查看了 sendmail.cf 文件，它看起来很正常，没有任何问题。事实上，它看起来很熟悉。

我将这个文件和我本机 home 目录下的 sendmail.cf 文件进行了比对。二者没有什么不同，这个文件就是我自己写的。我也确信没有启用 “FAIL_MAIL_OVER_500_MILES” 这一选项。带着满腹困惑，我远程登录到 SMTP 端口。服务器使用一个 SunOS sendmail 标识愉快地做出了响应。

等等… 一个 SunOS sendmail 标识？在那时，Sun 仍然随同操作系统捆绑发布 Sendmail 5 版本，尽管 Sendmail 8 已经相当成熟了。作为一名优秀的系统管理员，我已经把 Sendmail 8 作为一个标配了。同时，作为一名优秀系统管理员，我写了一个 sendmail.cf 配置文件，使用了 Sendmail 8 中优雅详细且自我描述的选项和变量名，而不是 Sendmail 5 中含义模糊的标点符号标记的代码。

一切都水落石出了，突然间，我被那杯现已冷的掉渣的拿铁咖啡再次被呛到了。当那名技服给服务器打补丁的时候，很显然他也升级了 SunOS 的版本，如此一来自然把 Sendmail 的版本“降级”了。升级程序将 sendmail.cf 配置文件单独保留了下来，即使它现在对应的是错误的版本。

碰巧的是 Sendmail 5（至少 Sun 发布的版本，或许做过一些调整）可以处理 Sendmail 8 的 sendmail.cf 配置文件，因为大多数的规则在那时并没有改变。但是对于那些在 Sendmail 8 中新增的长配置项，Sendmail 5 将之视为垃圾而忽略掉了。sendmail 的二进制安装包对大多数选项没有提供默认值，因此，如果在 sendmail.cf 中找不到合适的设置，它们就会被设为0。

这些被设为0的选项之一就是连接远程 SMTP 服务器的超时时间。一些试验已经证实，在一个具有典型负载的特定机器上，零超时意味着如果连接时间稍微超过3毫秒，服务器就会终止连接。

当时我们的校园网络有一个很奇怪的特点，它是百分之百交换型网络。发送出去的数据包，在遇到 POP 服务器和远端路由器之前，不会出现路由器延迟。因此，连接到临近网络上负载较轻的服务器所花的时间，很大程度上是由光速决定的，而不是偶发的路由器延迟。

这可真是让人有点儿眼花缭乱啊，我在 shell 里敲入如下代码：

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds  
You want: miles  
        * 558.84719
        / 0.0017893979

"500 miles, or a little bit more."

原文:

http://www.ibiblio.org/harris/500milemail.html

地板阻碍打印

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

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

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

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

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

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

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

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

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

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

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

专家说有一块地板变形了。当值班人员踩着这块变形的地板的一角时，地板块的边缘相互摩擦，这就会跟连接各地板的塑料之间产生静电，进而造成电磁干扰。

如今所有的RAM都有防电磁干扰功能。但当时并没有这种技术。专家指出，电磁干扰破坏的RAM的工作，操作系统也就崩溃了。

专家打电话给维护部门，拿来了一块新地板，他自己把它装上，问题就这样解决了。

原文:

http://patrickthomson.tumblr.com/post/2499755681/the-best-debugging-story-ive-ever-heard