写代码也要讲规矩——SLA

软件的复杂性带来的问题

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

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

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

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

代码交付

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

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

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

SLA（Service Level Agreement）

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

• SLI，服务质量指标，服务的某项质量的一个具体的量化指标。

• SLO，服务质量目标，服务的某项SLI的具体目标值，或者目标范围。

• SLA，服务质量协议，描述在服务不达SLO情况下的后果。

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

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

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

一个实例快速了解SLI、SLO

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览92165 人正在系统学习中