部署失败时如何区分连接与脚本问题?

部署失败的时候，我最怕的不是报错本身，而是一上来就盯着脚本改半天，结果发现问题根本不在脚本里。前阵子我在云效 Flow 上做主机部署，就踩过这个坑：页面上只显示“失败”两个字，我下意识地把部署脚本从头看了一遍，最后才发现 Runner 压根没接到任务。所以我现在的习惯是，先把“连接问题”和“脚本问题”分开，再动手。

先说连接这一侧。在云效 Flow 里，主机部署的任务要靠主机组里的 Runner 来接收，Runner 不在线，任务就根本不会执行。判断方法很简单：打开部署详情，如果日志里几乎没有任何执行记录，基本可以先怀疑连接。这时候回到“全局设置”里的“主机组管理”，看一下该主机的 Runner 状态是不是正常。如果显示离线或安装失败，先检查主机能否访问流水线服务端的公网地址，再确认当初复制的安装命令有没有过期。命令过期了就关掉对话框重新生成，别拿旧命令硬撑，我以前就吃过这个亏。

还有一种情况比较隐蔽，是通过镜像创建的 ECS。自定义镜像或共享镜像会把旧的 Runner 进程和安装目录一起带进来，重新安装时容易冲突，表现出来就是部署失败、日志却很少。这种时候我的建议是先卸载旧 Runner，再重新接入，比在原地反复重试省事得多。

确认连接没问题之后，再看脚本。部署日志里如果能看到具体步骤和报错，说明任务已经跑起来了，问题大概率出在命令或路径上。我的做法是把日志里失败的那条命令，原样拷到目标主机上手动执行一遍，真实报错往往一眼就能看出来。最常见的是“文件不存在”：构建产出的是一个路径，部署脚本却去另一个目录找，两边对不上。所以每次改之前，我都会先去构建日志里确认制品的真实输出位置。

还有一个小习惯值得分享：每次只改一项配置，改完重新跑一次。别一口气把参数、脚本、路径全改了，出错的时候你根本不知道是哪一处起了作用。部署成功的版本会保留在部署历史里，万一新版本有问题，直接回滚到上一个成功版本，心里也踏实。