[點(diǎn)晴永久免費(fèi)OA]AWS 故障官方復(fù)盤報(bào)告
今天 AWS 官方發(fā)布了 10-20 日美東大故障 的事后復(fù)盤報(bào)告，細(xì)節(jié)比較豐富，算是少有的第一手資料。所以老馮把它翻譯成了中文，并附上解讀與評(píng)論，供大家參考。  Amazon DynamoDB 服務(wù)中斷總結(jié)我們希望就2025年10月19日至20日發(fā)生在美國(guó)東部弗吉尼亞北部（us-east-1）區(qū)域的服務(wù)中斷事件向您提供一些補(bǔ)充信息。此次事件始于10月19日 PDT23:48，結(jié)束于10月20日 PDT14:20。在此過(guò)程中，客戶應(yīng)用的影響大致可分為三個(gè)不同階段： 首先，10月19日23:48至10月20日02:40，Amazon DynamoDB 在美國(guó)東部（弗吉尼亞北部，us-east-1）區(qū)域的 API 錯(cuò)誤率顯著升高。 其次，10月20日05:30至14:09，網(wǎng)絡(luò)負(fù)載均衡器（Network Load Balancer，NLB）在該區(qū)域出現(xiàn)部分負(fù)載均衡實(shí)例連接錯(cuò)誤率上升的情況（源于 NLB 集群的健康檢查失?。?/span> 第三，10月20日02:25至10:36，新的 EC2 實(shí)例啟動(dòng)均告失敗；盡管從10:37開始實(shí)例啟動(dòng)逐步恢復(fù)成功，但部分新啟動(dòng)實(shí)例出現(xiàn)了網(wǎng)絡(luò)連接問題，直到13:50才完全解決。  DynamoDB2025年10月19日23:48 至 10月20日02:40期間，美國(guó)東部（弗吉尼亞北部，us-east-1）區(qū)域的 Amazon DynamoDB API 錯(cuò)誤率顯著升高。在此期間，所有依賴 DynamoDB 的客戶應(yīng)用和其他 AWS 服務(wù)都無(wú)法與該服務(wù)建立新的連接。此次故障由 DynamoDB 服務(wù)的自動(dòng)化 DNS 管理系統(tǒng)中的一個(gè)潛在缺陷所觸發(fā)，該缺陷導(dǎo)致 DynamoDB 服務(wù)端點(diǎn)的 IP 地址解析失敗。 AWS 許多大型服務(wù)都高度依賴 DNS 來(lái)實(shí)現(xiàn)無(wú)縫擴(kuò)展、故障隔離與恢復(fù)、低延遲以及數(shù)據(jù)就近訪問。例如，DynamoDB 在每個(gè)區(qū)域維護(hù)著數(shù)十萬(wàn)條 DNS 記錄，以管理該區(qū)域內(nèi)龐大且異構(gòu)的負(fù)載均衡集群。通過(guò)自動(dòng)化頻繁更新這些 DNS 記錄，可以在新擴(kuò)容資源上線時(shí)立即添加對(duì)應(yīng)記錄，正確應(yīng)對(duì)硬件故障，并高效地分配流量，優(yōu)化客戶體驗(yàn)。該自動(dòng)化系統(tǒng)針對(duì)高彈性進(jìn)行設(shè)計(jì)，使服務(wù)能夠從各種運(yùn)行問題中快速恢復(fù)。除了提供公共區(qū)域端點(diǎn)以外，該系統(tǒng)還維護(hù)了多個(gè) DynamoDB 的動(dòng)態(tài) DNS 端點(diǎn)，包括符合 FIPS 標(biāo)準(zhǔn)的專用端點(diǎn)、IPv6 專用端點(diǎn)，以及賬號(hào)級(jí)別的專屬端點(diǎn)。 此次問題的根本原因在于 DynamoDB DNS 管理系統(tǒng)中存在一個(gè)潛伏的競(jìng)態(tài)條件（race condition）。該競(jìng)態(tài)問題導(dǎo)致服務(wù)的區(qū)域端點(diǎn) (dynamodb.us-east-1.amazonaws.com) 的 DNS 記錄被錯(cuò)誤地清空，而自動(dòng)化系統(tǒng)未能及時(shí)糾正這一狀況。為解釋這一情況，我們需要先介紹 DynamoDB DNS 管理系統(tǒng)的架構(gòu)。出于高可用性的考慮，該系統(tǒng)分為兩個(gè)相互獨(dú)立的組件： ?DNS 規(guī)劃器（DNS Planner）：監(jiān)控負(fù)載均衡器的運(yùn)行狀況和容量，并定期為服務(wù)的每個(gè)端點(diǎn)創(chuàng)建新的 DNS “方案”（plan），其中包含一組負(fù)載均衡器及其權(quán)重。我們?yōu)檎麄€(gè)區(qū)域生成統(tǒng)一的 DNS 方案，因?yàn)楫?dāng)多個(gè)端點(diǎn)共享資源容量時(shí)（例如公共區(qū)域端點(diǎn)和新推出的 IPv6 端點(diǎn)），統(tǒng)一的方案極大地簡(jiǎn)化了容量管理和故障處理。?DNS 執(zhí)行器（DNS Enactor）：被設(shè)計(jì)為幾乎無(wú)依賴，以便在任何場(chǎng)景下都能獨(dú)立運(yùn)行恢復(fù)。DNS 執(zhí)行器負(fù)責(zé)將 DNS 方案應(yīng)用到 Amazon Route 53 服務(wù)中。為增強(qiáng)彈性，我們?cè)谌齻€(gè)不同的可用區(qū)（AZ）中各部署了一個(gè)完全獨(dú)立運(yùn)行的 DNS 執(zhí)行器實(shí)例。每個(gè) DNS 執(zhí)行器都會(huì)監(jiān)聽新的方案生成，并通過(guò) Route 53 事務(wù)嘗試將當(dāng)前方案替換為新方案。這種機(jī)制可確保即使有多個(gè) DNS 執(zhí)行器并發(fā)地更新同一端點(diǎn)，也能讓該端點(diǎn)應(yīng)用一致的方案。 此次競(jìng)態(tài)條件源于兩個(gè) DNS 執(zhí)行器之間一次極為罕見的交互。正常情況下，DNS 執(zhí)行器獲取最新方案后，會(huì)依次將其應(yīng)用到服務(wù)的各個(gè)端點(diǎn)上。這個(gè)過(guò)程通常非常迅速，能夠確保 DNS 狀態(tài)保持最新。在開始應(yīng)用新方案之前，DNS 執(zhí)行器會(huì)一次性檢查其即將應(yīng)用的方案是否比之前的方案更新。在遍歷端點(diǎn)列表應(yīng)用方案的過(guò)程中，如果某個(gè) DNS 執(zhí)行器在更新某端點(diǎn)時(shí)被另一執(zhí)行器暫時(shí)阻塞，它將反復(fù)重試直到成功。 在本次事件發(fā)生前夕，一臺(tái) DNS 執(zhí)行器在更新多個(gè)端點(diǎn)時(shí)遭遇了異常高的延遲，不得不對(duì)幾個(gè) DNS 端點(diǎn)進(jìn)行了多次重試。當(dāng)它以緩慢的速度逐步處理這些端點(diǎn)時(shí)，又發(fā)生了幾件事：首先，DNS 規(guī)劃器繼續(xù)運(yùn)行并生成了多代更新的方案；其次，另一臺(tái) DNS 執(zhí)行器開始應(yīng)用其中一個(gè)較新的方案，并快速地完成了對(duì)所有端點(diǎn)的更新。這一系列操作在時(shí)間上的巧合觸發(fā)了那個(gè)潛伏的競(jìng)態(tài)條件。 當(dāng)?shù)诙_(tái)（較快的）DNS 執(zhí)行器完成端點(diǎn)更新后，它啟動(dòng)了方案清理進(jìn)程，該進(jìn)程會(huì)刪除所有比剛應(yīng)用方案“陳舊得多”的舊方案。恰在此時(shí)，第一臺(tái)（較慢的）DNS 執(zhí)行器終于將其早已過(guò)期的方案應(yīng)用到了 DynamoDB 的區(qū)域主端點(diǎn)，結(jié)果把較新的方案覆蓋掉了。由于該執(zhí)行器在開始應(yīng)用時(shí)所做的新舊方案校驗(yàn)因長(zhǎng)時(shí)間延遲而變得過(guò)期無(wú)效，所以未能阻止舊方案覆蓋新方案。隨后，第二臺(tái)執(zhí)行器的清理進(jìn)程檢測(cè)到這個(gè)過(guò)期方案（相對(duì)于它剛應(yīng)用的方案已過(guò)多代），便將其刪除。隨著這一方案被刪除，該區(qū)域端點(diǎn)的所有 IP 地址也從 DNS 記錄中被移除了。而且由于活動(dòng)方案被移除，系統(tǒng)陷入不一致狀態(tài)，導(dǎo)致之后無(wú)論哪臺(tái) DNS 執(zhí)行器都無(wú)法再成功應(yīng)用新的方案。最終，我們不得不通過(guò)人工干預(yù)來(lái)糾正這一狀況。  當(dāng)上述故障于 PDT 時(shí)間10月19日23:48 出現(xiàn)后，所有通過(guò)公共端點(diǎn)連接美國(guó)東部（弗吉尼亞北部，us-east-1）區(qū)域 DynamoDB 服務(wù)的系統(tǒng)立刻遭遇 DNS 解析失敗，無(wú)法連接至 DynamoDB。這不僅影響了客戶流量，也影響了依賴 DynamoDB 的 AWS 內(nèi)部服務(wù)流量。啟用了 DynamoDB 全局表（Global Tables）的客戶雖然能夠?qū)ζ渌麉^(qū)域的副本表成功發(fā)出請(qǐng)求，但與 us-east-1 區(qū)域?qū)?yīng)副本之間出現(xiàn)了嚴(yán)重的復(fù)制延遲。相關(guān) AWS 服務(wù)的工程團(tuán)隊(duì)在事故發(fā)生后立即投入調(diào)查。到10月20日00:38，我們的工程師確認(rèn) DynamoDB 的 DNS 狀態(tài)正是這次中斷的根源。到了01:15，通過(guò)實(shí)施一系列臨時(shí)緩解措施，我們恢復(fù)了部分內(nèi)部服務(wù)對(duì) DynamoDB 的連接，并修復(fù)了關(guān)鍵的內(nèi)部工具，為后續(xù)全面恢復(fù)掃清了障礙。到02:25，所有 DynamoDB 服務(wù)的 DNS 信息均已恢復(fù)正常，全球表的所有副本也在02:32 前完成了追趕同步。隨著 DNS 緩存逐步過(guò)期，客戶在02:25至02:40之間重新能夠解析 DynamoDB 區(qū)域端點(diǎn)并建立連接。至此，與 DynamoDB 服務(wù)相關(guān)的主要中斷階段宣告結(jié)束。 Amazon EC22025年10月19日23:48 至 10月20日13:50，在美國(guó)東部（弗吉尼亞北部，us-east-1）區(qū)域內(nèi)，客戶遇到了 EC2 API 錯(cuò)誤率上升、延遲增加以及新實(shí)例啟動(dòng)失敗的情況。在整個(gè)事件持續(xù)期間，故障發(fā)生前已運(yùn)行的 EC2 實(shí)例始終保持正常，未受到影響。在02:25解決 DynamoDB DNS 問題后，客戶啟動(dòng)新 EC2 實(shí)例依然出現(xiàn)大量錯(cuò)誤?；謴?fù)工作于10月20日12:01展開，至13:50 EC2 服務(wù)全面恢復(fù)。在此期間，新的實(shí)例啟動(dòng)請(qǐng)求要么失敗并返回“請(qǐng)求超過(guò)限制”（request limit exceeded）錯(cuò)誤，要么失敗并返回“資源不足”（insufficient capacity）錯(cuò)誤。 要理解這一問題，我們需要先介紹幾個(gè)與 EC2 實(shí)例啟動(dòng)以及新實(shí)例網(wǎng)絡(luò)配置相關(guān)的內(nèi)部子系統(tǒng)。第一個(gè)子系統(tǒng)是 Droplet Workflow Manager (DWFM)，負(fù)責(zé)管理 EC2 用于承載實(shí)例的所有底層物理服務(wù)器——這些物理服務(wù)器我們稱之為 “droplet”。第二個(gè)子系統(tǒng)是 網(wǎng)絡(luò)管理器（Network Manager），負(fù)責(zé)管理網(wǎng)絡(luò)狀態(tài)并將網(wǎng)絡(luò)配置傳播至所有 EC2 實(shí)例和網(wǎng)絡(luò)設(shè)備。 每個(gè) DWFM 在每個(gè)可用區(qū)內(nèi)管理著一組 droplet，并為每個(gè) droplet 維護(hù)一個(gè)租約（lease）。通過(guò)租約，DWFM 可以跟蹤 droplet 的狀態(tài)，確保無(wú)論是由 EC2 API 發(fā)起的操作，還是由實(shí)例操作系統(tǒng)內(nèi)部觸發(fā)的關(guān)機(jī)或重啟操作，都能夠在整個(gè) EC2 系統(tǒng)中正確反映狀態(tài)變化。為了維持這些租約，每臺(tái) DWFM 主機(jī)需要每隔幾分鐘就與其管轄的每個(gè) droplet 進(jìn)行一次狀態(tài)檢查。 從10月19日23:48開始，上述 DWFM 的狀態(tài)檢查開始失敗——由于該過(guò)程依賴 DynamoDB 而 DynamoDB 當(dāng)時(shí)不可用，檢查無(wú)法完成。雖然這并未影響任何正在運(yùn)行的 EC2 實(shí)例，但對(duì)于任何涉及實(shí)例狀態(tài)變更的新操作，droplet 在執(zhí)行前必須先與 DWFM 建立新的租約。于是，在10月19日23:48至10月20日02:24這段時(shí)間內(nèi)，EC2 集群中 DWFM 與 droplet 之間的租約開始陸續(xù)因超時(shí)而失效。 02:25（DynamoDB API 恢復(fù)）之后，DWFM 開始在整個(gè) EC2 集群中重新與各 droplet 建立租約。由于任何沒有有效租約的 droplet 都不會(huì)被視為新實(shí)例啟動(dòng)的可用候選資源，因此此時(shí) EC2 API 針對(duì)新的啟動(dòng)請(qǐng)求返回“資源不足”的錯(cuò)誤。DWFM 雖然著手重新為集群中的 droplet 建立租約，但由于 droplet 數(shù)量龐大，重新建立租約所需時(shí)間過(guò)長(zhǎng)，以至于還未完成就再次超時(shí)。這使得大量重試操作排隊(duì)等待處理。此時(shí)，DWFM 陷入了一種“擁塞崩潰”（congestive collapse）的狀態(tài)，無(wú)法繼續(xù)推進(jìn)租約恢復(fù)進(jìn)程。 鑒于此前沒有針對(duì)這種情況的現(xiàn)成應(yīng)急方案，工程師在處理 DWFM 問題時(shí)格外謹(jǐn)慎。嘗試了多種緩解步驟后，團(tuán)隊(duì)于04:14采取措施：一方面限制新的任務(wù)進(jìn)入隊(duì)列（對(duì)請(qǐng)求進(jìn)行了限流），另一方面選擇性地重啟了部分 DWFM 主機(jī)。重啟操作清除了 DWFM 隊(duì)列，縮短了處理時(shí)間，并使 droplet 租約得以及時(shí)重新建立。到05:28，DWFM 已經(jīng)與 us-east-1 區(qū)域內(nèi)所有 droplet 恢復(fù)租約，新實(shí)例啟動(dòng)也再次開始成功。不過(guò)，由于我們之前實(shí)施的請(qǐng)求限流措施尚未完全解除，許多啟動(dòng)請(qǐng)求依然會(huì)遇到“請(qǐng)求超過(guò)限制”的錯(cuò)誤。 當(dāng)一個(gè)新的 EC2 實(shí)例啟動(dòng)時(shí)，一個(gè)名為網(wǎng)絡(luò)管理器（Network Manager）的系統(tǒng)會(huì)將網(wǎng)絡(luò)配置下發(fā)給該實(shí)例，以使其能夠與同一虛擬私有云（VPC）內(nèi)的其他實(shí)例、其他 VPC 的網(wǎng)絡(luò)設(shè)備以及互聯(lián)網(wǎng)進(jìn)行通信。在05:28（DWFM 恢復(fù)后不久），網(wǎng)絡(luò)管理器開始向新啟動(dòng)的實(shí)例以及事件期間曾經(jīng)終止過(guò)的實(shí)例分發(fā)更新的網(wǎng)絡(luò)配置。然而，由于之前 DWFM 故障導(dǎo)致網(wǎng)絡(luò)配置傳播事件積壓，N. Virginia 區(qū)域的網(wǎng)絡(luò)管理器累積了大量等待處理的網(wǎng)絡(luò)狀態(tài)更新。06:21起，網(wǎng)絡(luò)管理器在處理這些積壓的網(wǎng)絡(luò)更新時(shí)出現(xiàn)了顯著的延遲。盡管新的 EC2 實(shí)例可以成功啟動(dòng)，但由于網(wǎng)絡(luò)狀態(tài)傳播延遲，這些實(shí)例無(wú)法及時(shí)獲得必要的網(wǎng)絡(luò)連接。工程師通過(guò)降低網(wǎng)絡(luò)管理器的負(fù)載來(lái)縮短網(wǎng)絡(luò)配置的傳播延遲，并采取了額外措施加速恢復(fù)。到10:36，網(wǎng)絡(luò)配置傳播已恢復(fù)正常，新啟動(dòng)的 EC2 實(shí)例也重新具備了正常的網(wǎng)絡(luò)連通性。 EC2 服務(wù)恢復(fù)的最后一步是解除此前為減輕各子系統(tǒng)負(fù)載而實(shí)施的請(qǐng)求限流措施。隨著 API 調(diào)用頻率和新實(shí)例啟動(dòng)請(qǐng)求逐步恢復(fù)正常，工程師于11:23開始逐步放寬并最終移除這些限流限制。至13:50，所有 EC2 API 和新實(shí)例啟動(dòng)均恢復(fù)正常運(yùn)行。 網(wǎng)絡(luò)負(fù)載均衡器（NLB）新實(shí)例網(wǎng)絡(luò)狀態(tài)傳播延遲的問題同樣波及到了 網(wǎng)絡(luò)負(fù)載均衡器（Network Load Balancer，NLB） 服務(wù)及其他使用 NLB 的 AWS 服務(wù)。在10月20日05:30 至 14:09期間，美國(guó)東部（弗吉尼亞北部，us-east-1）區(qū)域內(nèi)部分客戶的 NLB 出現(xiàn)了連接錯(cuò)誤率上升的現(xiàn)象。NLB 基于高度可擴(kuò)展的多租戶架構(gòu)構(gòu)建，為用戶提供負(fù)載均衡訪問端點(diǎn)，并將流量路由至后端目標(biāo)（通常是 EC2 實(shí)例）。該架構(gòu)還包含一個(gè)獨(dú)立的健康檢查子系統(tǒng)，會(huì)定期對(duì) NLB 體系結(jié)構(gòu)內(nèi)的所有節(jié)點(diǎn)執(zhí)行健康檢查，并將任何被判定為不正常的節(jié)點(diǎn)移出服務(wù)。 在此次事件期間，NLB 的健康檢查子系統(tǒng)開始記錄到大量健康檢查失敗。原因在于健康檢查子系統(tǒng)將新啟動(dòng)的 EC2 實(shí)例納入服務(wù)時(shí)，這些實(shí)例的網(wǎng)絡(luò)配置尚未完全傳播。因此，即使相關(guān) NLB 節(jié)點(diǎn)和后端目標(biāo)本身是健康的，這些實(shí)例的健康檢查仍會(huì)失敗。結(jié)果就是健康檢查狀態(tài)在“失敗”和“正常”之間來(lái)回波動(dòng)：一次檢查失敗，該節(jié)點(diǎn)及其目標(biāo)就被從 DNS 中移除；下一次檢查恢復(fù)正常時(shí)，它們又被重新加入服務(wù)。 我們的監(jiān)控系統(tǒng)在06:52檢測(cè)到了這一異常，工程師隨即展開了補(bǔ)救工作。健康檢查結(jié)果的反復(fù)“閃爍”使健康檢查子系統(tǒng)負(fù)載加重，導(dǎo)致檢查延遲，并觸發(fā)了可用區(qū)級(jí)別的自動(dòng) DNS 故障切換（AZ Failover）。對(duì)于跨多個(gè)可用區(qū)部署的負(fù)載均衡器而言，這意味著部分可用區(qū)的負(fù)載均衡節(jié)點(diǎn)被判定故障而下線。如果剩余的可用容量不足以支撐應(yīng)用負(fù)載，就會(huì)出現(xiàn)客戶連接錯(cuò)誤。09:36，工程師手動(dòng)停用了 NLB 的自動(dòng)健康檢查故障切換功能，讓所有健康的 NLB 節(jié)點(diǎn)和后端目標(biāo)重新回到服務(wù)中。這一措施消除了受影響負(fù)載均衡器的連接錯(cuò)誤。在 EC2 服務(wù)完全恢復(fù)后，我們已于14:09重新啟用了 NLB 的自動(dòng) DNS 健康檢查故障切換功能。 其他 AWS 服務(wù)在10月19日23:51 至 10月20日14:15期間，us-east-1 區(qū)域的客戶在使用 AWS Lambda 函數(shù)時(shí)遇到了 API 錯(cuò)誤和延遲問題。最初，由于 DynamoDB 區(qū)域端點(diǎn)不可用，Lambda 函數(shù)的創(chuàng)建和更新請(qǐng)求無(wú)法完成，SQS/Kinesis 事件源的處理出現(xiàn)延遲并伴隨調(diào)用錯(cuò)誤。到02:24，除 SQS 隊(duì)列拉取外的 Lambda 服務(wù)功能均已恢復(fù)；SQS 隊(duì)列處理仍然受阻，是因?yàn)樨?fù)責(zé)輪詢 SQS 隊(duì)列的內(nèi)部子系統(tǒng)發(fā)生故障且未能自動(dòng)恢復(fù)。我們于04:40修復(fù)了該子系統(tǒng)，并在06:00前清理完所有消息積壓。但在07:04左右，受 NLB 健康檢查故障影響，一部分 Lambda 內(nèi)部系統(tǒng)實(shí)例被異常終止，導(dǎo)致計(jì)算容量不足。由于 EC2 實(shí)例啟動(dòng)尚未完全恢復(fù)，我們對(duì) Lambda 事件源映射和異步調(diào)用實(shí)施了限流，以優(yōu)先保障對(duì)延遲敏感的同步調(diào)用。到11:27，我們恢復(fù)了足夠的運(yùn)行容量，錯(cuò)誤率開始下降。隨后我們逐步解除限流，并于14:15之前處理完所有積壓任務(wù)，Lambda 服務(wù)恢復(fù)正常。 在10月19日23:45 至 10月20日14:20期間，美國(guó)東部（弗吉尼亞北部，us-east-1）區(qū)域的 Amazon Elastic Container Service（ECS）、Amazon Elastic Kubernetes Service（EKS）和 AWS Fargate 服務(wù)均出現(xiàn)了容器啟動(dòng)失敗和集群擴(kuò)容延遲的問題。這些服務(wù)均已于14:20恢復(fù)正常。 在10月19日23:56 至 10月20日13:20期間，使用 Amazon Connect 的客戶在處理呼叫、聊天和工單（Cases）時(shí)遇到了顯著的錯(cuò)誤提升。DynamoDB 區(qū)域端點(diǎn)恢復(fù)后，Amazon Connect 的大多數(shù)功能已經(jīng)恢復(fù)，不過(guò)客戶在05:00之前發(fā)送聊天消息時(shí)仍然會(huì)遇到錯(cuò)誤。從07:04開始，由于 NLB 故障以及 Lambda 函數(shù)執(zhí)行錯(cuò)誤，客戶在接入新來(lái)電、處理聊天、任務(wù)、郵件和工單時(shí)再次出現(xiàn)大量錯(cuò)誤。具體來(lái)說(shuō)：呼入電話的主叫方會(huì)遇到忙音、錯(cuò)誤消息或連接失敗；由座席發(fā)起的外呼電話（無(wú)論人工或通過(guò) API）均無(wú)法接通；即使已接聽的電話也可能出現(xiàn)提示音播放失敗、無(wú)法路由至座席或通話中斷等問題。此外，座席在處理聯(lián)絡(luò)時(shí)會(huì)遇到錯(cuò)誤，一些座席甚至無(wú)法登錄?？蛻粼谡{(diào)用 Connect 提供的 API 或執(zhí)行聯(lián)系搜索時(shí)同樣碰到錯(cuò)誤。實(shí)時(shí)和歷史儀表板的數(shù)據(jù)更新也出現(xiàn)延遲，數(shù)據(jù)湖的數(shù)據(jù)更新被延后，我們將在10月28日之前補(bǔ)齊所有數(shù)據(jù)。隨著 Lambda 函數(shù)調(diào)用錯(cuò)誤率的恢復(fù)下降，到13:20 Amazon Connect 服務(wù)的可用性已經(jīng)恢復(fù)。 在10月19日23:51 至 10月20日09:59期間，AWS 安全令牌服務(wù)（AWS Security Token Service，STS）在 us-east-1 區(qū)域出現(xiàn)了 API 調(diào)用錯(cuò)誤率上升和延遲增加的情況。DynamoDB 區(qū)域端點(diǎn)恢復(fù)后，STS 已于01:19恢復(fù)正常。但在08:31 至 09:59期間，受到 NLB 健康檢查故障的影響，STS API 錯(cuò)誤率和延遲再次升高。到09:59，STS 從 NLB 健康檢查故障中恢復(fù)，服務(wù)恢復(fù)正常運(yùn)行。 在10月19日23:51 至 10月20日01:25期間，通過(guò) IAM 用戶登錄 AWS 管理控制臺(tái)的客戶遇到了較高的身份驗(yàn)證失敗率，原因是弗吉尼亞北部（us-east-1）區(qū)域的 DynamoDB 故障導(dǎo)致 IAM 驗(yàn)證服務(wù)受損。將 AWS IAM 身份中心（原 AWS SSO）配置在 us-east-1 區(qū)域的客戶也無(wú)法通過(guò)身份中心完成登錄。使用 Root 用戶憑證登錄，或使用指向 signin.aws.amazon.com 的身份聯(lián)合登錄方式嘗試訪問其他區(qū)域 AWS 管理控制臺(tái)的客戶，同樣遇到了錯(cuò)誤。隨著 DynamoDB 區(qū)域端點(diǎn)在01:25重新可用，IAM 登陸服務(wù)恢復(fù)正常。 在10月19日23:47 至 10月20日02:21期間，客戶在 us-east-1 區(qū)域創(chuàng)建、修改 Amazon Redshift 集群或?qū)ΜF(xiàn)有集群執(zhí)行查詢時(shí)遇到了 API 錯(cuò)誤。Redshift 查詢處理依賴 DynamoDB 來(lái)讀寫集群的元數(shù)據(jù)。隨著 DynamoDB 區(qū)域端點(diǎn)的恢復(fù)，Redshift 查詢操作得以恢復(fù)，到02:21 時(shí)，Redshift 客戶已經(jīng)可以成功查詢集群并創(chuàng)建或修改集群配置。然而，一些 Redshift 計(jì)算集群在 DynamoDB 恢復(fù)后仍然處于受損不可用狀態(tài)。原因是：當(dāng)集群節(jié)點(diǎn)憑證過(guò)期且未被及時(shí)刷新時(shí)，Redshift 自動(dòng)化會(huì)嘗試啟動(dòng)流程，用新的 EC2 實(shí)例替換底層故障節(jié)點(diǎn)。但由于當(dāng)時(shí) EC2 實(shí)例無(wú)法啟動(dòng)，這些替換流程被阻塞，集群因此卡在“修改中”（modifying）狀態(tài)，無(wú)法處理查詢。我們的工程師在06:45采取措施，阻止替換流程隊(duì)列繼續(xù)增長(zhǎng)。當(dāng) Redshift 集群從14:46開始陸續(xù)成功啟動(dòng)新的替換實(shí)例后，積壓的替換流程也開始逐步消化。到10月21日04:05，AWS 運(yùn)維人員已完成對(duì)所有受此問題影響集群的可用性恢復(fù)。 此外，在10月19日23:47 至 10月20日01:20期間，由于 Redshift 的一個(gè)缺陷——其在解析用戶組時(shí)調(diào)用了 us-east-1 區(qū)域的 IAM API——導(dǎo)致所有 AWS 區(qū)域的 Amazon Redshift 客戶都無(wú)法使用 IAM 用戶憑證執(zhí)行查詢。在此期間 IAM 服務(wù)的故障使 Redshift 無(wú)法完成這些查詢。使用 Redshift 本地用戶憑證連接集群的客戶不受該問題影響。 其他一些依賴 DynamoDB、新 EC2 實(shí)例啟動(dòng)、Lambda 執(zhí)行和 Fargate 任務(wù)啟動(dòng)的 AWS 服務(wù)（例如 Amazon Managed Workflows for Apache Airflow、Outposts 生命周期管理操作以及 AWS Support Center 等）在 us-east-1 區(qū)域也受到了此次事件的影響。 結(jié)語(yǔ)對(duì)于此次事件給我們的客戶帶來(lái)的影響，我們深表歉意。我們?cè)诟呖捎梅?wù)運(yùn)營(yíng)方面一直保持著良好的記錄，但我們深知我們的服務(wù)對(duì)于客戶、客戶的應(yīng)用及終端用戶乃至其業(yè)務(wù)而言有多么關(guān)鍵。這次事件對(duì)許多客戶產(chǎn)生了重大影響，我們將盡最大努力從中汲取經(jīng)驗(yàn)教訓(xùn)，并以此進(jìn)一步提升服務(wù)的可用性和可靠性。 老馮評(píng)論10-20 日，AWS 出了一場(chǎng)讓人嘆為觀止的級(jí)聯(lián)雪崩故障 —— 一個(gè) DNS 服務(wù)的設(shè)計(jì)缺陷被級(jí)聯(lián)放大到影響半個(gè)互聯(lián)網(wǎng)。老馮昨天也已經(jīng) 介紹過(guò)這次事故的經(jīng)歷與影響。 這次故障是一場(chǎng)讓人嘆為觀止的級(jí)聯(lián)雪崩，一個(gè)區(qū)域內(nèi)的 DNS 服務(wù)的設(shè)計(jì)缺陷被級(jí)聯(lián)放大到影響半個(gè)互聯(lián)網(wǎng)。毫無(wú)疑問是一次架構(gòu)哲學(xué)的大失敗。接下來(lái)，讓我們一起看一下 AWS 在此次故障中的三個(gè)問題。 DNS 問題這份故障報(bào)告披露了 DNS 故障的原因 —— DNS 管理控制面的設(shè)計(jì)缺陷。其實(shí)這是一個(gè)相當(dāng)標(biāo)準(zhǔn)的數(shù)據(jù)庫(kù)事務(wù)問題，DNS 更新踩踏完全可以在元數(shù)據(jù)庫(kù)層面用事務(wù)機(jī)制來(lái)規(guī)避 —— 當(dāng)然 AWS 可能會(huì)主張他們的規(guī)模會(huì)有這樣那樣的問題沒法實(shí)現(xiàn)操作的原子性，這也就算了； 但最離譜的是，一個(gè)執(zhí)行器把另一個(gè)執(zhí)行器的計(jì)劃給清理了，另一個(gè)執(zhí)行器的合理行為是 —— 執(zhí)行計(jì)劃都沒了就別執(zhí)行了 —— 而不是直接把 DNS 解析給刪掉。然后，這個(gè) BUG 還卡住了后續(xù)的 DNS 計(jì)劃更新，導(dǎo)致最后只能依賴人工介入處理。  老實(shí)說(shuō)看到這個(gè)原因，老馮真心覺得匪夷所思：都知道 DNS 是基礎(chǔ)中的基礎(chǔ)，更新 DNS 的服務(wù)竟然會(huì)有如此低級(jí)的 BUG ？任何并發(fā)程序設(shè)計(jì)都要考慮的競(jìng)態(tài)條件處理，竟然實(shí)現(xiàn)的如此粗糙？這種失智行為讓人懷疑這些代碼到底有沒有經(jīng)過(guò)測(cè)試？是不是用 Vibe Coding 糊出來(lái)的東西？ 另一個(gè)槽點(diǎn)是幾乎是整個(gè)運(yùn)維圈都在吐槽的 —— 定位到是 DNS 的問題用了 40 分鐘，手工修復(fù)這個(gè)問題又用了 37 分鐘，最后又是 70 分鐘才恢復(fù)正常，一個(gè) DNS 故障處理總共歷時(shí) 2小時(shí) 52 分鐘，對(duì)于 AWS 這樣的云廠商來(lái)說(shuō)，這個(gè)戰(zhàn)績(jī)可謂是慘不忍睹了 —— 引用 Corey Quinn 的評(píng)論就是 —— “當(dāng)你炒掉最優(yōu)秀的工程師時(shí)，就別驚訝云廠商會(huì)忘記 DNS 是怎么工作的” 。 EC2 問題第二場(chǎng)次生故障是 EC2 Droplet 租約系統(tǒng)對(duì) DynamoDB 的高度依賴與“擁塞崩潰”。 大體上來(lái)說(shuō)，AWS 把 DynamoDB 當(dāng)作 Consul，etcd 這樣的 DCS 來(lái)用，存儲(chǔ)各種核心系統(tǒng)的云數(shù)據(jù)，比如 EC2 的租約。AWS 把物理機(jī)叫做 “Droplet” （液滴），管理這些物理機(jī)的管控組件叫做 DWFM （液滴工作流管理者）。 DWFM 需要存儲(chǔ)在 DynamoDB 里面的租約才可以執(zhí)行管理操作，但是現(xiàn)在 DynamoDB 掛了，DWFM 的租約一過(guò)期，就失去管理權(quán)限了。 據(jù)稱，這次故障并沒有影響已有 EC2 的運(yùn)行，影響的是EC2的管理操作，即管控面 。在故障的第一階段 —— DynamoDB 下線階段，EC2 表現(xiàn)為新啟動(dòng) EC2 提示 “資源不足”，因?yàn)?DWFM 都因?yàn)閬G失租約而失去權(quán)限。在故障的第二階段，DynamoDB 重新上線，大量的 DWFM 爭(zhēng)搶著去申請(qǐng)新的租約，這就直接把 DynamoDB 給打爆了。 按理說(shuō)，AWS DynamoDB 號(hào)稱可以自動(dòng)彈性伸縮，但是現(xiàn)在底下的彈性計(jì)算 EC2 管控服務(wù)又處于故障狀態(tài)，沒有辦法創(chuàng)建新的 EC2 ，于是就卡死了。 AWS 的解決辦法是不讓用戶新創(chuàng)建 EC2，然后祭出了 重啟大法。把 DWFM 分批重啟了一遍清空了重試隊(duì)列。 這個(gè)部分讓老馮非常疑惑的點(diǎn)有：重試似乎沒有指數(shù)退避擁塞控制機(jī)制？還是說(shuō)根本沒有重試前超時(shí)取消的機(jī)制？難道連個(gè)斷路器都沒有嗎？當(dāng)然，要說(shuō)最滑稽的，應(yīng)該是 —— “鑒于此前沒有針對(duì)這種情況的現(xiàn)成應(yīng)急方案，工程師在處理 DWFM 問題時(shí)格外謹(jǐn)慎。” 通常來(lái)說(shuō)，重啟大法能解決 90% 的問題，但是重啟 DWFM （都不是重啟物理機(jī)）這個(gè)決定，AWS 團(tuán)隊(duì)花了 100 分鐘才拍版決定下來(lái)。然后重啟后又花了 74 分鐘才恢復(fù)過(guò)來(lái)，這個(gè)決斷能力與擔(dān)當(dāng)實(shí)在是過(guò)于拉胯了。 NLB 故障當(dāng) EC2 開始恢復(fù)的時(shí)候，網(wǎng)絡(luò)負(fù)載均衡器 NLB 又開始出問題了。這又重新導(dǎo)致 元數(shù)據(jù)庫(kù) DynamoDB，CloudWatch 監(jiān)控，以及 Lambda 執(zhí)行引擎出現(xiàn)網(wǎng)絡(luò)連接問題。 因?yàn)榫W(wǎng)絡(luò)配置沒有及時(shí)下發(fā)，所以根據(jù) NLB 的健康檢查規(guī)則，就會(huì)將新節(jié)點(diǎn)從服務(wù)列表中移除。AWS 通過(guò)停用 NLB 的自動(dòng)健康檢查故障切換功能解決了這個(gè)問題。從 6:52 檢測(cè)到問題，到 9:36 手工停用健康檢查 —— 兩個(gè)半小時(shí)的決斷時(shí)間。 當(dāng)然，DynamoDB，EC2，NLB 的故障其實(shí)還引發(fā)了許多服務(wù)的次生故障，比如 AWS 自己的工單支持系統(tǒng)，STS，IAM，Redshift，等等等等。這里特別提一下 IAM ，之前 Google IAM 帶崩半個(gè)互聯(lián)網(wǎng)，以及 阿里云全球全局服務(wù)大故障，都與身份認(rèn)證這項(xiàng)基礎(chǔ)服務(wù)有關(guān)。而 IAM 是使用 DynamoDB 存儲(chǔ)身份認(rèn)證策略的，因此在 23:51 - 01:25 這94分鐘里是受到影響的。這里 AWS 對(duì)IAM 故障輕描淡寫一筆帶過(guò)，但其實(shí)很有可能是 DynamoDB 故障擴(kuò)散到 142 項(xiàng)服務(wù)的關(guān)鍵路徑。 老馮感想有 AWS 的客戶在事故發(fā)生后和老馮吐槽 —— 看到這個(gè)故障處理的過(guò)程，他對(duì) AWS 幻滅了，原來(lái)光鮮亮麗的云計(jì)算一哥也是草臺(tái)班子。 當(dāng)然，草臺(tái)班子也有層次之分，相比某些云廠商諱莫如深，故障后裝死，AWS 肯在故障事后公開技術(shù)細(xì)節(jié)和不足，這份坦誠(chéng)還是難能可貴的。 老馮認(rèn)為，云廠商的核心資產(chǎn)不僅是服務(wù)器和骨干網(wǎng)絡(luò)，更是經(jīng)驗(yàn)豐富的專家們。但對(duì)于云廠商來(lái)說(shuō)，這些老專家是成本中心，他們的水平?jīng)]法體現(xiàn)在財(cái)報(bào)里。因此在過(guò)去幾年的裁員中，很大一部分精英都流失了，機(jī)構(gòu)的記憶也隨之離去。留下的新人已經(jīng)不再知道老系統(tǒng)的隱秘依賴關(guān)系，再加上 “75%的代碼由 AI 生成” ，最終導(dǎo)致工程團(tuán)隊(duì)缺乏診斷復(fù)雜級(jí)聯(lián)故障的直覺，以及在危急關(guān)頭拍版決斷的能力，最終導(dǎo)致如此拉胯的響應(yīng)表現(xiàn)。
老馮覺得，規(guī)模帶來(lái)的復(fù)雜度已經(jīng)開始反噬云廠商了?？v觀最近幾年的云故障，因?yàn)闄C(jī)房起火斷電之類不可抗力事件的并不多，反而那些超大規(guī)模故障幾乎都是因?yàn)楣芸剀浖毕荩藶榕渲貌僮魇М?dāng)導(dǎo)致的。 額外復(fù)雜度是架構(gòu)設(shè)計(jì)中的大敵，有時(shí)候，簡(jiǎn)簡(jiǎn)單單在數(shù)據(jù)中心里租倆機(jī)柜，跑幾套數(shù)據(jù)庫(kù) + Docker 跑跑應(yīng)用這種經(jīng)典的架構(gòu)，異地對(duì)象存儲(chǔ)備份一下，足夠絕大多數(shù)企業(yè)一路干到 IPO 了。如果你的問題本質(zhì)復(fù)雜度如果沒有 Amazon Google 的規(guī)模，卻非要使用他們的基礎(chǔ)架構(gòu) —— 那么成本可不僅是高昂的云上財(cái)務(wù)開銷，還有架構(gòu)復(fù)雜度帶來(lái)的風(fēng)險(xiǎn) —— 而這幾次大故障毫無(wú)疑問的證實(shí)了這一點(diǎn)。 當(dāng)一家云廠商內(nèi)部的一條 DNS 記錄損壞，就能讓全球數(shù)千萬(wàn)用戶的生活陷入混亂； 當(dāng)一個(gè)區(qū)域的數(shù)據(jù)中心網(wǎng)絡(luò)故障，能讓遍布五大洲的企業(yè)同時(shí)癱瘓，老馮覺得：云計(jì)算在帶來(lái)便利的同時(shí)，也創(chuàng)造了前所未有的系統(tǒng)性風(fēng)險(xiǎn)。 而這可不是互聯(lián)網(wǎng)誕生的初衷！ 要想解決這個(gè)問題，也許最后還是需要監(jiān)管介入。像當(dāng)年 FCC 拆分 AT&T 一樣，拆分幾大云廠商。公有 IaaS 硬件層成為類似電網(wǎng)，通信的公共基礎(chǔ)設(shè)施接受強(qiáng)監(jiān)管。而上面的 PaaS ，SaaS 軟件層則由無(wú)數(shù)供應(yīng)商與創(chuàng)業(yè)公司百花齊放。 References
閱讀原文：https://mp.weixin.qq.com/s/csopt3H5ZSh60vvcO-28hQ 該文章在 2025/10/24 10:02:19 編輯過(guò) |
關(guān)鍵字查詢
相關(guān)文章
正在查詢... 
|
400 186 1886
