CPU不高但响应慢，迁移云服务器前如何评估停机窗口与回退条件？

交付当天如果只看到 CPU 总使用率不高，就直接把业务迁移到更高配置的云服务器，最容易出现两种结果：迁移后响应速度没有改善，或者切换过程中数据无法回退。云服务器 CPU 使用率不高但响应慢，可能是哪些资源出现瓶颈？常见原因包括内存回收或 Swap、磁盘 I/O 等待、单个 CPU 核心或线程饱和、网络连接队列、应用连接池，以及数据库、缓存、消息组件或外部服务变慢。

因此，是否迁移不能由 CPU 曲线单独决定。只有当现网瓶颈已经被监控或现场检查确认，并且目标服务器具备对应的改善能力，同时完成数据同步演练、兼容性验证和回退演练，迁移才有明确收益。停机窗口则应以演练中的最终增量同步、服务排空、入口切换、业务验收和回退预留时间为依据，而不是凭数据总量或经验估算。

一、先确认瓶颈，再判断迁移是否值得

1. 建立一份可对比的现网基线

在业务正常且响应慢现象能够复现的时段，连续记录接口响应时间、错误率、超时数、并发连接数和下游请求耗时。这里要区分两个概念：并发连接数表示同时保持的连接数量，不能直接替代每秒请求数。如果要判断吞吐能力，还应记录实际请求速率、消息处理速率或数据库事务速率。

基础资源至少记录以下项目：

• CPU 总使用率、各 CPU 核心使用率和系统负载；
• 内存可用量、Swap 使用和内存回收情况；
• 磁盘空间、inode、I/O 等待、设备繁忙程度和读写等待；
• 网络连接数、监听队列、重传和连接建立失败情况；
• 应用线程池、连接池、任务队列和请求排队时间；
• 数据库锁等待、慢查询、缓存命中情况和其他依赖服务耗时。

没有现成监控平台时，可以先使用只读命令收集现场信息。部分工具需要预先安装，命令本身不会修改业务配置：

date -Is
hostname
uptime
free -h
vmstat 1 5
df -hT
df -ih
ss -s

如果服务器已安装 sysstat，再观察各 CPU 核心和磁盘设备：

mpstat -P ALL 1 5
iostat -xz 1 5

这些命令只能提供现场采样，不能单独证明某个组件就是根因。应把采样时间与慢请求、错误日志或业务操作时间对应起来。

2. 根据结果解释瓶颈位置

如果现网瓶颈无法与目标服务器的某项能力建立对应关系，就不应仅因“CPU 使用率不高”而安排停机迁移。例如，数据库锁等待、第三方接口变慢或应用代码中的串行队列，通常不会因为换一台应用服务器自动消失。

迁移收益可以用一个简单的判断式表达：

迁移收益成立 = 已确认的现网瓶颈 × 目标环境具备对应改善能力 × 应用和依赖能够兼容

三个条件缺一不可。只完成前两个条件而未验证兼容性，可能得到一台资源更充足但业务无法正常启动的服务器。

二、按真实数据量和演练结果确定停机窗口

1. 先盘点需要迁移的对象

df -h 显示的是文件系统使用量，并不等于全部迁移数据量。应分别盘点：

• 应用程序、依赖文件和运行时配置；
• 上传文件、附件、图片和其他业务文件；
• 数据库数据、事务日志或增量日志；
• 必须保留的缓存内容；
• 消息队列中尚未处理的数据；
• 定时任务、脚本、证书和密钥文件；
• 迁移期间仍会新增或修改的增量数据。

日志、临时文件和可重新生成的缓存不一定需要迁移，但必须先确认它们是否包含业务数据、审计记录或恢复所需信息。数据库持续运行时，不能把正在使用的数据目录简单当作普通文件目录复制，应使用对应数据库版本支持的备份、复制或导出方式，并验证恢复结果。

2. 用变量计算窗口，不用磁盘大小直接代替

停机窗口可以按以下方式拆分：

停机窗口 = 最终增量同步时间 + 服务排空或停止时间 + 入口切换时间 + 功能验收时间 + 回退预留时间

其中，最终增量同步时间必须单独测量，不能用首次全量复制时间代替。至少需要记录：

1. 全量数据复制耗时；
2. 业务运行期间各时段产生的增量数据量；
3. 增量同步速率；
4. 最终停止写入后剩余数据量和同步耗时；
5. 同步完成后的校验、入口切换和验收耗时。

可以使用变量表示收敛条件：

增量同步速率 Vsync > 业务增量产生速率 Vwrite

如果 Vsync 长期小于或接近 Vwrite，同步就无法稳定收敛，停机窗口没有可靠依据。此时应减少迁移期间的写入、采用支持增量复制的方式、调整数据同步方案，或重新评估是否适合在当前窗口迁移。不能用“并发连接数较少”来推断数据增量少，数据量应根据实际字节数、记录数、文件数量或日志产生量测量。

3. 用一次完整演练校准时间

正式迁移前，应在不影响生产的条件下按正式步骤做预演。预演至少包括：

• 按正式方式准备目标服务器和运行环境；
• 复制具有代表性的数据，而不是只复制少量小文件；
• 启动服务并执行本机、外部入口和关键业务验证；
• 模拟最终增量同步和停止写入；
• 测量服务排空、入口切换、验收和回退耗时；
• 记录每一步的负责人、开始时间、完成条件和异常处理人。

大型数据库、海量小文件和持续写入目录，耗时特征可能完全不同。预演时应尽量覆盖实际数据规模、文件数量、单文件大小和写入速率。若只能使用缩小后的数据集，时间结果只能作为参考，不能直接承诺正式停机时长。

三、迁移前完成系统、配置和依赖兼容性核对

目标服务器即使资源更多，也可能因为操作系统、CPU 架构、运行时、文件路径或权限不同而启动失败。源端和目标端都应记录基础环境：

uname -a
uname -m
cat /etc/os-release
command -v systemctl
command -v docker
ss -lntup

其中，systemctl 只适用于使用 systemd 的系统，docker 仅用于确认实际部署是否依赖 Docker；命令不存在不代表系统异常，应结合现有部署方式判断。ss -lntup 可能需要相应权限，重点是核对监听端口、监听地址和实际进程。

兼容性清单至少应覆盖：

• 操作系统发行版和主要版本；
• CPU 架构；
• 运行时、动态库和扩展版本；
• 服务启动方式、启动顺序和环境变量；
• 文件路径、挂载点、软链接和权限；
• 定时任务、后台消费者和日志目录；
• TLS 证书、密钥权限和证书链；
• 防火墙规则、监听地址和外部访问控制；
• 数据库、缓存、消息服务的连接地址；
• 外部系统是否按源服务器地址进行访问控制。

如果目标端不是相同操作系统或相同架构，不要直接假设源端二进制文件可以运行。应在目标环境重新安装或构建依赖，并通过启动日志确认动态库、配置文件和数据路径加载正确。

配置应形成可交接的清单，而不是依赖操作人员记忆：

密码、私钥和访问令牌不应直接写入命令行或公开脚本。目标端应通过受控配置管理或安全传输方式提供敏感配置。

四、按低风险顺序执行迁移

1. 迁移前确认前置条件

开始正式操作前，确认源端和目标端均可登录，目标端已安装所需运行环境，并且备份能够读取和恢复。备份不仅要确认文件存在，还要记录备份时间点、恢复点和可能丢失的数据范围。

同时确认：

• 目标端有足够的存储空间、内存和文件权限；
• 日志、监控和告警已经接入；
• 已明确切换、验收和回退负责人；
• 已通知业务方停机窗口和影响范围；
• 可能自动运行的定时任务已经暂停或登记；
• 源端不会在切换后被无意地继续写入。

2. 先做非破坏性同步

应用文件或静态文件可以先执行模拟同步，路径和目标地址需要替换为实际值：

rsync -a --dry-run --itemized-changes /srv/app/ user@target-server:/srv/app/

确认变更清单符合预期后，再进行首次同步：

rsync -a --info=progress2 /srv/app/ user@target-server:/srv/app/

首次同步不建议直接使用带删除效果的参数。若确实需要删除目标端多余文件，必须先确认目标目录专用于该应用、目标端已有备份，并明确删除后的恢复方法。数据库目录、正在写入的日志目录和运行时临时目录不应直接按普通文件目录复制。

同步完成后，应在目标端核对关键目录、文件数量或抽样校验值。发现路径、权限或文件内容不一致时，应先修正同步范围，不要直接进入正式切换。

3. 启动目标端并做分层验证

若环境使用 systemd，先确认实际服务名：

systemctl list-units --type=service --all

再查看服务状态和近期日志：

sudo systemctl status app.service
sudo journalctl -u app.service --since "10 minutes ago" --no-pager

如果应用提供健康检查接口，可先进行本机验证：

curl --fail --max-time 5 http://127.0.0.1:PORT/health

服务无法启动时，先检查运行时版本、配置路径、权限、证书、端口冲突和依赖连接；不要在尚未确认原因时反复重启或覆盖配置。健康检查通过也不等于迁移成功，还要从实际入口验证域名、证书、鉴权、查询、写入和关键业务流程。

4. 执行最终同步和入口切换

正式切换按以下顺序进行：

1. 暂停新的写入请求，必要时启用维护页；
2. 等待正在处理的请求排空，并确认队列和后台任务状态；
3. 停止会继续写入源端的应用或任务；
4. 执行最后一次增量同步；
5. 在目标端确认配置、数据和服务状态；
6. 切换负载均衡入口、域名解析或其他正式访问入口；
7. 先验证健康检查，再验证登录、查询、写入和关键业务流程；
8. 进入观察期，保留源端数据和回退能力。

例如使用 systemd 停止服务：

sudo systemctl stop app.service

该命令会造成业务中断，执行前必须确认服务名、依赖关系、影响范围和已验证的备份；执行后通过 systemctl status、端口检查和日志确认服务确实停止。停止源端后，不能只依赖“重新启动旧服务”完成回退，还要先处理目标端已经产生的数据。

五、把回退条件写成可观察的动作

回退条件应在操作单中预先写明，并使用可以观测和记录的指标。以下情况通常应暂停切换或进入回退评估：

• 目标端服务无法启动，或关键依赖持续连接失败；
• 健康检查通过，但登录、查询、写入等关键流程失败；
• 数据校验出现缺失、重复或明显延迟；
• 错误率、超时率或关键接口响应时间超出迁移前约定的可接受范围；
• 目标端资源使用方式与预演明显不一致且持续恶化；
• 外部系统无法访问目标端，且无法在窗口内修复；
• 最终同步无法完成，或无法确认数据已经收敛；
• 观察期内出现重复消费、重复执行定时任务等业务风险。

回退方式取决于目标端是否已经产生写入。

目标端尚未产生新写入

如果目标端没有接收业务写入，且源端仍然是最新数据，可以暂停目标端入口，将访问切回源端，恢复源端服务并重新验证关键流程。切回后仍要检查源端监听、依赖连接和入口状态，不能只看进程是否启动。

目标端已经产生新写入

这时不能直接把入口切回源端，否则可能造成数据丢失或数据分叉。应按以下顺序处理：

1. 立即停止目标端新的写入；
2. 记录目标端已经产生的数据和操作时间；
3. 判断是否能够把目标端增量反向同步到源端；
4. 如果不能反向同步，使用已经验证过的备份恢复或人工对账方案；
5. 确认源端数据状态后，再切回源端；
6. 保留目标端现场、日志和同步记录，便于追查原因。

没有明确的数据合并方案时，不应让源端和目标端同时接受写入。更安全的做法是先进入只读或维护状态，完成数据状态判断后再决定回退。

六、切换后的验收、留证和复核

验收至少分为基础、访问、数据和性能四层。

基础层检查目标端进程、监听端口、启动日志、依赖连接、磁盘、内存、文件系统和监控采集是否正常。连续启动失败、权限错误或依赖连接失败，说明目标端尚未达到交付条件。

访问层从实际访问入口验证域名、证书、端口、健康检查、登录、鉴权、权限边界、常用请求和异常请求。只打开首页不能证明业务链路正常。

数据层抽查关键数据，核对重点目录、文件数量或校验值，并验证新增数据能写入后再次读取。同时检查队列、定时任务和后台处理是否出现重复、遗漏或积压。

性能层将切换后的响应时间、错误率、超时、连接数、内存、磁盘 I/O 和下游耗时与迁移前基线、预演结果进行同口径比较。成功标准应以事先约定的业务指标和可接受范围为准，而不是只看 CPU 是否下降。如果 CPU 下降但数据库耗时、I/O 等待或下游请求耗时没有改善，说明迁移可能没有解决原始瓶颈。

出现异常时，应保存切换时间、最后一次同步完成时间、入口变更记录、关键接口结果、数据校验结果和现场采样：

date -Is
hostname
uptime
free -h
vmstat 1 5
df -hT
df -ih
ss -s
journalctl -u app.service --since "30 minutes ago" --no-pager

日志和命令输出可能包含账号、令牌、个人信息或私钥内容，归档前应脱敏。迁移完成后不要立即销毁旧服务器，应在预先约定的观察期内复核目标端是否仍有间歇性超时、后台任务是否按预期执行、数据是否持续增长、告警是否完整，以及备份、配置和入口权限是否仍可用于回退。只有在瓶颈改善、业务验收通过、数据状态明确且回退路径仍然可执行时，才适合结束迁移窗口。