本文根据石鹏老师在〖deeplus直播第227期〗线上分享演讲内容整理而成。

我们都知道SRE是一个体系化的工程，SRE体系的建设涉及的内容繁多，比如日常需求处理、容量规划、资源部署、监控告警、预案梳理、灾备演练、OnCall值班、应急事件响应、故障处理、运维自动化建设等等；其中「故障」可以算作是这众多事项的一个交汇点。

故障处理是一个特别符合“台上一分钟，台下十年功”这句俗语的场景，一次故障就是一次考试。SRE团队的响应速度、对服务的掌控能力、监控告警的覆盖是否完整、配置是否合理，灾备预案的体系是否完善、是否做了充分的灾备演练、应急预案是否有效....这些都是用于考核SRE体系建设水平的一些指标，都会在「故障处理」的过程中得到淋漓尽致的体现。不管你是研发、测试、运维，或其他“工种”，只要你身处IT行业，「故障」怕都是大家避之唯恐不及却无法绕开的一个梦魇和话题。

我将围绕「故障管理」这个点跟大家聊一聊SRE的工作范畴，跟大家共同探讨SRE体系的建设。希望可以通过分享让大家对故障管理有一个宏观的框架，可以更从容淡定、有章可循地做服务稳定性建设。

本次分享将按照如下的顺序展开：

 

• 先聊一聊SRE的工作职责，聊一下我所理解的SRE的核心目标；

• 初步看一下稳定性建设的工作范畴，看一看从宏观上如何划分我们的工作内容；

• 然后我们由此进入今天的主题：故障管理，我将按照我的理解对故障管理进行拆解和分析；

• 再后面，围绕故障管理，我们深入聊一下SRE的体系建设，如何通过体系建设来更好地做故障管理；

• 最后我们再简单做下对未来的展望，共同畅想一下SRE工作的未来。

 

一、SRE的工作职责

 

同样的岗位名称，在不同公司的具体职责和目标可能会有些差异，这是我们在美图的职责定位：我把SRE的核心目标归结为3点：稳定性、效率和成本。

• 稳定性是核心职责，这也是SRE岗位跟之前运维相关岗位的名称(像SA、OP、PE等)之间最大的区别；SRE这个岗位在名称中重点突出了岗位目标——稳定性，而SA、OP、PE等岗位名称则没有明确出目标；

• 然后我们需要通过建设工具、平台、基础设施的建设来提高效率；

• 最后一个核心目标，我们定为成本；连同上一个点效率，可以用一个现在比较流行的词来概括——「降本增效」。这个点之所以重要，原因是多方面的，可以明确的是现在企业(当然也包括互联网行业)对成本控制的重视程度是越来越高了。我们SRE也可以切实的通过技术手段来达成“优化服务运行成本”的目标，这也是SRE团队对于企业的一个重要价值体现。

其中这3个目标中，我们今天要重点谈的是最核心、最基础的“稳定性”。

 

二、稳定性建设

 

那么，

 

• 什么是稳定性？我们应该如何定义这个词？

• 我们应该如何度量稳定性?

• 稳定性的目标应该怎么设置？

• 我们又该如何管理，如何提升稳定性呢?

这些问题，之前你是否有过系统的思考？

面对这一系列的问你，你的脑中会不会有很多问号?

著名的管理学大师彼得德鲁克曾经说过一句名言：如果你不能度量它，你就无法改进它。这句话同样适用于「稳定性」，那我们应该如何度量「稳定性」呢?

在业界我们通常用MTBF和MTTR这两个关键指标来衡量稳定性，这两个指标分别是「平均故障时间间隔」(Mean Time Between Failure)、「平均故障修复时间」(Mean Time To Repair)。

这两个指标也很好理解，我们用二分法简单地把服务状态分为“正常态”和“异常态”；异常态(故障)之间的平均时间间隔就是MTBF，从异常态(故障)恢复到正常态之间的平均时间就是MTTR。

如果我们把故障发生的时间间隔变长，让服务更长时间地保持稳定运行；并把故障恢复的时间变短，让服务更少(时间)地受到故障的影响；那么服务的稳定性也就自然提升了。这也就是我们之所以用这两个指标来衡量稳定性的原因。

上面的二分法是为了方便大家理解，在定义上不够严谨。我们再把上面这两个时间细化一下，看一下相对严格的定义：

如上图，在一个时间轴上，标注有几个关键的时间点： 

 

• 故障维修结束：上一次故障恢复结束的时间；

• 故障开始：故障开始发生的时间；

• 故障维修开始：开始介入故障，开始处理的时间。

上面这几个时间点就把时间划分为了几个时间段：

 

• 维修结束 -> 故障开始：T1

• 故障开始 -> 维修开始：T2

• 维修开始 -> 维修结束：T3

其中，

• T1的平均值为「平均无故障时间」，MTTF(Mean Time To Failure)

• T2+T3的平均值为「平均修复时间」，MTTR(Mean Time To Repair)

• T1+T2+T3的平均值为「平均故障间隔」，MTBF(Mean Time Between Failure)

所以我们可以看到 MTBF = MTTF + MTTR，因为MTTR通常远小于MTTF，所以MTBF近似等于MTTF；因此我们平时常用的衡量指标就是MTBF和MTTR。

衡量稳定性的指标明确了，那我们稳定性的目标也就明确了：

 

• 提高MTBF

• 降低MTTR

MTBF的提升可以看做是我们众多稳定性建设工作的一个结果(稳定)状态，MTTR则是我们对故障的应急处理、恢复服务的过程，这是一个集中检验我们稳定性建设水平的过程。

为了更好的理解和掌控故障恢复这个阶段，我们对MTTR做进一步拆解；根据时间顺序，MTTR可以细化为MTTI、MTTK、MTTF、MTTV四个阶段(指标)。

• MTTI(Mean Time To Identify，平均故障发现时间)：指的是从故障实际发生，到我们真正开始感知、识别、响应的时间。这个过程最长见的渠道可能是服务监控告警、常规巡检、用户或者同事反馈，也可能是舆情监控等。

• MTTK(Mean Time To Know，平均故障认知时间)：也就是我们常说的平均故障定位时间。

• MTTF(Mean Time To Fix，平均故障恢复(解决)时间)：这个时间指从我们定位到故障的原因到我们采取措施恢复业务为止。这里采用的方式可能有很多：故障隔离、容灾切换、限流、降级、熔断等，甚至是重启服务。

• MTTV(Mean Time To Verify，平均故障修复验证时间)：即故障解决之后，我们用来验证服务是否真正恢复的时间。

 

MTTR的指标被细化之后，我们的目标也就变成了降低这些细化之后的指标；我们可以分而治之、各个击破，那么我们应该如何去达成这些目标呢？

我们可用的手段，总结如上图：

 

• MTTI阶段：多管齐下；尽可能用更多的手段来覆盖可以发现、暴露问题的通道，包括完善监控的覆盖，建设体系化的监控系统。

• MTTK阶段：工具赋能；这个过程中需要更多的借助工具、平台的能力，建设健全运维系统，比如监控平台、日志平台、链路跟踪平台等，如果能力允许也可以去尝试建设“根因自动定位”系统。

• MTTF阶段：完备预案、一键应急、紧密协作；这个是在故障处理过程中最核心的部分，是真正可以让服务恢复正常的阶段；这个过程有比较多的前置依赖，也就是需要我们在平时做好储备的，比如建立健全预案体系，将预案的执行手段尽可能沉淀到工具平台中，尽可能做到一键直达，缩短预案执行的路径。其次这个过程中可能还会涉及到部门内部、部门之间的协作，尤其是在处理重大故障的场景；这时候就需要有一套可以让大家紧密协作的流程或共识，让大家可以信息互通、各司其职、有条不紊。

• MTTV阶段：自动校验；这个过程也是需要尽可能依赖自动化的手段去做。

讲完这些之后，让我们来看一下SRE稳定性建设的全景图，看一看上面的内容在整个稳定系体系中的位置：

看图中带箭头标识的部分，整个时间轴总体分为MTBF和MTTR两部分。

根据MTBF所处的位置，MTBF又可以被分为两部分：一个是故障前的Pre阶段，一个是故障后的Post阶段；但其实因为整个时间轴是连续的，上次故障的Post-MTBF就是本次故障的Pre-MTBF，同理本次故障的Post-MTBF就是下次故障的Pre-MTBF。

在这几个阶段中SRE的职责分别是：

• Pre-MTBF：预案建设、灾备演练、OnCall值守等；

• MTTR：应急响应；

• Post-MTBF：故障复盘、故障改进、OnCall值守等。

看上图中红色的故障管理主线，整个过程可以被归纳为：

故障预防 -> 故障发现 -> 故障定位 -> 故障恢复 -> 故障改进

围绕故障管理这条主线，我们把SRE稳定性建设的众多工作内容串联起来；夸张一点讲，我们做的所有稳定性建设都是为「故障」服务的，SRE的稳定性建设都必须围绕“提高MTBF”和“降低MTTR”这两个目标展开。

接下来，我们将沿着这条主线对「故障管理」进行进一步分析和讲解。

在深入故障管理的细节之前，我们先统一下对「故障」这个事情的认识，看一看我们推崇的故障文化。

「故障」其实是服务运行中的一个常态，是无法完全避免的；因此我们需要用一个积极的心态，至少是一颗平常心来看待故障，不能惧怕故障，更不要谈之色变；只有我们正视故障，分析并改进才更有可能在未来去规避它；这就需要我们辩证的看待故障，我们需要尽可能从故障中汲取正向的意义，建议把关注点聚焦在「改进」上，而不是「处罚」。

这是我们基于No Blame Culture得出的公司内部的故障文化的标语：「拥抱故障，卓越运维」，我们希望在这样的基调之下去做开展故障管理的工作。

 

三、故障管理

 

接下来，让我们进入今天的核心部分。我将按照前、中、后三部分对故障管理的工作内容做拆解，按照时间顺序来层层推进，解开故障管理的面纱。

根据故障发生的时间顺序，我们把故障管理分为故障前、故障中和故障后，在每个环节都有一些核心的工作内容和目标。

• 故障前：故障预防、灾备预案；目标是尽可能地做足准备工作，毕竟有备方可无患；

• 故障中：发现、定位、解决故障；目标是尽可能的提高效率，缩短故障恢复的时间；

• 故障后：故障复盘、故障改进；目标是尽可能多的从故障中吸取教训，反思和学习，完善和修复故障中暴露出来的问题。

1、故障前

 

 

 

故障前的故障预防和灾备预案，我们应该怎么做呢？

这里列出了这么几个比较关键工作内容：监控覆盖、架构设计、容量评估、灾备预案、灾备演练、还有持续交付。

 

1）监控覆盖

 

监控覆盖的话比较容易理解，服务上线后，只有拥有足够的监控手段，并且尽可能多的覆盖服务的各个环节，才有可能在后面发生问题的时候，快速的感知到。也就是说，我们的目标是尽可能有多的监控手段去覆盖我们服务，保障各个场景。下图是我们之前用到的一些监控组件：

也是比较多的，大概是分为这么些类别：

之前我们是把大的监控体系分为两块：客户端质量监控和服务端质量监控。

①客户端质量监控

我们在客户端质量监控里边去感知客户端的状态。

当然，现在大家对这一点也越来越重视了。其实在移动互联网兴起之前，大部分的监控产品、监控思路都是集中在服务端的。而如今，移动端的流量越来越高，用户会花更多时间在移动端，但传统服务端的一些质量监控体系并不能够完全感知到客户端的状态，所以说这一点也就显得比较重要。

客户端质量监控我们都使用了哪些手段呢？

 

• 常规的有一些第三方的拨测、第三方的APM。除了一些商用的产品，当然也有一些免费的工具是可以用的。

• 应对一些流媒体的应用，我们自研了一套融合CDN的监控还有流媒体的监控。这个其实也比较关键，因为现在业务体量大了之后，CDN是不可避免的会用到，但如果没有这部分监控的话，CDN质量就要依赖于用户反馈，链路就会比较长。所以说要有手段去主动监测CDN的质量。我们建设了这样的CDN的质量监控，然后会去给不同的CDN厂商去打分，再去做智能的调度，是这样的。

 

②服务端质量监控

服务端的质量体系是用到了一些比较通用的，像InfluxDB套件、ELK、Prometheus、Open-Falcon

Zabbix。除此之外，我们还建设了一些基于大数据流式计算的系统，主要是用来做我们SLA的体系

接下来展示一些我们现在正在使用的监控大盘案例，都是需要我们在日常工作中完善的：

比如下图，是我们一组ECS的磁盘监控，通过这张图可以非常快速识别到哪组机器的磁盘的利用率比较高。

下图是我们SLA的监控：

这是我们服务端质量体系里边最重要的一张报表，请求数、错误数、慢请求有多少、服务整体平均响应时间、后端响应时间、成功率等SLA的指标都会在这张报表里边体现。

下图是我们基于Grafana，用了ES的数据源来做了一些日志的报表：

下图就是前文提到的客户端的质量监控：

其实在这之前我们有用过一些商业产品，但后来发现商业产品不能很好的满足我们的监控需求，所以后来就决定自己研发了哈勃监控。

在这里面，我们就可以对客户端的状态有一个感知能力。比如说有时候客户端的网络质量不好，或者说因为一些网络错误、SSL证书的错误，连接到CDN之类的失败了，导致最终请求没有到达服务端。

此时，你看SLA报表里面显示一直是OK的，但其实这时候用户真实的体验并不是这样的，他对服务的感受其实已经是很糟糕了。所以我们就需要有客户端的监控体系，在这个报表里，就可以用一些指标，将用户真实的用户体验反馈出来。