Microsoft 的同仁一向努力確保提供您需要的服務。 不過，發生非計劃性服務中斷。 本文說明它們執行時會發生什麼事。
Microsoft為其許多服務提供服務等級協定（SLA），作為運行時間和連線能力的承諾。 個別的 Azure 服務 SLA 位於 Azure 服務等級協定。
瞭解事件範圍
當發生事件時，如果您瞭解該事件的範圍，您可以判斷最佳行動路線。
若要瞭解事件的範圍，請遵循下列步驟：
移至 Azure 服務健康情況，其提供：
可能會影響您服務的問題或事件 相關信息。
自動事件更新警示，讓您可以自動收到任何事件狀態更新的通知。 當Microsoft瞭解事件的範圍時，我們會更新事件狀態。 您可以將這些狀態更新設定為移至 Azure 監視器動作群組，以將警示傳送至電子郵件地址或您自己的事件管理系統等各種位置。
如果您在存取 Azure 入口網站 時遇到問題，請移至 Azure 狀態。
如果狀態頁面發生問題，請檢查 社交平臺上 X @AzureSupport 文章。
可用性區域和數據中心事件
許多問題僅限於單 一可用性區域。 可用性區域代表與相同區域中其他可用性區域隔離的數據中心或數據中心群組。 當可用性區域遇到問題時，您看到的影響取決於服務部署的方式：
- 釘選到受影響可用性區域的區域性服務 可能會受到影響。
- 區域備援服務 不太可能受到影響。 您不需要對區域備援資源採取任何補救動作。
- 區域（非區域性）服務 可能會受到影響，因為它們可能會使用受影響的可用性區域。
若要深入瞭解 Azure 服務中的可用性區域支援，以及區域、區域備援和區域（非區域）服務之間的差異，請參閱 具有可用性區域支援的 Azure 服務。
如果對於部署在受影響可用性區域中的區域性或區域資源有任何疑慮，請考慮起始商務 持續性 和 災害復原 （BC/DR） 方案。
邏輯與實體可用性區域
每個 Azure 訂用帳戶都會看到不同的可用性區域清單。 每個訂用帳戶所使用的邏輯區域可能會對應至不同的實體區域。 您可以在邏輯區域與實體區域之間對應，以確認哪些資源在受影響的實體可用性區域中執行。 如需詳細資訊，請參閱 實體和邏輯可用性區域。
全區域事件
有時候，問題會影響整個區域。 當區域沒有可用性區域時，可能會發生全區域問題。 發生全區域事件時，您可能需要考慮 起始災害復原計劃。 您計劃可能包括故障轉移至另一個區域。
排定商務持續性的優先順序
面對事件時，首要任務是讓您的商務營運持續運作。 過於專注於隔離或修正問題的原因，可能會轉移您的注意力，使其無法還原解決方案的作業和維護商務持續性。
下列因素會呈現您不一定需要執行任何動作才能保留商務持續性的情況：
問題對生產資源，以及使用者或工作負載的實際影響 。 例如，在標準上班時間以外發生的問題可能不需要您立即執行任何動作。
事件的範圍。 針對隔離至單一可用性區域的問題，如果您使用區域備援資源，或您使用的資源位於未受影響的實體可用性區域，則不需要執行任何動作。
如果有的話，預估的解決時間。 Microsoft努力儘快提供明確的復原時程表。 如果您的復原程式需要相當長的時間才能運作，請考慮問題是否預期會在完成時解決。
如果您擁有服務等級目標， 則為受影響的工作負載使用者所建立的服務等級目標。 SLO 在這類情況下會引導決策。 例如，在某些情況下，您可能能夠切換至手動作業，直到服務狀況良好，且此決策可能會反映在系統的 SLO 中。 若要深入瞭解 SLO 以及如何定義它們，請參閱 在 Azure Well-Architected Framework 中定義可靠性目標 的建議。
不過，如果商務持續性需要某種形式的動作，而且您確實已備妥災害復原計劃，則下一個步驟是考慮是否起始該計劃。
考慮災害復原計劃
災害復原計劃會說明您預期在發生重大事件時要執行的動作。 災害復原計劃通常包含如下的動作：
- 針對可用性區域內的隔離中斷，如果可以的話，請相應放大資源。
- 對於使用區域服務時的可用性區域中斷，請部署到另一個可用性區域，並故障轉移至另一個可用性區域。
- 對於使用區域備援服務時的可用性區域中斷，您可能不需要執行任何動作。 如果您觀察到效能問題，請考慮相應放大您的資源，讓其餘區域中的實例可以處理它們收到的流量流入。
- 針對區域性中斷，請部署到另一個區域並故障轉移。
重要
不要在沒有思考任何動作的情況下採取任何動作。 匆忙的決定有時會使事情變得更糟。 如果您已經開發涵蓋案例的災害復原計劃，通常最好使用，而不是在目前建立計劃。
故障轉移可以是複雜的程式。 只有在您可以證明成本和風險合理時，才應該觸發故障轉移。 在某些情況下，可能會導致數據遺失，例如，在開始任何停機時間之前，區域之間沒有複寫最近的變更。 您也可能會遇到停機時間，特別是如果您需要將流量重新導向至不同區域中的部署。 根據解決方案的設計方式，您可能需要更新 DNS 記錄，並等候它們傳播。
Microsoft 起始的容錯移轉
某些 Azure 服務會在事件期間自動故障轉移至替代區域。 Microsoft管理這些服務的故障轉移程式。 不過，Microsoft起始的故障轉移通常會以最後手段執行，並在復原嘗試花費大量時間之後執行。 一般而言，Microsoft的原則是盡可能減少數據遺失，即使這表示復原時間更長。 您不應該只依賴自己解決方案的Microsoft起始故障轉移，特別是如果您需要將復原時間降到最低。 如果可以，請針對 Azure 儲存體 等服務使用客戶起始的故障轉移。
Azure 支援
如果服務事件已在 Azure 服務健康狀態中傳達，則會在那裡提供所有最新資訊，而且不需要開啟支援要求。
不過，您可能會考慮在下列情況下開啟支援案例：
您會在 Azure 服務健康狀態的事件描述中看到未涵蓋的問題。
您需要Microsoft的協助，作為復原工作的一部分。
提示
如果您受到服務中斷的影響，在問題降低之後最多 72 小時，您就能夠提出免費支援票證，以協助您採取任何可能需要進行復原的步驟。
開啟支援案例時，請清楚說明受影響的資源，以及問題的影響。 指定發生問題的 Azure 訂用帳戶標識碼和區域。 根據對企業的影響，設定支援案例的嚴重性。 請注意，在上述條件以外的 Azure 服務中斷期間，許多客戶可能會主動連絡 Azure 支援。 這增加了 Azure 支援 資源的負載，很不幸會延遲解決您的支援需求。
事件發生後
若要瞭解事件所學到的內容Microsoft，請從 Azure 服務健康狀態的 [健康情況歷程記錄] 窗格，或透過客戶設定的服務健康狀態警示，閱讀 [事後事件檢閱][PIR]。 不同的事件可能會取得不同類型的 PIR。 初步 PIR 通常會在事件發生後幾天發佈，而較完整的 PIR 會在幾周後公佈。
針對在我們的公用狀態頁面上列出的重大事件，請加入 Azure 事件回顧即時串流以取得任何問題，或 觀看錄製。
如果您認為您可能有資格獲得 SLA 點數， 請建立具有問題類型「退款要求」的新支援要求 ，並包含事件追蹤標識符。
請考慮您可以從事件中學到的內容，以改善自己的復原能力和程式。 請考慮下列問題：
災害復原計劃如何運作？ 您是否可以進行任何改進？ 如需詳細資訊，請參閱 Azure 架構完善的災害復原策略指導方針。
您的事件回應是否適合其嚴重性？ 如果不是，是否有辦法讓您獲得更好的資訊，並做出更好的決定該怎麼做？
您所使用的服務是否有 Azure 服務可靠性指南 ？ 可靠性指南提供可設定多少 Azure 服務以符合復原需求的資訊。
您是否可以進行設計取捨，以在未來改善這類問題的復原能力？ 如需詳細資訊，請參閱 Azure Well-Architected Framework 的可靠性要素。
現在您遇到這種非計劃性中斷，SLO 或 SLA 是否仍然適用？ 現在，您可以重新審視您對用戶基礎所做的承諾，以符合您從此事件學到的內容的期望。
您是否應將 Azure 服務健康狀態警示設定為自動收到任何未來事件的通知？
如果您有如何改善事件回應的意見反應，請透過您指派的Microsoft代表，或透過 Azure 意見反應網站讓我們知道。