本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
人員觀點
本節著重於人員觀點的下列關鍵領域:
-
執行支援 – 識別有權做出決策的單執行緒領導者
-
團隊協作和所有權 – 在不同團隊之間協作
-
訓練 – 主動訓練團隊使用各種工具
執行支援
識別單執行緒領導者
開始大型遷移時,請務必識別 100% 致力於專案並負責的單執行緒技術領導者。該領導者有權透過維持一致的優先順序來做出決策、協助避免孤立,以及簡化工作流程。
大型遷移全球客戶能夠在程式開始時每週從一個伺服器擴展到第二個月開始時每週超過 80 個伺服器。CIO 作為單執行緒領導者的完整支援對於要遷移的伺服器快速擴展至關重要。CIO 每週與遷移團隊進行遷移切換呼叫,以確保問題的即時升級和解決,從而加速遷移速度。
協調資深領導團隊
請務必在各種團隊之間建立遷移成功條件的一致性。雖然遷移規劃和實作可由小型的專用團隊完成,但在定義策略和執行周邊活動時,仍會產生挑戰。這些潛在障礙可能需要 IT 組織不同區域的動作或呈報,包括下列項目:
-
商業
-
應用程式
-
聯網
-
安全
-
基礎設施
-
第三方供應商
來自應用程式擁有者、領導階層、一致性和明確呈報至單執行緒領導者的直接動作變得很重要。
團隊協作和所有權
建立跨職能雲端啟用團隊
在本節中:
大型遷移專案中重要的第一步是讓組織能夠在雲端運作。為了達成此目標,我們建議您建置雲端啟用引擎
-
制定政策
-
定義和實作工具、程序和將建立組織雲端操作模型的架構
-
繼續促進利益相關者在其代表的所有領域之間的一致性
一位醫療保健客戶沒有從 CEE 開始。不過,透過初始試行遷移,發現了差距。在最後遷移轉換日期之前,團隊在嚴格的截止日期內實作了遷移戰場。在遷移戰室中,來自基礎設施、安全、應用程式和業務的利益相關者可協助解決問題。
事先定義核心遷移團隊以外的團隊和個人需求
識別核心計畫以外的團隊和個人,並定義他們在遷移規劃階段中的參與。為了在後續階段促進遷移的動能,請特別注意應用程式團隊的參與。他們必須具備應用程式的知識、診斷問題的能力,以及要求在切換時登出。
雖然遷移將由核心團隊領導,但應用程式團隊可能會參與驗證遷移計劃,並在切換期間進行測試。客戶通常會將雲端遷移作為基礎設施專案來處理,而不是作為應用程式遷移。這可能會導致遷移期間發生問題。
我們建議您在選擇遷移策略時,考慮應用程式團隊的必要參與。例如,與變更更多應用程式環境的轉換或重構策略相比,重新託管策略需要的應用程式團隊參與較少。如果應用程式擁有者的可用性有限,請考慮使用 Rehost 或 replatform,而不是重構、重新定位或重新購買策略。
驗證遷移工作負載時沒有授權問題
當您將企業現成產品遷移至雲端時,授權可能會變更。您的授權合約可能著重於您的內部部署資產。例如,授權可能由 CPU 提供,或連結至特定 MAC 地址。或者,授權合約可能不包含在公有雲端環境中託管的權利。不過,與廠商重新交涉授權可以包含較長的前置時間,並呈現遷移的硬性封鎖程式。
我們建議您在定義遷移範圍後,立即與您的採購或供應商管理團隊合作。授權也可能影響您的目標架構和遷移模式。
培訓
在本節中:
訓練團隊有關新工具和程序
定義遷移策略後,請花時間了解遷移和目標操作模型可能需要哪些訓練。在遷移期間,您可能會使用 工具 AWS Database Migration Service,例如, 對您的組織來說是新的。主動訓練團隊可減少遷移階段發生的延遲。
我們建議尋求主動的知識轉移方法,提供機會以實際操作的方式實驗工具。例如, AWS 專業服務為負責大型遷移的三個系統整合商 (SI) AWS Partners 提供數個 Cloud Migration Factory 培訓課程。這可確保團隊在進入遷移階段時擁有基本熟悉度。它還有助於識別主題專家 (SMEs),他們可以在每個 SI AWS 合作夥伴團隊中作為一線上報。