你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
协调角色和职责
了解组织的文化和数据中心管理对于 Azure 迁移成功至关重要。 具有明确角色的集中式 IT 团队可以简化流程，但大型或合规企业面临阻碍进步的细微挑战。
Azure 云采用框架强调了 组织协调 在迁移中的作用，主张跨部门协作履行关键职能。
在本文中，你将了解：
- 与云策略和云采用功能保持一致的特定于迁移的角色。
- 在迁移过程中为其他功能提供支持可能需要的角色，例如登陆区域架构师和工作负载架构师。
- 如何识别您迁移项目中与各角色相关的专家或负责人。
- 帮助了解哪个角色负责迁移项目的一部分的责任矩阵。
提示
提到的角色可能与特定职务不匹配，或者需要专门的团队成员。 通常，一个人可以涵盖多个角色，或者多个团队成员可以分担责任。 此列表概述了共同的责任，但不是人员配备指南。 关键是确保组织内满足这些职责。
云策略职能角色
若要确保对迁移项目具有必要的承诺和组织，云策略功能需要以下角色。 下表描述了云策略函数角色及其职责：
| 角色 | 责任 |
|---|---|
| 项目发起人 | 定义迁移的范围，以确定移动的资源以及移动每个资源的好处。 为迁移工具购买、总体工作负荷体系结构和发布活动提供决策所有权。 |
| 项目管理人 | 推动迁移范围项目计划的执行。 负责驱动测试过程。 为利益相关者组织状态更新。 |
| 组织变更管理器 | 帮助项目团队向组织传达更改。 与不同部门合作，确保合适的团队成员参与，并确保进行正确的组织变更以支持迁移。 |
| 许可专家 | 提供许可见解和 FinOps 管理，以确保项目获得适当的许可并使用现有的许可资源。 |
| 工作负载业务负责人 | 为工作负荷评估、体系结构和迁移过程提供决策所有权。 作为 Azure 中工作负载业务价值的所有者。 |
云采用功能角色
在迁移到 Azure 期间，云采用功能 执行大部分技术执行。 对于此功能，计划设置下表中所述的角色：
| 角色 | 责任 |
|---|---|
| 迁移架构师 | 监督工作负荷的技术决策，例如迁移波规划和所有迁移过程。 |
| 迁移工程师 | 执行项目中确定的各项任务。 |
为其他功能提供支持的角色
下表描述了可能需要用于其他函数的支持角色：
| 角色 | 责任 |
|---|---|
| 登陆区域架构师 | 支持将工作负荷迁移到登陆区域。 帮助解决着陆区中平台服务的任何问题。 有关详细信息，请参阅 云平台函数。 |
| 云操作经理 | 为将迁移的工作负载集成到管理平台提供支持，确保在工作负载迁移时能够进行妥善管理。 有关详细信息，请参阅 云作函数。 |
| 工作负荷架构师 | 为迁移工作负荷的设计提供体系结构指导和决策。 对于每个工作负荷，可能需要一个特定的主题专家来完成此角色的多个实例。 有关详细信息，请参阅 中央 IT 函数。 |
| 用户验收测试人员 | 测试单个工作负荷。 可能需要为每个工作负载设置多个此角色的实例，以便为用户验收测试 (UAT) 提供反馈。 有关详细信息，请参阅 中央 IT 函数。 |
确定角色的专家或所有者
对于其中某些角色（例如工作负荷架构师和工作负荷业务所有者），很难确定正确的资源。 如果工作负载长时间在维护中，且没有频繁更改，你可能会发现难以找到足够的所有权信息和技术专家支持相应功能。 例如，在数字资产规划中，有时服务器不会映射到特定的工作负荷，因此不清楚谁拥有这些工作负载。
下面是用于标识角色的一些建议：
- 历史数据：使用配置管理数据库或票证系统来确定任何指示谁请求维护或谁就服务器或工作负载进行沟通的历史项。
- 登录日志：查找最近在工作负荷中的服务器上登录的用户。 尽管此方法可能无法标识所有者，但最近的用户可以为你提供服务器的上下文。
- 依赖项分析：使用依赖项分析工具来确定最常连接到服务器上托管的函数的人员。 这些工具可以帮助你识别业务部门，而后者又可以帮助你识别所有者。
- 相关应用程序所有者：联系服务类似业务部门或功能的应用程序的所有者。 请让他们帮助你确定需要担任的角色。 即使组织中没有某个角色的专家，也必须在迁移过程中填补该角色。 业务团队和 IT 团队应至少确定临时成员，然后在迁移后为工作负荷的长期支持制定所有权计划。
为大型迁移计划扩展角色
根据迁移的工作负荷的大小和数量，可能需要为每个角色分配多个团队成员。 一种很好的方法是，按照本文描述的标准，对每次两周冲刺中的最多五个中等大小和复杂性的工作负荷进行评估。
但是，评估工作负荷的大小和复杂性可能很困难。 在早期的迁移阶段，先从核心团队开始，如果需要的话，可以逐步扩展规模。
如果发现需要横向扩展，还应规划下表中所述的角色：
| 角色 | 责任 |
|---|---|
| 项目经理 | 跨多个项目范围组织项目管理活动。 |
| 迁移架构负责人 | 在多个迁移架构范围内推动技术卓越。 |
责任矩阵示例
下表使用此图例来指示迁移项目的各个阶段每个角色的责任类别：
- D = 推动者：组织中负责推动目标的唯一个人。
- = 审批者：组织中一个或多个人负责做出大多数决策，并在目标未满足时承担责任。
- C = 参与者：组织中负责执行支持目标的任务的个人。
- I = 知情者：组织中受项目影响的人员，他们会定期收到有关项目决策和状态的通知。
可以使用以下责任矩阵作为迁移项目的基础。 可能需要根据组织的需求确定更多角色或转移职责。
| 角色 | 数字资产发现 | 迁移范围 | 项目计划 | 迁移工具 | 工作负荷识别 | 工作负荷评估 | 工作负荷体系结构 | 波次规划 | 工作负荷测试迁移 | 工作负载迁移 UAT | 工作负荷迁移 | 工作负载发布 UAT | 组织变更管理 | 运营过渡 | 工作负荷许可 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 迁移架构师 | D | D | A | D | A | A | D | A | A | A | A | A | 我 | D | 我 |
| 迁移工程师 | C | 我 | C | C | D | D | C | D | D | C | D | C | 我 | C | C |
| 项目管理人 | 我 | 我 | D | 我 | 我 | 我 | 我 | 我 | 我 | D | 我 | D | 我 | C | 我 |
| 项目发起人 | A | A | A | A | 我 | 我 | A | 我 | 我 | 我 | A | 我 | A | A | A |
| 用户验收测试人员 | 我 | 我 | 我 | 我 | 我 | 我 | 我 | 我 | 我 | C | 我 | C | 我 | C | 我 |
| 工作负荷架构师 | 我 | 我 | C | C | C | C | C | C | C | C | C | C | C | C | 我 |
| 工作负载业务负责人 | 我 | 我 | C | 我 | A | A | A | A | A | A | A | A | C | C | A |
| 组织变更管理器 | 我 | 我 | C | 我 | 我 | 我 | 我 | 我 | 我 | C | 我 | C | D | C | 我 |
| 许可专家 | 我 | 我 | C | C | 我 | C | C | C | 我 | 我 | 我 | 我 | 我 | C | D |
| 云操作经理 | C | C | C | 我 | 我 | 我 | 我 | C | 我 | 我 | 我 | 我 | C | A | 我 |
| 登陆区域架构师 | 我 | 我 | C | C | 我 | 我 | C | C | 我 | 我 | 我 | 我 | 我 | 我 | 我 |