本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 減少 MTTR
<a name="reducing-mttr"></a>

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

**規則第 9 條**  
可觀測性和儀器儀表對於減少MTTD和MTTR.

## 故障周圍的路由
<a name="route-around-failure"></a>

 減輕影響的最快方法是透過快速故障的子系統繞過故障。這種方法會將故障子系統的工作快速轉移至備援，MTTR藉此減少備援。備援範圍包括軟體程序、EC2執行個體、多個區域AZs，以及多個區域。

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

 例如，如果您的服務使用 Application Load Balancer (ALB) 後面的EC2執行個體，您可以設定健全狀況檢查的間隔 (最少 5 秒)，而且只需要兩次失敗的健康狀態檢查，才能將目標標示為狀態不良。這表示您可以在 10 秒內偵測到故障並停止將流量傳送到健康狀態不良的主機。在這種情況下MTTR，實際上與相同，MTTD因為一旦檢測到故障，它也會被緩解。

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

 請注意，使用這種快速故障機制會使您的工作負載對暫時性錯誤非常敏感。在提供的範例中，請確定負載平衡器健康狀態檢查只對執行個[https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/)健康狀態檢查，而不是測試相依性或工作流程 (通常稱為*深度*健康狀態檢查)。這有助於避免在影響工作負載的暫時性錯誤期間不必要的執行個體更換 

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

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

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

 使用多區域容錯移轉自動化繞過故障的路MTTRs由，可以採用較不嚴格的一致性模型的工作負載縮短。[Amazon S3 跨區域複寫或 Amazon DynamoDB 全域](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)[表](https://aws.amazon.com/dynamodb/global-tables/)等功能可透過最終一致的複寫提供多區域功能。此外，當我們考慮CAP定理時，使用寬鬆的一致性模型是有益的。在影響到可設定狀態子系統連線的網路故障期間，如果工作負載選擇可用性而不是一致性，它仍然可以提供非錯誤回應，也就是另一種繞過故障路由的方式。

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

 第二個策略是將某些流量從故障的子系統路由到其他[流量，並將剩餘容量無法處理的過量流量負載](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)。在此降級期間，您可以擴展新資源以取代故障的容量。這種方法具有更長的時間，MTTR並在控制平面上產生依賴性，但在待機，備用容量方面的成本更低。

## 返回已知良好狀態
<a name="return-to-a-known-good-state"></a>

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

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

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

 有各種各樣的[部署策略](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html)，例如就地部署、藍/綠部署和滾動式部署。其中每一個都可能使用不同的機制來返回已知的良好狀態。它可以自動回復到先前的狀態，將流量轉移回藍色環境，或者需要手動介入。

 CloudFormation [提供了作為其創建和更新堆棧操作的一部分自動復原的功能](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html)，就像一樣[AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks)。 CodeDeploy 也支援藍/綠和滾動式部署。

 若要充分利用這些功能並將您的功能降到最低MTTR，請考慮透過這些服務自動化所有基礎結構和程式碼部署。在無法使用這些服務的案例中，請考慮使用實作 [saga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) AWS Step Functions 以復原失敗的部署。

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

 


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

 查看表格，使用容器和無伺服器功能（如 [AWS Lambda](https://aws.amazon.com/lambda/)）有一些明顯的好處。MTTR它們MTTR的速度比重新啟動虛擬機器或啟動新的虛擬機器快。不過，透過軟體模組化使用故障隔離也是有益的。如果您可能導致單一處理序或執行緒失敗，則從該失敗中復原會比重新啟動容器或伺服器快得多。

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

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

## 故障診斷
<a name="failure-diagnosis"></a>

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

## 手冊和自動化
<a name="runbooks-and-automation"></a>

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