服务质量指标(SLI)、服务质量目标(SLO),服务质量协议(SLA)
这三项分别是指该服务最重要的一些基础指标、这些指标的预期值，以及当指标不符合预期时的应对计划。事先选择好合适的指标有助于在故障发生时帮助SRE进行更好地决策，同时也为SRE团队判断系统是否正常工作提供帮助。
SLI 服务质量指标：
该服务的某项服务质量的一个具体量化指标。
大部分服务都将请求延迟——处理请求所消耗的时间——作为一个关键的SLI。其他常见的SLI也包括错误率（请求失败的百分比）、系统吞吐量（每秒请求数量）等。这些质量通常是汇总过的；在某一个度量时间范围内将原始数据收集起来，计算速率、平均值、百分比等汇总数据。
理想情况下，SLI应该直接度量某一个具体的服务质量。但是很多时候，直接度量信息 可能非常难以获取，或者无法观测，我们只能用某种指标来替代。例如，客户端的延迟数据经常是最直接的用户指标，但是由于条件限制可能只能监控服务器端的延迟数据。
对数据存储系统来说，持久性数据能够完整保存的时间也是一个重要指标。虽然100%的“可用性”是不可能实现的，但是接近100%的可用性指标是 可以实现的一个目标。运维行业经常用9的数量来描述可用程度。例如，99%可用性被 称为“2个9”,99.999%被称为“5个9”。目前Google云计算服务公开的可用性指标是“3.5 个9”—— 99.95%可用。
目标
SLO是服务质量目标(Objective):服务的某个SLI的目标值，或者目标范围。SLO的 定义是SLI≤目标值，或者范围下限≤SLI≤范围上限
协议
SLA是服务质量协议(Agreement):指服务与用户之间的一个明确的，或者不明确的协议，描述了在达到或者没有达到SLO之后的后果。这些后果可以是财务方面的退款或者罚款，也可能是其他类型的。区别SLO和SLA的一个简单方法是问“如果 SLO没有达到时，有什么后果?”如果没有定义明确的后果，那么我们就肯定是在讨论 一个SLO,而不是SLA 。
SRE通常不会参与SLA的书写，因为SLA是与业务产品的决策紧密相关的。但是， SRE确实会参与帮助避免触发SLA中的惩罚性条款。同时，SRE会参与制定具体的 SLI:很明显，提供一个客观的方式来度量SLO是很重要的，否则大家就会产生分歧。
在讨论SLA的大部分时候，实际上是在讨论SLO。如果某个人说道“违反SLA”,实际是指没有达到SLO,真实的“违反SLA”可能会触发一次违反合约的法律诉讼!
目标的选择
选择目标SLO不是一个纯粹的技术活动，因为这里还涉及产品和业务层面的决策，SLI和SLO(甚至SLA)的选择都应该直接反映该决策。同样的，有时候可能可以牺牲某些产品特性，以便满足人员、上线时间、硬件可用性，以及资金的限制。
1、保持简单
SLI中过于复杂的汇总模式可能会掩盖某种系统性能的变化，同时也更难以理解。
2、避免绝对值
3.SLO越少越好
应该仅仅选择足够的SLO来覆盖系统属性， 一定要确保每一个SLO都是必不可少的： 如果我们无法针对某个SLO达标问题说服开发团队，那么可能这个SLO就是不必要的。
4.不要追求完美
可以随着时间流逝了解系统行为之后优化SLO的定义。刚开始可以以一个松散 的目标开始，逐渐收紧。这比一开始制定一个困难的目标，在出现问题时放松要好得多。
如 果 S R E 团 队 无 法 说 服 研 发 团 队 接 受 任 何 一 个 S L O , 那 么 这 个 产 品 可 能 压 根 不需 要 S R E 团 队 的 支 持 。
控制手段
SLI和SLO在决策系统运维时也非常有用：
1. 监控并且度量系统的SLI。
2. 比较SLI和SLO,以决定是否需要执行操作。
3. 如果需要执行操作，则要决定究竟什么操作需要被执行，以便满足目标。
4. 执行这些操作。
琐事小结
如果我们都致力于每一周通过工程工作消除一点琐事，就可以持续性地整顿服务。我们 就可以将更多的力量投入到扩大服务规模的工程工作上去，或者是进行下一代的服务的 架构设计，又或者是建立一套跨SRE使用的工具链
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
