本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # MES 中的復原能力 彈性是 MES 系統能夠從基礎架構或服務中斷中復原、動態取得運算資源以滿足需求，以及減少中斷情況，例如設定錯誤或暫時性網路問題。彈性是 [AWS Well-Architected 架構的可靠性支柱所依賴的](https://aws.amazon.com/architecture/well-architected/)主要因素。 恢復能力可分為兩個主要因素：可用性和災難恢復。這兩個區域都依賴一些相同的最佳作法，例如監視故障、部署到多個位置，以及自動容錯移轉。不過，可用性著重於 MES 微服務的元件，而災難復原則著重於整個微服務或甚至整個 MES 系統的獨立副本。 ## 可用性 我們將可用*性*定義為微服務可供使用的時間百分比，如下列公式所示。此百分比是在一段時間內計算的，例如月份、一年或尾隨三年。 ![MES 架構的可用性公式](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/mes-on-aws/images/formula.png) 此公式需要瞭解製造和設備維護中常見的三個指標： + 平**均失敗間隔時間 (MTBF)**：微服務的一般作業開始與其後續失敗之間的平均時間。 + 平**均偵測時間 (MTTD)**：失敗發生與修復作業開始之間的平均時間。 + 平均**修復時間 (MTTR)**：由於子系統失敗而無法使用微服務與其修復或恢復服務之間的平均時間。MTTD 是 MTTR 的一個子集。 下圖說明這些使用狀態測量結果。 ![MES 架構的可用性指標](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/mes-on-aws/images/availability.png) 具有彈性、高可用性的 MES 旨在減少 MTTR 和 MTTD 並增加 MTBF。雖然理想的設計可以消除故障，但這並不現實。傳統的整體式 MES 故障難以偵測，而且需要更長的時間來修復。現代化的雲端原生 MES 可透過異地同步備份部署，實現更快速的偵測、快速修復和業務連續性。有關具有相關 AWS 服務的高可用性現代系統的最佳實踐，請參閱白 paper，可[用性和超越：了解和提高分佈式系統的恢復](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)性 AWS。 ## 災難復原 災難復原是指準備與技術相關的災難 (例如重大硬體或軟體故障)，以及從中復原的程序。防止微服務 (MES) 在其主要部署位置實現其業務目標的事件被視為災難。災難復原與可用性不同，並透過下列兩個指標來衡量： + **復原時間目標 (RTO)**：微服務中斷與微服務還原之間可接受的延遲。RTO 決定當服務無法使用時，什麼被視為可接受的時間範圍。 + **復原點目標 (RPO)**：自上次資料復原點以來可接受的時間上限。RPO 會判斷最後一個復原點與微服務中斷之間，哪些資料會被視為可接受的資料遺失。 下圖說明這些嚴重損壞修復指標。 ![MES 架構的災難復原指標](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/mes-on-aws/images/rpo-rto.png) 下圖描述了不同的災難恢復策略。 ![MES 架構的災難復原策略](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/mes-on-aws/images/dr-strategies.png) 您可以在 AWS Well-Architected 的框架指南中找到有關實施這些策略的詳細指導，[在雲中恢復工作負載的災難恢復](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)。 AWS