选型从约束开始
工具选型最常见的失败方式是先看功能清单，再看能解决什么。更稳妥的顺序是先把硬约束写清楚：被管对象是服务器、网络设备还是容器编排平台；控制端能否反向访问被管节点；团队现有技能集中在哪种脚本语言；节点规模是数十台还是数千台；合规是否要求操作留痕与双人复核。这些约束通常能直接排除掉多数候选，剩下的才比较生态、可维护性与长期成本。
基本信息
| 第一步 | 明确要自动化的变更类型与频率 |
|---|---|
| 第二步 | 列出不可协商的硬约束 |
| 第三步 | 筛选 2 至 3 个候选做小范围试点 |
| 第四步 | 按维护成本与退出成本决策 |
评估维度
- 对象覆盖：目标平台是否原生支持，还是需要大量自研适配层。
- 网络模型：推送还是拉取，是否能适配现有网络分区与出口策略。
- 团队技能：现有人员多快能独立编写与排错，是否需要长期培训投入。
- 规模与性能：并发执行能力、控制端资源需求、是否支持分布式执行。
- 可观测与审计：执行记录、变更差异、失败详情是否可查询可导出。
- 退出成本：资产是否可迁移，是否会被专有格式锁死。
常见组合与适用判断
| 组合方式 | 适合情况 | 主要代价 |
|---|---|---|
| 纯脚本加调度 | 变更类型少、频率低、团队规模小 | 幂等性与记录靠自己保证 |
| 无代理配置管理 | 服务器与网络设备混合、历史主机多 | 大规模并发需额外编排 |
| 代理式管理平台 | 节点规模大、需要持续合规 | 代理生命周期与安全评审 |
| 基础设施即代码工具 | 云资源与网络资源需要版本化管理 | 状态文件与权限管理要求高 |
| 编排平台加流水线 | 需要审批、发布与回滚串联 | 平台自身需要独立运维投入 |
试点要比对的不只是功能，更是「新人多久能改对一条任务」。工具的效率差异在半年后才显现，而学习成本从第一天就在发生。
同时引入两套功能重叠的平台是长期隐患：同一台主机的配置被两处管理、执行记录分散在两地、责任界面模糊。若必须共存，先划定各自负责的对象范围并写进规范。