工程师希望软件系统既庞大又敏捷，可以在最高水平上运行，并且不影响安全性。 他们希望软件具有扩展能力，设计简单，易于开发和维护。 他们不需要的是更多的缩写词。

SLA代表服务水平协议。 SLA通常跨越业务领域。 它们由跨法律，技术，销售和支持职能的跨职能团队组成。 在所有语言和冗长条件之下，这是一个基本前提-如果该软件无法按预期运行，则我们的一位工程师将在规定的时间内对其进行修复。 本文档的其余部分是此工程职责的多层。

SLA涵盖了可接受的解决方案时间，性能预期，服务/服务器的正常运行时间以及无数其他参数的定义。 参数的包含和排除取决于卖方/公司所同意的可用性的良好度量。 这遭受了令人遗憾的二分法。 所有这些定义都是基于试探法和假设进行的。 很少基于观察实际用户行为或与应用程序的交互的基础。

拥有SLA并不能保证您更好地了解用户需求。 但是将它们放在适当的位置具有优势。 SLA在冲突期间提供通用的词汇表，并在发生争执时帮助解决。 它们帮助提供服务的公司定义其人力需求，并确定工程师的职责。

工程师必须了解SLA，这一点很重要。 他们需要了解其中的定义和参数。 它有助于使单个工程师意识到他们的职责，并创建一种意识文化。 它可以帮助工程师在设计软件系统时设计SLO，以考虑到整个企业的影响。

对于工程师来说，SLO并不是那么抽象。 SLO代表服务水平目标。 工程师构建的每个软件组件都可以有效地提供服务。 该服务必须满足某些要求。 这些要求可以是通用的，也可以是非常具体的。 通用要求的示例可以是“此网关必须连接到支付提供商的API”。 特定的可能是“所有API调用中的99％应该在100毫秒内完成”。

创建SLO很快会成为一个复杂的过程，涉及概率论，演算和其他统计方法以准确预测事件。 创建它们的一种简单明了的方法是监视用户交互，设置适当的阈值并将它们绘制到相关的分位数中。 例如，“使用app.plumbr.io时，少于1％的用户应经历大于5 s的空闲时间”。 SLO通常来自系统预期的特定行为。 重要的是要记住，这些可能超出了分析师和产品经理的范围。

SLO是工程师的最好朋友。 它可以帮助他们定义所构建系统的重要边界。 当工程师有效地使用SLO时，它们可以帮助他们构建准确的系统。 它使工程师可以围绕体系结构考虑进行调整。 在使用相互依赖的系统时，它有助于分析可行性。 SLO还可以通过确定概述SLO时要使用的SLI来帮助工程团队平衡技术活动，权衡取舍并纳入业务考虑因素。

SLI是指标。 讲述故事的数字。 SLI代表服务水平指示器。 一些SLI（例如吞吐量，延迟，可用性和容量）非常常见。 这些指标涉及服务器如何承受负载。 您可以针对每个系统或子系统以不同的方式监视SLI。

错误的SLI选择可能会使工程师对用户的实际经验有非常错误的了解。 区分用户行为的一种方法是将它们划分为源自已认证和未经认证的请求，并监视每个请求的不同参数。 读写请求可以与只读请求分开处理。 清单继续。

这些用户中的每一个都有不同的期望，因此需要针对不同的参数进行测量。 这些用户的业务含义也不同。 故障和瓶颈对接口的影响会影响不同类别的用户，这是决定在哪里进行工程设计的重要方面。 如果SLI可以准确地衡量用户的行为，那么它在更大的事情方案中将起到更加积极的作用。

综上所述，
1. SLI是工程师交流有关系统的定量数据的方法。
2. SLO旨在提供使用SLI定义的一定级别的服务。 3.在了解团队采用的SLO的基础上交换SLA。 4.如果这些定义中未包括用户行为，则它们仍然存在缺陷。

感谢Priit ，感谢他们阅读草稿并帮助编辑该帖子。

图标礼貌Freepik从www.flaticon.com下， CC 3.0许可。

翻译自: https://www.javacodegeeks.com/2018/12/engineers-guide-sla-slo-sli.html