[[185395]]

如今 2017 年，云是重要業務技術選型的***選擇。使用云也為管理基礎設施帶來了很多益處，包括提升靈活性、可擴展性，同時降低了 IT 成本。但是上周我們目睹了 AWS S3 停機故障 ，看來即使是最可靠的服務提供商也可能遇到倒霉的一天。 服務不可用直接導致了數百萬的收入損失，以及難以估量的公司品牌負面影響。盡管如此，你依然可以采取一些預防措施來減少這種事件的負面影響。

事故報告

亞馬遜 Web 服務(AWS)是當今被廣泛使用的的云基礎設施服務，占據全球40%以上的市場份額。一直以來 AWS 的服務質量都高于其服務質量協議(SLA) ，達到99.9%的正常運行時間。但是上周發生的 AWS 簡單對象存儲服務(S3)故障說明沒有什么服務是***無懈可擊的。

在星期二上午 11:30 左右，AWS 美國東一區(US-EAST-1)的 S3 存儲服務宕機，并且迅速產生了巨大的影響。 服務恢復后，AWS 發布了一個聲明，有意思的是，我們從官方聲明中發現，這次故障既不是人為破壞的，也是不是系統損壞的原因，而僅僅是由簡單的錯誤輸入命令導致。 難以置信吧?但確實是，一個完全無意的命令輸入錯誤 [1]，這導致像 Adobe，Slack，Expedia，甚至是美國證券交易委員會，都遭受了嚴重的性能影響，據悉還有小的在線電商網站因此被拖垮。

目前很難準確估量在這將近 5 個小時的宕機過程中造成的財產損失，但據不完全統計，已經造成了數千萬的財產損失，數十萬的用戶受到影響。

事故真相

整個事故過程中，雖然許多依賴美國東一區 S3 服務的公司在宕機期間受到嚴重影響，但仍然有一些公司部分或全部業務毫不受影響。 這是為什么? 有幾個因素發揮作用。

隱藏的依賴

S3 服務已經成為大多數基于云的分布式系統中至關重要的組件。正因為其被廣泛使用，同時大量復雜的服務或系統構建在它之上，所以當 S3 服務不可用時加劇了事故影響范圍和深度。對于那些直接或間接依賴(S3 服務) 的系統，S3 服務都會成為潛在的影響因素。

網絡性能監控公司 Thousand Eyes 歸納了 3 種可能被所依賴的 S3 服務影響的表現形式：

• 如果一個公司的靜態網頁直接或單獨托管在宕機的 S3 服務器上，那么將變得完全不可用。很不幸，Lululemon Athletica Inc 是這類公司之一。
• 如果頁面中的某些元素(腳本、資源)直接或間接依賴于 S3 服務，則會發生部分失效。比如Slack，事故造成它的文件上傳功能變得不可用。
• 應用程序的關鍵服務可能依賴于受影響的 S3 或其他 AWS 服務，這將導致應用部分或完全無法使用。8th Light 的創始人之一介紹了他對 AWS Lambda 功能的使用，通過它可以實現 rate limit 功能以限制用戶惡意請求，但在宕機期間它變得無法使用，因為該功能依賴 S3 服務。***他給出了一條建議：“清楚的認識你依賴的依賴。“

滑稽的是，事故剛開始發生時，AWS 無法將 S3 服務狀態更新到儀表板上，因為它也依賴于 S3 來存儲。這意味著出現故障的服務在宕機期間顯示為正常?!這就是我們說的隱藏的依賴!

這里我們強調的是要知道風險在哪里，并做有針對性得規劃。 將每個遠程依賴關系都看作是潛在的故障點這會有所幫助，特別是以這次 AWS 事故為例，對遠程依賴關系的分析首先將會幫你反思是否真的有依賴的必要。

裝滿雞蛋的籃子

AWS 的數據中心(zone)遍布全球 16 個不同的國家地區。在美國，有四個地區：北弗吉尼亞州、俄亥俄州、俄勒岡州和北加利福尼亞州，剩下的則分布在歐洲、亞洲、南美洲和澳大利亞。

在 AWS 上部署/使用服務時，可以選擇要部署到哪個獨立區域。顯而易見，通過跨地區、或者跨云服務提供商來創造冗余，將提供最健壯的業務連續性。在這次事故中，只有一個區(美國東一區)受到影響，但對那些資源/服務/依賴集中在這個區的公司來說，這便成他們的噩夢。

為故障而設計

前面提到，一些公司在這次事故中損失較小。這是因為他們部署服務時，帶著某一天某些事會出錯的預期，從而更有針對性得做準備。

雖然 AWS 正在處理此次事故的后續事宜，但是亞馬遜的零售部門(amazon.com)，盡管依賴 S3，但在事故期間并沒有受多大影響。誠然，亞馬遜在任何時候都會采取所有必要和建議的預防措施，以確保其旗艦產品的健壯。

如何為故障做規劃和預防，我們可以參考 Netflix。他們內部使用一套被稱為猴子軍團(Simian Army)的云測試工具，這些工具專門用于模擬系統上的破壞，以便捕獲可能導致服務中斷或性能問題的任何潛在故障點。通過規劃一系列可能遇到的小問題和大問題，Netflix 能夠預測他們系統面對問題時反應，并依此建立各種保護措施，以確保系統在故障期間依然可以提供服務。

應對故障的準備措施不應采取”一刀切“的方法。亞馬遜和 Netflix 都擁有海量的數據、數億用戶，他們的預防措施和解決方案可能有很大不同。在決定如何防止第三方故障時，應考慮諸如數據容量，針對不同情況進行防護的性價比，以及計算損失風險等因素。

對于較小的規模，解決方案可能不是完全預防，而是如何優雅的降級。這意味著需要對應用中各個功能進行不同優先級的容錯。例如網絡故障時，對于需要遠程訪問的資源降級成從本地文件/緩存中獲取。

S3事故也暴露了網絡架構設計的缺陷，AWS 官方提出了未來防止這類事故的舉措，也表態采取更多的預防措施來保護客戶們的業務不受損失是十分重要且明智的。

好了，上星期我們學到了“一個錯誤輸入可以使得一部分互聯網不可用”，現在我們學到了更好更充分的準備和預防，可以***程度減少故障再次發生時的損害和影響。