写代码也要讲规矩——SLA

软件的复杂性带来的问题

工作一年多了，在涉及到跨部门合作的时候往往就是最痛苦的时候，其实道理很简单，刚开始，我们的组织和产品如左图，一切都比较简单，为了业务的发展，通过人工快速吃到技术和产品的红利，很多事情人工能掌控，有事吼一声，开个会就解决了，也运转得很好。

但随着慢慢发展，组织和产品就如右图，彼此连接依赖越来越复杂，为了整体的高速运转，对每个部件的稳定性越来越高，越来越精密，发展到一定程度，人力已经无法掌控，任何一个组件出异常都有可能牵一发而动全身，影响全局。每个部件的稳定性和精密程度决定了整体的工程质量，也决定了整体的发展速度。

那么，为了解决这样的问题，我们可以采取什么样的手段？

从汽车的发展到软件系统的建设

他山之石可以攻玉，软件系统虽然日益复杂，但和汽车建造无本质区别。软件编写完成后是要交付出去的，这就跟一辆车建造好后是要卖给别人一样，闭门造车无疑是自嗨。那么车主在买车的时候会考虑什么？

把时钟拨回到100多年前，贵族们在买车时，车能跑起来就万事大吉了；后来出“车祸”的人越来越多，开车变成了一件危险的事情，于是车企就开始了各种测试（例如碰撞测试）；再后来，为了方便车主关心自己车子的状况，越来越多的车撞上了「仪表盘」；到了现在，没有仪表盘的汽车没有几个人敢开，因为你对车的健康、速度等状态一无所知，和闭着眼睛走路没什么区别。

如今，你再去买车，你会关心百里加速耗时多少，油耗多少，制动距离等等「指标」，因为这些「指标」让我们对最终交付给我们的车辆能提供的服务有一个明确的认识和期望，开车的时候心里更踏实。

软件系统的交付（代码->安装包->镜像）

回到软件系统，软件工程的本质就是为了解决软件系统的复杂性，而其中一个part就是就是交付过程的复杂性。

代码交付

一开始，我们会选择把代码+配置文档交给业务方，然后由业务方自己去打包、配置运行环境并进行部署和运行。这种交付手段可想而知：流程复杂且不可控，加之开发环境与生产环境的差异，上线前往往需要烧香拜佛，更多的不是技术问题而是玄学问题。

安装包交付

于是在代码的基础上更进一步，交付二进制的安装包或者将配置部署过程脚本化，实现了部署和运行的规范化。这种方式解决了流程复杂和重复的问题，但是仍然不能解决环境不一致的问题，因为宿主环境是你无法预先确定的。

镜像交付

再后来，开发者直接将代码及其依赖的环境（OS、三方库、配置等）完整地打包进虚拟机镜像，实现了一键部署和运行。这种方式既解决了流程问题，也解决了环境问题，主要问题在于虚拟机是一种比较重的技术，比较耗费资源和部署时间。而容器的出现，才真正改变了软件交付的形式，镜像将代码和环境全部打包，容器了确定镜像、部署流程与配置，实现一键部署和运行。这种方式实现了 "一处编译，处处运行" 的美好愿景（同样愿景的Java还必须依赖JVM，而容器直接与OS交互，是真真的实现了这个愿景），并且比虚拟机更轻量高效，是目前软件交付的事实标准。

我们需要交付的究竟是什么？

类比上文说的汽车的交付，软件系统交付的究竟是什么？是代码吗？功能代码是模棱两可的，谁也不知道到底正确与否，交付质量全凭价值观保证。

客户需要的，其实是你交付的系统能做到什么，不能做到什么，你的系统是否达到我的期许，如果没达到我的期许，又该怎么解决问题。这就是系统开发者与客户之间的「约定」，在软件系统中称为服务等级协议，即SLA（Service Level Agreement）。

那么回到一开始的那个问题，为什么在涉及到跨部门合作的时候往往就是最痛苦的时候，本质上在于双方的SLA不对等，我认为你这个服务的提供方应该要给我提供这些能力，但是服务方却觉得这根本不是我的职责，我为什么要帮你解决问题。

升华一下，亲密关系也是如此，事先没有约定好你想要的和对方能给予的，吵架便也是家常便饭了。

SLA（Service Level Agreement）

前面铺垫了这么多，总算是来到本文的主角了。

SLA，是服务供应商与客户之间的服务等级协议，它定义了服务供应商应保证的服务质量，以及在服务不达标情况下的服务赔偿。SLA在定义上又细分为SLI、SLO与SLA。

• SLI，服务质量指标，服务的某项质量的一个具体的量化指标。
• SLO，服务质量目标，服务的某项SLI的具体目标值，或者目标范围。
• SLA，服务质量协议，描述在服务不达SLO情况下的后果。

现在大家对于SLA的讨论更多是围绕着云服务厂商展开的，其实很好理解，云原生时代，云服务厂商就是最大的服务提供方，而用来确保服务双方达成一致的SLA，自然会更加重视。

云计算的最终愿景是“让计算资源和公共基础设施一样，按照使用者的规模提供随用量变化的弹性经济模式！”

虽然SLA常见于公司与外部供应商之间，但事实上SLA也可以用于公司内部两个部门，两个产品之间。公司内部可能不会涉及到服务赔偿，因此内部SLA更关注于SLO的达标情况。

一个实例快速了解SLI、SLO

给你承诺的男人不一定可靠，但连承诺都不给的男人一定不可靠。

男孩对女孩说：以后你发消息，我一定秒回，间隔时间超过xx分钟，我就给你送礼物

SLA中的对服务类型、质量时间条款的条文规定

可是女孩每次发消息的时候，男孩不是在洗澡就是在打游戏，每次都超过约定的时间

可用性低于条文中所规定的值

于是为了哄女孩开心，男孩只能道歉+送礼物

服务商所需提供的赔偿

久而久之，女孩终于忍受不了男孩的行为，选择删除好友。

客户更换服务商

在上面这个SLA的例子中，SLO（指标）就是男孩给出的秒回承诺，秒回（≈0ms）就是SLI（指标），「超过规定时间就送礼物」是未达标的后果，因此SLA又可以抽象成👇

SLA = SLO + 后果

如何描述服务质量？

对于大多数服务而言，表述服务可用性最直接的方式可能就是服务可用时间。

在这种体系下，常说的99.9%，99.99%，99.999%的可用性都是时间维度的统计，可以理解为：在规定的条件和规定的时间内，完成规定任务的概率。基于时间的可用性有如下表述形式👇

可用性 = 系统正常运行时间 / 统计周期内的总时间

关于系统的可用性，之前已经写过一篇了，可以参考👉《你的系统可用性 5 个 9 了吗？》

不同SLA不同的成本

「取舍」是软件工程中亘古不变的主题，一个有明确SLA的服务最理想的运行状态是： 增加额外资源来改进系统所带来的收益小于把该资源投给其他服务所带来的收益。

一个简单的例子就是某服务可用性从99.9%提高到99.99%所需要的资源和带来的收益之比，是决定该服务是否应该提供4个9的重要依据。