導讀：AWS S3 故障已經過去一週多了，我們可以從中得到哪些啟示？本文由魏佳翻譯，轉載請註明來自高可用架構 (ID: ArchNotes) 公眾號。

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

事故報告

亞馬遜 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 官方提出了未來防止這類事故的舉措，也表態採取更多的預防措施來保護客戶們的業務不受損失是十分重要且明智的。

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

本文連結：

1. https://aws.amazon.com/message/41926/
2. 本文原文 https://8thlight.com/blog/nicole-carpenter/2017/03/06/to-minimize-downtime-prepare-for-chaos.html