第12章 生产运营与治理控制

大模型系统的可靠性不只是接口可用。模型可能返回格式正确但事实错误的答案，工具可能重复执行副作用，推理服务可能在长上下文下耗尽 KV，训练任务可能在 checkpoint 损坏后无法恢复，数据和 prompt 可能泄露，模型升级可能让成本、偏差和安全风险同时变化。因此，大模型 Infra 的最后一层需要把系统可靠性、模型质量、数据治理、供应链安全、成本、发布和灾备放进同一套可审计的控制闭环。

SRE 的 SLO、错误预算和事故方法提供了服务可靠性基础 [1][2]；Dapper、OpenTelemetry 和 Prometheus 提供了跨服务追踪、指标和日志的观测基础 [3][4][5]；NIST AI RMF、ISO/IEC 42001、模型卡片、数据集说明书、SLSA 和 Sigstore 则把风险、责任和制品完整性扩展到 AI 生命周期 [6][7][8][9][10][11]。本章关注如何把这些原则具体化为 LLM 平台的指标、状态、策略、门禁和操作。

本章的组织方式是“风险—控制—证据—责任人”。可靠性、发布、安全、成本、灾备和审计不应散落在不同文档里，而应能映射到同一张治理矩阵。

12.1 可靠性目标：从服务可用到任务成功

多层 SLO

大模型平台至少有平台层、模型层、任务层和治理层四类目标。平台层关注网关可用、调度成功、实例健康、TTFT、TPOT、队列和恢复；模型层关注格式、引用、拒答、工具参数和能力回归；任务层关注用户目标成功、人工接管、重试和外部状态；治理层关注数据权限、审计、供应链和安全事件。

只看 HTTP 200 会把流式中断、JSON 非法、工具失败和部分输出当作成功。每个请求和 Run 定义 outcome，响应状态与业务状态分离。任务成功率按 workflow、模型、版本、租户和风险分层，不能用所有请求的平均覆盖重要少数场景。

SLI 设计

SLI 是可测量的服务行为，例如成功完成的请求/有效请求、满足 TTFT SLO 的请求/请求、工具状态正确的操作/操作、有效 checkpoint/保存尝试、恢复成功的故障/故障。分母定义尤其重要：客户端取消、模型拒答、策略阻断、上游错误和平台错误是否进入分母，按场景明确。

指标包含时间窗口、版本、region、tenant、model、workflow、length bucket 和 outcome。高维字段不一定全部放 Prometheus label，可在 trace 和离线仓库聚合。SLI 定义版本化，指标语义改变时创建新版本，避免趋势图跨定义比较。

错误预算

错误预算把可靠性要求转换为变化速度。预算消耗包括平台错误、任务失败、工具副作用、质量回退、安全事件、数据泄露和恢复超时。预算耗尽可以暂停灰度、冻结非必要变更、降低实验并发、增加人工或切换稳定版本。SRE Workbook 的错误预算方法适合连接发布与可靠性 [1]。

模型质量回退不能被平台 99.99% 可用性掩盖；一次数据泄露也不应被平均成功率稀释。治理事件使用独立的硬门禁，服务错误预算用于自动化决策，业务质量预算由 owner 审批。每类预算有发现、确认、修复和关闭流程。

可靠性不是单一百分比

“服务可用率 99.9%”无法回答模型是否正确、工具是否安全、任务是否完成。大模型平台把可用性拆成控制面可用、执行面可用、模型可加载、请求可接受、输出可消费、任务可完成和数据可审计。每一层有不同分母和响应，平台报告同时展示，避免高层成功掩盖下层失败。

例如网关返回成功但流式只发送了首 token，执行面可用但任务未完成；工具返回 200 但业务状态没有变化，调用可用但副作用失败；评估 job 结束但 coverage 只有一半，任务完成但证据不可信。SLO 定义必须绑定 outcome，而不是只绑定 HTTP 状态。The Twelve-Factor App 关于配置、日志和进程隔离的原则可作为服务边界基础，但 LLM 平台还需增加 token、质量和数据责任 [12]。

错误预算的分配

全局错误预算按产品、模型、租户、区域和 workflow 分配。核心交易、告警处理和高风险自动化拥有更严格预算；实验和低风险摘要可以使用较宽预算。子系统预算不能简单相加，因为一次模型错误可能同时造成任务失败、工具重试和成本上涨。平台以 parent task 归因并定义最大总消耗。

预算消耗有严重级别和恢复动作。质量轻微下降触发加大评估，延迟增长触发容量或降级，重复副作用触发立即停止，数据泄露触发隔离、撤回凭证和合规响应。预算恢复需要新的证据或时间窗口，不能人工把数字重置成零而不保留原因。

SLO 的统计陷阱

平均延迟、平均成功率和总错误数量会掩盖长尾与少数租户。平台使用分位数、窗口、分层和最小样本；对于流式和 Agent，定义部分完成、取消、用户中断和人工接管的计量。指标改变定义时保留版本，图表显示数据质量和覆盖率。SRE 方法要求 SLO 可测量、可行动，而不是漂亮的目标 [1][2]。

任务成功也有观察滞后：用户可能数小时后才确认，工具外部状态可能最终一致，投诉可能几天后出现。短窗口服务指标与长窗口业务质量并列，长期问题通过反馈和评估闭环处理。不能因为当前窗口没有投诉就宣布高风险模型可靠。

可靠性与质量的联合门禁

发布门禁不是两个独立的清单。质量退化可能导致更多重试、人工和 token；延迟变差可能让用户重复提交；安全拦截升高可能表示攻击增加，也可能表示模型过度拒答。报告把质量、SLO、成本、安全和人工放在同一版本和时间窗口，解释相互影响。

门禁采用硬约束加软分析。数据泄露、越权、重复副作用、关键任务失败和 artifact 未签名直接阻断；普通任务小幅变化进入人工判断；性能和成本变化结合业务价值审批。门禁规则版本化，旧报告不因规则改变而被重写，新规则可以对历史 evidence 做离线重算。

12.2 可观测性：信号、质量与告警

三类信号

Metrics 适合时间序列和聚合，logs 记录具体错误与上下文，traces 连接一次请求或任务的因果链。OpenTelemetry 提供跨组件的语义与传播，Prometheus 提供指标采集、查询和告警，Dapper 展示大规模分布式追踪的价值 [3][4][5]。LLM 平台还要增加 token、模型、模板、cache、工具、质量和成本字段。

Trace root 可以是 request、task 或 training run；span 包含 gateway、queue、tokenizer、prefill、decode、retrieval、model、tool、approval、database、cost 和 evaluator。字段包含 hash、version、input/output token、TTFT、TPOT、error、retry、tenant、budget、deadline、quality result 和 policy。默认不记录完整敏感内容，使用摘要、hash、脱敏和受控采样。

质量观测

线上质量信号包括任务成功、重试、编辑、用户评分、转人工、引用点击、工具成功、结构化合法、拒答、安全拦截和投诉。质量与延迟、成本、上下文长度、路由、模型版本和数据 snapshot 联合分析。单独看点赞率或 token 长度会受到反馈选择偏差和策略改变影响。

质量监控按场景分层，设置最小样本与置信区间。高风险任务全量或高比例采样，普通任务分层抽样；失败与不确定结果优先保留。反馈样本脱敏后进入评估平台，生产观测和离线回归通过 request id、model hash 和 dataset id 关联。

告警与诊断

告警分为症状和原因：症状包括成功率下降、p99 上升、任务失败、成本突增；原因包括 KV 水位、队列、模型加载、对象存储、网络、工具、数据 drift、policy 和供应链。告警必须有 owner、runbook、严重级别、抑制与恢复条件，避免只把所有错误发给值班人员。

诊断页面按一个请求或 Run 显示状态时间线、资源、版本、路由、错误、重试、工具和质量。事故中先冻结相关发布和保留 trace，再做降级、隔离和回滚。观测数据本身要有留存、权限、脱敏和成本控制，不能为了排查故障无限保存 prompt。

观测数据的生命周期

metrics 可以长期保留聚合，logs 按错误和审计保留，trace 高价值失败与抽样成功保留，prompt/output 按数据等级短期保留，audit 事件按合规保留。不同数据拥有不同访问角色、加密、区域和删除流程。观测系统的成本和隐私必须进入平台预算，不能默认全量记录。

改变采样比例或字段会影响趋势。每个 dashboard 标记观测版本、采样率、覆盖率和缺失字段；事故发生后临时提升采样有开始与结束时间。OpenTelemetry 的统一字段有利于关联，但不能让所有业务把任意高基数内容塞进 trace [4]。Prometheus label 设计尤其避免 token、prompt、用户自由字符串和完整 URL [5]。

告警疲劳

告警按用户影响和行动区分：page 需要立即处理，ticket 可以工作时间处理，dashboard 只用于趋势。一个告警必须有 runbook、owner、抑制、恢复和升级；重复告警合并到 incident。质量漂移和成本异常可以由每日评估或预算系统处理，不应把所有分布变化变成夜间 page。

告警内容不包含敏感 prompt 和秘密。它包含模型、版本、区域、tenant group、错误类别、影响比例、SLO 和 trace link。告警确认、转交和关闭都是审计事件，事故复盘检查告警是否及时、准确、可行动。

观测与评估的回路

线上 trace 抽样到数据与评估平台，评估结果回写模型、workflow、tool 和 release evidence；发布门禁读取质量与安全趋势，运行时根据 policy 选择模型、工具和人工。回路中的每个转换都保存 sample hash、版本、权限和采样策略。没有这个回路，平台只能看到服务可用，却无法发现输出质量逐渐变差。

反馈有偏、缺失和延迟，平台报告 coverage、标签来源和不确定性。人工确认的安全事件进入高优先级回归，普通低评分按分层进入候选。线上与离线版本不一致时，先冻结比较再定位数据、模板、路由或 evaluator 变化。

质量异常检测

质量异常包括输出长度、格式合法、拒答、引用、工具计划、事实性、用户反馈、人工接管和任务 outcome 的分布改变。没有标签时使用代理信号并标记不确定；高风险类别保留人工抽样。检测基线按版本、任务、语言、长度和用户层级建立，避免全局平均稀释异常。

异常确认后，冻结受影响版本、扩大回归、回放失败、比较 baseline、检查数据和路由，决定修复、回滚或接受。接受变化需要 owner、理由、有效期和新基线。模型卡、评估报告和风险登记同步更新，不能只关闭一个告警。

可靠性指标的长期趋势

季度趋势不只看可用率，还看事故数量与严重度、MTTD、MTTR、恢复丢失、回滚时间、质量回退、人工接管、成本/成功任务、安全事件、评估覆盖、供应链风险和灾备演练通过率。指标按组织、模型、workflow 和故障域观察，识别结构性问题。一次短期低错误不能掩盖恢复能力下降。

趋势报告列出目标、当前、变化、解释、行动和 owner。若改善来自减少观测或缩小分母，报告标记 measurement change；若质量提升来自更多人工，计入人工成本；若成本下降来自关闭备份，计入 RPO 风险。长期治理要求诚实解释，而不是指标漂亮。

12.3 发布、变更与供应链治理

Artifact 与供应链

模型、tokenizer、template、engine、adapter、工具、workflow、policy、数据 snapshot 和评估报告都是制品。每个制品记录来源、构建、依赖、hash、签名、许可证、owner、数据等级和兼容矩阵。本章采用SLSA v1.0的来源与构建完整性框架，不声称它是当前最新版本；它提供供应链参考，Sigstore 通过签名和透明日志帮助验证制品 [10][11]；OpenSSF Scorecard 可用于检查开源依赖风险 [13]。

构建在隔离环境执行，依赖锁定并生成 SBOM；运行时只拉取允许的 hash；部署前校验签名、漏洞、模型评估和权限。第三方模型或 MCP server 不能因为公开可下载就自动进入生产。升级依赖、CUDA、driver、kernel 或工具都触发兼容、性能、安全和回滚测试。

变更分类

变更按风险分为配置、prompt/template、模型、推理 engine、数据、workflow、工具、policy、基础设施和安全。配置变更可能影响容量，prompt 变更可能影响工具和隐私，数据变更可能影响质量与授权，工具变更可能产生副作用。变更单说明背景、获得、牺牲、风险、指标、门禁、灰度和回滚。

灰度与回滚

灰度按租户、区域、任务、流量、模型版本或 workflow 分组。影子不执行副作用，canary 受限执行，正式流量满足 SLO、质量、成本和安全。回滚恢复模型、tokenizer、template、engine、adapter、workflow、policy、route 和 cache 兼容版本；新状态无法被旧版本理解时，先 drain 或迁移。

回滚演练验证正在执行的请求、长 Run、审批、工具 operation、计费、memory 和 trace。发布控制器保存 baseline、candidate、evidence、审批和操作人。自动暂停条件明确，人工 override 需要理由与期限。没有可执行回滚的变更不能进入生产。

供应链的信任链

从源代码到模型服务建立 provenance：源代码 commit、依赖、构建器、基础镜像、模型来源、数据 snapshot、转换器、engine、签名和部署。SLSA 定义构建来源和保证等级，Sigstore 提供签名与验证，Scorecard 检查公开依赖的维护和安全信号 [10][11][13]。平台按已批准的信任根与身份约束验证签名，拒绝无来源、hash不匹配或签名无效的artifact。签名证明来源与完整性，不证明模型质量、授权数据或无后门；Scorecard分数也是风险信号，不能当安全背书。

模型供应链还包括数据和 prompt，不只是软件。训练数据下载、清洗脚本、量化校准、评估器、MCP server 和工具 schema 都可能改变行为。平台可按制品类型生成SBOM、数据表和模型卡，发布报告引用它们。发现漏洞时按依赖图找到运行中的模型、engine、workflow 和租户，快速隔离与替换。

版本与配置治理

配置分为代码、静态 manifest、动态策略和运行时临时状态。代码通过构建发布，manifest 不可变，动态策略有版本与审批，临时状态通过事件与 TTL。关键配置要有可追溯的版本和生效记录；受控环境变量可以承载部署配置，但不应成为未登记、不可重现的隐式开关。The Twelve-Factor App提倡配置与代码分离、日志作为事件流 [12]。

配置变更触发 diff、兼容、容量、质量和安全检查。灰度先使用少量租户或影子，失败自动暂停；回滚恢复完整配置集合而非单个值。配置读取写入 trace 的有效版本，事故复盘可以重建真正生效的行为。

供应链应急

发现依赖漏洞、恶意镜像、模型后门、泄露 token 或签名问题时，平台执行供应链 incident：定位受影响 artifact 与运行实例，停止下载和发布，隔离实例，轮换凭证，保存证据，生成可信替代品并灰度。SBOM 与 provenance 让影响范围可计算；没有来源的旧制品可能需要完全下线。

模型供应链风险还包括训练数据投毒、评估器偏置、恶意 tool description 和被篡改的 prompt template。数据 manifest、模型卡、工具注册和评估报告互相引用，发现一个来源问题可以查找所有消费者。供应链响应完成后运行安全、质量、性能和回滚门禁，不因紧急修复跳过验证。

事故中的发布冻结

当发生高等级事故时，发布系统进入 freeze 状态：禁止新的模型、工具、workflow、数据和基础设施变更，保留必要的安全修复和容量扩容，但每项例外都有审批。冻结范围按 blast radius 定义，可以是单模型、单租户、单区域或全局。发布冻结与流量降级、凭证轮换、回滚和数据保全共同执行。

冻结期间仍然需要处理正常的配置过期、证书轮换和节点维护。运行手册列出允许动作、风险和兼容验证，避免把安全运维完全停死。事故结束后先恢复观测与回归，再小比例解除冻结；错误预算恢复与根因修复是不同条件，不能只等流量下降。

变更影响分析

变更影响分析沿 artifact graph 和 runtime graph 做。模型 hash 变化影响 tokenizer、engine、cache、路由、评估、成本和工具；数据 snapshot 变化影响训练、评估、模型卡和发布；工具 schema 变化影响 workflow、prompt、权限、补偿和回放；policy 变化影响所有调用与审计。平台生成受影响消费者和需要重跑的门禁列表。

影响分析有静态与动态两层。静态层读取 manifest、依赖和血缘，动态层用 shadow/replay、固定回归和容量测试验证。若无法解析依赖，默认按高风险处理而不是假设没有影响。图中节点与边有 owner，边记录兼容版本和失效条件，变更完成后更新。

发布前检查

发布前自动生成检查表：artifact hash 和签名、SBOM、模型卡、数据说明、兼容矩阵、质量门禁、SLO 基线、容量、故障演练、权限、审计、trace、成本、回滚、灾备和 owner。缺失项阻断或需要显式风险接受。发布后检查灰度窗口、错误预算、质量、成本和用户反馈。

发布控制器把检查结果写到 release evidence，不依赖聊天或邮件。审批人看到的是差异与风险，不是一个模糊的“测试通过”。回滚路径在发布前使用相同版本和权限演练，防止事故中发现旧制品已删除或不兼容。

执行状态与运营状态的接口

Kubernetes的Pod生命周期提供执行层状态，不能代表业务任务成功 [14]。Run、Step、Operation的迁移、UNKNOWN核验、fencing和恢复算法统一引用第11章；本章治理记录只关联权威状态版本、owner、处置期限与证据，不再另定义一套Runtime状态机。发布可暂停、修复可认领、灾备需验证，均应通过受控接口并留下审计，不能因operator页面显示绿色就覆盖业务事实。

12.4 事故响应、人工修复与责任升级

事故分级

事故按用户影响、数据风险、业务副作用、区域范围、持续时间和恢复难度分级。数据泄露、重复副作用和模型大面积错误通常高于单区域 p99 回退。事故 commander 负责决策与沟通，technical lead 处理隔离和恢复，scribe 保留时间线，业务与安全 owner 负责影响判断。

第一步是止损：冻结高风险发布、限流、摘除故障副本、停止工具、关闭跨租户 cache 或切换安全 fallback；第二步保留证据；第三步恢复有限服务；第四步核对数据和业务状态；第五步复盘与修复。不要在事故中随意删除日志、重试未知副作用或修改历史状态。

Runbook 与演练

Runbook 包含症状、查询、指标、权限、判断、动作、风险和回滚。训练故障查 checkpoint 与数据游标，推理故障查 KV 与队列，Agent 故障查 operation 与状态，数据事故查血缘与 snapshot，安全事故查凭证与审计。每条 runbook 由演练验证，不可执行步骤进入 backlog。

复盘与学习

无责复盘描述时间线、触发、检测、决策、影响、恢复、哪些信号缺失、哪些自动化失败和修复 owner。行动项分为代码、数据、配置、观测、容量、文档、流程和培训，带期限与验证。事故样本进入回归集，故障演练加入发布门禁，重复事件触发架构评审。

组织与职责

模型 owner 对能力、限制和评估负责，数据 owner 对来源、授权和质量负责，平台 owner 对资源、可用性和恢复负责，安全 owner 对威胁、策略和响应负责，业务 owner 对任务成功与残余风险负责，发布 approver 对变更承担审批。RACI 记录在系统和文档中，避免事故时无人决定。

职责不是把风险切开。模型变更同时影响容量、质量、安全和成本，发布评审需要多方 evidence；事故 commander 可以停止系统但不替代业务判断；人工接管结果反馈给模型和流程 owner。季度治理评审检查风险登记、指标、事故、成本、数据和供应链。

事故中的状态保护

事故处理第一原则是保留事实。冻结相关 Run、snapshot、artifact、trace、配置、状态、凭证和事件；禁止未经受控修复流程直接改业务状态、覆盖制品或清理会丢失必要证据的现场。对未知外部副作用查询 operation；对可能泄露的数据隔离访问并轮换凭证；对错误模型停止新流量但保留回滚所需的制品。

状态保护需要只读快照、fencing token 和操作审计。一个旧 worker 恢复后不能覆盖新状态；一个过期 operator command 不能执行；一个故障区域不能与恢复区域同时写同一业务状态。控制面在每个危险动作前检查 generation、lease、policy 和 approval。

事故沟通

内部沟通说明影响范围、开始时间、当前状态、临时措施、下一次更新、数据风险和用户动作；对外沟通只披露确认事实和可执行建议，不泄露敏感样本与内部策略。事件时间线统一使用 UTC 或明确时区，所有操作带 operator、trace 和版本。事故 commander 避免多个团队同时执行互相冲突的回滚。

复盘中区分触发条件与根本原因，记录检测为什么晚、告警为什么无动作、runbook 为什么不可执行、自动恢复为什么失败以及哪些假设不成立。行动项有 owner、期限、验证命令和优先级。重复事故说明修复停留在文档而未进入系统门禁。

可操作性评审

每个新组件上线前做 operability review：健康检查是否能区分依赖与自身，指标是否能定位，日志是否脱敏，trace 是否关联，配置是否可动态或版本化，备份与恢复是否验证，限流与熔断是否存在，runbook 是否可执行，回滚是否完成演练，成本是否归因。不能回答的问题进入上线阻断清单。

可操作性不是运维后补。模型仓库、评估器、MCP server、数据 job 和安全策略一开始就纳入平台标准。组件拥有明确 owner、SLO、依赖、升级、退役和事故联系人。这样平台不会因为增加一个看似小的模型能力而增加不可见的运维负担。

运维人员的最小权限

值班人员需要查看健康、指标、trace 摘要、执行限流、摘除实例和切换安全 fallback，但不应默认读取敏感 prompt、下载模型或执行业务工具。高风险操作双人审批或 break-glass，break-glass 记录原因、时间、范围、自动过期和复盘。平台 API 对 operator 与 tenant 使用不同 audience 和 policy。

权限轮换和离职回收自动化，服务账户短期化，密钥不进入日志和 artifact。审计系统定期检查异常访问、批量导出、跨区域、非工作时间和失败授权。发现异常时冻结账户、保留证据并走安全 incident。

部分失败与用户体验

AI 任务经常出现部分完成：检索成功但生成失败，三项工具完成两项，答案生成但引用缺失，流式输出完成一半，评估覆盖不足。API 返回 partial、failed、needs_attention 或 completed_with_warnings，附带已完成、未完成、可重试和人工动作。隐藏部分失败会让用户重复提交和增加副作用。

部分结果是否可用由 workflow 定义，不能让模型自行宣布成功。业务系统提供 postcondition 和确认接口；Runtime 记录用户是否接受 partial。成本与资源按已执行部分结算，重试只补未完成或明确重算。事故和评估样本保留部分路径，帮助定位是哪个阶段导致失败。

模型与系统的责任分界

模型 owner 不能保证所有业务正确，平台 owner 不能通过平台隐藏模型限制，业务 owner 不能把安全交给 prompt，安全 owner 不能只提供禁止清单。责任边界用接口和证据表达：模型提供能力、限制和质量；平台提供资源、状态、版本、观测与恢复；业务提供 outcome、风险承受和人工；安全提供策略、威胁和响应。

接口契约定义哪些错误由哪一层处理。模型返回格式错误由 Runtime 重试或失败，工具权限由策略拒绝，业务状态冲突由业务查询，平台节点故障由调度恢复，数据授权由数据 owner。责任不清会导致无限重试和事故互相推诿。

从死信到关闭：operator修复流程

第11章定义Operation、UNKNOWN、lease/epoch和repair接口，本章只规定谁在何时凭什么证据操作。一个心跳正常但无进展的Run，或反复失败的毒消息，不应仅靠重启或全量重放处理。修复工单引用原task/run/step/operation、manifest、最后进展、错误类型、已确认与未知业务事实、待处理风险和受控证据链接；页面默认不复制prompt、客户载荷或凭据。

例如退款已提交而响应丢失，先按原操作ID核对；查到退款成功则补记Step，不能新建退款键重发；查不到但下游仍可能在执行时保持NEEDS_RECONCILIATION。手工在数据库把status改ready会绕开原操作及owner检查，因此修复入口必须调用第11章同一状态转换接口。补偿也失败时保留主事实与补偿attempt，用户看到待处理事项，不能把“工单已创建”算业务风险关闭。

每种修复等级预先指定认领时限、核验期限与升级对象，均为组织配置而非本章通用分钟数。无人认领先转值班备份，超过核验期限转工具/业务owner，再按影响升级incident commander与治理负责人；交接须明确接收人确认，原owner不能仅因发送通知就消失。SRE事故管理强调清晰角色和交接 [2]，这里将其落实为repair的owner、next_action_at、deadline、escalation_level与handoff_ack字段。期限到达只触发升级或限制新增动作，不把UNKNOWN自动改失败。

修复结束保存外部查询时间、返回版本、已确认事实、执行代次、批准与动作事件、剩余风险及复审时间。独立检查任务终态、操作事实、通知交付和用户确认四件事；若只有技术队列清空而退款仍未知，工单不得以“平台恢复”关闭。演练覆盖操作者交班、审批过期、重复点击、自动接管竞争和批量恢复冲击，实际验收结果另存证据包，本章表格不代表已运行演练。

12.5 安全、数据最小化与AI风险治理

风险登记

AI 风险登记表包含系统用途、用户、模型、数据、工具、威胁、失败影响、控制、残余风险、owner 和复审时间。NIST AI RMF 的 govern、map、measure、manage 结构可作为生命周期框架 [6]；生成式 AI profile 进一步关注幻觉、数据、滥用、供应链和内容风险 [15]；ISO/IEC 42001:2023的公开摘要界定AI管理体系，ISO/IEC 23894:2023摘要界定AI风险管理指导 [7][16]。这里未逐条解读付费标准，也不声称完成合规审计或认证。NIST材料在此按已发布的1.0与2024 Profile使用，其概览说明框架为自愿采用并处于修订进程，不将未发布版本写成既成规范。

风险不能只写“模型可能出错”。明确危害场景、触发条件、暴露范围、检测信号、阻断与补偿。例如模型生成错误退款动作、工具越权读取、训练数据泄露、提示注入、输出偏见、服务成本失控和区域合规违规。每个高风险场景至少有预防、检测、响应和复盘。

权限与审计

权限分为调用模型、读取数据、执行工具、写外部状态、查看 trace、下载 artifact、审批发布和修改 policy。采用最小权限、短期凭证、租户和区域限制、目标 allowlist。审计记录主体、资源、动作、理由、策略版本、结果、trace、时间和来源；不能由应用日志临时拼接。

审计本身不可被普通租户修改，保留期、访问者和导出要有策略。数据删除与合规请求沿数据血缘、缓存、trace、评估和 artifact 处理；历史指标保留摘要并标记内容已撤回。中文《生成式人工智能服务管理暂行办法》第十一条规定输入与使用记录保护、非必要个人信息收集限制及个人信息请求处理 [17]；适用范围按第二条和实际服务场景核对，不以本章清单代替适用性判断。

LLM 应用安全

提示注入、敏感信息泄露、不安全工具、供应链、过度代理、输出处理、拒绝服务和模型窃取等风险需要进入测试。OWASP LLM Top 10 和 MITRE ATLAS 提供威胁分类与攻击知识库 [18][19]。防御不是只加系统 prompt，而是权限、沙箱、schema、输出过滤、网络、速率、审计、人工和回滚的组合。

安全策略不能被模型修改。工具结果、检索文档和用户文件标记为不可信；模型输出先做 schema 和 policy，再执行副作用；安全服务不可用时 fail closed 或进入人工。红队样本、失败 trace 和安全回归集受控保存，修复后验证正常任务没有被过度拒答。

模型卡与数据集说明

Model Cards 记录模型用途、限制、评估、数据、风险和适用场景 [8]；Datasheets for Datasets 强调数据来源、组成、收集、推荐用途和限制 [9]。平台将这些文档与 model artifact、dataset snapshot 和 release evidence 关联，变更时重新生成或复审。文档不是营销材料，而是让调用方知道不能做什么。

模型风险的持续监控

模型卡中的限制不是上线时检查一次。生产监控关注输入分布、输出事实性、拒答、偏差、敏感内容、工具错误、人工投诉和新攻击。新场景、语言、地区和用户群进入风险评估；模型或数据变化触发重新测量。Model Cards 和 Datasheets 将模型与数据的限制、来源、用途和责任显式化 [8][9]。

风险监控需要定义红线和响应：达到红线自动停止流量、隔离模型、关闭工具或转人工；接近阈值扩大采样和人工；正常波动只记录。风险指标分层避免平均数掩盖少数群体。中文政策原文可用于核对服务输入保护与请求处理职责，具体控制仍需落在权限、留存、删除和审计流程 [17]。

数据治理的责任矩阵

数据 owner 负责来源和用途，steward 负责 schema 与质量，security 负责敏感等级与访问，legal/compliance 负责授权和保留，model owner 负责使用影响，platform 负责执行控制。责任矩阵写入数据 catalog 和 snapshot manifest；没有 owner 的数据不能进入生产训练或评估。

数据说明书记录收集方式、代表性、缺失、偏差、推荐用途、不适用用途和已知问题。模型卡记录能力、限制、评估和风险。文档变化触发使用者通知和重新门禁，不能把旧卡片继续附在新模型上。本章中文来源是政策原文，不再用机构主页代替未核验白皮书；本地职责与适用范围按实际场景落实 [17]。

安全策略的失败模式

安全系统可能误拦截、漏拦截、超时、版本不一致或返回不确定。策略引擎不可用时，对高风险动作 fail closed；对低风险只读动作可以有限降级，但事件标记为 policy_unavailable。输入安全、输出安全、工具权限和数据访问使用一致的 policy version，避免各层使用不同答案。

策略误拦截需要人工复核和样本回流，漏拦截需要立即隔离、查找影响、撤销凭证和扩大红队。安全指标按语言、任务、租户和模型分层，避免平均数掩盖少数场景。OWASP 与 MITRE 提供风险分类，但组织需要把具体资产、攻击面和响应动作写进 runbook [18][19]。

安全事件的证据保全

安全事件发生时，保留请求 hash、模型、policy、工具、凭证标识、权限决定、网络、artifact、trace、时间线和影响范围；对敏感正文采取受控快照和加密。隔离受影响租户、撤销 token、停止工具和切断 egress，防止继续扩散。证据访问最小化并记录，避免调查过程二次泄露。

事件分类包括 prompt injection、敏感数据输出、越权工具、供应链、模型窃取、拒绝服务和数据投毒。每类有检测、遏制、清除、恢复、通知和复盘。攻击样本经过脱敏和审批后进入红队与回归；修复后检查攻击路径、正常任务和跨模型迁移。

治理控制的自动化

自动化控制包括制品签名校验、数据授权检查、schema、兼容矩阵、漏洞、质量门禁、权限、限流、成本、备份、漂移、删除和回滚。控制结果是机器可读的 pass、fail、waived 或 unknown；waiver 有 owner、理由、期限和补偿；unknown 默认按风险等级处理。手工审批只处理不可自动判断部分。

控制器自身也要有版本、权限、观测和回滚。错误的 policy 可能阻断所有服务或放行危险动作，更新前用历史回放和 sandbox 验证。策略发布按区域、租户和风险灰度，紧急禁用高风险工具的路径独立于普通发布。

第三方审查与内部复核

高风险系统可由安全、隐私、业务和平台联合复核，必要时引入外部审查。审查输入为机器可读 evidence bundle，输出为发现、风险等级、修复、接受或期限。内部复核检查控制是否真的执行，而不只是文档存在；通过抽样生产事件、权限和发布记录验证。

审查发现应进入 issue 与发布门禁，修复后重新生成证据。审查文件包含版本与范围，不能用上一版本结果覆盖当前系统。重大模型、工具、数据或地区变化重新触发审查，而不是等年度周期。

数据最小化沿整条链路实施

先枚举任务必需字段，再决定模型输入；业务密钥、完整账户资料和无需公开的核心脚本留在受控服务，模型只接收必要结果。假名化映射与原文分开授权，电话号码遮盖但姓名地址完整仍可能识别主体；hash也可能被关联或枚举，不能自动视为匿名信息。资源读取、模型上下文、工具返回、日志、记忆、评估和网络出口分别设策略，不用“已脱敏”一个标签覆盖全链路。

Skill/工具声明只描述获准能力，不能存业务凭据；模型执行进程也不应获得不必要密钥。若任务确需代码或脚本内容，按已授权范围提供，而不是把隐藏prompt当唯一保护。供应商的训练使用、驻留、保留与删除能力逐项核对实际配置及约定，不因产品叫企业版就假定不训练或零留存。

12.6 成本、容量与资源治理

成本账本

成本包括 GPU、CPU、内存、网络、存储、模型下载、token、KV、cache、工具、评估、人工和失败重试。训练按有效 token、GPU 小时和重算归因；推理按输入输出 token、GPU 毫秒、成功任务和 cache；Agent 按 Run、Step、Tool、人工和副作用。每条费用事件带 tenant、project、model、version、task 和 idempotency。

成本报告区分预约、实际、等待、通信、空闲、失败、重试和有效工作。GPU 利用率高但有效任务少，仍可能成本高；便宜模型输出更长或失败更多，单位成功成本不一定低。成本预算与错误预算、质量门禁并列，超限触发暂停、限流、降级或审批。

容量计划

容量模型按 workload、长度、并发、模型、GPU、区域、故障余量、发布余量和长尾建立。训练关心有效 token/s 和扩展效率，推理关心 goodput、TTFT、TPOT、KV，Agent 关心 active Run、tool QPS、状态、人工与模型调用。容量 dashboard 显示 planned、reserved、active、pending、failed、draining 和 spare。

容量计划每次模型、模板、数据、流量、硬件或工具改变都重算。SRE 错误预算与容量余量一起保护发布和故障；Borg 的优先级、配额和隔离为多租户资源治理提供经验 [20]。不能把正常峰值填满后再假设可以完成滚动发布和节点故障转移。

成本优化的取舍

量化、batch、cache、低优先级资源、模型路由、上下文压缩、预计算和异步化都可能降本，但改变质量、延迟、内存或数据风险。每个优化有基线、假设、获得、牺牲、指标、回滚和重新评估条件。一次只改变少数变量，用固定 workload 比较质量、SLO、成本和错误预算。

可靠性预算与容量预算

错误预算耗尽时暂停高风险变更，容量预算不足时限制流量和长任务，安全预算被突破时关闭相关工具或区域，质量预算退化时回滚模型。不同预算可能互相冲突，平台指定优先级：安全和数据责任高于成本，关键业务质量高于平均吞吐，可靠性保护优先于实验速度。

容量预算包括正常峰值、节点故障、发布双份、灾备切换、评估和突发；不可把全部 GPU、状态库连接、对象存储 QPS 和人工容量都分配给常态业务。Borg 的资源配额、优先级和故障域经验说明，预留和抢占需要控制面统一治理 [20]。

成本透明与治理

治理控制也有成本：全量 trace、judge、人工审核、备份、红队和灾备会消耗资源。平台把控制成本显式归因，不以取消安全和可靠性换取表面低价。低风险任务可以使用较低采样和自动化，高风险任务使用更强证据、人工和保留；分层策略比所有任务一刀切更可持续。

成本透明让业务能做知情取舍。若减少评估样本可省钱但扩大未检测风险，决策由 owner 接受并设置有效期；若增加 cache 降低 GPU 却延长敏感数据保留，需安全审核；若跨区域备份缩短RTO却不被驻留策略允许，应改用许可范围内的冷备或重算。每项牺牲写在 ADR 与治理报告中。

成本治理与组织行为

成本面板公开模型、租户、项目、workflow、数据处理、评估和人工成本，提供预算、趋势、异常和单位成功任务成本。公开透明不等于惩罚排名，研究实验和生产任务使用不同解释。平台允许团队设置预算、预警和自动暂停，避免月底才发现资源耗尽。

成本优化有潜在反模式：为了省 token 让模型少验证，为了提高 GPU 利用率混入长任务，为了省日志关闭 trace，为了省备份降低 RPO。治理评审把这些牺牲写明，业务 owner 接受风险并设重新评估日期。好的成本管理提高单位价值，而不是简单砍掉控制。

成本异常检测

成本监控检测模型 token 突增、输出长度变化、重试风暴、cache 命中下降、judge 队列、工具调用爆发、GPU 空闲、对象存储请求和跨区域流量。异常按 tenant、model、workflow、版本和 region 分层。自动动作包括限流、降低优先级、暂停实验、切换模型、关闭可选分支和通知 owner；高风险动作需要人工。

成本异常可能是攻击、业务流量、模型行为、模板循环或计量 bug。排查使用 trace、事件、配置 diff、数据分布和发布记录，不要立即把配额调高。费用事件与供应商账单定期对账，发现计量重复或漏记时生成修订事件，不覆盖原始记录。

12.7 故障演练、业务连续性与灾备

故障域

故障域包括请求、实例、GPU、节点、网络、区域、存储、调度器、模型仓库、数据仓库、工具和人工队列。每个故障定义检测、隔离、重试、降级、回滚、补偿、恢复时间和数据损失。单节点故障不应让所有副本同时失效；单租户的工具风暴不应拖垮全局。

故障分类区分瞬时、确定性、未知状态和不可逆。只读或契约允许的瞬时网络错误可有界退避，写操作超时先核验，schema 错误需要修复输入，工具提交后连接断开需要查询，支付或删除等动作需要人工。AIP-194的自动重试适用条件与错误分类可作为接口参考 [21]。

混沌演练

混沌实验覆盖杀死 worker、GPU reset、节点断电、网络延迟、丢包、DNS 失败、对象存储不可用、模型下载损坏、KV OOM、事件重复、状态库只读、工具超时和区域切换。Chaos Mesh的NetworkChaos官方文档给出网络延迟等注入机制 [22]，其余场景是本书待实施的实验设计；Jepsen的资料区分一致性模型 [23]；本书据此要求明确历史检查所用模型，再为分区与时序设计实验。

每次实验有假设、范围、注入、预期、停止条件、指标、影响、恢复和复盘。先在隔离池与影子流量执行，再逐步扩大。实验结果进入发布门禁和 runbook；若系统只能靠人工 SSH 清理，说明自动恢复边界不足。

恢复点与灾备

训练恢复依赖 checkpoint、数据游标、optimizer 和并行布局；推理恢复通常重建 KV；Agent 恢复依赖 workflow state、operation status、approval 和 compensation；数据与评估恢复依赖 snapshot、manifest、结果和报告。不同状态拥有不同 RPO/RTO，不能用一套备份策略覆盖。

灾备方案分为同节点、同区域跨故障域、跨区域和离线冷备。权重和模型制品可多区域复制，敏感数据可能只能保存加密指针和受控副本；trace 可采样保留，审计事件高等级保留。恢复演练验证 hash、权限、schema、版本、依赖和成本，而不只是服务能否启动。

RPO、RTO 与降级

训练 RPO 是可丢失的 step/token，RTO 是恢复到可继续训练的时间；推理 RPO 通常是正在执行请求和 KV，RTO 是恢复健康副本；Agent RPO 是事件、审批、operation 和状态，RTO 是重新接管；评估 RPO 是结果与报告，RTO 是重新运行或读取证据。每类系统定义自己的目标。

降级按能力层级设计：稳定模型、小模型、异步、缓存回答、只读工具、人工队列和安全拒绝。降级不能突破数据区域、权限、安全和副作用边界。用户看到的状态明确是 degraded、partial、queued 或 needs_attention，避免把降级结果误认为正常完成。

跨区域恢复

跨区域恢复需要复制模型制品、配置、注册表、状态、事件、数据 snapshot、评估报告和密钥引用，但不是所有内容都能跨区域。数据驻留和删除策略优先；敏感 payload 可以不复制，Run 恢复时转人工。路由保存 region、policy 和 fallback，区域切换后重新校验模型和工具兼容。

恢复演练

季度演练区域不可用、对象存储延迟、模型仓库损坏、状态库恢复、凭证轮换、网络分区和工具供应商故障。测量 RTO、RPO、数据完整、权限、trace、成本、用户影响和人工工作量。演练结束保留证据并更新 runbook；“备份成功”不等于“可以恢复”。

灾备状态分类

灾备清单将状态分为可重建、可复制、不可复制和需人工。模型 engine 可从权重重建，KV 通常可重建，训练 checkpoint 需要复制，Agent tool operation 需要查询外部状态，人工审批可能不可复制，敏感 prompt 可能禁止跨区复制。RPO/RTO 与状态类别绑定，灾备演练按类别验收。

灾备切换前验证 artifact 签名、版本、区域、密钥、数据授权、工具 endpoint、路由、容量和观测；切换后验证流量、SLO、成本、审计、任务状态和副作用。区域恢复不能只是 DNS 修改，必须重新做能力与安全检查。故障区域恢复后，防止双活写入造成状态冲突，采用 fencing、单主或明确的合并规则。

混沌与一致性测试的组合

单纯杀 Pod 只能验证重启，复杂系统还要验证消息重复、网络分区、时钟偏差、状态库延迟、外部操作未知和回滚中断。Chaos Mesh 可做资源和网络注入，Jepsen 风格测试关注并发、分区和一致性 [22][23]。Agent Runtime 的副作用测试还需要沙箱、幂等断言和外部状态检查。

混沌实验结果按故障、检测、隔离、恢复、数据损失和用户影响保存。实验期间不能让自动回滚掩盖错误，停止条件保护真实业务。重复演练直到恢复时间、资源释放和审计符合目标，再把场景变为长期回归。

一致性测试

分布式状态测试关注事件重复、乱序、分区、时钟偏差、重试和并发写。Jepsen 风格的测试将操作序列、故障窗口和最终状态记录下来，检查是否出现丢失更新、重复副作用、非法状态或读到未来 [23]。运行时还增加业务不变量，例如一次 operation 最多成功一次、预算不为负、已撤销权限不能执行、终态不可逆。

测试使用模型、工具、消息和状态的可控 fake，真实外部副作用在 sandbox 中验证。发现不变量破坏时保留最小重现历史、事件、版本和资源，加入回归。仅测试单机和 happy path 无法证明跨节点状态正确。

灾备中的安全降级

灾备区域或冷备环境可能没有同样的模型、工具、数据权限和安全服务。切换前生成 capability matrix，按任务选择可用功能；缺少高风险策略时关闭自动副作用；缺少私有数据时返回明确不可用而不是访问公共替代；缺少 judge 时不执行质量门禁或转人工。灾备成功定义包含安全和合规，不只是流量返回 200。

冷备恢复时间较长，用户看到 queued 或 degraded；状态系统保存预计恢复与取消入口。恢复后优先处理已批准且有 deadline 的任务，新任务按容量逐步放量。双区域恢复时使用 fencing 和 epoch，防止旧区域恢复写入造成重复。每个切换动作写审计和 incident timeline。

灾备与成本取舍

更低 RPO/RTO 通常增加复制、备用 GPU、跨区网络、人工演练和存储成本。ADR 明确哪些状态值得复制，哪些可重建，哪些转人工；业务 owner 接受低概率高影响风险。训练 checkpoint 可能按阶段选择频率，推理 KV 多数重建，Agent operation 需要外部查询，评估报告高价值保留。

恢复演练测真实时间和资源，而不是理论配置。若跨区复制不被允许，不能仅以加密作为越界理由；应改用批准区域内备份、分区存储或在许可环境重算；若备用模型质量不足，限定任务或转人工。所有牺牲都有有效期和重新评估条件，避免临时降级变成永久事实。

可靠性评审中的 ADR

每个重要平台选择写 ADR：背景问题、目标、候选、证据、决策、获得能力、主动牺牲、已接受风险、监控、回滚和重新评估条件。比如选择全量 trace 获得诊断与合规，但牺牲成本和隐私；选择跨区复制获得 RTO，但牺牲数据驻留与成本；选择自动重试获得短暂故障恢复，但增加副作用风险。

ADR 的维度保持一致：可用性、延迟、吞吐、质量、成本、安全、隐私、恢复、复杂度、团队负担和供应商锁定。表格比较候选，正文解释因果；指标和实验链接到来源与报告。这样治理不是审批形式，而是让系统取舍长期可见。

可靠性测试的分层

单元测试验证状态迁移、schema、策略、预算、幂等和错误；集成测试验证模型、工具、存储、队列和观测；合同测试验证 API 与事件；回放测试验证历史 Run；压力测试验证容量；混沌测试验证故障；恢复测试验证 RPO/RTO；红队测试验证安全。每层的失败都产生不同门禁，不能用集成测试替代恢复和安全。

测试数据和生产数据隔离，副作用使用 sandbox 或 mock，敏感数据受控。测试结果保存 commit、artifact、配置、环境、原始输出和报告。Flaky 测试不应被简单重试隐藏，标记不稳定并修复；随机测试保存 seed 与最小重现。

12.8 删除、备份、供应商与交付证据

数据保留与删除

定义 prompt、output、trace、memory、tool result、评估样本、模型制品和审计事件的保留期、删除方式、备份影响和法律保留。删除请求沿 lineage 找到缓存、派生 embedding、回放、标注、训练 candidate 和报告；摘要仍含个人信息或可关联标识时也纳入清理；保留例外列明依据、用途限制、owner和复审期限。删除本身产生审计事件但不保留原始敏感内容。

数据备份与删除冲突

备份提高恢复能力，但会延长数据保留和删除复杂度。备份记录数据等级、密钥、区域、保留、恢复 owner 和删除实现；敏感备份设置最小化、加密和到期清理；只有专用密钥及全部副本/密钥副本均受控、可验证失效时，才能评估密钥销毁是否满足不可恢复目标，不能把加密本身当已删除。删除请求要检查在线、缓存、快照、备份、评估、训练候选、trace 和人工导出，给出完成范围与例外。

审计需要证明删除请求被处理，但审计不能再次保存被删除内容。保存主体、时间、对象 hash、策略和结果，不保存原文。历史模型无法简单从训练中“删除记忆”时，风险登记记录限制、补救和重新训练计划，由治理 owner 批准。

供应商与外部 API

外部模型、judge、搜索、支付、短信、邮件和云服务拥有各自的 SLA、数据处理、区域、限流、错误和版本。供应商清单保存用途、数据流、DPA/授权、fallback、成本、联系人和退出方案。敏感数据默认不发送；发送前最小化、脱敏和记录同意。供应商版本变化进入兼容与评估。

外部服务不可用时，Runtime 依据工具 policy 选择重试、缓存、替代、异步或人工。不可逆副作用的供应商确认未知时，查询 operation 而非重试。合同与技术控制共同决定风险，不能只相信服务方“高可用”描述。

灾备与供应商退出

平台不能只设计“供应商一直可用”。模型供应商、GPU 云、对象存储、检索、支付和标注服务都需要退出或切换计划：保存可迁移 artifact、协议、数据格式、评估、权限、成本和替代服务；定期运行导出与恢复。依赖外部专有格式时，生成可读 manifest 和转换器，避免被单一服务锁定。

退出演练不等于立刻迁移全部流量。先在离线数据和影子 Run 验证，比较质量、成本、延迟、安全与合规，再迁移低风险租户，最后处理关键任务。旧服务 drain 后保留查询和审计能力，确保历史 Run 能解释。供应商变化进入风险登记和容量预算。

合规证据的可重复生成

合规报告从机器可读的 manifest、policy decision、audit event、model card、datasheet、评估报告和发布记录生成。手工复制截图容易遗漏版本和时间。报告包含系统用途、数据流、用户、模型、限制、风险控制、监控、事件、删除、供应链和审批。任何结论都有 artifact、trace 或事件引用。

报告生成器版本化，组织规则变化产生新报告，旧报告保留历史语义。外部审计访问受控 view，原始敏感内容不必交付。需要解释一次决策时，可以从 report 反查输入、策略、版本和结果，但不暴露无关租户。

交付证据的长期保留

长期保留的 evidence bundle 包括 model、data、workflow、tool、policy、runtime、hardware、评估、灰度、事故、成本和审批版本。内容按敏感等级和合规期限保存，摘要 hash 与审计保留时间更长。历史报告只读，修订通过新报告引用旧报告，不能覆盖审计事实。

在季度或重大变更时做 evidence review：链接是否有效，签名是否可验证，snapshot 是否可读，指标定义是否改变，风险是否已关闭，回滚是否仍能启动，owner 是否仍存在。长期治理的难点不是写第一份报告，而是保证几年后仍能解释一个旧模型为何被发布和如何被撤回。

端到端演练

选取一个训练 run、一个推理请求、一个 Agent Run 和一个评估任务，验证从输入、资源、状态、trace、成本、质量、权限到结果的完整链路。注入节点故障、存储失败、工具超时、状态重复、模型回滚、数据撤回和区域切换，检查状态不覆盖、副作用不重复、敏感数据不泄露、预算可对账。

变更与发布验收

随机选择模型、engine、prompt、workflow、tool、policy、数据和依赖变更，验证来源池、兼容矩阵、质量门禁、灰度、告警、自动暂停和回滚。发布记录包含变更、获得、牺牲、风险、审批、指标和恢复策略。旧版本可启动、可读取需要的状态、可关闭新 cache，并能处理正在执行的任务。

审计与治理验收

验证租户、角色、凭证、区域、数据等级、工具权限、模型 artifact、评估报告和删除请求。检查审计不可篡改、访问可追踪、日志脱敏、证据可回放、模型卡和数据说明存在、供应链 hash 和签名正确。安全红队、混沌、恢复和成本演练至少按周期重复，不能只在首次上线执行。

一份删除与备份范围记录

删除先让授权查询、召回与缓存命中停止，再可靠传播到派生副本，并记录“逻辑不可见”“在线物理清理”“历史副本待到期”“依法保留”各自状态。S3开启版本时，简单DELETE通常只增加delete marker并把旧内容保留为历史版本，GET返回404并不能证明物理擦除；永久删除需覆盖相应versionId [24]。本书因此要求列出当前对象、历史版本、复制目的地、索引、向量、摘要、缓存、回放、标注导出和供应商副本，而非只删会话表。

这不是实际用户删除记录，所有示例值仅说明字段职责。执行结果不能用单一done掩盖仍在备份保留窗的载荷。对不能逐项删除的不可变备份，记录隔离访问、到期清理计划和例外，恢复时先在隔离环境完成删除清单及当前撤权叠加，再允许业务读取。PostgreSQL18的PITR会从base backup和WAL重建历史时点 [25]；它不会自动理解应用删除请求，因此恢复旧时点可能重新出现旧内容，需要应用层恢复门禁。

索引回滚或离线重建同样读取当前删除清单和实体版本；旧snapshot只能提供候选数据，发布前追平deletion watermark及增量撤权，验证旧记录被墓碑拒绝。删除清单本身也需最小权限与保留策略，尽量使用不可逆受限标识，并防止墓碑到期早于所有旧副本。恢复日志、重放队列和人工导出都属于范围，不能只看数据库当前行。

已经进入训练权重的内容不能通过删除原始样本就证明被遗忘。记录受影响模型、是否需要停止使用、替换/重训或其他可验证补救及责任人；未经验证不宣称完成模型遗忘。对象hash或主体标识仍有识别风险时，审计亦需访问限制与期限；“保存删除证据”不意味着永久保留原文或可恢复的PII映射。

发布、恢复与保留的联合验收

按第10章门禁区分服务成功、任务成功和证据完整，按第11章查询操作事实。回滚模型/索引只能恢复兼容执行组合，当前撤权与删除不能一起回退；旧审批也不能因恢复旧版本自动扩权。不兼容的在途Run暂停并保留checkpoint，迁移必须重验语义、权限与既有副作用。供应商故障时fallback仍受能力与数据策略约束，缺批准区域或删除能力的端点不能临时接收敏感数据。

验收抽样至少覆盖一条UNKNOWN修复、一条补偿失败升级、一条跨班次交接、一条删除旧备份恢复和一次供应商中断；每条保存输入引用、范围、owner、期限、实际动作、外部事实和剩余限制。治理通过表示这些范围有证据，并非所有风险已消失；任何waiver都要绑定能力、理由、有效期和补救，不能通过延期让未知状态永久无人处理。

12.9 本章小结

生产治理把第7–11章的资源、制品、评估、请求和业务状态变成可运营承诺。SLO说明怎样测量，发布记录说明改变什么，operator流程说明谁处理未决事实，删除范围说明哪些数据已清理、哪些仍受限保留。任何服务恢复都要同时核对业务事实、数据权限和剩余责任。

本批书稿交付的是机制、教学推演与验收设计，不把引用存在等同控制已执行。实际平台仍需运行自己的故障演练、恢复和删除测试并保存证据；后续Agent章节复用这里的运营接口，不复制另一套状态恢复算法。

12.10 参考资料

[1] Beyer, B., et al. The Site Reliability Workbook: Implementing SLOs. O’Reilly, 2018. https://sre.google/workbook/implementing-slos/ 核验日期：2026-10-17

[2] Beyer, B., et al. Site Reliability Engineering: Managing Incidents. 2016. https://sre.google/sre-book/managing-incidents/ 核验2026-10-17

[3] Sigelman, B. H., et al. Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Research, 2010. https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ 访问日期：2026-10-17

[4] OpenTelemetry Authors. Signals. 在线文档，核验2026-10-17. https://opentelemetry.io/docs/concepts/signals/

[5] Prometheus Authors. Prometheus Documentation. https://prometheus.io/docs/introduction/overview/ 访问日期：2026-10-17

[6] NIST. AI Risk Management Framework. https://www.nist.gov/itl/ai-risk-management-framework 访问日期：2026-10-17

[7] ISO. ISO/IEC 42001:2023 — AI Management Systems. 官方公开摘要，核验2026-10-17. https://www.iso.org/standard/42001

[8] Mitchell, M., et al. Model Cards for Model Reporting. 2019. https://arxiv.org/abs/1810.03993 核验2026-10-17

[9] Gebru, T., et al. Datasheets for Datasets. CACM, 2021. https://arxiv.org/abs/1803.09010 核验2026-10-17

[10] SLSA. Specification v1.0. https://slsa.dev/spec/v1.0/ 访问日期：2026-10-17

[11] Sigstore. Overview. 官方文档，核验2026-10-17. https://docs.sigstore.dev/about/overview/

[12] Wiggins, A. The Twelve-Factor App. https://12factor.net/ 访问日期：2026-10-17

[13] OpenSSF. Scorecard. https://github.com/ossf/scorecard 访问日期：2026-10-17

[14] Kubernetes. Pod Lifecycle. 官方文档，核验2026-10-17. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

[15] NIST. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1，2024. https://doi.org/10.6028/NIST.AI.600-1 核验2026-10-17

[16] ISO. ISO/IEC 23894. https://www.iso.org/standard/77304.html 访问日期：2026-10-17

[17] 国家互联网信息办公室等. 生成式人工智能服务管理暂行办法. 中文政策原文，2023-07-13. https://www.cac.gov.cn/2023-07/13/c_1690898327029107.htm 核验2026-10-17

[18] OWASP. Top 10 for Large Language Model Applications. 官方项目说明，核验2026-10-17. https://owasp.org/projects/top-10-for-large-language-model-applications

[19] MITRE ATLAS. ATLAS Tactics, Techniques, and Case Studies Data. 官方仓库，核验2026-10-17. https://github.com/mitre-atlas/atlas-data

[20] Verma, A., et al. Large-scale Cluster Management at Google with Borg. EuroSys, 2015. https://research.google/pubs/large-scale-cluster-management-at-google-with-borg/ 访问日期：2026-10-17

[21] Google. AIP-194: Automatic Retry Configuration. https://google.aip.dev/194 核验2026-10-17

[22] Chaos Mesh. Simulate Network Faults. 官方文档，核验2026-10-17. https://chaos-mesh.org/docs/simulate-network-chaos-on-kubernetes/

[23] Jepsen. Consistency. 官方一致性模型说明，核验2026-10-17. https://jepsen.io/consistency

[24] AWS. Deleting Object Versions from a Versioning-enabled Bucket. 官方S3文档，核验2026-10-17. https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjectVersions.html

[25] PostgreSQL. 25.3 Continuous Archiving and Point-in-Time Recovery. 18. https://www.postgresql.org/docs/18/continuous-archiving.html 核验2026-10-17