A. 运维体系 --- SLA理论体系

A. 运维体系 — SLA理论体系

概述：SLA，是服务供应商与客户之间的服务等级协议，它定义了服务供应商应保证的服务质量，以及在服务不达标情况下的服务赔偿。SLA在定义上又细分为SLI、SLO与SLA。

• SLI，服务质量指标，服务的某项质量的一个具体的量化指标。
• SLO，服务质量目标，服务的某项SLI的具体目标值，或者目标范围。
• SLA，服务质量协议，描述在服务不达SLO情况下的后果。

SLA的收益

• 3.1 增强运行态的确定性：SLA可以帮助构建线上运行态的确定性，让产品从“能够正常对外提供服务”跨度到“能主动控制服务状态”
  • 在服务能力明确的基础上，产品能明确自身的短板，能以最优的资源投入产出比提升服务质量。一个简单的例子就是：某服务可用性从99.9%提升到99.99%所需的资源和带来的收益之比，是决定该服务是否应该提供4个9的重要依据。
  • 在服务能力明确的基础上，产品能增强对突发情况的应对能力。合适的SLI指标能帮助产品在故障发生时进行更好的决策，产品有能力在资源不足时去选择舍弃哪些服务。
  • 在服务能力明确的基础上，产品能给用户提供差异化的服务，进而节省成本。Google SRE认为，基础设施服务运维的关键战略就是明确划分服务水平，从而让客户在构建系统时能够进行正确的风险和成本权衡。
• 3.2 建立用户预期：从用户的视角来看，SLA可以帮助用户建立对服务质量的预期。这可以避免用户对某项服务的过度依赖，甚至会左右用户的技术方案和架构设计。
  • 为了避免用户对服务的过度依赖，Google SRE会保证服务能达到预定义的SLO，但也确保不会大幅超出该SLO，在SLO的可控范围内，SRE甚至会安排计划内的停机，以找出不合理的服务过度依赖，因此我们建议每个产品在周期内试图用光错误预算。
• 3.3 错误预算
  • 错误预算，可以用来平衡稳定性与创新迭代速度之间的关系。错误预算定义了某个服务在一段时间内的稳定性目标，错误预算是通过1-SLO得出来，对于某个99.99%可用性目标的服务具有0.01%的错误预算。错误预算在Google内部帮助了产品研发部门与SRE之间建立了良好的合作关系，只有该产品在本周期内没有用光这错误预算，才允许进行变更或发布。

SLA实践

• 4.1 如何描述服务质量？
  • 基于时间的SLO计算
    • 可用性 = 系统正常运行时间 / 统计周期内的总时间
    • 可用性 = 系统达标时间 / 统计周期内的总时间
      • 关键问题就在于如何定义产品不可用。比如ECS在对外的可用性承诺中，不可用包含三种场景：宕机、磁盘不可用、网络不可用。对于服务型的不可用，一个很容易想到的点是请求成功率，这是一个基于产量的指标，这类指标一般通过滚动时间窗口来计算，
      • 比如一天内成功请求的比率。但这个时间窗口越长，越能起到平滑的作用，比如某接口在某天的成功率是99.99%，这一天调用了1亿次，失败了1万次，乍一看99.99%的成功率很高，但可能1万次失败集中在某半小时内，而这半小时确实影响到了用户。因此我们希望这个时间窗口能缩小到秒级或分钟级，我们定义在每个小时间片内的成功率要求，如果达标则认为该时间片可用，
• 4.2 如何梳理产品的服务指标？
  • LESS IS MORE：指标要少而精
  • 客户视角/系统边界：一个平台常常拥有比较清晰的客户界面或系统边界，可以屏蔽掉内部的复杂逻辑。
    • 对于一个WEB应用，最值得关注的是UI界面。比如页面的完整度，加载延迟，ajax请求成功率等等；
    • 对于一个后端服务，最值得关注的就是API服务。比如搜索业务域，内部系统错综复杂，但是搜索对外提供的服务，比如给导购，主搜提供的服务，都集中在tisplus与tpp应用中，因此首先需要关注tisplus与tpp的服务能力。
  • 故障视角：从故障视角，我们能理出业务域内最核心的服务。集团每个BU都有严格的故障等级定义，我们需要知道哪些服务不可用会引发自身BU或其他关联BU的故障。
  • 依赖视角：在分布式环境下，整个系统被拆分成越来越多的子系统，每个子系统又被其他若干子系统依赖或依赖于其他子系统。在这种环境下，依赖的服务能力会直接或间接的影响到产品自身对外的服务能力，因此产品需要去关心依赖对自身的服务能力，强依赖也往往需要保证更高的SLO。
• 4.3 有哪些常见的服务指标？
  • 黄金指标-延迟/成功率
    • 延迟：延迟是常见的一项性能指标，可以针对延迟设置SLO，比如99.9%的延迟在10ms内，这是对用户的直观感受，非常有意义。
    • 流量：QPS也是经常关注的一项监控指标，但是QPS是由用户行为决定的，我们不能针对QPS设置一个SLO，但是QPS跟延迟是有相关性的，QPS的升高很大程度上也会引起延迟的升高。
    • 错误：错误是一项常用的可用性指标，错误又可以分为显式失败(例如HTTP的500)，或隐式失败(例如业务侧的错误码)，产品可以细分不同的错误码建立不同的SLO目标。
    • 饱和度：饱和度用以描述服务的容量水位，比如CPU利用率。但是从用户侧来看，饱和度是服务端行为，并不能直接通过饱和度描述服务对用户的影响，同时与QPS类似，饱和度的升高也会体现在延迟上。
  • 性能：SLA相比于传统监控的不同点，在于更关注指标长期的变化。性能SLO，能帮助我们对比服务更新前后的状态变化，比如新的版本或架构升级，是不是让系统运行更快更稳定了？每个产品都可以根据自身特性来定义性能SLO，常见的性能指标有：
    • 响应时间。比如ConfigServer 99.9%的客户端查询响应时间；
    • 容量。容量是服务端的服务能力，测量可能需要依靠压测等手段，比如MQ Broker 支持100万并发链接请求；
    • 实效性。比如Diamond 99.9%配置推送延迟，比如ConfigServer 99.9%数据变更推送延迟；
  • 可用性：可用性是最常提及的服务指标，常见的是成功率/错误率，与运行时间。
    • 成功率/错误率。成功率/错误率在上文黄金指标中已有讲述；
    • 可用时间。在基于时间的SLO计算模型下，实际上SLO就是按照可用时间运算的，因此产品只需要关心什么情况下产品不可用，可用时间这项数据会在周期性计算SLO时自动聚合得出。
  • 可靠性：可靠性常常是针对存储一类产品而说的，更细致的又可以分为数据准确性、数据完整性、数据一致性、数据可访问性等等。
• 4.4 如何选择指标数据源？
  • 客户端：SLA是对客户承诺的服务能力，因此从客户端获取指标数据是最有意义的。由于接入成本大，一般采用采样的方法
  • 服务端：服务端的指标数据是必不可少的，也是产品负责人最关心的一部分数据，当服务端数据异常时，很大可能性就是产品服务出问题了。
  • 巡检/探针：巡检/探针既可以直接探测前端，又可以探测后端的服务，完全模拟用户侧的请求。
• 4.5 如何度量指标？
  • 监控SLI的要求
    • 实时性。监控数据的实时性，是秒级延迟，还是分钟级？
    • 准确性。数据度量的精度，精确到几位小数？是精确值还是数据拟合？指标数据能否真实反映服务能力？
    • 完整性。数据完整度如何，有无数据缺失？异常数据如何处理？
    • 稳定性。在灾难场景下，监控自身能否正常工作？
  • 使用AliMetrics：常见的监控方式有三类：Metrics、Log以及Tracing
  • 自定义监控
• 4.6 如何设置度量的精度？
  • 服务的不同SLO目标要求，应该以不同的精度去度量。比如对于月可用性要求99.99%的服务来说，不可用时长4.32min，如果按照1min的采样周期，则只要出现5个坏点就达不到SLO，这样的采样精度是明显不够的。又比如对于要求99.9%的服务，如果按照5s的采样周期，又会过于频繁而增加计算及存储的成本。在集团内我们一般要求有四个九的可用性，同时考虑到太长的采样周期可能会错失一些峰值现象或毛刺，因此我们推荐使用5s、15s、30s、60s这几类周期，具体视产品情况而定。
• 4.7 如何设置服务质量的目标？
  • 软件系统不需要一味追求100%的可用性，如果以按月的SLO周期计算，99.999%与100%的可用性只相差25.9秒，对于最终用户来说，99.999%与100%的可用性可能并没有实际的区别，过于追求可用性，可能会带来成本的急剧上升，同时也会限制产品的创新速度。那么设置多少的可行性目标呢，这其实并不是一个技术问题，而是一个产品问题，产品需要回答好以下几个问题：
    • 基于用户的使用习惯，服务可用性要达到什么程度才能让用户满意？
    • 如果这项服务的可用性不够，用户是否有其他替代的选择？
    • 服务的可用性高低，会不会影响用户对这项服务的使用模式？
• 4.8 如何以SLO驱动服务质量提升？
  • SLA不是静态文档，不是一成不变的。实际生产过程中，业务需求、技术环境、工具流程等都在不断更新迭代，因此实际应用中，SLA应该包括一个修改框架，定期审查更新SLA，并长期追踪SLA的变化。
  • 在明确上述问题的基础上，我们就能总结出一套SLA的常规玩法：
    • 梳理平台架构，理清系统架构与边界；
    • 确定平台的服务能力指标，透传指标；
    • 度量指标，形成当前服务能力基线；
    • 为每项SLI定义目标SLO，监控跟踪SLO；
    • 记录并公示SLI与SLO；
    • 迭代不断优化，不断微调提升SLO；