兩個經典的排障故事
很久之前就在某雜誌上看過，不久前在知乎ofollow,noindex" target="_blank">有哪些讓你目瞪口呆的 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