先给结论：推荐节奏这个配置项有三档取值——全部更新都推、只推给跑最老版本的机器、只推跨版本升级；它决定的是「谁先动」，跟推迟天数那种「多久动」是两个完全不同的维度。选错档的典型症状是把整个机队同时推到同一个版本，一次闪断全队受影响。
今年 9 月 14 日那次系统更新之后，有件事在同行圈子里被反复说到：过去常用的那套更新管理命令在新版本上不再起作用了。苹果在给企业用户的说明里列得很清楚——执行命令、状态查询、推荐节奏设置，以及推迟和后台安全改进这类限制，这几个都不再有效。所以推荐节奏这一项现在要去新的配置里找，界面位置变了，逻辑也跟着变了。
三档分别解决什么问题
第一档「全部更新都推」的机制最简单：只要有新东西就往下发。它的底层假设是机队状态高度同质、且业务对版本变化不敏感。适合的是机型单一、使用场景固定、并且有自动化测试兜底的队伍。体验到的一致性最好，代价是任何一次兼容性问题都会全队爆发。
第二档「只推给跑最老版本的机器」，作用是把分布拉齐。之所以会有这一档，是因为混跑机队的实际分布通常是长尾的——绝大部分机器集中在两三个版本，剩下 5% 到 10% 拖在很老的版本上。这一档只咬住那批最老的，把它们推到主流版本，其余不动。适合机型杂、采购批次多的队伍，我们自己在用这一档。
第三档「只推跨版本升级」，意思是中间的小修小补不主动推，只在跨大版本的时候统一步伐。它依赖的前提是你的安全管理用另外的手段兜住了（否则小补丁不推会积累漏洞），换来的收益是设备在运行期间几乎不会因为小版本变化重启。适合设备位置分散、重启成本高的场景，比如外勤、展陈、长期外借。
为什么推荐节奏和推迟天数要一起看
这两个参数经常被当成一回事，其实它们是正交的。推迟天数回答「新版本出来多久之后再动」，是时间维度；推荐节奏回答「这一批里哪些机器动」，是范围维度。两个乘起来才是实际的生效面：90 天推迟配合「只推最老版本」，意味着机队里最老的那批机器会在第 90 天迎来升级，其余的继续等。
需要注意的是这两项都只对受监督的设备起作用。这条约束被忽略的情况不少——配置看起来全下发了，实际生效的只有开了监督模式的那一部分。判断依据是实际行为：看机器有没有真的停在旧版本上，而不是看服务端有没有下发成功。
三个容易误判的地方
误判一：以为推荐节奏是控制时间快慢的。不等于——它控制的是范围，快慢由推迟天数决定。误判二：以为选了「只升最新」就不管安全了。不适用，中间层的补丁要靠别的机制兜，这一档本身不含安全管理能力。误判三：以为这三档对所有平台一致。不适用，具体可用项取决于设备管理服务端开放了哪些，先问清楚再配。
这套方法不成立的时候
需要提前说明：机队规模小于 30 台的，分档带来的收益往往小于维护成本，直接用「全部更新 + 30 天推迟」更简单可控。另外机队里有相当比例设备长期离网的，任何基于「当下状态」的分档判断都会失真，因为这些设备在服务端看到的最后一次状态可能已经过期超过 7 天。还有一种情况是设备要进入流转、马上要结清退出，这时候去动它的更新批次没有意义。
落到台账上是怎么记的
MDM.Plus 的设备台账里，系统版本号按「主版本加构建号」两列存，取的是设备自己上报的值，不做服务端推断。
给同行的一个自验判据
先做一件小事：把机队按当前版本号画一张分布表，看长尾在哪一侧。长尾偏老就选第二档，长尾偏新且机型统一就选第一档，承担不起频繁重启就选第三档。MDM.Plus 的台账这两列能直接导出做分布统计，我这边据此做的是判断建议，最终选哪一档还是使用的人说了算。
- 判据一：推荐节奏控范围、推迟天数控时间，两个参数要分开配、分开验证
- 判据二：这两项目前只对受监督设备起作用，配前先确认监督状态
- 判据三：先画版本分布再选档，长尾超过 10% 的机队不适合直接上第一档
- 判据四：状态过期超过 7 天的设备不参与分档统计，否则结论会失真
