安全云迁移：8 个关键步骤实现无缝过渡
将关键任务应用和数据迁移到云端是大型项目，若想获得高 ROI，需要深度规划。没有合理策略，云迁移可能带来更多利润损失和头疼问题，而非业务收益。
本文提供云迁移清单，确保您的云迁移平稳、安全、无意外惊喜。您可将清单作为迁移过程基线，因为下面的分步计划涵盖移动应用到云的所有主要方面。
云迁移清单
云迁移困扰是企业常见问题。最新研究显示55% 云迁移或严重延期或超预算。
此外，62% 正在向云过渡的组织将过程描述为困难或失败。大多数公司冲动转型，未充分考虑：
- 总拥有成本 (TCO)
- 团队如何将海量数据和关键任务应用迁移到云
- 云部署和集成的不同选项
- 潜在新网络安全风险
- 内部团队在云环境运营的准备程度
以下云迁移清单确保团队开始迁移应用和服务前考虑这些因素。
指定首席迁移架构师
云迁移涉及大量技术决策和规划，必须指定单一专家或专家团队领导工作。无论选择一名还是多名员工，迁移架构师角色是：
- 评估服务看哪些更适合本地或云托管
- 制定迁移时间线和云路线图
- 设计移动数据和应用的最优策略
- 识别和监督必要的应用重构
- 确定迁移优先级
- 定义所需工具链
专职架构师还应提供 IT 全貌。这涉及回答：
- 有哪些应用，谁使用（频率如何）？
- 拟迁移应用业务关键程度如何？
- 程序消耗什么资源，是否依赖其他应用？
- 当前有哪些 SLA、业务连续性措施和合规措施？
- 是否有影响当前运营的性能问题？
基于分析，迁移架构师应评估当前员工是否具备必要知识：
- 执行迁移
- 在云环境运营
除非确定团队能在新环境茁壮成长，绝不开始向云过渡。
专职迁移团队还应确定总拥有成本 (TCO)，说明云迁移 ROI。云迁移 TCO 评估包含因素：
- 迁移总成本
- 迁移后云成本（主要是带宽和网络价格）
- 员工培训成本
- 常规迁移后维护
- 潜在停机成本
- 空间、制冷、电力成本（本地私有云）
设定迁移目标和 KPI
下一步确立迁移主要目标。常见高层目标：
- 现代化遗留应用
- 加速特定服务
- 提升运营能力
- 增强系统弹性
- 改善用户体验
- 实现更好服务扩展性
- 降低运行成本
- 改善数据安全
除总体目标，团队应定义云迁移关键绩效指标 (KPI)。这些指标衡量迁移应用或服务表现是否符合预期。团队可跟踪的 KPI 数量无上限，但所有指标归属两类：
- 迁移过程中跟踪的 KPI
- 迁移后 KPI
迁移过程中最常见可跟踪 KPI：
- 迁移持续时间（整体和单应用）
- 关键服务可用性
- 服务和数据中心停机时长
- 因停机导致的服务降级
- 生成的服务工单数量
- 迁移成本
看看迁移后团队可跟踪的后迁移 KPI：
- 基础设施 KPI（CPU 使用率、服务内存占用、磁盘性能、负载均衡、延迟、网络吞吐量等）
- 应用性能指标（错误率、超时数、平均响应时间 (ART)、峰值响应时间 (PRT)、正常运行时间、可用性等）
- 用户体验 KPI（请求峰值数、HTTP 状态码错误、抛出和记录的异常、延迟、响应时间等）
- 业务影响指标（结账流程时长、订阅和退订率、参与率等）
- 成本 KPI（月度账单、人员成本、第三方工具、咨询成本等）
决定跟踪什么前，必须为每个 KPI 设定基线值。基线化是测量应用和服务当前（迁移前）状态的过程。这些 KPI 让您判断迁移后性能是否可接受。
执行数据和应用评估
数据评估是此云迁移清单关键步骤，因移动数据通常是采用云最棘手部分。仔细评估数据让团队评估：
- 数据风险等级
- 计划迁移数据的体量和类型
- 整体数据弹性
- 法律数据隐私要求（如有）
- 对数据完整性最大威胁
- 潜在迁移后数据泄露或泄漏场景
数据驻留位置可影响应用和服务性能。数据迁移到云而数据访问方式仍在本地运行，会显著影响性能。数据库仍在本地但访问它的服务在云端时同理。
除评估数据，本地应用应获同等待遇。迁移前，团队应创建所有本地应用及其服务器的清单。还应评估任何当前虚拟机并考量潜在应用依赖。
结果可确定哪些应用迁移前需重构。团队也可开始优先级排序先迁移哪些应用。
评估云迁移选项
云迁移清单下一步是评估哪些应用需要何种云集成类型。有两个选项：
- 浅层云集成（即直接迁移 / 重新托管）：直接迁移应用时，极少或不改代码，以当前形态或多或少在云中设置应用。不做任何更改迁移应用称重新托管；迁移到云时做微小调整称重构
- 深度云集成：与浅层对应，深度云集成要求修改应用以利用云功能。变更范围从相对简单调整（如设置自动扩展和动态负载均衡）到高级更新（如启用无服务器计算）使应用成为云原生解决方案
浅层云集成比重构应用主要部分快得多。通常，关键任务应用值得深度集成投入。不太重要的应用和服务可用浅层方法，迁移到云后再逐步重构。
评估哪个服务需要何种集成时，公司也常决定退役或保留应用：
- 退役是识别上传到云无价值的过时应用或服务的过程
- 保留是决定因安全或合规顾虑将应用留在本地
选择合适的云部署模型
选择合适云部署模型对成功云迁移至关重要。不同模型适配不同用例，五个可选项：
- 公有云（多租户环境，通过互联网或专用直连提供计算资源访问）
- 私有云（单租户系统，企业在自有数据中心运行云资源）
- 混合云（本地系统、公有云、私有云混合，工作负载通过自动化和编排在环境间移动）
- 多云（两个或更多公有云 IaaS 环境混合）
- 社区云（多家有共同需求或顾虑的公司共享基础设施）
应用何种部署模型主要取决于业务独特需求和目标。几个指引：
- 公有云提供按使用付费的可扩展环境。虽高扩展，但公有云可能不适合敏感工作负载
- 私有云适合有预算运行本地云环境、为关键任务工作负载定制的公司
- 混合云让您在本地运行敏感工作负载，同时利用公有云扩展性应对需求峰值
- 做对虽有巨大益处，但设计混合架构前需知混合云挑战
- 多云是担心供应商锁定或想混合匹配多提供商服务公司的绝佳选择
选择云服务提供商
除非选择建立本地私有云，云迁移清单下一项应是寻找云提供商。虽然大多数供应商提供相似服务，但并非完全相同。选择云提供商关键考量：
- 定价
- 服务选择
- 特定区域可用性
- 正常运行时间保证
- 内部团队对提供商技术栈的熟悉度
- 行业特定合规要求（如根据 CCPA 或 GDPR 在来源地保存用户数据）
- 迁移后支持和托管 IT 服务
记住最流行服务提供商不总是最佳匹配。知名供应商旨在满足广泛需求，故不总能与特定垂直领域公司完美匹配。
例如，医疗行业公司可能更适合与更懂并支持 HIPAA 合规的利基提供商合作。
执行必要重构
知晓需要何种云部署和合作伙伴后，团队应在迁移到云前开始对应用和服务做必要更改。
目标是让软件在云中尽可能高效、有效运行。例如，团队可重构应用以：
- 适配可变运行实例数，允许近乎即时扩展
- 利用动态云能力（如按当前需求分配和释放资源）
- 创建更面向服务的架构，快速将单个服务移至云（无论此时还是未来）
现在也是重新思考治理和安全的正确时机。您可能需要调整治理策略，减少对内部安全和控制的依赖，更多依赖提供商云服务。云安全方面，您需：
- 评估迁移是否可能导致新漏洞
- 理解内部团队将如何与提供商合作保障云资产安全
- 调整（并可能改进）当前安全措施和实践
- 决定能否从提供商提供的额外安全工具受益
- 建立故障转移和灾难恢复机制
有条不紊地迁移并从本地运营切换流量
虽可一次性将所有迁移到云，但此法难度大、风险高。相反，应逐个迁移应用和服务，从风险最小的非关键应用开始，慢慢过渡到关键应用。
此迁移方法应如下：
- 优先团队能以最小运营风险迁移的应用。好选择是仅需重新托管或使用极少资源（如低存储或计算）的应用
- 然后迁移对业务高价值但迁移风险相对低的应用
- 最后将关键任务和破坏性工作负载留到迁移最后阶段。除非前几步应用运行最优，绝不开始迁移这些应用
- 用手动或自动测试（或两者）检查迁移是否成功
视应用和数据存储架构，可两种方式从本地方案切换流量到云：
- 一次性切换：应用在云中开始运行后，团队立即切换所有本地流量
- 逐步切换：团队建立云端应用后，将少量客户迁移至新环境。若一切正常，随时间继续将客户切换到云，直到所有最终用户依赖新应用
用我们的云迁移清单自信迁移
虽然迁移到云常是不假思索的决定，但许多企业在迁移应用到云时挣扎或成功有限。坚持上述云迁移清单确保您避开所有常见陷阱，从而无惧昂贵失误地开始规划云采用。
云计算