自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

從Amazon停機(jī)事件說起:故障不可避免 風(fēng)險(xiǎn)管理常備

譯文
系統(tǒng)
Amazon網(wǎng)絡(luò)服務(wù)停機(jī)最近鬧得沸沸揚(yáng)揚(yáng),客戶(以及作為競爭對(duì)手的其它云服務(wù)供應(yīng)商)紛紛指責(zé)Amazon店大欺客、穩(wěn)定性毫無保障。但在批評(píng)聲當(dāng)中,CIO.com網(wǎng)站專欄作家Bernard Golden卻挺身而出,認(rèn)為云計(jì)算故障不可避免,奉勸大家以平和心態(tài)對(duì)待停機(jī)事故。作為云計(jì)算的天敵,停電是每一家服務(wù)供應(yīng)商不愿看到但又無可奈何的事態(tài),但云計(jì)算自身所具有的低廉成本、易于冗余等優(yōu)勢很可能成為未來對(duì)抗停機(jī)的有力武器。

【51CTO專稿】 上周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遇到的問題為用戶敲響了警鐘,今后我們應(yīng)該在SLA處罰條款中將停機(jī)作為關(guān)注重點(diǎn),并以談判的方式為業(yè)務(wù)流程提供停電保護(hù)。

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

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

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

[[102337]]

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

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

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

更有趣的是,AWS聲稱用戶沒必要對(duì)停機(jī)事故表現(xiàn)得太過驚訝。Amazon公司的頭號(hào)設(shè)計(jì)原則就是:任何產(chǎn)品都會(huì)有出問題的一天,只有把故障作為設(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é)。在他們看來,如果用戶對(duì)于自己的業(yè)務(wù)可用性如此重視,就應(yīng)該選擇那些愿意為服務(wù)可靠性提供嚴(yán)格承諾的供應(yīng)商。換言之,用戶需要通過所謂“企業(yè)級(jí)”硬件及軟件作為依托,以此換取固若金湯的意外狀況應(yīng)對(duì)能力。

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

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

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

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

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

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

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

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

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

云計(jì)算的出現(xiàn)堪稱照世之明燈,它以輕松的方式與低廉的成本一舉搞定了冗余資源這個(gè)大問題。許多用戶都會(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ā)。換句話來說,出問題的并不是某個(gè)應(yīng)用所涉及的資源,而是一類服務(wù)之下所包含的大量應(yīng)用程序。

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

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

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

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

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

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

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

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

 

責(zé)任編輯:彭凡 來源: 51CTO.com
相關(guān)推薦

2019-05-09 14:32:13

IT中斷災(zāi)難恢復(fù)攻擊

2010-12-07 10:56:30

ARM英特爾

2013-04-11 09:21:46

PaaS平臺(tái)即服務(wù)PaaS產(chǎn)品

2022-06-09 13:40:44

加密貨幣監(jiān)管金融

2023-06-12 13:46:05

2010-12-28 10:15:03

多供應(yīng)商網(wǎng)絡(luò)網(wǎng)絡(luò)架構(gòu)

2016-01-27 15:07:33

vmware服務(wù)器虛擬化

2014-03-17 17:41:42

云計(jì)算云存儲(chǔ)

2011-09-19 11:14:32

OpenFlow網(wǎng)絡(luò)配置

2023-06-21 13:41:00

增強(qiáng)現(xiàn)實(shí)虛擬現(xiàn)實(shí)AR

2009-05-19 15:53:29

LinuxRed HatIBM

2009-11-24 09:42:00

Cisco無線路由器配

2019-10-30 14:15:41

云服務(wù)微軟Olmstead

2009-05-19 08:38:46

Redhat紅帽收購

2023-02-20 10:43:29

2017-11-20 11:53:38

CDN406錯(cuò)誤故障

2017-10-20 10:34:37

存儲(chǔ)雙活實(shí)施

2021-05-19 16:21:16

比特幣加密貨幣貨幣

2017-02-15 09:44:14

2018-06-07 12:44:47

云計(jì)算邊緣云物聯(lián)網(wǎng)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)