Azure 可靠性文件

發行項
03/27/2024

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

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)。

共用方式為