规模瓶颈会转移
几十台节点时几乎任何工具都能胜任；节点数上千后，瓶颈往往不在任务逻辑，而在连接建立、凭据读取、结果回传与日志写入。评估规模时不能只看节点总数，要看单次任务的并发上限、单节点平均执行时长与可用的变更窗口：一万台节点、每台五分钟、并发一百，一轮就要超过八小时，必须靠分批与错峰而不是硬提并发。
基本信息
| 关键输入 | 节点总数、单节点执行耗时、可用的变更窗口 |
|---|---|
| 控制端约束 | 并发数上限、内存与文件句柄、凭据检索性能 |
| 网络约束 | 连接新建速率、带宽、跨机房链路质量 |
| 输出结论 | 每批节点数、批次数、所需执行窗口 |
需要评估的维度
- 并发上限：控制端能同时维持多少连接，超限后错误率如何变化。
- 单节点耗时：任务本身耗时与连接建立耗时各占多少，能否优化。
- 凭据与密钥：集中存储的读取性能，是否成为串行瓶颈。
- 结果与日志：执行回传的数据量，汇聚与检索是否跟得上。
- 失败重试成本：失败节点重跑一轮的额外时间与资源开销。
- 分层控制：是否需要按机房或网段部署多个执行节点分担压力。
规模阶梯与主要瓶颈
| 节点规模 | 主要瓶颈 | 建议做法 |
|---|---|---|
| 数十台 | 几乎没有瓶颈 | 单控制端串行或小并发即可 |
| 数百台 | 执行窗口与并发设置 | 分批执行并设置最大并发 |
| 数千台 | 连接速率与凭据检索 | 错峰调度、按组执行 |
| 上万台 | 控制端资源与日志汇聚 | 分层执行节点、按机房分批 |
| 弹性环境 | 清单变化频繁 | 改用动态清单并加执行锁 |
规模评估的结论要落到具体数字：每批多少台、间隔多久、整轮最长耗时多少、失败重试留多少窗口。只写「支持大规模」这样的结论在实施阶段没有指导价值。
留出冗余而不是把窗口排满：任务耗时随目标节点负载波动，曾经刚好跑完的窗口在业务高峰期必然超时。