共用方式為

什麼是商務持續性、高可用性和災害復原？

  • 發行項

本文定義並描述透過高可用性和災害復原設計，在風險管理方面的商務持續性和商務持續性規劃。 雖然本文並未提供有關如何符合您自己商務持續性需求的明確指引，但它可協助您了解在整個Microsoft可靠性指引中使用的概念。

商務持續性 是企業在失敗、中斷或災害期間可以繼續作業的狀態。 商務持續性需要主動式規劃、準備，以及復原系統和程序的實作。

規劃商務持續性需要識別、瞭解、分類和管理風險。 根據風險及其可能性，設計 高可用性 （HA） 和 災害復原 （DR）。

高可用性 是設計解決方案以復原日常問題，並滿足商務可用性需求。

災害復原 是關於規劃如何處理不常見的風險，以及可能導致的災難性中斷。

業務持續性

一般而言，雲端解決方案會直接系結至商務營運。 每當雲端解決方案無法使用或遇到嚴重問題時，對商務營運的影響可能會很嚴重。 嚴重影響可能會中斷商務持續性。

對商務持續性的嚴重影響可能包括：

  • 失去業務收入。
  • 無法為使用者提供重要的服務。
  • 違反對客戶或另一方的承諾。

請務必瞭解和傳達業務期望，以及失敗的後果，以及重要項目關係人，包括那些設計、實作及操作工作負載的人員。 然後，這些項目關係人會分享參與達成該願景的成本來做出回應。 根據預算和其他限制，通常有談判和修訂該願景的程式。

商務持續性規劃

若要控制或完全避免對商務持續性造成負面影響，請務必主動建立 商務持續性計劃。 商務持續性計畫是以風險評估為基礎，並開發透過各種方法控制這些風險的方法。 針對每個組織和工作負載，要減輕的特定風險和方法會有所不同。

商務持續性計劃不僅會考慮雲端平臺本身的復原功能，也會考慮應用程式的功能。 健全的商務持續性計劃也會納入商務中支援的所有層面，包括人員、商務相關手冊或自動化程式，以及其他技術。

商務持續性規劃應包含下列循序步驟：

  1. 風險識別。 識別工作負載可用性或功能的風險。 可能的風險可能是網路問題、硬體故障、人為錯誤、區域中斷等。瞭解每個風險的影響。

  2. 風險分類。 將每個風險分類為一般風險，這應納入HA的計劃，或不常見的風險，這應該是DR規劃的一部分。

  3. 風險降低。 設計HA或DR的風險降低策略，以將備援、複寫、故障轉移和備份等風險降到最低或降低。 此外，請考慮非技術型和以程式為基礎的風險降低和控件。

商務持續性規劃是一個程式，而不是一次性事件。 應定期檢閱和更新所建立的任何商務持續性計劃，以確保其保持相關且有效，並支援目前的商務需求。

風險識別

商務持續性規劃的初始階段是識別工作負載可用性或功能的風險。 應該分析每個風險，以瞭解其可能性和嚴重性。 嚴重性必須包含任何潛在的停機時間或數據遺失，以及解決方案設計其餘部分的任何層面是否可能會補償負面影響。

下表是一份非詳盡的風險清單，依降低的可能性排序：

範例風險 描述 正則性（可能性）
暫時性網路問題 網路堆疊元件中的暫時失敗，可在短時間內復原（通常是幾秒鐘或更少）。 一般
虛擬機重新啟動 重新啟動您使用的虛擬機，或相依服務所使用的虛擬機。 重新啟動可能會因為虛擬機當機或需要套用修補程式而發生。 一般
硬體失敗 數據中心內元件的失敗，例如硬體節點、機架或叢集。 偶爾
數據中心中斷 影響大部分或所有數據中心的中斷，例如電源故障、網路連線問題，或取暖和冷卻問題。 異常
區域中斷 影響整個大都市或更廣泛的地區的中斷，例如重大自然災害。 非常不尋常的

商務持續性規劃不只是雲端平臺和基礎結構。 請務必考慮人為錯誤的風險。 此外，一些傳統上可能被視為安全性、效能或作業風險的風險也應該被視為可靠性風險，因為它們會影響解決方案的可用性。

以下列出一些範例：

範例風險 描述
數據遺失或損毀 數據已被意外刪除、覆寫或損毀，或因勒索軟體攻擊之類的安全性缺口而損毀。
軟體錯誤 新程式代碼或更新程序代碼的部署引進會影響可用性或完整性的 Bug，使工作負載處於故障狀態。
失敗的部署 新元件或版本的部署失敗，使解決方案處於不一致的狀態。
拒絕服務攻擊 系統遭到攻擊，試圖防止合法使用解決方案。
流氓系統管理員 具有系統管理許可權的使用者已刻意對系統執行破壞性動作。
非預期的流量湧入應用程式 流量激增已讓系統的資源不堪重負。

失敗模式分析 （FMA） 是識別工作負載或其元件可能失敗之潛在方式的程式，以及解決方案在這些情況下的運作方式。 若要深入瞭解，請參閱 執行失敗模式分析的建議。

風險分類

商務持續性計劃必須同時解決常見和不常見的風險。

  • 一般風險 是規劃和預期的。 例如，在雲端環境中，經常發生 暫時性失敗 ，包括短暫的網路中斷、設備因修補程式而重新啟動、服務忙碌時逾時等等。 由於這些事件會定期發生，因此工作負載必須具備復原能力。

    高可用性策略必須針對此類型的每個風險考慮和控制。

  • 常見的風險 通常是意外事件的結果，例如自然災害或重大網路攻擊，可能會導致災難性的中斷。

    災害復原程式會處理這些罕見的風險。

高可用性和災害復原相互關聯，因此請務必共同規劃這兩者的策略。

請務必瞭解風險分類取決於工作負載架構和業務需求，有些風險可以分類為一個工作負載的HA，另一個工作負載的DR。 例如，完整 Azure 區域中斷通常被視為該區域工作負載的DR風險。 但是，對於使用主動-主動設定中具有完整複寫、備援和自動區域故障轉移之多個 Azure 區域的工作負載，區域中斷會分類為 HA 風險。

風險降低

風險降低包括開發HA或DR策略，以將商務持續性的風險降到最低或降低。 風險降低可以是以技術為基礎或人為為基礎。

以技術為基礎的風險降低

以技術為基礎的風險降低會使用以工作負載實作和設定方式為基礎的風險控制措施，例如：

  • 備援性
  • 資料複寫
  • 容錯移轉
  • 備份

技術型風險控制必須在商務持續性計劃的內容內考慮。

例如：

  • 低停機時間需求。 由於嚴格的 高可用性 需求，某些商務持續性計劃無法容忍任何形式的停機時間風險。 某些以技術為基礎的控件可能需要時間才能通知人類，然後回應。 包含緩慢手動程式的技術型風險控制可能不適合納入其風險降低策略。

  • 部分失敗的容錯。 某些商務持續性計劃能夠容忍處於降級狀態執行的工作流程。 當解決方案處於降級狀態時，某些元件可能會停用或無法運作，但核心商務作業可以繼續執行。 若要深入瞭解，請參閱 自我修復和自我保護的建議。

人為風險風險降低

以人為為基礎的風險降低會使用以商務程式為基礎的風險控制，例如：

  • 觸發回應劇本。
  • 回復為手動作業。
  • 訓練和文化變化。

重要

個人設計、實作、操作和不斷演進工作負載應該稱職，鼓勵他們說話，如果他們有疑慮，並感受到系統的責任感。

由於人為風險控制通常比技術型控件慢，而且更容易發生人為錯誤，因此良好的商務持續性計劃應該包含任何改變執行中系統狀態的正式變更控制程式。 例如，請考慮實作下列程式：

  • 根據工作負載關鍵性嚴格測試您的工作負載。 若要防止變更相關問題，請務必測試對工作負載所做的任何變更。
  • 在工作負載的安全部署實務中引進策略性質量網關。 若要深入瞭解，請參閱 安全部署做法的建議。
  • 將臨機操作生產存取和數據操作的程序正規化。 這些活動，無論多麼輕微，都可能會造成可靠性事件的高風險。 程式可能包括與另一位工程師配對、使用檢查清單，以及在執行腳本或套用變更之前取得對等檢閱。

高可用性

高可用性是特定工作負載每天可以維持其必要運行時間層級的狀態，即使在暫時性錯誤和間歇性失敗期間也是如此。 由於這些事件會定期發生，因此請務必根據特定應用程式和客戶期望的需求，針對高可用性設計及設定每個工作負載。 每個工作負載的HA都會為您的商務持續性計劃做出貢獻。

由於 HA 會隨著每個工作負載而有所不同，因此請務必瞭解判斷高可用性時的需求和客戶期望。 例如，組織用來訂購辦公室用品的應用程式可能需要相對較低的運行時間層級，而重要的財務應用程式可能需要更高的運行時間。 即使在工作負載內，不同的 流程 也可能有不同的需求。 例如，在電子商務應用程式中，支援客戶流覽和下單的流程可能比訂單履行和後台處理流程更重要。 若要深入瞭解流程，請參閱 識別和評等流程的建議。

通常，運行時間是根據運行時間百分比中的「九」數目來測量。 運行時間百分比與您在指定時間內允許的停機時間有關。 以下列出一些範例：

  • 99.9% 的運行時間需求（三個九）允許在一個月內大約 43 分鐘的停機時間。
  • 99.95% 的運行時間需求（3 個半 9 秒）允許在一個月內大約 21 分鐘的停機時間。

運行時間需求越高、中斷的承受度越少，以及達到該可用性層級所需的工作越多。 運行時間不是由單一元件的運行時間來測量，例如節點，而是透過整個工作負載的整體可用性來測量。

重要

請勿過度工程您的解決方案，以達到比合理程度更高的可靠性。 使用商務需求來引導您的決策。

高可用性設計元素

若要達到HA需求，工作負載可以包含一些設計元素。 本節將列出一些常見的元素，如下所述。

注意

某些工作負載是 任務關鍵性工作負載，這表示任何停機都可能會對人類生命和安全造成嚴重後果，或造成重大財務損失。 如果您要設計任務關鍵性工作負載，當您設計解決方案及管理商務持續性時，需要考慮的特定事項。 如需詳細資訊，請參閱 Azure 架構完善的架構：任務關鍵性工作負載。

支援高可用性的 Azure 服務和層級

許多 Azure 服務都設計為高可用性，可用來建置高可用性工作負載。 以下列出一些範例：

  • Azure 虛擬機器擴展集 藉由自動建立和管理 VM 實例及散發這些 VM 實例，以減少基礎結構失敗的影響，為虛擬機 （VM） 提供高可用性。
  • Azure App 服務 透過各種方法提供高可用性，包括自動將背景工作角色從狀況不良的節點移至狀況良好的節點，以及提供許多常見錯誤類型自我修復的功能。

使用每個 服務可靠性指南 來瞭解服務的功能、決定要使用的層級，以及決定要包含在高可用性策略中的哪些功能。

檢閱每個服務的服務等級協定 （SLA），以瞭解預期的可用性層級和您需要符合的條件。 您可能需要選取或避免特定層級的服務，才能達到特定層級的可用性。 有些來自Microsoft的服務是透過瞭解未提供 SLA，例如開發或基本層，或可從執行中的系統回收資源，例如現成供應專案。 此外，某些層級已新增可靠性功能，例如可用性區域的支援。

容錯

容錯是系統在發生失敗時繼續運作的能力，在某些已定義的容量中。 例如，即使單一 Web 伺服器失敗，Web 應用程式仍可能設計為繼續作業。 容錯可透過備援、故障轉移、分割、正常降低和其他技術來達成。

容錯也需要您的應用程式處理暫時性錯誤。 當您建置自己的程式代碼時，您可能需要自行啟用暫時性錯誤處理。 某些 Azure 服務會針對某些情況提供內建暫時性錯誤處理。 例如，根據預設，Azure Logic Apps 會自動重試其他服務的失敗要求。 若要深入瞭解，請參閱 處理暫時性錯誤的建議。

備援性

備援是複製實例或數據以增加工作負載可靠性的做法。

藉由以下列方式，將復本或備援實例分散在一起，即可達成備援：

  • 資料中心內 （本機備援）
  • 在區域內的可用性區域之間（區域備援）
  • 跨區域（異地備援）。

以下是某些 Azure 服務如何提供備援選項的一些範例：

  • Azure App 服務 可讓您執行應用程式的多個實例，以確保即使一個實例失敗，應用程式仍可供使用。 如果您啟用區域備援，這些實例會分散在您使用的 Azure 區域中的多個可用性區域。
  • Azure 儲存體 藉由自動復寫數據至少三次來提供高可用性。 您可以藉由啟用區域備援記憶體 （ZRS） 將這些複本分散到可用性區域，而且在許多區域中，您也可以使用異地備援記憶體 （GRS） 跨區域復寫記憶體數據。
  • Azure SQL 資料庫 有多個複本，以確保即使一個復本失敗，數據仍可供使用。

若要深入瞭解備援，請參閱 設計備援 的建議和使用 可用性區域的建議。

延展性和彈性

延展性和彈性是系統藉由新增和移除資源（延展性）來處理增加負載的能力，以及隨著需求變更而快速處理（彈性）。 延展性和彈性可協助系統在尖峰負載期間維護可用性。

許多 Azure 服務都支援延展性。 以下列出一些範例：

延展性是部分或完整故障期間要考慮的一個關鍵因素。 如果復本或計算實例無法使用，其餘元件可能需要承擔更多負載，以處理先前由錯誤節點處理的負載。 如果您的系統無法快速調整以處理負載中預期的變更，請考慮 過度 布建。

如需如何設計可調整和彈性系統的詳細資訊，請參閱 設計可靠調整策略的建議。

零停機時間部署技術

部署和其他系統變更會造成停機的重大風險。 由於停機時間風險是高可用性需求的挑戰，因此請務必使用零停機時間部署做法來進行更新和設定變更，而不需要任何必要的停機時間。

零停機部署技術可能包括：

  • 一次更新資源的子集。
  • 控制到達新部署的流量量。
  • 監視對您用戶或系統的任何影響。
  • 快速補救問題，例如復原至先前已知良好的部署。

若要深入瞭解零停機部署技術，請參閱 安全部署做法。

Azure 本身會針對我們自己的服務使用零停機時間部署方法。 當您建置自己的應用程式時，您可以透過各種方法採用零停機時間部署，例如：

雖然零停機時間部署通常與應用程式部署相關聯，但也應該用於設定變更。 以下是您可以安全地套用設定變更的一些方式：

  • Azure 儲存體 可讓您在多個階段變更記憶體帳戶存取金鑰，以避免在金鑰輪替作業期間停機。
  • Azure 應用程式組態 提供功能旗標、快照和其他功能，以協助您控制套用設定變更的方式。

如果您決定不實作零停機部署，請確定您定義 維護期間 ，以便使用者預期時進行系統變更。

自動化測試

請務必測試解決方案能夠承受您考慮在HA範圍內發生的中斷和失敗。 許多這些失敗都可以在測試環境中模擬。 測試解決方案自動容許或從各種錯誤類型復原的能力稱為 混亂工程。 混亂工程對於具有嚴格 HA 標準的成熟組織而言非常重要。 Azure Chaos Studio 是一種混亂工程工具，可模擬一些常見的錯誤類型。

若要深入瞭解，請參閱 設計可靠性測試策略的建議。

監視和警示

監視可讓您知道系統的健康情況，即使自動化風險降低也一起發生。 監視對於瞭解解決方案的行為非常重要，並監視失敗的早期訊號，例如增加錯誤率或高資源耗用量。 透過警示，您可以主動接收環境中的重要變更。

Azure 提供各種監視和警示功能，包括下列各項：

如需詳細資訊，請參閱 設計可靠監視和警示策略的建議。

災害復原

災害是一個明顯、罕見、重大事件，其影響比應用程式可透過其設計的高可用性層面來減輕影響。 災害範例包括：

  • 自然災害，如颶風、地震、洪水或火災。
  • 造成重大影響的人為錯誤，例如意外刪除生產數據，或公開敏感數據的設定錯誤防火牆。
  • 重大安全性事件，例如阻斷服務或勒索軟體攻擊，導致數據損毀、數據遺失或服務中斷。

災害復原 是關於規劃如何回應這些類型的情況。

注意

您應該遵循解決方案的建議做法，以將這些事件的可能性降到最低。 不過，即使在仔細主動規劃之後，您還是謹慎地規劃在發生這些情況時會如何回應這些情況。

災害復原需求

由於災害事件的罕見性和嚴重性，DR 規劃會為您的回應帶來不同的期望。 許多組織都接受一個事實，即在災害案例中，某些層級的停機時間或數據遺失是不可避免的。 完整的DR方案必須為每個流程指定下列重要的商務需求：

  • 恢復點目標 （RPO） 是發生災害時可接受的數據遺失持續時間上限。 RPO 是以時間單位來測量，例如「30 分鐘的數據」或「四小時的數據」。

  • 復原時間目標 （RTO） 是發生災害時可接受的停機時間上限，其中您的規格會定義「停機時間」。 RTO 也會以時間單位來測量，例如「八小時的停機時間」。

RTO 和 RPO 持續時間以小時為單位的螢幕快照。

工作負載中的每個元件或流程可能都有個別的 RPO 和 RTO 值。 在決定需求時，檢查災害案例風險和潛在復原策略。 指定 RPO 和 RTO 的程式，會因為您唯一的商務考慮（成本、影響、數據遺失等）而有效地為您的工作負載建立 DR 需求。

注意

雖然的目標是以零的 RTO 和 RPO 為目標（在發生災害時不會停機且不會遺失任何數據），但實際上實作是困難且成本高昂的。 技術和商業專案關係人必須一起討論這些需求，並決定實際的需求。 有關詳細資訊，請參閱定義可靠性目標的建議。

災害復原方案

不論災害原因為何，請務必建立妥善定義且可測試的DR計劃。 該計劃將作為基礎結構和應用程式設計的一部分，以積極支援它。 您可以針對不同類型的情況建立多個DR方案。 DR 計劃通常依賴程式控制和手動介入。

DR 不是 Azure 的自動功能。 不過，許多服務確實提供可用來支援DR策略的功能。 您應該檢閱 每個 Azure 服務 的可靠性指南，以瞭解服務的運作方式及其功能，然後將這些功能對應至DR方案。

下列各節列出災害復原計劃的一些常見元素，並說明 Azure 如何協助您達成這些計劃。

容錯移轉和容錯回復

某些災害復原計劃牽涉到在另一個位置布建次要部署。 如果災害影響解決方案的主要部署，流量就可以 故障轉移 至其他月臺。 故障轉移需要仔細規劃和實作。 Azure 提供各種服務來協助故障轉移，例如：

故障轉移程式通常需要一些時間，才能偵測主要實例失敗，並切換至次要實例。 請確定工作負載的 RTO 與故障轉移時間一致。

也請務必考慮 容錯回復，這是復原主要區域后還原作業的程式。 容錯回復對規劃和實作可能十分複雜。 例如，在故障轉移開始之後，主要區域中的數據可能已經寫入。 您必須針對如何處理該數據做出仔細的商務決策。

備份

備份牽涉到擷取數據的複本，並安全地儲存一段時間。 透過備份，您可以在無法自動故障轉移到另一個複本時，或發生數據損毀時，從災害中復原。

使用備份作為災害復原計劃的一部分時，請務必考慮下列事項：

  • 儲存位置。 當您使用備份做為災害復原計劃的一部分時，應該分別儲存到主要數據。 備份通常會儲存在另一個 Azure 區域中。

  • 數據遺失。 由於備份通常不常進行，因此備份還原通常牽涉到數據遺失。 基於這個理由，備份復原應該作為最後手段使用，而災害復原計劃應該指定從備份還原之前必須進行的步驟和復原嘗試順序。 請務必確定工作負載 RPO 與備份間隔一致。

  • 復原時間。 備份還原通常需要時間，因此請務必測試備份和還原程式，以確認其完整性，並瞭解還原程式需要多久時間。 請確定工作負載的 RTO 帳戶是還原備份所需的時間。

許多 Azure 資料和記憶體服務都支援備份，例如：

  • Azure 備份 提供虛擬機磁碟、記憶體帳戶、AKS 和其他各種來源的自動備份。
  • 許多 Azure 資料庫服務，包括 Azure SQL 資料庫 和 Azure Cosmos DB，都有資料庫的自動備份功能。
  • Azure 金鑰保存庫 提供功能來備份您的秘密、憑證和密鑰。

自動部署

若要在發生災害時快速部署和設定所需的資源，請使用基礎結構即程式代碼 （IaC） 資產，例如 Bicep 檔案、ARM 範本或 Terraform 組態檔。 相較於手動部署和設定資源，使用 IaC 可減少復原時間和發生錯誤的可能性。

測試和鑽研

請務必定期驗證和測試DR計劃，以及更廣泛的可靠性策略。 在您的演練中包含所有人類程式，而不只是專注於技術程式。

如果您尚未在災害模擬中測試復原程式，在實際災害中使用復原程式時，更有可能面臨重大問題。 此外，藉由測試DR方案和必要程式，您可以驗證 RTO 的可行性。

若要深入瞭解，請參閱 設計可靠性測試策略的建議。

相關內容