漂移是怎么发生的
手工热修过的参数会在下一次发布被覆盖，实例之间也可能不一致：同一个服务的两台机器跑着不同的参数，行为差异就很难解释。把配置纳入版本管理、发布前做差异比对、启动时留痕、定期巡检，漂移才能控制在可预期范围内。
基本信息
| 适用平台 | 自托管推理服务与多实例部署 |
|---|---|
| 漂移来源 | 手工热修、临时改参数、发布未同步 |
| 控制手段 | 配置入库、发布前比对、启动留痕、定期巡检 |
| 权限控制 | 限制手工修改并保留审计日志 |
巡检比对（示意）
巡检比对（示意）
# 现网生效启动命令与配置仓库目标值对比
systemctl show <服务> -p ExecStart > /tmp/running.txt
diff /tmp/running.txt /etc/llm/exec-start.expected
# 多实例抽查：接口探活加关键参数核对典型使用场景
- 配置即代码：启动参数写进仓库或配置中心，改动走评审
- 发布前比对：现网生效值与目标值的差异必须为零或有意为之
- 启动留痕：启动时记录生效配置与版本，事后可回溯
- 多实例巡检：逐台抽查关键参数，找出不一致的机器
- 故障复盘：行为差异出现时，先比配置再怀疑代码
漂移类型与处置
| 漂移类型 | 典型表现 | 处置方向 |
|---|---|---|
| 参数不一致 | 同类实例行为不同 | 统一回配置仓库的目标值 |
| 版本不一致 | 镜像或权重版本不同 | 按发布记录对齐 |
| 配置未入库 | 重启后参数丢失 | 先入库再重启 |
| 配置未生效 | 文件写对但行为照旧 | 确认是否重载并核对生效值 |
限制手工修改权限并用审计日志兜底：漂移的根源常是临时改一下却没有归位。
把比对脚本接进发布流水线：靠人定期执行的检查，执行几次之后就会被跳过。
启动时打印生效配置：事后排查时不必再猜当时到底用的是哪套参数。