此內容已過時。這個版本的 Well-Architected 框架現在可以在以下位置找到: https://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/reliability.html

可靠性

可靠性支柱包含工作負載如預期般正確、一致地執行其預期功能的能力,這包括在其整個生命週期中操作和測試工作負載的能力。

可靠性支柱概述了設計原則、最佳實務和相關問題。您可以在可靠性支柱白皮書中找到實作的指引。

設計原則

有 five 項雲端可靠性設計原則:

定義

有 four 個雲端可靠性最佳實務方面:

若要實現可靠性,您必須先從基礎開始,即服務配額和網路拓撲能適應工作負載的環境。分散式系統的工作負載架構在設計上必須能防止失敗並減輕失敗的影響。工作負載必須處理需求或要求的變更,且在設計上須能偵測失敗並自動進行自我修復。

最佳實務

基礎

基礎要求是其範圍超過單一工作負載或專案的要求。在建立任何系統架構之前,應確立會影響可靠性的基本要求。例如,您必須為資料中心提供足夠的網路頻寬。

藉助 AWS,這些基礎需求中的大多數已予以納入或可以按需要進行處理。設計的雲端近乎無限,因此 AWS 有責任滿足足夠的聯網和運算容量的要求,讓您可以根據需要自由變更資源大小和分配。

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

REL 1: 您如何管理服務配額和限制?
REL 2: 如何規劃您的網路拓撲?

雲端型工作負載架構會有服務配額 (也稱為服務限制)。這些配額旨在用於防止不慎佈建超過您所需的資源,並限制 API 操作上的請求率,以防止服務遭到濫用。工作負載經常存在於多個環境中。您必須監控和管理這些適用於所有工作負載環境的配額。這些環境包括多個 (可公開存取和私有的) 雲端環境,且可能包含您現有的資料中心基礎設施。計畫必須包括系統內和系統間連接、公有 IP 地址管理、私有 IP 地址管理和網域名稱解析等網路考量因素。

工作負載架構

可靠的工作負載始自於軟體和基礎設施的前期設計決策。您的架構選擇會對所有五大 Well-Architected 支柱的工作負載行為產生影響。為求可靠性,您必須依循特定模式。

藉助 AWS,工作負載開發人員可以選擇要使用的語言和技術。AWS 開發套件為 AWS 服務提供特定語言 API,讓編碼不再如此複雜。這些開發套件加上各種語言選項,可讓開發人員實作本文列出的可靠性最佳實務。開發人員也可在 The Amazon Builders' Library 中閱讀和了解 Amazon 如何建置和操作軟體。

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

REL 3: 如何設計您的工作負載服務架構?
REL 4: 如何在分散式系統中設計防止失敗的互動?
REL 5: 如何設計分散式系統中的互動以緩解或承受故障?

分散式系統倚賴通訊網路來互連元件,例如伺服器或服務。即使這些網路上的資料遺失或延遲,您的工作負載仍必須可靠運作。分散式系統的元件必須以不會對其他元件或工作負載造成負面影響的方式運作。

變更管理

必須預期並因應工作負載或其環境的變更,才能實現可靠的工作負載操作。變更包括對工作負載強加的變更,例如需求峰值,以及內部的變更,例如功能部署和安全性修補程式。

您可以使用 AWS 監控工作負載的行為,並自動化對 KPI 的回應。例如,隨著工作負載的使用者增加,您的工作負載可能會新增其他伺服器。您可以控制有權作出工作負載變更的人員,並稽核這些變更的歷史紀錄。

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

REL 6: 如何監控工作負載資源?
REL 7: 如何設計工作負載以適應需求變更?
REL 8: 您如何實作變更?

當您建立工作負載架構以根據需求的變更自動新增和刪除資源時,其不僅可以提高可靠性,而且還能確保企業成功不會成為負擔。在適當監控下,當 KPI 偏離預期規範時,您的團隊將會自動收到提醒。自動記錄對環境的變更,讓您可進行稽核並快速識別可能影響可靠性的動作。對變更管理的控制將確保您能執行交付所需可靠性的規則。

失敗管理

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

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

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

REL 9: 您如何備份資料?
REL 10: 如何使用故障隔離來保護您的工作負載?
REL 11: 如何設計工作負載以承受元件失敗?
REL 12: 如何測試可靠性?
REL 13: 您如何規劃災難復原 (DR)?

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

資源

請參閱以下資源,進一步了解我們的可靠性最佳實務:

Reliability Pillar: AWS Well-Architected
AWS Well-Architected Reliability Labs
The Amazon Builders' Library: How Amazon builds and operates software
AWS Documentation
AWS Global Infrastructure
AWS Auto Scaling: How Scaling Plans Work
Implementing Microservices on AWS
What Is AWS Backup?