本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 增加 MTBF
提高可用性的最後一個元件正在增加MTBF. 這可以同時適用於軟件以及用於運行它的 AWS 服務。
## 增加分散式系統 MTBF
增加的一種方法MTBF是減少軟件中的缺陷。有幾種方式可以執行此作業。客戶可以使用 [Amazon CodeGuru 審核](https://aws.amazon.com/codeguru/)者等工具來尋找並修復常見錯誤。您也應該在軟體部署到生產環境之前，對軟體執行全面的對等程式碼檢閱、單元測試、整合測試、迴歸測試和負載測試。增加測試中的代碼覆蓋率將有助於確保即使是不常見的代碼執行路徑也會被測試。
部署較小的變更也可降低變更的複雜性，協助防止意外結果。每個活動都提供了一個機會，以識別和修復缺陷之前，它們可以被調用。
防止故障的另一種方法是[定期測試](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html)。實作混沌工程計畫可協助測試工作負載失敗的情況、驗證復原程序，以及協助在生產環境中發生之前尋找和修正失敗模式。客戶可以使用[AWS 故障注入模擬器](https://aws.amazon.com/fis/)作為其混亂工程實驗工具集的一部分。
容錯能力是防止分散式系統故障的另一種方法。快速故障模組、具有指數輪詢和抖動的重試、交易和冪等都是協助讓工作負載容錯的技術。
交易是一組遵守ACID屬性的操作。如下所示：
+ **原子性** — 無論是所有的行動發生或沒有一個會發生.
+ **一致性** — 每個交易都會使工作負載保持有效狀態。
+ **隔離** — 同時執行的交易會使工作負載保持與按順序執行相同的狀態。
+ **耐久性** — 一旦交易認可，即使在工作負載失敗的情況下，也會保留其所有效果。
透過[指數輪詢和抖動](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)進行重試，可讓您克服由 Heisenbugs、超載或其他情況造成的暫時性故障。當事務是冪等的時候，它們可以重試多次而不會產生副作用。
如果我們考慮一個 Heisenbug 對容錯硬件配置的影響，我們會相當不關心，因為 Hisenbug 出現在主要和冗餘子系統上的概率是無限小的。（見吉姆·格雷，「[為什麼計算機停止，可以做些什麼？](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf) 「，一九八五年六月，串聯技術報告 85.7。） 在分佈式系統中，我們希望使用我們的軟件實現相同的結果。
當調用 Hisenbug 時，軟件必須快速檢測到不正確的操作並失敗，以便再次嘗試。這是通過防禦性編程來實現的，並驗證輸入，中間結果和輸出。此外，處理序會被隔離，並且不會與其他程序共用任何狀態。
這種模組化方法可確保故障期間的影響範圍受到限制。程序獨立失敗。當一個進程確實失敗時，軟件應該使用「進程對」來重試工作，這意味著一個新的進程可以承擔一個失敗的工作。為了維護工作負載的可靠性和完整性，每個操作都應被視為一個ACID事務。
這可讓處理程序失敗，而不會中斷交易並復原所做的任何變更，而不會損毀工作負載的狀態。這可讓復原程序從已知良好狀態重試交易，並正常重新啟動。這就是軟件對海森錯誤的方式。
但是，您不應該旨在使軟件對 Bohrbug 進行容錯。在工作負載進入生產環境之前，必須先找到並移除這些瑕疵，因為沒有任何等級的備援能夠達到正確的結果 （見吉姆·格雷，「[為什麼計算機停止，可以做些什麼？](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) 「，一九八五年六月，串聯技術報告 85.7。）
增加的最後一種方法MTBF是減少故障造成的影響範圍。透過模組化使用[故障隔離](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)來建立容錯容器，是先前在容錯*和容錯*隔離中所述的主要方式。降低故障率可提高可用性。 AWS 使用諸如將服務劃分為控制面和數據平面，[可用區域獨立性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)（AZI），區[域隔離](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)，[基於細胞的架構](https://www.youtube.com/watch?v=swQbA4zub20)和[洗牌分片](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding)等技術來提供故障隔離。這些也是 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是通過使用[故障隔離](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)。許多 AWS 服務在 AZ 提供一定程度的隔離，這表示一個 AZ 中的故障不會影響不同 AZ 中的服務。
在多個中使用冗餘EC2執行個體可AZs提高子系統可 AZI在單一區域內提供備用功能，可讓您提高AZI服務的可用性。
不過，並非所有 AWS 服務都在 AZ 層級運作。許多其他人提供區域隔離。在這種情況下，如果區域服務的可用性設計不支援工作負載所需的整體可用性，您可以考慮採用多區域方法。每個區域都提供服務的獨立實例化，相當於備用。
有各種服務可以幫助您更輕鬆地構建多區域服務。例如：
+ [Amazon Aurora 全球數據](https://aws.amazon.com/rds/aurora/global-database/)
+ [Amazon DynamoDB 全球表](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) — 全球資料存放區](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS 全球加速器](https://aws.amazon.com/global-accelerator/)
+ [Amazon S3 跨區域複寫](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Amazon 路線 53 應用程序恢復控](https://aws.amazon.com/route53/application-recovery-controller/)
本文件並未深入探討建置多區域工作負載的策略，但您應該權衡多區域架構的可用性優勢，以及符合您所需的可用性目標所需的額外成本、複雜性和作業實務。
下一個增加依賴性的方法MTBF是將工作負載設計為靜態穩定。例如，您有一個提供產品資訊的工作負載。當您的客戶提出產品要求時，您的服務會向外部中繼資料服務提出要求，以擷取產品詳細資訊。然後，您的工作負載會將所有這些資訊傳回給使用者。
不過，如果無法使用中繼資料服務，您的客戶提出的要求就會失敗。相反地，您可以在本機以非同步方式將中繼資料提取或推送至服務，以便用來回應要求。這樣可以消除關鍵路徑對中繼資料服務的同步呼叫。
此外，由於即使沒有中繼資料服務，您的服務仍然可以使用，因此您可以在可用性計算中將其作為相依性移除。這個範例取決於中繼資料不會頻繁變更，而且提供過時的中繼資料比要求失敗更好的假設。另一個類似的例子是[服務過時DNS，它允許數據保存](https://www.rfc-editor.org/rfc/rfc8767)在緩存中超過TTL到期，並在刷新的答案不容易獲得時用於響應。
增加依賴性的最後一種方法MTBF是減少失敗造成的影響範圍。如前所述，失敗不是二進制事件，有失敗程度。這是模塊化的效果; 失敗僅包含由該容器服務的請求或用戶。
這會導致事件發生的失敗次數減少，最終藉由限制影響範圍來提高整體工作負載的可用性。
## 減少常見的影響來源
在 1985, 吉姆·格雷發現, 在串聯計算機的研究, 失敗主要由兩件事驅動:軟件和操作. （見吉姆·格雷，「[為什麼計算機停止，可以做些什麼？](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) 「，一九八五年六月，串聯技術報告 85.7。） 即使在 36 年後，這仍然是真實的。儘管技術有進步，但這些問題並不是一個簡單的解決方案，並且主要的故障來源並沒有改變。在本節的開頭討論了解決軟件故障的問題，所以這裡的重點將是操作和減少故障的頻率。
### 穩定性與功能相比
如果我們回到本節中的軟件和硬件圖表中的故障率[分散式系統可用](distributed-system-availability.md)，我們可以注意到每個軟件版本中都添加了缺陷。這表示工作負載的任何變更都會增加失敗的風險。這些變化通常是像新功能一樣的東西，它提供了必要的結果。較高的可用性工作負載比新功能更有利於穩定性 因此，提高可用性的最簡單方法之一就是減少部署頻率或提供較少的功能。部署頻率較高的工作負載本質上會比沒有的工作負載具有較低的可用性。但是，無法新增功能的工作負載無法跟上客戶需求，而且隨著時間的推移可能會變得不那麼有用。
那麼，我們如何繼續安全地創新和發布功能？ 答案是標準化。什麼是正確的部署方式？ 您如何訂購部署？ 測試的標準是什麼？ 您在階段之間等待多長時間？ 您的單元測試涵蓋了足夠的軟件代碼嗎？ 這些是標準化將回答並防止由於不加載測試，跳過部署階段或部署太快到太多主機等問題引起的問題。
您實作標準化的方式是透過自動化。它減少了人為錯誤的機會，並讓計算機做他們擅長的事情，這是做同樣的事情，每次一遍又一遍地做同樣的事情。您將標準化和自動化結合在一起的方式是設定目標。目標像沒有手動更改，只能通過臨時授權系統訪問主機，為每個編寫負載測試API等。卓越運營是一種文化規範，可能需要重大的改變。根據目標建立和追蹤效能，有助於推動文化變革，從而對工作負載可用性產生廣泛影響。[AWS Well-Architected 的卓越營運支柱](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)提供了全面的最佳實踐，以實現卓越的營運。
### 操作員安全
引入失敗的操作事件的其他主要貢獻者是人。人類會犯錯誤。他們可能會使用錯誤的認證，輸入錯誤的命令，過早按 Enter 鍵，或錯過關鍵步驟。採取手動操作會持續導致錯誤，從而導致失敗。
導致操作員錯誤的主要原因之一是混淆，不直觀或不一致的用戶界面。Jim Gray 在 1985 年的研究中還指出：「要求操作員提供信息或要求他執行某些功能的接口必須簡單，一致且操作員容錯。」 （見吉姆·格雷，「[為什麼計算機停止，可以做些什麼？](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) 「，一九八五年六月，串聯技術報告 85.7。） 這種見解今天仍然是真實的。在過去三十年中，整個行業中有許多例子，其中令人困惑或複雜的用戶界面，缺乏確認或說明，甚至只是不友好的人類語言導致操作員做錯事。
**規則十二**
讓運營商輕鬆做正確的事情。
### 防止過載
影響的最終常見因素是您的客戶，也就是工作負載的實際使用者。成功的工作負載往往會被大量使用，但有時使用量超過了工作負載的擴展能力。可能會發生許多事情，磁碟可能已滿、執行緒集區可能會耗盡、網路頻寬可能已飽和，或是可以達到資料庫連線限制。
沒有故障防護方法可以消除這些問題，但是透過「作業 Health 全狀況」指標主動監控容量和使用率，可在發生這些失敗時提供早期警告。諸如[負載[脫落、[斷路器](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html)以及具有指數輪詢和抖動的重試等技術可以幫助減少影響並](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)提高成功率，但這些情況仍然代](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)表失敗。根據作業 Health 狀態指標自動調整可協助減少因超載而導致的故障頻率，但可能無法快速回應使用率變更。
如果您需要確保客戶持續可用的容量，則必須取捨可用性和成本。確保容量不足不會導致無法使用的一種方法是為每位客戶提供配額，並確保您的工作負載容量可擴展，以提供 100% 的配額。當客戶超出其配額時，他們會受到限制，這不是失敗，也不會計入可用性。您還需要密切追蹤客戶群並預測 future 的使用率，以保持佈建足夠的容量。這可確保您的工作負載不會因為客戶過度使用而導致故障情況。
+ [Amazon Builders' Library-使用負載脫落以避免過載](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library — 多租戶系統的公平性](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
例如，讓我們檢查提供儲存服務的工作負載。工作負載中的每個伺服器每秒可支援 100 次下載，為客戶提供配額或每秒 200 次下載，並有 500 個客戶。為了能夠支援此數量的客戶，此服務需要提供每秒 100,000 次下載的容量，因此需要 1,000 部伺服器。如果有任何客戶超出其配額，則會受到限制，以確保每個其他客戶都有足夠的容量。這是一個簡單的例子，說明了避免過載而不拒絕工作單位的一種方法。