在刚刚接触SRE时，很多人认为就是Google的一个具备全栈能力的岗位，可以独立解决很多问题的人。

而在深入探究之后发现，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。

上述我们知道目标是提升MTBF，降低MTTR基本是围绕这“故障”这个维度来衡量的，但是系统什么时候才是故障呢？

所以这里我们需要有个判断条件或者说是判断标准，来界定“故障与否”

了解监控系统的同学们会知道“告警”了，就有可能发生“故障”，这里用“有可能”是因为现实场景中通常下是不一定的。

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

而提到了SLO就不得不提其相关的 SLI 先。

建设监控系统的同学会知道，监控中对目标对象进行监控时会有大量的指标，但是很多指标的作用估计微乎其微。

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

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

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

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

通过以上类别可以快速区分出SLI，在实际使用场景上是一个非常实用的技巧。

但是这里免不了的就是人工介入，无论是对现有指标的筛选，还是未来接入指标的筛选。

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

比如 1个小时内 90% 时延