雲端採用架構中的雲端移轉

任何企業級 雲端採用方案 都包含不需要大量投資建立新商務邏輯的工作負載。 這些工作負載可以透過任意數目的方法移至雲端:隨即轉移、隨即轉移、隨即轉移和優化,或現代化。 每個方法都會被視為移轉。

觀看下列影片,以快速瞭解隨即轉移方法。


下列練習可協助建立反復程式,以評估、移轉、優化、保護和管理這些工作負載。

若要為雲端採用生命週期的這個階段做好準備,我們建議您執行下列步驟:

   
遷移您的第一個工作負載:使用 Azure 移轉指南,熟悉 Azure 原生工具和移轉方法。
移轉案例:使用其他移轉工具和方法來處理其他移轉案例。
最佳做法:透過應用程式一致的最佳作法,解決一般的移轉需求。
流程改善:移轉是大量使用流程的活動。 當移轉工作擴展時,請使用這些流程改善,來評估和完善移轉的各個層面。

遷移方法和上述步驟會根據下列假設而建置:

  • 移轉短期衝刺符合移轉波或發行的方法。 您可以使用計畫、就緒和採用方法來定義移轉波或發行。 在每個移轉短期衝刺內,會將一批工作負載移轉至雲端。
  • 移轉工作負載之前,您已識別、設定及部署至少一個 登陸區域 ,以符合短期雲端採用方案的需求。
  • 移轉通常會與「隨即轉移」或「重新裝載」的條款相關聯。 此方法和上述步驟是建置在信念上,認為不應該使用純重新裝載方法來移轉任何資料中心和少數工作負載。 雖然您可以重新裝載許多工作負載,但客戶通常會選擇在每個工作負載中現代化特定資產。 在此反復執行流程中,速度和現代化之間的平衡為常見的討論點。

移轉工作

移轉工作負載所需的動作通常屬於每個工作負載的三個工作或階段:評估工作負載、部署工作負載和發行工作負載。 這一節的「雲端採用架構」內容會教導讀者如何讓將工作負載移轉至生產環境所需的每個階段發揮最大效用。

在標準的兩周反復專案中,有經驗的移轉小組可以完成此程式,以取得 2-5 個低度複雜度工作負載。 更複雜的工作負載 (例如 SAP) 可能需要數個兩周的反覆項目,才能對單一工作負載全數完成三個移轉工作階段。 體驗和複雜度對時間軸和移轉速度會有很大的影響。

Diagram that shows the Cloud Adoption Framework migration effort

下列項目符號將概述此程序的各個階段 (如上圖所示):

  • 評估工作負載: 評估工作負載以評估成本、現代化和部署工具。 此程式著重于驗證或具挑戰性的假設。 您可以在探索和評量期間進行這些假設,方法是更仔細地查看合理化選項。 此程式也是當使用者模式和相依性更仔細地研究時,以確保工作負載在移轉之後將達到技術成功。

    觀看這段影片,以快速概觀完成全面評定。


  • 部署工作負載:在評估工作負載之後,現有的工作負載功能會在雲端中複寫或改善。 此複寫可能會牽涉 到隨即轉移重新裝載 至雲端。 但是,在這個階段中,支援這些工作負載的許多資產都會現代化,以充分利用雲端的優點。

  • 發行工作負載:一旦功能複寫至雲端,就可以測試、優化、記載及發行工作負載以進行進行中的作業。 檢閱已移轉的工作負載並交出這些工作負載在這段程式期間非常重要。 對於持續工作負載支援,治理、作業管理和安全性小組而言,工作非常重要。

注意

在移轉工作的一些早期反復專案中,通常會將範圍限制為單一工作負載。 這種方法可盡可能保留技能,並且讓小組有更多時間進行實驗和學習。

注意

建置移轉處理站時,有些小組可能會選擇將上述各個階段分散到多個小組和多個短期衝刺。 這種方法可以改善可重複性,並加速移轉工作。

遷移波和反覆變更管理

移轉反覆項目可藉由移轉資產和工作負載來提供技術價值。 移轉波是提供可測量商業價值之工作負載的最小集合。 每個反復專案都應該產生一份報表,以概述已完成的技術工作。 不過,商務變更和策略性規劃通常會在較高一點的層級發生。 當雲端採用小組進行移轉工作時,雲端策略小組會著重於規劃後續的 1-2 個移轉波浪。 雲端策略小組也會以學習計量的形式追蹤技術進展,以進一步了解實現商業價值的時程表。 移轉波是追蹤業務成果、人員和時程表的反復變更管理方法。

在上一節中,圖形描述計畫方法就緒方法,以及雲端採用架構策略方法中的程式。 這些方法提供規劃和管理移轉波的指引。 這些波的管理會定義技術小組所要傳遞的移轉工作。

後續步驟

上述步驟和進一步的方法指引可協助您改善每個移轉短期衝刺中的程式。 Azure 移轉指南包含文章,概述第一次移轉階段期間所需的最常見工具和方法。