团队组织和组成

团队组织和组成的最佳实践

大型迁移中的团队组成因组织而异，并且在项目过程中会发生变化。以下是所有大型迁移项目中常见的最佳实践：

• 在项目层面确定单线程技术负责人，避免孤岛 — 大型迁移项目通常有多个工作流程和团队，每个团队都有不同的任务和预期结果。项目级别的单线程领导者很重要，因为该领导者可以确保所有工作流协同工作并保持联系。这有助于防止孤岛和边界。例如，项目组合工作流需要持续将迁移元数据发送到迁移工作流以支持迁移活动。如果不完全了解所需的迁移元数据，则项目组合工作流的输出可能无法作为迁移工作流的输入。单线程领导者帮助协调每个工作流的输入和输出，以帮助高效地进行迁移。

• 使所有工作流级别的成果与项目级别的业务成果保持一致 — 在迁移开始之前，应将项目级别的业务成果传达给所有工作流负责人。每个工作流领导者都必须了解其工作流的作用，并设计流程以支持项目级业务成果。例如，如果项目层面的业务成果将在未来 12 个月内退出数据中心，而速度是最重要的因素，则工作流负责人应采取以下措施：

  • 所有工作流都应优先考虑重新托管迁移，减少手动任务的数量，并增加自动化以提高速度。

  • 产品组合工作流应定义标准化模式并限制可自定义的模式，以减少设计目标环境所需的时间。

• 根据项目范围和阶段设计工作流 — 每个迁移项目都不一样，不能一刀切。我们建议为所有大型迁移项目设置四个核心工作流：迁移工作流、项目组合工作流、项目治理工作流和基础工作流。根据您的用例，您可能会决定创建其他支持性工作流。有关工作流的更多信息，请参阅大型迁移中的工作流。例如，如果您尚未在移动阶段设计安全护栏，则需要在开始迁移之前创建一个安全与合规性工作流，该工作流可以定义安全性和合规性要求。有关在移动阶段建立安全防护栏的更多信息，请参阅 “动员组织以加快大规模迁移” 中的安全、风险和合规性。

• 在迁移之前让应用团队参与进来 — 大型迁移绝不仅仅是一个 IT 基础架构项目 — 它会改变您的业务运营模式。尽早让应用程序团队参与进来，并将应用程序所有者嵌入大型迁移工作流中，对于大型迁移项目的成功至关重要。例如，在产品组合评估期间，尽早安排与应用程序所有者的会议，以便他们可以参与深入研究并帮助设计应用程序的目标状态AWS。

• 根据工作流程和业务成果确定团队规模 — 您的预期业务结果和迁移策略决定了每个团队的规模，每个团队由名为 pod 的较小单位组成。在每个工作流中，您可以为每个迁移策略定义团队，然后将这些团队分成多个窗格。例如，如果重新托管是你的主要迁移策略，那么你应该有一个由包含 3-5 个人的 pod 组成的重新托管迁移团队。在以峰值速度运行时，迁移团队中由 4-5 人组成的 Pod 通常每周最多可以重新托管 50 台服务器。这相当于每月大约 200 台服务器或每年大约 2,500 台服务器。如果您的目标是每周重新托管 100 台服务器，则应在重新托管迁移团队中创建两个由 4 到 5 人组成的 pod。如果您的目标每周少于 50 人，则可以将迁移容器的大小减少到 3 个人。平台迁移的成本通常高于重新托管，相同大小的 pod 每周最多可以迁移 20 台服务器。产品组合工作流的规模通常是迁移工作流的一半。你可以在每个工作流中创建额外的团队和窗格来支持每种迁移策略。这些建议假设您的迁移资源熟练，不需要大量培训。下表是一个示例，说明了如何将迁移和组合工作流划分为团队和窗格，以用于重新托管和平台迁移策略。以下示例假设您需要每周迁移 120 台服务器（100 台重新托管 + 20 台平台重建），或者每年需要迁移 6,000 台服务器。这个例子是最大速度。我们建议您规划更多资源，以帮助防止延迟。

  工作流	团队	Pod	资源
  迁移工作流	重新托管迁移团队	重新托管迁移容器 1	4—5 个人
  		重新托管迁移容器 2	4—5 个人
  	平台迁移小组	重新平台迁移窗格	4—5 个人
  投资组合工作流	投资组合团队	投资组合窗格 1	3—4 个人
  		投资组合窗格 1	3—4 个人

• 在早期阶段建立治理模型 — 大规模迁移通常涉及很多人，包括您自己公司的人员、第三方软件供应商、系统集成商或外部顾问。您的项目可能包括来自您的客户团队AWS、支持工程师或AWS专业服务专家等的代表。根据您的项目范围以及与谁合作交付项目，您的交付模式会有所不同。例如，您的项目可能包括AWS或系统集成商，或者您可能同时包含两者。重要的是要尽早建立治理模型，并创建一个明确界定角色和职责的RACI矩阵。作为建议，我们还建议在您的组织中创建一个云支持引擎 (CEE)，也称为卓越云中心，并包括各方代表。CEE的主要目的是将组织从本地运营模式转变为云运营模式。这个集中的团队对大规模迁移的成功至关重要，因为它可以在整个项目中管理关系、做出关键决策和处理上报。本指南稍后将更详细地讨论中欧和东欧问题。

创建 RACI 矩阵

大型迁移项目通常涉及很多人，因此建立治理模型对于管理项目非常重要。治理模型的关键组成部分之一是 RACI矩阵，该矩阵用于定义参与大规模迁移的所有各方的角色和责任。RACI 矩阵的名称源自矩阵中定义的四种责任类型：

• 负责(R) - 此角色负责执行工作以完成任务。

• 问责(A) - 此角色负责确保任务完成。此角色还负责确保满足先决条件，并将任务委派给相关负责人。

• 咨询(C) - 应向此角色咨询有关任务的意见或专业知识。根据任务的不同，可能不需要此责任类型。

• 知情(I) - 此角色应随时了解任务的最新进度，并会在任务完成时收到通知。

由于大规模迁移的复杂性，我们不建议使用单个 RACI 矩阵来记录大型迁移中的每项任务。多层 RACI 矩阵是一种更易于使用的方法。首先要构建一个高级别 RACI 矩阵，然后向每个部分添加更多细节以构建详细的矩阵。构建详细的 RACI 矩阵不是一次性的方法。随着投资组合的进展，您需要建立新的矩阵或在现有矩阵中添加更多细节，并发现更多的迁移策略和模式。

在基础剧本模板中，你可以使用 RACI 模板（Microsoft Excel 格式）作为构建自己的高级和详细的 RACI 矩阵的起点。此模板包括两个详细的 RACI 矩阵示例，一个用于重新托管迁移，另一个用于重新平台迁移。这些示例中的任务仅供示例之用，您应根据自己的用例自定义这些示例。

构建高级别 RACI 矩阵

在开始构建高级别 RACI 矩阵之前，您需要准备好以下信息：

• 谁是参与此次迁移的高层人士？ 确定将参与此项目的任何合作伙伴或顾问，例如AWS专业服务或系统集成商。考虑一下您当前 IT 基础架构的任何部分是否由外部合作伙伴管理。以下是高级别聚会的例子：

  • 你的组织

  • AWS专业服务

  • 系统集成商

• 您的迁移工作流程有哪些？ 有关更多信息，请参阅大型迁移中的工作流。您至少应该拥有四个核心工作流，并且可以根据需要为项目添加支持工作流。

• 您的迁移中有哪些高级任务？ 创建迁移中的高级任务列表。以下是高级任务的示例：

  • 建造一个AWS着陆区

  • 进行投资组合评估并收集迁移元数据

  • 执行重新托管、平台重置或重新定位迁移

  • 执行应用程序测试和切换

  • 执行项目管理和治理任务

执行以下操作来构建您的高级别 RACI 矩阵：

1. 在基础剧本模板中，打开 RACI 模板（微软 Excel 格式）。

2. 在高级 RACI 选项卡的第一行中，输入您的组织名称和您确定的任何合作伙伴。

3. 在第一列中，输入您确定的高级任务和工作流。

4. 在矩阵中，确定哪一方负责每项任务，如下所示：

   • 如果一方负责完成任务，请输入 R。

   • 如果一方对任务负责，请输入 A。

   • 如果应就任务征求一方的意见，请输入 C。

   • 如果应将任务通知一方，请输入 I。

下表是高级别 RACI 矩阵的示例。

Task	你的组织	合作伙伴 A	合作伙伴 B	合作伙伴 C
建造一个AWS着陆区	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，并进一步完善任务、各方和所有权。在开始构建详细矩阵之前，您需要准备好以下信息：

• 您的迁移中有哪些详细任务？ 在为大型迁移项目准备好运行手册和任务列表后，这些运行手册中的流程和详细信息将构成您的 RACI 矩阵的详细层。例如，对于重新主机迁移，详细任务可能包括安装复制代理、验证复制以及启动测试实例以进行启动测试。如果您还没有这样做，请按照以下攻略手册中的说明创建这些文档：

  • 适用于AWS大型迁移的投资组合手册

  • AWS大型迁移的迁移手册

• 每个工作流程和每个高级别小组由哪些较小的团队组成？ 例如，组织中的团队可能包括应用程序团队、基础架构团队、运营团队、网络团队或项目管理办公室。

要构建详细的 RACI 矩阵，请执行以下操作：

1. 打开您的高级别 RACI 矩阵。

2. 创建详细 RACI（模板）电子表格的副本。

3. 为您在中确定的高级任务对复制的电子表格命名构建高级别 RACI 矩阵。

4. 在第一行中，输入参与此高级任务的团队的名称。

5. 在第一列中，输入您为此高级任务确定的详细任务。您可以将详细任务分组为逻辑顺序组，这有助于读者浏览矩阵。

6. 在矩阵中，确定哪些团队负责每项任务，如下所示：

   • 如果团队负责完成任务，请输入 R。

   • 如果团队负责完成任务，请输入 A。

   • 如果需要就该任务征求团队的意见，请输入 C。

   • 如果应将任务告知团队，请输入 I。

7. 对于每项详细任务，请确认只有一个团队负责，只有一个团队负责。如果有多个团队负责或负责，则可能表明任务定义不明确，或者没有明确的所有权。

8. 与确定的团队共享详细的 RACI 矩阵，并确认所有团队都熟悉自己的角色和职责。

9. 对您在中确定的每项高级任务重复此过程构建高级别 RACI 矩阵。

有关详细的 RACI 矩阵的示例，请参阅 RACI 模板中的 Rehost RACI 和 Replatform RACI 电子表格，可在基础剧本附件中找到。

云支持引擎 (CEE)

使用 CEE 的最佳实践

CEE的目的是将IT组织从本地运营模式转变为云运营模式，它负责指导组织完成组织和文化变革。作为最佳实践，建议您为大型迁移建立 CEE。CEE中定义明确的基础流程和防护轨道可以帮助您实现大规模迁移所需的规模和速度。有关设置 CEE 的信息，请参阅云支持引擎：实用指南。以下是为大型迁移项目建立 CEE 的其他建议和最佳实践：

• 中欧和东欧团队应由具有以下素质的跨职能领导者组成：

  • 拥有深厚的机构知识

  • 有牢固、长期的内部关系

  • 大规模移民的进展和成功符合既得利益

  • 很好奇，想学习

  • 主要或完全专注于迁移

• CEE团队应该由以前合作过的人和能够提供新见解的新成员组成。

• 中欧和东欧团队应在迁移目标上获得强有力的管理支持和一致性。

• 确保中欧和东欧团队的目标特定于大规模迁移。

• 定期举行公开会议，提供提问和解答的机会，演示云服务和架构，并分享成功迁移和其他成功的最新信息。

• 应授权中欧和东欧团队就大型迁移项目做出关键决策。

大型迁移的典型中欧和东欧角色和职责

下表提供了大规模迁移 CEE 团队中的角色，并描述了每个角色的典型任务和职责。您的团队的实际组成及其职责可能会因您的用例、范围和业务目标而异。

角色	任务和责任
执行发起人	管理升级 使组织与迁移的目标和重要性保持一致。 充当权威的代言人
企业架构师或项目级技术主管	识别和记录已知工作负载类型的参考架构 为整个项目设计和构建跨所有工作流的迁移流程 担任单线程技术领导者，确保所有工作流程都相互协作，努力实现相同的业务级目标 对主要应用程序和常见架构有深厚的机构知识
项目管理办公室主管	管理时间表、入职、培训、文档、报告、沟通和资源管理 管理资源和培训 管理与移民相关的市政厅
迁移主管	设计迁移流程和工具 设计迁移策略和自动化 监督迁移切换并实现目标速度
投资组合负责人	设计投资组合评估和波浪规划流程和工具 设计投资组合发现和数据收集流程 监督迁移元数据和波浪计划的持续供应
云运营主管	设计用于在上运行工作负载的操作模型 AWS 设计监控、事件响应、标记、业务连续性和灾难恢复策略的策略
应用团队负责人	管理与个人应用程序所有者的关系 管理其应用程序的迁移计划和切换 管理应用程序变更、测试和批准
网络和基础设施主管	为目标账户设计AWS着陆区 设计网络连接和基础架构 设计和部署安全组 管理基础架构和网络变更以支持大规模迁移
许可负责人	确定所有商业 off-the-shelf (COTS) 和企业应用程序，并与迁移团队和应用程序团队合作，围绕许可规划迁移策略
安全与合规主管	为大型迁移设计身份验证和授权，包括 Active Directory、单点登录和 IAM 策略 设计网络安全，包括本地防火墙和管理漏洞 为范围内的工作负载设计合规性要求