申报签署流程详解

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

在申报签署环节中，各个环节的变化将通过 通知模块传递信息给相应负责人，实时通知降低信息交流成本，加速了SLA的达成。

流程简介

上图为申报签署的一般流程，在实际操作时，如任务链路变化、SLA时间商讨待确认等特殊情况，申报签署流程会有微调。

首先需要申报人填写申报单，在申报人提交后，系统会根据申报单中的申报任务拉取上游的所有任务，构成一个完整的DAG，并进行 任务链路分析。 链路分析的结果是后续算法的前提，也是管理员审批时的重要参考因素，可以让用户快速了解到自身任务在链路中所处的位置及上下游运行情况。

在理想情况下，为保证申报任务顺利推进，需要该任务的 所有上游任务都签署 SLA 才算完成签署。而链路复杂导致的 上游任务多、跨团队沟通成本高、SLA难以确定等问题，成了整体SLA达成的最大阻碍。通过“卡点计算”与“SLA推荐计算”可以跨越此阻碍。

卡点计算

本系统采取一定的“卡点策略”，计算出此DAG中的部分需要被签署的任务，此类任务称为“ 卡点任务”，这个过程称之为“ 卡点计算”。计算得到卡点任务后，在签署过程中可以忽略其他任务，从而大大降低签署成本。

一个申报单会关联多个任务（即该申报任务及其上游的卡点任务），同理一个任务也会关联多个申报单，因为在一个DAG中，申报任务可能从任意节点起，因此二者是N:N的关系。

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

SLA推荐计算

利用任务及其上下游任务的历史运行信息，再结合推荐算法，得到该任务的推荐SLA，这个过程称之为 SLA推荐计算。

在负责人签署SLA之前，SLA推荐算法会 智能计算每个任务的推荐的SLA，并以此进一步通过算法 自动签署部分待签署的任务，进一步降低签署成本。据平台数据统计，此功能可以自动签署近 40%的SLA，是最核心的功能之一。

而对于剩余的待签署任务， 会将算法推荐的 SLA 提供给任务负责人。任务负责人可以直接选择直接用这个SLA签署，也可以自行决定SLA。一般情况下，智能推荐的SLA已经能满足绝大多数的需求，通过推荐SLA，任务负责人更快的做出签署决定，再次降低了签署成本。

系统保障监控

当一个申报单完成签署之后，平台将对申报单中的任务进行保障服务。保障服务的核心就是 通过监控 SLA 的状态变化及时播报消息通知，为相应负责人及时提供一手资料，以此降低运维成本。对于一个离线任务，评价其SLA主要是依据其完成时间和其所承诺的SLA来判断，SLA的状态分为四种，分别是：

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