4. 巡检体系总览：归因稳定性巡检的目标、巡检的四大维度、巡检频率与触发机制
归因稳定性巡检不是一次性的“体检”，而是一套持续运行的监控体系。本章从顶层视角出发，明确巡检要解决的核心问题、覆盖的检查范围以及执行节奏，为后续各维度的深度实战打下框架基础。
4.1 巡检的核心目标
归因稳定性巡检的最终目的是保障归因结果的准确、可复现与可解释。具体可拆解为三个子目标：
- 准确性：归因逻辑与数据源一致，计算结果符合业务预期。
- 可复现性：相同输入在任意时间点重跑，结果保持一致。
- 可解释性：当结果出现异常时，能快速定位到根因（数据源、计算逻辑或环境）。
巡检 vs. 监控：监控通常关注“是否可用”（如任务是否失败），而巡检更关注“结果是否合理”。归因巡检是数据质量保障体系中针对归因场景的专项深化。
4.2 巡检的四大维度
我们将巡检范围划分为四个相互独立的维度，每个维度对应一类常见的稳定性风险。下表总结了各维度的核心检查项与典型风险场景：
| 维度 | 核心检查项 | 典型风险场景 |
|---|---|---|
| 数据源 | 上游表分区完整性、字段空值率、数据延迟、Schema 变更 | 埋点日志丢失、业务库字段类型变更导致归因失败 |
| 计算逻辑 | 归因模型参数、窗口期配置、去重逻辑、回溯代码版本 | 窗口期被误修改、代码上线未同步导致结果漂移 |
| 环境 | Spark 配置参数、资源队列、依赖组件版本、Shuffle 稳定性 | Executor 内存不足触发 OOM、动态资源分配导致结果不一致 |
| 结果校验 | 汇总级指标对比、明细级抽样、历史趋势、跨环境一致性 | 某渠道归因转化数突增、生产与预发结果差异超过阈值 |
4.3 巡检频率与触发机制
巡检并非所有维度都按相同频率执行。根据数据时效性要求和风险等级，我们设计了定时巡检 + 事件触发的双模机制。
4.3.1 定时巡检频率
| 巡检维度 | 默认频率 | 适用场景 |
|---|---|---|
| 数据源 | 每批次（小时级） | 实时/准实时归因任务，需在数据到达后立即校验 |
| 计算逻辑 | 每日一次 | 日级归因任务，通常在凌晨调度完成后执行 |
| 环境 | 每周一次 | 集群配置变更后或定期健康检查 |
| 结果校验 | 每日一次 + 周度深度校验 | 日级结果快照对比，周度进行明细级抽样 |
4.3.2 事件触发机制
以下事件发生时，会立即触发对应维度的巡检，不受定时周期限制：
- 数据源 Schema 变更：上游表新增/删除字段、字段类型修改，触发数据源维度巡检。
- 归因代码发布：Spark 作业代码版本更新，触发计算逻辑维度巡检。
- 集群资源调整：Executor 数量、内存配置、动态分配策略变更，触发环境维度巡检。
- 结果异常告警：归因结果偏离历史基线超过 3σ，触发结果校验维度巡检。
注意：事件触发巡检的结果需要与最近一次定时巡检结果合并分析，避免因重复告警导致运维疲劳。建议在告警系统中设置 30 分钟的静默期。
4.4 巡检体系落地要点
在实际搭建巡检体系时，建议遵循以下原则：
- 先核心后外围：优先覆盖核心归因模型（如 last-click、multi-touch），再扩展到实验性模型。
- 阈值动态化：数据源空值率、结果偏差等阈值应根据历史数据自动计算，避免硬编码。
- 巡检结果可回溯：每次巡检的输入、输出、配置快照都应持久化，便于事后审计。
- 告警分级：P0 级（结果错误）直接通知值班人员；P1 级（数据延迟）发送到工作群；P2 级（配置变更）记录日志。
实战建议：在 Spark 作业中嵌入巡检探针，利用 Accumulator 或 Metrics 系统实时上报数据源质量指标，与离线巡检形成互补。