結交“混世魔猴”

去年年底，Netflix技術部落格上發表了這麼一篇文章，題為“轉向亞馬遜網路服務過程中學到的五個教訓”（5Lessons We’ve Learned Using AWS）。亞馬遜網路服務（Amazon Web Services，以下簡稱AWS）無疑是所謂的“雲端運算”的傑出代表。因此，這篇文章實際上也可以看成是給任何想要轉向“雲”的網站的關鍵性建議。當然，這些建議的確很棒！下面是一條最讓我震驚的：

譯者註：Netflix是一家美國公司，在美國、加拿大等地提供互連網隨選流媒體播放，以及DVD、藍光光碟的線上租賃業務。該公司成立於1997年，總部位於加利福尼亞州的洛斯蓋圖。1999年開始訂閱服務。到2009年，該公司可提供多達10萬部DVD電影，並有1000萬的訂閱使用者。

我們時常把Netflix在AWS裡的軟體架構稱作為“藍博”。不管怎麼樣，哪怕不藉助任何外力，每個系統都要有自我實現成功的能力。我們在設計每一個分布式系統時，對我們所依賴的其他系統的容錯能力總是會充分考慮的。

譯者註：藍博（Rambo）是電影《第一滴血》裡男主角的名字，他是一個所向披靡的孤膽英雄的形象。

如果我們的推薦系統當機了，我們對客戶響應的品質肯定會下降，但我們仍然是有應必答的。雖然在這種情況下做不了個人化的推薦，但我們會把最流行的電影推薦給客戶。如果我們的搜尋系統突然慢得讓人無法忍受，但這絕對不會妨礙使用者以流媒體的方式觀看電影。

我們的工程師最早在AWS裡建立的一個系統其實是“混世魔猴”。這隻猴子的工作就是搗蛋，它要隨機殺死我們系統架構裡的組件或服務。如果我們不持續檢驗我們在失敗面前自我恢複乃至成功的能力，那這個系統很有可能就是會在關鍵時刻掉鏈子。

猛一看，你肯定覺得這條建議太瘋狂！但我們必須面對它。我不確定會有多少公司認同這樣的做法，更別說有多少公司會真的去嘗試了。如果在你工作的地方，有人部署了一個背景程式或服務，專門用於隨機殺死你的伺服器叢集裡的服務或進程，請舉手！

如果這個人還沒被你的公司解僱，請舉起你的另外一隻手！

但凡大腦正常的人，怎麼會願意去結交一隻“混世魔猴”呢？

其實，有時候你沒的選擇；“混世魔猴”會自己找上門！StackExchange網路曾經碰到過一個詭異的問題，我們也為此苦苦掙紮了幾個月。這個問題是：每隔幾天，Oregon網路中心的某台伺服器總會突然對來自外部網路的任何請求停止回應。沒有原因；毫無道理；而且必須經過緩慢的關機、重啟之後才能恢複，期間還會讓伺服器出現藍屏現象……

我們花了幾個月——真正是幾個月的時間——去追蹤這個問題。我們還把可能的原因列了很長的一個清單，一項一項去排除：

• 交換網路連接埠
• 更換網線
• 使用一個不同的路由器
• 嘗試多個版本的網路卡驅動程式
• 嘗試各種作業系統和驅動程式層級的網路設定
• 簡化我們的網路設定，並且關掉TProxy代理服務以使用更為傳統的X-FORWARDED-FOR
• 更換虛擬化軟體供應商
• 改變我們的TCP/IP主機模型
• 安裝核心升級包
• 尋求進階供應商客戶支援團隊的協助
• 其他嘗試（我現在已經忘記了，因為我現在已經從這種痛苦中解脫了）

在整個事件程序中，我們的團隊成員是如此地受挫，以致於一度幾乎要打起來。（團隊成員都是遠程工作的，怎麼“打”？我們都用Skype。你懂的……）這能怪我們嗎？每隔幾天，我們的幾台伺服器中的一台會隨機地出現當機。“混世魔猴”老是來搗亂！

不過，即使在我們最受挫的時刻，我意識到我們還是做了一些積極的改變：

• 對於一些重要的功能，以前我們只用一個伺服器，現在我們改成兩個。
• 如果某些服務沒有合理的容錯或應變方案，我們補上一個。
• 我們對系統做了全面的檢查，去掉了一些不必要的組件，直至一個足以營運我們的服務的最小集合。
• 我們採取了一些權變措施，使得我們的系統即使在我們之前認為很關鍵的服務突然失效的時候，也能永遠處於運行狀態。

時間一天一天過去，我們每周都使我們的系統更加冗餘一點點，因為我們必須這麼做。儘管整個過程很痛苦，但事實擺在面前，實際上“混世魔猴”幫了我們一個大忙，它迫使我們變得極具彈性。趕快行動起來吧！不要等明天，也不要指望將來更遠的某一天，更別說“以後再說吧”，立刻行動起來！

當你結交“混世魔猴”之後，你很快就會發現，每件事情發生的背後總是有原因的（除了那些完完全全隨機發生的事情）。“避免失敗最好的辦法就是不斷地失敗。”明白這句話的道理了吧，雖然它聽起來很瘋狂！