美图 SRE：一次线上大事故，我悟出了故障治理的 3 步 9 招

# 一分钟精华速览 #

美图公司旗下产品月活用户达 2.409 亿，每月平台上大概会产生 60 亿的照片和视频。这样庞大的用户体量下，美图 SRE 团队作为公司最稳的大后方，如何尽可能地保障和提升服务的稳定性？

2021 年 8 月美图出现了一次严重的线上故障，结合各种踩坑和摸索，SRE 团队总结出了一套围绕故障生命周期的“前中后”三段式故障治理方法论，具体如下：

作者介绍

美图 SRE 负责人-石鹏

2016 年加入美图，运维技术专家，美图产品 SRE 负责人。目前在美图负责社区、商业化、创新等全线产品的运维保障工作，同时参与公司日志、监控等基础设施的建设。参与或主导过多次公司基础设施的调整、改造，在监控、灾备、故障管理、稳定性运营等方面有一定的经验和积累。

温馨提醒：本文约 4400 字，预计花费 7 分钟阅读。

关注「TakinTalks 稳定性社区」，回复“8201”获取文件资料；回复 “交流” 进入读者交流群；

美图“818”故障回顾

大概一年前我们发生了一个七层负载均衡误操作的大故障。这个问题是怎么发生的呢？

• 起因

去年美图对容器集群版本进行了升级，升级之后需要要退订部分老节点。当时具体的做法是通过一系列的条件来筛选节点，退订这部分筛选出来的节点，但在这个过程中因为我们的筛选条件不够严格， 导致退订的节点里包含了 7 层的 Ingress 的节点，这是起因。

• 爆发

因为类似操作我们进行过很多次，所以这次直接采用了自动化的手段，批量“咔咔”把筛选出来的节点全给退掉了，结果只留下了极少数的 Ingress 节点(也很快由于负载过高被打挂)，最终引发了非常严重的问题（由于某些原因，在此不做详细陈述）。

• 解决

尽管这个故障非常严重，但因为之前我们搭建了比较完善的应急响应机制（也是我这次会重点分享的部分），内部反应非常迅速，我们快速拉起了 WarRoom，卷入了相关人员来应对，同时我们之前做的一些应急预案(同城灾备、异地灾备、基础设施逃生通道等)也发挥了重要的作用。最终这个故障在相对较短的时间内得以恢复，可以说这都是依靠美图平时持续在投入和推进的故障治理工作。

凡事皆有章法，所以故障治理这个事情也有规律和方法可循的。做好故障治理，我们美图是围绕故障生命周期进行管理的，关于这个故障生命周期的管理，先做个简单的三段式拆解，分为故障前、故障中、故障后，那每个阶段应该要做哪些不同的事情呢？

一、故障发生前我们做了哪些工作？

在故障发生前，我们做了下图所示的一些工作，包括：

• 做好监控覆盖，确保核心系统都有监控指标以及告警覆盖；

• 做好架构设计，很多故障发生都是因为在架构设计之初就存在不合理的地方，我们需要尽早的识别并规避掉这块的风险；

• 服务上线之初就要做好容量评估；

• 在整个运营阶段，要做好灾备预案，并且通过灾备演练来保障预案的有效性；

• 通过制作自动化的工具来提升工作的效率；

• 日常的 oncall 和常规巡检也是不能缺失的；

• 针对流量高峰期、节假日或者一些容易引发故障的点，我们要进行重点保障；

• 
  

这边选取几个大家关注度比较高的工作，结合美图的实践来跟大家详细说一说。

1.1  可观测建设

监控覆盖放大了讲，就是现在大家提的比较多的可观测性的建设，通俗的来讲就是我们常规在做的 Metrics、Log、APM、Trace 以及事件，针对这些做一个更好的融合和串联，目前美图也在做相关的尝试和探索。首先我们针对各个环节都做了比较多的关键指标的识别，也做了很多相关工具的开发与适配。

下图是我们做的监控大盘，前面提到我们做了许多监控相关的工作，最终需要给使用者提供一个便捷高效的 UI，让他能在一张图里看到各个服务的状态、整个链路的表现。这样在故障发生的时候，我们也能比较清晰地看到到底是哪个模块出现了问题，可能的原因是什么，从而提升故障识别和定位的效率。

（美图公司-某业务的监控大盘）

针对巡检我们制作了巡检大盘，所有的域名、服务的 SLA 都体现在这个报表里，当发生比较大范围的故障时， 就可以非常清晰地看到有哪些服务受到了影响。另外在日常巡检的时候，通过巡检大盘也可以非常清晰地看到全局的状态，识别哪些服务是需要去重点关注的。

（美图公司-域名 SLA 巡检大盘） 

从监控大盘里的服务下钻就可以看到具体单个域名的可用性报表，这块应该很多公司都有相关的实践。

（美图公司-某个服务单个域名的 SLA 报表） 

1.2  灾备建设

先讲一下方法论，下图是灾备建设的一个流程体系，按照这个思路来做相信可以把事情做的比较中规中矩。

具体可以分为服务梳理、预案梳理、沙盘推演、预案落地、预案演练这么几个阶段。

• 服务梳理：在这个过程中要识别请求核心链路，然后进行分层分段，还得识别到服务的周边依赖，最重要的是识别架构中的风险，包括单点、瓶颈点都需要识别出来；

• 预案梳理：这个阶段要针对前面识别到的这些风险去逐个击破，针对不同风险制定多级预案。在代码层面也就是研发侧也需要去做一些柔性设计，基础设施部分要去做一些智能调度之类的事情。

• 沙盘推演：有了预案不是说马上就可以去落地实施的，我的建议是先做推演。这部分就涉及多个部门的协作了，需要大家一起针对前面梳理的 case 进行沙盘推演，通过头脑风暴、互相挑战去确认预案的有效性。这个预案是想解决某个问题，但它真的有效吗？有没有一些其他的边界条件或者场景没有识别到？讨论碰撞直至达成共识，再考虑后续的落地。

• 预案落地：预案的落地除了你的工具建设，还需要文档流程以及一些基础设施的适配工作；

• 预案演练：演练又分无损演练、轻损演练，根据你演练的范围又可以分为单点演练或者组合的演练，通过演练的方式来验证和保证预案的有效性。

1.3  基础能力建设——工具研发

将所有的保障工作落到工具里，并且可以自动化地去处理是我们要追求的目标。在基础能力建设方面美图也做了非常多的工作，应急响应平台、稳定性运营平台、压测平台这几个与稳定性保障是相关性比较高的。另外还有有一个 Matrix 容器多元平台，为我们提供云上容器的基础设施，它里边的相关能力对稳定性的保障也有非常大的作用。下面为大家稍微介绍一下我们的应急响应平台、稳定性运营平台、压测平台。

1.3.1  稳定性运营平台

这个平台承载了日常巡检、数据存储、报告渲染、数据解读的一些工作。其实线上所有的稳定性相关数据数据本身是没有价值的，我们对数据的理解、解读以及由此推导出来一系列手段措施，它才能够真正地产生价值，提升系统的稳定性。

1.3.2  应急响应平台

我们将针对服务稳定性制定的干预手段抽象成一个个原子性动作，再编排成预案去应对不同的场景。其中动作的编排可能是并行或者串行，预案可能会有多级，当然最终还是要基于场景去匹配。平台工作具体的执行逻辑就是从「监控大盘」到「动作管理」到「预案编排」再到实际的「预案执行」，是一个非常连贯的工作流。

1.3.3 全链路压测平台

在压测方面由于时间成本、人员成本、沟通成本以及 SLA 风险的痛点明显，美图由架构组主推构建了全链路压测平台，可以满足压测方面的相关需求。平台拥有流量拷贝/回放、流量过滤/修改的能力，支持编排流量梯度、压测场景管理。当压测过程中对 SLA 产生影响的时候，平台会主动的停止压测，主动进行止损，同时它还可以自动生成压测报告。

（后台回复“全链路压测”获取 开源项目地址）

二、故障发生的时候我们是怎么做的？

可观测性的几个点肯定要关注，比如监控告警、日志分析、链路跟踪这些。

因为很多故障的引发原因是人为操作/变更，所以这些变更或者操作我们都形成事件记录下来，当故障发生时需要去查看哪些事件可能会与这个故障相关，这个操作可以加快故障定界定位的时间。

故障定界并不一定是要定位到根因，而是要识别这个故障的影响的范围是什么、边界的在哪里、可能是哪一阶段出现的问题，我们有没有对应的预案可以匹配到。如果有的话就立刻去执行，这里会有不同的手段，比如将故障隔离起来、去切换容灾线路，还有降级熔断的一些手段都可以去实施。还是一样挑几个重点跟大家分享一下。

2.1  图文告警更实用

告警这里通过一个实例来跟大家分享，传统的报警都是文本类的，我们美图现在做的是图文告警，前面介绍过我们的监控大盘，当故障发生的时候，我们会将监控大盘的实时状态给发送出来，这样用户在接收到报警的时候就可以一览服务的整体状态，清晰地看到这个服务异常可能是由哪个环节哪个模块所引起的，大大减少故障定位时间。

2.2  日志和 Trace 基础要打好

日志是比较常规手段就不再赘述了，而 Trace 在各个企业里边都有应用，在服务排查的时候是非常重要的。这些手段需要我们做好前置的建设，这样在故障中才能很好地去利用的。一定要避免“我们建了很多工具体系，但在故障的时候都没有发挥作用”的情况。

2.3  故障处理的一些原则和建议

在整个故障处理过程中的一些原则和建议总结起来有这么几个点：

• 目标一定是恢复优先，问题定界要高于根因定位；

• 心态方面 SRE 作为服务稳定性的守护人，一定要冷静，遇到故障不要慌；

• 流程机制方面， 在整个故障处理过程中需要有流程来保障，在需要的时候要及时扩大故障处理范围，卷入更多角色，适时启动 War Room，通过会议室或者线上会议室，把更多的相关人员拉在一起去协作；

• 关于现场的建议是：组织之间如何协调要有约定并达成一致， 此外还要明确信息的通报机制。在故障处理过程中，尤其是大型故障，很多人都非常关注，包括服务的研发、你的老板，甚至是客服也会承压。他们都需要得到一个信息的通报与反馈，因此要明确的这个机制，定期或者在什么特定的时间点去做信息的周知，否则一边要处理故障一边还要忙着去响应各种问询消息，只会让现场越发混乱。

• 故障恢复的过程中有一个点需要注意的是，在应对大型的故障，尤其是流量入口层的故障时，需要逐步地放量、慢慢恢复。以美图 818 故障为例，入口的 Ingress 故障了，你的流量就没了，入口流量没了对应后端服务的 Pod 也都自动缩容了，只保留非常低的流量。当故障恢复，流量重新进来的时候，如果不提前进行预扩容和数据的预热以及流量控制等操作，很容易会引发二次故障。

  
  

三、故障后的工作重点是什么？

故障处理之后的工作也是故障治理非常重要的环节，重点就是复盘与改进。在这个过程里可以总结吸取经验教训并改进，这样才能让我们整个系统的稳定性得到实质性提升。复盘里面的内容就比较多了，你要去审视之前做的预案是否完善，有没有哪些新的场景没有识别到？根据结果进行完善，然后举一反三，针对故障周边做彻底清查，这个服务发生了问题，那与它类似的架构或者类似链路中的点，有没有可能发生问题，如果有的话我们要及时识别并处理。

在这整个过程中，不管是教训还是经验都需要去固化，固化成流程的修复或者工具里的一些卡点都是可以的。因为这块内容比较多，下次咱们专门讲一讲美图的故障复盘和管理工作是怎么开展的。

四、总结一下

故障治理是稳定性保障中的重点，甚至可以称之为是核心内容。每一次故障就像一次考试，平时围绕稳定性做的所有的工作成效如何都会在故障中得到检验。所以只有在平时做足了准备，才能在实际生产中有更稳定的表现，对此切勿心存侥幸。

声明：本文由公众号「TakinTalks 稳定性社区」联合社区专家共同原创撰写，如需转载，请在公众号后台回复“转载”获得授权。