本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
增加 MTBF
提高可用性的最終組成部分是增加 MTBF。這可以適用於軟件以及用於運行它的AWS服務。
增加分散式系統 MTBF
增加 MTBF 的一種方法是減少軟件中的缺陷。有幾種方式可以執行此作業。客戶可以使用 Amazon CodeGuru 審核
部署較小的變更也可降低變更的複雜性，協助防止意外結果。每個活動都提供了一個機會，以識別和修復缺陷之前，它們可以被調用。
防止故障的另一種方法是定期測試。實作混沌工程計畫可協助測試工作負載失敗的情況、驗證復原程序，以及協助在生產環境中發生之前尋找和修正失敗模式。客戶可以使用AWS故障注入模擬器
容錯是防止分散式系統故障的另一種方法。快速故障模組、具有指數輪詢和抖動的重試、交易和冪等都是協助讓工作負載容錯的技術。
交易是一組堅持 ACID 屬性的操作。如下所示：
-
原子性-無論是所有的行動發生或者都不會發生。
-
一致性 — 每個交易都會使工作負載保持有效狀態。
-
隔離 — 同時執行的交易會使工作負載保持與按順序執行相同的狀態。
-
耐久性 — 一旦交易認可，即使在工作負載失敗的情況下，也會保留其所有效果。
透過指數輪詢和抖動
如果我們考慮一個 Heisenbug 對容錯硬件配置的影響，我們會相當不關心，因為 Hisenbug 出現在主要和冗餘子系統上的概率是無限小的。（見吉姆·格雷，「為什麼計算機停止，可以做些什麼？
當調用 Hisenbug 時，軟件必須快速檢測到不正確的操作並失敗，以便再次嘗試。這是通過防禦性編程來實現的，並驗證輸入，中間結果和輸出。此外，處理序會被隔離，並且不會與其他程序共用任何狀態。
這種模組化方法可確保故障期間的影響範圍受到限制。程序獨立失敗。當一個進程確實失敗時，軟件應該使用「進程對」來重試工作，這意味著一個新的進程可以承擔一個失敗的工作。為了保持工作負載的可靠性和完整性，每個操作都應被視為 ACID 事務。
這可讓處理程序失敗，而不會中斷交易並復原所做的任何變更，而不會損毀工作負載的狀態。這可讓復原程序從已知良好狀態重試交易，並正常重新啟動。這就是軟件對海森錯誤的方式。
但是，您不應該旨在使軟件對 Bohrbug 進行容錯。在工作負載進入生產環境之前，必須先找到並移除這些瑕疵，因為沒有任何等級的備援能夠達到正確的結果 （見吉姆·格雷，「為什麼計算機停止，可以做些什麼？
增加 MTBF 的最後方法是減少故障造成的影響範圍。透過模組化使用故障隔離來建立容錯容器，是先前在容錯和容錯隔離中所述的主要方式。降低故障率可提高可用性。 AWS使用諸如將服務劃分為控制平面和資料平面、可用區域獨立性
例如，讓我們回顧一個案例，即工作負載將客戶置於其基礎架構的不同容器中，該容器最多為總客戶總數的 5% 提供服務。其中一個故障容器遇到的事件會增加延遲超過 10% 的要求的用戶端逾時。在此活動期間，對於 95％ 的客戶，該服務 100％ 可用。對於其他 5％，該服務似乎是 90％ 可用。這會導致 1 的可用性-(5% 或 F C U s o 米 電子 s × 10% 或 F t 我的 R 電 子 問題 u s s) = 99.5% 而不是 10% 的請求失敗 100% 的客戶 (導致 90% 的可用性)。
規則十一
故障隔離可降低整體故障率，從而減少影響範圍並增加工作負載的 MTBF。
增加相依性 MTBF
增加AWS依賴關係 MTBF 的第一種方法是使用故障隔離。許多AWS服務在 AZ 提供一定程度的隔離，這表示一個 AZ 中的故障不會影響不同 AZ 中的服務。
在多個 AZ 中使用冗餘 EC2 執行個體可提高子系統的可用性。AZI 在單一區域內提供備用功能，可讓您增加 AZI 服務的可用性。
不過，並非所有AWS服務都在 AZ 層級運作。許多其他人提供區域隔離。在這種情況下，如果區域服務的可用性設計不支援工作負載所需的整體可用性，您可以考慮採用多區域方法。每個區域提供服務的獨立實例化，相當於備用。
有各種服務可以幫助您更輕鬆地構建多區域服務。例如：
本文件並未深入探討建置多區域工作負載的策略，但您應該權衡多區域架構的可用性優勢，以及符合您所需的可用性目標所需的額外成本、複雜性和作業實務。
增加依賴性 MTBF 的下一個方法是將工作負載設計為靜態穩定。例如，您有一個提供產品資訊的工作負載。當您的客戶提出產品要求時，您的服務會向外部中繼資料服務提出要求，以擷取產品詳細資訊。然後，您的工作負載會將所有這些資訊傳回給使用者。
但是，如果無法使用中繼資料服務，則客戶提出的要求會失敗。相反地，您可以在本機以非同步方式將中繼資料提取或推送至服務，以便用來回應要求。這樣可以消除關鍵路徑對中繼資料服務的同步呼叫。
此外，由於即使沒有中繼資料服務，您的服務仍然可以使用，因此您可以在可用性計算中將其作為相依性移除。這個範例取決於中繼資料不會頻繁變更，而且提供過時的中繼資料比要求失敗更好的假設。另一個類似的例子是 DNS 的服務過時，它允許數據保存
增加依賴性 MTBF 的最後一種方法是減少故障影響的範圍。如前所述，失敗不是二進制事件，有失敗程度。這是模塊化的效果; 失敗僅包含由該容器服務的請求或用戶。
這會導致事件發生的失敗次數減少，最終藉由限制影響範圍來提高整體工作負載的可用性。
減少常見的影響來源
在 1985, 吉姆·格雷發現, 在串聯計算機的研究, 失敗主要由兩件事驅動:軟件和操作. （見吉姆·格雷，「為什麼計算機停止，可以做些什麼？
穩定性與功能相比
如果我們回到本節中的軟件和硬件圖表中的故障率分散式系統可用，我們可以注意到每個軟件版本中都添加了缺陷。這表示工作負載的任何變更都會增加失敗的風險。這些變化通常是像新功能一樣的東西，它提供了必要的結果。較高的可用性工作負載比新功能更有利於穩定性 因此，提高可用性的最簡單方法之一就是減少部署頻率或提供較少的功能。部署頻率較高的工作負載本質上會比沒有的工作負載具有較低的可用性。但是，無法新增功能的工作負載無法跟上客戶需求，而且隨著時間的推移可能會變得不那麼有用。
那麼，我們如何繼續安全地創新和發布功能？ 答案是標準化。什麼是正確的部署方式？ 您如何訂購部署？ 測試的標準是什麼？ 您在階段之間等待多長時間？ 您的單元測試涵蓋了足夠的軟件代碼嗎？ 這些是標準化將回答並防止由於不加載測試，跳過部署階段或部署太快到太多主機等問題引起的問題。
您實作標準化的方式是透過自動化。它減少了人為錯誤的機會，並讓計算機做他們擅長的事情，這是做同樣的事情，每次一遍又一遍地做同樣的事情。您將標準化和自動化結合在一起的方式是設定目標。目標像沒有手動更改，只能通過臨時授權系統訪問主機，為每個 API 編寫負載測試等。卓越運營是一種文化規範，可能需要重大變化。根據目標建立和追蹤效能，有助於推動文化變革，從而對工作負載可用性產生廣泛影響。AWS架構良好的卓越營運支柱提供了全面的最佳實踐，以實現卓越的營運。
操作員安全
引入失敗的操作事件的其他主要貢獻者是人。人類會犯錯誤。他們可能會使用錯誤的認證，輸入錯誤的命令，過早按 Enter 鍵，或錯過關鍵步驟。採取手動操作會持續導致錯誤，從而導致失敗。
導致操作員錯誤的主要原因之一是混淆，不直觀或不一致的用戶界面。Jim Gray 在 1985 年的研究中還指出：「要求操作員提供信息或要求他執行某些功能的接口必須簡單，一致且操作員容錯。」 （見吉姆·格雷，「為什麼計算機停止，可以做些什麼？
規則十二
讓運營商輕鬆做正確的事情。
防止過載
影響的最終常見因素是您的客戶，也就是工作負載的實際使用者。成功的工作負載往往會被大量使用，但有時使用量超過了工作負載的擴展能力。可能會發生許多事情，磁碟可能已滿、執行緒集區可能會耗盡、網路頻寬可能已飽和，或是可以達到資料庫連線限制。
沒有故障防護方法可以消除這些問題，但是透過「作業健全狀況」指標主動監控容量和使用率，可在發生這些失敗時提供早期警告。諸如負載脫落、斷路器以及具有指數輪詢和抖動的重試等技術可以幫助減少影響並
如果您需要確保客戶持續可用的容量，則必須取捨可用性和成本。確保容量不足不會導致無法使用的一種方法是為每位客戶提供配額，並確保您的工作負載容量可擴展，以提供 100% 的配額。當客戶超出其配額時，他們會受到限制，這不是失敗，也不會計入可用性。您還需要密切追蹤客戶群並預測未來的使用率，以保持佈建足夠的容量。這可確保您的工作負載不會因為客戶過度使用而導致故障情況。
例如，讓我們檢查提供儲存服務的工作負載。工作負載中的每個伺服器每秒可支援 100 次下載，為客戶提供配額或每秒 200 次下載，並有 500 個客戶。為了能夠支援此數量的客戶，此服務需要提供每秒 100,000 次下載的容量，因此需要 1,000 部伺服器。如果有任何客戶超出其配額，則會受到限制，以確保每個其他客戶都有足夠的容量。這是一個簡單的例子，說明了避免過載而不拒絕工作單位的一種方法。
