先说结论：分组批量执行的核心是「分组别混、先单台试跑、超时给 120 秒、失败重试 2 次」。每组控制在 20 台以内，按用途命名。指令里别写死 IP，用变量引用。这几条做到，能避开九成的批量翻车。
一、分组怎么建才不乱
进控制台的分组管理页，新建分组，按用途命名，比如 Web 集群、数据库、测试环境，别把不同用途的机器混在一起。把机器拖进对应的组，每组 20 台以内，出问题能快速定位。组多、机器多的时候，先在高阶群控版 30 元档确认台数够不够，别建到一半发现额度满了。
拖完先切「预览」模式，一台一台核对，确认无误再保存。嫌麻烦直接点确认的人，后面改分组比重建还费劲。分组名也别随手起，过两周自己都认不出是干什么的。
图：留一成余量
二、批量执行的四项设置
进分组详情点「批量执行」，把指令粘进去或手动输入，然后勾超时时间和失败重试次数。默认值偏保守，实际下发建议超时 120 秒、重试 2 次，网络抖动时不至于整批算失败。
| 设置项 | 建议值 | 原因 |
|---|---|---|
| 超时 | 120 秒 | 留足执行余量 |
| 失败重试 | 2 次 | 应对网络抖动 |
| 单组机器数 | 20 台以内 | 便于定位问题 |
下发前先拿组内一台试跑，输出正常再全量推。一条错指令能让整组设备全瘫，返工成本远超那几秒等待。
三、容易翻车的三个点
一是混组。Linux 的指令扔进 Windows 分组，立刻报语法错误。每组只放同类型系统，执行前看一眼分组标签确认系统类型。
二是在指令里写死 IP。换成变量引用，换组或扩容时不用逐条改。三是命令没做幂等，重跑一次就重复写入，重试次数开得越高，错得越狠。这三条，踩过的人都记一辈子。
四、跑得快还要跑得省心
常用指令存成「指令模板」，下次直接调用，不用每次重敲。执行报告要当回事，失败的那几台单独拉出来处理，别整组重跑白烧资源。
过期分组每两周清一次。分组堆多了，列表检索会卡，新分组还搜不出来。清理前把还在用的机器先挪到临时组，别手快删了。还有，分组标签和实例备注两处都写清楚，只看其中一处的人会认错机器。
规模再大一点，就要靠多开账号托管里的分工方式：一台机器上的账号、应用、网络配置统一登记，出了故障按登记表找，不靠记忆。批量操作省下的是点击次数，登记省下的是排查时间，两样都得有。
五、这套玩法不适合什么
只有一两台机器的，手动点比配分组快，先看安卓云机按量计费吗再决定买多久。指令本身没在单台上验证过的，先验证再批量。涉及支付、改密、实名的操作，别用批量下发，风险不可控。跨系统的组更别硬上，Windows 和 Linux 的路径分隔符都不一样，指令复制过去必错。
Q：一组最多放多少台？
建议 20 台以内。再多出问题定位慢，回滚也麻烦。
Q：执行到一半失败了怎么办？
先看报告里的失败原因，单台处理，别整组重跑。
Q：模板能改吗？
能，改了只影响下次调用，已下发的任务不受影响。常用的存三五个就够，存太多反而挑花眼。
图：贴着上限就升档
