围绕故障管理谈SRE体系建设

本文根据石鹏老师在〖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值守等。

 

看上图中红色的