故障管理

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

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

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

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

REL 10：如何使用故障隔離來保護您的工作負載？
錯誤隔離界限可將工作負載的故障影響限制在有限數量的元件內。界限外部的元件不會受到故障影響。您可以使用多個錯誤隔離界限來限制對工作負載的影響。

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

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

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

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