本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 設計高可用性的分散式系統 AWS
前面的章節主要是關於工作負載的理論可用性以及它們可以實現的目標。它們是建置分散式系統時要牢記的重要概念集。它們將有助於告知您的依賴關係選擇過程以及如何實現冗餘。
我們也研究了MTTD、MTTR與MTBF可用性之間的關係。本節將根據以前的理論介紹實用指導。簡而言之，高可用性的工程工作負載旨在增加MTBF和減少MTTD. MTTR
儘管消除所有失敗將是理想的，但這並不現實。在具有深層堆疊相依性的大型分散式系統中，將會發生故障。「一切都失敗了所有的時間」(見沃納·沃格爾斯,CTO, Amazon.com, [10 從 Amazon Web Services 多年的經驗教訓](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html)。) 和「你不能立法針對失敗 [所以] 專注於快速檢測和響應。」 （請參閱 Amazon EC2 團隊創始成員 Chris Pinkham，[為故障ARC335設計：在上構建彈性](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf)系統） AWS
這意味著您通常無法控制是否發生故障。您可以控制的是檢測故障並對其執行某些操作的速度。因此，雖然增加仍然MTBF是高可用性的重要組成部分，但客戶在其控制範圍內最重要的變化是減少MTTD和MTTR。
**Topics**
+ [減少 MTTD](reducing-mttd.md)
+ [減少 MTTR](reducing-mttr.md)
+ [增加 MTBF](increasing-mtbf.md)
# 減少 MTTD
減少失敗意味著盡快發現故障。MTTD縮短基MTTD於可觀察性，或者您如何檢測工作負載以了解其狀態。*客戶應在工作負載的關鍵子系統中監控其「客戶體驗*」指標，以便主動識別問題發生時機 (請參閱[附錄 1 — 以MTTD及關MTTR鍵指標以取得有關這些指標](appendix-1-mttd-and-mttr-critical-metrics.md)的詳細資訊)。). 客戶可以使用 [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 建立監控您APIs和主控台的*金絲雀*，以主動衡量使用者體驗。還有許多其他健康狀態檢查機制可用於最小化MTTD，例如 E [lastic Load Balancing (ELB) 運作狀態檢查](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html)、[Amazon Route 53 運作狀態檢查](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html)等。（請參閱 [Amazon Builders' Library-實施運行狀態檢查](https://aws.amazon.com/builders-library/implementing-health-checks/)。）
您的監視也需要能夠偵測整個系統和個別子系統中的部分故障。您的可用性、失敗和延遲指標應使用錯誤隔離界限的維度作為[CloudWatch 量](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension)度維度。例如，假設單一EC2執行個體屬於儲存格架構的一部分，位於 us-east-1 區域的 use1-az1 AZ 中，該執行個體屬於其控制平面子系統的工作負載更新API的一部分。伺服器推送指標時，可以使用其執行個體 ID、AZ、地區、API名稱和子系統名稱作為維度。這使您可以在每個維度上具有可觀察性並設置警報以檢測故障。
# 減少 MTTR
在發現故障之後，剩餘的MTTR時間就是實際修復或緩解影響。要修復或減輕故障，您必須知道出了什麼問題。在此階段有兩個關鍵的指標群組可提供深入分析：1/ *影響評估*指標和 2/ *作業 Health* 度量。第一個群組會告訴您失敗期間的影響範圍，測量受影響的客戶、資源或工作負載的數量或百分比。第二組有助於確定*為什麼*會產生影響。在發現原因之後，操作員和自動化可以回應並解決故障。如需有關這些[測量結果的詳細資訊，請參閱附錄 1 — MTTD 和MTTR重要](appendix-1-mttd-and-mttr-critical-metrics.md)測量結果。
**規則第 9 條**
可觀測性和儀器儀表對於減少MTTD和MTTR.
## 故障周圍的路由
減輕影響的最快方法是透過快速故障的子系統繞過故障。這種方法會將故障子系統的工作快速轉移至備援，MTTR藉此減少備援。備援範圍包括軟體程序、EC2執行個體、多個區域AZs，以及多個區域。
備用子系統可以減少到MTTR幾乎為零。恢復時間只是將工作重新路由到備用備用所需的時間。這通常以最小的延遲發生，並允許工作在定義的範圍內完成SLA，從而保持系統的可用性。這種產生MTTRs的經歷是輕微的，甚至難以察覺的延遲，而不是長時間的不可用性。
例如，如果您的服務使用 Application Load Balancer (ALB) 後面的EC2執行個體，您可以設定健全狀況檢查的間隔 (最少 5 秒)，而且只需要兩次失敗的健康狀態檢查，才能將目標標示為狀態不良。這表示您可以在 10 秒內偵測到故障並停止將流量傳送到健康狀態不良的主機。在這種情況下MTTR，實際上與相同，MTTD因為一旦檢測到故障，它也會被緩解。
這就是*高可用性或持續可用性**工作負載試圖*實現的目標。我們希望藉由快速偵測失敗的子系統、將其標示為失敗、停止傳送流量至備援子系統，以及將流量傳送至備援子系統，藉此快速繞過工作負載中的故障。
請注意，使用這種快速故障機制會使您的工作負載對暫時性錯誤非常敏感。在提供的範例中，請確定負載平衡器健康狀態檢查只對執行個[https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/)健康狀態檢查，而不是測試相依性或工作流程 (通常稱為*深度*健康狀態檢查)。這有助於避免在影響工作負載的暫時性錯誤期間不必要的執行個體更換
可觀察性和檢測子系統故障的能力對於成功繞線故障至關重要。您必須知道影響範圍，以便受影響的資源可以標記為狀態不良或失敗並退出服務，以便可以繞過這些資源。例如，如果單一 AZ 遇到部分服務損害，則您的檢測將需要能夠識別是否存在 AZ 本地化問題，以繞過該 AZ 中的所有資源，直到恢復為止。
能夠繞過故障可能還需要額外的工具，具體取決於環境。使用上一個範例與後面的EC2執行個體一起使用ALB，假設一個 AZ 中的執行個體可能會通過本機運作狀態檢查，但是隔離的 AZ 損害導致它們無法連線至其他 AZ 中的資料庫。在此情況下，負載平衡健康狀態檢查不會將這些執行個體停止服務。需要使用不同的自動化機制，才能[從負載平衡器移除 AZ](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html)，或強制執行個體的健康狀態檢查失敗，這取決於識別影響範圍是 AZ。對於未使用負載平衡器的工作負載，需要使用類似的方法來防止特定 AZ 中的資源接受工作單位或完全從 AZ 移除容量。
在某些情況下，將工作轉移到冗餘子系統無法自動化，例如主要到次要資料庫的容錯移轉，其中技術不會提供自己的領導者選舉。這是[AWS 多區域架構](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)的常見案例。由於這些類型的容錯移轉需要一定程度的停機時間才能完成，無法立即回復，並且將工作負載保留一段時間而不需要冗餘，因此在決策過程中擁有人力是非常重要的。
使用多區域容錯移轉自動化繞過故障的路MTTRs由，可以採用較不嚴格的一致性模型的工作負載縮短。[Amazon S3 跨區域複寫或 Amazon DynamoDB 全域](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)[表](https://aws.amazon.com/dynamodb/global-tables/)等功能可透過最終一致的複寫提供多區域功能。此外，當我們考慮CAP定理時，使用寬鬆的一致性模型是有益的。在影響到可設定狀態子系統連線的網路故障期間，如果工作負載選擇可用性而不是一致性，它仍然可以提供非錯誤回應，也就是另一種繞過故障路由的方式。
圍繞失敗的繞線可以使用兩種不同的策略來實現。第一個策略是透過預先佈建足夠的資源來處理故障子系統的完整負載，以實作靜態穩定性。這可以是單一EC2執行個體，也可能是整個 AZ 容量。在失敗期間嘗試佈建新資源，會增加復原路徑中控制平面的相依性，MTTR並增加相依性。但是，它需要額外付費。
第二個策略是將某些流量從故障的子系統路由到其他[流量，並將剩餘容量無法處理的過量流量負載](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)。在此降級期間，您可以擴展新資源以取代故障的容量。這種方法具有更長的時間，MTTR並在控制平面上產生依賴性，但在待機，備用容量方面的成本更低。
## 返回已知良好狀態
修復期間緩解的另一種常見方法是將工作負載返回先前已知的良好狀態。如果最近的變更可能導致失敗，則復原該變更是返回先前狀態的一種方法。
在其他情況下，暫時性情況可能導致失敗，在這種情況下，重新啟動工作負載可能會減輕影響。讓我們來看看這兩種情況。
在部署期間，最小化MTTD並MTTR依賴可觀測性和自動化。您的部署程序必須持續觀察工作負載，以提高錯誤率、延遲增加或異常情況。識別這些之後，它應該停止部署程序。
有各種各樣的[部署策略](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html)，例如就地部署、藍/綠部署和滾動式部署。其中每一個都可能使用不同的機制來返回已知的良好狀態。它可以自動回復到先前的狀態，將流量轉移回藍色環境，或者需要手動介入。
CloudFormation [提供了作為其創建和更新堆棧操作的一部分自動復原的功能](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html)，就像一樣[AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks)。 CodeDeploy 也支援藍/綠和滾動式部署。
若要充分利用這些功能並將您的功能降到最低MTTR，請考慮透過這些服務自動化所有基礎結構和程式碼部署。在無法使用這些服務的案例中，請考慮使用實作 [saga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) AWS Step Functions 以復原失敗的部署。
考慮*重新啟動*時，有幾種不同的方法。這些範圍從重新啟動服務器，最長的任務，重新啟動線程，最短的任務。這是一個表格，概述了一些重新啟動方法和要完成的近似時間（代表數量級差，這些差異並不精確）。
| 故障恢復機制 | 估計 MTTR |
| --- | --- |
| 啟動並設定新的虛擬伺服器 | 15 分鐘 |
| 重新部署軟體 | 10 分鐘 |
| 重啟伺服器 | 5 分鐘 |
| 重新啟動或啟動容器 | 2 秒 |
| 叫用新的無伺服器功能 | 一百毫秒 |
| 重新啟動程 | 10 毫秒 |
| 重啟執行緒 | 10 微秒 |
查看表格，使用容器和無伺服器功能（如 [AWS Lambda](https://aws.amazon.com/lambda/)）有一些明顯的好處。MTTR它們MTTR的速度比重新啟動虛擬機器或啟動新的虛擬機器快。不過，透過軟體模組化使用故障隔離也是有益的。如果您可能導致單一處理序或執行緒失敗，則從該失敗中復原會比重新啟動容器或伺服器快得多。
作為恢復的一般方法，您可以從下移動到頂部：1/ 重新啟動，2/ 重新啟動，3/ 重新映像/重新部署，4 /替換。但是，一旦進入重新啟動步驟，繞過失敗通常是一種更快的方法（通常最多需要 3—4 分鐘）。因此，為了最快地減輕嘗試重新啟動後的影響，請繞過故障，然後在背景繼續復原程序，以將容量返回至您的工作負載。
**規則第十條**
專注於緩解影響，而不是解決問題。以最快的路徑回到正常操作。
## 故障診斷
檢測後修復過程的一部分是診斷期。這是運營商試圖確定什麼是錯誤的時間段。此程序可能涉及查詢記錄檔、檢閱作業 Health 狀態指標，或登入主機以進行疑難排解。所有這些動作都需要時間，因此建立工具和 Runbook 來加速這些動作也有助於減少這些動MTTR作。
## 手冊和自動化
同樣地，在您判斷錯誤的原因以及要修復工作負載的動作方式之後，操作員通常需要執行一組步驟來執行此操作。例如，在失敗之後，修復工作負載的最快方法可能是重新啟動工作負載，這可能涉及多個有序的步驟。使用可以自動執行這些步驟或向操作員提供特定方向的 runbook 將加快流程並有助於降低無意採取行動的風險。
# 增加 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 部伺服器。如果有任何客戶超出其配額，則會受到限制，以確保每個其他客戶都有足夠的容量。這是一個簡單的例子，說明了避免過載而不拒絕工作單位的一種方法。