数据质量SLA起草助手

跨部门指标数据质量服务协议（SLA）

1. 目的与适用范围
- 目的：为跨部门共享指标（经营、财务、客户、运营等）的生产、交付与使用建立统一的数据质量标准、监控与响应机制，确保指标的准确性、完整性、及时性、一致性、唯一性与有效性。
- 适用范围：纳入公司指标目录的所有跨部门公共指标及其数据管道、数据集、数据资产标签和相关元数据。
- 生效对象：数据生产部门、数据平台与数据质量团队、各指标使用部门（业务、财务、风控、运营、产品等）。

2. 角色与职责
- 数据生产方（源系统/业务域）：负责源数据的正确产生、数据合同遵循、变更提前沟通、提供对账控制总量与业务规则。
- 数据平台团队：负责数据管道稳定性、元数据管理、数据访问控制、作业编排与重试机制。
- 数据质量团队（服务提供方）：制定质量标准与检测规则、实施监控与告警、执行事件响应与根因分析、组织修复与防再发措施、发布质量报告。
- 指标所有者（各部门）：定义指标口径与计算规则、确认基准（source-of-truth）、参与上线验收与变更评审、对质量问题影响评级及优先级分配。
- 数据治理委员会：裁决质量争议、批准重大变更、审议豁免与风险接受、周期性复审SLA。

3. 术语与定义
- 指标：按统一口径计算的可复用度量，具备唯一标识、计算逻辑、来源、适用范围与责任人。
- 数据质量维度：准确性、完整性、及时性、一致性、唯一性、有效性。
- SLI（服务等级指标）：用于衡量数据质量维度的量化指标。
- SLO（服务等级目标）：对SLI设定的目标值。
- SLA（服务协议）：对服务范围、目标、测量、响应与报告的综合承诺。
- 指标分级：Tier-0（关键/合规）、Tier-1（核心业务）、Tier-2（一般运营）。

4. 服务时间与支持渠道
- Tier-0：7×24监控与告警；事件响应7×24。
- Tier-1/2：工作日08:00–20:00监控与告警；非工作时段降级为关键事件响应。
- 支持渠道：统一工单系统（事件与变更）、即时沟通频道（应急协调）、邮件（变更与通报）。
- 日常交付窗口：日指标在T+1 09:00前交付；小时级在每小时+15分钟内；周/月指标在周期结束后1个工作日内。

5. 指标分级与质量目标（SLO）
- Tier-0（关键/合规）
  - 准确性：相对误差≤0.1%，或规则通过率≥99.9%。
  - 完整性：交付记录数/预期记录数≥99.7%（以控制总量、分区计数或源系统业务事件为准）。
  - 及时性：95%周期按承诺交付时点前完成；99%在+1小时容差内完成。
  - 一致性：跨源或版本对账差异≤0.2%（计数/金额）；口径一致性变更需冻结与评审。
  - 唯一性：重复记录率≤0.05%（主键或业务唯一键）。
  - 有效性：规则（类型、范围、字典、参照完整性）通过率≥99.7%。
- Tier-1（核心业务）
  - 准确性≤0.5%；完整性≥99.0%；及时性：90%按时、95%+1小时；一致性≤0.5%；唯一性≤0.1%；有效性≥99.0%。
- Tier-2（一般运营）
  - 准确性≤1.0%；完整性≥98.0%；及时性：85%按时、90%+1小时；一致性≤1.0%；唯一性≤0.2%；有效性≥98.0%。

6. SLI计算与测量方法
- 评估对象：以分区（天/小时）、表、指标实例为单位计算SLI；月度汇总用于SLO达成评估。
- 准确性（Accuracy）
  - 指标相对误差 = |交付值 − 基准值| / 基准值。
  - 规则通过率 = 通过记录数 / 被评估记录数。
- 完整性（Completeness）= 交付记录数 / 预期记录数（来源控制总量、上游事件计数、分区期望列表）。
- 及时性（Timeliness）= 按承诺时点前成功交付的周期数 / 总周期数。
- 一致性（Consistency）= 1 −（跨源或版本差异量 / 对账基数），或差异占比阈值比较。
- 唯一性（Uniqueness）= 1 −（重复主键或业务唯一键记录数 / 总记录数）。
- 有效性（Validity）= 通过所有校验规则的记录数 / 总记录数。
- 采样与覆盖：Tier-0全量校验；Tier-1优先高风险字段全量+增量采样；Tier-2采用分层随机采样（≥10%或≥10万条，以较大者为准）。
- 告警抑制与确认：为降低误报，非Tier-0告警可设置2次连续失败阈值；Tier-0实时告警且不抑制。

7. 监控与校验规则
- 结构与模式：Schema变更检测、字段级非空/类型/长度、字典值范围、参照完整性（外键）、主键唯一。
- 业务规则：口径计算前置校验、状态机合法性、金额平衡（借贷平衡、总额=分项和）、不可逆约束（已结算不可变更）。
- 对账与调和：源系统控制总量、跨系统计数/金额对账、期初期末余额一致性。
- 漂移监控：分布统计（均值/方差/分位数）与历史窗口对比，KS/PSI等漂移指标告警（Tier-0仅提示，不自动阻断）。
- 补数据与重算：定义回补策略（按分区重算、按事件重放），记录回补影响范围与再验证结果。

8. 交付与变更管理（数据合同）
- 上线验收：必须提供指标口径文档、字段字典、依赖与血缘、基准对账方法、质量规则清单与测试报告。
- 变更类型：
  - 非破坏性变更（新增字段、性能优化）：需提前≥3个工作日通知。
  - 破坏性变更（字段删除/重命名、数据类型变更、口径调整）：Tier-0需≥10个工作日通知与冻结窗口；Tier-1≥5天；Tier-2≥3天。
- 版本化与兼容：破坏性变更需并行双轨运行≥1个周期，提供映射与迁移指南；发布变更通告与影响评估。
- 依赖管理：上游停机或重大事件需在1小时内通报影响范围与预估恢复时间。

9. 事件管理与响应
- 严重级别定义：
  - Sev-1（阻断/合规风险）：Tier-0指标无法交付或质量显著越界（准确性/完整性/一致性未达标且影响决策/合规）。
  - Sev-2（重大影响）：关键指标部分分区异常、延迟超过+2小时、跨源差异超阈。
  - Sev-3（一般影响）：局部有效性/唯一性轻微越界、不影响关键决策。
- 响应与修复时限（工作时段；Tier-0为7×24）：
  - Sev-1：确认≤15分钟；初步缓解≤2小时；根因与修复≤4小时；事后报告（RCA）≤1个工作日。
  - Sev-2：确认≤1小时；缓解≤6小时；修复≤12小时；RCA≤2个工作日。
  - Sev-3：确认≤4小时；修复≤3个工作日；RCA按周汇总。
- 沟通与通告：创建工单、标注影响指标与部门、预计恢复时间、将临时措施与风险明示；重大事件需邮件通报管理层。
- 回溯与更正：当质量问题导致指标错误发布，需在发现后≤24小时完成更正与替换，并保留版本与更正说明。

10. 报告与审计
- 日/周质量报告：包含各维度SLI达成情况、未达标事件清单、已知风险与缓解计划。
- 月度与季度评审：质量KPI（SLO达成率）、重复问题复盘、规则覆盖率提升计划。
- 审计追踪：保留监控结果、事件记录、RCA与变更文档≥12个月；重要指标采用不可篡改日志。

11. 例外与豁免
- 部门可提交SLO豁免申请，需包含：豁免维度、持续时长、业务影响、风险接受方与补偿措施；由数据治理委员会审批。
- 暂时风险接受需设定到期复审，并在报告中标识。

12. 数据安全与合规（与数据质量相关的最低要求）
- 访问控制：基于角色的访问与最小权限原则；敏感字段脱敏校验不降低有效性评估准确性。
- 合规：合规类指标（监管/财务）必须执行Tier-0标准与双人复核；任何口径变更需合规评审。

13. 违约与补救
- 若连续两个评审周期SLO未达成（同一维度、同一Tier），服务提供方需提交整改计划与时间表；关键指标需引入额外控制（双源对账、加强规则）。
- 对因服务未达标导致的重大业务影响，执行管理层审查与专项改进（包括资源保障、流程优化）。

14. 生效、修订与版本
- 本SLA自发布之日起生效，至少每半年复审一次；重大组织或系统变更需临时修订。
- 文档版本化管理，历史版本可追溯。

15. 附：验收与质量门槛清单（用于新指标上线）
- 指标定义完整：名称、唯一ID、业务口径、计算逻辑、时间粒度、维度枚举、适用范围、所有者。
- 数据血缘与依赖：来源系统、表/主题、关键字段、上游/下游列表。
- 基准与对账方法：source-of-truth说明、控制总量来源、允许误差界限。
- 质量规则配置：维度规则、异常阈值、灰度范围、告警策略。
- 监控覆盖：分区与字段覆盖率、抽样策略、回补策略。
- 发布准备：仪表盘/接口说明、使用指南、变更回滚方案、演练记录。
- 上线验收：试运行≥1个完整周期，质量SLI达标且无Sev-1事件。

本协议旨在以可度量、可验证的标准保障跨部门指标的数据质量。所有承诺均以定义明确的SLI/SLO为依据，并通过规范的监控、事件管理与变更流程确保持续达成与改进。

Data Quality Service Level Agreement (SLA) for Order ETL

1) Purpose
- Establish measurable data quality, timeliness, and reliability commitments for the Order ETL service.
- Define monitoring, incident response, remediation, and change management processes to protect downstream analytics and operational use.

2) Scope
- Pipelines: Order ingestion (CDC/stream or batch), transformation, enrichment, and publication to the analytics warehouse and curated marts.
- Environments: Production SLA; lower environments excluded from SLA but must follow the same controls.
- Datasets in scope (canonical names are examples and must be mapped to your environment):
  - Raw landing: raw_orders, raw_order_lines
  - Staging: stg_orders, stg_order_lines
  - Curated: dim_order, fct_order, fct_order_line, order_daily_snapshot
- Sources: Primary order management system and any approved auxiliary sources for enrichment (e.g., customer, product, currency rates).

3) Definitions
- Order: A business transaction with unique order_id per source system, containing header and one or more lines.
- Batch: One scheduled ETL run (for batch mode) or a defined time window (for streaming/CDC aggregation, e.g., 5-minute buckets).
- Mandatory fields (minimum set): order_id, source_system_id, order_date, order_status, customer_id, currency_code; for lines: order_id, line_id, product_id, quantity, unit_price.
- Business day/time: All deadlines stated in UTC unless otherwise specified.
- Error budget: Allowed proportion of SLO non-compliance per calendar month.

4) Service Hours and Schedule
- Processing window:
  - CDC/stream: near-real-time with target end-to-end latency < 15 minutes for 99.9% of events.
  - Daily batch: complete T+0 aggregation and reconciliation by 02:00 UTC for 99.5% of days.
- Maintenance windows: Pre-announced with 48 hours notice; excluded from availability SLO if approved.

5) Data Quality Objectives, Metrics, and Targets
Unless noted, targets apply per batch and are evaluated monthly on a rolling basis.

5.1 Accuracy
- Metric A1 (field-level accuracy): Percentage of records where computed financial amounts match the source within tolerance.
  - Target: ≥ 99.95% records with absolute difference in order_total ≤ 0.01 currency units OR relative difference ≤ 0.05%.
  - Measurement: Recalculate order_total from raw lines and compare to curated totals.
- Metric A2 (derivation correctness): Tax, discount, and net amounts consistent with documented transformation logic.
  - Target: ≥ 99.9% records pass derivation checks.
  - Measurement: Deterministic recomputation and rule-based assertions.

5.2 Completeness
- Metric C1 (record completeness): Percentage of expected records present in curated tables vs. source for the window.
  - Target: ≥ 99.8%.
  - Measurement: Source vs. curated row counts by natural keys and business date.
- Metric C2 (mandatory field population): Percentage of records with non-null mandatory fields.
  - Targets:
    - order_id, source_system_id, order_date: 100%
    - customer_id, order_status, currency_code: ≥ 99.95%
    - line-level mandatory fields: ≥ 99.95%
  - Measurement: Null and empty checks post-staging and pre-publish.

5.3 Timeliness and Freshness
- Metric T1 (CDC latency): P95 end-to-end latency from source commit to curated publish.
  - Target: ≤ 15 minutes for 99.9% of events; ≤ 5 minutes for 95%.
- Metric T2 (daily batch deadline): Completion by 02:00 UTC.
  - Target: ≥ 99.5% of calendar days.
- Metric T3 (freshness watermark): Max age of latest successful watermark.
  - Target: ≤ 15 minutes (CDC) and ≤ 24 hours (daily aggregates).

5.4 Validity and Conformance
- Metric V1 (schema conformance): Records conform to schema, datatypes, and allowed enumerations.
  - Target: 100% of published records; non-conformant records are quarantined.
- Metric V2 (referential integrity): Foreign keys resolve to customer and product dimensions (or valid late-binding placeholders).
  - Target: ≥ 99.9% at publish time; unresolved keys backfilled within 24 hours.

5.5 Uniqueness
- Metric U1 (primary key uniqueness): No duplicate (source_system_id, order_id) in order headers; no duplicate (source_system_id, order_id, line_id) in order lines.
  - Target: 100% uniqueness in curated; ≤ 0.05% in staging with quarantine.
- Metric U2 (idempotency): Re-runs do not create duplicates.
  - Target: 100% of reprocessed batches.

5.6 Consistency and Reconciliation
- Metric R1 (row-count reconciliation vs. source): |curated_count − source_count| / source_count.
  - Target: ≤ 0.2% per batch; ≤ 0.05% monthly average.
- Metric R2 (financial reconciliation): Absolute difference in sum(order_total) and sum(line_amounts).
  - Target: ≤ 0.05% or ≤ equivalent of 100 currency units per day, whichever is smaller.
- Metric R3 (intra-model consistency): Header totals equal aggregated line totals.
  - Target: 100%; discrepancies quarantined.

5.7 Availability and Reliability
- Metric S1 (pipeline run success rate): Successful completion of scheduled runs.
  - Target: ≥ 99.9% monthly (excluding approved maintenance).
- Metric S2 (dataset availability): Curated datasets accessible and queryable.
  - Target: ≥ 99.9% monthly.

6) Measurement and Calculation
- Evaluation windows: Per-batch and aggregated monthly; CDC metrics evaluated on rolling 5-minute windows and daily aggregates.
- Sampling: 100% checks for uniqueness, schema, referential integrity; statistical sampling (≥ 10,000 records or 10%, whichever larger) for high-cost recomputation checks, unless otherwise agreed.
- Golden-source comparisons: Source-of-truth defined per field; when multiple sources exist, precedence order must be documented.
- Late-arriving data: Counted as complete if within late-arrival window (default 24 hours) and backfilled automatically.

7) Controls and Quality Gates
- Ingestion controls:
  - Checkpointing, exactly-once or deduplicated-at-least-once semantics.
  - Raw data immutability; write-once landing zone.
  - File/event completeness validation (counts, sizes, checksums; sequence continuity).
- Transformation controls:
  - Primary/foreign key enforcement.
  - Business rule assertions (e.g., quantity > 0; unit_price ≥ 0; currency_code in ISO 4217 list).
  - Type coercion with safe casting; invalid records routed to quarantine with reasons.
- Publish controls:
  - Pre-publish row-count and financial reconciliation vs. staging.
  - Schema compatibility check (backward compatible by default).
  - Blue/green publish with data drift checks; canary queries on key aggregates.
- Quarantine handling:
  - All rejects written to error tables with reject_reason, rule_name, detected_at, batch_id, and raw payload reference.
  - Automated reprocessing on rule fixes or reference-data updates.

8) Monitoring, Alerting, and Observability
- Metrics emitted for all KPIs in section 5 with labels: environment, dataset, batch_id/window, source_system.
- Alerting thresholds:
  - Page (Severity 1): Missed batch deadline; CDC latency > 30 min P95 for > 15 min; uniqueness breach in curated; reconciliation R2 breach > 0.1%.
  - Ticket (Severity 2): Completeness below target but above 99%; referential integrity dips below 99.9%.
  - Informational (Severity 3): Trend degradation > 20% from 30-day baseline.
- Dashboards: Real-time run status, freshness, counts, and financial aggregates.
- Logs and traces retained for correlation with batch_id and lineage run_id.

9) Incident Management
- Detection to acknowledgement (MTTA): ≤ 10 minutes for Sev1, ≤ 30 minutes for Sev2.
- Resolution time objective (MTTR): Sev1 ≤ 4 hours; Sev2 ≤ 1 business day; Sev3 ≤ 3 business days.
- Communication:
  - Initial incident notice within 30 minutes (Sev1) including impact, scope, provisional workaround.
  - Status updates at least hourly (Sev1) until resolution.
  - Post-incident review (PIR) within 5 business days, with root cause, detected/undetected signals, corrective and preventive actions (CAPA), and error budget impact.

10) Remediation, Backfill, and Rollback
- Automated retries on transient failures with exponential backoff; maximum 3 attempts before page.
- Safe rollback: Versioned datasets support transactionally consistent rollback to prior successful publish.
- Backfills:
  - Authorized with change request; executed in off-peak windows when possible.
  - Must preserve idempotency, lineage, and history (SCD strategy documented).
- Data corrections:
  - Correct at the earliest point in the pipeline; prefer fix-forward with deterministic reprocessing.
  - All corrections must be auditable with who/when/why and before/after diffs.

11) Change Management and Schema Evolution
- Changes require a Request for Change (RFC) with:
  - Description, rationale, risk assessment, rollout plan, and rollback plan.
  - Data contract updates and impact analysis to downstream consumers.
- Backward compatibility:
  - Additive schema changes allowed with ≥ 90-day deprecation window for removals/renames.
  - Breaking changes require stakeholder approval and coordinated cutover.
- Validation in non-prod with production-like data samples before promotion.
- Versioning:
  - Semantic versioning for data contracts (e.g., v1.2.0).
  - Changelogs published to data catalog.

12) Data Lineage and Catalog
- End-to-end lineage captured: source → raw → staging → curated, including transformation nodes and quality gates.
- Data assets documented with:
  - Definitions, owners, SLAs, refresh frequency, primary keys, business rules, and known limitations.
- Lineage and documentation must be updated as part of the RFC process.

13) Security and Privacy
- Access control:
  - Least privilege and role-based access; sensitive attributes masked in non-production.
- Encryption:
  - In transit (TLS) and at rest; keys managed per organizational policy.
- PII handling:
  - Sensitive fields classified and tagged; restricted datasets documented.
  - No PII in logs, metrics, or error messages; redaction applied at source if feasible.
- Audit:
  - Access audits retained ≥ 400 days; data change audits retained ≥ 400 days.

14) Data Retention
- Raw landing: ≥ 30 days immutable retention for replay.
- Staging: ≥ 30 days or until successful reconciliation plus 7 days.
- Curated: In accordance with legal and business retention policies; historical snapshots maintained per defined SCD strategy.
- Error/quarantine: ≥ 90 days to facilitate remediation and analysis.

15) Recovery Objectives
- RPO (data loss tolerance): ≤ 15 minutes for CDC; ≤ 24 hours for batch.
- RTO (pipeline recovery): ≤ 2 hours for Sev1 outages impacting publish.

16) Reporting and Reviews
- Monthly SLA report:
  - KPI attainment, error budget consumption, incidents and PIR outcomes, top data quality offenders, and trend analysis.
- Quarterly review with stakeholders to adjust targets, rules, and capacity plans.

17) Exceptions and Waivers
- Temporary SLA exceptions must:
  - Be documented with scope, rationale, start/end dates, and compensating controls.
  - Be approved by data owners and service owners.
  - Not exceed 30 days without re-approval.

18) Roles and Responsibilities
- Data Platform Team:
  - Own pipeline reliability, controls, monitoring, and incident response.
- Data Owners (Orders Domain):
  - Own data definitions, business rules, exceptions, and prioritization of fixes.
- Source System Owners:
  - Provide stable interfaces, change notifications, and data contract adherence.
- Data Consumers:
  - Use published contracts; report anomalies via the agreed channel with reproducible examples.

19) Acceptance Criteria for Production Readiness
- All mandatory checks implemented and passing in non-prod.
- Runbooks and on-call rotations established.
- Dashboards and alerts validated with test scenarios.
- Backfill and rollback procedures tested with representative volumes.
- Data contract published and signed off by data owners and key consumers.

20) Effective Date, Review Cycle, and Version Control
- Effective date: [insert]
- Review cycle: Quarterly or upon material changes to source, pipeline, or usage.
- SLA version: [insert]; prior versions archived in the data catalog.

Appendix A: Key Calculations
- Completeness (C1) = 1 − |expected_count − observed_count| / expected_count.
- Field population (C2) = non_null_records / total_records.
- Reconciliation (R1) = |curated_count − source_count| / source_count.
- Financial reconciliation (R2) = |sum_curated − sum_source| / max(1, |sum_source|).
- Latency (T1) = publish_timestamp − source_commit_timestamp.

Notes
- Targets and thresholds are starting points and must be calibrated with historical performance and business risk.
- All thresholds apply to production unless explicitly stated otherwise.

核心报表服务 数据质量服务级别协议（SLA）草案

1. 目的与范围
- 目的：为核心报表服务提供统一、可量化、可监控的数据质量保障，确保报表结果的准确性、完整性和可用性。
- 范围：生产环境中的核心报表及其数据管道、关键数据元素（CDE）、计算口径与发布流程。测试与沙箱环境不在本协议保障范围内。
- 适用方：数据平台团队、数据工程团队、数据治理/质量团队、业务数据负责人（Data Steward）、报表产品负责人、上游系统负责人。

2. 术语与定义（核心）
- 准确性（Accuracy）：数据与真实值或权威来源的一致程度（含数值偏差容差）。
- 完整性（Completeness）：记录或字段的存在与填充程度（覆盖率、非空率）。
- 一致性（Consistency）：同一业务口径在不同系统/层级的结果一致性。
- 有效性（Validity）：数据是否满足定义的业务规则与格式约束。
- 唯一性（Uniqueness）：主键或唯一约束下无重复。
- 时效性/新鲜度（Timeliness/Freshness）：数据相对约定发布时间的延迟情况。
- 可用性（Availability）：服务可用的时间占比。
- 可追溯性（Lineage）：数据来源、加工逻辑与版本可被追踪与审计。
- 关键数据元素（CDE）：对核心报表有重大影响的事实、维度字段或指标。

3. 数据范围与CDE管理
- 报表范围：核心经营指标、合规与外部披露报表、管理驾驶舱。具体清单及依赖关系在报表目录与数据血缘文档维护。
- CDE识别与变更：由数据治理委员会批准；新增/变更CDE需完成口径定义、数据字典、质量规则与监控配置。
- 数据来源：明确上游系统边界与数据契约（Schema、分发时点、数据语义），变更需提前公告。

4. 服务目标与KPI（默认目标，可按报表重要度分层调整）
4.1 数据质量KPI（对CDE与关键中间层表强制）
- 准确性
  - 指标：数值偏差率 ≤ 0.5%（相对权威来源/对账口径）；或绝对偏差阈值（按指标定）。
  - 计算：|报表值-基准值|/基准值。
  - 频率：每日或每次发布。
- 完整性
  - 字段非空率 ≥ 99.9%（CDE）；记录覆盖率 ≥ 99.5%（对账基数）。
  - 计算：非空记录数/总记录数；实际记录数/期望记录数。
- 一致性
  - 跨层/跨系统对账差异率 ≤ 0.1%；代码值合法性通过率 100%。
  - 计算：聚合对账差/基准聚合；值域命中数/总数。
- 有效性
  - 规则通过率 ≥ 99.8%（含范围、格式、业务约束）。
  - 计算：规则通过记录数/评估记录数。
- 唯一性
  - 主键重复率 = 0；近实时去重延迟内的临时重复 ≤ 0.01%。
  - 计算：重复主键记录数/总记录数。
- 时效性/新鲜度
  - 日批：T+1发布完成时间 ≤ 08:00 本地时区。
  - 近实时/小时：数据落地至可用 ≤ 15 分钟（窗口结束后）。
  - 计算：实际可用时间-约定可用时间。
- 可追溯性
  - CDE血缘、口径、规则文档覆盖率 100%；加工作业版本与参数留痕 100%。
- 稳定性与回归
  - 规则执行成功率 ≥ 99.9%；异常重复发生（同根因）在30日内 ≤ 1次。

4.2 服务可用性KPI（报表查看与分发）
- 报表服务可用性：≥ 99.9%（7x24），或 ≥ 99.95%（业务时间窗口，例：08:00–20:00）。
- 发布成功率：≥ 99.9%（按发布批次）。
- 延迟告警SLA：违反时效性阈值后10分钟内发出高优先级告警（MTTD ≤ 10分钟）。

5. 测量与验证方法
- 基准值来源：权威账套、外部对账文件、上游主系统或历史黄金口径；基准优先级在规则中声明。
- 采样与覆盖：CDE与关键聚合全量校验；大表可采用分区全量或分层抽样（置信度≥95%，误差≤0.5%）。
- 规则执行点：入湖前（Schema/值域/去重）、建模层（实体约束/主外键）、指标层（口径约束/对账）、发布前（端到端校验）。
- 指标计算口径：统一在数据质量字典中维护；公式示例
  - 非空率 = 非空记录数/总记录数
  - 规则通过率 = 通过记录数/评估记录数
  - 可用性 = 1 -（不可用时长/总时长）
  - 延迟 = 实际可用时间 - 约定可用时间
- 误报/漏报控制：规则含白名单与豁免条件；异常确认需双人复核（数据工程+Data Steward）。

6. 发布与时效管理
- 发布节奏：日批T+1；小时批或流式按约定窗口；重大报表的月度/季度结账窗口明确冻结时间。
- 截止时间（Cut-off）：对账口径与取数时间点固定化并文档化。
- 回补策略：延迟或缺数在24小时内自动回补；超过24小时需评估对业务影响并发布公告与补救计划。

7. 监控与告警
- 覆盖范围：作业运行、数据量/分布、规则结果、对账差异、接口滞后、报表渲染与分发。
- 告警分级
  - P1（致命）：影响核心报表准确性或发布时效；5分钟内页面/IM告警，15分钟内人力响应，4小时内恢复或提供临时替代方案。
  - P2（高）：局部CDE异常或次要报表延迟；15分钟内告警，30分钟内响应，1个工作日内修复。
  - P3（中）：非关键字段异常或文档偏差；4小时内响应，5个工作日内修复。
- 通知渠道：IM/邮件/工单/状态页；关键事件需状态页实时更新与事后RCA通报。

8. 事件与问题管理
- 工单全流程：发现-分级-归属-处置-验证-关闭；每单需附根因、影响评估、补救与预防措施（CAPA）。
- 根因分析（RCA）：P1在2个工作日内提交；P2在5个工作日内提交。
- 缺陷回归测试：同类规则新增回归用例并纳入自动化。
- SLA违约处置：连续两周期未达标需提交改进计划与时间表；可触发专项治理。

9. 变更与发布管理
- 架构/Schema重大变更提前至少5个工作日通知（含兼容策略与回滚方案）。
- 指标口径变更需评审并双轨期运行（至少1个发布周期），期间向用户披露差异影响。
- 新增上游数据源需签订数据契约（时点、质量、格式、语义）并通过质量门禁。
- 维护窗口：每周固定维护时段提前72小时公告；维护期间不计入可用性SLA。

10. 例外与豁免
- 外部供应商数据故障、监管口径紧急变更、不可抗力导致的影响经评估与公告后可豁免SLA考核，但需提供缓解方案与回补计划。
- 历史遗留数据在一次性清洗期间的临时偏差经备案可阶段性放宽阈值。

11. 角色与责任
- 数据质量负责人（DQA Owner）：SLA治理、指标口径与审计、例外审批。
- 数据工程团队：规则实现、监控与告警、数据管道稳定性与回补。
- 数据治理/Steward：CDE定义、值域与业务规则维护、口径一致性。
- 报表产品负责人：发布节奏与变更管理、用户沟通与期望管理。
- 上游系统负责人：数据契约遵循与变更提前通知。
- 安全与合规：与数据质量交叉的合规约束（如脱敏对完整性的影响）评估。

12. 报告与评审
- 运营看板：近实时展示规则通过率、延迟、可用性、对账差异。
- 周报：异常清单、根因汇总、SLA达成率。
- 月度/季度评审：SLA指标复核、阈值与权重优化、问题趋势与改进计划。

13. 数据修复与重算
- 修复优先级：先保障CDE与核心指标，再处理非关键字段。
- 重算策略：版本化重算，保留旧版快照与变更说明；对外披露报表需补发修订说明与影响范围。
- 回溯窗口：至少保留近12个月重算能力（存储与血缘可追溯）。

14. 数据保留与审计
- 质量结果留存：规则执行日志、对账结果、异常处置记录保留≥24个月。
- 审计追踪：作业版本、参数、代码变更、手工干预均需审计可追溯。

15. 安全与合规（与质量相关的最小交集）
- 口径一致性与脱敏/汇总策略兼容性评估，确保在不暴露敏感信息的前提下完成对账与验证。
- 测试/训练数据不得污染生产口径；生产与非生产数据隔离。

16. 指标分层与权重（建议）
- S0（监管/外部披露/董事会级）：阈值最严，必须达到准确性≥99.9%、时效性零容忍延迟（除维护），双轨对账。
- S1（经营管理核心）：与文稿默认阈值一致或略严。
- S2（分析与探索）：阈值适度放宽，强调及时性与可追溯。

17. 争议与度量复核
- 如对测量口径或阈值适用性有争议，提交至数据治理委员会进行复核；在复核结论前，沿用现有口径。
- 任何指标或公式调整需记录版本并通知相关方。

18. 生效与更新
- 生效日期：签署后生效。
- 评审周期：至少每半年一次，或发生重大业务/系统变更时即时评审。
- 附件（示例清单）：核心报表目录与CDE清单、规则与告警项明细、上游数据契约、维护窗口计划、联系与升级矩阵。

备注
- 本草案提供默认目标值，具体阈值应结合实际数据规模、系统能力与业务风险进行基线测量后校准。
- 任何高于系统能力上限的目标在上线前需进行容量与压力验证，并形成补充协议。