干货 | 难对齐、难保障、难管理？一文了解字节跳动如何解决数据SLA治理难题

基于字节跳动分布式治理的理念，数据平台数据治理团队自研了SLA保障平台，目前已在字节内部得到广泛使用，并支持了绝大部分数据团队的SLA治理需求，每天保障的SLA链路数量过千，解决了数据SLA难对齐、难保障、难管理的问题。本文将分为上、下篇发布。上篇主要介绍数据SLA的应用场景、核心概念以及申报签署流程。

文 | 录铸  来自字节跳动数据平台开发套件团队

背景介绍

在海量数据任务开发场景中，因业务多样化、数据量大、数据任务复杂等问题，导致数据任务链路依赖复杂、链路长、跨团队节点依赖多，因此，在实际开发运维过程中，任务负责人为保证自身数据准时产出，会遇到如下困难：

• 沟通成本高：任务负责人尝试与上游任务负责人约定SLA，但由于上游任务数多（可至上千个），且跨越多个团队，沟通成本非常高

• 权责不清晰：由于链路复杂，如何制定SLA？谁来负责保障SLA？

• 运维压力大：无法及时发现上游任务延迟，导致下游任务负责人承担绝大部分运维压力，且运维效果较差，往往发现延迟已经错过了补救的时间。

应用场景

• 数据业务方：“我们团队的业务很依赖一份重要数据，希望能对其进行保障，希望上游能承诺SLA”

• 数据负责人：“我们团队有很多对外承诺SLA的数据，希望能有一个平台对SLA进行集中管理，并能提供一些统计大盘、风险分析等内容”

• 数据治理方：“我们希望能提升团队内核心数据的数据质量，对齐进行SLA管理，及时发现风险，并进行事故复盘和改进，最终不断优化数据质量”

核心概念介绍

• 申报人：即SLA提申报的人，一般是数据业务方，其提申报的目的是保障业务数据的SLA；

• 管理员：满足数据治理方的需求设置的角色，负责申报的审核、批准、管理、统计、登记、复盘等，其目的是不断优化所属团队的数据质量。
• 任务负责人：即待保障SLA数据链路中的任务owner，负责确定及签署所负责任务的SLA，平台会按照其签署的SLA进行保障；

申报签署流程详解

SLA保障的前提是先达成SLA协议。在SLA保障平台中，以申报单签署的形式达成SLA协议。平台核心特点是优化了SLA达成的流程，先通过“系统卡点计算”减少待签署任务的数量，再通过“SLA推荐计算”自动签署部分任务，最后为剩下的待签署任务智能提供合适的SLA，进一步降低签署成本。

当两个申报单有部分任务列表重合时，如Task4关联了两个申报单，该任务的申报方、治理团队等数据是两个申报单的去重合集，而等级则取所有申报单中最高者。

• 未到SLA：即当前时间，任务未产出，且还未到SLA时间（继续监控）；

• 已达成：即任务已完成，且完成时间在所承诺的SLA之前（发送就绪通知）；

• 已延迟：即任务未完成，且当前时间已在所承诺的SLA之后（发送延迟通知）；

• 已延迟（产出）：即任务已完成，但完成时间在所承诺的SLA之后（发送延迟产出通知）；
• 从下图可以看到在任务达成、未达成两种情况下，随着时间的推移，其SLA状态的变化。

在下篇中，重点介绍数据SLA如何进行复盘管理以及平台架构，敬请期待。

开发套件团队正在招人，点击阅读原文了解