部署后立即执行健康检查是防止“假成功”的关键，需在gitlab ci中新增verify阶段依赖deploy，用curl/jq/systemctl等工具验证http状态、响应内容、耗时、服务状态及依赖连通性，任一失败须exit 1中断流水线并告警。
部署完成后立刻执行健康检查，是防止“假成功”的关键一步。GitLab CI 本身不内置健康检查逻辑，但你可以用标准 Shell 脚本 + curl / jq / systemctl 等工具，在流水线末尾手动添加一个验证阶段，由 Runner 自动执行。
在 deploy 后新增 verify 阶段
把健康检查写成独立 stage，显式依赖 deploy，确保它只在目标环境生效后运行：
- 在 .gitlab-ci.yml 中定义 stages：增加
- verify - 用
needs: ["deploy"]强制顺序，避免并行导致检查目标未就绪 - 指定合适 runner 标签（如
tags: [shell]或[k8s]），确保能访问线上服务地址
编写可落地的健康检查脚本
脚本核心是模拟真实请求并校验结果，重点不是“通不通”，而是“对不对、快不快”：
- 主入口检查：
curl -s -o /dev/null -w "%{http_code}" https://your-app.com/，期望返回200，且响应体非空（可用curl -s https://... | grep -q "<title>"</title>） - 健康端点验证：
curl -s https://your-app.com/health | jq -e '.status == "UP"'，失败则退出 - 响应时间控制：
curl -s -w "%{time_total}" https://... -o /dev/null | awk '{if ($1*1000 > 300) exit 1}'（单位转毫秒，超 300ms 就报错） - 连续多次取稳：
for i in {1..3}; do ...; done | awk '{sum+=$1} END{if (sum/3 > 0.3) exit 1}'
对接真实运行环境
仅查 HTTP 不够，尤其对后台服务或容器化部署：
- 如果是 systemd 服务，加
systemctl is-active --quiet myapp && ! systemctl is-failed --quiet myapp - 如果是 Docker 容器，用
docker ps --filter "name=myapp" --format "{{.Status}}" | grep -q "Up" - 若依赖数据库，跑一条轻量查询：
mysql -h db -u user -p'pass' -e "SELECT 1" &>/dev/null || exit 1
失败必须中断并通知
健康检查 job 里任何一步失败，都要 exit 1，让整个 pipeline 停止，并触发告警：
- GitLab 内置通知：配合
after_script发 Slack 或邮件（需提前配置 Integration） - 脚本末尾加判断：
if [ $? -ne 0 ]; then echo "Health check failed!" >&2; exit 1; fi - 避免静默失败——不报错、不中断、不通知，等于没检查
