SRE心里话:要求100%服务可用性就是老板的无知

开发 架构
服务于内部的基础设施,比如 BigTable 这样的服务,没有终端用户,那谁来拍板?基础设施类服务,通常是服务于内部其他服务的,此时应该是 BigTable 的研发团队和上游服务所有者一起拍板,制定 SLO。

服务可用性必须100%?其实完全没必要

一个服务客户的产品,不需要追求极端的可用性,因为实在是没有必要。比如一个论坛服务,用户使用智能手机来访问,手机本身有可能故障,手机的蜂窝网络可能出问题,如果用的 wifi 本地路由器可能出问题,小区宽带可能出问题,运营商的骨干网可能出问题,这些都不是论坛服务能够控制的。简单来说,用户在一个有着 99% 可靠性的智能手机上,是不能分辨出 99.99% 和 99.999% 的服务可靠性的区别的。

高可靠性带来高成本

99.99% 的可用性,每年不可用时长不能超过 53 分钟,如果是 99.999% 的可用性,每年不可用时长不能超过 5.3 分钟。多了一个 9,不可用时长只是缩减了 47.7 分钟,但是付出的成本可能是巨大的,需要衡量 ROI 是否值得。成本通常来自两个方面:

  • 冗余物理服务器/计算资源的成本
  • 机会成本

机会成本是说,我们把过多的人力投入到稳定性建设上了,导致投入到业务功能开发的人力就变少了,这个机会成本是很难估量的,但是很重要。

如何度量可用性

通常的做法是按照计划外停机时间来度量,比如:

可用性 = 系统正常运行时间 / (系统正常运行时间 + 系统计划外停机时间)

这个计划外停机时间,通常是指系统不可用的时间,比如系统崩溃了,或者系统的某个功能不可用了,或者系统的某个功能的性能下降了,都可以算作计划外停机时间。与计划外停机时间相对的,显然是计划内停机时间,偶尔通知用户,说凌晨3点我会做系统升级,计划停机3分钟,这个3分钟就是计划内停机时间,这3分钟内的不可用,不影响SLA。

但是,很多系统都是分布式的,尤其是 Google,一个服务,通常不会完全不可用,可能某个 region 不可用,但是其他 region 还可用,所以,大型互联网公司的服务通常是不会 100% 不可用的,可能会部分不可用,此时这个计划外停机时间就不好计算了。怎么办?使用请求数量来统计,可用性计算公式变成:

可用性 = 成功请求数 / 总的请求数

这是服务可用性的度量方法,一个大型互联网公司可能有几千个微服务,老板问技术团队,咱们今年的可用性如何?显然没法使用服务层面的数据,那就把众多微服务做个加权平均?也不那么说得通!那公司整体业务的 SLO 应该怎么算?一般是看业务指标,分享一下滴滴的做法,滴滴最核心的业务就是打车,核心就看打车的订单量,如果订单量下跌 10%,就开始计算不可用时长,这是整个公司最重要的可用性指标。这种指标称为北极星指标,我们现在创业就专门做了一个北极星指标的产品,对北极星指标做 VIP 级别的保障。详情可以了解这里

谁来制定SLO?

在 Google,对于服务于终端用户的产品,通常有个产品技术团队,是这个服务的「商业所有者」,这个团队明确知道自己的商业目标,可以拍板 SLO。因为:SLO 最终是服务于商业目标的!

通常来讲,线上 70% 的故障是变更导致的,更好的 SLO 意味着线上变更的频率会降低,但是低频的变更,就意味着有些功能 feature 不能尽快发布给终端用户,终端用户的体验就会变差,竞争对手可能有更花哨好用的功能,我们无法及时跟进。那好,那就更快的变更,更快的变更通常意味着稳定性变差,所以就需要权衡了,这本质上是一个商业取舍,所以,需要商业所有者来拍板。而这个商业所有者,对于服务于终端用户的产品,通常就是产品团队,最终可能是这个业务的负责人最终拍板。

服务于内部的基础设施,比如 BigTable 这样的服务,没有终端用户,那谁来拍板?基础设施类服务,通常是服务于内部其他服务的,此时应该是 BigTable 的研发团队和上游服务所有者一起拍板,制定 SLO。

BigTable 可能同时服务两类上游服务,举例:一类上游服务是面向终端用户的,他们需要更低的延迟,另一类上游服务可能是离线任务,在 BigTable 里存储离线分析数据,他们需要更大的吞吐。低延迟的上游服务希望 BigTable 的请求队列(几乎总是)为空,这样系统可以立刻处理每个出现的请求。而离线分析的上游服务,需要更高的吞吐,希望 BigTable 繁忙,希望请求队列永远不为空。如果拿请求队列长度作为 SLO,就尴尬了…

所以,对于差异化要求比较大的基础设施,通常会拆分成不同的集群,提供不同维度的 SLO。

提升 SLO 的时候要注意 ROI

举个例子,假设某个服务每一个请求的价值是一样的:

  • 可用性目标希望从 99.9% 提升至 99.99%
  • 增加的可用性:0.09%
  • 服务收入:100万美金
  • 改进可用性后的价值:100万 * 0.09% = 900 美金

可用性提升一个 9,收益是 900 美金,如果提升一个 9 的成本低于 900 美金,就是划算的,如果高于 900 美金,就是不划算的。

SLO和错误预算构建过程

  • 产品管理层定义一个 SLO,确定一项服务在每个季度预计的正常运行时间
  • 实际在线时间是通过一个中立的第三方来测算的:我们的监控系统
  • 这两个数字之间的差值就是这个季度中剩余的不可靠性预算
  • 只要测算出的正常在线时间高于 SLO,也就是说,只要仍然有剩余的错误预算,就可以发布新的版本
责任编辑:武晓燕 来源: SRETalk
相关推荐

2009-08-10 10:23:22

基层员工福利通信员工

2024-08-13 15:42:19

2020-03-09 09:56:13

高并发高可用架构

2014-06-03 10:21:13

服务器服务器可用性

2012-09-07 09:57:14

2024-02-27 09:48:25

Redis集群数据库

2013-12-06 15:31:49

TechEd2013

2020-07-29 08:30:48

微服务架构数据

2012-02-13 23:20:18

linux集群高可用

2017-08-24 17:05:06

2013-02-01 14:13:41

服务器内存可靠性可用性

2012-07-04 11:21:07

OpenStack

2015-05-13 16:18:14

邮箱大师网易

2009-06-27 18:32:00

评估Exchange可用性

2011-02-17 08:49:49

WebHTMLCSS

2013-11-19 17:50:33

Linux辅助软件

2009-04-16 15:34:35

SQL Server

2016-07-14 10:38:51

2014-05-14 09:43:01

SUSE私有云

2012-09-04 13:43:31

SQL Server
点赞
收藏

51CTO技术栈公众号