你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
查看合理化决策
在初始策略和规划阶段,建议对数字资产应用增量合理化方法。 但此方法将一些假设嵌入到最终的决策中。 建议云策略团队和云采用团队根据扩展的工作负载文档审查这些决策。 此审查也是让业务利益干系人和执行发起人参与未来决策的好时机。
重要
在迁移的评估阶段,将对合理化决定进行进一步验证。 此验证侧重于对合理化的业务审查,以适当地调整资源。
若要验证合理化决策,请使用以下问题来促进与企业的对话。 这些问题按可能的合理化对齐方式分组。
创新指标
如果对以下问题的联合审查得出肯定的答案,则工作负载可能是更好的创新候选项。 此类工作负载不会通过直接迁移或现代化模型进行迁移。 相反,业务逻辑或数据结构将被重新创建为一个新的或重新构建的应用程序。 此方法可能更费时费力。 但对于表示重大业务回报的工作负载来说,投资是合理的。
- 此工作负载中的应用程序是否会产生市场差异化?
- 是否有提议或已获批准的投资旨在改进与此工作负载中的应用程序相关的体验?
- 此工作负载中的数据是否可以提供新产品或服务产品?
- 是否有旨在利用与此工作负载相关的数据的提议或已获批准的投资?
- 可以量化市场差异化或新产品/服务的影响吗? 如果可以,这种回报是否可以证明在云采用期间增加的创新成本是合理的?
以下两个问题可帮助在合理化审查中包括高级技术场景。 如果任一问题的答案都是“是”,则可以确定用于计算或降低与创新相关的成本的方法。
- 在云采用过程中,数据结构或业务逻辑会发生更改吗?
- 是否可以使用现有的部署管道将此工作负载部署到生产环境?
如果任一问题的答案都是“是”,则团队应考虑将此工作负载添加为创新候选项。 团队至少应标记此工作负载以进行体系结构审查,从而确定现代化机会。
迁移指标
迁移是采用云的一种更快、更便宜的方式。 但它没有利用创新的机会。 在投资创新之前,请回答以下问题。 它们可以你帮助确定迁移模型是否更适用于工作负载。
- 支持此应用程序的源代码是否稳定? 是否希望它在此发布周期的期限内保持稳定和不变?
- 此工作负载目前是否支持生产业务流程? 在整个发布周期中,它都将提供支持吗?
- 此云采用工作是否会优先考虑提高此工作负载的稳定性和性能?
- 与此工作负载相关的成本降低是否是此工作的目标?
- 降低此工作负载的操作复杂性是否是此工作的目标?
- 创新是否受到当前体系结构或 IT 操作过程的限制?
如果上述任一问题的答案都是“是”,则应该考虑针对此工作负载的迁移模型。 即使工作负载是创新的候选项,此建议也是正确的。
运营复杂性、成本、性能或稳定性等方面的挑战可能会阻碍业务回报。 可以使用云快速生成与这些挑战相关的改进。 如果适用,建议首先使用迁移方法稳定工作负载。 然后,在稳定、敏捷的云环境中拓展创新机会。 此方法可提供短期回报,并且可降低推动长期变革所需的成本。
重要
迁移模型包括增量现代化。 使用平台即服务 (PaaS) 体系结构是迁移活动的一个常见方面。 使用这些平台服务的次要配置更改也是如此。 迁移的边界被定义为对业务逻辑或支持业务结构的重大更改。 这种更改被视为一项创新工作。
更新项目计划
迁移工作所需的技能与创新工作所需的技能不同。 在实现云采用计划期间,建议将迁移和创新工作分配给不同的团队。 每个团队都有自己的迭代、发布和规划节奏。 通过分配单独的团队可提供流程灵活性,以维护一个云采用计划,同时顾及创新和迁移工作。
当在 Azure DevOps 中管理云采用计划时,通过将父工作项(或 epic)从云迁移更改为云创新来体现该管理。 这种细微的更改有助于确保云采用计划中的所有参与者都可以快速跟踪所需的工作和对补救工作的更改。 此跟踪还有助于将适当的分配与相关的云采用团队保持一致。
对于包含多个不同项目的大型复杂采用计划,请考虑更新迭代路径。 通过更改区域路径使工作负载仅对分配到该区域路径的团队可见。 通过减少可见任务的数量,此更改可以使云采用团队的工作更轻松。 但它增加了项目管理过程的复杂性。
后续步骤
建立迭代和发布计划,以开始规划工作。
建立迭代和发布计划,以开始规划工作。