文章首或尾句需要带关键词“ 本文正在参加「金石计划」 ”
前言
我比较早接触sla这个概念是得物的一篇文章从 0 到 1，亿级消息推送的稳定性保障，然后一次机缘巧合下，我在梳理自己的工作，发现在流程上也有一些异步的场景，那我开始思考了，对方什么时候将数据返回给我呢？如果对方没有返回数据，我们的链路现在又是怎么正常运作的呢？毕竟我负责的系统也是供应链的一环，在这一瞬间让我想起了sla。
之前还遇到另一个线上问题，就是有业务同学反馈某某商家一直没有返回数据，我这边一看，对方确实没有返回我数据，然后有同学让我去看这一单整条链路的日志，这个做法我也是摸不着头脑，看别人的日志能看出个啥。
我认为原因还是sla没有建设好，比如说老板问起来，这一单当前卡在什么环节，卡了多久，为什么会有这种情况，有没有一个预警机制呢？其实我们当前靠业务去管控这些，接下来我们开始聊聊sla建设想法。
sla概念以及为什么要做
服务等级协议（SLA， 又称为服务级别协议，服务水平协议，服务品质协议）定义了用户期望从服务供应商，或是内部另一个服务部门那里得到的服务水平，它规定了衡量服务是否达标的指标。
我们从概念里面可以知道，sla是衡量服务、系统达标一些指标，在我阅读完一些介绍文章之后，发现它主要是以时间为维度去衡量达标情况。
why？
作为一个功能，或者一个系统，你是某一部分的负责人员，是比较难去知道这个链路发生状况的，有很多原因，比如说权限，你没有权限去访问其他系统数据，最多就问一下其他同学查一下；其次对方的代码就像黑盒，你只知道当前系统返回了什么结果，不清楚里面做了什么操作。
还有另一个场景，就是业务跟技术因为知识领域不同，交互的不同，很难聊到一块。sla业务链路可以将两种角色统一到一起，业务同学清楚链路里面系统作业动作，当前卡在哪里，处理时间多少，作业效率怎样，那个业务同学跟进不到位；然后技术同学清晰业务作业，可以根据这些任务的时间进行调优、兜底，比如说目前卡在我系统，我要怎么快速的处理这种情况。
sla建设
当然目前只能是理论阶段，我认为需要分4块来，记录上报、监控、预警、卡点自动化。
记录上报
这是一个基础，所有的情况以及后续调优都需要基于一开始的数据沉淀。我认为需要梳理出一条主业务线，比如说你是看重订单整个流程，还是说关注某个具体系统交互情况（得物那篇关注短信类送达、可用性），有了目标之后才好针对性的解决。
我们举订单流程吧，从下单、校验库存、结账、出库、运输、收货、售后，里面涉及到不同的系统，每个系统都需要对核心任务进行上报，然后上个任务是什么，然后当前任务执行时间，归属的负责人是谁。这些应该是sla数据上报元数据。
监控
有了上面这些数据之后，将他们串成链条，至于里面一些细节要不要展示这看具体场景，比如说会员体系通知用户，如果你只关心最终促达的情况，那么只需要统计最终结果，中途是通过短信还是app送达那可以忽略。
我们可以统计出每一单的作业时间，哪个步骤耗时长，哪个步骤容易出问题。
预警
我们再基于上面监控，做一个预警值，比如说某个过程超过多少小时没有响应了，提醒对应的负责人。预警之后肯定会有备用方案，比如说人工跟进处理，或者说走其他方式让流程正常运作。
卡点自动化
流程总会需要卡点，比如说财务审批，节点状态变更，这些可以部分由系统自动去切换状态，实现提高效率的作业。
场景
就拿我们刚刚提到场景来聊吧，就是业务同学下完单之后，我们将这些单子丢到外部供应商去的，供应商会进行内部一系列操作之后再异步丢回信息。
之前出现一个问题，就是有些供应商调我们接口出现问题了，导致数据一直没有从线上传递过来，之后一个月后业务同学才反馈说一直没有收到供应商对应的数据。
如果有了sla系统，那么我们可以在页面看到 下单->报单->外部供应商接收报道完成->waiting。。。
那么我们可以参照之前完成的链路去排查，是已经切换新的模式导致，还是说下一环出现了问题，这时预警就起作用了，系统提醒人员去跟进处理。
总结
我认为sla最大作用就是对业务流程量化，然后让不同角色都看得懂，比如老板想看流程的成交率，业务同学关心流程高效，技术同学关心一般是可用性，业务的稳定性，不会说业务卡了半天，然后客户投诉才开始搞。
