浅谈SRE-基础理论篇

什么是SRE？

在刚刚接触SRE时，不少人认为就是Google的一个具有全栈能力的岗位，能够独立解决不少问题的人。

而在深刻探究以后发现，SRE确实能够解决不少问题，但问题实在太多了，一个岗位或一我的是很难高效快速的解决的。

好比怎么作容量评估、怎么进行故障演练、怎么能作到服务限流、怎么作到异常熔断、怎么让监控告警更有效等

因此为了解决这些问题，不难看出须要测试、开发、运维以及其余相关岗位人员都得进行合做建设，因此会发现其实能够认为SRE是一套指导建设的体系化方法。

那SRE的目标是什么？

提升稳定性

建设SRE体系的目标是“提升稳定性”

而在SRE中对“提升稳定性”这一目标有着两个衡量的指标

指标	释义
MTBF（Mean Time Between Failure）	平均故障时间
MTTR（Mean Time To Repair）	故障平均修复时间

从他们的释义中能够看出两个指标与系统运行状态关系对应以下

指标	系统运行状态
MTBF	系统正常运行时
MTTR	系统故障时

其实咱们对系统稳定性认识就是让系统正常运行状态长时间维持下去，当出现故障时能够快速处理恢复。

因此提高MTBF，下降MTTR就成为了“提升稳定性”的目标

这让咱们在建设SRE作相关工做时，能够依据是否提高MTBF，下降MTTR去判断工做的有效性

细分目标

有了这个目标以后，问题就来了，MTBF和MTTR两个指标是否是有点太大了，即便能够经过告警、通知或其余手段梳理出其两个指标的时间数据，也不清楚如何具体落实改进阿。

其实MTTR还能够细分4个指标，分别对应系统故障中四个阶段，具体以下

指标	释义	阶段
MTTI（Mean Time To Identify）	平均故障发现时间	故障发现：故障发生到响应
MTTK（Mean Time To Know）	平均故障认知时间	故障定位：根因或是根因范围定位出来为止
MTTF（Mean Time To Fix）	平均故障解决时间	故障恢复：采起措施恢复业务
MTTV（Mean Time To Verify）	平均故障修复验证时间	故障恢复验证：故障解决后验证业务恢复所用时间

而MTBF也能够细分2个阶段，以下

阶段	释义
Pre-MTBF	故障预防
Post-MTBF	故障改进

因此有了具体的阶段分割，咱们就能够针对着去作工做，好比参考至赵成老师的SRE稳定性保证规划图以下

Pre-MTBF（故障预防）	MTTI（故障发现）	MTTK（故障定位）	MTTF&MTTV（故障恢复）	Post-MTBF（故障改进）
故障演练	AIOps	日志分析	容灾切换	故障复盘
容量评估	舆情感知	链路跟踪	服务降级	改进验收
持续交付	监控告警	根因定位	服务限流	故障模拟
自动化			异常熔断	混沌工程
架构设计				容量压测

在体系建设方面能够分别对应

Pre-MTBF（故障预防）	MTTI（故障发现）	MTTK（故障定位）	MTTF&MTTV（故障恢复）	Post-MTBF（故障改进）
建设演练/On-Call	应急响应	应急响应	应急响应	复盘改进/On-Call

在如此清晰明了的阶段化划分，咱们建设阶段性工做就很是清晰，有针对性的去作，不怕走错路。

好比Pre-MTBF时，咱们能够作好架构设计提供限流、降级、熔断等Design-for-Failure的服务治理手段，提供快速隔离的条件

而Post-MTBF时，咱们须要作好故障复盘，总结不足以及进行改进措施落地。

在这里呢，也能够借助AIOps能力提升问题定位效率以及告警准确率，下降MTTI和MTTK。

辨别故障的基础：合适的SLI，对应的SLO

上述咱们知道目标是提高MTBF，下降MTTR基本是围绕这“故障”这个维度来衡量的，可是系统何时才是故障呢？

因此这里咱们须要有个判断条件或者说是判断标准，来界定“故障与否”

了解监控系统的同窗们会知道“告警”了，就有可能发生“故障”，这里用“有可能”是由于现实场景中一般下是不必定的。

而SRE体系中，有着更好、更准确的衡量标准 SLO（Service Level Objective）来界定“故障与否”。

而提到了SLO就不得不提其相关的SLI(Service Level Indicator) 先

什么是SLI

建设监控系统的同窗会知道，监控中对目标对象进行监控时会有大量的指标，可是不少指标的做用估计微乎其微。

而经过遵循如下两个原则从中脱颖而出让其做用发光发热的指标就是SLI。

1. 能标识目标对象是否稳定
2. 与用户体验强相关或用户能够明显感知的

因此SLI更能表达出“目标对象稳不稳定”。

VALET选择法

挑选SLI时，不少同窗估计会有点摸不着头脑，毕竟仅有原则也很难辨别。

业界也深知这个问题，因此也有一套VALET选择方法依据指标的特质进行分类甄别，指标分类以下所示

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

经过以上类别能够快速区分出SLI，在实际使用场景上是一个很是实用的技巧。

可是这里免不了的就是人工介入，不管是对现有指标的筛选，仍是将来接入指标的筛选。

什么是SLO

好，从SLI能够表达“目标对象稳不稳定“这点，咱们就可让SLI + 目标 + 时间维度就能更精确的表达稳定性现状

好比 1个小时内 90% 时延 <= 80ms

而其就是SLO。

若是以上例子值高于80ms时，就已经表明该SLO已经不达标了，有可能发生故障了。

可是会发现简单的将单独SLO做为“稳定性”的判断标准，未免会陷入到监控领域相似的告警风暴和误报这种困境中。

而现实中衡量业务稳定性时，咱们一般会经过多个不一样的判断标准和依据来决定业务是否故障

因此咱们也能够经过组合多个SLO，采用与运算的方式，来更加精确的表达业务的稳定性

公式如：Availability = SLO1 & SLO2 & SLO3

因此得全部的SLO都达成才能算是达标！

而简单来讲SLO的出现让业务的稳定性表达的更加精确、可靠。

关于时间维度

SLO中的时间维度能够分红持续时间和周期，用来覆盖如下两种场景

1. 时间维度：从故障角度评估
2. 请求维度：从成功请求占比评估

时间维度：从故障角度评估

这里能够理解为从SLI已经达不到所设阈值已经持续多长时间的角度，来界定这个SLO是否异常了

好比设定1分钟内请求成功率低于95%持续10分钟就是异常

可是这样的方式在时间细粒度上并不精细

好比出现1分钟内请求成功频率多发低于95%，但并无持续10分钟，这样其实算是有异常的须要关注的，因此能够利用请求维度进行补充

请求维度：从成功请求占比评估

这里能够理解为在统计周期内SLI是否低于所设阈值，来界定SLO是否异常

好比1天内请求成功率低于95%就是异常

这种方式有效的补充了时间维度的不足，一般就是相辅相成的存在

关于SLO与可用性

可用性一般认识就是几个9，好比 4个九、3个9

可是可用性一直被人诟病的是其数据的准确率问题，而经过SLO组合计算的方式来表达可用性能够保证准确率问题

由于其底层基础就是可表达目标对象是否稳定的SLI + 根据业务特征调整的目标 + 根据业务调整的时间。

经过不断的调整优化改进，可用性的准确率就会持续提高，并且更加贴近业务表现。

关于SLO与故障

从上述表达，SLO能够有效的表达稳定性是否达标，因此经过SLO去设置告警能够有效的告知系统是否处于故障中，

固然经过多个SLO组合后的SLO的告警会更为稳妥，

由于这样不止能够达到告警收敛的效果，也可让告警更加精确有效，防止狼来了现象。

从这点出发，接下来会介绍的一种量化SLO的数据ErrorBudget更加将这个优点发挥的更加出色

指导工做的量化数据：ErrorBudget

当咱们设定好SLO，可是该怎么开展具体工做呢？这时候就没那么直观

因此咱们须要有个可量化的数据，能够用于提醒并观测SLO的状况

而SRE中经过反向推导SLO的方式，得出一个量化数据 ErrorBudget（错误预算）就能达到这个效果

什么是ErrorBudget

ErrorBudget，错误预算，能够直白的理解其为“提示你还有多少次犯错的机会”

好比 4周为一周期，应用的请求次数是 4,653,680，反向推导如下SLO得出 ErrorBudget 以下

SLO	ErrorBudget
99.95% 可用性	23,268
90% 时延 <= 80ms	465,368
99% 时延 <= 200ms	46,536

这样能够将数据转换成计分的形式，更加直观并且感官冲击力更增强。

因此咱们能够经过应用 ErrorBudget进行数据的归一化 的方式，更好的来推动稳定性目标的达成

消费 ErrorBudget 数据

稳定性燃尽图

利用ErrorBudget计分形式，使用柱状图形式图表实时展现其状态，固然得设定一个周期建议为4个天然周，周期后数据恢复。

对于特殊的场景，能够适当增大ErrorBudget，可让其场景合理化，可是仍是具体状况具体分析。

故障定级

利用ErrorBudget归一化成次数时，能够利用其消耗数百分比来制定故障等级，这样全部不一样的SLO均可以利用同一份规则去作故障定级，达到统一规范的目的。

通常故障等级都会分红P0~P4五个级别，0为最高。

常见的故障等级设定以下

单次消耗比例	故障等级
比例<=5%	P4
5%<比例<=20%	P3
20%<比例<=30%	P2
30%<比例<=50%	P1
50%<比例	P0

好比 ErrorBudget为25000，问题产生错误请求超过5000，也就是消耗20%以上既能够定级为P2级以此类推。

具体的等级设定须要根据业务的状况和容忍度去制定。

稳定性共识机制

驾照记分制想必你们都不陌生，在等你发现计分剩下1分时，你开车就会很是的当心，避免犯规致使再教育或驾照吊销。

因此你会发现ErrorBudget也是如此，一旦剩余的数量很少时，你会提升警戒，制定相应的行动措施，来避免稳定性目标SLO不达标。

而如何制定行动措施呢？能够考虑如下两个原则

1. 当剩余预算充足或未消耗以前，对问题的发生要有容忍度

在平常咱们会遇到网络抖动或设备瞬时切换致使了极短暂系统不稳定， 这时有极少一部分客户反馈或业务使用时遇到了，结果就被投诉业务不稳定，而后技术人员就马上放下手头工做去排查问题，后续还要花大量的时间去复盘总结和汇报。

这样消耗了技术人员大量的时间和精力，排查结果对业务没什么大帮助，这样致使的结果会有技术人员手头工做没法完成，也浪费了其余协助人员的时间。

整体来讲性价比不高，并且是一个涟漪的扩散影响，这种事情一多了，估计就会引起”海啸“了吧！

如今有了SLO和错误预算判断标准，就有了明确的应对思路：若是预算充足就应该有所容忍不该该被投诉，也不该该高优先级响应。

2. 当剩余预算消耗过快或即将消耗完以前，SRE有权停止和拒绝任何线上变动

这种情形下，能够理解成一个带病的工程师，还在坚持上班工做，可是这时他的工做完成的并不理想，并且有可能会直接倒下的风险

你还忍心给他分配新的任务或让他继续以这样的状态工做下去嘛？

这时应该让他恢复健康，才能继续好好的干下去！

从这点类比可看，团队应该是要优先配合解决影响稳定性的问题，直至问题解决，等到下个周期有了新的错误预算后再恢复正常的变动节奏

注意要点

这两点实际上是须要你们都要承认并执行的。由于这里涉及的是多方配合协做问题，有一样的共识才能保证工做协做上的流畅以及高效。

从多方协做这点出发看待，若是要推行该机制是须要”Top-DOwn“自上而下的，好比技术VP或CTO级别。

并且有问题时还能够逐步上升由CTO角度作决策。

基于错误预算的告警

在以往平常工做，常常会收到大量的告警短信，可是其价值很是低，致使的后果就是狼来了，你们都开始对告警产生了不信任。

其实这样的后果是很是严重的，由于极有可能有用的信息被淹没了，致使业务利益受损，多方担责。

固然业界也有解决方案，名为”告警收敛“

经常使用作法有让相同类似告警合并后在发送给通知人，好比同一集群、同一异常告警

可是这种作法也会充斥着不少信息，没法快速的定位到问题并处理，为何这样说？

由于只是单纯的将信息合并了，信息量仍是没有变化，除非是结合其余手段将信息再提炼计算合并，好比所谓的告警决策树，这样的话会更加精准。

可是这种建设的成本也不低，涉及到收敛的规则设计、对象逻辑层级设计、决策逻辑处理实现等。

而采用基于错误预算告警的方式就能自然的作到告警收敛，由于他是基于业务的SLO的

这也代表咱们只关注对稳定性形成影响的告警，而这类告警的出现咱们是必须快速响应处理，并且这种告警数量很少

达到收敛效果的同时又很是精准。

简单作法就是将故障定级的阈值进行告警设置，更详细精准的作法会涉及到AIOps领域相关的，

能够从谷歌基于SLO和错误预算的几种告警算法了解

如何衡量SLO是否有效

虽然咱们定好的SLO，可是SLO是否有效的反映出业务的稳定性，以及其反推出来的ErrorBudget是否真的能有效指导工做呢？

咱们仍是须要去进行验证检测，并持续优化的。

这里就须要从三个维度去梳理场景，以及根据三种策略去处理相应状况

哪三个维度？

咱们能够从三个维度去评估

维度	状态
SLO达成状况	达成（met）或未达标（miss）
"人肉"投入程度	高（high）或低（low）
用户满意度	高（high）或低（low）

根据这三个维度不一样的组装有8种状况

哪三种策略？

而在咱们能够用如下三种策略去处理

1. 收紧SLO
   用户满意度低时，而目标反而达成了，这时咱们就要收紧SLO，缩小目标，逐步调整成能反馈出真实状况
2. 放宽SLO
   用户满意度高时，目标反而没达成，这时咱们就能够适当的松绑，将目标调大，也适当增大发布次数，加快业务增加
3. 针对问题，持续优化
   这里需按状况分析出问题的缘由，针对性优化
   好比三种维度都符合预期时，增长迭代次数，提高业务生产效能
   三种维度都没符合预期时，分析业务特征不断调整优化SLO，落实优化改进措施持续提高

应对状况策略

梳理具体的状况应对表格以下

SLO达成状况	“人肉”投入程度	用户满意度	执行策略
Met	Low	High	持续优化：产品用户体验差的问题，因此放宽发布和部署流程并提升速度，或先推迟规划实现，更多专一于提高服务可靠性
Met	Low	Low	收紧SLO
Met	High	High	持续优化：若是是告警产生错误的导向，下降敏感度。不然临时放松SLO或减小人工投入、修复产品和提升故障自愈能力。
Met	High	Low	收紧SLO
Missed	Low	High	放松SLO
Missed	Low	Low	持续优化：告警设置质量不足，需提高告警的敏感度
Missed	High	High	放松SLO
Missed	High	Low	持续优化：减小人工投入、修复产品和提高故障自愈能力

怎么落地SLO？

前面说了一堆SLO的各类好，那落地的话该怎么入手呢？

其实前面或多或少也说了一点，可是这个篇幅咱们就把他揪出来

找出核心链路

实践SRE无非就是服务于业务，因此应从分析业务入手，找出核心点

而虽然业务中应用众多，可是能创造核心价值的是显而易见的，毕竟用户访问量、业务业绩、业务特征从这些角度就能够筛选出整个具备核心价值的链路出来

因此优先从业务角度先整理辨别核心和非核心应用，从而梳理出核心链路，就是咱们的指导方针。

其实这里当前并无很好的自动化手段去整理，毕竟贴近用户的，除了利用机器学习的方式去推断貌似也没什么好解决方法

因此这里会充斥着大量的人肉工做，这里涉及的架构的梳理、业务方的沟通、技术栈的梳理等等。

可是这个付出是值得的，由于这样就会对整个业务有着通盘的理解，之后也更好的开展工做。

梳理应用间关系

当核心链路整理出来后，里面的核心应用与非核心应用都会相应的整理出来，毕竟核心链路就是由核心应用所构成的

而在处理应用与应用直接的关系时，分强弱两种，具体组合状况分类以下

应用角色	应用角色	关系强弱
核心	核心	强
核心	非核心	弱
非核心	非核心	弱

当咱们梳理好关系以后，咱们既能够分而治之，对其设定SLO

设定应用SLO

设定应用的SLO，能够遵循四个原则

1. 核心应用SLO要更严格，非核心应用能够放宽

让咱们建设更加关注核心业务上

2. 强依赖的核心应用之间SLO要一致：

能够理解他们是同一条道路上的，一旦某个路段出现阻塞时，影响的是整条道路的车辆运行状况。

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

主要目的在于下降非核心应用对核心应用的影响，保证用户的最高权益

4. ErrorBudget策略，核心应用的错误预算要共享

若是某个核心ErrorBudget消耗完了，一定是对整个链路有影响的，从而对用户体验上形成影响，这是原则上是要中止链路上全部变动操做的，优先修复。
固然能够根据实际状况放松，好比某个核心应用自身预算充足且不影响核心链路功能，固然这点决策须要很是谨慎。

验证

固然咱们设定完，以后都须要验证一把，给出相应的实证，否则就成“自娱自乐”了。

而这里手段，如今所了解到的有两种

1. 容量压测
2. 混沌工程（Chaos Engineering）

容量压测

容量压测主要做用是对SLO中的Volume类的进行验证，通常容量类的指标有业务的QPS、TPS，

因此会依据这些指标进行容量的进行压力测试，从而暴露依赖关系问题，和各类服务治理措施是否有效。

好比模拟用户访问请求提高TPS并发访问到SLO所设定的数值，而后观察业务是否有影响，原先所设置的的限流降级策略是否生效，达到预期

混沌工程（Chaos Engineering）

混沌工程主要做用是模拟故障发生场景，主动产生线上异常和故障

好比机房断电验证异地双活、打满流量验证网络、写满磁盘或跑满CPU等等操做

混沌工程是很是复杂的系统化工程，由于要线上制造故障，或多或少都要对线上业务形成影响，若是模拟故障形成的真实影响超过预估影响，也要可以快速隔离，并快速恢复正常业务。

看到这句话是否是以为有点恐怖，貌似跟维稳有点违背阿。

因此混沌工程的实施要很是的谨慎当心。

其中模拟策略必需要通过大量的反复验证，包括异常恢复原实施，确保影响可控以后，通过多方评审或验证才能线上实施。

因此混沌工程并不会在SRE体系初期就会尝试的东西，

必须是在高级阶段，也就是服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分很是完善的状况才回去考虑的东西。

混沌工程其实就是从未知中挖掘出问题，从而让业务对自身了解更加清晰，更能保障本身，简单来讲就是“在失败中成长”。

何时作验证？

咱们知道要作验证，可是何时作呢?

参考Google的建议，核心就是错误预算充足时能够尝试，尽可能避开错误预算不足的时间段。

正常的业务下，完成SLO也不是一件简单的事情，并且也不能给系统稳定性形成风险。

并且得评估故障模拟的影响，好比须要考虑是否损害公司收益？是否损害用户体验？

若是对业务影响很大时，还要将方案粒度细化，分步骤、避免形成不可预估的损失。

因此实际实践中，时间段须要根据业务特征去选择，要考虑故障恢复时间，准备必定要充分，不可大意。

结语

本文为学习赵成老师的SRE实战手册，所总结得出本身对SRE的理解。但愿对各位有兴趣的同仁们有所帮助。