down指令本质是将Nginx upstream静态下线纳入平台闭环，实现业务节点无感平移；平台需接管全链路：模板引擎注入、原子化发布、失败自动回滚，并在下线前调用健康接口验证。

在自动化运维平台中配置 down 指令，本质是将 Nginx upstream 的静态下线能力纳入平台调度闭环，实现业务节点“无感平移”——即对用户零感知、对其他节点零干扰、对服务SLA零影响。关键不在指令本身，而在平台如何触发、校验、协同和回滚。

down 指令必须由平台接管配置变更链路

不能依赖人工编辑 nginx.conf 后手动 reload。平台需具备：

• 配置模板引擎：upstream 块使用变量或标签（如 {{ node_ip }}:{{ port }} down），由平台注入目标节点信息
• 原子化发布能力：生成新配置 → 语法校验（nginx -t）→ 安全备份旧配置 → 执行 nginx -s reload
• 失败自动回滚：若 reload 失败或探测到 upstream 中无可用节点，立即恢复上一版配置并告警

下线前必须完成平台级健康前置验证

down 不做探测，但平台要补足这一环。避免“刚标 down，后端其实还没停稳”导致请求丢失：

• 调用后端健康接口（如 /healthz），确认返回 200 且响应时间
• 检查该节点当前连接数（通过 ss -tn sport = :8080 | wc -l 或 Prometheus 指标）是否已趋近于 0
• 平台记录本次下线操作的 trace_id，并关联到该节点最近 5 分钟的错误率、延迟 P95 等基线数据，用于事后归因

与 backup 节点联动，实现流量自动承接

单纯 down 会丢流量；配合 backup 才构成完整平移逻辑：

• 平台在下发 down 前，自动检查同 upstream 中是否存在标记为 backup 的节点且状态就绪
• 若存在，可同步触发 backup 节点的预热（如发送 10 次 warmup 请求），避免冷启动抖动
• 若不存在 backup，平台应拒绝执行 down，并提示“缺少备用承接节点，建议先部署 backup 实例”

上线恢复需平台闭环验证再放行

维护完成后，不能仅删掉 down 就 reload —— 平台必须确认服务真正可用：

• 主动向恢复节点发起连通性测试（TCP + HTTP HEAD）、接口功能测试（如模拟一次核心业务调用）
• 比对恢复前后 metrics：QPS、错误率、平均延迟是否回归基线 ±10% 内
• 只有全部验证通过，平台才执行“删 down + reload”，否则冻结操作并通知负责人