上云迁移与部署

迁移可行性评估与资源盘点

迁移的第一步不是开通服务器，而是把现有系统看清楚。我们会逐项记录服务器规格与运行负载、数据库版本与数据量、中间件与依赖组件、对外端口与访问白名单、定时任务与外部接口调用关系，形成一份可以和运维同事逐条核对的资源清单。

清单里的每一项都会标注迁移方式与风险等级：可以直接平移的系统、需要调整配置才能搬迁的系统、以及必须改造后才能在目标环境稳定运行的系统。这一步做完，迁移范围、批次划分和大致工作量就有据可依。

盘点同时会确认几个容易被忽略的细节：域名备案主体是否一致、证书与密钥如何随业务迁移、日志与备份文件需要保留多长时间、是否存在仅限内网访问的组件。这些内容如果留到割接当天再处理，往往会拖长窗口。

目标架构与方案设计

方案设计围绕业务峰值和增长预期展开。计算资源按当前峰值加一定余量选择实例规格，磁盘按 IO 特征区分高效云盘与 SSD，带宽按峰值流量的合理倍数预留，安全组策略按最小开放原则重建，避免把原有宽松规则整体搬过去。

数据库部分会明确主从结构、读写分离是否必要、备份窗口放在什么时段；静态资源、图片与备份文件建议转入对象存储，减轻系统盘压力。如果业务本身已经容器化，会同步给出容器编排与镜像仓库的落地方式。

数据搬迁与应用部署

数据搬迁通常采用全量加增量的方式：先把历史数据完整传输到目标环境，再通过同步机制追平增量部分，缩短最后停机阶段的耗时。数据库使用主从复制或逻辑同步工具，文件类数据使用同步工具或对象存储迁移能力，两侧同时记录传输量与校验结果。

应用部署阶段统一环境变量与配置文件，把测试、预发、生产的差异项集中管理，避免出现改了一台忘了一台的情况。部署完成后先在目标环境跑一轮功能自测与关键接口验证，确认通过再进入割接环节。

分批搬迁，把风险摊薄

系统数量较多时，会按依赖关系把搬迁拆成若干批次：先搬没有外部依赖的后台服务与工具类系统，再搬有上下游调用的业务模块，最后处理数据库与核心交易链路。每一批都有独立的验证清单，上一批不通过就不进入下一批。

业务割接与回滚预案

割接是整个过程里要求最细的一段。我们会把切换动作拆成解析调整、流量放量、数据读写切换、旧环境降级等步骤，每一步都写明操作人、验证方式和判断标准。域名解析提前降低 TTL，负载均衡按比例放量观察，数据库在确认增量同步无延迟后再做写入切换。

回退预案和割接方案同时准备：原环境保持可运行状态，原解析记录和路由配置保留，出现异常时先停止放量、再切回原环境，把问题定位放到业务恢复之后进行。这样即使某个环节不顺利，用户侧感知也有限。

割接当天的现场配合

割接当天按提前确认的时间表推进，双方各有一名对接人。每完成一步在协同记录里留痕，出现判断分歧时以验收标准为准，不以主观感受决定是否继续放量。

上线后稳定性保障

业务切到新环境并不代表工作结束。上线后第一周是最需要关注的阶段，监控项覆盖 CPU、内存、磁盘使用率与 IO、连接数、慢查询、端口存活和关键接口耗时，告警按影响程度分级，先处理影响用户访问的问题。

备份策略按可接受的数据恢复点设定，定期做一次恢复演练，确认备份文件确实可用。前两周安排每日巡检，之后转为按周汇总，把资源使用趋势和异常记录整理成简报，作为后续扩容或降配的依据。