多团队下SLA约定问题

一、问题

在数据生产上有这么一种场景，明明可以实现按照业务方需求交付，但却没法承诺一个SLA。

二、问题描述

比如业务方要求一个数据产出结果是8点钟产出，但是这个结果在数据上经历了4个团队的顺序生产，从源头到结果分别是甲乙丙丁。

甲负责任务A0，A1，A2，三个任务一共需要2个小时

乙负责任务B0，B1，B2，三个任务一共需要1.5小时

丙负责任务C0，C1，C2，三个任务一共需要1小时

丁负责任务D0，D1，D2，三个任务一共需要2小时

正常来说从0点开始A0任务启动，顺序执行甲乙丙丁四方的9个任务，需要6.5个小时，肯定可以在8点之前产出。但是由于跨团队了，需要团队之间承若SLA。

三、倒推法尝试

此时丁向业务方承诺8点就绪，因为担心有数据波动以及留有一个的buffer，那么实际就绪时间需要在7点就结束。往前倒推两个小时，需要丙保证5点钟可以就绪。

丙为了达成5点的SLA，需要也给自己预留1个小时buffer，加上自己生产需要耗时1小时，所以需要乙保证在3点就要就绪。

乙为了达成3点的SLA，需要也给自己预留1个小时buffer，加上自己生产需要耗时1.5小时，所以需要甲保证在0点30分就要就绪。

甲说，哥几个逗我呢，0点30分我任务才刚启动，你们就让我就绪了，完成不了

四、正推法尝试

于是甲乙丙丁又重新沟通了一次，这次让甲先做出承诺

甲说，我0点启动，任务需要2个小时，预留buffer一小时，可以承诺3点完成。

乙说，那我按3点启动算，任务需要1.5个小时，预留buffer一小时，可以承诺5点30分完成。

丙说，那我按5点30分启动算，任务需要个小时，预留buffer一小时，可以承诺7点30分完成。

丁说，那我按7点30分启动算，任务需要2个小时，预留buffer一小时，可以承诺10点30完成。

业务方说，10点30分黄花菜都凉了，我自己手工统计吧。

五、问题分析

明明正常情况下可以向业务方承诺SLA的数据，却因为有多个团队在维护数据，变得无法向业务方承诺了。问题原因在哪？原因在于每个团队由于作出了承诺，都需要给自己的承诺预留一个buffer，团队越多，buffer叠加的越多。注意，这个场景中并不是说数据真的在10点30分才能产出，而是数据可以产出，但是由于叠加了太多buffer却不敢承诺了。

找到了问题的原因，可以解决吗？也不容易。

六、固定buffer尝试

一种尝试是固定buffer，不允许buffer叠加

比如甲给自己留1个小时buffer，实际2点完成但对外承诺3点。

乙不能以甲的承诺时间作为起点，而是以自己实际就绪时间+1小时对外承诺SLA，实际就绪是2+1.5=3点30分，对外承诺就是4点30分。

同理，丙实际4点30完成，对外承诺是5点30分。丁实际6点30分完成，对外承诺是7点30分。正好可以满足业务方的需求，于是就定下7点30分是最终SLA。

看似很好解决了，实则不然。比如，恰好有一天甲和乙都是正常时间产出，丙从3点30分开始启动，但是数据出现故障，延迟了55分钟，最终5点25分完成，没有打破SLA。丁由于启动晚了，正好和其他高优任务挤在一起，导致抢不到资源，比平时2小时的时间延迟了10分钟，所以是7点35分产出，正好打破了承诺的SLA。业务方气势汹汹的找到丁，丁很委屈，明明是丙的任务延迟引起的，但是由于没有打破丙的SLA，好大一口锅就落到了我的头上。

七、按比例拆分buffer

在buffer相对充裕的情况下，有一种相对公允的SLA约定方式

假如还是一开始的例子，此时最终业务方可以接受10点钟数据就绪，则整条链路在正常情况下有3.5个小时的buffer（但是按照正推法只能承诺10点半，依然不满足）。此时我们可以按照每个数据团队任务执行时长的占比，按比例拆分buffer，既每个团队分得的buffer=该团队任务执行时长/整条链路执行时长*总buffer数。比如甲团队一共执行2小时，分得(2/6.5)*3.5=1.07小时buffer，则乙跟甲约定的SLA是2+1.07=3.07点钟。乙团队执行1.5小时，分得（1.5/6.5）*3.5=0.81小时buffer，则丙跟乙约定的SLA=3.07（甲乙约定SLA）+1.5（乙的执行池昌）+0.81（乙的buffer）=5.38点钟。后面以此类推。

这种方式的公平之处在于，使用同一种规则作用在一条链路上的各个团队，并不是只管自己不管他人死活的“正推法”和“倒推法”。另外，每个团队的buffer多少由这个团队内任务执行耗时长短来决定，任务执行时长越长认为内部越复杂、需要的buffer也就越高。