# 定義
<a name="definitions"></a>

 本白皮書涵蓋雲端可靠性，並介紹以下四大領域的最佳實務：
+  基礎 
+  工作負載架構 
+  變更管理 
+  失敗管理 

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

**Topics**
+ [彈性和可靠性的組成部分](resiliency-and-the-components-of-reliability.md)
+ [可用性](availability.md)
+ [災難復原 (DR) 目標](disaster-recovery-dr-objectives.md)

# 彈性和可靠性的組成部分
<a name="resiliency-and-the-components-of-reliability"></a>

 雲端中的工作負載可靠性取決於數項因素，其中主要的因素是*彈性*：
+  **彈性**是工作負載在以下方面的能力：從基礎架構或服務中斷恢復、動態取得運算資源以符合需求，以及緩解中斷狀況 (例如，設定錯誤或暫時性網路問題)。

 影響工作負載可靠性的其他因素如下所述：
+  卓越營運，包括變更自動化、使用程序手冊回應失敗，以及營運準備度審查 (ORR)，以確認應用程式已準備好用於生產營運。
+  安全性，包括防止惡意動作項目損毀資料或基礎架構，進而影響可用性。例如，加密備份以確保資料安全無虞。
+  效能達成效率，包括實現工作負載最大請求率和最小延遲的設計。
+  成本最佳化，包括是否在 EC2 執行個體上投入更多資源，以實現靜態穩定性，或是否在需要更多容量時仰賴自動調整規模等方面的權衡。

 彈性是本白皮書的重點。

 其他四個方面也很重要，並都有各自的 [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 支柱白皮書說明。這裡的許多最佳實務也會處理可靠性的這些層面，但重點是在彈性上。

# 可用性
<a name="availability"></a>

 *可用性* (也稱為*服務可用性*) 既是定量衡量彈性的常用指標，也是目標彈性目標。
+  **可用性**是工作負載可供使用的時間百分比。

 *可供使用*是指工作負載在需要時成功執行其議定的功能。

 該百分比根據一段時間 (例如，一個月、一年或過去三年) 計算得出。套用最嚴格的解釋，只要應用程式無法正常運行 (包括計劃和非計劃中的中斷)，可用性就會降低。我們將*可用性*定義如下：

![\[\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/availability-formula.png)

+ 可用性是一段時間 (通常為一個月或一年) 內運行時間的百分比 (例如 99.9%) 
+  常見的簡寫僅以「九的數量」表示；例如，「五個九」可轉化為 99.999% 的可用率 
+ 一些客戶選擇從公式中的*總時間*中排除計劃的服務停機時間 (例如，計劃的維護)。不過，不建議這樣做，因為您的使用者可能想要在這些時間使用您的服務。

 下表為通用應用程式可用性設計目標及在保證仍可達到目標的情況下，一年內發生的最大中斷時長。該表格包含我們通常會在每個可用性層看到的應用程式類型範例。在本文件中，我們將引用這些值。


|  可用性  |  最高的無法使用程度 (每年)  |  應用程式類別  | 
| --- | --- | --- | 
|  99%  |  3 天 15 小時  |  批次處理、資料擷取、傳輸和載入任務  | 
|  99.9%  |  8 小時 45 分鐘  |  知識管理、專案追蹤等內部工具  | 
|  99.95%  |  4 小時 22 分鐘  |  線上商務、銷售點  | 
|  99.99%  |  52 分鐘  |  影片交付、廣播工作負載  | 
|  99.999%  |  5 分鐘  |  ATM 交易、電信工作負載  | 

**根據請求衡量可用性。**對於您的服務，計算成功和失敗的請求數可能比計算「可用時間」更容易。在此情況下，可以使用下列計算：

![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)


這通常以一分鐘或五分鐘期間進行測量。然後可以根據這些期間的平均值計算每月運行時間百分比 (時間型可用性測量)。如果在給定期間未收到任何請求，則該時間的可用率為 100%。

  

 **使用硬相依性計算可用性。**許多系統對其他系統存有硬相依性，其中相依系統中的中斷會直接轉化為調用系統的中斷。這與軟相依性相反，後者在應用程式中補償了相依系統的故障。若發生這種硬相依性，調用系統的可用性是相依系統的可用性的乘積。例如，如果您有一個設計為 99.99% 可用性的系統，並且與其他兩個設計為 99.99% 可用性的獨立系統存在硬相依性，則該工作負載理論上可以實現 99.97% 的可用性：

 Availinvok × Avail*dep1* × Avail*dep2* = Availworkload 

 99.99% × 99.99% × 99.99% = 99.97% 

 因此，在計算您自己的相依性及其可用性設計目標時，務必要對其有一定的了解。

 **使用冗餘元件計算可用性。**當系統涉及使用獨立的備援元件 (例如，不同可用區域中的備援資源) 時，理論可用性的計算方式為 100% 減去元件故障率的乘積。例如，如果系統使用兩個獨立的元件，每個元件的可用性為 99.9%，則此相依性的有效可用性為 99.9999%：

![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/image2.png)


 Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency)) 

 99.9999% = 100% − (0.1%×0.1%) 

 *捷徑計算*：如果您的計算中所有元件的可用性僅由數字 9 組成，則您可以將 9 數字的計數相加來得到您的答案。在上面範例中，兩個具有三個 9 可用性的備援獨立組件造成六個 9。

 **計算相依系統可用性。**某些相依系統提供了有關其可用性的指引，包括許多 AWS 服務的可用性設計目標。但是，在無法使用此功能的情況下 (例如，製造商未發布可用性訊息的元件)，其中一種估算方法是確定**平均故障間隔時間 (MTBF)** 和**平均復原時間 (MTTR)**。可透過以下方式確定可用性估算值：

![\[\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)


 例如，如果 MTBF 為 150 天，MTTR 為 1 小時，則可用性估算值為 99.97%。

 如需詳細資訊，請參閱 [Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)，該文件可協助您計算可用性。

 **可用性成本。**設計具有較高可用性的應用程式通常會導致成本增加，因此在著手進行應用程式設計之前，有必要識別出真正的可用性需求。對於在詳盡的失敗情境下進行測試和驗證，高可用性會實施更嚴格的要求。他們需要自動化以從各種失敗中復原，並且要求系統營運的所有方面均以相似的方式進行建置和測試，已達到相同的標準。例如，必須進行容量的新增或刪除，更新軟體或組態變更的部署或還原，或者系統資料的移轉，以達到所需的可用性目標。在非常高的可用性水平上，軟體開發成本增加了，但由於在部署系統中需要更緩慢地移動，創新將會受到影響。因此，該指南詳述了如何套用標準，以及考慮操作系統的整個生命週期中的適當可用性目標。

 在具有較高可用性設計目標的系統中，成本不斷攀升的另一種方式是選擇相依系統。在這些較高的目標下，可以選擇哪些軟體或服務作為相依系統，取決於這些服務中的哪一項具有我們前面所述的大量投資。隨著可用性設計目標的提高，通常會發現更少的多功能服務 (如關聯式資料庫) 和更多的專用服務。這是因為後者更易於評估、測試和自動化，並且可減少與包含但未使用的功能進行意外互動的可能性。

# 災難復原 (DR) 目標
<a name="disaster-recovery-dr-objectives"></a>

 除了可用性目標之外，您的彈性策略還應包括基於策略的災難復原 (DR) 目標，以在發生災難事件時復原您的工作負載。災難復原專注於回應自然災難、大規模技術故障，或攻擊或錯誤等人為威脅的一次性復原目標。這與可用性不同，其會測量一段時間內回應元件失敗、負載峰值或軟體錯誤的平均彈性。

 **復原時間點目標 (RTO)** 由組織定義。RTO 是服務中斷與恢復服務之間的最大可接受延遲。這會決定可接受的服務無法使用之時間長度。

 **復原點目標 (RPO)** 由組織定義。RPO 是自上次資料復原點之後的最大可接受時間長度。這會決定最後一個復原點與服務中斷之間可接受的資料遺失。

![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/latest/reliability-pillar/images/business-continuity.png)


*RPO (復原點目標)、RTO (復原時間點目標) 和災難事件的關係。*

 RTO 與 MTTR (平均復原時間) 相似，兩者都會測量從中斷開始到工作負載復原的這段時間。不過，MTTR 是從一段時間內的多項影響可用性事件取得的平均值，而 RTO 則是*單一*影響可用性事件允許的目標或最大值。