申报签署流程详解
火山引擎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状态的变化。
-
SLA的实时状态是数据业务方所需要的重要信息，因此平台会所有任务的SLA进行监控，并在SLA状态变化时实时对相关人员发送通知，相关人员根据收到的通知知晓SLA的具体情况，并能做出应对措施。
复盘管理详解
复盘管理是本平台提供的响应式治理服务的实现方式，是数据治理方的重点关注对象。复盘管理又分为问题管理与事故管理，问题管理侧重于“为什么”——即整理分析SLA破线的原因，事故管理侧重于“怎么做”——即SLA破线事故之后该怎么治理。
问题管理
问题管理模块的整体目标是满足数据治理团队对SLA问题的登记管理，支持对登记后的问题数据进行不同维度根因数据分析，辅助用户对问题根因进行治理，沉淀治理问题经验。
平台在进行系统保障监控时，会在SLA延迟时进行通知播报，并持续提醒负责人进行问题登记。在问题登记时，平台提供了一组根因树辅助登记，明确问题根因类别，方便统计分析。任务负责人进行问题登记后，累积数据展示在问题看板上，数据治理方由此做问题分析归纳总结。
平台保证了SLA延迟记录与问题之间是一一对应的关系，并在问题看板上关联了SLA详情信息，包括任务链路、负责人、任务起止时间等。
问题登记往往是一个从多到少的过程，前期出现的问题在逐一治理解决后，将对后期的治理起到很好的参考警示作用，它的数据价值如下：
- 不同SLA问题类型的趋势分布，针对性的治理问题
- 相同根因引发了多少SLA问题，涉及影响多少数据资产
- 哪些数据资产经常出现SLA问题，问题的分类以及是什么根因造成的
- SLA问题经验总结，方便类似问题发生后，后期做推荐辅助快速定位根因
根据平台运营的记录显示，常见的问题有 资源 队列 阻塞、上游任务故障、 数据倾斜等。某数据团队双月问题登记总结如下，问题数量和问题根因种类得到了有效的收敛：
| 双月 | 问题数量 | 根因种类 |
| 2019-07/08 | 77 | 12 |
| 2019-09/10 | 58 | 10 |
| 2019-11/12 | 33 | 7 |
| 2020-01/02 | 23 | 5 |
| 2020-03/04 | 17 | 4 |
| 2020-05/06 | 9 | 2 |
| 2020-07/08 | 9 | 2 |
事故管理
事故管理用于记录SLA破线事故的复盘与改进管理，每个事故至少对应一条SLA问题记录，而每个SLA问题不一定会造成事故。
事故可以在任意节点进行，一般在SLA破线并造成实际的业务影响之后，需要进行事故登记，事故登记同样会关联相关的SLA信息。一个事故的处理流程如下所示：
如图所示，事故主要包含SLA事故明细、SLA事故根因、改进计划及SLA消耗这几部分，在这其中可以关注以下几点：
- 事故在登记时，会根据事故明细确认事故根因，并让相应负责人提出改进计划。
- 用户可以订阅事故，在事故的复盘状态及其改进计划的完成状态变化时，都会通知订阅人。
- 任务的改进计划在完成前，每日都会提醒计划负责人，直到计划完成为止
SLA事故管理平台的数据是数据治理方治理成果的重要依据，也是整个SLA保障平台使用效果的体现，它的数据价值如下：
- 对事故的复盘归档管理，方便后期随时查阅，定位相关SLA信息
- 针对不同数据团队发生SLA事故的整体情况进行对比查看，互相借鉴
- 对事故的改进计划管理跟踪，验收SLA的治理效果
以下是某个团队的双月事故统计：
| 双月 | 事故数量 | 环比 |
| 2019-07/08 | 46 | - - - |
| 2019-09/10 | 26 | -43% |
| 2019-11/12 | 18 | -31% |
| 2020-01/02 | 13 | -28% |
| 2020-03/04 | 7 | -46% |
| 2020-05/06 | 6 | -14% |
| 2020-07/08 | 5 | -16% |
通过上述数据可知，火山引擎DataLeap SLA平台有效保障了核心任务的稳定产出，辅助降低了稳定性事故发生的概率，现在每双月该类型事故数量长期维持在个位数。
点击跳转 【大数据研发治理套件 DataLeap】 了解更多
