SRE实践

目录(SRE实践)

SRE

SRE 全称是 Site Reliability Engineering,最早是由 Google 提出,并且在其工程实践中发扬光大。 他们还出了一本同名书籍「Site Reliability Engineering」, 让这个理念在互联网工程师圈子里广泛传播。

Google 对 SRE 解释是(via Site Reliability Engineering - Wikipedia):

Site reliability engineering (SRE) is a discipline that incorporates aspects of software engineering and applies that to operations whose goals are to create ultra-scalable and highly reliable software systems.

有人认为 SRE 就是一个岗位,而且是一个具备全栈能力的岗位,只要有这么一个人,他就能解决所有稳定性问题。这还只是一种理解,而且这个理解多是站在管理者的角度

也有人站在运维人员的角度,认为做好 SRE 主要是做好监控,做到快速发现问题、快速找到问题根因;还有人站在平台的角度,认为做好 SRE 要加强容量规划,学习 Google 做到完全自动化的弹性伸缩;甚至还有人认为,SRE 就是传统运维的升级版,把运维自动化做好就行了。

你看,其实不同的人站在不同的角度,对 SRE 的理解就会天差地别,但是好像又都有各自的道理。

本文将从实践的角度来理解SRE: SRE 是一套体系化的方法,我们也只有用全局视角才能更透彻地理解它。

SRE体系

从全局视角来理解SRE体系

SRE实践

从上面这张图可以看出,为了保障系统的稳定性,我们需要做很多工作,这些能力之间的相互依赖,就决定了从职能分工上,SRE 体系的建设绝不是单个岗位或单个部门就能独立完成的,必然要求有高效的跨团队组织协作才可以。

从实践角度来看,SRE 的力量不能通过一个岗位、一个或几个技术就发挥出来。SRE 是一个体系化工程,它需要协同多个部门、多项技术。

SRE的目的

建设SRE体系是为了 提升稳定性

从业界稳定性通用的衡量标准看,有两个非常关键的指标:

  • MTBF,Mean Time Between Failure,平均故障时间间隔。

  • MTTR,Mean Time To Repair, 故障平均修复时间。

通俗地说,MTBF 指示了系统正常运行的阶段,而 MTTR 则意味着系统故障状态的阶段

提升稳定性

提升稳定性的手段:

  1. 提升 MTBF,也就是减少故障发生次数,提升故障发生间隔时长

  2. 降低 MTTR,故障不可避免,那就提升故障处理效率,减少故障影响时长。

从 SRE 稳定性保障规划图中,可以看出 MTTR 可以细分为 4 个指标:MTTI、MTTK、MTTF 和 MTTV。

  • MTTI (Mean Time To ldentify,平均故障发现时间),也就是从故障实际发生,到我们真正开始响应的时间。这个过程可能是用户或客服反馈、舆情监控或者是监控告警等渠道触发的。

  • MTTK (Mean Time To Know,平均故障认知时间),更通俗一点,可以理解为我们常说的平均故障定位时间。这个定位指的是root cause,也就是根因被定位出来为止。

  • MTTF (Mean Time To Fix,平均故障解决时间),也就是从知道了根因在哪里,到我们采取措施恢复业务为止。这里采取的手段就很多了,比如常见的限流、降级、熔断,甚至是重启。

  • MTTV (Mean Time To Verify,平均故障修复验证时间),就是故障解决后,我们通过用户反馈、监控指标观察等手段,来确认业务是否真正恢复所用的时间。

现在,我们再来看 SRE 稳定性保障规划这张图,你就会理解,为什么要把所做的事情分组分块呈现。目的就是区分清楚,我们做的任何一件事情、开发的任何一套系统、引入的任何一个理念和方法论,有且只有一个目标,那就是”提升 MTBF,降低 MTTR”,也就是把故障发生时间的间隔变长,将故障影响的时间减少。

比如,在 Pre-MTBF 阶段(无故障阶段),我们要做好架构设计,提供限流、降级、熔断这些 Design-for-Failure 的服务治理手段,以具备故障快速隔离的条件;还可以考虑引入混沌工程这样的故障模拟机制,在线上模拟故障,提前发现问题。

在 Post-MTBF 阶段,也就是上一故障刚结束,开启新的 MTBF 阶段,我们应该要做故障复盘,总结经验,找到不足,落地改进措施等。

在 MTTI 阶段,我们就需要依赖监控系统帮我们及时发现问题,对于复杂度较高和体量非常大的系统,要依赖 AIOps 的能力,提升告警准确率,做出精准的响应。

同时 AIOps 能力在大规模分布式系统中,在 MTTK 阶段也非常关键,因为我们在这个阶段需要确认根因,至少是根因的范围。

好了,按照以终为始的思路,SRE 要实现的目标就是”提升 MTBF、降低 MTTR”,从这个角度出发,我们再次认识到一定要把 SRE 作为一个体系化的工程来建设,因为单纯在某些技术点上发力是没有多大意义的。

系统可用性

衡量系统可用性的 2 种方式:

  • 时间维度:Availability = Uptime / (Uptime + Downtime)

  • 请求维度:Availability = Successful request / Total request

时长维度,是从故障角度出发对系统稳定性进行评估。

时间维度的可用性测量方法包含的三要素:

  • 衡量指标

  • 衡量目标

  • 影响时长

常见的按时长维度统计的可用性对照表:

系统可用性故障时间/年故障时间/月故障时间/周故障时间/天
90%36.5天72小时16.8小时2.4小时
99%3.65天7.2小时1.68小时14.4分钟
99.9%8.76小时43.8分钟10.1分钟1.44分钟
99.99%52.56分钟4.38分钟1.01分钟8.66秒
99.999%5.26分钟25.9秒6.05秒0.87秒

用时长维度来衡量系统稳定性的方式,其主要缺点就是粒度不够精细

请求维度,是从成功请求占比的角度出发,对系统的稳定性进行评估。

请求维度的可用性测量方法包含的三要素:

  • 衡量指标

  • 衡量目标

  • 统计周期

这种方式对系统运行状况是否稳定监管得更为严格,不会漏掉任何一次问题的影响,因为它对系统整体运行的稳定性判定,不仅仅会通过单次的异常影响进行评估,还会累计叠加进行周期性的评估。

故障一定意味着不稳定,但是不稳定,并不意味着一定有故障发生。

设立系统稳定性目标要考虑的3个因素:

  • 第一个,成本因素。 可用性越高,相应付出的成本就越高。比如为了更高的可用性,要有更多的冗余资源投入,甚至要做主备、双活甚至是多活。

  • 第二个,业务容忍度。稳定性怎么设定,很大程度上还要取决于业务上的容忍度。对于核心业务或核心应用来说,当然是希望成功率越高越好,一般对系统稳定性要求是3个9或4个9。因为这些系统一旦出问题,就会直接影响整个网站和公司的收益,这些都是钱,所以对稳定性要求必然就会提高。但是,对于非核心业务或应用,比如商品评论,商品评分等,或许”2 个 9”也能容忍。因为短时间的评论看不到,并不会对业务收入和用户体验造成太大的影响。

  • 第三个,系统当前的稳定性状况。结合系统的实际情况,定一个合理的标准比定一个更高的标准会更重要。比如,如果系统可用性是低于 99% 的,那首先第一步是不是可以做到 99%,然后再争取做到 99.5%,再到 99.9%,一步一步朝着更高的标准迈进。同时,这样做也会更容易落地,因为你如果定一个太高的目标,又始终达不成,反而会打击到团队的自信心和积极性。

设定稳定性的衡量标准

“确定成功请求条件,设定达成占比目标” 的过程,在 SRE 中就是设定稳定性衡量标准的 SLI 和 SLO 的过程。

  • SLI,Service Level Indicator,服务等级指标,其实就是我们选择哪些指标来衡量我们的稳定性。

  • SLO,Service Level Objective,服务等级目标,指的就是我们设定的稳定性目标

落地 SRE 的第一步其实就是“选择合适的 SLI,设定对应的 SLO”

比如,http状态码返回为非 5xx 的比例大于等于 99.95%时,我们就认为这个应用是稳定的。

在 SRE 实践中,我们用 SLI 和 SLO 来描述。”状态码为非 5xx 的比例” 就是 SLI,”大于等于 99.95%”就是 SLO。说得更直接一点,SLO 是 SLI 要达成的目标。

在这个例子中,SLI 就是我们要监控的指标,SLO就是这个指标对应的目标。

确定SLI指标的两大原则

  • 原则一:选择能够标识一个主体是否稳定的指标,如果不是这个主体本身的指标,或者不能标识主体稳定性的,就要排除在外。

  • 原则二:针对电商这类有用户界面的业务系统,优先选择与用户体验强相关或用户可以明显感知的指标。

快速识别 SLI 指标的方法:VALET

VALET 是 5 个单词的首字母,分别是 Volume、Availability、Latency、Error 和Ticket。这 5 个单词就是我们选择 SLI 指标的 5 个维度。

类别解释
Volume(容量)服务承诺的最大容量是多少。比如QPS、TPS、会话数、吞吐能力以及连接数等等
Availablity(可用性)代表服务是否正常,比如请求调用的非5xx状态成功率、任务执行成功情况
Latency(时延)响应是否足够快,比如时延,但时延的分布符合正态分布,需指定不同的置信区间,有针对性解决。
Error(错误率)有多少错误率,比如5xx、4xx,也可以自定义状态码
Ticket(人工介入)是否需要人工介入,比如任务失败需人工介入恢复

如何通过SLO计算可用性?

  • 第一种,直接根据成功的定义来计算。

    比如 Successful = (状态码非 5xx) & (时延 <= 80ms)

  • 第二种方式,SLO 方式计算。

    SLO1:99.95% 状态码成功率 SLO2:90% Latency <= 80ms SLO3:99% Latency <= 200ms

    Availability = SLO1 & SLO2 & SLO3

Google 的 SLI 和 SLO 设定模板链接:https://landing.google.com/sre/workbook/chapters/slo-document

错误预算

错误预算(Error Budget)最大的作用就是“提示你还有多少次犯错的机会”

错误预算是怎么得出的呢?其实计算方式一点都不复杂,简单讲就是通过SLO 反向推导出来的。

假设一个应用在4周的时间内,所有的请求次数为4,653,680,按照给出的 SLO 反向推导,就可以得到容许的错误次数,这就是错误预算。

SLOError Budget
99.95% Availability23,268
90% Latency <= 80ms465,368
99% Latency <= 200ms46,536

在 SLO 落地实践时,我们通常就把 SLO 转化为错误预算,以此来推进稳定性目标达成。

如何应用Error Budget?

  1. 稳定性燃尽图, 按照4周一个周期来制作错误预算燃尽图,可以随时查看错误预算的消耗情况。

  2. 故障定级,根据错误预算消耗的比例来指定故障的级别。

  3. 稳定性共识机制,在我们系统稳定性保障过程中,我们也会根据剩余预算的情况,来制定相应的行动措施,来避免我们的稳定性目标,也就是 SLO 达不成。当错误预算处于不同状态时,采取两个指导原则: 第一.剩余预算充足或未消耗完之前,对问题的发生要有容忍度。 第二,剩余预算消耗过快或即将消耗完之前,SRE 有权中止和拒绝任何线上变更。

  4. 基于错误预算的告警

如何衡量slo的有效性?

衡量 SLO 及错误预算策略是否有效,其实就是看实际运行后,是否真的能达到我们的期望。我们可以从下面三个关键维度来看。

  • SLO 达成情况。我们用达成(Met),或未达成(Missed)来表示。

  • “人肉”投入程度。英文表示为 Toil,这里用形象一点的”人肉”投入作为它的译意,泛指需要大量人工投入、重复、繁琐且没有太多价值的事情。我们用投入程度高(High)和低(Low)来表示。

  • 用户满意度。英文就是 Customer Satisfaction,可以理解为用户感受和体验如何。这个信息可以通过真实和虚拟渠道获得。真实渠道如客服投诉、客户访谈和舆情监控获取;虚拟渠道如真机模拟拨测。我们用满意度高(High)和低(Low)来表示。

三种维度在不同情况下的应对策略

  • 第一类,收紧 SLO。这个时候就是目标定得太低了,比如 SLO 达成(Met),但是用户不满意(Low)。遭到大量投诉,这就表示我们的 SLO 设定得太容易达成,没有反馈真实的运行状况。

  • 第二类,放宽 SLO。目标定太高,总是达不成(Missed),但用户反馈却很不错(High),这种就会造成错误预算提前消耗完,导致很多变更暂停,产品延期,甚至会做一些无谓的优化,这时就可以适当松松绑。

  • 第三类,保持现状,对有问题的维度采取有针对性的优化措施。是我们期望的最理想状态,SLO 能达成,人肉投入又低,客户满意度又很高,也没有特别的优化空间,这时我们就可以增加发布和变更次数,更大程度地释放生产力。

设定 SLO 有哪些原则?

  • 第一,核心应用的 SLO 要更严格,非核心应用可以放宽。

  • 第二,强依赖之间的核心应用,SLO 要一致。

  • 第三,弱依赖中,核心应用对非核心的依赖,要有降级、熔断和限流等服务治理手段。

  • 第四,Error Budget 策略,核心应用的错误预算要共享,就是如果某个核心应用错误预算消耗完,SLO 没有达成,那整条链路,原则上是要全部暂停操作的,

如何验证核心链路的 SLO?

  • 容量压测

  • Chaos Engineering,也就是混沌工程

应该在什么时机做系统验证?

选择在业务量相对较小的情况下, 一般是一天的凌晨时间做演练。

故障发现

MTTI (Mean Time To ldentify,平均故障发现时间),也就是从故障实际发生,到我们真正开始响应的时间。这个过程可能是用户或客服反馈、舆情监控或者是监控告警等渠道触发的。

减少MTTI时间

  • 第一件事,判断出现的问题是不是故障;

    根据设定的 SLO 和错误预算,准确判断发生的问题是否是故障,并依据故障等级决定我们采取什么样的措施去处理这些问题,大大提高反应效率。

  • 第二件事,确定由谁来响应和召集。

    建设 On-Call 机制

On-Call 的流程机制建设

  1. 确保关键角色在线。 产品体系中的所有关键角色。

  2. 组织 War Room 应急组织。建立专门的应急群,将这些关键角色纳入其中,当有故障发生时会第一时间在群通报,这时对应的 On-Call 同事就要第一时间最高优先级响应呼叫。

  3. 建立合理的呼叫方式。建议使用固定的 On-Call 手机,建立手机与所有 On-Call 系统的对应关系,比如这个手机号码对应交易核心应用,另一个号码对应 IDC 机房运维等等。这样我们在 On-Call 时就不再找具体的哪个人,而是手机在谁手中,谁就承担 On-Call 职责。

  4. 确保资源投入的升级机制。 授予On-Call值班人员有权调动其他必要资源投入。如果故障等级偏高,一下无法明确具体找哪些人员投入的时候,SRE 或运维可以直接上升到自己的主管或相关主管那里,要求上级主管协调资源投入。必要时,还可以上升到更高级主管,甚至 CTO 或技术 VP 来关注。

  5. 与云厂商联合的 On-Call。应该把云产品和云厂商作为我们系统的一部分,而不是单纯的第三方。而对于云厂商来说,也要考虑把客户业务作为自身业务的一部分,只有这样双方才能紧密合作。我们应该提前做好与云厂商之间的协作磨合,联合故障演练,必要的授权等等。

故障处理

基本原则: 在故障处理过程中采取的所有手段和行动,一切以恢复业务为最高优先级。

故障处理过程中效率如何,其实取决于三个因素:

  1. 技术层面的故障隔离手段是否完备;

  2. 故障处理过程中的指挥体系是否完善,角色分工是否明确;

  3. 故障处理机制保障是否经过足够的演练。

建立有效的故障应急响应机制

关键角色分工

Google 的故障指挥体系,是参考了美国消防员在处理 1968 年森林大火时建立的应急指挥体系,体系中有三个核心角色。

  1. Incident Commander,故障指挥官,简称为 IC。这个角色是整个指挥体系的核心,他最重要的职责是组织和协调,而不是执行,下面所有的角色都要接受他的指令并严格执行。

  2. Communication Lead,沟通引导,简称 CL。负责对内和对外的信息收集及通报,这个角色一般相对固定,由技术支持、QA 或者是某个 SRE 来承担都可以,但是要求沟通表达能力要比较好。

  3. Operations Lead,运维指挥,简称 OL。负责指挥或指导各种故障预案的执行和业务恢复。

  4. 这里其实还有一类角色,虽然不在指挥体系内,但是也非常重要,我们也要做一下介绍:

Incident Responders,简称 IR。就是所有需要参与到故障处理中的各类人员,真正的故障定位和业务恢复都是他们来完成的,比如具体执行的 SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA,甚至是 QA 等。

流程机制

  1. 故障发现后,On-Call 的 SRE 或运维,最一开始就是 IC,有权召集相应的业务开发或其它必要资源,快速组织 War Room。

  2. 如果问题和恢复过程非常明确,IC 仍然是 SRE,就不做转移,由他来指挥每个人要做的具体事情,以优先恢复业务优先。

  3. 如果问题疑难,影响范围很大,这时 SRE 可以要求更高级别的主管介入,比如 SRE 主管或总监等,一般的原则是谁的业务受影响最大,谁来牵头组织。这时 SRE 要将 IC 的职责转移给更高级别的主管,如果是全站范围的影响,必要时技术 VP 或 CTO 也可以承担IC 职责,或者授权给某位总监承担。

反馈机制

一般要求以团队为单位,每隔 10~15 分钟做一次反馈,反馈当前处理进展以及下一步Action,如果中途有需要马上执行什么操作,也要事先通报,并且要求通报的内容包括对业务和系统的影响是什么,最后由 IC 决策后再执行,避免忙中出错。没有进展也是进展,也要及时反馈。

为了尽量减少对执行者的干扰,让执行者能够更聚焦,我们一般要求团队 Leader 来收集反馈并传递 IC 的指令。CL 也要收集信息,他要做的不是传达指令,而是在更大范围内同步汇总后的信息,同时还要整理信息传递给外部联系人。

对于技术以外的人员反馈,如客服、PR 以及商家和其它各类合作代表等等。