AWS近日披露了關于《Amazon EC2 以及 Amazon EBS 在東京區域 (AP-NORTHEAST-1) 的服務事件》的說明，以下為披露的原文，供各位參考。
針對在東京區域 (AP-NORTHEAST-1) 的服務中斷事件，我們在這里提供更多信息。從 2019 年 8 月 23 日 11:36 AM CST (中國標準時間)開始，一小部分的 EC2 服務器在東京 (AP-NORTHEAST-1) 區域中單一可用區 (Availability Zone) 由于服務器過熱造成停機。這導致在該可用區中受到影響的 EC2 實例與 EBS 卷效能降低。造成服務器過熱的原因是控制系統故障，造成受影響的可用區的部分冷卻系統失效。
受到影響的冷卻系統已經在 2:21 PM CST (中國標準時間)修復，服務器溫度也恢復到正常狀態。在溫度恢復正常后，EC2 實例的電源供應也已恢復。
在 5:30 PM CST (中國標準時間) ，大部分受影響的 EC2 實例與 EBS 卷都恢復正常工作，但仍有一小部分的實例與卷因為過熱與斷電暫時無法修復，因為底層硬件的故障，其中有些實例與卷需要更多的時間進行修復。
除了 EC2 實例與 EBS 卷受到影響外，在 12:21 PM CST (中國標準時間) EC2 RunInstances API 也受到了影響。在受影響的可用區中，嘗試啟動新的 EC2 實例和和嘗試使用 RunInstances API 的 "idempotency token" 功能 (一個允許用戶啟動新的實例時重試而不會產生多余的實例的功能)時，服務器租用，也有發生錯誤。其他沒有調用 "idempotency token"的 API 則可正常運作。
這個事件也導致透過 "idempotency token" 使用 Auto Scaling 時，無法啟動新實例。
后臺團隊已經于 1:51 PM CST (中國標準時間) 修復了 “idempotency token” 與 Auto Scaling 相關的問題。并且于 3:05 PM CST(中國標準時間)在受影響的可用區中，修復了EC2 控制面板的子系統，開啟新實例的功能已經可以正常工作。但在本事件中受到影響的卷所建立的新快照 (Snapshot) 依舊有一定的錯誤率。
本次事件是由于數據中心負責控制和優化冷卻的控制系統故障所造成，這個控制系統在多個主機都有部署以實現高可用性，本控制系統中包含了允許與風扇、冷卻器和溫度傳感器等硬件組件相互傳遞信號的第三方的程序，該程序可以直接或透過 Programmable Logic Controllers (PLC) 來與實際的硬件組件溝通。
在這事件發生前，數據中心的控制系統正在為了其中一臺失效的控制主機進行備份處理，在備份處理中，控制系統要彼此互相交換信號 (例如：冷卻裝置與溫度傳感器交換信號)以保持最新的信息。由于該第三方程序中的一個錯誤，導致控制系統與組件過度的進行信息交換而造成控制系統無法回應。
我們的數據中心被設計成一旦控制系統發生錯誤，冷卻系統就會自動進入最冷的模式，直到控制系統恢復正常為止，這樣的設計對于我們大部分的數據中心都是有效的，但有一小部分的數據中心，由于冷卻系統無法正確進入安全降溫模式，而造成系統關機。我們的數據中心加入了安全防護設計，在控制系統故障時，可以略過控制系統，直接進入凈空模式將數據中心中的熱空氣迅速排出，但控制中心的團隊在啟動凈空模式時發生了故障，所以數據中心的溫度才會持續攀升，而服務器在到達溫度上限后也開始自動關機了。由于數據中心的控制系統故障，維運團隊無法得知數據中心冷卻系統的即時信息，在進行故障排除時，團隊必須要對所有組件進行逐一的人工檢查，才能讓控制系統進入最冷模式，在這故障排除的過程中，發現控制空調組件的 PLC 控制器無法回應，控制器需要進行重置，是 PLC 控制器的錯誤造成了預設的冷卻模式與凈空模式無法正確動作，在 PLC 控制器被重置之后，該可用區數據中心的冷卻系統就可以正常工作了，而數據中心的過高的溫度也開始慢慢降低。
我們仍在與第三方供應商合作以了解導致控制系統和受影響的 PLC 無響應的錯誤和后續交互。 在此期間，我們已禁用在我們的控制系統上觸發此錯誤的故障轉移模式，以確保我們不會再次出現此問題。 我們還培訓了我們的本地運營團隊，以便在發生這種情況時快速識別和修復這種情況，并且我們相信，如果再次發生類似情況，無論什么原因，我們可以在客戶受影響之前重置系統。 最后，我們正在努力修改我們控制受影響的空氣處理單元的方式，以確保“清除模式”能夠完全繞過PLC控制器。 這是我們在最新的數據中心設計中開始使用的一種方法，即使 PLC 無響應，歐洲服務器租用，我們也會更加確信“清除模式”將起作用。
在這次事件中，EC2 實例以及 EBS 儲存在同一區域的其它的可用區沒有受到影響。同時在多個可用區上充分執行他們的應用程序的客戶，在這次的事件中依然可以維持服務可用。對于需要絕對高可用的客戶，我們持續建議您使用高可用性的架構設計。任何與應用程序相關的元件都應該采用這種容錯設計。
