第26章：数据平台可观测性¶

杜文卓（Wenzhuo Du）；王灿（Can Wang）；於俊（Jun Yu）

摘要¶

"调度成功"和"数据健康"是两件完全不同的事情。SRE 实践强调，系统健康不能只看进程是否运行，而要看服务是否持续满足用户可感知的可靠性目标（Beyer et al. 2016）。数据平台的作业可能在全绿的状态下运行，而训练数据的质量已经悄然恶化——直到算法团队发现模型效果异常，数据团队才开始排查，发现问题已经累积了数周。

本章面向负责平台稳定性、作业监控和质量预警的工程团队，系统阐述如何建立 LLM 数据平台的可观测性体系。可观测性通常需要把指标、日志、追踪和上下文信息组合起来，用于解释系统为什么处于当前状态，而不只是报告状态本身（Sigelman et al. 2010; OpenTelemetry Authors 2024）。本章将从四个层面展开：首先分析为什么作业成功不等于数据健康，以及 LLM 数据平台特有的故障模式；其次建立指标分层体系，将任务指标、质量指标和业务指标整合到统一的观测框架中；第三，设计告警策略、异常归因流程和应急响应机制；最后，讨论容量预测、成本预警和运营面板的设计。

读者读完本章后，将掌握一套完整的数据平台可观测性设计方案：包括监控指标分层表、告警级别与处置动作表、一份可直接复用的事故复盘模板，以及一次真实平台事故的完整复盘案例。

关键词¶

数据平台可观测性；质量指标；血缘追踪；告警归因；事故复盘；成本预警

学习目标¶

能够区分调度成功、任务成功与数据正确三个层次及其典型漏检场景。
能够识别语义漂移、过滤过度、依赖版本漂移与语料污染等静默失效故障模式。
能够设计整合任务指标、质量指标与业务指标的分层观测框架。
能够构建告警分级、异常归因与应急响应流程。
能够设计容量预测、成本预警与运营面板以支撑平台长期运行。

场景引入¶

以下为匿名化复合案例，数值用于说明可观测性问题的量级，不代表某个公开平台的真实统计。某公司的 LLM 数据平台每天处理约 200 万条原始数据，经过清洗、标注、格式转换后，产出约 10 万条训练样本。平台的监控面板显示：过去一个月，所有调度系统 DAG 的成功率保持在 99.2% 以上，作业平均耗时稳定，存储空间充足，看起来一切正常。

然而，在一次月度评审会议上，算法团队提出：最近两周的训练实验效果明显不如预期，特别是中文长文理解任务的评测分数出现了约 6% 的下滑。数据团队开始排查。

排查结果如下：三周前，数据清洗管线的一个依赖库升级了版本，新版本的分词器对中文长文的截断处理发生了变化，导致超过 512 token 的长文本被错误地截断，而不是按语义边界切分。作业仍然成功运行，输出文件的样本数量看起来正常，所有任务指标都已达成——但数据内容已经变了，而没有任何一个告警被触发。

这个案例揭示了数据平台可观测性的核心命题：不能用"作业是否成功运行"来代替"数据是否健康"。生产机器学习系统中的静默错误和数据依赖问题，常常会绕过传统基础设施监控，最终表现为模型质量退化（Sculley et al. 2015; Polyzotis et al. 2017）。两者是不同层面的问题，需要不同层面的监控体系。

26.1 为什么作业成功不等于数据健康¶

26.1.1 调度成功、任务成功与数据正确并不等价¶

理解这三个层次的区别，是建立正确可观测性体系的前提：

调度成功是最基础的层次：调度系统（如 Airflow）成功触发了任务，任务进入运行队列。调度成功只意味着"任务被启动了"，不代表任务做了正确的事情。

任务成功是第二个层次：任务进程以退出码 0 结束，没有抛出未捕获的异常。任务成功意味着"程序正常运行完了"，但程序运行完的结果可能是错误的——比如处理了一个空文件、过滤条件出现 bug 导致所有样本被删除、或者输出格式不符合预期。

数据正确是最关键的层次：产出的数据在内容上是健康的，符合业务期望的质量标准。数据验证研究表明，schema、统计约束、分布偏移和异常值检测应被纳入常规流水线，而不是事故后手工排查（Breck et al. 2019）。数据正确无法通过任务状态来反映，只能通过对数据内容本身的检查来验证。

表26-1汇总了本节的关键对象、工程要点与复核口径。

表 26-1：三个层次的成功定义与典型漏检场景。

层次	检测对象	典型工具	常见的漏检场景
调度成功	任务是否启动	Airflow/Dagster 状态	任务启动但立即以错误退出
任务成功	进程退出码	监控系统告警	任务完成但输出为空、输出内容错误
数据正确	数据内容质量	数据质量检测框架	内容格式正确但语义错误、分布偏移

这三个层次之间存在明显的包含关系，但不能相互替代。调度成功只是说明控制平面没有明显故障，任务成功只是说明执行平面没有显式异常，数据正确才说明业务语义层面的结果可信。许多团队之所以长期误判平台健康，是因为把控制平面和执行平面的绿色状态当作数据层面的绿色状态。对于传统批处理报表，这种误判可能只造成某个指标晚一天修复；对于 LLM 数据平台，它可能让错误数据进入训练集，并在数周后以模型能力退化的形式暴露出来。

因此，数据平台可观测性首先需要重新定义"成功"。一个数据处理任务真正成功，应至少满足四个条件：任务按预期时间运行，处理过程没有异常退出，输出数据满足结构和统计约束，输出数据在语义和业务覆盖上没有偏离目标。前两个条件属于平台工程范围，后两个条件属于数据质量和业务治理范围。只有把四个条件同时纳入监控，团队才能避免"管线全绿但模型变差"的静默风险。

在实际系统中，调度成功和任务成功通常容易被自动化监控覆盖，因为它们对应明确的机器信号：状态码、退出码、耗时、重试次数、资源使用率。数据正确则更困难，因为它涉及内容、分布、语义和业务边界。一个样本字段完整、长度合理、语言识别正确，并不意味着它适合训练；一个标注批次通过抽检，也不意味着它在关键业务场景中没有系统性偏差。数据健康必须通过多维信号共同判断，而不是依靠单一指标。

数据正确还具有相对性。同一批数据在一个任务中可能是高质量数据，在另一个任务中可能是噪声。例如，历史政策文本对历史问答任务有价值，但对当前操作指导任务可能有风险；用户投诉文本对鲁棒性训练有价值，但如果没有脱敏和分类，也可能带来隐私和安全问题。因此，数据健康不能只定义为"没有错误"，还要定义为"在指定用途下适合使用"。这也是数据平台可观测性必须与数据版本、使用场景和数据契约结合的原因。

26.1.2 LLM 数据平台的特有故障模式¶

与传统数据仓库不同，LLM 数据平台面临一类特有的"静默失效"故障——问题发生了，但没有任何明显的错误信号。高风险 AI 场景中的数据级联研究也说明，数据问题往往会沿组织流程和模型链路逐级放大（Sambasivan et al. 2021）：

语义漂移（Semantic Drift）：处理逻辑没有改变，但数据源的内容发生了变化。例如，爬虫抓取的网页内容变成了广告页，或者外包商的标注风格在不知不觉中发生了偏移，导致输出数据的语义分布偏离了预期，但文件格式、样本数量等结构化指标完全正常。

过滤过度（Over-filtering）：清洗逻辑的某个参数调整（如质量分数阈值提高）导致大量高质量样本被误删，训练集覆盖率下降，但样本数量仍然在"正常范围"内，不会触发数量类告警。

依赖版本漂移（Dependency Drift）：如上文案例所示，处理框架的底层依赖库升级，改变了某些数据处理行为，但测试用例没有覆盖到这类边界情况。

标注一致性衰减（Annotation Drift）：长期标注任务中，标注员疲劳或理解偏差导致标注质量缓慢下降，但单批次的质量抽检可能无法发现这种趋势性变化。

数据孤岛（Data Island）：多路数据源中的某一路突然停止更新（如某个第三方数据合作到期），导致训练数据缺乏某类领域的覆盖，但总量指标没有显著变化。

这些故障模式的共同特点是：表面的系统指标健康，但实质的数据健康已经出问题。生产 ML 平台需要同时关注数据、模型、基础设施和业务反馈，才能覆盖这类跨层故障（Amershi et al. 2019; Kreuzberger, Kühl and Hirschl 2023）。传统的基础设施监控体系无法感知这类问题，需要专门针对数据内容的质量监控来覆盖。

LLM 数据平台还存在一些更隐蔽的故障模式。第一类是语料污染：本应作为评测集或验证集保留的数据，被误合并进训练集，导致模型评测结果虚高。污染问题通常不会让作业失败，也不会让质量指标异常，只有在评测结果与真实线上表现不一致时才会暴露。第二类是类别稀释：新增大量通用样本后，关键小类样本占比下降，模型在小类场景中的能力退化，但总体指标可能仍然稳定。第三类是安全边界漂移：拒答、敏感信息处理或风险内容过滤规则发生变化，导致安全数据分布改变，但普通质量指标无法捕捉这种变化。

第四类是元数据失真。数据内容本身可能没有变化，但标签、来源、时间戳、授权状态或业务类别等元数据出现错误，导致下游系统误用数据。例如，一批仅允许内部评测的数据被标记为可训练数据，一批英文数据被错误归入中文语料，一批历史反馈数据被标记为近期反馈。元数据失真在短期内不一定影响训练作业，却会破坏数据治理和实验解释。

第五类是处理顺序漂移。在复杂流水线中，过滤、去重、脱敏、分片、标注和采样的顺序会影响最终数据分布。某个步骤顺序调整后，任务仍然成功，输出规模也可能正常，但被保留和被删除的样本集合已经发生变化。尤其在去重与采样同时存在时，顺序变化可能显著影响长尾样本保留率。可观测性系统需要记录处理链路和关键中间指标，才能发现这类问题。

这些故障模式说明，LLM 数据平台的监控对象不能仅限于作业和服务，还必须包括数据分布、数据语义、元数据、处理规则、版本依赖和下游使用。换言之，数据平台可观测性是一套跨层能力：它既要能发现机器层面的故障，也要能发现数据资产层面的退化。

26.1.3 数据健康问题为何经常滞后暴露¶

LLM 数据质量问题的一个典型特征是"影响延迟"——问题发生后，可能要等几周甚至几个月才在模型效果上表现出来。这个延迟来自两个环节：

数据-训练延迟：数据问题发生后，问题数据需要积累到足够的量才会被采集进训练集；训练本身需要时间；训练后还需要经过评测才能发现效果异常。在规律性的迭代中，这个延迟通常在 2-6 周。

训练-部署延迟：模型训练完成后，往往还需要经过多轮评测、灰度发布才能全量上线，这又增加了 1-4 周的延迟。

总的影响延迟可能长达 2-3 个月。这意味着，如果没有在数据层面的实时或近实时监控，团队就会一直在事后被动处置，而不是事中预警。

滞后暴露还与组织协作链路有关。数据团队通常最早接触原始数据，但模型效果由算法团队观察，线上反馈由产品或运营团队收集，合规问题由安全和法务团队关注。如果这些信号没有汇聚到统一平台，数据健康问题就会在组织边界之间来回传递。一个数据源断供可能先表现为训练集覆盖率下降，再表现为模型某类能力退化，最后才表现为用户投诉。可观测性系统的作用，就是把这些分散信号提前连接起来。

另一个原因是团队对"正常波动"缺少基线。数据指标天然会波动，例如每日采集量、类别占比、质量分数和标注一致性都会受到业务活动、供应商排期和采样策略影响。如果没有历史基线，工程师很难判断一次波动是否异常。过于敏感会产生告警疲劳，过于迟钝则会错过早期信号。因此，数据健康监控必须同时保存短期窗口和长期趋势，用趋势变化来识别风险，而不是只看单点阈值。

对 LLM 数据平台而言，最有价值的监控往往不是告诉团队"已经坏了"，而是告诉团队"正在变坏"。例如，某类样本覆盖率连续三批下降，某个供应商的标注一致性连续两周低于历史均值，某条数据源的新鲜度逐渐落后于业务变化，某个清洗规则的过滤比例缓慢升高。这些信号如果被及时捕捉，团队可以在数据进入正式训练前完成修复。

26.2 指标体系、日志、追踪与血缘结合¶

26.2.1 三层指标体系¶

LLM 数据平台的指标体系应该分为三个层次，每个层次解决不同的问题。SRE 中的 SLI/SLO 思路可以迁移到数据平台，但需要把服务请求层面的指标扩展到数据内容、质量和业务覆盖层面（Beyer et al. 2016）：

第一层：任务指标（Task Metrics）

任务指标是对平台运行状态的基础监控，衡量"任务是否按时完成"。主要指标包括：

任务成功率：过去 24 小时内，成功完成的任务数 / 总触发任务数
任务耗时：各类任务的平均执行时间和 P95 分位
队列积压：等待执行的任务数量趋势
重试率：需要重试才能成功的任务比例（高重试率暗示底层资源或依赖不稳定）
数据吞吐量：每小时处理的原始数据量（记录数和存储大小）

任务指标是可观测性的基础，但如前文所述，全绿的任务指标不意味着数据健康。

第二层：质量指标（Quality Metrics）

质量指标是对数据内容健康程度的直接度量，衡量"产出的数据是否符合质量标准"。主要指标包括：

空白率：内容为空或过短（< 10 tokens）的样本比例
重复率：与历史数据集重复的样本比例
格式合规率：样本字段完整性和格式正确性
语言分布：多语言数据集中各语言的比例（偏离预期分布触发告警）
标注一致性：同一批次中，同类标注任务的 IAA 评分
平均质量分数：使用自动质量评估模型打分的平均值和分布
特定类别覆盖率：训练目标中，关键业务类别的样本数量和比例

质量指标需要在每个处理批次产出后计算，形成时序数据，便于趋势分析和异常检测。ML Test Score 也把数据测试、训练/服务一致性和监控覆盖纳入生产就绪度评估（Breck et al. 2017）。

第三层：业务指标（Business Metrics）

业务指标是从业务价值角度衡量数据资产的整体健康状况，衡量"数据是否在支撑业务目标"。主要指标包括：

训练集领域覆盖率：训练集是否覆盖了所有目标业务场景
数据新鲜度：训练集中最近一段时间内的数据占比（避免知识截止问题）
标注吞吐量：单位时间内完成高质量标注的样本数量（支撑迭代节奏的核心指标）
数据需求响应率：来自算法团队的数据需求，按时完成的比例
合规数据比例：通过合规审核的数据占总数据的比例

表26-2汇总了本节的关键对象、工程要点与复核口径。

表 26-2：监控指标分层表。

指标层次	典型指标	更新频率	主要受众
任务指标	成功率、耗时、吞吐量	实时/分钟级	平台工程师、SRE
质量指标	空白率、重复率、一致性、覆盖率	批次级（小时/天）	数据工程师、质量评估员
业务指标	领域覆盖、数据新鲜度、响应率	日/周	数据Owner、算法团队、产品团队

三层指标体系需要避免彼此割裂。任务指标告诉团队"平台是否按时运行"，质量指标告诉团队"数据是否达到标准"，业务指标告诉团队"数据是否支撑目标"。如果只看任务指标，团队会忽视静默质量问题；如果只看质量指标，团队可能不知道问题是否已经影响业务；如果只看业务指标，团队又会在问题暴露太晚时才开始排查。三层指标必须通过同一个数据版本、同一个处理批次和同一个时间窗口关联起来，才能形成完整判断。

指标体系还应区分"健康指标"和"诊断指标"。健康指标用于判断是否需要告警，例如重复率、空白率、类别覆盖率、数据新鲜度和标注一致性；诊断指标用于解释为什么异常发生，例如各来源占比、过滤原因分布、处理节点耗时、依赖版本变化和外包商批次差异。健康指标应尽量少而稳定，诊断指标可以更丰富，用于事故排查。把所有诊断指标都设置为告警，会导致噪声过多；缺少诊断指标，则会让告警触发后难以定位原因。

指标还需要有明确的所有者。平台工程师负责任务成功率、队列积压和资源利用率；数据工程师负责吞吐量、处理失败原因和版本产出；质量评估员负责重复率、空白率、一致性和覆盖率；数据 Owner 负责业务覆盖、需求响应和数据资产复用；合规角色负责授权状态、敏感数据比例和访问审计。没有所有者的指标最终会变成无人处理的仪表盘装饰。

指标设计还应保留解释上下文。一个指标数值本身通常不足以判断是否异常。例如，数据吞吐量下降可能是数据源故障，也可能是业务淡季；重复率上升可能是爬虫问题，也可能是某个业务事件导致用户集中咨询相似问题；标注一致性下降可能是标注员质量退化，也可能是任务难度提高。面板中应当同时显示数据来源、版本、业务日历、变更记录和质量规则版本，帮助读者理解指标变化。

最后，指标体系需要定期修订。随着模型目标、数据来源和业务场景变化，原有指标可能不再覆盖关键风险。早期团队可能只监控格式、数量和去重；成熟团队则需要监控语义覆盖、偏好分布、安全边界、评测污染和数据资产复用。指标体系如果长期不变，就会逐渐与真实风险脱节。建议在月度质量评审或季度数据治理评审中，专门检查指标是否仍然有效。

26.2.2 日志、Trace、Audit Log 与 Lineage 的组合¶

可观测性的四个核心工具——日志（Log）、追踪（Trace）、审计日志（Audit Log）和血缘（Lineage）——在数据平台中各有分工，需要组合使用。日志管理、分布式追踪和血缘上下文分别回答“发生了什么”“请求经历了什么路径”和“数据从哪里来”的问题（NIST 2006; Sigelman et al. 2010; Hellerstein et al. 2017）：

日志（Log）：记录数据处理过程中的详细运行信息，包括每条数据的处理结果（通过/过滤/异常）、过滤原因、处理耗时。系统日志研究表明，日志不仅是事故后证据，也可以通过模式挖掘提前发现大规模系统异常（Oliner and Stearley 2007; Xu et al. 2009）。日志是最细粒度的记录，适用于问题排查，但不适合长期全量保存（成本过高）。建议采用分级日志：

INFO 级：记录批次级别的汇总信息（每批次处理了多少条、过滤了多少条）
DEBUG 级：记录单条数据的详细处理过程（仅在问题排查时开启）
ERROR 级：记录处理失败或异常情况（永久保留）

追踪（Trace）：记录一条数据从进入管线到产出的完整处理链路，包括经过的每个处理节点和对应的时间戳。Dapper 的经验说明，端到端分布式追踪对于定位跨服务性能瓶颈和请求路径异常关键（Sigelman et al. 2010）。与日志不同，Trace 强调跨系统的端到端视角。在数据平台中，Trace 可以帮助回答："这条样本是什么时候进来的，经过了哪些处理步骤，最终出现在哪个数据集版本中"。

审计日志（Audit Log）：记录谁在什么时间对数据做了什么操作，不可篡改，用于合规审计。审计日志必须永久保留，必须包含完整的操作者身份信息。典型的审计事件包括：数据集版本创建/删除、质量标准修改、合规审核通过/拒绝、数据访问请求。

血缘（Lineage）：如第25章所述，记录数据资产之间的依赖关系。血缘信息与日志和 Trace 的主要区别在于：血缘描述的是静态的"产生关系"，而日志和 Trace 描述的是动态的"处理过程"。血缘图告诉你"数据集 v2.3 是由哪些数据源加工而来"，Trace 告诉你"这条具体的样本经历了什么处理"。

表26-3汇总了本节的关键对象、工程要点与复核口径。

表 26-3：可观测典型信息特点。

工具	记录对象	时效性	主要用途
日志	处理过程事件	实时	故障排查、过滤原因分析
Trace	单条数据端到端路径	实时	数据追溯、性能分析
审计日志	用户操作事件	实时，永久保留	合规审计、责任追溯
血缘	数据资产依赖关系	每次版本变更更新	影响分析、根因定位

四类信息的组合方式决定了可观测性的上限。日志适合解释单个处理步骤中发生了什么，Trace 适合解释单条样本经历了什么路径，审计日志适合解释谁做了什么操作，血缘适合解释数据资产之间如何依赖。如果团队只保存日志，事故发生后仍然难以判断影响范围；如果只有血缘而没有日志，则知道依赖关系，却不知道具体处理细节；如果没有审计日志，就无法回答权限、责任和合规问题。

在一次典型排障中，工程师可能先从告警指标发现某类样本覆盖率下降，再通过血缘图定位到受影响数据集和上游分片，然后通过 Trace 抽查异常样本经过的处理节点，最后通过日志和审计日志确认某个过滤规则变更是根因。这条路径体现了四类信息的互补关系：指标负责发现异常，血缘负责确定范围，Trace 负责连接样本路径，日志和审计负责解释具体动作。

为了支持这种组合查询，平台需要统一关联键。批次 ID、样本 ID、数据集版本、任务运行 ID、代码版本和操作人 ID 应在日志、Trace、审计和血缘中保持一致。如果每个系统都有自己的命名方式，排障时就需要人工对齐，极大降低效率。统一 ID 是可观测性系统的基础设施，看似不显眼，却决定了跨系统查询能否成立。

四类信息的保留策略也应不同。全量 DEBUG 日志成本高，不宜长期保存；批次级 INFO 日志和 ERROR 日志应保留更久；Trace 可以对普通样本采样，但对异常样本、关键数据集和高风险任务应全量保留；审计日志应长期保存且不可篡改；血缘信息则应随数据版本永久保留。统一保留策略会造成成本浪费或证据不足，分层保留更符合数据平台实际。

此外，审计日志和可观测日志不应混淆。可观测日志服务于工程排障，可以根据成本和性能做采样；审计日志服务于责任和合规，必须完整、不可篡改、可验证。某些团队为了节省成本把审计事件写入普通应用日志，后续在审查时很难证明其完整性和可信度。对于数据访问、权限变更、质量规则修改和版本删除等关键事件，应建立专门的审计通道。

26.2.3 从作业可观测到数据资产可观测¶

传统的基础设施监控（CPU、内存、磁盘、网络）加上作业状态监控，只覆盖了"计算资源健康"和"流程健康"两个维度。LLM 数据平台还需要覆盖第三个维度：数据资产健康。

数据资产健康监控的核心是建立"数据集 SLO（Service Level Objective）"——对每个重要的数据集，定义其质量目标和监控规则。SRE Workbook 强调，SLO 应服务于实际用户体验和错误预算决策；数据集 SLO 也应服务于下游训练、评测和业务使用的真实风险（Beyer et al. 2018）。例如：

代码清单26-1给出了YAML 配置示例。

dataset_slo:
  dataset_id: cs-dialog-sft-zh
  dataset_version: v2.8.0
  contract_id: data-contract-cs-dialog-2024
  owner: data_platform_owner
  steward: cs_domain_data_steward
  severity: P1
  runbook_url: https://internal.example.com/runbooks/cs-dialog-slo
  escalation_policy:
    primary: data-platform-oncall
    secondary: data-owner-oncall
    notify_after: 30m
  slo:
    - metric: duplicate_rate
      threshold: 0.01       # 重复率 < 1%
      window: 7d            # 7天滚动窗口
    - metric: blank_rate
      threshold: 0.005      # 空白率 < 0.5%
    - metric: iaa_score
      threshold: 0.85       # 标注一致性 > 0.85
    - metric: coverage_rate_by_category
      min_coverage:
        refund: 0.05        # "退款"类样本 > 5%
        complaint: 0.08     # "投诉"类样本 > 8%
  alert_channel: "#data-platform-alerts"
  on_violation: page_on_call

代码清单26-1：YAML 配置示例。

这种 SLO 驱动的数据资产监控，使得数据质量问题可以在训练之前就被发现，而不是等到模型效果下降后才回溯。需要注意的是，数据集 SLO 不应只有指标、阈值和告警渠道，还应包含运维闭环字段：owner 用于明确最终责任人，steward 用于明确日常维护人，runbook_url 指向排障手册，severity 决定告警级别，escalation_policy 定义升级路径，dataset_version 绑定当前受控版本，contract_id 关联数据契约或数据产品接口。缺少这些字段时，SLO 只能发现问题，却无法保证问题被正确接手、升级和修复。

数据集 SLO 的设计必须贴近使用场景。一个通用预训练语料的数据集 SLO 可能强调语言分布、去重率、毒性内容比例和来源多样性；一个客服 SFT 数据集可能强调业务类别覆盖、标注一致性、历史流程保留和敏感信息脱敏；一个评测集则更强调污染防控、题目稳定性和版本冻结。把所有数据集套用同一组指标，会让监控看似统一，实际却无法覆盖关键风险。

数据集 SLO 还应包含错误预算思想。如果某个数据集连续多次违反 SLO，团队应暂停扩大使用范围，优先修复质量和流程问题；如果数据集长期稳定达标，可以考虑提高自动化发布比例或扩大复用范围。这样，SLO 不只是告警阈值，而是数据资产治理的决策依据。稳定资产获得更多信任，不稳定资产需要更多审查。

从作业可观测到数据资产可观测，还意味着监控对象从"一次运行"扩展为"一个长期演化的数据产品"。作业运行结束后，任务指标的价值会迅速下降；但数据集会持续被训练、评测、复用和审计，其质量状态需要长期跟踪。一个数据集今天健康，不代表下周仍然健康；一个版本被冻结，不代表其已知限制不需要被记录。数据资产可观测性要求团队持续维护数据集的健康档案。

健康档案应至少包括版本历史、质量趋势、SLO 达成情况、已知问题、下游使用、事故记录和责任人。对于高价值数据资产，还可以增加使用收益、复用次数、成本投入和模型效果贡献等信息。这样，数据 Owner 不仅能看到数据集"是否可用"，还能判断它"是否值得继续维护"。

26.3 告警策略、归因与应急流程¶

26.3.1 告警设计原则¶

数据平台的告警设计有两个常见误区：告警过少（出了问题才知道）和告警过多（告警疲劳，有告警也不当回事）。监控工程实践强调，告警应该对应可执行动作，并尽量避免把不可行动的噪声推给值班人员（Turnbull 2014; Beyer et al. 2016）。好的告警策略需要在敏感性和精确性之间取得平衡。

以下是 LLM 数据平台告警设计的五个原则：

原则一：告警必须可执行。每一条告警触发后，必须有对应的处置动作。如果一条告警触发后，接收者不知道该做什么，这条告警就不应该存在（或者应该改为信息通知而非告警）。

原则二：告警按影响分级。不同严重程度的问题应该有不同的响应级别，而不是所有告警都以同样的紧迫度处理。

原则三：告警避免孤立指标。单个指标的瞬时波动可能是噪声，组合告警（多个指标同时异常）的可靠性更高。例如，"重复率上升"可能是正常批次差异，但"重复率上升 + 样本量增加 + 数据新鲜度下降"同时出现，则强烈暗示数据管线出现了问题。

原则四：区分静态阈值和动态基线。静态阈值（如"空白率 > 5% 就告警"）适用于有明确质量标准的指标；动态基线（如"今天的数值比过去 30 天均值高 3 个标准差"）适用于正常值会随时间变化的指标（如日处理量可能随业务增长而正常增加）。

原则五：告警收敛。如果同一个根因导致多个指标同时异常，应该聚合成一条告警，而不是发出十条不同的告警。

告警设计还需要明确"通知"与"告警"的边界。通知用于让相关人员知情，例如某个低风险批次完成、某项指标略有波动、某个非关键任务延迟；告警则意味着必须有人采取行动。如果所有通知都进入告警渠道，值班人员会逐渐忽视告警。一个成熟平台应当把信息分为仪表盘展示、异步通知、工作项、告警和事故五个层级，并根据影响程度逐级升级。

动态基线的使用也需要谨慎。对于具有强季节性或业务周期的数据，静态阈值会产生大量误报；对于合规、安全和关键质量指标，动态基线又可能掩盖慢性退化。例如，敏感信息泄露比例即使长期很低，也不能因为历史均值低就放松阈值；某个关键类别覆盖率如果连续缓慢下降，动态基线可能跟着下降，反而不触发告警。因此，关键指标应结合绝对阈值、相对变化和长期趋势共同判断。

告警还应包含足够上下文。一个只写"duplicate_rate high"的告警价值很低；一个有用的告警应说明哪个数据集、哪个版本、哪个批次、当前值、历史基线、影响范围、最近变更、推荐排查入口和负责人。告警本身就是排障流程的第一份材料，信息越完整，平均确认时间和定位时间越短。

同时，告警系统需要持续回顾。每周或每月可以统计告警数量、误报率、未确认比例、平均确认时间、平均恢复时间和重复告警比例。误报率高说明规则过于敏感或上下文不足；未确认比例高说明通知渠道或责任机制有问题；重复告警比例高说明根因没有被解决。告警治理本身也是数据平台运营的一部分。

26.3.2 四级告警体系¶

表26-4汇总了本节的关键对象、工程要点与复核口径。

表 26-4：告警级别与处置动作表。

级别	名称	触发条件示例	响应时间	通知方式	处置动作
P0	严重（Critical）	核心管线完全中断；训练集被意外删除；发现大量合规违规数据	15分钟内	电话 + 短信 + 即时消息	立即通知值班工程师，启动事故响应流程
P1	高（High）	数据吞吐量下降 > 50%；质量指标大幅偏离基线（> 3σ）；关键类别数据断供	1小时内	即时消息 + 邮件	值班工程师在1小时内确认问题，评估影响范围
P2	中（Medium）	数据吞吐量下降 20-50%；质量指标轻微偏离（2-3σ）；标注任务积压超过阈值	4小时内	即时消息	在当天工作时间内处理
P3	低（Low）	非关键指标异常；趋势性预警（如存储使用率连续7天上升）	24小时内	邮件	纳入当周任务计划处理

P0 和 P1 告警必须有人工确认（ACK）机制。高可靠系统通常通过分级告警、升级路径和明确值班责任来缩短平均恢复时间，并避免事故在无人接手时扩大（Beyer et al. 2018; Nygard 2018）。收到告警的工程师必须在规定时间内进行确认，否则系统将自动升级。P2 和 P3 告警不需要立即确认，但必须在 SLA 时间内处理完毕并关闭。

四级告警体系还应与数据生命周期结合。采集阶段的断供告警、清洗阶段的过滤异常、标注阶段的一致性下降、训练前的数据集 SLO 违约、发布后的合规风险，虽然都属于数据平台问题，但影响路径不同。P0/P1 的判定不能只看指标偏离程度，还要看是否影响正式训练、关键评测、线上发布或合规承诺。一个低比例敏感数据泄露可能比高比例普通重复样本更严重。

告警升级路径必须明确到角色。平台资源类告警通常由平台工程师处理；数据质量类告警由数据工程师和质量评估员共同处理；业务覆盖类告警需要数据 Owner 和算法代表参与；合规类告警必须通知安全或法务角色。缺少角色路由，告警就会在团队之间转发，延误处置。

对于 P0 和 P1，还应建立沟通节奏。事故负责人需要定期更新状态，例如每 30 分钟同步一次影响范围、当前判断、下一步动作和预计恢复时间。对外沟通应避免过早下结论，但必须及时说明止损动作。数据事故往往影响多个实验和团队，如果缺少统一沟通，算法团队可能继续使用受影响数据，扩大损失。

26.3.3 异常归因决策树¶

当告警触发后，工程师面临的第一个问题是：这个问题的根因在哪里？复杂系统的尾延迟与跨层依赖问题表明，局部正常并不代表整体正常，归因流程必须从基础设施、调度、数据来源、处理逻辑和数据内容逐层收敛（Dean and Barroso 2013; Kleppmann 2017）。以下决策树是 LLM 数据平台中最常见的异常归因路径：

第一步：判断是平台问题还是数据问题

检查底层基础设施状态（服务器、存储、网络）是否正常
检查调度系统是否有任务失败或延迟
如果基础设施和调度都正常，问题在数据层

第二步（数据层）：判断是来源问题还是处理问题

检查原始数据的入库量是否正常（是否有数据源断供）
检查各数据来源的占比是否有显著变化
如果入库量和分布都正常，问题在处理层

第三步（处理层）：判断是代码问题还是配置问题

检查最近是否有代码或依赖库的版本变更
检查最近是否有配置参数的修改（如质量阈值、过滤规则）
如果代码和配置都没有变更，检查数据内容本身

第四步（数据内容）：判断是分布漂移还是标注质量问题

检查不同数据来源的质量分数分布是否有显著变化
检查最近的标注批次 IAA 是否有下降趋势
抽样检查具体样本，人工判断质量

归因决策树的作用不是替代工程师判断，而是提供稳定的排查顺序。事故发生时，团队容易受到最近变更、个人经验或最显眼指标的影响，过早锁定某个方向。结构化决策树可以帮助工程师先排除基础设施和调度问题，再进入来源、处理和内容层面，减少无序排查。

归因还应遵循"先止损、后精确"的原则。如果告警显示错误数据正在持续进入正式训练集，团队应先暂停相关管线或隔离受影响批次，而不是等待完整根因确认。数据事故与普通服务事故不同：错误数据一旦被多个实验或版本消费，后续清理成本会迅速增加。止损动作可以是暂停写入、冻结版本、撤销发布候选、通知下游停止使用或回滚到上一个健康数据集。

在排查数据内容问题时，自动指标与人工抽样应结合。自动指标擅长发现统计异常，但不一定能判断语义质量；人工抽样能够识别语义错误，但覆盖范围有限。较好的方式是先用指标定位异常来源、类别、批次或供应商，再对这些局部范围进行分层抽样。这样既避免盲目抽样，也能弥补自动检测的语义盲区。

归因结果应写回问题池和知识库。每次事故排查都会产生有价值的排障路径，例如某类告警通常由某个数据源断供引起，某个质量分数下降通常与某种标注任务有关，某个依赖升级常影响特定语言处理。把这些经验写入排障手册，可以缩短下一次类似事故的定位时间。

图26-1展示了相应的流程或结构。

图26-1：LLM 数据平台异常归因决策树——从告警触发到根因定位的四级诊断路径。

26.3.4 数据事故分级响应与排障手册¶

数据事故（Data Incident）是指数据质量或平台状态出现严重异常，影响到训练数据的可用性或可靠性的情况。事故响应不应只关注快速修复，还应记录时间线、影响范围、根因和预防动作，形成组织学习闭环（Beyer et al. 2016; Nygard 2018）。以下是一套标准化的事故响应流程：

事故触发：P0 或 P1 告警触发，且问题在 15/60 分钟内未被自动恢复。

事故声明：值班工程师创建事故工单，填写：

事故描述（影响了什么）
影响范围评估（哪些数据集、哪些下游任务受影响）
事故负责人（IC，Incident Commander）
通知范围（需要知情的团队和个人）

诊断与止损：

按归因决策树快速诊断根因（目标：在P0情况下30分钟内定位根因）
评估是否需要立即止损（如暂停受影响管线的运行，避免错误数据继续生产）
如果无法快速修复，评估是否需要回滚到上一个健康版本

恢复与验证：

执行修复或回滚操作
运行自动化质量检查，确认数据恢复到健康状态
由事故 IC 宣布事故解除

复盘：事故解除后的 48 小时内，完成事故复盘报告（格式见本章末尾附录）。

事故响应中需要设置明确的角色。事故负责人（Incident Commander）负责整体协调和决策节奏，不一定亲自排查技术细节；技术负责人负责根因定位和修复方案；沟通负责人负责向受影响团队同步状态；记录人负责维护时间线、关键判断和行动项。小团队可以由一人兼任多个角色，但角色职责仍应明确，否则事故处理中容易出现无人决策或多人重复排查。

排障手册应当写成可执行步骤，而不是概念性原则。例如，"检查数据源是否正常"应进一步写明查询哪个面板、看哪些指标、如何判断断供、断供应通知谁；"回滚到上一个健康版本"应说明健康版本如何确认、回滚命令或流程在哪里、回滚后如何验证。手册越具体，值班人员在高压状态下越容易执行。

事故响应还应区分恢复和修复。恢复是让系统或数据尽快回到可接受状态，例如暂停问题管线、回滚数据版本、重新处理受影响批次；修复是消除根因，例如补充测试、修改规则、完善审批和增加监控。很多团队在恢复后就结束事故，导致同类问题重复发生。正式关闭事故前，必须确认修复项有负责人、期限和验收标准。

对于数据事故，还应明确受影响数据的处置方式。受影响批次是否删除、隔离、修复、重新标注或降级使用，需要写入事故记录。不能只修复管线而不处理已经产生的数据，否则错误数据可能在未来被重新引用。数据事故的关闭条件应包括：错误数据停止扩散，受影响版本被标记，修复数据通过质量验证，下游团队收到明确通知。

26.4 容量预测、成本预警与运营面板¶

26.4.1 容量预测的三个维度¶

LLM 数据平台的容量预测需要覆盖三个维度：处理量、存储量和标注量。数据密集型系统设计通常需要同时考虑吞吐、延迟、存储增长、故障恢复和成本约束，因为这些因素会共同决定平台可扩展性（Kleppmann 2017）。

处理量预测：

处理量（每天需要处理的原始数据量）通常与业务增长节奏相关。可以基于历史趋势进行简单的线性或指数外推，但需要叠加以下调整因素：

季节性因素：某些业务数据的产生有明显的时间规律（如电商的促销节点）
项目驱动的脉冲：新项目启动或大版本迭代前，数据需求会出现集中爆发
算法演进：新的训练范式（如更长的上下文、更精细的 RLHF 流程）会改变数据消耗模式

存储量预测：

存储量的增长由三个因素驱动：新产出数据的增加、历史数据的保留策略、数据格式的变化（如 token 化后数据通常比原始数据更大）。

关键决策：不同类型数据的保留期限。原始爬取数据：保留 12 个月；处理后的分片数据：保留 6 个月；已发布的数据集版本：永久保留；历史实验数据：保留 18 个月（见第25章版本粒度表）。

标注量预测：

标注量预测需要考虑：算法团队的实验计划（通常由产品路线图驱动）、标注员的产能（每人每天可以完成的标注数量）、标注任务的复杂度（不同类型的标注任务耗时差异可能高达 10 倍）。

标注量预测的结果决定了标注团队的规模规划和外包商资源预留，应该在季度初完成，并在月度评审时更新。

容量预测不应只服务于资源采购，也应服务于数据交付承诺。处理量不足会导致数据清洗和质量检查排队，存储量不足会迫使团队过早删除中间产物，标注量不足则会拖慢模型迭代节奏。三类容量约束最终都会转化为数据团队的 SLA 风险。因此，容量预测应与需求池、版本计划和模型训练日历联动，而不是由平台团队单独估算。

处理量预测需要关注峰值而不仅是平均值。LLM 数据项目常常存在阶段性脉冲，例如大版本训练前集中补充数据、评测发现能力短板后临时追加某类样本、合规整改期间重新清洗历史数据。如果平台只按平均吞吐设计，峰值期间会出现任务积压，进而影响训练窗口。较好的做法是同时估算平均处理量、P95 处理量和应急重处理能力。

存储量预测还需要考虑版本策略。数据平台为了支持复现和审计，会保留多个历史版本、分片和质量报告。版本越多，可追溯性越好，但存储成本越高。平台团队应与数据 Owner 一起确定哪些数据必须永久保存，哪些可以归档，哪些可以在一定期限后删除。没有保留策略的版本管理，会把可观测性成本推高到不可持续。

标注量预测则应纳入质量因素。低质量标注会产生返工，实际占用的标注能力可能远高于计划数量。复杂任务还需要培训、校准、争议处理和专家复审，这些时间都应计入容量。简单用"样本数 / 人均日产能"估算标注能力，往往会低估真实周期。对于高价值或高风险任务，宁可降低名义吞吐，也要预留质量复核时间。

容量预测的结果应进入运营面板，并形成提前预警。例如，未来两周训练计划需要 300 万条清洗样本，而当前平台按历史吞吐只能交付 220 万条，就应提前触发容量风险提示；如果某类标注任务的积压天数连续上升，也应提前通知数据 Owner 调整优先级或增加外包资源。容量可观测性的目标，是让资源瓶颈在影响交付前被看见。

26.4.2 成本监控与预警¶

LLM 数据平台的主要成本来源有四类。云上数据系统的成本通常来自计算、存储、网络和平台服务的组合，成本可观测性需要与容量预测和保留策略一起设计（Nygard 2018）：

表26-5汇总了本节的关键对象、工程要点与复核口径。

表 26-5：成本驱动因素与优化方向设计。

成本类别	主要驱动因素	优化方向
计算成本	数据处理、格式转换、质量评估的 CPU/GPU 使用	批处理合并、低峰时段运行、算法优化降低计算密度
存储成本	原始数据、中间产物、历史版本的存储	分级存储（热/温/冷）、过期数据自动归档/删除
标注成本	外包标注的单价 × 标注量	提升标注任务设计质量减少返工、合理分配内外部标注比例
工具与平台成本	标注平台、监控工具、版本管理工具的订阅费	自建 vs 购买的 ROI 评估

成本预警应该在两个层面设置：

绝对值预警：当某类成本在一个计费周期内超过预算上限的 80%，触发 P2 告警；超过 100% 触发 P1 告警。

增速预警：当某类成本的月环比增速超过 30%（在没有明确业务增长驱动的情况下），触发调查请求。

除了按成本类别监控，生产级数据平台还应建立 showback/chargeback 口径，即把成本归因到具体数据资产、项目、团队、租户、管线和版本。只知道"存储成本上涨"不足以支持管理决策；团队还需要知道是哪一个数据资产、哪一个项目、哪条流水线或哪个版本策略导致成本上升。showback 侧重透明展示成本归属，帮助团队理解资源消耗；chargeback 则进一步把成本计入业务或团队预算，用于资源治理和优先级决策。

成本归因记录可以采用统一标签或账单维度，例如 asset_id 标识数据资产，project_id 标识项目，team 标识责任团队，pipeline_id 标识产生成本的数据管线，dataset_version 标识具体数据版本，cost_center 标识财务成本中心。对于多租户平台，还可以增加 tenant_id、workspace_id 或 business_domain。这些字段应在任务调度、存储路径、元数据服务和云账单标签中保持一致，否则后续成本聚合会出现大量无法归属的"公共成本"。

一个典型的成本归因事件可以包含：asset_id=cs-dialog-sft-zh、project_id=customer-service-llm、team=data-platform、pipeline_id=cs-dialog-cleaning-dag、dataset_version=v2.8.0、cost_center=FIN-DATA-LLM。有了这些字段，团队就能回答"哪个数据产品最贵""哪个项目产生了最多重处理成本""哪个版本保留策略导致存储增长""哪个团队需要优化管线效率"等问题。

成本监控应避免只看总账单。总成本上升并不一定是坏事，如果它对应更多高质量数据、更快实验迭代或更高复用价值，就是合理投入；总成本下降也不一定是好事，如果它来自质量检查减少、历史版本被过早删除或标注复核不足，就可能埋下风险。成本可观测性应把成本与产出、质量和风险一起呈现。

一个更有解释力的成本指标是单位有效数据成本。它不是简单地用总成本除以样本数，而是用总成本除以通过质量标准、进入可用数据集并被实验消费的数据量。这样可以避免团队用低质量高数量样本稀释成本。对于标注数据，还可以计算单位合格标注成本、单位返工成本和单位高价值类别样本成本。成本指标越接近真实价值流，越能支持管理决策。

成本异常也可能是事故信号。计算成本突然上升，可能是任务重试或死循环；存储成本异常增长，可能是中间产物未清理或版本重复保存；网络成本上升，可能是跨区域数据传输策略错误；标注成本上升，可能是返工率增加或任务设计不清。成本面板如果能与任务、质量和版本指标关联，就能成为异常归因的一部分。

成本治理还需要防止局部优化。平台团队为了降低存储成本过早删除中间数据，可能损害复现和审计；数据团队为了降低标注成本减少复核，可能导致模型质量下降；算法团队为了节省训练成本减少对照实验，可能导致数据策略难以验证。可观测性面板应让各方看到成本节约的代价，而不是只展示成本下降。

在预算管理上，可以采用分层预算：基础运行预算覆盖日常采集、清洗、存储和监控；项目增量预算覆盖大版本训练、专项标注和历史数据重处理；风险预留预算覆盖事故恢复、合规整改和紧急扩容。分层预算能够减少临时审批，并让数据平台在高峰期保持弹性。

26.4.3 三维运营面板设计¶

LLM 数据平台的运营面板需要服务于不同视角的受众：平台工程师关注稳定性，数据 Owner 关注质量和效率，产品和业务团队关注数据资产的业务价值。数据上下文服务的研究强调，治理、血缘、质量和使用信息需要在同一个上下文中呈现，才能支持跨角色决策（Hellerstein et al. 2017）。

建议设计三块独立的面板视图：

面板一：平台健康视图（平台工程师/SRE 使用）

所有数据管线的实时状态（绿/黄/红）
过去 24 小时的任务成功率趋势
当前队列积压量
存储和计算资源使用率
未解决的 P0/P1 告警数量

面板二：数据质量视图（数据 Owner/质量评估员使用）

过去 7 天的关键质量指标趋势（重复率、空白率、标注一致性）
各数据集的 SLO 达成状态
本周产出的数据量与质量摘要
问题池中未解决的高优质量问题

面板三：业务运营视图（产品/算法团队使用）

训练集的领域覆盖率热力图
数据需求响应率（按时交付比例）
本月数据迭代进度（相对于计划）
成本 vs 产出趋势（成本效率指标）

三维运营面板的设计原则是"同源数据，不同视角"。平台工程师、数据 Owner 和业务团队看到的指标可以不同，但底层数据来源应一致。否则，同一问题在不同面板中呈现不同数值，会削弱团队信任。例如，平台健康视图显示任务成功率 99%，数据质量视图却显示关键数据集 SLO 违约，如果两者没有共同的批次和版本关联，团队就很难解释差异。

运营面板还应支持从概览到细节的下钻路径。高层视图显示红黄绿状态和趋势，点击异常指标后应能看到受影响数据集、批次、来源、最近变更、相关告警和责任人。没有下钻能力的面板只能用于展示，不能用于排障；只有细节没有概览的面板则难以支撑管理决策。优秀的面板应同时服务于日常巡检、事故排查和月度复盘。

面板的文字说明也很重要。指标名称、统计口径、更新时间、阈值含义和负责人应在面板中可见。很多监控面板失败不是因为图表不够多，而是因为没有人知道某个指标究竟如何计算。对于跨团队使用的面板，指标口径比可视化样式更重要。指标口径一旦变更，应在面板中标记，避免趋势误读。

运营面板还应设置不同时间尺度。分钟级视图用于事故响应，小时级或日级视图用于批次质量观察，周级视图用于需求响应和标注产能管理，月级或季度视图用于成本、容量和数据资产价值评估。单一时间尺度无法满足所有角色需求，也容易把短期波动误判为长期趋势。

最后，面板不应无限堆叠。每个视图应保留少数核心指标和明确行动入口。平台健康视图关注是否需要值班处理，数据质量视图关注是否需要暂停或修复数据，业务运营视图关注是否影响模型和产品计划。多余指标可以放入诊断页，而不是占据首页。监控面板的目标不是展示团队能收集多少数据，而是帮助团队更快做出正确判断。

图26-2展示了相应的流程或结构。

图26-2：LLM 数据平台可观测性全景图。

26.5 案例：一次平台事故的复盘¶

26.5.1 事故概述¶

时间：2024年5月某周二，13:47

告警级别：P1（后升级为 P0）

事故描述：数据平台质量监控系统发出告警：核心训练数据集dialogue-sft-zh的"医疗健康"类别覆盖率从正常水平的 8.2% 骤降至 1.3%，触发 P1 告警。在调查过程中发现，同类问题影响了过去 6 天的所有数据批次，升级为 P0。

影响范围：6 天的增量数据（约 42 万条）中，医疗健康类样本减少约 35 万条；三个正在使用这批数据训练的实验受到影响。

事故发生时，平台层面的作业状态全部正常。爬虫任务按时运行，清洗任务没有失败，数据写入也没有异常。最初触发问题的是类别覆盖率指标，而不是任务失败告警。这一点典型：数据事故并不总以系统故障的形式出现，而是以数据资产质量退化的形式出现。如果团队只看调度状态，这次事故可能会继续隐藏，直到模型在医疗健康类问答上表现下降。

这次事故还具有明显的滞后性。代码变更发生在 5 月 15 日，告警触发在 5 月 21 日，中间经过了多个批次。每个单批次的下降都没有达到原有告警阈值，但累积趋势已经较为明显。事故暴露后，团队意识到原有监控只关注单点异常，缺少趋势性检测，也缺少对关键类别覆盖率的错误预算管理。

表26-6汇总了本节的关键对象、工程要点与复核口径。

表 26-6：案例时间线。

时间	事件
5月15日 09:00	数据工程师 Zhang 对爬虫过滤规则进行了一次"小优化"：将过滤规则中的关键词列表从外部 JSON 文件改为硬编码，目的是减少配置文件依赖
5月15日 09:15	该变更通过了基础单元测试（测试样本中不包含医疗健康类别）
5月15日 10:00	变更部署到生产环境，后续所有批次都使用新逻辑处理
5月21日 13:47	质量监控系统触发 P1 告警：医疗健康类别覆盖率异常
5月21日 14:05	值班工程师 Li 接到告警，开始调查
5月21日 14:30	Li 通过血缘图定位到问题数据批次，对比代码变更历史，怀疑与 5/15 的变更有关
5月21日 14:45	Zhang 确认：硬编码过程中，医疗健康类的关键词列表遗漏了几个关键词，导致该类别 80% 以上的样本被误过滤
5月21日 14:50	事故升级为 P0，通知算法团队暂停使用受影响的数据批次
5月21日 16:30	修复变更部署，重新处理受影响的 6 天数据
5月22日 08:00	数据重新处理完成，质量指标恢复正常，事故解除

缺陷潜伏/影响时长：从 5 月 15 日 10:00 错误变更部署，到 5 月 22 日 08:00 数据重新处理完成并解除事故，约 6 天 22 小时。这个口径反映错误数据实际影响窗口，也反映监控发现能力的不足。

告警后恢复时长：从 5 月 21 日 13:47 质量监控触发 P1 告警，到 5 月 22 日 08:00 事故解除，约 18 小时 13 分钟。这个口径反映团队在告警触发后的响应、定位、修复和重新处理效率。

这两个时间口径都重要。前者衡量缺陷潜伏和影响时长，后者衡量告警后的恢复效率。一个可观测性体系成熟的团队，不仅要缩短平均恢复时间，也要缩短平均发现时间。对于数据平台而言，平均发现时间往往比平均恢复时间更难优化，因为数据错误可能在统计上缓慢累积。

时间线还显示，根因定位主要依赖血缘和代码变更记录。值班工程师没有逐个检查所有批次，而是先通过血缘图确认受影响数据集的上游处理链路，再对比最近一周的规则变更。这说明可观测性系统不仅要能告警，还要能支撑有方向的排查。没有血缘和变更记录，团队可能需要人工比对大量日志和输出文件，定位时间会显著增加。

26.5.2 根因分析¶

直接原因：代码变更将过滤关键词从外部配置文件改为硬编码时，遗漏了医疗健康类别的部分关键词。

根本原因（系统性问题）：

测试覆盖不足：代码变更的测试样本不包含医疗健康类别数据，导致测试无法发现回归问题。
监控检测延迟：质量监控系统每6小时运行一次批次级别的检查，且告警规则基于单批次的偏离阈值，对于渐进性变化（每批次减少量不显著）的检测不够灵敏，直到问题累积6天后才触发告警。
变更审批不严格：这次变更被认为是"小优化"，没有经过完整的变更审批流程（没有检查影响范围、没有设置回滚点）。

从更深层看，这次事故暴露了三个组织假设。第一，团队假设"配置改硬编码"属于低风险工程优化，但实际上它改变了过滤规则的维护方式，也改变了质量风险边界。第二，团队假设单元测试通过即可发布，但测试样本没有覆盖所有关键业务类别，无法代表真实训练数据分布。第三，团队假设批次级阈值足以发现覆盖率异常，却忽略了慢性下降和类别稀释。

这些假设并非某个工程师个人失误，而是流程设计不足。成熟复盘应避免把事故简单归因于"开发不小心"。更有价值的问题是：为什么一个会影响关键类别覆盖率的变更被归类为小变更？为什么测试集没有覆盖业务类别？为什么监控没有识别连续下降？为什么变更审批没有要求影响分析？这些问题指向系统改进，而不是个人归责。

根因分析还需要区分直接原因、促成因素和未被触发的防线。直接原因是关键词遗漏；促成因素包括测试覆盖不足、审批过轻和趋势告警缺失；未被触发的防线则包括数据质量冒烟测试、关键类别回归测试和变更影响评估。把防线逐一列出，可以帮助团队判断应该补哪一层防护，而不是在事故后随意增加规则。

26.5.3 修复措施¶

短期（已执行）：

修复关键词列表，重新处理受影响数据
通知算法团队更新实验中的数据集版本

中期（2周内）：

测试数据集中增加医疗健康类别的代表性样本，覆盖所有业务类别
质量监控系统增加"趋势告警"规则：连续3批次某类别覆盖率下降超过 20%，触发告警

长期（1个月内）：

建立数据变更分级制度：影响过滤规则的变更必须经过完整审批流程
在 CI/CD 流水线中增加数据质量冒烟测试（smoke test）：每次代码变更后，自动运行一个小型数据集的质量指标检查。生产级 ML 平台通常把数据验证、模型验证和流水线元数据作为持续交付链路的一部分，而不是上线后的附加检查（Baylor et al. 2017; Breck et al. 2019）

修复措施的优先级遵循先止损、再恢复、后预防的顺序。短期动作解决已经产生的错误数据，中期动作提高检测能力，长期动作改变变更流程。这样的分层很重要，因为事故处理中常见的误区是只修代码而不修流程，或者只制定流程而不处理受影响数据。数据事故必须同时处理"未来不再发生"和"已经发生的影响如何消除"两个问题。

重新处理受影响数据时，团队还保留了原错误批次的隔离副本，用于复盘和测试。隔离副本不能再进入训练集，但可以作为回归测试样本，验证未来过滤规则是否会再次误删医疗健康类数据。把事故样本转化为测试资产，是数据平台持续改进的重要方式。每一次事故都应提高下一次检测能力，而不是只恢复到事故前状态。

团队还要求三个受影响实验重新绑定修复后的数据版本，并在实验卡片中记录事故影响。这样做是为了避免历史实验结论被误读。如果某个实验使用了受影响数据却没有标记，未来算法团队可能把模型效果下降归因于训练策略，而不是数据覆盖不足。数据事故的影响记录必须进入实验追踪系统，才能支撑长期复盘。

26.5.4 事故复盘模板¶

以下是标准化的事故复盘模板，适用于所有 P0/P1 级数据事故。有效复盘应关注系统性改进，而不是个体归责；这也是 SRE 事故复盘和韧性工程实践反复强调的原则（Beyer et al. 2016; Beyer et al. 2018）：

表26-7汇总了本节的关键对象、工程要点与复核口径。

表 26-7：事故复盘报告。

字段	内容
事故 ID	INC-2024-0521-001
事故级别	P0
影响时间	2024-05-15 10:00 ~ 2024-05-22 08:00（共7天）
事故负责人	Li（值班工程师）
参与人员	Zhang（数据工程师）、算法团队代表
事故描述	医疗健康类样本因过滤规则变更被大量误删，6天数据受影响
影响范围	42万条增量数据；3个进行中的训练实验
根本原因	代码变更遗漏关键词 + 测试覆盖不足 + 变更审批流程不完善
响应时间线	见上文时间线
修复措施	短期/中期/长期措施见上文
预防措施	更新测试数据集；增加趋势告警；建立变更分级制度
经验教训	任何影响过滤逻辑的变更都需要完整测试覆盖

事故复盘模板应在所有 P0/P1 事故中保持一致，但内容不能模板化。尤其是"根本原因"和"预防措施"两栏，必须写到可执行层面。例如，"加强测试"不是合格的预防措施，"在过滤规则 CI 中加入覆盖全部业务类别的 200 条固定回归样本，并由质量负责人每月复核样本集"才是可执行措施。"提高监控灵敏度"也不是合格表述，"新增连续三批覆盖率下降超过 20% 的趋势告警，告警路由到数据质量值班人"才可验收。

复盘还应记录哪些信号本可以更早发现事故。例如，在本案例中，5 月 16 日起医疗健康类样本覆盖率已经连续低于过去 30 天均值，但没有触发趋势告警；5 月 17 日某个医疗相关关键词过滤比例异常上升，但该指标只在诊断面板中展示，没有进入告警规则。这些"差一点发现"的信号有价值，它们能帮助团队改进告警策略。

事故复盘结束后，应把行动项纳入问题池，而不是停留在复盘文档中。每个行动项都需要负责人、截止时间、验收方式和关联事故 ID。下次月度运营评审时，应检查行动项是否关闭，以及关闭后是否真的降低了风险。没有行动项跟踪的复盘，容易成为一次性会议；有跟踪机制的复盘，才会转化为平台能力。

26.5.5 关键指标改进¶

通过这次事故的整改，团队完善了以下监控能力：

表26-8汇总了本节的关键对象、工程要点与复核口径。

表 26-8：指标改善。

改进项	改进前	改进后
类别覆盖率异常检测延迟	约 6 天（本次事故中需累积足够多的偏差才触发告警）	目标 < 6 小时（整改后新增趋势告警的目标发现时间）
变更导致的数据质量回归发现时间	平均 4 天	< 2小时（CI 冒烟测试）
代码变更有质量测试覆盖率	约 35%	> 85%

指标改善并不意味着风险完全消失。表中的 < 6 小时 是整改后新增趋势告警所设定的目标发现时间，并不是本次事故的实际发现时间；本次事故实际从错误变更部署到告警触发约 6 天。趋势告警的目标是把类似覆盖率异常从"多天后发现"提前到"数小时内发现"，但如果业务类别定义发生变化，仍可能需要人工复核；CI 冒烟测试能发现代表性样本上的回归，但不能覆盖所有真实数据分布；变更测试覆盖率提高，也不能替代代码评审和影响分析。因此，复盘后的指标应被理解为防线增强，而不是事故类型被彻底消灭。

案例的核心启示是，数据平台可观测性必须覆盖"变化"。很多事故并非来自系统突然失败，而是来自规则、依赖、数据源、业务类别和使用方式的细微变化。可观测性系统如果只监控静态状态，就无法发现这些变化；如果能够把指标、日志、血缘、变更和实验关联起来，就能把变化转化为可解释信号。

从落地角度看，数据平台可观测性建设不宜一次性追求完整体系。较稳妥的路径是先覆盖高价值、高风险的数据链路，再逐步扩展到所有数据资产。对于早期团队，首要目标是把核心训练集的任务状态、质量指标和版本血缘记录下来；对于中型团队，重点是建立告警分级、SLO、事故响应和面板下钻能力；对于平台化团队，则需要进一步建设审计日志、成本可观测、容量预测、跨团队运营视图和数据资产健康档案。

当然，可观测性建设也应遵循风险优先原则。并不是所有数据集都需要同等监控强度。正式训练集、关键评测集、线上反馈数据和合规敏感数据，应拥有更严格的 SLO、告警和审计；探索性实验数据可以采用较轻量的监控，但必须明确其不可进入正式链路；临时分析数据则可以只保留基本访问和生命周期记录。分层监控能够避免平台团队被低价值信号淹没，也能把资源集中到真正影响模型和业务的对象上。

表26-9汇总了本节的关键对象、工程要点与复核口径。

表 26-9：数据平台可观测性建设阶段与验收问题。

建设阶段	主要目标	关键能力	验收问题
基础阶段	让平台问题可见	任务状态、基础日志、质量摘要、版本记录	能否知道核心数据集何时产出、是否通过基本质量检查
标准阶段	让数据问题可诊断	三层指标、Trace、血缘、告警分级、问题池	能否从告警追溯到受影响批次、来源和处理步骤
运营阶段	让风险可管理	数据集 SLO、事故响应、复盘闭环、运营面板	能否提前发现趋势性质量退化并组织跨团队处置
治理阶段	让资产可审计和可经营	审计日志、权限记录、成本面板、容量预测、健康档案	能否解释数据资产的质量、成本、风险和业务价值

参考数据平台可观测性建设阶段表，若基础阶段尚未完成，团队不应急于建设复杂运营面板；若标准阶段缺少血缘和 Trace，告警触发后仍会难以排查；若运营阶段没有复盘闭环，事故会反复出现；若治理阶段缺少成本和审计视图，平台价值很难向管理层解释。每个阶段都应产生可验证的能力，而不是只上线新的监控工具。

在实施过程中，最容易被低估的是指标口径治理。一个指标从采集、计算、聚合到展示，会经过多个系统。如果口径不清，面板就会制造新的歧义。例如，"数据吞吐量"究竟按原始样本数、清洗后样本数还是进入训练集的样本数计算；"标注一致性"是按任务平均、按标注员平均还是按样本加权平均；"数据新鲜度"是按采集时间、入库时间还是业务事件时间计算。口径不清时，团队会围绕数字争论，而不是围绕问题行动。因此，每个核心指标都应配备指标说明书。说明书至少包括指标定义、计算公式、数据来源、更新时间、负责人、阈值含义、适用场景和已知限制。指标说明书不需要冗长，但必须可查询、可版本化。指标口径发生变化时，应记录变更原因和影响范围，避免趋势图在不知情的情况下失去可比性。

另一个关键问题是采样策略。为了控制成本，日志和 Trace 往往不能全量长期保存。但采样如果设计不当，就会错过关键异常。普通低风险任务可以按比例采样，高风险数据集、P0/P1 事故期间、异常批次和合规敏感操作则应提高采样率或全量保留。采样策略也应能动态调整：当某个指标进入预警状态时，系统自动提高相关链路日志和 Trace 的保留粒度，为后续排查准备证据。进一步，这种可观测性应纳入数据变更流程。任何影响数据内容、过滤逻辑、采样策略、标注指南或质量阈值的变更，都应自动关联到后续监控窗口。变更后的一段时间内，相关指标应进入强化观察状态，面板中也应标记"近期存在变更"。这样，指标波动发生时，工程师可以快速判断是否与变更有关。没有变更上下文的监控，容易把人为调整误判为自然波动，也容易把真实事故解释为正常变化。

可观测性建设还需要明确团队分工。平台工程师负责采集基础设施指标、维护日志和 Trace 管道、保障面板和告警系统稳定；数据工程师负责定义批次级质量指标、处理规则变更和血缘记录；质量评估员负责解释质量指标、设计抽检规则和维护人工评估基准；数据 Owner 负责确定数据集 SLO、告警优先级和业务影响判断；算法团队负责反馈模型效果变化和错误样本分布；安全合规团队负责审计日志、访问控制和敏感数据风险。没有清晰分工，可观测性系统会出现"有人看到指标，但无人负责行动"的问题。这些分工应写入日常流程，而不是只在事故中临时确认。每个核心数据集都应有数据 Owner，每个关键 SLO 都应有指标负责人，每个 P0/P1 告警都应有默认值班角色，每个运营面板都应有维护人。指标无人维护时，阈值会逐渐过期；面板无人维护时，展示内容会逐渐失真；告警无人负责时，团队会形成告警疲劳。可观测性本身也需要治理。

对于管理者而言，可观测性投资的价值不只体现在事故减少，还体现在决策质量提高。容量预测让团队能提前安排资源，成本监控让团队理解投入产出，数据集 SLO 让团队知道哪些资产稳定可靠，血缘和审计让团队能够解释风险边界。可观测性把数据平台从"能运行的系统"提升为"可经营的资产体系"。

不过，可观测性也有边界。监控系统只能观察已定义或可推断的信号，不能自动理解所有业务语义。某些问题仍需要业务专家、质量评估员和算法工程师共同判断。例如，某类历史政策数据是否应被保留，某种用户反馈是否代表真实需求，某个安全拒答边界是否合理，这些问题无法完全由指标决定。成熟的数据平台应把可观测性视为决策证据，而不是决策替代品。

最后，团队应定期演练数据事故。演练可以选择一个模拟场景，例如关键数据源断供、评测集污染、过滤规则误删、标注一致性下降或合规数据误入训练集。通过演练，团队可以验证告警是否触发、路由是否正确、排障手册是否可执行、血缘查询是否有效、沟通机制是否顺畅。没有演练的事故响应流程，往往在真实事故中才暴露缺陷。演练结束后，应像真实事故一样进行复盘。复盘不只检查技术系统，也检查人员响应、文档可用性、权限是否足够、面板是否清晰、告警上下文是否完整。通过持续演练，数据平台可观测性才能从"有监控"走向"能应对"。

本章小结¶

本章系统构建了 LLM 数据平台的可观测性体系，覆盖监控、告警、归因和运营四个维度。

在基础认知层面，我们厘清了调度成功、任务成功与数据正确三个层次的区别，分析了 LLM 数据平台特有的五类"静默失效"故障模式（语义漂移、过滤过度、依赖漂移、标注衰减、数据孤岛），以及数据质量问题滞后暴露的根本原因。

在指标体系层面，我们建立了任务指标、质量指标和业务指标的三层体系，讨论了日志、Trace、审计日志和血缘四种可观测性工具的分工与组合，以及基于 SLO 的数据资产健康监控设计。

在告警与应急层面，我们设计了四级告警体系（P0-P3）和对应的处置动作，给出了数据平台异常归因的四步决策树，以及标准化的事故响应和复盘流程。

在运营管理层面，我们讨论了处理量、存储量和标注量的三维容量预测方法，成本监控的分类与预警规则，以及面向不同受众的三维运营面板设计。

最后，通过一次真实的平台事故完整复盘，展示了可观测性体系如何在实际中把问题发现时间从 6 天压缩到 6 小时。

数据平台的可观测性不是一次性建设就能完成的，而是随着平台的演进和事故经验的积累，不断完善的过程。每一次事故都是一次系统性提升监控能力的机会。

延伸阅读¶

可观测性工程经典参考

Beyer 等人编写的《Site Reliability Engineering》（Google SRE Book）是 SRE 领域的奠基之作，其中关于 SLO 设计和事故管理的章节，对数据平台可观测性体系的设计有直接的参考价值。Kleppmann 的《Designing Data-Intensive Applications》（数据密集型应用系统设计）中，关于可靠性和可维护性的讨论，提供了更底层的工程思维框架。

开源数据质量工具

Great Expectations 是目前最成熟的数据质量测试框架，支持定义"数据期望"（Data Expectations）并在管线中自动运行检查，与 Airflow、dbt 等工具集成良好。Apache Griffin 是专为大数据场景设计的数据质量工具，支持批处理和流处理两种模式的质量监控。Evidently AI 是专注于 ML 数据和模型监控的开源库，提供了可直接接入的数据漂移检测和模型性能监控组件。

事故管理工具

PagerDuty 是业界最广泛使用的事故响应工具，支持多级告警路由、值班排班和事故工单管理。Opsgenie 是 Atlassian 旗下的事故管理平台，与 Jira 深度集成，适合已经使用 Atlassian 生态的团队。

参考文献¶

Amershi S, Begel A, Bird C, DeLine R, Gall H, Kamar E, Nagappan N, Nushi B, Zimmermann T (2019) Software Engineering for Machine Learning: A Case Study. In: Proceedings of the 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), pp 291-300. https://doi.org/10.1109/icse-seip.2019.00042.

Baylor D, Breck E, Cheng H-T, Fiedel N, Foo C Y, Haque Z, Haykal S, Ispir M, Jain V, Koc L, Koo C Y, Lew L, Mewald C, Modi A N, Polyzotis N, Ramesh S, Roy S, Whang S E, Wicke M, Wilkiewicz J, Zhang X, Zinkevich M (2017) TFX: A TensorFlow-Based Production-Scale Machine Learning Platform. In: Proceedings of the 23rd ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, pp 1387-1395.

Beyer B, Jones C, Petoff J, Murphy N R (eds.) (2016) Site Reliability Engineering: How Google Runs Production Systems. O'Reilly Media.

Beyer B, Murphy N R, Rensin D K, Kawahara K, Thorne S (eds.) (2018) The Site Reliability Workbook: Practical Ways to Implement SRE. O'Reilly Media.

Breck E, Cai S, Nielsen E, Salib M, Sculley D (2017) The ML Test Score: A Rubric for ML Production Readiness and Technical Debt Reduction. In: IEEE International Conference on Big Data, pp 1123-1132.

Breck E, Polyzotis N, Roy S, Whang S E, Zinkevich M (2019) Data Validation for Machine Learning. In: Proceedings of Machine Learning and Systems 1, pp 334-347.

Dean J, Barroso L A (2013) The Tail at Scale. Communications of the ACM 56(2):74-80. https://doi.org/10.1145/2408776.2408794.

Hellerstein J M, Sreekanti V, Gonzalez J E, Dalton J, Dey A, Nag S, Ramachandran K, Arora S, Bhattacharyya A, Das S, Donsky A, Fierro G, Kumar C, Mazzariol M, Narayanan S, Parameswaran A, Rahman T, Shah R, She C, Storey M, Turman C, Wu E (2017) Ground: A Data Context Service. In: Proceedings of CIDR.

Kleppmann M (2017) Designing Data-Intensive Applications. O'Reilly Media.

Kreuzberger D, Kühl N, Hirschl S (2023) Machine Learning Operations (MLOps): Overview, Definition, and Architecture. IEEE Access 11:31866-31879. arXiv:2205.02302.

National Institute of Standards and Technology (2006) Guide to Computer Security Log Management. NIST Special Publication 800-92. https://doi.org/10.6028/nist.sp.800-92.

Nygard M T (2018) Release It!: Design and Deploy Production-Ready Software, 2nd Edition. Pragmatic Bookshelf.

Oliner A, Stearley J (2007) What Supercomputers Say: A Study of Five System Logs. In: Proceedings of the 37th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), pp 575-584.

OpenTelemetry Authors (2024) OpenTelemetry Specification. Available at: https://opentelemetry.io/docs/specs/.

Polyzotis N, Roy S, Whang S E, Zinkevich M (2017) Data Management Challenges in Production Machine Learning. In: Proceedings of the 2017 ACM International Conference on Management of Data (SIGMOD), pp 1723-1726.

Sambasivan N, Kapania S, Highfill H, Akrong D, Paritosh P, Aroyo L M (2021) "Everyone wants to do the model work, not the data work": Data Cascades in High-Stakes AI. In: Proceedings of the 2021 CHI Conference on Human Factors in Computing Systems, pp 1-15. https://doi.org/10.1145/3411764.3445518.

Sculley D, Holt G, Golovin D, Davydov E, Phillips T, Ebner D, Chaudhary V, Young M, Crespo J-F, Dennison D (2015) Hidden Technical Debt in Machine Learning Systems. In: Advances in Neural Information Processing Systems 28, pp 2503-2511.

Sigelman B H, Barroso L A, Burrows M, Stephenson P, Moshchuk A, Osina D, Fikes J, Miller R (2010) Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. Google Technical Report.

Turnbull J (2014) The Art of Monitoring. James Turnbull.

Xu W, Huang L, Fox A, Patterson D, Jordan M I (2009) Detecting Large-Scale System Problems by Mining Console Logs. In: Proceedings of the ACM SIGOPS 22nd Symposium on Operating Systems Principles (SOSP), pp 117-132. https://doi.org/10.1145/1629575.1629587.