Mac CI 服务 SLA 怎么验？2026 企业采购清单

SSH 连得上，但 Runner 没接到任务；或任务结束了，却拿不到可发布的构建产物。

最快的判断方法：不要只看主机可用率，必须验收 CI 任务能否启动和完成，并写清故障计时、排除条件、响应恢复责任与可核验证据。 可用率目标由团队的发布要求和服务合同共同确定，不存在适用于所有团队的通用数字。

企业 IT 或采购负责人：把服务承诺整理成可比较、可签字的验收条款。
平台工程负责人：区分远程 Mac 能连接与流水线真正可用。
技术总监或研发效能负责人：核对故障责任、恢复路径和发布风险是否有明确归属。

主机在线与任务成功：验收对象要对准流水线

SLA（服务等级协议）不是 SLI（服务等级指标），也不是 SLO（服务等级目标）的另一种写法。SLI 说明如何测量服务表现，SLO 是指标的目标，SLA 则是带有约定后果的协议；签字前应检查指标如何测量，以及未达目标会发生什么。服务等级术语与定义

对企业 iOS CI/CD 来说，SSH 或 VNC 可以访问，只能证明某种访问路径可用。它不证明 Runner 已注册、能接单、xcodebuild 能完成构建，也不证明 .xcarchive、导出包或测试结果能交付。Apple 文档将 xcodebuild 列为 Xcode 命令行工具，并说明它可用于构建项目；归档与导出也有明确的命令行流程。因此，验收对象应是双方约定的一条真实任务链，而不是单个登录探测。Xcode 命令行工具说明

采购条款至少要把这些项目写清：

合格任务是什么：指定仓库或样例工程、构建方案、目标平台、测试步骤，以及成功时应产生的产物。
何时算成功：任务被 Runner 接收、构建与测试通过、产物上传或交付，各自是独立状态；不能用“任务已启动”代替“构建已完成”。
失败如何归属：服务端不可用、Runner 未接单、客户代码失败、签名凭据错误、外部依赖超时，分别由谁举证和处理。
从哪里观测：CI 工作流状态、Runner 诊断日志、服务状态记录和产物信息由谁提供、保存多久、如何取得。

可用性指标应以节点在线状态还是流水线结果为核心？ 对采购验收而言，建议把用户关心的构建任务成功率作为关键指标；主机在线率可以作为诊断指标，但不宜单独代表业务可用性。SRE 指南强调指标应尽量反映用户实际感受到的服务行为；把这条原则应用到 CI，就是观察约定任务能否完成，而不是只观察机器能否响应。以用户体验定义服务目标

可把初始口径写成以下形式，再由双方根据业务场景约定有效任务和排除条件：

任务可用性 = 成功完成的合格 CI 任务数 ÷ 纳入统计的合格 CI 任务数

这不是通用合同公式。若同一构建任务会因代码错误失败，或由团队取消、依赖服务中断，合同必须说明这些事件是否纳入分母，以及如何确认归属。没有这些定义，表面上精确的百分比仍可能无法复核。

分母与停机起止：百分比之外还要看口径

可用率数字只有连同统计对象、统计窗口和故障判定一起出现，才有采购比较价值。条款应说明统计的是主机探测、Runner 接单，还是约定的 CI 任务；以什么周期汇总；任务被排队、取消或重试时如何计数。SLI 需要可测量，目标也要有明确条件，否则同一事件可能被双方算出不同结果。SLI、SLO 与 SLA 的区别和关系

故障事件从哪个可核验时点开始计时？ 不要默认以工单创建、客户首次发现或服务方确认中的某个时点为准。合同应指定事件开始和结束的判定证据：例如，连续的合格任务无法启动，且服务端记录或双方认可的 CI 日志能够佐证；结束则应以约定任务恢复为准，而不只是远程桌面重新连通。

停机口径建议逐项确认：

统计范围：纳入哪类 Mac 节点、Runner、工作流与任务；临时测试任务是否与正式发布任务同权重。
计时窗口：按自然时间还是约定服务时段统计；跨窗口事件怎样记录和归并。
起止证据：CI 日志、Runner 日志、服务状态记录分别用于证明什么；时间戳采用何种时区和来源。
重试与部分失败：第一次失败后重试成功是否算成功，构建通过但产物交付失败是否仍算任务失败。
排除事项：客户代码、权限配置、签名材料、外部依赖等由谁判定；排除是否要求提供原因和证据，而非由一方单方面标注。

提醒：合同如果只写“服务可用率”，却不定义测量对象、时间窗口和失败归属，就不足以直接判断一条真实 iOS 流水线是否达标。

事件响应与业务恢复：确认、处置、发布验证要分开

“收到工单”不是故障已处理，“远程访问恢复”也不等于构建能力恢复。建议把事件过程拆成可分别核验的状态，并为每项指定责任人、通知渠道和升级路径。公开的事件管理实践也强调明确指挥、操作与沟通职责，以免故障处理中出现责任空档。事件管理中的角色与交接

确认事件：服务方确认收到事件，并建立可追踪的事件编号或记录。
开始处置：明确谁负责检查节点、Runner、网络或系统环境；“已转交”不能自动算作开始处置。
恢复远程访问：SSH、VNC 或网页控制台重新可用。
恢复构建能力：Runner 能接单，约定的构建、测试与产物环节通过。
完成发布验证：客户按自身发布流程确认签名、导出和交付可继续。

响应时间、处置启动和恢复目标是不同承诺。若合同只写“响应时间”，就要追问它对应确认、开始排查，还是恢复服务。还应约定事件等级如何判断，服务方何时更新进展，由谁负责通知客户，以及跨团队交接后谁继续跟进。事件响应资料建议预先约定沟通渠道、角色和工作记录，这些做法可转化为采购时的流程核对项。事件响应准备与协同方法

计划维护与环境变更：例外必须有范围和记录

计划维护、重启和 Xcode 环境变化很容易被笼统归入“例外”。条款不能只写“维护不计入停机”，还应明确哪些服务、时间段和影响类型适用，以及通知、记录和验收责任如何处理。

计划维护和 macOS 更新的影响如何计入停机？ 不宜一概而论。合同应区分提前通知且范围明确的维护，与超出通知窗口、延误或导致构建无法恢复的事件；同时说明环境更新期间哪些任务暂停、如何确认恢复，以及发生问题时谁负责回退。若维护造成约定任务不可用，是否计入指标必须在合同中明确。

重点检查以下内容：

通知机制：通知渠道、通知内容、适用节点，以及临时紧急维护如何说明。
系统和工具链变更：macOS、Xcode、命令行工具或构建镜像变化是否提前说明；旧项目能否继续使用原环境，需要如何验证。
重启和回退：谁发起重启，出现构建回归时由谁决定和执行回退，回退后怎样重新验收。
记录方式：保留变更时间、影响范围、执行结果与恢复验证；状态记录不能只写“维护完成”。

经验提醒：Xcode 归档或导出失败，不一定能靠“节点重新在线”解决。验收应覆盖团队实际使用的构建环节，并保留可追溯的任务日志和产物状态。

可在测试流水线中加入简单的验收命令，并保存完整输出。以下仅为示意，不是任何服务的实测结果或服务承诺：

xcodebuild \
  -workspace App.xcworkspace \
  -scheme App \
  -destination 'generic/platform=iOS' \
  -archivePath build/App.xcarchive \
  archive

** ARCHIVE SUCCEEDED **

如需验证签名和分发流程，还要按项目的导出配置执行导出，并确认预期产物确实存在。CI 工作流日志可显示任务状态并支持下载；Runner 诊断日志能记录 Runner 活动；构建产物与日志也应按团队需要保存，供故障复盘和验收查证。工作流运行日志；自托管 Runner 监控与诊断；工作流产物的保存与共享

补偿与风险控制：服务抵扣不能代替备用路径

若协议包含服务抵扣或其他补救措施，应确认触发条件、申报期限、所需证据、提交渠道和核验方式。没有经过书面确认的补偿承诺，不应被当作采购决策的既定收益。不同服务协议的条件各不相同，不能拿别家条款推定本服务的承诺。

即便补偿条款清楚，它也无法替团队保住发布窗口。企业仍要评估：发布节点不可用时，能否切换到备用构建路径；发布前是否有足够的验证时间；签名凭据和构建产物能否由团队按既定权限访问。补偿处理的是合同后果，不是即时恢复业务。

签字前的证据包与采购分支

签约评审应收齐哪些故障和恢复材料？ 至少准备一份可复核的指标定义、服务状态记录样例、Runner 或 CI 任务日志样例、事件通知和交接流程、维护与变更规则，以及真实构建验收记录。CI 日志可以证明任务状态与步骤结果；Runner 日志补充执行端活动；产物记录则用于确认构建结果是否留存。工作流产物说明

可将以下决策条件列表带入采购评审：

若任务定义、分母、停机起止和排除条件均可测量，则进入合同指标与团队发布要求的匹配评审；否则要求补充书面定义，不以单一可用率签字。
若确认事件、开始处置、构建恢复和发布验证分别有负责人及证据，则评估响应和恢复责任是否满足业务要求；否则要求补齐升级路径和交接责任。
若维护、重启、系统更新及工具链变更的通知、计入方式和回退责任明确，则进入环境兼容性验收；否则要求收窄例外范围并补充验证步骤。
若服务状态、任务日志和构建产物可按约定取得并保存，则形成签字材料；否则将证据访问列为采购前置条件。
若关键指标不可测量、例外范围无法解释，或故障恢复没有明确负责人，则暂缓采购或要求补充条款，不用抵扣承诺替代这些缺口。

签字前可把这套口径与企业 Mac 租赁费用页面中的费用信息分开核对：价格不能替代 SLA，SLA 也不能替代团队的容量与发布风险评估。若还在评估远程 Mac 是否适合自己的构建负载，可先从 SFTPMAC 的远程 Mac 服务信息了解可核验的服务范围，再以实际合同、状态记录和构建验收结果作判断。

自购 Mac 的硬件归团队掌控，但采购、维护、闲置容量和故障替换都要自行承担；临时借用或拼接现有节点，则可能面临环境不一致、责任分散和发布高峰容量不足。对阶段性项目、迁移验证或需要弹性构建环境的团队，远程 Mac 租赁可以作为比较方案；但若负载长期稳定且持续繁重，或必须连接特定物理设备，自购可能更合适。在签署 Mac CI 服务协议前，先逐项对照本文的指标与证据要求；若需要临时构建或验收环境，再依据合同确认服务范围与责任后评估 SFTPMAC。