本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
业务驱动因素和技术指导原则
业务驱动因素
无论您的组织已经决定迁移到云端还是即将做出这一决定,定义和记录云迁移的业务驱动因素都将阐明迁移的原因。记录原因后,您可以定义要迁移的内容以及迁移的方式。这项活动很重要。我们建议尽早进行此项工作,以便为后续步骤提供信息和指导。
确定应参与讨论的利益相关者,以记录驱动因素。通常是组织内部的高级管理人员和关键技术负责人,以及您自己的客户。 CxOs尽管您的客户不太可能参与此次讨论,但我们建议在您的组织中指定一个或多个人员来代表客户的观点和目标。
业务驱动因素应与可在整个迁移过程中进行衡量的指标相关联,以验证是否已实现成果。公司的战略目标和年度报告可以作为起点。
根据现有和预计的指标,将对话重点放在公司迁移到云端后想要达到的目标上。考虑目标和业务成果。另外,请考虑随着云采用率的提高,成功会是什么样子。
接下来,确定每个驱动因素的重要性级别。优先事项是什么? 预期的好处是什么? 收益如何支持业务目标和成果? 在应用程序组合评估的背景下,答案将有助于确定迁移工作负载的优先顺序并制定技术指导原则。但是,业务驱动因素将定义和影响整个迁移计划。
技术指导原则
技术指导原则为投资组合评估后期阶段的迁移策略选择提供了依据。在现阶段,重点是识别它们。
可以将指导原则确立为从业务目标和结果中得出的与技术有关和方法相关的一般决策。
例如,一家公司的主要目标是降低成本,而预期的结果是在 6-12 个月的给定日期之前关闭本地数据中心。由此产生的指导原则是,尽可能使用重新托管或重新定位迁移策略,将所有应用程序迁移到云端。在这种情况下,该 lift-and-shift 方法可以加快短期迁移的结果。应用程序迁出本地数据中心后,公司可以专注于主要业务驱动因素,以优化迁移的工作负载或实现现代化。
要制定技术指导原则,首先要分析业务驱动因素。确定一份可实现业务目标和结果的技术和技术清单。接下来,完善列表并根据适用性或偏好分配相关性顺序,以实现预期的结果。
记录指导原则,并与参与规划和执行迁移的人员进行沟通。强调原则与实际实施之间的担忧和潜在冲突。
下表提供了业务驱动因素和技术指导原则的示例。
业务驱动因素 |
结果 |
指标 |
技术指导原则 |
---|---|---|---|
加快创新。 |
提高竞争力,提高业务灵活性 |
每天或每月的部署次数、每季度发布的新功能、客户满意度得分、实验次数 |
通过使用微服务和 DevOps 运营模型重构差异化应用程序,以提高敏捷性和新功能的上市速度。 |
降低运营和基础设施成本。 |
供需匹配,成本基础弹性(按实际用量付费) |
支出随时间推移而变化 |
1. 调整基础架构规模,重新托管应用程序。 2. 淘汰利用率低或没有利用率的应用程序。 |
提高运营弹性。 |
延长正常运行时间,缩短平均恢复时间 |
SLA,事件数量 |
1. 将应用程序平台改为最新、最受支持的操作系统版本。 2. 为关键应用程序实施高可用性架构。 |
退出数据中心。 |
在 6-12 个月内关闭数据中心 |
服务器迁移速度 |
使用云迁移工厂解决方案重新托管应用程序。 |
留在内部,但要提高敏捷性和弹性。 |
在保持内部办公的同时,提高竞争力和正常运行时间 |
每天或每月的部署次数、每季度发布的新功能、SLA、事件数量 |
1. 通过将系统的功能扩展到云端,实现系统的现代化。 2. 评估是否重新托管或重定平台至 Outposts。 AWS |