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