一次真實的服務中斷事故#
2008 年 1 月 10 日凌晨 3:30，Fog Creek 的系統管理員 Michael Gorsuch 被 Nagios 監控系統的警報驚醒——系統不正常。經過反覆排查，問題出在與 PEER 1 紐約機房的網路連接：一台交換機的網速/雙工模式不匹配（speed/duplex mismatch），導致連線中斷。
事故時間線：
- 凌晨 3:30 首次警報，連上曼哈頓機房後似乎恢復正常
- 清晨 5:00 問題再次出現，PEER 1 NOC 調查後暫時恢復
- 清晨 6:15 曼哈頓機房徹底無法連通
- Michael Gorsuch 親自前往機房，發現問題出在交換機，拔下交換機後直接連到 PEER 1 的路由器，服務恢復
SLA 的局限性#
SLA（Service Level Agreement，服務級別協議）承諾保證服務的正常運行時間。典型的 SLA 會寫「保證 99.99% 的時間正常運行」，但實際上：
- 賠償金額往往微不足道——Joel 曾因機房兩天不能訪問損失幾千美元，卻只拿到 $10 的退費
- 許多 ISP 正是因為賠償金額微不足道，才敢大膽宣稱 100% 正常運行時間
SLA 不是包治百病的良藥。最大的問題是缺乏足夠的統計資料——服務中斷太少發生，你得不到足夠的數據來判斷什麼算是「正常的」。
黑天鵝難題#
提高服務穩定性的最大困難是**「黑天鵝難題」**（problem of black swans），由 Nassim Taleb 提出：
- 黑天鵝代表意外因素——超出正常預料的突發事件
- 幾乎所有的互聯網服務中斷都來自意料之外的突發情況
- 常規的統計方法（如「故障間隔平均時間」）對此完全失效
即使是公認最可靠的系統，如 AT&T 的長途電話服務（1991 年中斷了 6 個小時），也會出現長時間的服務中斷。所謂「電信級」（carrier grade）系統，也無法完全避免黑天鵝事件。
服務穩定性的兩個極端#
- 極端不可靠：服務不斷中斷
- 極端可靠：花費數百萬美元，每年正常運行時間只增加一分鐘
最佳位置在兩者之間：預先做好所有可預計突發情況的準備。你預計到硬碟可能故障，就事先準備好備份；預計到 DNS 伺服器可能故障，就事先做好冗餘。但意料之外的突發情況仍可能讓服務中斷。
借鑑豐田的「五個為什麼」#
豐田創始人豐田佐吉（Sakichi Toyoda）提出了「五個為什麼」的思想：當某個地方出錯時，一遍遍地追問為什麼，直到找到根本性的原因，然後從根本上解決問題。
Michael Gorsuch 的思考過程：
- 為什麼？ 交換機裡的網線接口好像不工作了
- 為什麼？ 網速/雙工模式不匹配（speed/duplex mismatch）
- 為什麼？ 交換機的網速開關設在自動調節檔，而沒有被手動設置在固定檔
- 為什麼？ 我們始終沒有寫出一份書面的技術說明文檔，用於指導和檢查交換機在生產環境中的設置
- 為什麼？ 我們沒有認識到應該把技術操作的標準和確認清單作為重要文件來維護
核心改進措施：不向顧客提出 SLA 條款，而是搭建一個公開的網誌，即時記錄每一次服務中斷，提供完整的事後分析，詢問五個為什麼，找到根本性的原因，告訴顧客我們所採取的防止措施。
實際採取的行動#
- 在內部文檔中寫入詳細的操作步驟和檢查清單
- 所有生產環境中的操作必須嚴格按照書面文件中寫好的步驟完成
- 搭建公開網誌讓顧客了解故障原因與改進措施
- 讓顧客自行決定補償金額（最多延長使用期限一個月）
- 再招聘一名系統管理員，避免只有一個人能被叫醒處理故障