河北
前幾天鬧的沸沸揚揚的阿里云的故障，今天在群里看到一篇基于故障報告的技術分析，感覺說的挺有道理，解答了一些我的疑惑，也轉過來給大家看看。
以下是全文內容：
阿里云前幾天的故障詳細報告出來了，跟很多網友猜的差不多，但也有很多細節不一樣，一起來分析一下。
首先糾正幾個錯誤，之前有很多網友分析是阿里云的AK系統出了問題，但從這份報告來看，AK本身沒出故障，是保護AK系統免受“無效AK ID攻擊”的白名單過濾機制出了問題。什么叫白名單過濾機制，就像為了防范非法用戶拿假鑰匙反復插入門鎖嘗試，門衛首先就會查驗用戶的合法性，合法后才允許其用鑰匙嘗試打開大門，這個門衛就是白名單。這本身是個保護AK的機制，這次故障的根因就是這里。
其次，影響時間并不是傳聞的3個半小時，實際是1個多小時，從17:39分發現故障到18:35就開始陸續恢復了。從影響面來看，不是所有產品都受到影響了，絕大部分在線業務，例如ECS、RDS、ACK都沒受影響，一些“全球性、大面積宕機”的說法太夸張了。部分用戶的控制臺確實無法登錄，但不影響當時他的業務可以正常服務。
特別值得指出的是，盡管網上的聲音給人的感覺是所有客戶都受到影響，但就故障的影響面而言，實際上總體的宏觀比例在10-15%之間，比如某大型電商交易平臺、某國內基金會的知名代碼托管平臺等等都正常運行，很多客戶也反映沒有受到影響，網上所謂的“1個多小時都不能用，全網不能用”并不可信。
ok，進入正題，先講下AK 是什么。阿里云的用戶要訪問云上資源，需要通過AK ID（用戶名）和AK Secret（密碼）來認證身份。出于AK服務的自身防御機制需要，AK服務每天定時生成一個白名單，ID不在白名單中的AK請求會失敗，并被網關攔截。
為何AK服務有白名單機制？為防止海量攻擊，AK服務通過數據庫對AK ID（用戶名）和AK Secret進行認證之前，有兩步預處理，第一步，判斷ID是否合乎命名規則，符合規則的進入認證環節，不符合規則的進入第二步；第二步，判斷ID是否在白名單中，如果在就進入認證環節，如果不在則直接拒絕訪問。
本次故障的問題在于：由于AK服務沒有校驗白名單的完整性，導致白名單不完整，讓大量不符合命名規則的ID在第二步直接被拒絕，沒能進入認證環節。
在整個修復過程中，阿里云工程師花了22分鐘定位了問題，6分鐘后制定方案并開始執行，28分鐘后杭州等Region恢復正常，之后又花了45分鐘全球Region恢復完畢，一共1小時41分鐘。
故障基本分析完了，這個鍋肯定得阿里云自己背，該道歉道歉，該賠償賠償。
從這次故障中，我們提出一些建議，希望阿里云重視。
首先，要降低爆炸半徑，核心必須閉環，要做到隔離和收斂，才能做到故障可控。
其次，系統要關注對異常情況的處理，當發現白名單不完整后，應果斷丟棄。
最后，從工具和系統機制上改進，要按照“數據、配置、發布”的流程，重點關注一致性和全鏈路校驗，并按Region進行灰度。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
