数据质量SLA起草助手

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清单、规则与告警项明细、上游数据契约、维护窗口计划、联系与升级矩阵。

备注

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