在线服务的目标应该是提供与业务需求匹配的可用服务。此流程的关键部分应该涉及组织中的不同团队,例如,从业务开发团队到工程团队。
要验证一个服务如何符合这些目标,可以用这些目标可衡量的“成就”来定义“阈值”,例如,“服务必须在 99.9% 的时间内可用”,这应该与用户的期望和业务连续性相匹配。
SLA, SLO, SLI
已经有很多关于这些话题的文章,如果你不熟悉这些术语,我强烈建议你先阅读谷歌关于 SLO(服务级别目标) 的 SRE 书籍中的文章。
总而言之:
-
SLA:服务水平协议
-
你承诺向用户提供的服务,如果你无法满足,可能会受到惩罚。
-
例如:“99.5%”的可用性。
-
关键词:合同
-
-
SLO:服务水平目标
-
你在内部设置的目标,驱动你的测量阈值 (例如,仪表板和警报)。通常,它应该比 SLA 更严格。
-
示例:“99.9%”可用性 (所谓的“三个 9”)。
-
关键字:阈值
-
-
SLI:服务水平指标
-
你实际测量的是什么,以确定你的 SLO 是否在满足目标 / 偏离目标。
-
示例:错误率、延迟。
-
关键词:指标。
-
SLO 关注时间
99% 的可用性意味着什么?它不是 1% 的错误率 (失败的 http 响应的百分比),而是在一个预定义的时间段内可用服务的时间百分比。
在上面的仪表板中,服务在 1 小时内的错误率超过 0.1% (y 轴为 0.001)(错误峰值顶部的红色小水平段),从而在 7 天内提供 99.4% 的可用性:
这一结果中的一个关键因素是你选择度量可用性的时间跨度 (在上面的示例中为 7 天)。较短的周期通常用作工程团队 (例如 SRE 和 SWE) 的检查点,以跟踪服务的运行情况,而较长的周期通常用于组织 / 更广泛的团队的评审目的。
例如,如果你设置了 99.9% 的 SLO,那么服务可以停机的总时间如下:
-
30 天:43 分钟 (3/4 小时)
-
90 天:129 分钟 (~2 小时)
另一个无关紧要的“数字事实”是,给 SLO 多加一个 9 都会产生明显的指数级影响。以下是 1 年的时间跨度的时间组成部分:
-
2 个 9: 99%: 5250min (87hrs 或 3.64 天)
-
3 个 9: 99.9%: 525min (8.7hrs)
-
4 个 9: 99.99%: 52.5min
-
5 个 9:99.999%:5min< - 经验法则:5 个 9 -> 5 分钟 (每年)
输入错误预算
在服务可以停机的允许时间内,上面的数字可能被认为是错误预算,你可以从以下事件中消耗这些错误预算: