运营契约：SLO、成本、事故与多租户

生产系统不能只有部署清单，还需要一份带版本的运营契约，把用户承诺连接到测量、执行、决策权限和证据。契约要说明覆盖哪些流量、什么样的服务才算可接受、一次任务最多可以花费多少、必须守住哪些租户边界、发生事故时如何处理，以及谁有权改变这些决定。如果一项声明不能改变准入、路由、发布、事故处置或审查行为，它就只是指导意见，还不是运营契约。

前几章已经给出了所需机制。第 88 章 定义系统接缝，第 89 章 管理发布，第 90 章 定义可观测结果，第 91 章 约束人工决策，第 92 章 生成合格证据。本章把这些机制连接成一项可执行策略，同时不假设一个指标或一项控制能够覆盖所有任务。

站点可靠性工程提供了服务水平指标、服务水平目标、错误预算、事故角色和从故障中学习等基本概念 (Beyer et al. 2016)。FinOps 则让工程、财务、产品和业务团队共同对技术价值与成本负责 (FinOps Foundation 2026)。多租户还需要隔离与公平性。AI 系统扩大了运营契约的范围，因为响应可能按时到达却仍然错误，工具可能产生外部影响，裁判可能漂移，一个租户也可能耗尽共享的模型、检索、工具或人工审查容量。

把契约写成可执行 Schema

第一项工件不是仪表板，而是一份经过审查的 Schema，其中每个字段都有负责人和执行点。

未知值是一种状态，不是空白单元格。如果服务无法识别契约版本、核验租户声明、判断流量是否合格，或找到必需的测量来源，契约必须规定是拒绝、隔离、进入合格的安全模式，还是升级处理。即使默认值是在事故期间临时拼出的，它仍然是一项策略选择，也需要负责人。

图 93.1 展示了这项工件如何进入运行时。控制平面先校验契约，再发布不可变的契约版本。请求路径只携带每个边界所需的最少必要声明。遥测与证据用于支持决策，但不会直接改写线上策略。任何变更都要经过审查，并形成下一份契约发布版本。

如果运行时需要相应字段，上下文应包含不透明的租户标识符、契约版本、任务类别、预留标识符、服务类别、策略版本和轨迹标识符。不要把用户内容、凭据或宽泛授权复制到上下文中。检索、工具、模型、存储和审查的每个边界，都必须根据已经核验的声明重新授权当前操作。轨迹上下文不能授权操作，只能帮助关联证据。

区分 SLI、SLO 与 SLA

这三个概念相互关联，但不能混为一谈 (Beyer et al. 2016)：

• 服务水平指标（SLI） 是在精确定义下，对实际交付服务的定量测量。
• 服务水平目标（SLO） 是一个 SLI 在给定窗口内的内部目标或目标区间，还包括目标面临风险时采用的策略。
• 服务水平协议（SLA） 是对外承诺，可以规定未达到约定时的补救措施。SLA 需要法律和商务审查，内部仪表板本身不会形成 SLA。

对于基于事件的 SLI，先定义以下符号：$W$ 表示测量窗口，$E_W$ 表示该窗口内的合格事件集合，$G(e)$ 表示事件 $e$ 的达标事件判定条件。计算式为

$$\operatorname{SLI}_W = \frac{\sum_{e \in E_W}\mathbf{1}[G(e)]}{|E_W|}.$$

其中，$W$ 是预先声明的测量窗口，$E_W$ 是合格事件集合，$e$ 是其中一个事件，只有事件满足完整的用户可见条件时 $G(e)$ 才为真，$\mathbf{1}[G(e)]$ 对达标事件取 1、否则取 0，$|E_W|$ 是合格事件数。契约必须说明取消、超时、重复、重试、缺失和未知结果如何计入分母。例如，只统计成功响应的延迟，会把缓慢的失败隐藏起来。

达标事件判定条件可以组合能够直接观测的要求，例如“在截止时间前完成，且没有提交未经授权的外部影响”。不同任务即使共用一个端点，也不能随意取平均值。快速聊天、长篇报告和调用工具的工作流，可能需要不同的合格条件与达标定义。《Site Reliability Workbook》建议采用面向用户的 SLI，明确负责人，记录计算方法，并建立错误预算策略 (Thurgood and Ferguson 2018)。

语义质量需要单独的测量契约

许多语义结果在请求结束时还无法得知。判断回答是否有依据，可能需要概率样本、纳入概率、带版本的评分规则、裁判版本、人工校准、标签延迟、置信区间和测量覆盖率。这些要求来自 第 92 章 中的抽样与标注流程，并不会因为估计结果出现在仪表板上就消失。

延迟得到的质量估计可以约束发布、创建工单，或在满足决策条件时声明事故。但是，如果单次请求的标签还不存在，它就无法立即触发单次请求告警。即时呼叫值班人员应依赖能够立即观测的安全、授权、完整性、可用性、延迟或成本信号。延迟质量流程还必须规定最大标签延迟，并说明裁判不可用、标签缺失或抽样权重变化时如何处理。

有计划地使用错误预算

假设目标达标事件比例为 $S^*$。其中，$b$ 表示允许的不达标事件比例，$q_W$ 表示告警窗口 $W$ 内观测到的不达标事件比例，燃烧率 $\beta_W$ 定义为

$$b = 1 - S^*, \qquad \beta_W = \frac{q_W}{b}.$$

其中，$S^*$ 是目标值，$b$ 是错误预算比例，$q_W$ 是窗口 $W$ 中观测到的不达标事件比例，$\beta_W$ 表示该窗口相对于目标消耗预算的速度。燃烧率持续为 1，表示恰好按计划速度消耗预算；数值更大，则会更早耗尽预算。

根据小型滚动样本的置信界直接呼叫值班人员，并不是通用的告警策略。对于直接观测的事件 SLI，多窗口、多燃烧率规则可以区分快速告警和较慢的工单，并在告警触发时确认预算仍在持续消耗 (Thurgood et al. 2018)。阈值和窗口是服务决策，不是通用常数。低流量服务需要特别处理，因为一个事件就可能消耗很大一部分预算。只有在符合用户影响的前提下，才应采用合成探针、相关任务分组、影响较小的服务设计或人工个案审查。

错误预算策略必须说明预算健康、受到威胁或已经耗尽时，运营行为分别如何变化。可选行动包括放慢发布、提高审查强度、关闭可选功能、优先安排可靠性工作，或要求例外批准。行动必须可逆，而且不能在不说明的情况下把任务路由到不合格模型或不安全回退。

在执行之前控制成本

账单报告可以解释已经发生的支出，却来不及阻止正在失控的循环。运行时成本治理依次执行五个步骤：估算、预留、准入、计量和对账。预算层级可以覆盖任务、请求、租户、产品、环境和账期。每笔预留都必须计入所有适用层级，避免并发请求分别花掉同一笔剩余预算。

成本应归入最终被接受的整项任务，并涵盖所有尝试。设 $A_t$ 为任务 $t$ 的尝试集合，则任务总成本为

$$\begin{aligned} C_t &= \sum_{a \in A_t} \bigl( C^{\mathrm{model}}_a + C^{\mathrm{retrieval}}_a \\ &\qquad + C^{\mathrm{tool}}_a + C^{\mathrm{judge}}_a \bigr) \\ &\quad + C^{\mathrm{human}}_t + C^{\mathrm{storage}}_t. \end{aligned}$$

其中，$t$ 是一项用户任务，$A_t$ 包含原始尝试和每次重试或回退，$a$ 代表其中一次尝试。四个 $C_a$ 项分别是该次尝试的模型、检索、工具和裁判成本，两个 $C_t$ 项分别是任务级人工审查与存储成本。每个成本项都采用计量对账时记录的价格版本和币种。延迟入账会更新账本，但不会改写历史价格上下文。

对于任务集合 $T$，每个已接受任务的单位成本为

$$U_T = \frac{\sum_{t \in T} C_t} {\sum_{t \in T}\mathbf{1}[\operatorname{accepted}(t)]}.$$

其中，$T$ 是被测任务集合，$C_t$ 是任务总成本，$\operatorname{accepted}(t)$ 是带版本的接受判定式，$U_T$ 是每个已接受任务的单位成本。报告必须同时给出分母和拒绝原因，否则一个更便宜的系统可能只是靠让更多任务失败显得高效。

请求准入之前，应根据当前契约预留估算成本。执行结束后，再核对实际用量，释放未使用的预留，记录超支，并把未知用量或缺失价格版本送入例外队列。只有在仍满足任务的信息安全、质量、延迟和租户要求时，较便宜的路线才是合格回退。成本低本身不能证明路线合格。

下面这段无外部依赖的账本代码用整数成本单位演示幂等的预留与对账。生产账本还需要持久事务，并为提交状态未知规定恢复规则。

class BudgetLedger:
    def __init__(self, contract_version, tenant_id, budget):
        self.contract_version = contract_version
        self.tenant_id = tenant_id
        self.available = budget
        self.spent = 0
        self.reservations = {}

    def reserve(self, reservation_id, estimate):
        prior = self.reservations.get(reservation_id)
        if prior is not None:
            if prior["estimate"] != estimate:
                raise ValueError("reservation payload changed")
            return prior["state"] == "reserved"
        if estimate < 0 or estimate > self.available:
            return False
        self.available -= estimate
        self.reservations[reservation_id] = {
            "estimate": estimate,
            "actual": None,
            "state": "reserved",
        }
        return True

    def reconcile(self, reservation_id, actual):
        item = self.reservations.get(reservation_id)
        if item is None:
            raise KeyError("unknown reservation")
        if item["state"] == "settled":
            if item["actual"] != actual:
                raise ValueError("settlement payload changed")
            return
        if actual < 0:
            raise ValueError("negative actual cost")
        self.available += item["estimate"] - actual
        self.spent += actual
        item.update(actual=actual, state="settled")


ledger = BudgetLedger(contract_version="contract-v7", tenant_id="tenant-a", budget=100)
assert ledger.reserve(reservation_id="task-42", estimate=30)
assert ledger.reserve(reservation_id="task-42", estimate=30)  # no double reservation
assert ledger.available == 70
ledger.reconcile(reservation_id="task-42", actual=25)
ledger.reconcile(reservation_id="task-42", actual=25)  # idempotent settlement
assert not ledger.reserve(reservation_id="task-43", estimate=80)
print(f"spent={ledger.spent} available={ledger.available}")

FinOps 为技术价值和财务责任提供了跨职能运营框架 (FinOps Foundation 2026)。FOCUS 提供供应商中立的账单数据 Schema，不是实时准入控制器。FOCUS 1.4 于 2026 年 6 月 4 日正式批准；更早加入的虚拟货币字段可以在账单记录中表示词元的购入与消耗 (FinOps Open Cost and Usage Specification 2026)。供应商采用程度和数据送达延迟仍不一致。因此，运行时账本会与 FOCUS 或其他账单来源对账，但不会等到这些数据到达后才控制当前请求。

逐个边界落实租户隔离

租户是具有明确范围的信息安全、容量、数据和计费主体，不是从请求头复制出来的字符串。Kubernetes 记录了控制平面与数据平面隔离、配额、网络策略、沙箱、节点隔离和公平性控制，同时提醒使用者，仅靠命名空间不能实现隔离，还必须配合其他控制 (Kubernetes 2025)。AI 服务还要在这些边界上加入模型状态和语义状态。

公平性不能只靠限流。系统应在资源竞争条件下联合测试配额、预留、并发、优先级、队列纪律、背压和负载削减。噪声邻居测试应分别重放租户 A 和租户 B 的代表性工作负载，再比较有竞争和无竞争时的准入量、截止时间违约和质量。契约要规定哪些工作可以等待、降级或被拒绝。即使总吞吐量上升，静默的优先级反转仍然是故障。

隔离是一个向量。专用节点可以减少计算共享，却可能仍然共享控制平面、模型端点、索引、密钥、证据系统或人员。把不可信工具放进沙箱不能隔离检索；使用独立索引也不能限制出站访问。每项边界都应根据威胁模型和所需影响范围分别选择并测试。

把事故作为受控状态转换来处理

凡是需要协同处置，以限制重大服务影响或 AI 安全、信息安全、隐私、成本与租户伤害的事件，都属于 AI 事故。NIST SP 800-61 Revision 3 把准备、检测、响应和恢复纳入持续风险管理，而不是把事故响应视为孤立的紧急活动 (Nelson et al. 2025)。SRE 实践还要求明确指挥、运营、沟通、规划和实时状态 (Beyer et al. 2016)。

最少角色包括：决定优先级的事故指挥官、协调系统变更的运营负责人、负责干系人与租户更新的沟通负责人，以及保存决策记录的证据负责人。在较小的事故中，同一个人可以承担多个角色，但每项责任仍须明确。应分别记录检测时间、确认时间、遏制时间、恢复时间和最终核验。单一的“解决时间”会掩盖流程究竟卡在哪里。

图 93.2 明确展示了这些状态转换。从事故声明到恢复，沟通和证据保存必须持续进行。自动化可以执行预先验证合格的遏制动作，但必须保留变更前状态和执行确认。提交状态未知的操作仍应保持为独立状态，直到完成对账。

复盘必须区分根本原因与促成条件。每项纠正措施都要有负责人、截止时间和核验方法。措施可以增加评测个案、预算保护、路由规则、隔离控制、数据检查或批准边界。证据也可能支持接受风险，或有充分理由地决定不作变更。无论采取哪一种决定，都必须带版本且可以审查。

发布契约变更

可执行策略和代码一样可能出错。它的生命周期包括草拟、校验、影子运行、金丝雀发布、激活、监控、回滚和废弃。校验范围包括 Schema、责任归属、指标语义、依赖兼容性、授权、预算计算、租户边界、运行手册和证据接收端。影子运行只比较拟议决定，不实际执行；金丝雀发布用于限制影响范围；激活时记录生效版本；回滚则指向经过测试的先前版本，而不是在事故中临时重建旧策略。

紧急例外必须写明授权主体、范围、原因、开始时间、最大影响范围、证据要求和失效时间，而且应自动失效。如果要继续保留，就必须走正常审查流程。例外不能删除底层事件、绕过租户隔离，也不能阻止成本对账。

隐藏消费方和配置依赖会让机器学习系统难以安全变更 (Sculley et al. 2015)。应记录所有读取契约的系统：网关、调度器、模型路由器、检索器、工具策略、沙箱、评测、事故自动化、计费和报告。任何无法报告当前生效版本的消费方，都不具备协同发布条件。

把治理编译成有界控制

NIST AI 风险管理框架由组织自愿采用，不是认证标准 (Tabassi 2023)。它的生成式 AI Profile 给出了生成式 AI 风险和候选行动 (National Institute of Standards and Technology 2024)。团队可以用这些资料把风险映射到负责人、控制、测量和证据要求。运营契约不能替代法律分析、信息安全工程、隐私治理、雇佣义务或协商形成的 SLA。

Microsoft 的 GenAIOps 指南是一份由特定供应商提供的实现参考，覆盖监控、漂移、部署、治理和生命周期运营 (Microsoft 2024)。它可以提供示例，但不是普遍要求。契约应把每项外部义务或内部策略连接到具体执行点和测试，同时保留原始依据，以及完成这项转换的审查者。

决策权限让组织责任形成闭环。服务负责人提出承诺；测量负责人定义可复现指标；产品和业务批准人接受目标和预算策略；信息安全和隐私负责人批准各自的边界；值班角色负责事故运营；具名授权人接受剩余风险。职责分离的强度应与影响相称，但紧急情况下的操作者不能悄悄成为永久策略批准人。

发布前测试失败路径

端到端测试套件不能只覆盖成功请求，还应测试：

• 租户声明缺失、伪造声明和契约版本未知；
• 不合格事件、重复事件、指标流水线中断、标签延迟、裁判版本变化和测量来源缺失；
• 重复预留、预留载荷变化、并发超支、重试绕过预算、延迟成本、未知用量和价格版本变化；
• 预算耗尽、合格回退不可用，以及达到失效时间的紧急例外；
• 跨租户缓存命中、跨租户检索结果、错误加密密钥、工具凭据泄漏、证据导出和审查队列混用；
• 模型、检索、工具、裁判和人工容量上的噪声邻居负载测试；
• 自动化失败、提交状态未知、证据存储故障、联系人过期和契约回滚同时出现的事故；
• 影子运行与金丝雀决策不同于当前契约。

运营契约发布记录是最终交接工件，其中包含：

• 契约身份、版本、状态、生效时间、失效时间、负责人、批准人、范围、依赖和回滚目标；
• 每项用户承诺、合格总体、指标实现、目标、错误预算与告警策略，以及缺失数据处理方式；
• 成本计量项、价格版本、预算层级、预留与对账证据、分配策略和合格回退；
• 租户身份，以及容量、缓存、数据、密钥、工具、出站访问、证据、审查和计费各边界的隔离配置；
• 事故严重级别、角色、运行手册、沟通职责、恢复条件、不可变证据位置和未完成的纠正措施；
• 校验、影子运行、金丝雀发布、失败路径、负载、回滚和浏览器可见证据，以及所有生效例外及其失效时间；
• 发布决定、实际行使的决策权限、剩余风险和下次审查日期。

运营报告也必须遵循同一份契约。报告应按已声明服务类别展示 SLO 达标率与燃烧率、每个已接受任务的成本、预留误差、延迟成本或未归属成本、事故时钟、重复发生的故障机制、纠正措施核验、隔离测试结果、噪声邻居影响、发布状态和例外持续时间。报告还要保护低流量租户的隐私，不能把测量覆盖率不足的切片呈现成精确比较。

基础设施是一项持续维护的承诺

运营契约并不能保证系统可靠、成本可控、安全或公平。它能把这些主张写得具体到可以测试，也把目标冲突写得具体到可以作出决定。即使决定最终被证明错误，系统也会留下记录。

这正是 AI 组件集合走向基础设施的最后一步。系统拥有已声明的服务、明确的测量总体、有边界的权限、责任清晰的成本、租户专属的隔离措施、受控的事故响应，以及把每项承诺连接到运行系统的发布记录。随着用户、模型、价格、策略和风险变化，契约也会改变。运营系统意味着通过发布契约时使用的同一套可见、可测试的流程来完成这些变更。

延伸阅读