可用性 - 可靠性支柱

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

可用性

可用性 (也稱為服務可用性) 既是定量衡量彈性的常用指標，也是目標彈性目標。

  • 可用性是工作負載可供使用的時間百分比。

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

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

$\text{Availability} = \ \frac{\text{Available}\ \text{for}\ \text{Use}\ \text{Time}}{\text{Total}\ \text{Time}}$

  • 可用性是一段時間 (通常為一個月或一年) 內運行時間的百分比 (例如 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.

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

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

Availinvok × Availdep1 × Availdep2 = 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.

Availeffective = AvailMAX − ((100%−Availdependency)×(100%−Availdependency))

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

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

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

$$\text{Avail}_{\text{EST}} = \frac{\text{MTBF}}{MTBF + MTTR}$$

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

如需詳細資訊，請參閱 Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS，該文件可協助您計算可用性。

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

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