Microsoft 365 中的內建服務復原

Microsoft能夠辨識需要提供一致運作的解決方案，並以客戶可以依賴的方式維持高可用性。 當任何指定的服務無法使用時，稱為停機時間。 每個 Microsoft 365 服務的停機時間定義可能不同，但它們通常會集中在使用者無法使用服務基本功能的任何一段時間。 例如，以下是從 Microsoft 365 服務等級協定取得的 SharePoint 停機時間定義：

「SharePoint 停機時間：用戶無法讀取或寫入其具有適當許可權之 SharePoint 網站集合的任何部分的任何一段時間。」

您可以在服務等級協定中尋找每個服務的停機時間定義。

為了將停機時間降至最低 (無論是計劃中或非預期的)，Microsoft 365 服務的設計和運作是要高度可用並對失敗具復原能力，其方法是專注於四個區域：

主動/主動設計

在 Microsoft 365 中，我們正致力於讓所有服務在主動/主動設計中架構及運作，以增加復原能力。 此設計表示一律有多個服務實例在執行中，可以回應使用者要求，而且它們裝載於地理位置分散的數據中心。 所有使用者流量會透過 Microsoft Front Door 服務進入，並會自動路由所找到最佳的服務執行個體，並解決任何服務失敗，以防止或減少對客戶的影響。

減少事件範圍

服務事件的範圍是由嚴重程度、其持續時間和受影響的客戶數來衡量。 我們透過下列方式努力限制所有事件的範圍：

• 讓每個服務的多個執行個體彼此分開
• 以受控制、使用驗證環的漸進方式來部署更新，這樣一來，可能從更新引發的任何問題就可以在部署程序中及早偵測並緩和。 此設計可讓您視需要在內部環形) 內 Microsoft (的小型群组中进行更新回归，然後先在內部環) 內的小型群組中進行部署，例如所有 140,000 Microsoft員工 (環 2) ，然後針對早期採用者通道 (環 3) ，最後針對全域 (環 4) 的所有客戶。
• 透過自動化來使得監控獲得改善。 Microsoft 365 是大型服務，且 SLA 目標運行時間很高。 在服務事件的最開始時，如果需要人員參與偵測和回應，我們便無法以夠快的速度回應來滿足 SLA。 自動化是快速且有效的服務事件偵測和回應的關鍵。 越快找到問題，便能越快解決問題。

除了Microsoft 365服務架構內建的作用中/主動功能，這些工作可降低服務事件期間受影響客戶的嚴重性、持續時間和數目。

錯誤隔離

正因為服務是以主動/主動的方式設計和作業，並彼此分開，以避免其中一個發生問題會影響另一個，因此服務的基礎程式碼是使用稱為錯誤隔離的類似分割準則來開發。 錯誤隔離措施是在基礎程式碼內本身進行的累加的保護。 這些措施可協助防止一個區域中的問題從串聯到其他作業區域。

錯誤隔離量值會在服務開發和傳遞的多個階段套用，包括程式代碼開發、服務部署、負載平衡和資料庫複寫。

Microsoft 安全性開發生命週期 (SDL) 進一步提升復原能力，並包含一組支援安全性與合規性需求的做法。 SDL 可指引我們的開發人員建立具備復原能力、安全與合規性的服務。 SDL 的重要元素包括程式碼檢閱、威脅模型、滲透測試，以及整個 Microsoft 雲端標準化的事件回應程序。

Microsoft 365 服務高度互連，但其背後的系統和技術是以一種限制一個服務事件的影響，使其無法溢出至其他服務的方式進行工程設計。 例如，影響 Exchange 的問題不會影響 Teams 中的核心功能，或 SharePoint 中的搜尋功能問題不會影響使用者上傳或下載檔的能力。

持續改善服務

當我們遇到事件時，我們會認真對待。 畢竟，我們的備援雲端架構和嚴謹的內部程序目標都是要讓我們的服務保持可存取。 在事件期間，我們的監視會快速偵測受影響的服務，如果您的租使用者受到影響，您會透過各種通道收到通知。 同時，工程師會依照定義明確的程序來對問題進行分級，並採取必要的步驟儘快恢復正常作業。 服務再次正常運作之後，我們會舉行事件後檢討，做為持續改善服務週期的一部分。 在事件後檢討期間，我們會找出事件的根本原因，以及修正問題所需的項目。 然後我們會從狀況中習得了教訓，並將它套用到我們所有產品套件的設計與運作。 有了這項知識，我們可以防止相同的根本原因影響其他服務和其他客戶。