读书笔记（SRE：Google运维解密）：第4章 服务质量目标

• 服务质量指标（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也不要过高