症状： 控制台显示更新命令已发送，但 macOS 27 节点不再执行旧的软件更新流程。
最快解法： 先迁移 MDM 控制面，再升级设备；没有通过声明式更新、强制安装、状态回传和失联恢复验收的生产节点，暂缓升级。

截至 2026 年 8 月 27 日，Apple 官方文档已将 macOS 27.0 的旧版软件更新管理列为失效范围；Apple Developer 发布页显示，当前公开测试线仍是 macOS 27.0 beta 6，版本号为 26A5416b，发布时间为 2026 年 8 月 17 日。(support.apple.com)

这篇文章适合三类人：

  • 管理企业远程 Mac 机群，需要制定 macOS 27 升级和分批放量策略的 IT 负责人。
  • 维护 MDM、设备合规和无人值守更新流程的平台工程团队。
  • 负责 iOS CI/CD 发布 SLA，需要避免构建节点因系统更新失控而中断的技术负责人。

注意： macOS 27 仍应按 Beta 状态管理。不要把 Beta 节点的成功结果直接当成正式生产准入证据；第三方 MDM 的支持范围也不能从 Apple 协议能力直接推导，必须逐项核实供应方当日文档。

第一步：先盘点旧更新控制面，而不是先升级 Mac

Apple 的变化不是简单地把一个命令换成另一个命令。官方部署说明指出，旧的软件更新管理在 27.0 系统中不再工作，受影响范围包括旧的软件更新命令、更新查询、推荐版本节奏设置和相关限制。(support.apple.com)

因此，你要先把当前工作流拆成四类动作：

  • 发现更新： 查询设备可用版本、硬件适配关系和推荐版本。
  • 决定更新： 选择目标版本、延期周期、通知规则和标准用户权限。
  • 执行更新： 下载、强制安装、重启和获取必要的启动凭据。
  • 证明结果： 记录策略是否生效、安装是否开始、失败原因和最终系统版本。

如果其中任何一步仍依赖旧命令，不能因为设备在控制台中显示在线，就判断它已经兼容 macOS 27。

你可以按下面的方式建立缺口清单：

  • 旧更新查询 → macOS 27 可能无法提供原有结果 → 改由声明式状态和 Apple 软件更新目录协同判断 → 影响版本可见性。
  • 旧推荐节奏设置 → macOS 27 不再作为可靠控制面 → 迁移到 SoftwareUpdateSettings 中的 RecommendedCadence 或对应声明 → 影响用户看到的版本范围。
  • 旧强制安装命令 → 不能作为 27.0 的回退路径 → 使用软件更新强制声明 → 影响合规截止时间。
  • 控制台“命令已发送” → 不等于设备已激活策略 → 订阅设备状态频道 → 影响审计证据。
  • 设备升级后重新上线 → 不等于 CI Agent 已恢复 → 增加服务健康检查和构建探针 → 影响发布 SLA。

Apple 的 SoftwareUpdateSettings 已定义自动行为、延期、通知、标准用户更新权限和推荐节奏等配置项；其中多个配置可以共同形成设备最终生效的配置。(developer.apple.com)

第二步：用平台能力证明 MDM 是否真的能迁移

“支持 macOS 27”不是合格的采购结论。你需要让 MDM 供应方回答五个可验证问题：

  • 能否为 macOS 设备通道启用 Declarative Device Management？
  • 能否同步 com.apple.configuration.softwareupdate.settings？
  • 能否创建指定版本和目标时间的强制更新声明？
  • 能否订阅 softwareupdate.* 与 device.operating-system.* 状态？
  • 能否导出设备级失败原因，而不是只返回一个任务成功状态？

Apple 的声明式管理可以与既有 MDM 命令和配置描述文件共存，企业可以渐进迁移，不必一次性重写所有设备管理流程。可是，声明式管理必须先通过 DeclarativeManagementCommand 启用；在 macOS 上，设备通道和用户通道需要分别处理，状态也分别回传。(developer.apple.com)

这意味着迁移并不是“在控制台勾选一个开关”。你需要确认平台是否真正完成了：

  1. 设备通道声明式管理启用。
  2. 用户通道声明式管理启用。
  3. 声明清单同步。
  4. 声明版本变化后的重新同步。
  5. 设备能力与服务能力匹配。

Apple 的能力模型要求设备通过 StatusManagementClientCapabilities 宣布支持的声明类型和状态项，服务端不应把设备没有宣布支持的声明发送过去。(developer.apple.com)

对企业采购来说，这里有一个容易被忽略的限制：协议支持不等于管理平台界面支持。即使 Apple 的 Schema 已经包含某个配置，平台也可能尚未提供策略编辑器、状态映射、失败重试或批量导出能力。你应要求供应方给出实际配置样例和导出结果，而不是接受一句“后续版本支持”。

第三步：把软件更新规则映射成声明

企业真正需要迁移的是规则，不是 JSON 外形。建议为每条现有规则建立一份内部映射记录，至少包含：

  • 原有规则名称。
  • 适用设备组。
  • 目标系统版本或构建版本。
  • 延期和通知要求。
  • 是否允许标准用户执行更新。
  • 是否允许 Beta。
  • 强制安装截止时间。
  • 冲突时的优先级。
  • 声明式替代项。
  • 验收状态和负责人。

最小化配置可以只保留解释声明类型、作用域和策略效果所需的字段：

{
  "Type": "com.apple.configuration.softwareupdate.settings",
  "Identifier": "software-update-policy-prod",
  "Payload": {
    "Notifications": true,
    "AllowStandardUserOSUpdates": false,
    "Deferrals": {
      "MajorPeriodInDays": 30
    },
    "AutomaticActions": {
      "Download": "AlwaysOn",
      "InstallOSUpdates": "AlwaysOn"
    }
  }
}

上面的结构只用于说明配置关系。具体键值、支持版本和设备范围，应以 Apple 当前的 SoftwareUpdateSettings 文档以及你的 MDM 实现为准。Apple 文档明确说明，软件更新配置允许多个配置共同组合，并作为一份最终有效配置应用到设备。(developer.apple.com)

这会带来三个实际风险：

✅ 策略重叠： 不同设备组同时收到多个声明，最终效果可能与控制台单条策略不同。
⚠️ 作用域错位： 设备通道和用户通道混用，导致策略看似已下发，实际没有在目标上下文激活。
❌ 版本锁定误判： 只验证目标版本字段，没有验证设备实际获得的待安装版本。

验收时不要只截图控制台配置。你要从设备状态和服务端导出中确认：

  • 当前声明是否有效。
  • 当前声明是否已激活。
  • 设备实际使用了哪些配置。
  • 是否存在冲突或无效原因。
  • 设备待安装的版本是否正确。

第四步：用状态回传区分“已发送”和“已完成”

软件更新管理最常见的审计错误，是把“配置已发送”当成“升级已完成”。

Apple 的软件更新强制流程包含多个阶段。声明激活后，设备会根据要求联系 Apple 软件更新目录并开始下载；在 Apple Silicon Mac 执行安装前，设备还可能向管理服务获取 bootstrap token。安装成功后设备重启，失败时则返回失败状态和原因。(developer.apple.com)

你的状态模型至少要拆成以下几层：

  • 配置已发送： MDM 服务已经完成声明同步。
  • 策略已激活： 设备确认声明有效并开始按规则处理。
  • 更新待安装： 设备已经识别目标版本和安装原因。
  • 安装进行中： 设备进入等待、下载或安装阶段。
  • 安装失败： 设备返回失败状态和失败原因。
  • 系统已重启： 设备重新上线。
  • 版本已确认： 设备回传最终操作系统版本和构建版本。
  • 业务已恢复： CI Agent、签名服务和构建任务通过探针。

Apple 提供的软件更新状态项包括待安装版本、安装状态、安装原因和失败原因；设备还可以回传当前操作系统版本与构建版本。(developer.apple.com)

建议审计记录包含：

  • 设备唯一标识。
  • 设备组和策略版本。
  • 声明标识符。
  • 策略发送时间。
  • 策略激活时间。
  • 安装开始时间。
  • 重启时间。
  • 最终系统版本和构建版本。
  • 失败原因。
  • 人工处置记录。
  • CI 恢复时间。

如果平台只能显示“成功”“失败”两个状态，无法提供设备级时间戳和失败原因，就不适合直接承载有发布 SLA 的生产构建节点。

第五步：在远程 Mac 上验证无人值守恢复

远程 Mac 的难点不在于能否下载更新，而在于重启后是否还能自动恢复。

数据中心节点通常没有人在旁边输入密码、点击确认或重新启动构建服务。你需要把以下故障分别设计证据和处置路径：

磁盘空间不足

设备应返回失败原因或至少产生可关联的系统事件。处置动作可以是暂停该设备的更新声明、清理缓存、转移构建任务，再重新触发策略。不要直接重复发送同一条声明，否则你只会得到更多“已发送”记录。

更新停滞

定义一个内部超时窗口，并用状态变化而不是控制台刷新判断是否停滞。若状态长期停留在等待或下载，先确认网络、Apple 更新目录访问、内容缓存和设备磁盘状态，再决定是否转移任务。

重启后 MDM 未上线

检查设备网络路径、推送通道、证书和设备身份。MDM 未重新上线时，不要把系统版本变化当成完整成功，因为你无法确认设备是否仍受策略管理。

FileVault 阻塞恢复

对于启用 FileVault 的 Apple Silicon Mac，要验证重启后的解锁路径、bootstrap token 使用情况以及 MDM 是否能继续接收状态。Apple 的软件更新强制流程明确提到，Apple Silicon Mac 在安装前可能需要从管理服务获取 bootstrap token。(developer.apple.com)

CI Agent 未自动启动

系统版本回传后，继续检查 CI Agent、代码签名工具链、钥匙串访问、缓存目录和构建任务。Mac 在线，不等于构建节点可用。

如果你需要准备隔离的远程 Mac 作为试点或替代节点，可以先从 远程 Mac 计算资源方案 评估节点交付方式；若团队需要固定的 Apple Silicon 构建机，也可以对照 Mac mini 云算力订购方案 规划测试与主备资源。

用可勾选清单决定是否放量

以下清单适合在变更评审会上逐项签字。每个“否”都应对应负责人和回退动作。

MDM 控制能力

  • [ ] MDM 供应方提供了 macOS 27 声明式软件更新的正式功能文档。
  • [ ] 平台支持设备通道和用户通道的声明式管理启用。
  • [ ] 平台能同步软件更新配置和强制更新声明。
  • [ ] 平台能读取设备能力，并避免发送未支持的声明。
  • [ ] 平台文档列出了当前版本的已知限制。

策略执行能力

  • [ ] 已将旧命令、查询和推荐节奏逐条映射到声明式配置。
  • [ ] 已验证自动下载、自动安装、延期和通知规则。
  • [ ] 已验证标准用户权限与管理员权限的差异。
  • [ ] 已验证目标版本或构建版本没有被其他声明覆盖。
  • [ ] 已从设备实际状态确认最终有效配置。

状态与审计能力

  • [ ] 能区分配置发送、策略激活、安装进行中和安装完成。
  • [ ] 能读取待安装版本、安装状态和失败原因。
  • [ ] 能读取最终操作系统版本与构建版本。
  • [ ] 导出结果包含设备标识、策略版本和时间戳。
  • [ ] 失败节点有人工处置和重新验证记录。

远程恢复能力

  • [ ] 远程 Mac 能在无人值守条件下完成重启。
  • [ ] FileVault 解锁和 bootstrap token 流程已验证。
  • [ ] MDM 重启后能重新上线。
  • [ ] CI Agent 能自动恢复并通过构建探针。
  • [ ] 关键节点有带外重启、替代节点或可验证回退流程。

如果控制能力、策略执行和状态审计全部通过，但远程恢复没有通过，结论应是“限范围试点”，而不是“可放量”。如果关键构建机没有替代节点，结论应直接是“暂缓升级”。

用同生产策略建立最小试点证据

测试 Mac 不应只是安装了 macOS 27 的空机器。它必须使用与生产一致的：

  • MDM 声明和设备组规则。
  • 网络出口和证书链。
  • FileVault 配置。
  • CI Agent 与构建脚本。
  • 代码签名和钥匙串访问方式。
  • 缓存、日志和监控策略。

试点至少要覆盖机群中的主要差异维度，例如不同 Apple Silicon 型号、不同网络区域、不同磁盘状态、不同用户权限和不同构建工作负载。Apple 没有规定所有企业统一保留某个百分比的测试节点，因此节点数量应由这些差异和业务连续性要求决定，而不是简单按设备总数计算。

在试点期间，保留未升级节点承担正式发布任务。这样迁移失败时，你回退的是发布流量，而不是试图把一台已经失联的 Mac 强行恢复到原状态。

如需进一步规划主备构建资源，可以参考 Mac 构建节点的资源规划思路，重点核对替代节点是否能覆盖升级期间的发布负载，而不是只比较单台机器的配置。

文末 FAQ：把长尾问题转成准入条件

前面的准入清单通过后，你还应把结果写入企业变更记录。记录中不要只写“MDM 已支持 macOS 27”，而要写清支持了哪些声明、哪些状态、哪些恢复路径，以及哪些节点仍被排除。

如果现有生产 Mac 不适合承担破坏性升级测试，可以先准备一台与生产策略一致的隔离远程 Mac，验证声明式更新、重启恢复和 CI 工作负载，再根据证据扩展试点节点或批量放量。

当前继续依赖旧 MDM 命令的方案，最大问题是控制台反馈可能与设备实际行为脱节；纯人工维护的本地 Mac 又会增加采购、折旧、现场维护和替代节点成本。对需要临时测试环境、隔离升级节点或短期 CI 备用容量的团队，使用 MACCOME 的远程 Mac 可以先验证迁移假设，再决定是否长期采购实机；但如果你需要长期满负载运行、物理接口或完全自主管理硬件，自购 Mac 仍可能更合适。