什么是SRE？
在刚刚接触SRE时，很多人认为就是Google的一个具备全栈能力的岗位，可以独立解决很多问题的人。
而在深入探究之后发现，SRE 确实可以解决很多问题，但问题实在太多了，一个岗位或一个人是很难高效快速的解决的。
比如怎么做容量评估、怎么进行故障演练、怎么能做到服务限流、怎么做到异常熔断、怎么让监控告警更有效等。
所以为了解决这些问题，不难看出需要测试、开发、运维以及其他相关岗位人员都得进行合作建设，所以会发现其实可以认为SRE是一套指导建设的体系化方法。
SRE的目标是什么？
提高稳定性
建设SRE体系的目标是“提高稳定性”
而在SRE中对“提高稳定性”这一目标有着两个衡量的指标
从他们的释义中可以看出两个指标与系统运行状态关系对应如下
其实我们对系统稳定性认识就是让系统正常运行状态长时间维持下去，当出现故障时可以快速处理恢复。
所以提升MTBF，降低MTTR就成为了“提高稳定性”的目标。
这让我们在建设 SRE 做相关工作时，可以依据是否提升MTBF，降低MTTR去判断工作的有效性。
细分目标
有了这个目标之后，问题就来了，MTBF和MTTR两个指标是不是有点太大了，即使可以通过告警、通知或其他手段梳理出其两个指标的时间数据，也不清楚如何具体落实改进。
其实MTTR还可以细分4个指标，分别对应系统故障中四个阶段，具体如下
而 MTBF 也可以细分2个阶段，如下：
所以有了具体的阶段分割，我们就可以针对着去做工作，比如参考SRE稳定性保证规划图如下
在体系建设方面可以分别对应
在如此清晰明了的阶段化划分，我们建设阶段性工作就非常清晰，有针对性的去做，不怕走错路。
比如 Pre-MTBF 时，我们可以做好架构设计提供限流、降级、熔断等Design-for-Failure的服务治理手段，提供快速隔离的条件。
而 Post-MTBF 时，我们需要做好故障复盘，总结不足以及进行改进措施落地。
在这里呢，也可以借助AIOps能力提高问题定位效率以及告警准确率，降低MTTI和MTTK。
辨别故障的基础：合适的SLI，对应的SLO
上述我们知道目标是提升MTBF，降低MTTR基本是围绕这“故障”这个维度来衡量的，但是系统什么时候才是故障呢？
所以这里我们需要有个判断条件或者说是判断标准，来界定“故障与否”
了解监控系统的同学们会知道“告警”了，就有可能发生“故障”，这里用“有可能”是因为现实场景中通常下是不一定的。
而SRE体系中，有着更好、更准确的衡量标准 SLO（Service Level Objective）来界定“故障与否”。
而提到了SLO就不得不提其相关的 SLI 先。
什么是SLI
建设监控系统的同学会知道，监控中对目标对象进行监控时会有大量的指标，但是很多指标的作用估计微乎其微。
而通过遵循以下两个原则从中脱颖而出让其作用发光发热的指标就是SLI。
- 能标识目标对象是否稳定
- 与用户体验强相关或用户可以明显感知的
所以SLI更能表达出“目标对象稳不稳定”。
VALET选择法
挑选SLI时，很多同学估计会有点摸不着头脑，毕竟仅有原则也很难辨别。
业界也深知这个问题，所以也有一套VALET选择方法依据指标的特质进行分类甄别，指标分类如下所示
通过以上类别可以快速区分出SLI，在实际使用场景上是一个非常实用的技巧。
但是这里免不了的就是人工介入，无论是对现有指标的筛选，还是未来接入指标的筛选。
什么是SLO
好，从SLI可以表达“目标对象稳不稳定“这点，我们就可以让SLI + 目标 + 时间维度就能更精确的表达稳定性现状
比如 1个小时内 90% 时延 <= 80ms
而其就是SLO。
如果以上例子值高于80ms时，就已经代表该SLO已经不达标了，有可能发生故障了。
但是会发现简单的将单独SLO作为“稳定性”的判断标准，未免会陷入到监控领域类似的告警风暴和误报这种困境中。
而现实中衡量业务稳定性时，我们通常会通过多个不同的判断标准和依据来决定业务是否故障。
所以我们也可以通过组合多个SLO，采用与运算的方式，来更加精确的表达业务的稳定性
公式如：Availability = SLO1 & SLO2 & SLO3
所以得所有的 SLO 都达成才能算是达标！
而简单来说SLO的出现让业务的稳定性表达的更加精确、可靠。
关于时间维度
SLO中的时间维度可以分成持续时间和周期，用来覆盖以下两种场景
- 时间维度：从故障角度评估
- 请求维度：从成功请求占比评估
时间维度：从故障角度评估
这里可以理解为从SLI已经达不到所设阈值已经持续多长时间的角度，来界定这个SLO是否异常了。
比如设定1分钟内请求成功率低于95%持续10分钟就是异常，但是这样的方式在时间细粒度上并不精细，比如出现1分钟内请求成功频率多发低于95%，但并没有持续10分钟，这样其实算是有异常的需要关注的，所以可以利用请求维度进行补充。
请求维度：从成功请求占比评估
这里可以理解为在统计周期内SLI是否低于所设阈值，来界定SLO是否异常，比如1天内请求成功率低于95%就是异常。
这种方式有效的补充了时间维度的不足，通常就是相辅相成的存在。
关于SLO与可用性
可用性通常认识就是几个9，比如 4个9、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 如下：
这样可以将数据转换成计分的形式，更加直观而且感官冲击力更加强。
所以我们可以通过应用 ErrorBudget 进行数据的归一化 的方式，更好的来推进稳定性目标的达成。
消费 ErrorBudget 数据
稳定性燃尽图
利用ErrorBudget计分形式，使用柱状图形式图表实时展示其状态，当然得设定一个周期建议为4个自然周，周期后数据恢复。
对于特殊的场景，可以适当增大ErrorBudget，可以让其场景合理化，但是还是具体情况具体分析。
故障定级
利用ErrorBudget归一化成次数时，可以利用其消耗数百分比来制定故障等级，这样所有不同的SLO都可以利用同一份规则去做故障定级，达到统一规范的目的。
一般故障等级都会分成P0~P4五个级别，0为最高。
常见的故障等级设定如下：
比如 ErrorBudget为25000，问题产生错误请求超过5000，也就是消耗20%以上既可以定级为P2级以此类推。
具体的等级设定需要根据业务的情况和容忍度去制定。
稳定性共识机制
驾照记分制想必大家都不陌生，在等你发现计分剩下1分时，你开车就会非常的小心，避免犯规导致再教育或驾照吊销。
所以你会发现ErrorBudget也是如此，一旦剩余的数量不多时，你会提高警惕，制定相应的行动措施，来避免稳定性目标SLO不达标。
而如何制定行动措施呢？可以考虑以下两个原则：
1.当剩余预算充足或未消耗之前，对问题的发生要有容忍度
在日常我们会遇到网络抖动或设备瞬时切换导致了极短暂系统不稳定， 这时有极少一部分客户反馈或业务使用时遇到了，结果就被投诉业务不稳定，然后技术人员就立刻放下手头工作去排查问题，后续还要花大量的时间去复盘总结和汇报。
这样消耗了技术人员大量的时间和精力，排查结果对业务没什么大帮助，这样导致的结果会有技术人员手头工作无法完成，也浪费了其他协助人员的时间。
总体来说性价比不高，而且是一个涟漪的扩散影响，这种事情一多了，估计就会引发”海啸“了吧！
现在有了SLO和错误预算判断标准，就有了明确的应对思路：如果预算充足就应该有所容忍不应该被投诉，也不应该高优先级响应。
2.当剩余预算消耗过快或即将消耗完之前，SRE有权中止和拒绝任何线上变更
这种情形下，可以理解成一个带病的工程师，还在坚持上班工作，但是这时他的工作完成的并不理想，而且有可能会直接倒下的风险
你还忍心给他分配新的任务或让他继续以这样的状态工作下去嘛？
这时应该让他恢复健康，才能继续好好的干下去！
从这点类比可看，团队应该是要优先配合解决影响稳定性的问题，直至问题解决，等到下个周期有了新的错误预算后再恢复正常的变更节奏。
注意要点
这两点其实是需要大家都要认可并执行的。因为这里涉及的是多方配合协作问题，有同样的共识才能保证工作协作上的流畅以及高效。
从多方协作这点出发看待，如果要推行该机制是需要”Top-DOwn“自上而下的，比如技术VP或CTO级别。
而且有问题时还可以逐步上升由CTO角度做决策。
基于错误预算的告警
在以往日常工作，经常会收到大量的告警短信，但是其价值非常低，导致的后果就是狼来了，大家都开始对告警产生了不信任。
其实这样的后果是非常严重的，因为极有可能有用的信息被淹没了，导致业务利益受损，多方担责。
当然业界也有解决方案，名为”告警收敛“
常用做法有让相同相似告警合并后在发送给通知人，比如同一集群、同一异常告警
但是这种做法也会充斥着很多信息，无法快速的定位到问题并处理，为什么这样说？
因为只是单纯的将信息合并了，信息量还是没有变化，除非是结合其他手段将信息再提炼计算合并，比如所谓的告警决策树，这样的话会更加精准。
但是这种建设的成本也不低，涉及到收敛的规则设计、对象逻辑层级设计、决策逻辑处理实现等。
而采用基于错误预算告警的方式就能天然的做到告警收敛，因为他是基于业务的SLO的
这也表明我们只关注对稳定性造成影响的告警，而这类告警的出现我们是必须快速响应处理，而且这种告警数量不多
达到收敛效果的同时又非常精准。
简单做法就是将故障定级的阈值进行告警设置，更详细精准的做法会涉及到AIOps领域相关的。
限于篇幅，本文为节选，更多请看原文。