服务质量指标(SLI)、服务质量目标(SLO)、服务质量协议(SLA) 这三项分别是指该服务最重要的一些基础指标、这些指标的预期值,以及当指标不符合预期时的应对计划 大部分服务都将请求延迟—处理请求所消耗的时间——作为一个关键SLI (a)其他常见的SLI包括错误率(请求处理失败的百分比)、系统吞吐量(每秒请求数量)等 (b)可用性(availability)是另外一个SRE重视的SLI,代表服务可用时间的百分比 (c)运维行业经常用9的数量来描述可用程度。例如,99%可用性被称为“2个9”,99.999%被称为“5个9”。目前Google 云计算服务公开的可用性指标是“3.5个9”—99.95% 可用 SLO是服务质量目标(Objective):服务的某个SLI的目标值,或者目标范围。SLO的定义是SLI≤目标值,或者范围下限≤SLI≤范围上限 区别SLO和SLA的一个简单方法是问“如果SLO没有达到时,有什么后果?” 究竟如何来识别哪些指标对服务是最重要:理解用户对系统的真实需求才能真正决定哪些指标是否有用 (a)用户可见的服务系统,例如莎士比亚搜索服务的前端服务器通常关心可用性、延迟,以及吞吐量。换句话说:是否能正常处理请求?每个请求花费的时间是多少?多少请求可以被处理? (b)存储系统通常强调:延迟、可用性和数据持久性。换句话说:读写数据需要多少时间?我们是否可以随时访问数据?数据是否一段时间内还能被读取? (c)大数据系统,例如数据处理流水线系统,一般来说关心吞吐量和端到端延迟。换句话说:处理了多少数据?数据从输入到产出需要多少时间? (d)所有的系统都应该关注:正确性。是否返回了正确的回复,是否读取了正确的数据,或者进行了正确的数据分析操作。正确性是系统健康程度的一个重要指标,但是它更关注系统内部的数据,而不是系统本身,所以这通常不是SRE直接负责的。 大部分指标都应该以“分布”,而不是平均值来定义。例如,针对某个延迟SLI,某些请求可能很快,其他的可能会很慢,有时候会非常慢。简单平均可能会掩盖长尾延迟和其中的变化 建议标准化一些常见的SLI,以避免每次都要重新评估它们。任何一个符合标准定义模板的服务可以不需要再次自己定义SLI。 (a)汇总间隔:每1分钟汇总一次 (b)汇总范围:集群中的全部任务 (c)度量频率:每10秒一次 (d)包含哪些请求:从黑盒监控任务发来的HTTP GET请求 (e)数据如何获取:通过监控系统获取服务器端信息得到 (f)数据访问延迟:从收到请求到最后一个字节被发出 为了节约成本,应该为常见的指标构建一套可以重用的SLI模板,从而使得理解每个SLI更简单。 选择目标SLO (a)不要仅以目前的状态为基础选择目标 (b)保持简单 (c)避免绝对值:要求系统可以在没有任何延迟增长的情况下无限扩张,或者“永远”可用是很诱人的,但是这样的要求是不切实际的 (d)SLO越少越好:仅仅选择足够的SLO来覆盖系统属性,一定要确保每一个SLO都是必不可少的 (e)不要追求完美 SLO可以建立用户预期 (a)留出一定的安全区:对内使用更高的SLO,对外使用稍低的SLO可以留出一些时间用来响应问题 (b)实际SLO也不要过高
转载请注明原文地址:https://blackberry.8miu.com/read-6947.html