围绕故障管理谈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值守等。

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

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

围绕故障管理这条主线，我们把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的，但其实这时候用户真实的体验并不是这样的，他对服务的感受其实已经是很糟糕了。所以我们就需要有客户端的监控体系，在这个报表里，就可以用一些指标，将用户真实的用户体验反馈出来。

2）架构设计

架构设计可能会更偏业务侧一些。我们在故障之前，要尽可能做好服务的架构设计，同时在做一些预案之前，也要把服务架构做好梳理。只有当我们把服务的架构了然于胸，才更有可能在故障发生的时候从容不迫，更好地定位问题。此外，要更多去加入柔性设计，也就是说你的服务要具备一些像降级熔断、故障隔离这些手段，要有这样的柔性设计在里边。这样架构可以提供这些能力，后面才能更好地去做服务的保障。再有一点就是，要尽可能的去规避常规的风险点，比如说单点之类的；同时还要尽可能地去规避架构里面常见的坑。

下图是我们偏运维侧的一张数据流向图：

主要是说明一个业务包含了哪些域名，大概经过了什么链路，经过了哪些中间组件，最终到达了服务端。

3）容量评估

下图是我们压力测试的一个页面：

以这个图为例，容量评估其实就是我们的服务在上线之前，要去对服务的承载能力做一个压测，这样我们才能更好的了解服务上线之后的状态。然后我们基于这个，再根据业务方量级的评估，去规划服务的容量。

但有一点需要注意的是，容量评估是不是要完全基于这些压测来做呢？在做压测之前，有没有一些其他的手段可以辅助我们，来更科学地做容量评估呢？其实是有的，但很多时候都被大家忽略了，也就是数学计算。

容量评估其实是不能完全依赖于压测的。在压测之前，要基于我们对自己服务的理解，包括每一条请求大概会耗费多少资源等，要有一个基础的认识，再基于这些认识去评估大概需要用多少后端资源、大概会用多少CPU内存，这些东西是可以用数学计算的方法来计算出来的。当然，非常精确的计算可能比较难达到，但这个手段是不能忽略的。我们要先有一个粗略的计算，再去辅助压测，才能最终得出一个比较科学的容量评估。

其实像Google这种大厂里面，他们有专门容量评估的系统，但目前业界据我了解，是没有这方面特别好用的系统。如果大家知道什么比较好用的系统，也可以在评论区留言，我们交流一下。

4）灾备预案和灾备演练

这两点是比较关键的，跟故障会更强相关。下图是我所整理的关于怎么做灾备预案和灾备演练的架构图：

我们把这个过程分为了五个环节，基本按照这五个环节来做，灾备预案就差不多可以完全覆盖了。下面来具体地说一下：

服务梳理：在服务梳理阶段，要基于前面的架构图等来梳理请求链路，要分段分层地梳理请求都经历了哪些层次、有哪些阶段、经过了哪些设备、周边有哪些依赖（包括内部的服务依赖、后端的资源依赖、第三方的依赖等），然后还要梳理架构目前是不是有什么风险、流量有没有经过一个单点、有没有哪个点可能是存在瓶颈的……这些都是我们在服务梳理阶段需要去梳理清楚的。
预案梳理：了解各种情况后，就可以梳理相应的预案了。仔细分析应该用什么样的手段来覆盖，将风险各个击破；然后要尽可能地做多级预案，因为预案如果只有一级的话，容灾能力是不够柔性的；此外，还要借助到一些智能调度的手段；最后就是柔性设计，前面也有提到，是更偏业务侧一些，也就是说在服务里要有尽可能多的手段来做自己的一些failover，可以去做一些降级、熔断等。
沙盘推演：梳理出来预案后，并不是直接到做演练。要了解预案是不是真的有效，不是直接做演练，而应该是先想清楚。我的建议是去做沙盘推演。在这个过程里，我们要尽可能去发动多的部门协作起来，来看我们的预案是不是有效。毕竟人多力量大，并且不同团队的人对业务可能有不同的理解，在这种头脑风暴下，就有可能碰撞出更多的可能性。然后在这个过程里，会基于一些可能的故障场景、case等来做推演，当故障场景A出现了，梳理出了预案A’，那 A’能不能把故障A完全解决掉？在解决故障场景的时候，有没有引入一些其他的风险点或问题？在这个过程里面，我们都要想清楚，当得出一个大家都认可的推演结果后，预案才推演完了。
预案落地：这一步是需要做落地，包括文档输出、功能实现、架构适配、工具建设。
预案演练：落地之后，要通过演练的方法来验证预案是不是真的有效。在这里，我大概列了几种。比如无损演练和轻损演练：我们做故障演练要尽可能地做到对业务无损，但有些预案本身应对的故障场景就是会损害业务的，那这种时候我们要尽可能降低这种演练带来的损失，比如说选不同的时间段、流量的控制、灰度之类的，尽量去做轻损的演练，既然我们是通过故障演练的方式来确保预案有效，那肯定不能因为故障演练而演练出一个大的故障，这就有些得不偿失了；还有就是单点演练跟组合演练：你的演练到底是要一次演练某个模块，还是说要把一个大故障场景里所有涉及的点都演练一遍？这个也是我们在预案演练里需要考虑的。

下图是美图内部灾备预案和故障演练的例子：

大家可以看到，我们是分了几级来做的预案，包括数据的冷备、同城的双AZ、异地灾备、热备等。我们在做故障梳理的时候，大致也是按照前面讲到的环节来做：先梳理（分为研发侧和运维侧梳理），然后盘点（盘点这个过程里有哪些故障点），再做case推演，而后是预案的输出，最后是演练。

5）持续交付

持续交付也是需要我们在日常建设中就做好的事情。

举个例子，10年之前，我们用的机器大部分都是物理机，当线上发生了一个故障，定位到的原因是有一波大流量导致性能扛不住了。那么这时候应对策略首先想到的是什么？是扩容。只有扩容才能完全的扛住流量，才能降低损失，否则的话，就只能是做有损的降级，也就是把请求丢掉。那么这个就涉及到持续交付能力。

回过头来，时间放到现在，如果我们选择了云、容器，它本身基础设施架构就具备了弹性伸缩的能力，具备更快提供扩容的手段，那么问题是不是就解决了呢？不是。与持续交付相关的场景还有非常多，万一发生故障，去做修复的时候发现持续交付的能力跟不上，其实还是会拖长故障恢复时间。

上图几个是我们目前公司在用的一些持续交付的体系组件，可能大家也都比较熟悉。可能除了最右上角这个，是我们公司内部开发的一个基于K8S的云管平台，支持多集群管控，内部代号Matrix。与其他外部的云管平台类似，不过我们开发得比较早。基于这些基础设施的存在，我们能够保持良好的持续交付能力。

上述讲的都是我们在故障管理之前需要做的事情：在故障来临之前，如何做好预防和准备，以及应对的能力储备。

2、故障中

当故障真的发生了，我们应该怎么做？去发现定位和恢复。这里列举几个比较核心的手段：监控告警、日志分析、链路跟踪、故障隔离、容灾切换、降级熔断。只看字面意思也很好理解。下面我将以图结合案例分享具体做法。

1）监控告警

左图是一个流量突变的告警，可能是大家常见到的一种，通过这种文字的手段把报警发给你。这里有一个点引起关注，突降30%，它其实是不同于常规那种告警，说目前的某个指标超出某个值或者低于某个值，或达到什么水平线那种阀值的告警。两者区别在于，突降是通过对比值得出的结论。这个示例说明在做监控报警时，可能需要考虑的建设点，想想是否有这类需求，有没有这类场景。

最右面的图看起来比较酷，它是怎么实现的呢？它的意义是什么？对比前面这两张文字图，文字图只是告知流量突降30%，这是一种告警方式。中间的图就是由名为“监控大盘”的机器人发送出来的，也是我们服务的架构图。放大图看，我们的业务模块、交互链路已经暴露出来了；图中有一块是红色的，红色代表标识异常，与异常关联的某个组件就变成淡绿色。

由于红色这块故障引发了另外一个异常，接连引发了一个又一个的异常。通过这张告警图，收获了更多的信息：首先知道系统挂了，或者系统异常了，然后这次异常大概是由什么引起的。一张图就可以让你非常快速地感知。现在有了这张图，不再需要文字告警来通知我组件异常，也不用翻找过往经验做排查。只要看图就能结合已有的监控系统直接做分析、排查，最终得出结论。后者这种监控手段就是让故障背后的原因甚至根因更快触达到用户。

具体是怎么实现的呢？这是基于grafana的插件flowcharting基于draw.io的一个绘图，结合我们的数据填充和告警配置来实现的。

2）日志分析

3）链路跟踪

4）预案执行

日志分析、链路跟踪、预案执行都是定位手段，在已经定位问题之后，并且匹配了相应的预案，要求去执行预案。当然前提是有相应的预案应对故障场景。然后依据操作手册，分别按不同的故障层次去执行处理。

恢复之后还要确认执行结果，看服务是否恢复正常。这是我们在故障处理中实际案例的截图。下面进入非常关键的故障后环节。

3、故障后

大家要重视一点，在故障发生和解决以后，以为问题真的结束了吗？其实并没有。在故障后，我们应该做好以下环节：故障复盘、故障改进、预案完善、容量压测、故障模拟、周边清查。我解释下其中几个概念：

预案完善：故障发生之前有做过预案，这些预案是不是完善的？在故障处理的过程中，有没有暴露出问题？是否要完善之前的预案中做的不完善的地方等等；
故障模拟：意思是用某种手段模拟某些故障，提前知道该如何解决这些问题；
周边清查：应该具备举一反三的能力，比如A服务出故障，那么A服务周边有一些相关联的服务有可能会受到影响。举个例子，比如集群里面有N台机器，收到机器A磁盘接近100%的一条告警，只需处理机器A就可以了吗？当然不是，在处理完该异常之后，肯定要查看同集群的其他机器是否存在类似情况。

1）故障复盘

在故障复盘阶段，最核心的思想就是要回顾关键的时间点：故障是从什么时间发生的？从什么时间到什么时间结束的？在这过程里面有哪些非常关键的操作？有哪些关键的信息？从什么时间点定位到问题？在什么时候执行怎样的操作？这些时间点都是非常重要的。

在故障复盘的过程中，要把这些操作的时间点一一还原回去，才能完整地回看操作是否合理有效。看在某个时间点执行了某个预案，思考某个时刻做出这样的操作是否恰当，此时有没有其他更好的手段能够恢复服务，某个时间段为什么没有及时处理而导致故障时间变长等等。

做好故障复盘，我们有黄金三问法：

我们应该怎么做，才能更快地恢复业务？
我们应该怎么做，才能避免再次出现类似问题？
我们有哪些好的经验可以总结、提炼，并固化？

基于以上三个问题，通过自问自答的形式弄清故障复盘。

这是故障解决后绕不开的一点，在故障发生后都会做一个报告，上图就是我们内部的一个故障报告模板。在报告里面写清楚故障级别、责任人、处理过程、改进措施，将这些关键点归纳成故障报告的文档。

到此做个总结，故障本质上是持续迭代的，当故障发生了，开始恢复、复盘、改进、验收，回到稳定运行的状态，再过一段时间又出现故障。同时，服务也持续地迭代，因此要不断去提升稳定性，这是我们都逃不出的一环。

四、故障管理体系

为了做好故障管理，需要建设一些SRE体系提供支撑，下面谈谈故障管理体系应该有哪些内容以及如何建设。

1、可用性体系

关于可用性体系里面的三个名词需要达成一致的理解。平时我们所讲的SLA并不是真正意义上的SLA。SLI是指标，SLO是目标，SLA是我们的目标加上目标未达成的后果，通常运用在双方一些商务合约上，例如使用某云厂商的服务，对方承诺可用性不低于99.95%。一旦没有达到我的要求，处罚性的或者赔偿性的一些条款将会生效，这才是真正意义上的SLA。

那么如何选择SLI？参照VALET法则，有五大选择依据：

容量（Volume）：服务承诺的最大容量是多少，从QPS、TPS、流量、连接数、吞吐思考；
可用性（Availability）：服务是否正常，看HTTP状态码2xx的占比；
延迟（Latency）：服务响应速度是否够快，rt是否在预期范围内；
错误率（Errors）：错误率有多少，看HTTP状态码5xx的占比；
人工介入（Tickets）：是否需要人工介入处理，考虑人工修复。

2、故障定级、定性、定责

1）定级：通用标准

这张图列出的故障等级衡量指标是非常具备参考性的，可以基于此建设自己的故障等级体系，看看用哪些指标来衡量故障的影响，从而给服务定级。图中列出四点都是常规的考核项，主要看对服务功能的影响、影响时长、故障所发生的时段、对用户的影响范围。对用户影响范围就是看是主要功能还是次要功能不能使用，大概会算出权重占比。

2）定级：个性化标准

除了通用标准，还有一些没有被囊括到体系中来，比如某些电商类、商业化、广告类和金融类的业务，有可能造成资产损失，那么不同的部门会有不同的故障管理的定级策略。为此，我们要把这些不同部门的体系映射到通用的定级标准里面，以便更好地管理。

注意这里个性化标准是无法规避的。它的存在体现了康威定律：一个设计系统的架构受制于产生于设置架构的组织，业务架构体现组织关系。定级制度同样体现了不同部门内部个性化之处，所以要有方法去把它映射成通用的定级标准，只有我标准统一了，才有可能坚持推行好故障管理。

3）定性：有效分类

上图是故障定性的一些有效分类，即定性故障是由什么原因引起的。是代码质量、测试质量、流程规范出了问题，还是变更操作不够规范呢？还有其他种种原因，我们要对故障做定性的分析和归类。

4）定责：判定原则

定责任并不意味着处罚。我们整体的故障管理从原则上来说尽量不指责，但不指责不代表着可以持续犯错误。这里由于时间原因重点解释四个原则：

高压线原则：不能犯一些低级的错误；不能持续犯某些错误；
上下游原则：根据服务的上下游依赖程度去做判断；
健壮性原则：根据服务的健壮性定性。例如服务A挂掉导致服务B出问题，这时候责任不能完全划分到服务A上，还要考虑到服务B本身的健壮性；
第三方默认无责：内部做故障定位时，默认第三方无责，当然该追责的还是会追责。

3、错误预算

在SRE里经常听到错误预算，如何做到实际落地？前面讲了故障的定级规则，明确定级规则之后，不同的故障被定为ABC级，按对应计分标准扣分。扣的分数来源于给出的预算。我们每半年为一个OKR考核周期，在一个考核周期里面每个BU会分到一定的故障分，允许在考核周期里由于故障被扣分，如果分数扣完了意味着错误预算用完了。这里提到的和Google SRE类似，即可用性达到多少标准，发布将受到限制。我们将错误预算和OKR做了绑定，让大家在目标驱动之下达成这个目标。

4、组织结构支撑

故障管理特别依赖于组织结构的支撑，因为故障管理不仅仅是运营部门或者技术保障部门能单独完成的事情，需要不同团队协作。为此，我们成立了故障管理委员会。故障委员会是一个虚拟的组织，不是一个实体的组织，由BU接口人负责故障委员会故障判定和定责之类的事情、传达信息给BU内部。

我们从上往下看。当故障发生了，基于判定规则给故障定级、定责。定级意味着每个级别产生对应的故障分；定责会涉及到故障的拆分，比如发生了一个故障，它由A、B两个部门共同承担。根据定责发现责任上A、B部门实际是五五开，因此A、B平分故障分，再从A、B部门的BU负责人各自的错误预算里扣除故障分。

通过这种方式就能约束好BU吗？当然不是，要用行政手段来保障，那就是OKR。周期OKR里需要有服务稳定性的目标项才行，把服务稳定性写进OKR后，BU出于压力而去共同做好故障管理。在上述这种组织支撑的情况下，才能更好地推行故障管理。

五、SRE体系建设

1、稳定性建设

看SRE稳定性全景图，按照 MTBF和MTTR，把日常时间分成几段，不同时段里要做哪些事情？先是建设演练、Oncall值班，然后应急响应，最后复盘改进、再Oncall。在一个循环里面完成了SRE的工作。这张图里有一些需要我们持续关注的前沿部分，例如AIOps智能预测、混沌工程。

2、PPTV

最后以PPTV总结SRE体系建设，即PPT+V。PPT包涵了人员、流程、技术，是ITIL中的IT管理的三要素。SRE体系建设同样无法脱离这个模型，做好故障管理要有一个合适的组织结构、流程流程保障。光有前两者没有办法落地，还要有强力的技术保障支撑。

在此基础上，我给增加了Vision即目标。只有对稳定性的建设有共同的目标期许，才能做好SRE。不同的业务部门要有对服务稳定性的一些共同追求，不管出于行政压力，还是基于自身对服务稳定性的追求，我们都要有统一的目标。PPTV做好以上四点，更有利于SRE体系的落地。

六、未来展望

基于当下的想象力，我对未来有一些必要和明确的期待。第一点个人认为是AIOps，很多大厂已经涌现出一批AIOps开源的东西，大家都在做一些探索。但是AIOps何时能实现大规模落地，应用在SRE建设并发挥更大的价值，甚至驱动SRE自我革命，目前都无法给出定论。

第二，混沌工程Chaos Engineering 在做故障发现时可能有用，已经有一些公司对此进行探索。以上就是我认为可能有好的未来发展的两种趋势。

>>>>

Q&A

Q1：请问DevOps与SRE是什么关系？

A：看来大家对DevOps vs SRE的问题还是比较热衷的，在很多场合下都会听到这样的问题。从我的理解来看，两者在工作范畴上是存在交叉重叠的，两者最本质的差异应该在于组织目标的侧重点上，即：效率 vs 稳定性。

Q2：如果维护对象质量太差，该怎么做SRE呢？

A：恩，这个问题还是略“尖锐”的哈。感觉可以从两个方面入手吧：

① SRE需要提升自己的掌控能力，尽可能用自己的掌控力去cover维护对象本身的质量问题；从另一个角度来看，不管你维护的对象本身质量如何，如果你都能够应对自如，这正是SRE的价值所在。

当然，上面这个状态是比较理想主义的，除此之外SRE还需要做到下面这点。

② 从SRE的角度给服务的研发、测试甚至是产品同学提出合理的建议，辅助提升产品的质量。这里就可以引用我们在直播中所讲到的“故障前的准备工作”的方法框架，比如柔性设计：这可能并不是所有的服务在设计之初都有考虑、实现的，然后这些特性却都是有助于我们更好地去保障服务的。这时候我们就可以提出相关的建设意见。

其实「服务质量」本身就是一个需要跨部门协作的事情，在统一好目标的前提下，去推动共同建设就好。

Q3：关于SRE团队组成，开发+运维的占比人数大概应该是怎样的一个组合呢？

A：这个还是要看具体的场景吧，看业务的复杂程度、看SRE团队的技术功力。像Google、Netflix等SRE理念落地成功的案例中，研发运维比就会比较高，比如Netflix只有个位数的核心SRE，支持着全球的业务。

Q4：石老师，请问那个架构图里标识出异常模块，是如何实现的？

故障管理-监控告警

A：我简单说一下实现思路，有需要的可以自己去了解一下，网络上也有一些相关的资料。

用到的技术、工具主要有：Grafana、Grafana的一个插件Flowcharting、Grafana-images-render、draw.io在线绘图、企业微信机器人(钉钉、飞书等其他企业IM也是同样的)、用户发送告警的脚本或平台。

实现步骤：

① 实现图的动态数据功能

draw.io绘图(https://app.diagrams.net/)。
将draw.io绘制的图形源码（*.drawio 文件）完整copy到Grafana (Grafana → Visualization → FlowCharting → Source Content)。
为图形配置数据源。
将图形中的各个元素(图块、线条)跟对应的监控指标绑定。

② 实现告警发送功能

获取监控图的渲染地址，用Grafana-images-render渲染为公网可以访问的图片
编写告警脚本实现发送监控图到企业微信等IM工具的告警通道
配置Grafana的告警功能，在告警触发的时候调用上一步中的告警通道，把告警时刻的监控图图形发送给告警接收人

下面贴一些资料，供大家参考：

插件教程：https://algenty.github.io/flowcharting-repository/STARTED.html
在线演示：https://play.grafana.org/d/_J1UvKjWk/flowcharting-aws-cloud?orgId=1
插件源码：https://github.com/algenty/grafana-flowcharting
插件首页：https://algenty.github.io/flowcharting-repository/
插件安装：https://grafana.com/grafana/plugins/agenty-flowcharting-panel
插件效果：https://twitter.com/gf_flowcharting/status/1183386365175746562
插件交流：https://twitter.com/gf_flowcharting

Q5：请问新组建的SRE团队应该怎样快速成长，尽快成熟？从哪块入手比较好？

A：回归到IT管理的3要素上，人员、流程、技术：

可以先从意识层面入手，让大家的目标、思路能够基本保持一致；也就是人。
然后约定一些必要的流程、规范、协助工具；约定统一的“语言体系”、沟通机制；在前面的基础上小步快跑，逐步校正和迭代；这个事情不可能一蹴而就，在实际工作需求中练兵；及时沟通、反馈，多反思、复盘；这个点更偏流程。
技术的话，作为一个基础点，可以先从业务需求入手，让团队把必备的技能拉齐到一个理想的水平线行，先做到能hold住服务；在这个目标达成之后就可以考虑做更长远的技术规划和更深的技术探索了。

Q6：现在SRE在美图发展的怎么样，工具平台是否都能自己团队搞定？

A：还是看具体的需求场景，注定有些需求是无法由单一团队完成的，这时候就需要借助外力来辅助或共建。

这里可以对齐一个理解和认知：全能全知的人是不存在的，依靠团队的力量可以让一群人的能力得到互补和延展，但同样也没有任何一个团队可以做到全能全知；这时候就需要有更高维的能力补充，跨团队协作就是最常见的方式之一。

所以，我们需要明确好我们的目标是什么，是解决具体的需求，还是要打造一个全能的团队；怎么选择会更具可行性、ROI会更好，这个或许就见仁见智了。

Q7：对于Trace系统选型和实践，美图是怎么做的呢？

A：基于开源的产品做了封装和适配。如果是小团队的话，建议直接使用开源的产品，目前这块的很多产品都是比较成熟的。

Q8：请问服务降级、熔断通过什么技术手段可以实现？

A：一般可以从3个层次来做实现：