101 lines
3.1 KiB
Markdown
101 lines
3.1 KiB
Markdown
# 第四章 服务质量目标
|
||
|
||
本章描述了SRE团队在指标建模、指标选择以及指标分析上采用的基本框架。
|
||
|
||
## 服务质量术语
|
||
|
||
- 指标 `SLI(Service Level Indicator)`
|
||
服务质量指标是一个服务的某项服务质量的具体量化指标。
|
||
|
||
- 目标 `SLO(Service Level Objective)`
|
||
服务质量目标是服务的某个SLI的目标值或目标范围。SLO的定义是 SLI≤目标值，或范围下限≤SLI≤范围上限。
|
||
|
||
- 协议 `SLA(Service Level Agreement)`
|
||
服务质量协议是服务与用户之间的一个明确的或者不明确的协议。描述在达到或者未达到SLO之后的后果。
|
||
|
||
## 指标`SLI`在实践中的应用
|
||
|
||
常见服务的几大类SLI
|
||
|
||
- 用户可见的服务系统
|
||
通常关心可用性、延迟、吞吐量
|
||
|
||
- 存储系统
|
||
通常强调: 延迟、可用性、数据持久性
|
||
|
||
- 大数据系统
|
||
通常关心吞吐量和端到端延迟
|
||
|
||
- 所有系统
|
||
都关注正确性
|
||
|
||
### 收集指标
|
||
|
||
指标收集分为服务端和客户端。服务端主要依靠监控系统(promethues)和日志分析系统，客户端主要依靠页面埋点和其他收集系统(如专门收集手机app指标的系统)。
|
||
|
||
对于大部分指标，汇总时应当以“分布”而不是平均值来定义。
|
||
|
||
### 指标标准化
|
||
|
||
应该标准化一些常见的SLI，任何符合标准定义模板的服务可以直接使用而不需要再次评估定义。
|
||
|
||
- 汇总间隔
|
||
- 汇总范围
|
||
- 度量频率
|
||
- 包含的请求
|
||
- 数据获取方式
|
||
- 数据访问延迟
|
||
|
||
## 目标`SLO`在实践中的应用
|
||
|
||
应从用户最关心的方面入手而不是从能度量什么入手。先制定目标，从而反推出指标`SLI`。
|
||
|
||
### 目标定义
|
||
|
||
定义SLO的几个要素：
|
||
|
||
- SLO应该具体指出其是如何度量的，以及有效条件。
|
||
|
||
- 应该使用错误预算而不是要求SLO能被100%满足。
|
||
|
||
- 通过每日(周)对SLO达标成都的监控可以展示一个趋势，在重大问题发生器得到预警。
|
||
|
||
- SLO不达标的频率与错误预算进行对比，利用差值来指导新版本的发布。
|
||
|
||
### 目标的选择
|
||
|
||
选择目标SLO不是一个纯粹的技术活动，因为这里还涉及产品及业务层的决策，SLI和SLO(甚至SLA)的选择都应直接反应该决策
|
||
|
||
选择目标的几点要素：
|
||
|
||
- 不要仅以当前状态为基础选择目标
|
||
- 保持简单
|
||
- 避免绝对值
|
||
- SLO越少越好
|
||
- 不追求完美
|
||
- 小心使用SLO
|
||
|
||
### SLI和SLO作为控制手段
|
||
|
||
SLI和SLO在决策系统运维是非常有用：
|
||
|
||
1. 监控并度量系统的SLI
|
||
2. 比较SLI与SLO以决定是否需要执行操作
|
||
3. 如果需要操作，决定执行什么操作以满足目标SLO
|
||
4. 执行操作
|
||
|
||
### 使用SLO建立用户预期
|
||
|
||
用户经常希望知道他们可以预期的服务质量以便理解服务是否能够满足他们的需求，通过公布SLO可以设置用户对系统的预期。
|
||
|
||
使用以下策略让用户拥有正确的预期：
|
||
|
||
- 留出一定的安全区
|
||
|
||
- 实际SLO不要过高
|
||
|
||
## 协议`SLA`在实践中的应用
|
||
|
||
由业务部门和法务部门选择合适的后果条款，SRE帮主这些部门理解SLA和SLO达标的概率和困难程度。
|
||
|
||
最好在用户宣传方面偏于保守。 |