您的位置:  首页 > 技术杂谈 > 正文

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

2022-09-16 18:00 https://my.oschina.net/5129714/blog/5578386 TakinTalks稳定性社区 次阅读 条评论

# 一分钟精华速览 #
美图公司旗下产品月活用户达2.409亿,每月平台上大概会产生60亿的照片和视频。这样庞大的用户体量下,美图SRE团队作为公司最稳的大后方,如何尽可能地保障和提升服务的稳定性? 2021年8月美图出现了一次严重的线上故障,结合各种踩坑和摸索,SRE团队 总结出了一套围绕故障生命周期的“前中后”三段式 故障治理 方法论,具体如下:

 

作者介绍

 

美图SRE负责人-石鹏

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

 

温馨提醒:本文约4400字,预计花费7分钟阅读。后台回复“8201”获取文件资料;

「TakinTalks稳定性社区」公众号后台回复 “交流” 进入读者交流群;

 

美图“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也都自动缩容了,只保留非常低的流量。当故障恢复,流量重新进来的时候,如果不提前进行预扩容和数据的预热以及流量控制等操作,很容易会引发二次故障。

         

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

       

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

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

       

      四、总结一下

       

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

      公众号回复【8201】关键词获取讲师PPT

      公众号回复【交流】进入读者交流群

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

       

      展开阅读全文
      • 0
        感动
      • 0
        路过
      • 0
        高兴
      • 0
        难过
      • 0
        搞笑
      • 0
        无聊
      • 0
        愤怒
      • 0
        同情
      热度排行
      友情链接