減少 MTR

發現故障之後，剩餘的 MTTR 時間就是實際修復或緩解影響。要修復或減輕故障，您必須知道出了什麼問題。在此階段有兩個關鍵的指標群組可提供深入分析：1/ 影響評估指標和 2/ 作業健康度量。第一個群組會告訴您失敗期間的影響範圍，測量受影響的客戶、資源或工作負載的數量或百分比。第二組有助於確定為什麼會有影響。在發現原因之後，操作員和自動化可以回應並解決故障。如需有關這些測量結果的詳細資訊，請參閱附錄 1 — MTTD 和 MTTR 重要測量結果。

規則第 9 條

觀察性和儀器對於降低 MTTD 和 MTTR 至關重要。

故障周圍的路由

減輕影響的最快方法是透過快速故障的子系統繞過故障。此方法利用備援功能，快速將故障子系統的工作轉換為備援，以減少 MTTR。備援範圍從軟體程序、EC2 執行個體、多個 AZ 到多個區域。

備用子系統可以將 MTTR 降低到幾乎為零。恢復時間只是將工作重新路由到備用備用所需的時間。這通常以最小的延遲發生，並允許工作在定義的 SLA 內完成，從而保持系統的可用性。這會產生 MTTRs，這些 MTTRs 經歷了輕微的，甚至難以察覺的延遲，而不是長時間的無法使用。

例如，如果您的服務在應用程式負載平衡器 (ALB) 後方使用 EC2 執行個體，您可以設定運作狀態檢查，在目標標記為狀態不良之前，只需要兩次失敗的運作狀態檢查。這表示您可以在 10 秒內偵測到故障並停止將流量傳送到健康狀態不良的主機。在這種情況下，MTTR 實際上與 MTTD 相同，因為一旦檢測到故障，它也會被緩解。

這就是高可用性或持續可用性工作負載試圖實現的目標。我們希望藉由快速偵測失敗的子系統、將其標示為失敗、停止傳送流量至備援子系統，以及將流量傳送至備援子系統，藉此快速繞過工作負載中的故障。

請注意，使用這種快速故障機制會使您的工作負載對暫時性錯誤非常敏感。在提供的範例中，請確定負載平衡器健康狀態檢查只對執行個體執行淺層或生命性以及本機健康狀態檢查，而不是測試相依性或工作流程 (通常稱為深度健康狀態檢查)。這有助於避免在影響工作負載的暫時性錯誤期間不必要的執行個體更換

可觀察性和檢測子系統故障的能力對於成功繞線故障至關重要。您必須知道影響範圍，以便受影響的資源可以標記為狀態不良或失敗並退出服務，以便可以繞過這些資源。例如，如果單一 AZ 遇到部分服務損害，則您的檢測將需要能夠識別是否存在 AZ 本地化問題，以繞過該 AZ 中的所有資源，直到恢復為止。

能夠繞過故障可能還需要額外的工具，具體取決於環境。對於 ALB 後面的 EC2 執行個體使用前一個範例，假設一個 AZ 中的執行個體可能會通過本機運作狀態檢查，但隔離的 AZ 損害導致它們無法連線至其他 AZ 中的資料庫。在此情況下，負載平衡健康狀態檢查不會將這些執行個體停止服務。需要使用不同的自動化機制，才能從負載平衡器移除 AZ，或強制執行個體的健康狀態檢查失敗，這取決於識別影響範圍是 AZ。對於不使用負載平衡器的工作負載，需要使用類似的方法來防止特定 AZ 中的資源接受工作單位或完全從 AZ 移除容量。

在某些情況下，將工作轉移到冗餘子系統無法自動化，例如主要到次要資料庫的容錯移轉，其中技術不會提供自己的領導者選舉。這是AWS多區域架構的常見案例。由於這些類型的容錯移轉需要一定程度的停機時間才能完成，無法立即回復，並且將工作負載保留一段時間而不需要冗餘，因此在決策過程中擁有人力是非常重要的。

可以採用不太嚴格一致性模型的工作負載，可以使用多區域容錯移轉自動化來繞過故障路由，實現更短的 MTTR。Amazon S3 跨區域複寫或 Amazon DynamoDB 全域表等功能可透過最終一致的複寫提供多區域功能。此外，當我們考慮 CAP 定理時，使用寬鬆的一致性模型是有益的。在影響到可設定狀態子系統連線的網路故障期間，如果工作負載選擇可用性而不是一致性，它仍然可以提供非錯誤回應，也就是另一種繞過故障路由的方式。

圍繞失敗的繞線可以使用兩種不同的策略來實現。第一個策略是透過預先佈建足夠的資源來處理故障子系統的完整負載，以實作靜態穩定性。這可以是單一 EC2 執行個體，也可能是整個 AZ 容量。在失敗期間嘗試佈建新資源會增加 MTTR，並將相依性新增至復原路徑中的控制平面。但是，它需要額外付費。

第二個策略是將某些流量從故障的子系統路由到其他流量，並將剩餘容量無法處理的過量流量負載。在此降級期間，您可以擴展新資源以取代故障的容量。這種方法具有較長的 MTTR，並在控制平面上產生相依性，但在待命備用容量方面的成本更低。

返回已知良好狀態

修復期間緩解的另一種常見方法是將工作負載返回先前已知的良好狀態。如果最近的變更可能導致失敗，則復原該變更是返回先前狀態的一種方法。

在其他情況下，暫時性情況可能導致失敗，在這種情況下，重新啟動工作負載可能會減輕影響。讓我們來看看這兩種情況。

在部署期間，將 MTTD 和 MTTR 最小化取決於可觀察性和自動化。您的部署程序必須持續觀察工作負載，以提高錯誤率、延遲增加或異常情況。識別這些之後，它應該停止部署程序。

有各種各樣的部署策略，例如就地部署、藍/綠部署和滾動式部署。其中每一個都可能使用不同的機制來返回已知的良好狀態。它可以自動回復到先前的狀態，將流量轉移回藍色環境，或者需要手動介入。

CloudFormation提供了作為其創建和更新堆棧操作的一部分自動復原的功能，就像一樣AWS CodeDeploy。CodeDeploy也支援藍/綠和滾動式部署。

若要充分利用這些功能並將 MTTR 降到最低，請考慮透過這些服務自動化所有基礎結構和程式碼部署。在無法使用這些服務的案例中，請考慮使用實作 saga 模式AWS Step Functions以復原失敗的部署。

考慮重新啟動時，有幾種不同的方法。這些範圍從重新啟動服務器，最長的任務，重新啟動線程，最短的任務。這是一個表格，概述了一些重新啟動方法和要完成的近似時間（代表數量級差，這些差異並不精確）。

故障恢復機制	估計的 MTTR
啟動並設定新的虛擬伺服器	15 分鐘
重新部署軟體	10 分鐘
重啟伺服器	5 分鐘
重新啟動或啟動容器	2 秒
叫用新的無伺服器功能	一百毫秒
重啟程序	10 毫秒
重啟執行緒	10 微秒

查看表，MTTR 在使用容器和無服務器功能（如）方面有一些明顯的好處。AWS Lambda它們的 MTTR 比重新啟動虛擬機器或啟動新的虛擬機器快數量級。不過，透過軟體模組化使用故障隔離也是有益的。如果您可能導致單一處理序或執行緒失敗，則從該失敗中復原會比重新啟動容器或伺服器快得多。

作為恢復的一般方法，您可以從下移動到頂部：1/ 重新啟動，2/ 重新啟動，3/ 重新映像/重新部署，4 /替換。但是，一旦進入重新啟動步驟，繞過失敗通常是一種更快的方法（通常最多需要 3—4 分鐘）。因此，為了最快地減輕嘗試重新啟動後的影響，請繞過故障，然後在背景繼續復原程序，以將容量返回至您的工作負載。

規則第十條

專注於緩解影響，而不是解決問題。以最快的路徑回到正常操作。

故障診斷

檢測後修復過程的一部分是診斷期。這是運營商試圖確定什麼是錯誤的時間段。此程序可能涉及查詢記錄檔、檢閱作業健康狀態指標，或登入主機以進行疑難排解。所有這些操作都需要時間，因此創建工具和手冊以加快這些操作也有助於減少 MTTR。

手冊和自動化

同樣地，在您判斷錯誤的原因以及要修復工作負載的動作方式之後，操作員通常需要執行一組步驟來執行此操作。例如，在失敗之後，修復工作負載的最快方法可能是重新啟動工作負載，這可能涉及多個有序的步驟。使用可以自動執行這些步驟或向操作員提供特定方向的 runbook 將加快流程並有助於降低無意採取行動的風險。