设定并达成数据服务级别协议的 11 点清单（附 SLA 模板）

我们可以断言，任何团队无论规模多小，都应当制定并遵守数据服务级别协议（即数据 SLA）。什么是数据 SLA？这是一项对可量化服务水平的公开承诺。正如您的基础设施即服务（IaaS）提供商承诺 99.99% 的正常运行时间一样，这是您承诺在特定参数范围内提供特定质量的数据。

此项承诺必须公开，这一点至关重要。（至少在公司内部如此。）公开性有助于建立更明确的责任制，帮助所有团队就最重要的事项达成一致，并使您能够构建支持数据质量的管理框架。

本指南将探讨如何建立您自己的数据 SLA。

正式的书面数据服务级别协议（SLA）能够使您的非正式承诺具体化，并获得双方的认可。每一种数据关系都包含非正式承诺，无论您是否明确声明。在许多情况下，双方可能就某件事达成一致，却未意识到彼此所谈论的内容存在差异。

那么，数据 SLA 究竟是什么？它是一份简洁的书面文档，通常为 250 至 500 词，发布在共享空间（如公司维基或 Google 文档）中。它应包含以下 6 个要素：

• 目的：为何制定此数据 SLA？您期望它解决哪些问题？希望它如何被使用？

• 承诺：您向其他团队承诺了什么？

• 衡量：如何衡量数据 SLA？由谁衡量？SLA 的时间框架是怎样的？

• 后果：当未能达到数据 SLA 时，将发生什么？谁将负责？可采取哪些补救措施（如有）？

• 要求： 您期望获得什么回报？您的承诺有何前提条件？

• 签署： 谁承诺遵守此数据 SLA？

在撰写数据 SLA 时，请用尽可能精简的文字准确传达含义。这需要多次修改，但我们建议先一气呵成完成初稿（即使粗糙），再返回修改。原因是若长时间面对空白页面，您可能会产生所谓的“空白页焦虑症”并不断拖延。请立即完成一份低质量的草稿——切勿等待。

以下是一份数据服务级别协议示例：

本文件的目的是让我们的团队向各方公开承诺，将在精准参数范围内维持高数据质量。我们希望这将增进理解，帮助我们所有人协同合作，并让团队之间相互问责。

我们的承诺：我们将在每天美国东部时间凌晨 5:00 之前提供数据质量得分至少为 95% 的销售数据，以便团队能够回答“昨天的销售额是多少？”之类的问题。我们将在 1 个工作日内确认所有请求，并将其按简单工单和复杂工单进行分类。我们将在 3 个工作日内解决简单请求，在 2 周内解决复杂请求。

通过比较数据交付关键绩效指标 (KPI)（例如运行开始时间和运行结束时间、记录计数和空值与记录计数之比、分布和漂移分数）与数据新鲜度、数据完整性和数据保真度的预定义标准来衡量数据质量。

若我们未能达成数据 SLA，本团队将在 3 个工作日内在公共渠道发布致歉声明，说明原因，并明确列出我们正在采取的具体改进措施。

为履行此承诺，我们需要您的协助。本团队需要及时的方向指导、信息输入以及关于数据使用情况的清晰反馈，同时对于任何复杂的变更请求，请至少提前四周通知。

如有任何疑问、意见或关切，请发送至 data-eng@team.com。

此致

– 您的数据工程团队

在制定 SLA 过程中（或修订期间），应同步规划实现承诺所需的全套支撑体系。

例如：

尽可能消除这一表述的模糊性，用具体且明确的术语对其进行界定。我们认为，您可以使用四个特征来定义高质量数据。定义明确后，需确保其他团队对此定义达成共识。

需自问：

• 优质数据能为业务带来什么成果？
• 优质数据的核心特征
• 劣质数据具有哪些特征？

为实现追踪，您需要一款可观测性工具，以便准确掌握数据管道中各环节的运行状态。若无此工具，将难以衡量是否未达到 SLA，更不用说诊断根本原因。该工具还能协助理解错误信息，从而加速问题修复。

您可将数据 SLA 视为北极星指标——引导全员聚焦的核心目标。但在此目标之下，实际隐藏着大量复杂性，您需要追踪一系列关键绩效指标来了解上下游动态。

具体建议如下：

1. 设置自动测试以监控四个维度的数据质量
   • 预生产环境测试数据
   • 分阶段测试：完整性、异常值检测
2. 衡量问题发现、响应与处理的效率
   • 问题发现时长
   • 问题解决时长
   • 单资产故障次数
3. 记录每个问题的直接原因与根本原因
   • 数据合作伙伴交付失败
   • 超时
   • 任务队列阻塞
   • 异常转换
   • 权限故障
   • 运行时错误
   • 调度变更

对承诺内容保持审慎。您无法面面俱到，而 99.999% 正常运行时间的 SLA 意味着每年仅允许 5 分钟停机时间。为实现该目标，您可能需要增加人员编制、提升可视化能力、构建冗余机制并安排全天候值守。

您可能需要使用 Jira 或 ServiceNow 等工单系统。这使数据用户可创建工单，您的团队能追踪处理进度，同时帮助您理解问题本质以制定长期修复方案并定位故障高发区域。

虽不必在公开的 SLA 文档中明确指定，但需在内部确定数据源与数据管道的负责人。他们是问题发生的最终责任主体。同时需规定其休假或离职时的交接机制。

在团队通讯工具（如 Slack）或事件管理系统（如 PagerDuty）中配置告警。告警包含的事件细节越丰富，诊断速度越快。这些告警将提前告知需协调人员名单或分析切入点。（IBM Databand 可发送此类告警，并附加有价值的洞察与上下文信息。 ）

假设数据用户告知您其仪表盘中的某个数据表异常，您应如何确认与响应？将其写成明文流程，避免事件发生时陷入旁观者效应——即所有人假定他人会处理，最终无人行动。

根据团队规模与全球分布情况，您可能需要严肃对待此事，任命应急响应中的“事件指挥官”。该人员将成为事件处置的最高负责人，指挥所有协调工作。（此举可确保响应协调一致，避免多人重复处理同一问题。）

若条件允许，可在用户仪表盘设置告警面板，用以通报系统状态。若发生故障，您可以发布通告："我们正在处理系统中断——这是预估的解决时间。"此举将有效减少数据消费者的重复告警，使您能专注实施应对措施。

若无法创建告警面板，至少应为每个团队指定关键联系人，通过其实现信息逐级传递。

监控数据消费者如何使用数据（包括是否真正使用数据）。通过定期开展正式或非正式调研，评估其对数据的信任度并收集改进建议。对于感兴趣的用户，可同步产品路线图规划。

建立定期维护机制，让团队复盘故障成因并共商解决方案。需深入探究问题根源，开展无责复盘会议，记录分析结论，分配修复任务并持续追踪改善效果。

完成上述规划后，即可着手编辑修订数据 SLA。将其公开发布至公司维基或共享平台，获取全体成员的承诺，并严格付诸实践。

数据 SLA 旨在规范你和团队的数据交付行为。虽然形式上是对外部的公开承诺，实则是双向协议——您承诺在特定参数内提供数据，同时需要获得各方的配合与理解。

数据工程领域隐患众多，多数问题源于沟通不畅。通过 SLA 文档化可有效扫清障碍，最终实现核心目标：在组织内部建立更坚实的数据信任体系。

及早发现数据健康隐患，避免因违反 SLA 造成经济损失。了解如何通过高级告警与异常检测赋能工程师，将质量问题扼杀于萌芽阶段。如果您准备深入了解，请立即预约演示。