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

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

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

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

[[102337]]

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

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

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

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

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

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

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

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

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

許多云服務(wù)供應(yīng)商都針對(duì)此次AWS停機(jī)故障提出了這樣或那樣的解決方案，但在我看來(lái)這只是再一次證明了他們的無(wú)能與愚蠢。說(shuō)實(shí)話(huà)，如果遇上這類(lèi)情況，那幫供應(yīng)商的硬件同樣支持不住。在這里我奉勸有心棒打落水狗的從業(yè)者們，Amazon的失利只能證明一點(diǎn)：驕兵必?cái)　?/p>

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

最后，大家提出的的解決方案缺乏前瞻性。每家運(yùn)營(yíng)良好的公司都必然會(huì)經(jīng)歷IT基礎(chǔ)設(shè)施規(guī)劃的規(guī)?；瘮U(kuò)展；僅僅在業(yè)務(wù)流程中考慮剛性資源需求、缺乏前瞻性眼光及對(duì)故障的認(rèn)識(shí)只會(huì)令企業(yè)在發(fā)展的道路上舉步維艱甚至陷入困境?？梢哉f(shuō)沒(méi)有任何一家IT企業(yè)（或者云服務(wù)供應(yīng)商）能夠負(fù)擔(dān)得起這種級(jí)別的人力（或者企業(yè)級(jí)設(shè)備）。

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

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

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

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

在普通用戶(hù)眼中，Amazon遭遇此次重創(chuàng)的原因可能是沒(méi)有制定良好的運(yùn)營(yíng)流程、或者不舍得花錢(qián)雇傭技術(shù)高超的員工。很多人認(rèn)為如果云服務(wù)供應(yīng)商能夠做好這兩點(diǎn)，此類(lèi)停機(jī)事故根本不會(huì)發(fā)生。

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

最終，一切歸于“風(fēng)險(xiǎn)”

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

這就回到了我們?cè)谖恼麻_(kāi)頭提到的風(fēng)險(xiǎn)話(huà)題。請(qǐng)記住，風(fēng)險(xiǎn)評(píng)估的基本定義在于衡量故障發(fā)生的可能性以及由此帶來(lái)的損失。作為管理者，大家必須以理性的眼光評(píng)價(jià)這類(lèi)發(fā)生頻率不高但后果嚴(yán)重的資源失效事件，同時(shí)考慮新方案的設(shè)計(jì)及運(yùn)營(yíng)成本。從某種意義上說(shuō)，這是一道精心設(shè)計(jì)加運(yùn)營(yíng)與意外事故之間的成本計(jì)算題。

計(jì)算設(shè)計(jì)及運(yùn)營(yíng)成本當(dāng)然并不困難，但很多人都無(wú)法正確估量應(yīng)用程序失效所帶來(lái)的實(shí)際損失。但對(duì)于AWS來(lái)說(shuō)，隨著越來(lái)越多關(guān)鍵性業(yè)務(wù)應(yīng)用進(jìn)入其統(tǒng)轄范疇，在缺乏對(duì)風(fēng)險(xiǎn)的準(zhǔn)確預(yù)期時(shí)就輕易推出抗災(zāi)措施顯然太過(guò)草率。

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

原文標(biāo)題：The Amazon Outage in Perspective: Failure Is Inevitable, So Manage Risk