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

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

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

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

[[102337]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最終，一切歸于“風險”

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

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

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

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

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