特定 Azure 服務的復原檢查清單

  • 發行項

復原是系統從失敗中復原並繼續運作的能力。 每個技術都有自己的特定失敗模式，您必須在設計和實作應用程式時加以考慮。 使用此檢查清單來檢閱特定 Azure 服務的復原考慮。 如需設計復原應用程式的詳細資訊，請參閱 設計可靠的 Azure 應用程式。

應用程式服務

使用標準層或進階層。 這些層支援預備位置和自動備份。 如需詳細資訊，請參閱 Azure App 服務 計劃深入概觀

避免相應增加或減少。 相反地，請選取符合一般負載下效能需求的階層和實例大小，然後 相應放大 實例來處理流量變更。 相應增加和減少可能會觸發應用程式重新啟動。

將設定儲存為應用程式設定。 使用應用程式設定將組態設定保留為應用程式設定。 定義 Resource Manager 範本中的設定，或使用 PowerShell，讓您可以將其套用為自動化部署/更新程式的一部分，更可靠。 如需詳細資訊，請參閱在 Azure App 服務 中設定 Web 應用程式。

為生產與測試建立個別的App Service方案。 請勿在生產部署上使用位置進行測試。 相同 App Service 方案內的所有應用程式都會共用相同的 VM 實例。 如果您將生產與測試部署放在相同的計劃中，可能會對生產部署造成負面影響。 例如，負載測試可能會降低即時生產網站。 藉由將測試部署放入個別的計劃，您可以將部署與生產版本隔離。

將 Web 應用程式與 Web API 分開。 如果您的解決方案同時有 Web 前端和 Web API，請考慮將它們分解成個別的 App Service 應用程式。 此設計可讓您更輕鬆地依工作負載分解解決方案。 您可以在個別的 App Service 方案中執行 Web 應用程式和 API，以便獨立調整它們。 如果您一開始不需要該層級的延展性，您可以將應用程式部署至相同的方案，並視需要稍後將它們移至個別的計劃。

部署區域備援 App Service 方案。 在支持的區域中，App Service 方案可以部署為區域備援，這表示實例會自動分散到可用性區域。 App Service 會自動分散區域之間的流量，並在區域發生中斷時處理故障轉移。 如需詳細資訊，請參閱將 App Service 移轉至可用性區域支援。

避免使用 App Service 備份功能來備份 Azure SQL 資料庫。 請改用 SQL 資料庫 自動備份。 App Service 備份會將資料庫導出至 SQL BACPAC 檔案，其成本為 DTU。

部署到預備位置。 建立預備的部署位置。 將應用程式更新部署至預備位置，並在將部署交換至生產環境之前先確認部署。 這樣可減少生產環境中更新不良的機會。 它也可確保所有實例在交換至生產環境之前都會熱身。 許多應用程式都有顯著的熱身和冷啟動時間。 如需詳細資訊，請參閱在 Azure App 服務 中設定 Web 應用程式的預備環境。

建立部署位置以保存最後一個已知良好的 （LKG） 部署。 當您將更新部署到生產環境時，請將先前的生產部署移至 LKG 位置。 這可讓您更輕鬆地復原不正確的部署。 如果您稍後發現問題，您可以快速還原為 LKG 版本。 如需詳細資訊，請參閱 基本 Web 應用程式。

啟用診斷記錄，包括應用程式記錄和 Web 伺服器記錄。 記錄對於監視和診斷很重要。 請參閱在 Azure App 服務 中啟用 Web 應用程式的診斷記錄

記錄至 Blob 記憶體。 這可讓您更輕鬆地收集和分析數據。

為記錄建立個別的記憶體帳戶。 請勿對記錄和應用程式數據使用相同的記憶體帳戶。 這有助於防止記錄降低應用程式效能。

監視效能。 使用 New Relic 或 Application Insights 等效能監視服務來監視負載下的應用程式效能和行為。 效能監視可讓您即時深入解析應用程式。 它可讓您診斷問題並執行失敗的根本原因分析。

Azure Load Balancer

選取 [標準 SKU]。 標準負載平衡器提供基本功能的可靠性維度，也就是可用性區域和區域恢復能力。 這表示當區域關閉時，您的區域備援標準Load Balancer將不會受到影響。 這可確保您的部署能夠承受區域內的區域失敗。 此外，Standard Load Balancer 也支援全域負載平衡，以確保您的應用程式不會受到區域失敗的影響。

布建至少兩個實例。 在後端部署至少有兩個實例的 Azure Load Balancer。 單一執行個體可能會導致單一失敗點。 若要建置規模，您應該將負載平衡器與 虛擬機器擴展集 配對。

使用輸出規則。 輸出規則可確保您因來源網路位址轉換 （SNAT） 埠耗盡而未遇到連線失敗。 深入了解 輸出連線能力。 雖然輸出規則可協助改善小型到中型部署的解決方案，但針對生產工作負載，我們建議將標準負載平衡器或任何子網部署與 VNet 網路地址轉換 （NAT） 結合在一起。

Azure 公用IP

選取 [標準 SKU]。 標準公用IP提供可用性區域和區域復原功能，與基本公用IP不同。 如果使用需要公用IP的服務，請選取區域備援公用IP。 針對現有的IP，請從基本升級為標準，以取得區域備援預設的優點。

應用程式閘道

布建至少兩個實例。 使用至少兩個實例部署 應用程式閘道。 單一實例是單一失敗點。 使用兩個或多個實例進行備援和延展性。 若要符合服務等級協定（SLA）的資格，您必須布建兩個或多個中型或更大的實例。

Azure Cosmos DB

設定區域備援。 當您使用區域備援時，Azure Cosmos DB 會同步複寫可用性區域的所有寫入。 它會在發生區域中斷時自動故障轉移。 如需詳細資訊，請參閱 使用 Azure Cosmos DB 實現高可用性。

跨區域復寫資料庫。 Azure Cosmos DB 可讓您將任意數目的 Azure 區域與 Azure Cosmos DB 資料庫帳戶產生關聯。 Azure Cosmos DB 資料庫可以有一個寫入區域和多個讀取區域。 如果寫入區域中發生失敗，您可以從另一個複本讀取。 用戶端 SDK 會自動處理此作業。 您也可以將寫入區域故障轉移到另一個區域。 如需詳細資訊，請參閱 如何使用 Azure Cosmos DB 全域散發數據。

事件中樞

使用檢查點。 事件取用者應該以某種預先定義的間隔，將其目前位置寫入永續性記憶體。 如此一來，如果取用者遇到錯誤（例如取用者當機或主機失敗），新的實例就可以從最後一個記錄的位置繼續讀取數據流。 如需詳細資訊，請參閱 事件取用者。

處理重複的訊息。 如果事件取用者失敗，訊息處理會從最後一個記錄的檢查點繼續。 在最後一個檢查點之後已經處理的任何訊息都會再次處理。 因此，您的訊息處理邏輯必須是等冪，或者應用程式必須能夠重複資料刪除訊息。

處理 exceptions.。 事件取用者通常會在迴圈中處理一批訊息。 您應該處理此處理迴圈內的例外狀況，以避免在單一訊息造成例外狀況時遺失整個批次的訊息。

使用寄不出的信件佇列。 如果處理訊息會導致非轉譯失敗，請將訊息放入寄不出的信件佇列中，以便追蹤狀態。 視案例而定，您稍後可能會重試訊息、套用補償交易，或採取其他動作。 請注意，事件中樞沒有任何內建寄不出的信件佇列功能。 您可以使用 Azure 佇列記憶體或 服務匯流排 來實作寄不出的信件佇列，或使用 Azure Functions 或其他一些事件機制。

設定區域備援。 在您的命名空間上啟用區域備援時，事件中樞會自動復寫多個可用性區域之間的變更。 如果一個可用性區域失敗，故障轉移就會自動發生。 如需詳細資訊，請參閱可用性區域。

故障轉移至次要事件中樞命名空間，以實作災害復原（DR）。 如需詳細資訊，請參閱 Azure 事件中樞 異地災害復原。

Azure Cache for Redis

設定區域備援。 當您的快取上啟用區域備援時，Azure Cache for Redis 會將裝載快取的虛擬機分散到多個可用性區域。 區域備援會在數據中心中斷時提供高可用性和容錯能力。 如需詳細資訊，請參閱為 Azure Cache for Redis 啟用區域備援。

設定異地複寫。 異地復寫提供連結兩個進階層 Azure Cache for Redis 實例的機制。 寫入主要快取的數據會復寫至次要只讀快取。 如需詳細資訊，請參閱 如何設定 Azure Cache for Redis 的異地複寫

設定數據持續性。 Redis 永續性可讓您保存儲存在 Redis 中的資料。 您也可以擷取快照集並備份數據，以在硬體故障時載入。 如需詳細資訊，請參閱 如何設定進階層 Azure Cache for Redis 的數據持續性

如果您使用 Azure Cache for Redis 作為暫存數據快取，而不是持續性存放區，則這些建議可能不適用。

布建多個複本。 針對讀取高可用性至少使用兩個複本，或使用三個複本進行讀寫高可用性。

使用區域備援。 您可以跨多個可用性區域部署認知搜尋複本。 這種方法可協助您的服務即使在數據中心中斷時仍可維持運作。 如需詳細資訊，請參閱 Azure 認知搜尋 中的可靠性

設定多區域部署的索引器。 如果您有多區域部署，請考慮索引編製持續性的選項。

  • 如果數據源是異地復寫的，您通常應該將每個區域 Azure 認知搜尋 服務的索引器指向其本機數據源複本。 不過，不建議針對儲存在 Azure SQL 資料庫 的大型數據集使用該方法。 原因是 Azure 認知搜尋 無法從次要 SQL 資料庫 複本執行累加式索引，而只能從主要複本執行。 相反地，將所有索引器指向主要複本。 故障轉移之後，將 Azure 認知搜尋 索引器指向新的主要複本。

  • 如果數據源不是異地復寫，請指向相同數據源的多個索引器，如此一來，Azure 認知搜尋 多個區域中的服務會持續且獨立地從數據源編製索引。 如需詳細資訊，請參閱 Azure 搜尋服務效能和優化考慮。

服務匯流排

針對生產工作負載使用進階層。 服務匯流排 進階傳訊提供專用和保留的處理資源，以及記憶體容量，以支援可預測的效能和輸送量。 進階傳訊層也可讓您存取一開始僅供進階客戶使用的新功能。 您可以根據預期的工作負載來決定傳訊單位數目。

處理重複的訊息。 如果發行者在傳送訊息後立即失敗，或遇到網路或系統問題，它可能會錯誤地無法記錄訊息已傳遞，而且可能會將相同的訊息傳送至系統兩次。 服務匯流排 可以藉由啟用重複偵測來處理此問題。 如需詳細資訊，請參閱重複偵測。

處理例外狀況。 傳訊 API 會在發生使用者錯誤、設定錯誤或其他錯誤時產生例外狀況。 用戶端程式代碼（傳送者和接收者）應該在其程式代碼中處理這些例外狀況。 這在批處理中特別重要，其中例外狀況處理可用來避免遺失整個批次的訊息。 如需詳細資訊，請參閱 服務匯流排 傳訊例外狀況。

重試原則。 服務匯流排 可讓您挑選應用程式的最佳重試原則。 默認原則是允許最多 9 次重試嘗試，並等候 30 秒，但可以進一步調整。 如需詳細資訊，請參閱重試原則 – 服務匯流排。

使用寄不出的信件佇列。 如果訊息在多次重試之後無法處理或傳遞至任何接收者，則會移至寄不出的信件佇列。 實作程式，以從寄不出的信件佇列讀取訊息、檢查訊息，並補救問題。 視案例而定，您可以依目前方式重試訊息、進行變更並重試，或捨棄訊息。 如需詳細資訊，請參閱服務匯流排寄不出的信件佇列的概觀。

使用區域備援。 在您的命名空間上啟用區域備援時，服務匯流排 會自動復寫多個可用性區域之間的變更。 如果一個可用性區域失敗，故障轉移就會自動發生。 如需詳細資訊，請參閱將應用程式與 服務匯流排 中斷和災害隔離的最佳做法。

使用異地災害復原。 異地災害復原可確保如果整個 Azure 區域或資料中心因為災害而無法使用，數據處理會繼續在不同的區域或數據中心運作。 如需詳細資訊，請參閱 Azure 服務匯流排地理災害復原。

儲存體

使用區域備援記憶體 （ZRS）。 區域備援儲存體 (ZRS) 會在主要區域中將資料同步複製到三個 Azure 可用區域。 如果可用性區域發生中斷，Azure 儲存體 會自動故障轉移至替代區域。 如需詳細資訊，請參閱 Azure 儲存體備援 \(部分機器翻譯\)。

使用異地備援時，請設定讀取許可權。 如果您使用多重區域架構，請使用適當的儲存層進行全域備援。 使用讀取許可權異地備援記憶體 （RA-GRS） 或讀取許可權異地區域備援記憶體 （RA-GZRS），您的數據會復寫到次要區域。 RA-GRS 會在主要區域中使用本地備援記憶體 （LRS），而RA-GZRS則會在主要區域中使用區域備援記憶體 （ZRS）。 這兩個組態都提供次要區域中數據的唯讀存取權。 如果主要區域中發生記憶體中斷，如果您已針對這種可能性設計數據，應用程式可以從次要區域讀取數據。 如需詳細資訊，請參閱 Azure 儲存體備援 \(部分機器翻譯\)。

針對 VM 磁碟，請使用受控磁碟。受控磁碟為可用性設定組中的 VM 提供更好的可靠性，因為磁碟彼此之間有足夠的隔離，以避免單一失敗點。 此外，受控磁碟不會受限於記憶體帳戶中建立的 VHD IOPS 限制。 如需詳細資訊，請參閱管理 Azure 中 Windows 虛擬機器的可用性。

針對佇列記憶體，請在另一個區域中建立備份佇列。 針對佇列記憶體，只讀複本的使用有限，因為您無法將專案排入佇列或清除佇列。 相反地，在另一個區域中的記憶體帳戶中建立備份佇列。 如果發生 Azure 儲存體 中斷，應用程式可以使用備份佇列，直到主要區域再次可用為止。 如此一來，應用程式就可以在中斷期間繼續處理新的要求。

SQL Database

使用標準層或進階層。 這些層提供較長的時間點還原期間（35 天）。 如需詳細資訊，請參閱 SQL 資料庫 選項和效能。

啟用 SQL Database 稽核。 稽核可用來診斷惡意攻擊或人為錯誤。 如需詳細資訊，請參閱 開始使用 SQL 資料庫稽核。

使用主動式異地復 寫使用主動式異地複寫，在不同的區域中建立可讀取的次要複本。 如果您的主資料庫失敗，或只需要離線，請執行手動故障轉移至輔助資料庫。 在您故障轉移之前，輔助資料庫會保持只讀狀態。 如需詳細資訊，請參閱 SQL 資料庫 作用中異地複寫。

使用分區化。 請考慮使用分區化水準分割資料庫。 分區化可以提供錯誤隔離。 如需詳細資訊，請參閱使用 Azure SQL 資料庫 向外延展。

使用時間點還原從人為錯誤復原。 時間點還原會將資料庫傳回先前的時間點。 如需詳細資訊，請參閱 使用自動化資料庫備份復原 Azure SQL 資料庫。

使用異地還原從服務中斷復原。 異地還原會從異地備援備份還原資料庫。 如需詳細資訊，請參閱 使用自動化資料庫備份復原 Azure SQL 資料庫。

Azure Synapse Analytics

請勿停用異地備份。 根據預設，Azure Synapse Analytics 會每隔 24 小時在專用 SQL 集區中完整備份一次數據，以進行災害復原。 不建議關閉此功能。 如需詳細資訊，請參閱 異地備份。

在 VM 中執行的 SQL Server

備份資料庫。 如果您已經使用 Azure 備份 備份 VM，請考慮使用 DPM 針對 SQL Server 工作負載使用 Azure 備份。 使用此方法時，組織會有一個備份系統管理員角色，以及 VM 和 SQL Server 的統一復原程式。 否則，請使用 SQL Server 受控備份Microsoft Azure。

流量管理員

執行手動容錯回復。 流量管理員 故障轉移之後，請執行手動容錯回復，而不是自動容錯回復。 在容錯回復之前，請確認所有應用程式子系統都狀況良好。 否則，您可以建立應用程式在數據中心之間來回翻轉的情況。 如需詳細資訊，請參閱 在多個區域中執行 VM 以取得高可用性。

建立健康情況探查端點。 建立自定義端點，報告應用程式的整體健康情況。 這可讓 流量管理員 在任何重大路徑失敗時進行故障轉移，而不只是前端。 如果任何重大相依性狀況不良或無法連線，端點應該會傳回 HTTP 錯誤碼。 不過，請勿報告非關鍵服務的錯誤。 否則，健康情況探查可能會在不需要時觸發故障轉移，並建立誤判。 如需詳細資訊，請參閱流量管理員端點監視和容錯移轉。

虛擬機器

避免在單一 VM 上執行生產工作負載。 單一 VM 部署無法復原計劃性或非計劃性維修。 相反地，將多個 VM 放在可用性設定組或 虛擬機擴展集中，並在前面加上負載平衡器。

當您佈建 VM 時，請指定可用性設定組。 目前，在佈建 VM 之後，無法將 VM 新增至可用性設定組。 當您將新的 VM 新增至現有的可用性設定組時，請務必建立 VM 的 NIC，並將 NIC 新增至負載平衡器上的後端位址池。 否則，負載平衡器不會將網路流量路由傳送至該 VM。

將每個應用層放入個別的可用性設定組。 在多層式應用程式中，請勿將來自不同層的 VM 放入相同的可用性設定組中。 可用性設定組中的 VM 會放在容錯網域 （FD） 和更新網域 （UD） 之間。 不過，若要取得 FD 和 UD 的備援優勢，可用性設定組中的每個 VM 都必須能夠處理相同的用戶端要求。

使用 Azure Site Recovery 複寫 VM。 使用 Site Recovery 複寫 Azure VM 時，所有 VM 磁碟會持續以非同步方式複寫至目標區域。 每隔幾分鐘就會建立一次復原點。 據此，您將獲得以分鐘為單位的復原點目標 (RPO)。 您可以依需求執行不限次數的災害復原演練，而不會影響生產應用程式或進行中的複寫。 如需詳細資訊，請參閱對 Azure 執行災害復原演練。

根據效能需求選擇正確的 VM 大小。 將現有的工作負載移至 Azure 時，請從最符合內部部署伺服器的 VM 大小開始。 然後測量實際工作負載相對於 CPU、記憶體和磁碟 IOPS 的效能，並視需要調整大小。 這有助於確保應用程式在雲端環境中如預期般運作。 此外，如果您需要多個 NIC，請注意每個大小的 NIC 限制。

針對 VHD 使用受控磁碟。受控磁碟為可用性設定組中的 VM 提供更好的可靠性，因為磁碟彼此之間有足夠的隔離，以避免單一失敗點。 此外，受控磁碟不會受限於記憶體帳戶中建立的 VHD IOPS 限制。 如需詳細資訊，請參閱管理 Azure 中 Windows 虛擬機器的可用性。

在資料磁碟上安裝應用程式，而不是OS磁碟。 否則，您可以達到磁碟大小限制。

使用 Azure 備份 備份 VM。 備份可防止意外遺失數據。 如需詳細資訊，請參閱 使用復原服務保存庫保護 Azure VM。

啟用診斷記錄。 包含基本健康情況計量、基礎結構記錄和 開機診斷。 如果您的 VM 進入無法開機狀態，開機診斷可協助您診斷開機失敗。 如需詳細資訊，請參閱 Azure 診斷記錄概觀。

設定 Azure 監視器。 從 Azure 虛擬機器 收集及分析監視數據，包括客體作業系統和其中執行的工作負載，請參閱 Azure 監視器和快速入門：Azure 監視器。

虛擬網路

若要允許或封鎖公用IP位址，請將網路安全組新增至子網。 封鎖惡意使用者的存取，或只允許具有存取應用程式許可權的使用者存取。

建立自定義健康情況探查。 負載平衡器健康情況探查可以測試 HTTP 或 TCP。 如果 VM 執行 HTTP 伺服器，HTTP 探查會比 TCP 探查更好的健康狀態指標。 針對 HTTP 探查，請使用自訂端點來報告應用程式的整體健康情況，包括所有重要的相依性。 如需詳細資訊，請參閱 Azure Load Balancer 概觀。

請勿封鎖健康情況探查。 負載平衡器健康情況探查會從已知的IP位址168.63.129.16傳送。 請勿在任何防火牆原則或網路安全組規則中封鎖此IP的流量。 封鎖健康情況探查會導致負載平衡器從輪替中移除 VM。

啟用 Load Balancer 記錄。 記錄會顯示後端有多少 VM 由於探查回應失敗而未接收網路流量。 如需詳細資訊，請參閱 Azure Load Balancer 的 Log Analytics。