无论是对外提供 IaaS PaaS SaaS 的云公司，还是提供信息技术服务的乙方公司，亦或是金融 制造等各行各业的数据中心、运维部门，我们的一个非常重要的合同承诺或考核评估指标就是：SLA（即：Service-Level Agreement 服务等级协议）。
而真正落地实现 SLA 的精确测量，最广为人知的就是 Google 的 SRE 理论。
在 Google，会明确区分 SLO 和服务等级协议 （SLA）。SLA 通常涉及向服务用户承诺，即服务可用性 SLO 应在特定时间段内达到特定级别。如果不这样做，就会导致某种惩罚。这可能是客户为该期间支付的服务订阅费的部分退款，或者免费添加的额外订阅时间。SLO 不达标会伤害到服务团队，因此他们将努力留在 SLO 内。如果您要向客户收取费用，则可能需要 SLA。
SLA 中的可用性 SLO 通常比内部可用性 SLO 更宽松。这可以用可用性数字表示：例如，一个月内可用性 SLO 为 99.9%，内部可用性 SLO 为 99.95%。或者，SLA 可能仅指定构成内部 SLO 的指标的子集。
如果 SLA 中的 SLO 与内部 SLO 不同（几乎总是如此），则监控必须显式测量 SLO 达标情况。您希望能够查看系统在 SLA 日程期间的可用性，并快速查看它是否似乎有脱离 SLO 的危险。
您还需要对合规性进行精确测量，通常来自 Metrics、Tracing、Logging 分析。由于我们对付费客户有一组额外的义务（如 SLA 中所述），因此我们需要将从他们那里收到的查询与其他查询分开进行度量。这是建立 SLA 的另一个好处 — 这是确定流量优先级的明确方法。
定义 SLA 的可用性 SLO 时，请注意将哪些查询视为合法查询。例如，如果客户因为发布了其移动客户端的错误版本而超出配额，则可以考虑从 SLA 中排除所有"超出配额"的响应代码。
SLI 是经过仔细定义的测量指标，它根据不同系统特点确定要测量什么。
常见的 SLI 有：
SLO（服务等级目标）指定了服务所提供功能的一种期望状态，服务提供者用它来指定系统的预期状态。SLO 里不会提到，如果目标达不到会怎么样。
SLO 是用 SLI 来描述的，一般描述为：
比如以下SLO：
设置 SLO 时的目标依赖于系统的不同状态(conditions)，根据不同状态设置不同的SLO：
总 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …
为什么要有 SLO，设置 SLO 的好处是什么呢？
SLA = SLO + 后果
总 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + … SLA = SLO + 后果
常见于通过 处理请求的服务或 API 提供的服务（如：对象存储 或 API 网关）
如果有前端 js 探针监控，或拨测监控，那么可以用前端用户体验 Apdex 作为 SLO。
Apdex 定义了一个性能标准，将应用程序用户分为三个组:
例如，作为前端应用程序的 SLO，您可以指定希望 90% 的用户 Apdex 都是 满意 。
如，My WebApp Apdex 公式如下：
100% * (apps.web.actionCount.category:filter(eq(Apdex category,SATISFIED)):splitBy("My WebApp")) / (apps.web.actionCount.category:splitBy("My WebApp"))
衡量手机 App (iOS 和 Android) 的可用性和可靠性的最重要指标之一是 无崩溃用户率。指的是没有崩溃的情况下打开并使用移动 APP 的用户百分比。
因此，公式示例如下：
apps.other.crashFreeUsersRate.os:splitBy("My mobile app")
拨测可用性 SLO 表示拨测处于可用状态下的时间百分比，或者，成功拨测占执行的总测试数的百分比。
因此，公式示例为：
(synthetic.browser.availability.location.total:splitBy("My WebApp"))
成功率 = 成功的请求调用次数 / 总的请求调用次数
如：My service 的 成功率：
100% * (service.requestCount.successCount:splitBy("My service"))/(service.requestCount.totalCount:splitBy("My service"))
那么，如果 My service 的关键 API 或请求需要计量，就可能是下面的公式：
(100%)*(service.keyRequest.successCount:splitBy(type("SERVICE_API") AND entityId("POST /login")))/(service.keyRequest.totalCount:splitBy(type("SERVICE_API") AND entityId("POST /login")))
ℹ️ 提示:
成功的请求最简单的一种方式是：http 状态码为 2xx 或 3xx 的请求即视为成功。
还有一种，请求执行过程中没有抛出错误（日志或异常）的请求视为成功。
重点在于性能。
服务性能 SLO 表示 「fast」 服务调用占服务调用总数的百分比，其中 「fast」使用自定义条件定义。例如：
ℹ️ 提示:
当然，上边的 3s 也不应该是拍脑袋想的，而应该是例如基于过去一个月系统正常运行时 99% 百分位数的响应时间。
公式示例为：
(service:fastRequests:splitBy("My WebApp")) / (service:totalRequests:splitBy("My WebApp"))
错误率：是在给定的一小时间隔内，DB 的失败 SQL 执行次数除以总 SQL 执行次数。
读错误率：是在给定的一小时间隔内，DB 的失败查询 SQL 执行次数除以总 SQL 执行次数。
公式示例为：
可用性 % = 100% - Average DB Error Rate
或：
读可用性 % = 100% - Average DB Read Error Rate
吞吐量失败的请求：是指请求尚未超过给定 DB 吞吐量，却被 DB 吞吐量限制，导致错误码
吞吐量错误率：是在给定的一小时间隔内，给定 DB 的吞吐量失败请求总数除以总请求数。
那么，公式示例为：
吞吐量目标% = 100% -平均吞吐量错误率
SLI 为：
一致性违规率：是指在给定的 DB 中，在给定的一小时间隔内，对所选的一致性级别(按总请求数划分)执行一致性保证时无法发送的成功请求。
select 1 from dual) 执行时间的 99% 百分位响应时间。那么，示例公式为：
延迟目标% = 100% - 总的延迟时间和的次数 / (DB 总使用时间/1H）
如：过去 1 个月，总的延迟时间和的次数为 50 次，分母为：30 * 24 / 1 = 720
那么：延迟目标% = 100% - 50 / 720 ≈ 93%
就是成功的消息除以 MQ 接收的总消息。
公式示例为：
(100)*((mq.rabbitmq.queue.requests.successful:splitBy("payment"))/mq.rabbitmq.queue.requests.incoming:splitBy("payment")))
例如，每小时正常运行时间百分比 = 100% - 单个 Host 实例处于不可用状态的总时间（没有超过多长时间才算不可用一说）百分比
不可用的定义可以是：
K8S 类是一类综合系统，需要考虑如下目标
大致也是类似上边的可用性目标。
这个通常非常高，比如：99.999999999%
可以简单粗暴认为：只要有数据丢失的情况，就是没达到目标。
典型案例就是腾讯的那次。
以 NAT 网关为例：
单实例服务不可用分钟数： 当某一分钟内，NAT 网关实例出方向所有数据包都被 NAT 网关丢弃时，则视为该分钟内该 NAT 网关实例服务不可用。在一个服务周期内 NAT 网关实例不可用分钟数之和即服务不可用分钟数。
可以根据不同的层次、组件设定不同的 SLO。
SLO 的监测是需要监控工具的支持。
常用的 SLO 包括：
EOF
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.