迁移不是一次性重写
手工运维里隐藏着大量未写下来的判断：看到某个报错就跳过一步、发现端口被占用就换个顺序。直接把这些流程写成自动化脚本，会把隐含经验丢掉，导致脚本在异常路径上失效。可行节奏是先按实际执行顺序记录步骤与判断点，再把这些判断显式编码进任务，然后按「只读验证 → 小范围变更 → 分批放量」的顺序推进，每一步都留下回退方式。
基本信息
| 第一步 | 记录现有手工步骤与其中的判断点 |
|---|---|
| 第二步 | 在非生产环境复现并验证 |
| 第三步 | 生产环境以只读任务验证采集与判断 |
| 第四步 | 小范围放开变更动作并观察 |
| 第五步 | 按批次扩大范围直到全量 |
每一步的验收条件
- 记录阶段：步骤顺序与实际一致，包含失败分支而不只是成功路径。
- 复现阶段：非生产环境重复执行结果一致，异常路径也能走到预期分支。
- 只读阶段：生产环境的现状采集准确，判断条件与人工经验一致。
- 小范围阶段：在少量节点上执行变更，验证结果与回退可用。
- 放量阶段：每批扩大后对比成功率与耗时，异常立即暂停并回退到上一批规模。
迁移各阶段关注点
| 阶段 | 主要动作 | 失败风险 |
|---|---|---|
| 步骤记录 | 访谈与实际跟岗 | 漏掉异常分支 |
| 环境复现 | 在测试环境跑通 | 测试环境与生产差异大 |
| 只读验证 | 采集现状与判断 | 权限不足导致结果失真 |
| 小范围变更 | 少量节点改动 | 回退路径未验证 |
| 分批放量 | 逐步扩大范围 | 问题在后期批次才暴露 |
迁移期间允许手工与自动化并存，但必须写清楚谁负责哪些节点：否则同一台机器可能被两套流程各改一次，问题定位时双方都认为自己没做错。
每一阶段都保留可执行的手工流程作为兜底，直到自动化在真实故障场景中被验证过至少一次，才考虑删除旧流程。