【51CTO專稿】 上周Amazon網絡服務停機事件一出，各大社交網站及博客平臺上的議論之聲此起彼伏，人們紛紛對此拋出自己或客觀或主觀的評價。有些議論者認為公共云服務的停機狀況應該上升到法律訴訟高度；另一些效力于其它云供應商的議論者則喜歡把這次事件當成AWS存在缺陷的有力證明。此外，還有一種聲音認為Amazon遇到的問題為用戶敲響了警鐘，今后我們應該在SLA處罰條款中將停機作為關注重點，并以談判的方式為業務流程提供停電保護。

顯然，這些反應或者是有心者蓄意歸納出的偏見、或者是議論者結合自身情況給出的建議，都沒能從此次事故出總結到正確的教訓。重要的是，議論者多數是在毫無顧忌地大放厥詞，根本沒有提供真正有用的意見或建議，更談不上拿出一套能夠替代傳統方案、真正為新時代IT事務服務的風險緩解策略。

首先我們要弄清楚“風險”這個詞到底是什么意思。根據維基百科的解釋，風險就是“未來出現損失的機率與程度”。換句話來說，我們應該通過評估問題出現的頻率與可能造成的損失來正確看待風險。當然，作為技術專家，我們還需要估算到底要投入多少人力、物力與財力才能緩解甚至最大程度避免風險。花1美元的投入、避免1000美元的損失是筆聰明賬，但花1000美元只為了保護自己免受1美元的損失則絕對是種愚蠢的念頭。

Amazon服務中斷告訴我們，故障也是可以選擇的

[[102337]]

目前用戶們所面臨的問題在于，此次停機帶來的損失是不是大到足以讓人徹底對AWS失去信心（或者說風險太大），轉而尋求其它方案的幫助。我們不能否認，在AWS平臺上運行的應用程序數不勝數，其中很多甚至與幾百萬甚至幾十億美元的巨額交易息息相關，所以每位企業客戶首先要做的就是弄清楚這個問題的答案。

在此次停機事故中，Amazon公司曾公開向用戶們發出通知，稱這只是一次有計劃的維護活動，但過程中遭遇到了內部配置文件更新失敗與程序內存泄漏等問題。結果證明，Amazon公司引以為傲的彈性塊存儲（簡稱EBS）服務可用性相當差勁。

有趣的是，上次AWS遭遇的重大停機故障同時是由EBS問題所引發，盡管兩次事故的產生原因不盡相同——上一回是人為因素所導致。在這兩次事故中，都是因為員工沒能正確配置EBS資源而衍生出的意外情況令作為后備機制的EBS無法為繼。

更有趣的是，AWS聲稱用戶沒必要對停機事故表現得太過驚訝。Amazon公司的頭號設計原則就是：任何產品都會有出問題的一天，只有把故障作為設計中的一部分，才能最大程度避免事故的發生。

很多人都對停機表現出極大憤慨，認為服務供應商應該為此承擔責任，畢竟100%（或者至少是99.999%）可用性是業界良心的份內之職。然而Amazon公司的態度非常明確——他們不會為此負責。在他們看來，如果用戶對于自己的業務可用性如此重視，就應該選擇那些愿意為服務可靠性提供嚴格承諾的供應商。換言之，用戶需要通過所謂“企業級”硬件及軟件作為依托，以此換取固若金湯的意外狀況應對能力。

無論SLA條款如何規定，“完美”的設備都不可能真正存在

盡管議論之聲四起，但我得說：這些流言所談到的解決方案早已過時，既不合理也很難持續。

首先，人們假設企業級設備的介入能夠降低停機風險。但事實上任何一種設備都有可能在緊要關頭出現紕漏。把提高可用性的希望寄托在簡單地采用“完美”設備的觀念上，其結果只能是被殘酷的現實打擊得鼻青臉腫。

資源失效是鐵一般的現實，首要方案在于如何讓用戶保護自己免受硬件故障的影響，這才是解決問題的關鍵。我認為，在談判桌上錙銖必較的策略與通過嚴懲提振士氣的做法并沒什么不同。這么做只會讓SLA條件的制定方獲得一定程度的心理滿足感，但對實際效果并不會帶來任何改善。

許多云服務供應商都針對此次AWS停機故障提出了這樣或那樣的解決方案，但在我看來這只是再一次證明了他們的無能與愚蠢。說實話，如果遇上這類情況，那幫供應商的硬件同樣支持不住。在這里我奉勸有心棒打落水狗的從業者們，Amazon的失利只能證明一點：驕兵必敗。

其次，高強度的變更控制流程事實上根本無法降低資源失效的風險。這是因為但凡涉及人機交互的工作總會帶來潛在的失誤可能，而失誤正是引發故障的根源。而且值得注意的是，AWS這兩次重大停機都跟硬件故障沒啥關系，而完全是人為因素所釀成的惡果——由于設計人員在開發之初并沒有將這類情況考慮在內，因此人為失誤一旦出現就將一發而不可收拾。就連那些ITIL（即信息技術基礎構架庫）管理經驗極為豐富的企業也很難徹底根除人為故障。

最后，大家提出的的解決方案缺乏前瞻性。每家運營良好的公司都必然會經歷IT基礎設施規劃的規模化擴展；僅僅在業務流程中考慮剛性資源需求、缺乏前瞻性眼光及對故障的認識只會令企業在發展的道路上舉步維艱甚至陷入困境。可以說沒有任何一家IT企業（或者云服務供應商）能夠負擔得起這種級別的人力（或者企業級設備）。

冗余設施與失效備援在很長一段時間內仍是最佳選擇

資源失效狀況的最佳解決方案其實早已非常成熟，這就是冗余設施與失效備援這一黃金組合。如果企業業務只需一臺服務器，咱們就設置兩臺；如果其中一臺出現故障，管理人員可以馬上將應用程序切換到第二臺當中。過去可能很多企業承擔不了如此沉重的經濟負擔，但隨著時間的推移，如今軟件與硬件成本都已經大幅降低，要為少數真正的關鍵任務應用配備冗余方案其實并不困難。

云計算的出現堪稱照世之明燈，它以輕松的方式與低廉的成本一舉搞定了冗余資源這個大問題。許多用戶都會在設計應用程序時納入彈性理念，借以應對自有資源失效并保護業務系統的可用性。其實歷史的選擇往往才是正確的選擇，面對一眾叫囂著使用傳統解決方案的議論者，云計算已經在客觀上成為企業級設備發生故障時最好的后備機制。

真正令人不安的情況在于，只有極少數停機事件中摻雜了人為因素，絕大多數故障完全是由服務失敗所引發。換句話來說，出問題的并不是某個應用所涉及的資源，而是一類服務之下所包含的大量應用程序。

在普通用戶眼中，Amazon遭遇此次重創的原因可能是沒有制定良好的運營流程、或者不舍得花錢雇傭技術高超的員工。很多人認為如果云服務供應商能夠做好這兩點，此類停機事故根本不會發生。

這種態度顯然不夠科學，即使大家的期望成為現實，各種小麻煩仍然會在陰暗的角落里醞釀滋生。云計算是一套新的計算模式——它自動化程度極高、易于擴展且功能豐富，整個行業在這位計算新寵的運營及管理方面都在摸著石頭過河。而在摸索的過程中，失誤自然是不可避免的。我所說的失誤絕不只是簡單的錯誤，它代表著特殊條件所引發的基礎設施內部的意外狀況。雖然云服務供應商已經竭盡所能、嚴防死守，但故障在很長一段時間內仍然會持續出現。

最終，一切歸于“風險”

這些或罕見或多發的服務停機到底該如何解決？根據AWS的建議，服務供應商應當采取地理區域更廣闊、部署更合理的冗余資源方案。在AWS看來，這將有效保護業務環境免受大規模突發情況的干擾。想法不錯，但問題只有一個：廣域冗余方案太過復雜也太過昂貴，相對于簡單的資源冗余措施，很少有哪家企業有能力實現這種幾乎沒有直接回報的燒錢規劃。

這就回到了我們在文章開頭提到的風險話題。請記住，風險評估的基本定義在于衡量故障發生的可能性以及由此帶來的損失。作為管理者，大家必須以理性的眼光評價這類發生頻率不高但后果嚴重的資源失效事件，同時考慮新方案的設計及運營成本。從某種意義上說，這是一道精心設計加運營與意外事故之間的成本計算題。

計算設計及運營成本當然并不困難，但很多人都無法正確估量應用程序失效所帶來的實際損失。但對于AWS來說，隨著越來越多關鍵性業務應用進入其統轄范疇，在缺乏對風險的準確預期時就輕易推出抗災措施顯然太過草率。

綜上所述，我們應該看到停機可能性并非無法估量，但合理的解決方案同樣難以設計。就連電信運營商這樣的成熟企業同樣無法做到完美無瘕，所以大家不妨以平和的心態面對云服務供應商在停機事件中應該承擔的責任。或者說回我們自己，每個人在做出決定時都很難準確認識到可能伴隨而來的連帶風險。而對于那些在停機事故之后一味指責供應商、要求完美服務，自己卻毫無可行方案的家伙，我對此深感遺憾。時至今日，云計算仍是個危險的游戲，玩與不玩取決于我們自己。正視問題、認識風險，這才是最好的處理態度。

原文標題：The Amazon Outage in Perspective: Failure Is Inevitable, So Manage Risk