在移轉之前補救資產

  • 發行項

在移轉評估程序期間，小組會識別任何可能使資產與所選雲端提供者不相容的設定。 補救是移轉程式中的檢查點，可用來解決任何不相容問題。

本文說明一些常見的補救工作，並協助您判斷補救是否為明智的投資。

補救類型

在整個部署中，您需要規劃的補救活動有兩種主要類型。

  • 根據評估活動的結果
    • 需要完成才能允許複寫和部署的補救活動。
    • 您在評估階段的工作負載評量中判斷這些補救活動。 您必須執行這些工作，以確保您可以在雲端中正確複寫和暫存工作負載。
    • 這主要著重於要移轉的來源伺服器。
  • 根據測試活動的結果
    • 這來自 測試移轉活動和 執行 商務測試。
    • 這些補救活動著重於複寫目的地伺服器的設定，以及負載平衡器、虛擬網路和記憶體帳戶等任何輔助服務。
    • 這些工作可能會更反覆。 測試並補救經過數個週期，直到所有測試案例都預期通過為止。

追蹤補救活動

在整個反覆專案中，您可以透過評量或測試來識別工作負載的補救工作。 您必須將這些工作追蹤為項目活動，以確保它們已完成。

雖然小型移轉波可以使用電子表格來追蹤專案，但具有許多補救工作的較大波會產生多個專案。 您可以使用 Azure DevOps 之類的工具來建立和排定工作專案的優先順序，並移至特定階段，以協助您相應放大。即使您未針對其他工作使用 Azure DevOps，您也可以使用它來分級補救問題，並組織移轉程式的工作。

當您建立這些工作時，請務必將它們連線回受影響的工作負載。 這可讓您評估補救工作可能會延遲哪些工作負載。 然後，您可以依工作負載優先順序來排定工作優先順序。

有些問題可能會影響多個工作負載。 這些通常是主機的專案、廣泛的設定，或整個登陸區域的問題。 這些問題應該是排定補救優先順序的第一個問題。

常見的補救工作

技術債務是公司環境的健康預期部分。 適用於內部部署環境的架構決策可能不適合在雲端平臺中。 在任一情況下，可能需要一般補救工作來準備資產以進行移轉。 以下是一些範例：

  • 次要主機升級：有時候必須在復寫之前升級過時的主機。
  • 次要客體作業系統升級：您可能需要在複寫之前修補或升級操作系統。
  • 服務等級協定 （SLA） 修改：備份和復原程式在雲端平臺中大幅變更。 可能需要修改已移轉資產的備份程式，以確保它們能夠繼續在雲端達到其必要的 SLA。
  • 應用程式設定變更：移轉的應用程式可能需要調整相依資產的網路路徑、服務帳戶變更或相依IP位址的更新等變數。
  • 網路路徑的次要變更：必須修改路由模式，才能適當地將使用者流量路由傳送至新的資產。 這不是對新資產的生產路由，而是設定以允許一般適當路由傳送至資產。

大規模補救工作

當數據中心正確維護、修補和更新時，就不需要進行補救。 補救豐富的環境往往在大型企業中很常見。 這可包括大型 IT 縮減、舊版受控服務和大量下載環境下的組織。 在這些環境中，補救包含大部分的移轉工作。 下列補救工作可能會經常發生，或對移轉速度或一致性造成負面影響。 如果發生這種情況，請將補救分成類似雲端採用和雲端治理的平行工作和小組。

  • 經常升級主機：升級多個主機以完成工作負載的移轉可能會延遲移轉小組。 隔離受影響的應用程式並解決補救步驟，再將受影響的應用程式包含在任何計劃版本中。
  • 經常升級客體操作系統：大型企業通常會在過時的Linux或Windows版本上執行伺服器。 除了操作過時操作系統的安全性風險之外，也有不相容的問題，導致受影響的工作負載無法移轉。 當多部虛擬機 （VM） 需要操作系統補救時，請嘗試將這些工作分成平行反覆專案。 移轉工具可完成某些升級，作為移轉程式的一部分，例如 Azure Migrate 和現代化中的 Windows Server 升級 功能。

解決大規模的補救

因為較小工作負載的補救可能很簡單，因此請為初始移轉波選擇較小的工作負載。 隨著移轉工作成熟，您開始處理較大的工作負載，補救可能會很耗時且成本高昂。 例如，Windows Server 2003 移轉的補救工作涉及超過 5,000 部 VM 的資產集區，可能會延遲移轉數月。 需要這類大規模補救時，您可能需要變更移轉受影響工作負載的計劃。 在這種情況下，將補救工作價值最大化的現代化活動可能更有效率且具生產力。

您可以使用下列問題來協助引導決策：

  • 是否已在移轉待處理項目中識別並註明所有受補救影響的工作負載？
  • 對於不會影響的工作負載，移轉會產生類似的投資報酬率（ROI）嗎？
  • 受影響的資產是否可以與原始移轉時程表一致進行補救？ 時間軸變更對 ROI 有何影響？
  • 與移轉工作平行補救資產是否可行？

如果未回答上述問題，請考慮下列現代化方法：

  • 容器化：某些資產可以裝載於容器化環境中，而不需要補救。 這可能會產生較不有利的效能，且無法解決安全性或合規性問題。
  • 自動化：視工作負載和補救需求而定，使用DevOps方法將部署編寫至新資產的腳本可能更有利可圖。
  • 重建：當補救成本和業務價值同樣高時，工作負載很適合重建或重新架構。

後續步驟

復寫資產