兩個經典的排障故事
很久之前就在某雜誌上看過,不久前在知乎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