公有雲事故頻發，吃瓜群眾怎麼看

有人說 ，上公有雲就像租房，屋內基礎設施一應俱全，租戶拎包即可入住，不僅自由靈活，而且便宜易擴展，於是很多企業對公有雲趨之若鶩。

然而，有的租戶發現，住進去第一天，現金和銀行卡沒了，第二天，電腦飛了，第三天直接被告知「您的住所正在燃燒」……

這些租戶無辜蒙受損失，四處討說法，結果認識了很多「同道中人」——出租屋失竊遭火被水淹，大家各有各的遭遇。

公有云為何事故頻發？

重大損失背後責任歸屬如何劃分？

各供應商和租戶應該注意什麼問題？

敬請閱讀本期走進IT之解密公有雲事故現場

▼▼▼

今年，某公有雲的一個用戶向媒體「狀告」其重大損失，引爆了IT界吃瓜群眾廣的朋友圈，為什麼近年來公有雲故障的事件時有發生？今天我就以一名普通吃瓜群眾的視角，來談一談公有雲面臨的四大關鍵問題以及問題分析，以饗讀者。

吃瓜群眾如何看事故？

某公有雲廠商的故障事件大致如下：

11:57

運維人員收到倉庫Ⅰ空間使用率過高告警，準備發起搬遷擴容；

14:05

運維人員從倉庫Ⅰ選擇了一批雲盤搬遷至新倉庫Ⅱ，為了加速搬遷，手動關閉了遷移過程中的數據校驗；

20:27

搬遷完成之後，運維人員將客戶的雲盤訪問切至倉庫Ⅱ，同時為了釋放空間，對倉庫Ⅰ中的源數據發起了回收操作；

20:30

監控發現倉庫Ⅱ部分雲盤出現IO異常。

事後，復盤發現該故障緣起於單副本數據錯誤，再加上數據遷移過程中的兩次不規範的操作，導致雲盤的三副本安全機制失效，並最終導致客戶數據完整性受損。

我們知道，運維的過程實際上就是人員、流程、工具三者之間的協同過程。本事件中，CSP(內容安全策略)在人員、流程和工具三個方面都有一些細節問題值得我們去進一步推敲：

? 人的問題：通過事件復盤，我對現場工程師的評價只有一個字—急！所有的操作都是為了快，不顧風險地關閉傳輸過程校驗，不確認一致性就回收空間……可能有人覺得此工程師是不是也被無限期休假了。

這裡，我要為現場的工程師說兩句：首先，我不相信能夠進入到大公司一線運維團隊的人是碌碌無為之輩，他的經驗肯定是豐富的，他對所有動作有可能帶來的後續風險肯定也是心知肚明的。否則，該公司在用人方面就糟糕透了。那他為什麼還要犯下這種低級錯誤呢？

這個問題該問下給該工程師下達數據遷移任務的人，對該工程師提出了什麼樣的時間要求？作為管理者設定任務完成時限時，有沒有考慮到可行性和執行風險？合格的團隊在出現問題時首先應該拷問的是管理者，不能只讓幹活的人挨板子！當然，作為一線操作者，他的問題是沒有勇於說不。明顯有很大風險的不合理任務，就該直接拒絕，這才是真正的負責。

? 流程問題：流程的設計首先要保證高效，其次更要做到閉環。縱觀此次變更，雖然公開的復盤描述中未體現從事件發生到產生工單啟動變更流程的過程，但可以看出一線人員的操作許可權沒有受到任何流程管控。可不經授權直接關閉數據校驗，遷移完成後可未經一致性校驗直接回收空間。整個變更流程從始至終沒能針對數據可用性形成完整的閉環，這是運維管理團隊最大的問題。

可能有人會說互聯網時代追求的是敏態，要快速地迭代，快速地完成變更，進而才能在競爭中立於不敗之地……但我必須告訴你，敏態不等於無序。不負責任地突破底線單純追求所謂的效率，那是「亂態」，要承擔嚴重的後果的混亂狀態。人與系統之間的交互和人與人之間的交互有一個最大的共同點，你對TA負責，TA才會讓你放心。

? 工具問題：「敏態運維」的一個必要條件是依靠強大的自動化工具高效完成任務的同時，最大程度地減少人工操作過程的不可控失誤。從這個事件看，公有雲服務商缺乏有效的容量預測手段，因而只能在超出警戒值進行被動響應，而且後續的操作也多依賴人工操作。在主動式、自動化運維領域，公有雲服務商還有很大的提升空間。

簡單總結了CSP的問題後，我們還得說說租戶自身的問題。作為旁觀者，總結租戶問題時，我的心情是沉重的。真！的！很！痛！啊！但痛定思痛，我們還是要分析一下租戶自身哪些方面做得不到位，才造成了要承擔如此嚴重後果的局面。

首先，租戶最大的問題可用一句話來總結：「把所有雞蛋放在了一個籃子里」！結合前面的分析我們可以看到，CSP對租戶所申請的資源的「帶外」維護，從租戶這一側都是無感知的，租戶不知道CSP在做什麼進而無法及時採取一些應對舉措。

籃子破了雞蛋碎了，賣籃子的可能根據合同依法賠償你三倍、五倍甚至十倍的雞蛋。但你說你這籃子雞蛋要孵小雞，小雞長大後再生蛋再孵雞最後你要開養雞廠，所以讓籃子的賠你個養雞廠？沒有任何法律支持這樣的訴求。所有伺服器、存儲提供方均不會對因設備或服務故障所帶來的關聯損失進行賠償。

其次，災備！災備！災備！無論雲服務商所宣傳的服務可靠性是幾個9，這都指的是通常狀態下的數值。所謂通常狀態，就是未考慮相關的人員、環境等外圍風險因素的評估結果。即便是你把數據放在9個9可靠性的三副本的雲存儲上，它也無法保證數據的絕對安全、可靠。

多副本不能替代數據的備份保護，也不能防範災難的風險。誤操作、邏輯故障、災難事件都能帶來數據的破壞，所以自家數據的容災及備份還是要自己注意，「公有雲服務的數據安全」永遠是租戶首要考慮的。

租戶在該公有雲上的數據一直在「裸奔」， 如此重大的安全風險存在這麼長的時間都沒有人認識到且提出應對舉措，真的是太不應該了。

從公有雲事故總結的經驗教訓

教訓一：

不能把雞蛋放到一個籃子里。這是在傳統IT時代即是老生常談，雲時代也一樣。

對於大、中型企業，更適合選擇自建私有雲+公有雲的方式實現多雲（multi-cloud）架構，並在多雲環境中通過異地備份、容災手段保證數據安全性和業務連續性。

對於小企業和初創公司，可以考慮採用公有雲服務，以較低初始成本快速開展業務，但務必考慮應用和數據的保護與恢復。隨著企業規模壯大，需要再次評估「雲戰略」是否需要調整。

教訓二：

核心數據要儘可能放在自己手中。針對本次事件我們不做任何陰謀論假設，也不對其他陰謀論觀點予以評述。但任何企業都會有對自身業務極其重要的核心機密數據存在，選擇公有雲服務時需要特別考慮這些數據的安全性，因為租戶對公有雲服務商在後台對資源進行的任何操作都是無感知的。所以從防止數據泄漏的角度，核心數據應盡量選擇私有雲或自有設備進行存儲。

教訓三：

提升風險意識。所有企業在經營過程中均會面臨市場、信用、合規、法律、會計、流動性等多個方面的風險。針對可能的風險，有效識別是採取規避手段的前提，識別風險後，根據風險的財務損失等級採取相應的規避措施是至關重要的。本次數據丟失事件的發生無疑對企業的市場和財務均造成了致命的影響，如能早期識別並採取規避措施，也許今天不會那樣的「痛」。

下圖是部分公有雲服務商的SLA示例，可以看出，「數據備份」都是用戶自己的責任，這意味著如果發生數據丟失，租戶自己才是第一責任人，服務商只有「協助」義務。這裡吃瓜群眾真誠提醒各位公有雲用戶再次評估一下，運行在公有雲上的業務應用及數據的保護與恢復是否能滿足企業的要求。

打開今日頭條，查看更多圖片

企業上雲需要考慮的問題：

目前，越來越多的企業已經制定或正在制定自己的「雲戰略」，公有雲服務及私有雲、混合雲技術得到了廣泛的應用。無論您企業的「雲之旅」到了哪個階段，都請試著回答下面我們為您精心整理的問題?

如果您回答上面的問題有困難，請來諮詢戴爾易安信。我們的諮詢團隊、技術專家都可以幫您解答，隨時為您提供全方位的「雲解決方案」。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！