385
AWS S3誤操作，官方故障回顧及專家深度思考
繼Gitlab的誤刪除數據事件沒幾天，“不沉航母” AWS S3（Simple Storage Service）幾天前也“沉”了4個小時，牆外的半個互聯網也跟著掛了。如約，按AWS慣例，AWS給出了一個簡單的故障報告《Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region》。這個故障簡單來說和Gitlab一樣，也是人員誤操作。先簡單說一下這份報中說了什麼。
故障原因
簡單來說，這天，有一個AWS工程師在調查Northern Virginia (US-EAST-1) Region上S3的一個和賬務係統相關的問題，這個問題是S3的賬務係統變慢了（我估計這個故障在Amazon裏可能是Sev2級，Sev2級的故障在Amazon算是比較大的故障，需要很快解決），Oncall的開發工程師（注：Amazon的運維都是由開發工程師來幹的，所以Amazon內部嬉稱SDE-Software Developer Engineer為Someone Do Everything）想移除一個賬務係統裏的一個子係統下的一些少量的服務器（估計這些服務器上有問題，所以想移掉後重新部署），結果呢，有一條命令搞錯了，導致了移除了大量的S3的控製係統。包括兩個很重要的子係統：
-
一個是S3的對象索引服務（Index），其中存儲了S3對象的metadata和位置信息。這個服務也提供了所有的GET，LIST，PUT和DELETE請求。
-
一個是S3的位置服務係統（Placement），這個服務提供對象的存儲位置和索引服務的係統。這個係統主要是用於處理PUT新對象請求。
這就是為什麼S3不可訪問的原因。
在後麵，AWS也說明了一下故障恢複的過程，其中重點提到了這點——
雖然整個S3的是做過充分的故障設計的（注：AWS的七大Design Principle之一Design for Failure）—— 就算是最核心的組件或服務出問題了，係統也能恢複。但是，可能是在過去的日子裏S3太穩定了，所以，AWS在很長很長一段時間內都沒有重啟過S3的核心服務，而過去這幾年，S3的數據對象存儲級數級的成長（S3存了什麼樣數量級的對象，因為在Amazon工作過，所以大概知道是個什麼數量級，這裏不能說，不過，老實說，很驚人的），所以，這兩個核心服務在啟動時要重建並校驗對象索引元數據的完整性，這個過程沒想到花了這麼長的時候。而Placement服務係統依賴於Index服務，所以花了更長的時間。
了解過係統底層的技術人員應該都知道這兩個服務有多重要，簡而言之，這兩個係統就像是Unix/Linux文件係統中的inode，或是像HDFS裏的node name，如果這些元數據丟失，那麼，用戶的所有數據基本上來說就等於全丟了。
而要恢複索引係統，就像你的操作係統從異常關機後啟動，文件係統要做係統自檢那樣，硬盤越大，文件越多，這個過程就越慢。
另外，這次，AWS沒有使用像以前那樣Outage的故障名稱，用的是“Increased Error Rate”這樣的東西。我估計是沒有把所有這兩個服務刪除完，有些用戶是可以用的，有的用戶則不行了。
後續改進
在這篇故障簡報中，AWS也提到了下麵的這些改進措施——
1）改進運維操作工具。對於此次故障的運維工具，有下麵改進：
-
讓刪除服務這個操作變慢一些（筆者注：這樣錯了也可以有時間反悔，相對於一個大規模的分布式係統，這招還是很不錯的，至少在係統報警時也可以挽救）；
-
加上一個最小資源數限製的SafeGuard（筆者注：就是說，任何服務在運行時都應該有一個最小資源數，分布式集群控製係統會強行維護服務正常運行的最小的一個資源數）；
-
舉一反三，Review所有和其它的運維工具，保證他們也相關的檢查。
2）改進恢複過程。對於恢複時間過長的問題，有如下改進：
-
分解現有厚重的重要服務成更小的單元（在AWS，Service是大服務，小服務被稱之為Cell），AWS會把這幾個重要的服務重構成 Cell服務。（筆者注：這應該就是所謂的“微服務”了吧）。這樣，服務粒度變小，重啟也會快一些，而且還可以減少故障麵（原文：blast radius – 爆炸半徑）；
-
今年內完成對Index索引服務的分區計劃。
相關思考
下麵是我對這一故障的相關思考——
0）太喜歡像Gitlab和AWS這樣的故障公開了，哪怕是一個自己人為的低級錯誤。不掩蓋，不文過飾非，透明且誠懇。Cool！
1）這次事件，還好沒有丟失這麼重要的數據，不然的話，將是災難性的。
2）另外，麵對在US-EASE-1這個老牌Region上的海量的對象，而且能在幾個小時內恢複，很不容易了。
3）這個事件，再次印證了我在《關於高可用的係統》中提到的觀點：一個係統的高可用的因素很多，不僅僅隻是係統架構，更重要的是——高可用運維。
4）對於高可用的運維，平時的故障演習是很重要的。AWS平時應該沒有相應的故障演習，所以導致要麼長期不出故障，一出就出個大的讓你措手不及。這點，Facebook就好一些，他們每個季度扔個骰子，隨機關掉一個IDC一天。Netflix也有相關的Chaos Monkey，我以前在的路透每年也會做一次大規模的故障演練——災難演習。
5）AWS對於後續的改進可以看出他的技術範兒。可以看到其改進方案是用技術讓自己的係統更為的高可用。然後，對比國內的公司對於這樣的故障，基本上會是下麵這樣的畫風：
-
加上更多更為嚴格的變更和審批流程；
-
使用限製更多的權限係統和審批係統；
-
使用更多的人來幹活（一個人幹事，另一個人在旁邊看）；
-
使用更為厚重的測試和發布過程；
-
懲罰故障人，用價值觀教育工程師。
這還是我老生長談的那句話——如果你是一個技術公司，你就會更多的相信技術而不是管理。相信技術會用技術來解決問題，相信管理，那就隻會有製度、流程和價值觀來解決問題（注意：這裏我並沒有隔離技術和管理，隻是更為傾向於用技術解決問題）。
最後，你是要建一個“高可用的技術係統”，還是一個“高可用的管理係統”？歡迎留言和我們一起探討。
原文發布時間為：2017-03-05
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-16 10:02:19