Azure 可靠性文件

  • 發行項

可靠性包含兩個原則：復原和可用性。 復原的目標是要避免失敗，如果仍然發生失敗，請將您的應用程式回復為正常運作的狀態。 可用性的目標是提供應用程式或工作負載的一致存取權。 請務必根據應用程式需求規劃主動式可靠性。

Azure 包含了內建的可靠性服務，您可以根據業務需求來使用和管理。 無論是單一硬體節點失敗、機架層級失敗、資料中心中斷或大規模區域性中斷，Azure 都能提供改善可靠性的解決方案。 例如，可用性設定組可確保 Azure 上部署的虛擬機器會分散到叢集中多個各自獨立的硬體節點。 可用性區域可保護客戶的應用程式和資料，避免區域內多個實體位置的資料中心失敗。 區域和可用性區域是應用程式設計和復原策略的核心，本文稍後會更詳細地討論。

Azure 可靠性文件提供了 Azure 服務的可靠性指引。 本指南包含可用性區域支援、災害復原指引和服務可用性的相關資訊。

如需詳細的服務特定可靠性指引，包括可用性區域、災害復原或高可用性，請參閱 Azure 服務特定的可靠性指引概觀。

如需有關 Microsoft Azure 服務可靠性和可靠性原則與結構的資訊，請參閱 Microsoft Azure Well-Architected Framework：可靠性。

可靠性需求

任何 Azure 解決方案所需的可靠性層級，都取決於數個考量。 可用性和延遲 SLA 和其他業務需求會推動架構選擇和復原層級，因此應首先列入考慮。 可用性需求的範圍從可接受的停機時間 (以及停機時間造成的業務成本)，到您實際可以投入多少金錢和時間來研發具有高可用性的應用程式。

在 Azure 上建置可靠性系統屬於共同責任。 Microsoft 負責雲端平台的可靠性，包括其全球網路和資料中心。 Azure 客戶和合作夥伴負責復原其雲端應用程式，根據每個工作負載的需求使用架構最佳做法。 雖然 Azure 持續努力在雲端平台的 SLA 中實現盡可能高的復原能力，但您必須為解決方案中的每個工作負載定義自己的目標 SLA。 SLA 可讓您評估架構是否符合商務需求。 當您致力於提高 SLA 保證執行時間百分比時，實現該可用性層級的成本和複雜性就會增加。 百分之 99.99 的執行時間，相當於每個月的總停機時間約五分鐘。 以額外的複雜性和成本來達到該百分比，到底值不值得？ 答案需視個別業務需求而定。 在決定最終 SLA 承諾用量時，請了解 Microsoft 支援的 SLA。 每項 Azure 服務都有其 SLA。

Diagram showing the shared responsibility model for Azure business continuity.

在傳統的內部部署模型中，從計算、記憶體和網路的硬體到應用程式，管理的全部責任都落在您身上。 您必須規劃各種類型的失敗，以及如何藉由建立災害復原策略來處理這些失敗。 使用 IaaS 時，雲端服務提供者負責核心基礎結構復原功能，包括記憶體、網路和計算。 當您從 IaaS 移至 PaaS，然後移至 SaaS 時，您會發現您負責較少，而雲端服務提供者則負責更多。  

如需可靠性原則的詳細資訊，請參閱架構完善的架構可靠性文件。  

建置可靠性

您應該在剛開始規劃時，就定義應用程式的可靠性需求。 如果您知道哪些應用程式在特定時段內不需要 100% 的高可用性，您可以在這些非危急期間將成本最佳化。 識別應用程式可能會遇到的失敗類型，以及每個失敗可能造成的潛在影響。 復原方案應該透過在個別元件和整體應用程式層級完成復原策略，來涵蓋所有重要服務。 設計您的復原策略，以防止區域性、地區和應用程式層級失敗。 執行端對端應用程式環境的測試，以測量應用程式可靠性和出現非預期失敗時的復原能力。

下列檢查清單涵蓋可靠性規劃的範圍。

可靠性規劃
定義可用性和復原目標以符合業務需求。
根據可用性需求設計應用程式的可靠性功能。
調整應用程式和資料平台以符合可靠性需求。
設定連線路徑以提升可用性。
在適用的情況下，使用可用性區域和災害復原規劃來改善可靠性及最佳化成本。
確保應用程式結構可從失敗中復原。
了解如果不符合 SLA 要求，會發生什麼情況。
識別系統中可能的失敗點；應用程式設計應該藉由進行斷路部署來容許相依性失敗。
建置可以在沒有相依性情況下運作的應用程式。

RTO 和 RPO

所需考慮的兩個重要指標是復原時間目標和復原點目標，因為這兩者與災害復原有關。  如需功能與非功能性設計需求的詳細資訊，請參閱架構完善的架構功能和非功能性需求。

  • 復原時間目標 (RTO) 是應用程式在事件之後可能無法使用的最大可接受時間。

  • 復原點目標 (RPO) 是在災害期間可接受的最大資料遺失時間長度。

RTO 和 RPO 是系統中的非功能性需求，並且應該依照商務需求來設定。 若要衍生這些值，建議方法是進行風險評估，並清楚地了解停機或資料遺失的成本。  

地區與可用性區域

區域和可用性區域是可靠性方程式的主要部分。 區域具有多個實際分隔的可用性區域。 這些可用性區域是透過實體區域之間的高效能網路 (延遲低於 2 毫秒) 進行連線。 低延遲可協助您的資料保持同步，並在意外發生時可供存取。 當您架構應用程式和資料基礎結構，來自動複寫及提供區域之間與跨地區的不中斷服務，您可以策略性使用此基礎結構，。

Microsoft Azure 服務支援可用性區域，啟用後能夠以最佳高可用性推動您的雲端作業，同時支援跨區域復原和業務持續性策略需求。

針對災害復原規劃，與其他區域配對的區域提供跨區域複寫，並透過以異步方式複寫其他 Azure 區域的資料來提供保護。 沒有配對的區域遵循資料落地指導方針，並提供具有可用性區域和本地備援或區域備援記憶體的高可用性。 客戶必須根據其 RTO/RPO 需求來規劃其跨區域災害復原。

根據技術和法規考量 (服務功能、資料落地、合規性需求、延遲)，針對您的需求選擇最佳區域，開始提升您的可靠性策略。 如需詳細資訊，請參閱 Azure 區域與可用性區域。

Azure 服務相依性

Microsoft Azure 服務可供全球使用，以最佳水準推動您的雲端作業。

部署至 Azure 區域的 Azure 服務會列在 Azure 全域基礎結構產品頁面上。 若要進一步了解 Azure 中的區域和可用性區域，請參閱 Azure 中的區域和可用性區域。

Azure 服務是專為達成可靠性目的所建置，包括高可用性和災害復原。 沒有任何服務相依於單一邏輯資料中心 (以避免單一失敗點)。 Azure 全域基礎結構產品上列出的非區域服務，是特定 Azure 區域上沒有相依性的服務。 非區域服務會部署至兩個或多個區域，如果發生區域性失敗，另一個區域中的服務執行個體會繼續提供客戶服務。 某些非區域服務可讓客戶指定區域，以便在該區域中部署執行服務的基礎虛擬機器 (VM)。 例如，Azure 虛擬桌面可讓客戶指定 VM 所在的區域位置。 所有儲存客戶資料的 Azure 服務都允許客戶指定儲存其資料的特定區域。 例外狀況是 Microsoft Entra ID，其具有地理位置位置 (例如歐洲或北美)。 如需資料儲存體落地的詳細資訊，請參閱資料落地地圖。

如果您需要了解 Azure 服務之間的相依性，以協助更妥善架構您的應用程式和服務，您可以連絡您的 Microsoft 銷售或客戶代表，索取 Azure 服務相依性文件。 本文件列出適用於 Azure 服務的相依性，包括任何常見的主要內部服務相依性，例如控制平面服務。 若要取得本文件，您必須是 Microsoft 客戶，並與 Microsoft 簽訂適當的保密協定 (NDA)。

下一步