昨天晚上，我終於把 More Joel on Software 翻譯完了。
謝天謝地，總算可以擺脫這本書了。
唯一的感覺就是特別倦怠......檢查完譯稿以後，我一分鐘也沒等，立刻用Email發給了編輯，然後倒頭就睡，直到剛才起床。此書的編輯工作量很大，但願一切順利，可以在年底前上市。
下面的文章是此書的第35篇，也就是倒數第2篇。它介紹了一種很好的工作方法，就是說，當你遇到問題的時候，要一連問5個為什麼，不停地問，直到找到根本原因為止，我覺得真的很值得借鑑。
======================
五個為什麼
作者：Joel Spolsky
譯者：阮一峰
原文網址：http://www.joelonsoftware.com/items/2008/01/22.html
發表日期 2008年1月22日，星期二
2008年1月10日的凌晨3點30分，一陣急促的嘟嘟聲驚醒了我們的系統管理員Michael Gorsuch，當時他正在位於布魯克林的家中睡覺。那是一條網路管理員Nagios發來的短訊息，報告系統不正常。
Michael Gorsuch從床上爬起來，不小心踩到了正在床邊酣睡的他的狗，把狗也弄醒了。那條狗氣呼呼地竄到客廳裡，在地板上撒了一泡尿，然後又回來繼續睡覺。這個時候，Michael Gorsuch已經在另一間房間裡開啟了電腦，發現在他負責的三個機房中，有一個位於曼哈頓鬧市的機房連不上去。
這個特別的機房位於曼哈頓繁華地區一幢很安全的大樓裡，面積很大，由Peer 1公司負責管理。它配備了發電機，以及足夠使用好幾天的柴油，還有大量的蓄電池，保證在自備發電機啟動前，能夠提供幾分鐘的電力，防止出現訪問中斷。它還有巨大的空調裝置，多個高速網際網路出口，以及非常務實、負責的工程師，他們總是以一種單調、穩重、井然有序的方式進行工作，而不會用花俏、刺激、時髦的方式做事，所以那是一個非常可靠的機房。
像PEER 1這樣的ISP，喜歡使用一個叫做"服務級別協議"（Service Level Agreement，簡稱SLA）的術語，承諾保證他們服務的正常執行時間（uptime）。典型的SLA往往這樣寫："保證99.99%的時間正常執行"。你可以做一下算術，地球圍繞太陽公轉一圈的時間是525949分鐘（或者以一年365天計算，就是525600分鐘），這就允許他們每年有52.59分鐘的故障時間。如果故障時間多於這個數字，SLA通常會寫清楚提供某種形式的賠償，但是說實話，賠償的金額往往是微不足道的......比如，你購買了一年的服務，他們就按照發生故障的分鐘數，把相應的使用費退還給你。我記得有一次，某一個機房發生故障，整整兩天都不能訪問，給我們造成了幾千美元的損失，結果我從ISP那裡得到的唯一賠償，就是10美元的退費。所以，SLA保證條款其實是沒用的。而且正是因為賠償金額微不足道，許多ISP開始打廣告，聲稱正常執行時間高達100%。
過了十分鐘，Michael Gorsuch連上了曼哈頓的機房，一切似乎都恢復正常，他就又回去睡覺了。
大約到了清晨5點，這個問題又出現了。這一次，Michael Gorsuch打電話到PEER 1在溫哥華的網路運營中心NOC。對方開始調查，做了一些測試，但是沒有發現任何異常。5點30分，一切好像又恢復了正常。但是，Michael Gorsuch還是不放心，不敢再回去睡覺了。
清晨6點15分，曼哈頓機房徹底無法連通。PEER 1在他們那一邊找不到任何異常。Michael Gorsuch穿好衣服，搭地鐵進入曼哈頓。伺服器本身好像沒有出問題，都在正常執行。PEER 1的網路連線也是好的，問題出在交換機。Michael Gorsuch取下了交換機，將我們的路由器直接連到了PEER 1的路由器。真是奇妙，我們的伺服器又可以重新訪問了。
這時，天已經亮了，我們在美國的客戶開始上班了，他們會感到一切正常。但是我們在歐洲的客戶，卻已經發來了電子郵件，抱怨不能連上我們的伺服器。Michael Gorsuch花了一些時間做事後分析，發現事故原因是交換機上一個簡單的設定。交換機能夠使用多種網速進行工作（每秒10M位元、100M位元或者1000M位元），你可以手動設定網速，也可以讓交換機自動選擇與所在網路相適應的網速。我們這臺交換機就設在了自動選擇檔，問題就出在這裡。通常情況下，交換機的這個設定會正常工作，但不能保證一定不出故障，1月10日的凌晨，它就發生故障了。
Michael Gorsuch其實早知道這個設定可能會引發故障，但是安裝交換機的時候，他忘了手動設定網速，所以交換機上的設定一直是出廠時的自動檔。這個設定也能正常工作，直到出了問題為止。
Michael Gorsuch並沒有因為解決了問題而感到高興，他給我寫了一封電子郵件：
我知道自從推出"FogBugz線上服務"以後，我們並沒有一個正式的SLA條款，但是我覺得應該擬定一個供內部使用（至少如此吧）。這樣我就能衡量，我自己（甚至整個系統管理團隊）是否達到了業務管理目標。我本來已經開始著手寫了，但是一直沒有完成，經過今天早上的事故後，我會盡快完成它。
SLA條款通常用"正常執行時間"來定義，所以我們需要定義"FogBugz線上服務"的"正常執行時間"到底是多少。確定以後，我們就要把它轉化成一系列政策，然後再把政策轉化成一整套的監控/報告指令碼，每隔一段時間就檢查一次，看看我們是否達到了業務管理目標。
好主意！
但是，SLA也不是包治百病的良藥，它也存在一些問題。最大的問題就是缺乏制定標準必需的統計資料，因為服務中斷的情況很少發生，所以你得不到足夠的資料，無從知道多長的執行時間才算是"正常的"。如果我沒有記錯的話，自從六個月前我們推出"FogBugz線上服務"以來，包括這一次在內，只發生了兩次服務的突然中斷。其中只有一次，是由於我們的過失而造成的。網際網路上大多數正常執行的線上服務網站，一年中只發生兩次、也許三次服務中斷。正是因為服務中斷很少發生，所以每次中斷的時間長度就開始變得真的很重要，這才是網站之間出現巨大差異的地方。突然之間，你正在談論的問題就變成了，如何才能最快地派一個人找到發生故障的裝置，然後替換掉它。為了得到非常高的正常執行時間，你等不及派人去換掉出問題的裝置，也等不及工程師去檢查哪裡出了問題，你必須事先就考慮到每一個可能出錯的地方，但是這實際上不太可能做到。能夠將你置於死地的，不是意料到的突發狀況，而是意料之外的突發狀況。
要想得到真正高的服務穩定性，成本是極其高昂的。俗稱"六個9"的服務穩定性（99.9999%的時間正常執行），意味著每年下線時間不能超過30秒。這真的有點接近荒謬了。即使有人聲稱，他們已經投資了上千萬美元，建立了超一流的大型超冗餘"六個9"系統，即使這樣，也無法排除出現嚴重故障的可能性。某一天當他們醒來的時候，我不知道是哪一天，但是會有這麼一天，他們發現一種異乎尋常的故障以一種異乎尋常的方式發生了，比如三個機房都遭到了電子脈衝EMP炸彈的襲擊，他們只能拼命捶自己的腦袋，眼睜睜看著服務中斷14天。
請這樣想，如果你的"六個9"系統由於某種神秘原因，突然下線了，然後你花了一個小時，找到了原因並將其修復，即使這樣，你也已經把直到下個世紀的服務中斷時間額度都用光了。即使是公認的最可靠系統，比如AT&T的長途電話服務，也會出現長時間的服務中斷（1991年中斷了6個小時），這意味著它們的服務穩定性只能到達一個令人羞於啟齒的"三個9"水平（99.9%的時間正常執行）......AT&T的長途電話服務被認為是"電信級"（carrier grade）的系統，是服務穩定性的黃金標準，你的系統會比它更穩定嗎？
提高服務穩定性的最大困難，就是"黑天鵝難題"（problem of black swans）。這個名詞是由Nassim Taleb提出來的（www.edge.org/3rd_culture/taleb04/taleb_indexx.html），他這樣定義："黑天鵝代表外來因素，是一個超出正常預料的事件。"幾乎所有的網際網路服務中斷，都來自於意料之外的突發事件，屬於極其小機率的非主流意外。這類事件是如此罕見，以至於常規的統計方法----比如"故障間隔平均時間"----都失效了。"請問新奧爾良市發生特大洪水的平均間隔時間是多少？"
測量出每年服務中斷的分鐘數，並無助於預測你的網站第二年會中斷服務多久。這讓我想到了今天的民用航空業。美國的全國運輸安全委員會NTSB的成就非常卓越，所有常見的飛機墜毀的原因都已經被消除了，結果就導致如今每一次發生飛機墜毀，事故的原因看來似乎都屬於非常令人意外的、獨一無二的"黑天鵝因素"。
服務穩定性有兩個極端，一個是"極端不可靠"，服務一次又一次地中斷，簡直愚蠢至極；另一個是服務穩定性"極端可靠"，你花了幾百萬美元，終於將每年的"正常執行時間"增加了一分鐘。在這兩個極端之間，存在一個服務穩定性的最佳位置，即所有被預計到的突發情況都已經事先做好了準備。你預計到硬碟可能會發生故障，就事先做好了準備，所以當硬碟真的發生故障的時候，你的服務就不會中斷。你預計到DNS伺服器可能會發生故障，就事先做好了準備，所以當DNS伺服器真的發生故障的時候，你的服務就不會中斷。但是，意料之外的突發情況，也許就會讓你的服務出現中斷。這種局面就是我們能夠期望的在兩個極端之間達到的最佳位置了。
為了達到這個最佳位置，我們借鑑了日本豐田公司創始人豐田佐吉（Sakichi Toyoda）的思想，他提出了五個為什麼。當某個地方出錯的時候，你就問為什麼，一遍遍地追問，直到你找到根本性的原因為止。然後，你就針對根本性的原因，開始著手解決問題，你要從根本上解決這個問題，而不是隻解決一些表面的症狀。
我們早就提出過"解決問題有兩種方法" ，"五個為什麼"同我們的提法很接近，所以我們就決定開始採用這種方法。下面就是Michael Gorsuch列出的思考過程：
我們與PEER 1紐約機房的連線中斷了。
為什麼？----我們交換機裡的網線介面好像不工作了。
為什麼？----與PEER 1的網路運營中心交換意見後，我們判斷這個問題很可能是由於網速/雙工模式不匹配（speed/duplex mismatch）造成的。
為什麼？----交換機的網速開關設在了自動調節檔，而沒有被手動設定在一個固定檔。
為什麼？----許多年前，我們就清楚地知道有可能發生此類故障。但是，我們始終沒有寫出一份書面的技術說明文件，用於指導和檢查交換機在生產環境中的設定。
為什麼？----我們總是很狹隘地看待技術說明文件，覺得只有在找不到系統管理員的情況下，才需要去看它，或者覺得只有運營團隊中那些不負責系統管理的成員，才需要看它。我們沒有認識到，應該把它作為技術操作的標準和確認清單。
"如果我們事先就寫好一份書面的標準操作流程，安裝完交換機後，再根據書面流程一一核對安裝步驟，這次的服務中斷事故就不會發生，" Michael Gorsuch寫道。"或者假定我們已經有了一份書面的操作流程，但是寫得不夠完整，那麼等到事故發生以後，我們就需要對這份文件進行相應的補充升級，確保類似的事故以後不再發生。"
經過幾次內部討論以後，我們所有人都同意，不為服務穩定性設定一個靜態值作為目標，那是毫無意義的。我們覺得，如果有人希望透過測量某些無意義的指標來改進工作，那肯定是沒用的。我們真正需要的是一個能夠不斷改進工作質量的流程。所以，我們決定不向我們的顧客提出一個SLA條款，而是搭建一個網誌。在這個網誌上面，我們將實時記錄每一次的服務中斷，提供完整的事後分析，詢問五個為什麼，找到根本性的原因，告訴我們的顧客為了防止類似故障再次發生，我們所採取的舉措。就拿這一次的交換機事故來說，我們採取的變化就是，在內部文件中寫入詳細的操作步驟和檢查清單。以後再在生產環境中安裝交換機的時候，所有操作步驟都必須嚴格按照檔案中寫好的步驟完成。
我們的顧客可以訪問這個網誌，看看故障的原因到底是什麼，以及我們正在怎樣改進我們的服務。我們希望，我們的顧客能夠因此增強信心，相信我們的服務品質正在穩步提高。
與此同時，如果我們的顧客感到我們的故障對他造成了影響，他就可以向我們要求補償，客服人員會給他的賬戶延長使用期限或者退款。我們讓顧客自己決定到底該補償多少，最多可以延長使用期限一個月，因為不是每個顧客都會注意到發生了服務中斷，更不要說遭受損失了。我希望我們的這些做法，能夠提高我們的服務穩定性，到達一種我們可以接受的程度，即我們的目標就是，我們遇到的所有引起服務中斷的故障，都是真正由於極其罕見的、無法預料的"黑天鵝因素"而引起的。
附言。對，我們需要再招聘一名系統管理員，以免深更半夜再發生故障的時候，只有Michael Gorsuch一個人能被叫醒。
（完）