團隊組織和組成

團隊組織和組成的最佳實踐

大型移轉中的小組組成因組織和專案過程中的變更而有所不同。以下是所有大型移轉專案通用的最佳作法：

• 在專案層級找出單執行緒技術領導者並避免孤島 — 大型移轉專案通常有多個工作流和團隊，每個團隊都有不同的工作和預期的結果。項目級的單線程領導者很重要，因為該領導者確保所有工作流協同工作並保持連接。這有助於防止孤島和邊界。例如，產品組合工作流需要持續將移轉中繼資料傳送至移轉工作流，以支援移轉活動。如果沒有完全瞭解所需的移轉中繼資料，產品組合工作流的輸出可能無法做為移轉工作流的輸入。單執行緒引線有助於協調每個工作流的輸入和輸出，以協助移轉有效率地執行。

• 使所有工作流層級成果與專案層級的業務成果保持一致 — 在移轉開始之前，應將專案層級的業務成果傳達給所有工作流領導者。每個工作流領導者都必須了解其工作流的作用，並設計他們的流程以支持項目級業務成果。例如，如果專案層級的業務成果在未來 12 個月內離開資料中心，而速度是最重要的因素，則工作流領導者應該執行下列動作：

  • 所有工作流都應優先考慮重新託管遷移，減少手動任務的數量，並添加自動化以提高速度。

  • 產品組合工作流應定義標準化模式並限制可自訂模式，以減少設計目標環境所需的時間。

• 根據專案範圍和階段設計工作流 — 每個移轉專案都不同，而且一個大小並不適合所有人。我們建議為所有大型移轉專案建立四個核心工作流：移轉工作流、產品組合工作流、專案治理工作流和基礎工作流。您可能會根據您的使用案例決定建立額外的支援工作流。如需有關工作流的詳細資訊，請參閱大型移轉中的工作流。例如，如果您尚未在動員階段設計安全護欄，則需要建立安全性與合規工作流，以便在開始移轉之前定義安全性和合規性需求。如需有關在動員階段建置安全護欄的詳細資訊，請參閱動員組織以加速大規模移轉中的安全性、風險和合規性。

• 在移轉之前讓應用程式團隊參與其中 — 大型移轉絕不只是 IT 基礎架構專案 — 它會改變您企業的營運模式。儘早參與應用程式團隊，並將應用程式擁有者嵌入到您的大型移轉工作流中，對於大型移轉專案的成功至關重要。例如，在產品組合評估期間，請儘早與應用程式擁有者安排會議，以便他們可以參與深入探討，並協助設計應用程式的目標狀態AWS。

• 根據工作流和業務成果確定團隊規模 — 您預期的業務成果和遷移策略會推動每個團隊的規模，這些單位由稱為 Pod 的較小單位組成。在每個工作流中，您可以為每個移轉策略定義小組，然後將這些團隊分隔到網繭中。例如，如果重新裝載是您的主要移轉策略，則您應該有一個由包含 3—5 個人員的網繭組成的重新裝載移轉小組。以尖峰速度操作時，移轉團隊中有 4—5 人的網繭通常每週最多可重新裝載 50 部伺服器。這大約是每個月 200 台伺服器或每年 2,500 部伺服器。如果您的目標是每週重新裝載 100 部伺服器，則應在重新裝載移轉小組中建立兩個由 4—5 人組成的網繭。如果您每週的目標目標少於 50 個，則可以將遷移網繭的大小縮減為 3 個人。重新平台移轉通常比重新裝載的成本高，而且相同大小的網繭每週最多可移轉 20 部伺服器。產品組合工作流通常是移轉工作流的一半大小。您可以在每個工作流中建立額外的團隊和網繭，以支援每種移轉策略。這些建議假設您的移轉資源熟練且不需要大量訓練。下表是如何將移轉和產品組合工作流劃分為小組和網繭，以進行重新裝載和重新平台移轉策略的範例。下列範例假設您每週需要遷移 120 部伺服器 (100 部重新裝載 + 20 個重新平台) 或每年需要 6,000 部伺服器。此範例為最大速度。我們建議您規劃其他資源，以防止延誤。

  工作流	團隊	Pod	資源
  移轉工作流	移轉小組的主持人	重新裝載移轉網繭 1	適合 4 至 5 人使用
  		重新裝載移轉網繭 2	適合 4 至 5 人使用
  	重新平台遷移團隊	重新平台移轉網繭	適合 4 至 5 人使用
  組合工作流	組合團隊	投資組合吊艙 1	三至四人
  		投資組合吊艙 1	三至四人

• 在早期階段建立治理模型 — 大型遷移通常涉及許多人員，包括您自己公司的人員、協力廠商軟體廠商、系統整合商或外部顧問。您的專案可能包括來自的代表AWS，例如您的客戶團隊、支援工程師或專AWS業服務的專家。您的交付模式會根據您的專案範圍以及與誰合作來交付專案而有所不同。例如，您的專案可能包含AWS或系統整合商，或者您可能會同時包含兩者。儘早建立治理模型並建立 RACI 矩陣，以清楚定義角色和責任是非常重要的。作為建議，我們還建議您在組織中建立雲端啟用引擎 (CEE)，也稱為雲端卓越中心，並包括所有各方的代表。CEE 的主要目的是將組織從內部部署作業模式轉換為雲端作業模式。這個集中式團隊對於大型移轉的成功至關重要，因為它可以管理關係、做出關鍵決策，以及處理整個專案的上報。本指南後面將更詳細地討論 CEE。

建立 RACI 矩陣

大型移轉專案通常涉及很多人，因此建置治理模型對於管理專案很重要。治理模型的其中一個關鍵元件是 RACI 矩陣，用於定義參與大型移轉的所有各方的角色和責任。RACI 矩陣名稱衍生自矩陣中定義的四種職責型態：

• 負責 (R) — 此角色負責執行工作以完成任務。

• 負責 (A) — 此角色負責確保任務已完成。此角色也負責確保符合先決條件，並將任務委派給負責人。

• 諮詢 (C) — 對於任務的意見或專業知識，應諮詢此角色。視作業而定，可能不需要此職責型態。

• 通知 (I) — 此角色應該保持最新的任務進度，並在任務完成時通知。

由於大型移轉的複雜性，我們不建議使用單一 RACI 矩陣來記錄大型移轉中的每項工作。多層 RACI 矩陣是一種更易於訪問的方法。您首先要建立一個高階 RACI 矩陣，然後在每個區段中新增更多詳細資訊以建立詳細矩陣。建立詳細的 RACI 矩陣並不是一次性的方法。您需要建立新的矩陣或新增更多詳細資料到現有的產品組合，並探索更多移轉策略和模式。

在基礎教戰手冊範本中，您可以使用 RACI 範本 (Microsoft Excel 格式) 作為建立自己高階且詳細 RACI 矩陣的起點。此範本包含兩個詳細的 RACI 矩陣範例，一個用於重新裝載移轉，另一個用於重新平台移轉。這些範例中的工作僅用於範例目的，您應該根據您的使用案例自訂這些範例。

建立高階 RACI 矩陣

在開始建立高階 RACI 矩陣之前，您需要準備好以下資訊：

• 誰是參與此次遷移的高層級各方？ 識別將參與此專案的任何合作夥伴或顧問，例如AWS專業服務或系統整合商。請考慮目前 IT 基礎架構的任何部分是否由外部合作夥伴管理。以下是高層次對象的範例：

  • 您的組織

  • AWS專業服務

  • 系統整合商

• 遷移中的工作流是什麼？ 如需詳細資訊，請參閱大型移轉中的工作流。您至少應該擁有四個核心工作流，並且可以根據需要為項目添加支持工作流。

• 移轉中有哪些高階工作？ 建立移轉中的高階工作清單。以下是高階工作的範例：

  • 建立一個 AWS landing zone

  • 執行產品組合評估並收集移轉中繼

  • 執行重新裝載、重新平台或重新定位移轉

  • 執行應用程式測試和切換

  • 執行項目管理和治理任務

請執行下列動作來建立您的高階 RACI 矩陣：

1. 在基礎教戰手冊範本中，開啟 RACI 範本 (Microsoft Excel 格式)。

2. 在 [高階 RACI] 索引標籤的第一列中，輸入您的組織名稱以及您識別的任何合作夥伴。

3. 在第一欄中，輸入您識別的高階工作和工作流。

4. 在矩陣中，確定哪些方負責每個任務，如下所示：

   • 如果一方負責完成工作，請輸入 R。

   • 如果關係人對作業負責，請輸入 A。

   • 如果一方應該就任務進行諮詢，請輸入 C。

   • 如果一方應該被告知有關任務，請輸入 I。

下表是高階 RACI 矩陣的範例。

任務	您的組織	合作夥伴 A	合作夥伴 B	合作夥伴 C
建立一個 AWS landing zone	R/C	A	I	I
執行投資組合評估和波浪規劃	R/C	A	I	I
執行重新裝載移轉活動	C	C	R/A	I
執行重新平台移轉活動	C	C	I	R/A
項目管理和治理	R/C	A	I	I
應用程式變更與測試	C	R/A	C	C
雲端作業	I	C	R/A	I

建立詳細的 RACI 矩陣

建立高階 RACI 矩陣之後，下一步是為每個高階任務建立詳細的 RACI，並進一步完善任務、對象和擁有權。在開始建立詳細矩陣之前，您必須準備好下列資訊：

• 移轉中有哪些詳細工作？ 準備好大型移轉專案的 Runbook 和工作清單之後，這些手冊中的程序和詳細資料會形成 RACI 矩陣的詳細層。例如，對於重新裝載移轉，詳細工作可能包括安裝複寫代理程式、驗證複寫，以及啟動測試執行個體以進行開機測試。如果您尚未這麼做，請依照下列教戰手冊中的指示建立這些文件：

  • AWS大型遷移的投資組合劇本

  • AWS大型移轉的移轉教戰手冊

• 哪些較小的團隊組成了每個工作流和每個高級派對？ 例如，您組織中的團隊可能包括應用程式小組、基礎結構小組、作業團隊、網路小組或專案管理辦公室。

請執行下列動作來建立詳細的 RACI 矩陣：

1. 開啟您的高階 RACI 矩陣。

2. 建立詳細 RACI (範本) 試算表的副本。

3. 為您在中識別的高層級任務命名複製的試算表建立高階 RACI 矩陣。

4. 在第一列中，輸入參與此高階任務的專案團隊名稱。

5. 在第一欄中，輸入您為此高階工作識別的詳細工作。您可以將詳細任務分組成邏輯順序組，以幫助讀者瀏覽矩陣。

6. 在矩陣中，確定哪些團隊負責每個任務，如下所示：

   • 如果團隊負責完成任務，請輸入 R。

   • 如果專案團隊負責完成任務，請輸入 A。

   • 如果團隊應該諮詢有關任務，請輸入 C。

   • 如果團隊應該被告知有關任務的信息，請輸入 I。

7. 對於每個詳細任務，請確認只有一個團隊負責，並且只有一個團隊負責。如果多個團隊負責或負責，這可能表明該任務沒有明確定義或沒有明確的所有權。

8. 與識別的團隊分享詳細的 RACI 矩陣，並確認所有團隊都熟悉他們的角色和職責。

9. 針對您在中識別的每個高階工作重複此程序建立高階 RACI 矩陣。

如需詳細 RACI 矩陣的範例，請參閱 RACI 範本中的「變更 R ACI 與重新平台 RACI」試算表，可在基礎教戰手冊附件中找到。

雲端啟用引擎 (CEE)

使用 CEE 的最佳做法

CEE 的目的是將 IT 組織從內部部署作業模式轉變為雲端作業模式，並負責引導組織完成組織與文化變革。最佳作法是建議您為大型移轉建立 CEE。CEE 的明確定義基礎程序和防護軌可協助您達成大型移轉所需的規模和速度。如需設定 CEE 的相關資訊，請參閱雲端啟用引擎：實用指南。以下是針對大型移轉專案建立 CEE 的其他建議和最佳實務：

• CEE 團隊應由具有以下素質的跨職能領導人組成：

  • 擁有深厚的制度知識

  • 擁有強大的，長期的內部關係

  • 對大型移轉的進度和成功有既得利益

  • 好奇，想學習

  • 主要或僅專注於遷移

• CEE 團隊應該是以前一起工作的人和可以提供新見解的新人的混合。

• CEE 團隊應該對遷移目標有強大的行政支持和一致性。

• 請確定 CEE 小組的目標特定於大型移轉。

• 定期舉行開放式會議，提供問題和答案的機會、展示雲端服務和架構，以及分享成功遷移和其他勝利的最新資訊。

• CEE 團隊應該有能力做出關於大型移轉專案的重要決策。

大型移轉的典型 CEE 角色和職責

下表提供大型移轉 CEE 小組中的角色，並說明每個角色的一般工作和職責。團隊的實際組成及其職責可能會因您的使用案例、範圍和業務目標而有所不同。

角色	任務和責任
行政贊助	管理升級 讓組織緊密地圍繞移轉的目標和重要性。 作為權威的聲音
企業架構師或專案級技術負責人	識別和記錄已知工作負載類型的參考架構 跨所有工作流設計和建置整個專案的移轉程序 擔任單執行緒技術領導者，確保所有工作流都能協同合作，並致力於實現相同的業務層級目標 對主要應用程序和通用架構的強大制度知識
項目管理辦公室主管	管理時間表、上線、訓練、文件、報告、溝通和資源治理 管理資源和培訓 管理與遷移有關的市政廳
遷移, 領導	設計移轉程序和工具 設計移轉策略和自動化 監督移轉切換並達到目標速度
投資組合鉛	設計投資組合評估和波浪規劃流程和工具 設計投資組合探索和資料收集程序 監督移轉中繼資料和波動計劃的持續供應
雲端作業領先	設計在上執行工作負載的作業模型 AWS 設計監控、事件回應、標記、業務持續性和災難復原策略的策略
應用團隊負責人	管理與個別應用程式擁有者的關係 管理其應用程式的移轉規劃和切換 管理應用程式變更、測試和核准
網路和基礎架構主管	設計目標帳戶的 AWS landing zone 設計網絡連接和基礎架構 設計和部署安全群組 管理基礎結構和網路變更以支援大型移轉
授權領導	識別所有商業 off-the-shelf (COTS) 和企業應用程式，並與移轉團隊和應用程式團隊合作，規劃有關授權的移轉策略
安全性與合規領導者	為大型移轉設計驗證和授權，包括 Active Directory、單一登入和 IAM 政策 設計網路安全性，包括內部部署防火牆，並管理弱點 設計範圍內工作負載的合規性需求