云端实例开机脚本部署失败，先别急着反复重启：脚本可能每次启动都会再次运行，重复改动反而扩大故障。稳妥的云端实例开机脚本部署失败的回滚方法，是先阻止失败版本继续执行，再恢复脚本和实例状态，并逐项验证服务。
先判断失败发生在哪一层
查看控制台中的启动输出、串口日志或系统启动日志，确认错误是脚本下载失败、命令返回非零状态，还是服务启动后未就绪。记录失败时间、脚本版本和实例状态；如果脚本会重复运行，先暂停自动重试，或暂时移除触发脚本的配置。保留日志和当前配置，便于定位问题。
同时确认脚本是否已执行部分操作：例如创建用户、修改配置、安装软件或清理文件。只要脚本产生过这些副作用，就不能仅凭“脚本已改回旧版”判断实例也恢复了。
按影响范围选择回滚方式
只改了脚本配置
如果失败发生在脚本执行前，或没有改动实例内的数据和配置，通常可将启动脚本恢复为上一份已验证版本，再确认触发设置正确。以 Google Compute Engine 为例，若脚本通过实例元数据配置，应检查对应元数据中的脚本内容或来源；具体如何重新触发，需按实例代理和平台配置确认。
脚本已经改动系统
若服务配置、文件或软件包已被修改，优先恢复变更前的配置备份；没有备份且实例无法正常启动时，可考虑从磁盘快照恢复，或将启动盘接入救援实例后修复。磁盘快照的应用一致性取决于平台和工作负载，数据库等持续写入场景应先评估数据一致性，不能把快照当作必然完整的应用备份。
可执行的回滚步骤
- 停止扩散：暂停自动扩容、批量部署或启动重试；必要时先将故障实例从流量入口摘除。
- 保存现场：导出当前启动脚本和实例配置，记录错误日志、执行时间及已完成的操作。避免覆盖唯一一份可排查材料。
- 恢复脚本：将脚本版本切回上一个已知可用版本，或清除错误配置；同时检查定时任务、实例元数据等其他触发来源，避免旧失败脚本再次运行。
- 修复实例状态：按变更清单逐项撤销已完成操作；若无法安全在线修复，再使用可用备份或救援方式处理，并确认目标磁盘及实例对应无误。
- 验证后恢复：先在单台实例上启动，检查启动日志、磁盘空间、关键进程和应用健康状态；通过后再恢复流量或扩大部署范围。
回滚后如何避免重演
部署前保留上一版脚本，并为关键配置准备可恢复副本。把脚本写成可重复执行：重复运行时检查目标状态，避免重复创建资源或覆盖已有数据；遇到错误及时退出，不要继续执行后续破坏性步骤。变更时先用一台非关键实例验证，再分批推送。若使用 cloud-init，应结合该实例镜像和配置检查其执行记录与日志，确认失败脚本是否会在下次启动再次处理。
简单来说，云端实例开机脚本部署失败的回滚方法不只是换回旧脚本：还要判断脚本是否改动过实例，必要时恢复磁盘或配置，并验证服务确实正常后再结束回滚。
常见问题
回滚时要不要重启实例？
取决于平台和脚本触发方式。先确认改回配置后是否会立即生效；确需重启时，先保留日志并确认不会再次执行故障版本。
脚本执行到一半失败，能直接重跑吗？
不建议盲目重跑。先核对已完成的操作和副作用，撤销不完整变更，或确认脚本具备重复执行保护后再运行。
什么时候需要恢复磁盘快照？
当实例内的文件或配置已被破坏，且无法可靠地逐项修复时可考虑。恢复前确认快照时间、数据一致性及是否会覆盖之后产生的数据。
怎样确认回滚完成？
检查新启动日志无相关错误，服务进程和应用健康检查正常，并确认失败脚本不会再次触发。仅看到实例显示“运行中”并不足以证明业务已恢复。