# REL11-BP05 使用靜態穩定性來防止雙模態行為
雙模態行為是您的工作負載在正常和失敗模式下展現出不同的行為，例如，當可用區域失敗時，仰賴啟動新的執行個體。您應改為建置靜態穩定且僅以一種模式操作的工作負載。在這種情況下，如果移除一個可用區域，則在每個可用區域佈建足夠的執行個體來處理工作負載負載，然後使用 Elastic Load Balancing 或 Amazon Route 53 運作狀態檢查，將負載從受損的執行個體移出。
運算部署 (例如 EC2 執行個體或容器) 的靜態穩定性可提供最高的可靠性。這必須與成本考量進行權衡。佈建較少的運算容量，而且在發生故障時仰賴啟動新的執行個體，所需的成本會更低。但對於大規模故障 (例如可用區域故障)，此方法效率較低，因為它仰賴在發生故障時對受損情況做出回應，而不是在發生之前為這些受損情況做好準備。您的解決方案應該權衡可靠性與工作負載的成本需求。透過使用更多可用區域，靜態穩定性所需的額外運算量會減少。
![\[圖表：顯示跨可用區域之 EC2 執行個體的靜態穩定性\]](http://docs.aws.amazon.com/zh_tw/wellarchitected/2022-03-31/framework/images/static-stability.png)
流量轉移後，使用 AWS Auto Scaling 以非同步方式取代故障區域的執行個體，並在運作良好的區域中啟動這些執行個體。
另一個雙模態行為範例是網路逾時，網路逾時可能導致系統嘗試重新整理整個系統的組態狀態。這樣一來，即會給另一個元件新增意外負載，且可能導致其發生故障，從而引發其他意外後果。這種負面意見回饋迴圈會影響工作負載的可用性。反之，您應該建置靜態穩定且僅以一種模式操作的系統。靜態穩定的設計是執行持續工作，並始終以固定的規律重新整理組態狀態。叫用失敗時，工作負載會使用先前的快取數值，並觸發警示。
另一個雙模態行為範例是允許用戶端在發生失敗時繞過您的工作負載快取。這看起來可能是滿足用戶端需求的解決方案，但不應得到允許，因為這會大幅變更工作負載的需求，且可能導致故障。
**若未建立此最佳實務，暴露的風險等級為：** 中
## 實作指引
+ 使用靜態穩定性來防止雙模態行為。雙模態行為是您的工作負載在正常和失敗模式下展現出不同的行為，例如，當可用區域失敗時，仰賴啟動新的執行個體。
+ [在災難復原計畫中盡可能減少相依關係](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library：使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [AWS 中的靜態穩定性：AWS re:Invent 2019：The Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ 您應改為建置靜態穩定且僅以一種模式操作的系統。在這種情況下，如果移除一個 AZ，則在每個區域佈建足夠的執行個體來處理工作負載負載，然後使用 Elastic Load Balancing 或 Amazon Route 53 運作狀態檢查，將負載從受損的執行個體移出。
+ 另一個雙模態行為範例是允許用戶端在發生失敗時繞過您的工作負載快取。這看起來可滿足用戶端需求的解決方案，但不應允許，因為這會大幅變更工作負載的需求，且可能導致失敗。
## 資源
**相關文件：**
+ [在災難復原計畫中盡可能減少相依關係](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library：使用可用區域實現靜態穩定性](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**相關影片：**
+ [AWS 中的靜態穩定性：AWS re:Invent 2019：The Amazon Builders’ Library 簡介 (DOP328)](https://youtu.be/sKRdemSirDM?t=704)