# 故障管理
<a name="rel-failmgmt"></a>

 在任何合理複雜的系統中，均有可能會發生失敗。為達可靠性要求，您的工作負載應在發生失敗時察覺此情況，並採取行動以免影響可用性。工作負載必須能夠承受失敗並自動修復問題。

 藉助 AWS，您可以利用自動化對監控資料作出反應。例如，當特定指標超過閾值時，您可以啟動可修補問題的自動化動作。此外，您無需嘗試診斷和修正生產環境中的失敗資源，而是可以用新的資源取代它，並對失敗的頻外資源執行分析。由於雲端可讓您以低成本建立整個系統的臨時版本，因此您可以使用自動化測試來驗證完整的復原程序。

 下列問題著重於可靠性方面的這些考量。


| REL 9：您如何備份資料？ | 
| --- | 
| 備份資料、應用程式和組態以满足您對復原時間點目標 (RTO) 和復原點目標 (RPO) 的要求。 | 


| REL 10：如何使用故障隔離來保護您的工作負載？ | 
| --- | 
| 故障隔離會將元件或系統故障的影響侷限在定義的界限內。藉由適當的隔離，界限外部的元件就不會受到故障影響。只要能跨多個故障隔離界限執行工作負載，就可更靈活地應對故障。 | 


| REL 11：如何設計工作負載以承受元件失敗？ | 
| --- | 
| 須架構具高可用性和低平均復原時間 (MTTR) 需求的工作負載以實現彈性。 | 


| REL 12：如何測試可靠性？ | 
| --- | 
| 在將工作負載設計為可彈性應對生產壓力之後，進行測試是確認其依設計運作並提供預期之彈性的唯一方法。 | 


| REL 13：您如何規劃災難復原 (DR)？ | 
| --- | 
| 備妥備份和冗餘工作負載元件是 DR 策略的開始。[RTO 和 RPO](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 是您還原工作負載的目標。根據業務需求設定這些目標。實作策略以滿足這些目標，考量工作負載資源和資料的位置和功能。發生中斷的可能性和復原成本也是重要因素，可反映為工作負載提供災難復原的商業價值。 | 

 定期備份資料並測試備份檔案，從而確認您可以從邏輯和實際錯誤復原。管理失敗的關鍵是對導致失敗的工作負載頻繁進行自動化測試，然後觀察其可如何復原。定期執行此操作，並確認在出現重大工作負載變更後也能啟動此類測試。主動追蹤 KPI、復原時間點目標 (RTO) 和復原點目標 (RPO)，以評估工作負載的彈性 (尤其是在失敗測試情境下)。追蹤 KPI 將能助您識別和減輕單一失敗點。其目標是徹底測試您的工作負載復原程序，以便您確信即使面對持續問題，您也可以復原所有資料並繼續為客戶提供服務。應與執行正常生產程序一樣執行復原程序。