可靠性
想像您為醫療保健組織執行臨床系統。 臨床醫師與照顧者不太能容忍停機。 他們必須能夠全天候存取臨床 IT 系統，以確保他們能隨時提供最高品質的照護。
為了符合臨床醫師的全天候需求，應用程式必須能夠在對使用者影響最小的情況下處理失敗。 他們如何確保其應用程式在遭遇局部事件與大規模災害時能夠運作？
在本單元中，您將了解如何在您的架構設計中包含來自可靠性要件的元素。
什麼是可靠性？
在複雜的應用程式中，任何數量的項目可能發生任何規模的錯誤。 個別伺服器和硬碟可能會失敗。 部署問題可能會不小心刪除資料庫中的所有資料表。 整個資料中心可能會無法連上。 勒索軟體事件可能會惡意地將您的所有資料加密。 重要的是，您的應用程式必須維持可靠性，並可同時處理局部與廣泛的影響事件。
針對可用性進行設計包括在小規模事件與暫時性情況 (例如部分網路中斷) 下持續運作。 您可以透過將高可用性整合到每個元件中，來確保您的應用程式會處理本地化的失敗問題。 此應用程式的設計可消除單一失敗點。 此類設計也可將基礎結構維護的影響降到最低。 高可用性設計的目標通常是要快速且自動排除事件的影響，並確保系統能夠繼續處理要求，而且幾乎不會造成影響。
針對可靠性進行設計包括也著重於從資料遺失與較大規模的災害中復原。 從這些類型的事件復原通常牽涉到主動介入，但自動復原步驟可縮短復原所需的時間。 這些類型的事件可能會導致一定程度的停機或永久遺失資料。 災害復原既要仔細規劃，又要能夠執行。
在架構設計中納入高可用性和復原能力，可讓您的企業免於遭受由停機和資料遺失所導致的財務損失。 它們也會保護您的企業免受失去客戶信任所造成的信譽損失。
針對可靠性設計架構可確保您的應用程式滿足您對客戶所做的承諾。 您希望確保您的系統對終端使用者是可用的，並且能夠從任何故障中復原。
建置高可用性架構
針對可用性，找出您所認可的服務等級協定 (SLA)。 檢查您的 SLA 相關應用程式的潛在高可用性功能，並找出您有適當涵蓋範圍的地方以及您需要改進的地方。 目的是要對架構元件新增備援，如此您就比較不可能遇到中斷情形。
高可用性設計元件的範例包括叢集處理與負載平衡：
叢集處理會以一組協調的 VM 取代單一 VM。 有一部 VM 失敗或無法連上時，服務即可容錯移轉到另一部可處理要求的 VM。
負載平衡會將要求分散到服務的許多執行個體，偵測失敗的執行個體，以及避免將要求路由傳送到這些失敗的執行個體。
建置可從失敗中復原的架構
針對復原能力，您應該執行分析，以檢查可能的資料遺失與重大停機案例。 您的分析應該包含復原策略的探索以及每個策略的成本/效益取捨。 本練習可讓您對貴組織的優先順序有重要的見解，並協助釐清您應用程式的角色。 分析的結果應包含應用程式的這些持續時間值：
復原點目標 (RPO)：可接受資料遺失的持續時間上限。 RPO 是以時間單位來測量，而不是時間量。 例如，「30 分鐘的資料」、「4 小時的資料」，依此類推。 RPO 牽涉到的是資料「遺失」(而不是資料「竊取」) 的限縮和復原。
復原時間目標 (RTO)：可接受停止運作的持續時間上限 (您的規格可在其中定義「停止運作時間」)。 例如，若發生災害時可接受的停止運作持續時間是八小時，則您的 RTO 就是八小時。
定義 RPO 和 RTO 後，您可以在架構中設計備份、還原、複寫和復原功能，以符合這些目標。
每個雲端提供者都會提供一套服務和功能，可供您改善應用程式的可用性和復原能力。 可能的話，使用現有的服務和最佳做法，試著不要建立自己的服務。
硬碟可能會失敗，資料中心可能無法連上，而駭客可能攻擊。 重要的是，您可透過可用性和復原能力對客戶維護良好的信譽。 可用性著重於在網路中斷等情況下持續運作，而復原能力則著重於在災害後擷取資料。