从全链路监控,落地SRE稳定性运营

石鹏 2022-03-30 10:09:08

本文根据石鹏老师在2021 Gdevops全球敏捷运维峰会-广州站〗现场演讲内容整理而成。

 

 

图片

(文末可获取完整PPT)

 

讲师介绍

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

 

前言

 

监控一直以来是个老生常谈的话题,本文将从监控出发展开SRE的相关讨论,同时给大家分享两个开箱即用、特别适合中小企业的实战内容,希望大家看完之后对SRE会有更为具象化的了解,且能将本文内容运用到实践中。

 

首先介绍一下美图公司的大致情况。目前,美图有toC和toB两大方向的业务,在影像美化、美妆、皮肤管理这三大板块均有toC的产品或toB的行业解决方案。

 

图片

 

其中,面向用户的产品,有大家比较熟悉的美图秀秀和美颜相机等(女生可能更为了解);面向行业的产品,有开放平台、美图宜肤、美图云修、品牌星球等。

 

图片

 

上图是美图截止到2020年的一个大致的数据:2.6亿的月活跃用户数,已在20多亿的独立设备上激活使用,每月平台上大概会产生60亿的照片和视频。

 

下图是本文的整体脉络:

 

图片

 

一、美图SRE的核心工作职责

 

现在各种岗位概念层出不穷、千变万化,很多同学因此会感到焦虑。但无论如何变化,只要回归到岗位核心价值我们就能找到方向。在美图,SRE岗位的核心价值就是这个岗位的核心工作职责,抽象之后就是三个点:

 

  • 稳定性

  • 效率

  • 成本

 

图片

 

美图对SRE的愿景是做公司业务最稳的大后方。相对比PE、OP、SA这些岗位,SRE需要输出的核心价值是中间的Reliability(稳定性),同时效率和成本也需要同时兼顾。

 

如何平衡3个核心职责之间的关系?

 

图片

 

SRE的工作既要稳定性,又要讲究效率,同时还要管控成本,大家会质疑这是不是一个不可能重合的三角呢?SRE这一角色,其实就是需要平衡好这三者之间的关系,而在这个过程中就会涉及到如何去评估量化所涉及的各个部分。

 

如何量化评估?

 

管理学大师彼得·德鲁克(Peter F.Drucker)说过:“如果说你不能度量它,你就无法去改进它。”( if you can't measure it,you can't improve it. )

 

对于SRE来说,一个可靠的、稳定的度量体系是必不可少的东西,运维日常接触最多的监控系统,就是SRE具象化的度量指标。所以一套稳定可靠的监控系统,对SRE工作的指导意义是重大的。

 

图片

 

  • 稳定性

我们的稳定性目标、故障恢复的效率会细化成很多具体的指标,对应有平均故障恢复时间和平均无故障时间(即MTTR和MTBF)。

 

  • 成本

成本是很好量化的,因为可以很直观体现在财务数据里面。对于运维来讲,除了最终的成本开销,还需要去关注资源使用量和资源利用率,这些指标是需要用技术手段来提供数据支持,用到的工具就是监控系统。

 

二、低成本全链路监控大盘实践

 

图片

 

上图是美图监控体系建设中选用的一些组件,常见的有:Prometheus、ElasticStack、OpenFalcon、InfluxDB套件、SkyWalking分布式跟踪,还有基于eBPF去做的一些偏底层的监控……整体体系非常庞杂,结构也不够清晰。

 

为了解决这个问题,首先我们梳理了当前在用的监控系统,并做了分类归纳。上图就是我们梳理后呈现出来的美图监控体系,主要分为:一个是用户端的质量监控体系,一个是服务端质量监控体系。

 

图片

 

  • 用户端的质量监控体系

主要包含两大块内容:用户端监控和流媒体监控。

 

用户端监控:主要包括网络质量、内容&DNS劫持、客户端的崩溃和卡顿,以及一些常规的诸如返回码、响应时间、错误率、慢请求、吞吐量等指标项。用于承载这部分功能的组件主要有:第三方的拨测和自研的APM。

 

流媒体监控:主要包括直播、点播等一些诸如推拉流的监控指标(一些做直播的同学会更为了解),以及我们的CDN质量监控体系(大多数运维同学都会有所了解)。CDN监控这部分是我们自研的,实现了CDN评分、CDN线路融合调度等能力。

 

  • 服务端的质量监控体系

 

主要包含三大块内容:业务监控、服务监控、基础资源监控,这是一个自上而下的分层。

 

业务监控:其指标或能力更聚焦在业务的可用性、性能方面。

 

服务监控:更偏向于一些基础服务组件,比如四七层负载均衡、DNS、云PaaS服务等。

 

基础资源监控:更偏向底层的一些环节,硬件、云IaaS、网络、容器底座、系统内核等。用于提供这部分监控能力的组件就相当丰富了,按照这个分层的划分方式,一些组件的能力其实也是跨层的。

 

通过上面的介绍的这些组件,我们其实就可以实现端到端的监控覆盖,从客户端到请求链路,再一直到服务端的各个环节,我们都有了对应的监控覆盖。

 

但是,如此庞杂的工具梳理之后,就会发现它们已经自成体系。比如,每个套件它都会有数据采集、数据处理、数据展示等组件,最后构成了多套独立的监控系统,UI是独立的、相互之间的数据也是不流通的,使用的时候,需要通过分别的入口进去查看,会有诸多不便。

 

图片

 

因此,统一将收纳到Grafana的监控数据源全都归纳进来,解决了上述问题。Grafana目前是我们在做监控数据可视化的一个事实标准,常用的数据源大都是支持的,使用起来非常便利。(当然也还是有些数据的可视化、数据查询能力是不及原生UI的,我们会组合使用,比如Elastic的Kibana。)我们把之前散落的监控数据汇总到了同一个平台做展示,去做统一的权限管控,之前散落、割裂的情况得到了一定的改善。

 

不过这又产生另一问题:监控数据汇总到了Grafana,可以在同一个平台做展示,但是还是有很多监控数据散落在很多个报表页面或者Org里的,查询使用的时候还需要来回切换或者开启多个页面。

 

图片

 

上图是一个典型的请求链路,请求从客户端发起经过中间链路到流量入口,再到服务端,然后可能会请求后端资源,然后再去请求周边的一些内部或第三方的依赖。

 

这个典型请求链路中不同环节的监控数据,大都是存放在不同的数据源里的,最终在建设报表的时候,按照往常的思路,这些监控数据可能就会分布在不同的Dashboard里,比如客户端一个报表、负载均衡一个报表、服务端和后端资源也是类似的情况。这就会造成前面说的为了排查一个问题,需要来回切换监控报表不便的情况。

 

为解决这个问题,我们就需要对监控数据做进一步梳理,按照更贴近业务使用的视角来组织和呈现这些监控数据。

 

这就要求我们去制定一系列的使用规则和约束,然后按照这个规则去做调整。这些规约可能会包括:Grafana里边各种资源的申请和使用;一些数据源和权限的管理规范;一些Org、Dashboard等资源的命名规范。(这是一个偏流程管理类的工作,算是一个有价值的体力活。)

 

图片

 

梳理成果可以参考上图两个样例:

 

右上是Golang的业务监控报表,是按照SLA、服务概览、服务本身、周边依赖、后端资源、Golang代码层的方式来做的分层。

 

右下是偏运维侧一张报表,是按照网络、代理层及服务层的SLA、容器Pod、基础服务、后端资源的方式来做的组织。

 

经过梳理之后,你就可以看到监控报表是更有层次感、也更清晰了。我们从实际使用视角或者不同查看需求出发,来重新组织监控数据的呈现,把监控数据汇总到一张Dashboard里来展示,就免去了来回切换Dashboard或Org的痛苦。

 

回顾上述步骤:一开始我们监控数据散落在多个平台,虽然覆盖面相对较全,但是数据散落、权限混乱;然后我们把监控数据的查看入口归纳到Grafana里边,集中数据、统一权限后,仍有散落的情况,且缺乏层次;最后我们指定规约,按照规范重新梳理,把监控数据集中到一个Dashboard里,最终实现了多张图表在一个页面的分层展示,监控报表使用起来也更加便捷。

 

然而,这当中还有两个欠缺点:全局视角和监控数据关联。

 

图片

 

解决这一问题,比较成熟的方案就是:做分布式链路追踪,用一个TraceID,把整个请求串起来。但是做分布式链路追踪,需要有一定的人力投入,同时有一定的技术门槛,还会涉及到客户端的改造,成本相对较高。(PS:我们公司也有相关同学在做这块的事情,此处按下不表。)

 

本文想讲的是低成本的实现方式,下面是我们的具体实践:

 

图片

 

这是我们从2020年开始,基于Grafana做的一个名叫FlowCharting插件的监控大盘的实战,上图可以看到清晰看到我们这个业务完整的请求链路。具体的操作步骤,之前也有分享过,详细的实践步骤请参考:美图全链路监控实战,成本低还能直接落地

 

从客户端到服务端,流量接入层Ingress,然后再进入到我们的容器平台(内部叫Matrix),周边依赖、后端资源的情况,以及各个模块的状态,都会清晰地呈现在这张图表里面。上图我是挑了一个服务异常时间的截图,绿色的模块是正常的,橙色模块状态不健康,红色的模块出现异常,导致达到了一个异常阈值。

 

通过上图也可以一眼看到整个业务各个链路环节是怎样的状态,可以快速地获得了一个业务的全局视角。

 

低成本本身没有太高的技术门槛,简单来说,就是手绘一个图,然后为图中的组件、连线绑定上动态的监控数据,下面我们分步讲解:

 

  • 图形绘制:绘图工具使用Draw.io(在线的或者本地版都可以),绘图完成之后可以导出来一个XML文件。

  • 图形导入:在Grafana里边引用FlowCharting这个插件,把导出的这个XML导进去。

  • 配置监控数据查询规则:图形导入之后就可以添加数据源了,配置监控的查询规则,然后绑定到各个图形上,每一个方框、每个连线都可以单独绑定。

  • 配置展示规则:定义一些图形的展示规则,比如说它的 SLA,然后它高于两个9的时候是绿的,然后一个9的时候它就是橙色的等等。

 

具体实操讲解的部分,可以移步:美图全链路监控实战,成本低还能直接落地

 

图片

 

这是另外一个监控大盘的样例。

 

图片

 

总结来看,这个方案优缺点都非常明显:

 

  • 优点

容易操作、展示灵活,可以不拘泥于任何展示方式,图形可随着业务状态变换,也不需要要什么特别复杂的技术支持,简单来说就是:画图、导入、绑数据、配置展示。

 

  • 缺点(局限性)

首先使用这个方案的前提是监控数据本身需要具备,只是缺乏有层次、有逻辑的数据呈现方式,即监控数据需要前置;

 

其次这个图里的逻辑关系是静态的,它只是帮你去做一些动态渲染,跟分布式链路跟踪有区别,需要人工维护;

 

然后这个推广的边际成本偏高,如果说公司里的业务线非常复杂,选用这个方案的话,就意味着需要投入人力分别去建设和维护;

 

注意事项:有一个元素的限制,默认的元素编号是从a到z,不能重复,稍微调整下就好。

 

三、基于企业IM机器人的图文告警实践

 

有了前面的监控大盘之后,当业务出现问题时,我们就会有比较全局的视角,比较方便地看到现在SLA波动可能是由哪个环节的异常引起的,此时的过程会是:服务异常→发出告警→业务维护同学收到告警→登录监控系统查看,过程是偏繁琐的,会拖长我们的MTTR(其实是MTTI),最终会影响服务的SLA,该如何优化呢?

 

接下来会详细介绍我们基于企业IM机器人的图文告警实践:具体可用来缩短这个信息传递/信息感知的链路,把告警和前面的监控大盘串联起来,整体实现思路也很朴素,我们期望在发出告警的时候,同时能够携带一张服务当前的监控大盘的截图(快照),告诉我服务整体的概况。

 

图片

 

这个事情需要实现的目标有:

  • 提高告警消息的信息密度;

  • 快速感知服务整体的状态;

  • 最终达到缩短MTTI,降低MTTR,提升服务SLA的目标;

 

我们平时收到的告警内容大概是:XX指标,在几点几分,出现了OO异常。

 

常规的告警就是,如果我们在告警发生的时候,携带一张监控大盘的图出来,信息密度就会高,同时我们也可以快速感知服务的整体状态,判断上下游依赖有没有什么问题,提升告警信息触达的效率和质量。

 

再往后的目标,就要当告警出来的时候,尝试把可用的应急预案、对服务的干预手段推荐出来,这样我们就可以更快地实现服务干预,缩短故障恢复时间。

 

图片

 

上图是我们实现思路的简图。我们中间有个叫MT-Alert的组件,是美图的统一告警平台。在这个告警平台上可以实现告警功能的扩展和定制,比如去调用一些WebHook,当收到告警的时候,我们配置去触发截取监控大盘的钩子,然后组合告警消息为图文样式,发送到企业IM。

 

同样具体实操讲解的部分,也可以参考:美图全链路监控实战,成本低还能直接落地

 

四、基于监控体系的SRE稳定性运营实践

 

接下来详解第四部分:基于监控体系的SRE稳定性运营的建设。

 

图片

 

上图是我们工作的范畴,中间的蓝色部分,就是我们故障管理过程的全部环节,这里我们以故障管理的视角来总览我们SRE的工作内容:从故障预防→故障发现→故障定位→故障恢复→复盘改进,形成一个完整的闭环。

 

中间有非常多的事项,有哪些是可能会跟监控相关的呢?

 

图片

 

上图对监控相关的功能进行了筛选:灾备预案、容量评估、架构设计、监控覆盖、常规巡检、故障定位等内容都会涉及到,即使是故障恢复环节,同样需要用监控系统。

 

到了这个环节,不能忘记我们的SRE的核心价值:效率、支撑还有成本,梳理过后,围绕监控SRE需要做以下事情:

 

图片

 

值得注意的是:这些事项是需要持续输出、定期复盘、量化结果,并需要用数据支撑决策,并不断地迭代改进;并且,这里面有很多工作可能不是说立竿见影的,需要长期坚持、持续推进。

 

图片

 

上图是一个小的实践:就是SLA巡检、网络巡检,在节假日值班非常适用;另外一个是每日的资源统计。

 

图片

 

上图是我们的稳定性运营报告,我们把偏运营类的事情,系统性地整理了起来,这里其实我一直在强调一个词:运营。目前业界早已经有了这个声音:我们现在很多工作内容已经不仅仅是运维了,不仅要保证服务的稳定性,现在更重要的是以运营的视角来审视我们的工作,看哪些事情能提供更高层次的价值,然后系统性地推进这些事情。

 

图片

 

上图是节假日运营报告的样例,这样稳定性运营的方式,可以更好地去持续输出我们SRE团队的价值,建立在公司内部的影响力,让业务方感知到业务服务的稳定运行,让他们知道后方有SRE团队的支撑。

 

图片

 

上图是SRE稳定性运营实践的演进方向:从数据化→自动化→体系化→智能化。(智能化当前也有很多公司和团队在探索,也是我们在做的事情。)

 

下面介绍我们SRE稳定性运营实践当中,搭建的两个平台:稳定性运营平台、应急响应平台

 

 
1、稳定性运营平台

 

前面说的运营报告,其实是有痛点的,最开始我们是在公司内网的知识库平台(Confluence)里的,进行人工维护的,贴图、分析数据都很耗时间的。所以我们要把这个事情自动化起来,覆盖已有的报告场景,自动的去获取监控图表,对监控数据做一些简单的分析,然后自动地定期发出来,让你有方法去对相关的监控数据做解读和批注。

 

图片

 

这里我认为:监控数据它本身其实没有价值,你对监控数据的解读和理解才会产生价值。

 

目前我们的稳定性运营平台已经覆盖了很多运营场景,下图是已经实现的部分功能:

 

图片

 

上图是稳定性运营报告的列表页面。

 

图片

 

上图是定义的一些报告模板,选用了Markdown语法。

 

图片

 

上图是批注页面,我们在一个报告里内置了很多个批注的slot,SRE可以去对各个监控数据的子项做批注,批注完成之后会渲染成一个完整的运营报告。

 

后续,我们可能会去做一些自动的归类、归因、批注,比如搭建一些联动事件平台之类的系统。

 

 
2、应急响应平台

 

前面我们大多内容都是在讲「监」,接下来我们讲「控」。

 

图片

 

监控系统通常情况下,只能帮你解决发现异常,但是无法帮你修复问题。除了对服务异常状态的感知,我们还需要有对服务的干预和控制手段。

 

上图是一个应急响应平台执行的样例。应急响应平台就可以把我们日常对服务干预的一些手段抽象成「动作」,然后「动作」可以被组合、编排成「预案」,最后预案会应对到不同的「场景」上。当服务出现了某些异常的时候,我们就可以快速地通过这个平台去执行相应的预案去做干预,把预案推荐和预案执行入口集成到告警通知里,用来缩短MTTF(故障修复<fix>时间)。

 

  • 成本管控

 

 

图片

 

成本管控是贯穿在服务的整个周期里的,我们需要更早地去介入和干预。在资源申请阶段,即技术成本即将产生的时候,就要开始介入;在服务运营过程中,我们需要把控监控资源的用量和利用率,并持续优化;在成本核算的环节,需要制作成本报表,进行账单分析。

 

图中上半部分是相关流程和活动,下半部分是用来支撑这些活动的平台。比如资源申请环节,需要依赖压测平台提供数据支撑,用来评估资源申请是否合理;中间的资源监控需要监控系统的支持,持续优化的事情需要有自动优化调整资源配额的能力,容器平台会提供相关的支持;最后的成本核算、成本报表、成本分析则需要相关成本数据来支撑,在我们公司成本中心、利润中心会提供相关的功能。

 

整个流程需要形成一个闭环,才能完整地运转起来。

 

这里额外提一个Ops概念,FinOps(Financial Operations),有兴趣的同学可以去做下了解。

 

五、内容回顾&未来展望践

 

上图是本文的一个内容的总结,简言之可以分为三大板块:

 

图片

 

回归到SRE本身,未来我们一定要思考:还应该做哪些事情?还可以做哪些事情?持续输出,拓宽SRE的能力边界。

 

现在各种各样的名词也比较多:云原生、容器、微服务、服务网格、XXOps……各种新兴概念、技术的崛起,大家可能就会觉得焦虑,甚至是慌张。

 

这里我的建议是:首先,面对这些层出不穷的变化,我们不能害怕,要去顺势而为地拥抱它,看清趋势之后,找到我们的方向并为之努力。

 

图片

 

然后,一定要紧扣着我们岗位的核心价值,只要我们能够持续、高效、高质量地去输出我们的岗位价值,即同时兼顾好稳定性保障、效率提升、成本管控,我们就可以做到泰然自若。

 

延伸阅读:

 

>>>>
 

 活动推荐 - Gdevops峰会·广州站

 

2022 Gdevops全球敏捷运维峰会·广州站将于5月13日举办精选运维热门议题,共同探索云原生时代下的运维转型蜕变之路,部分议题抢先剧透:

 

  • 【腾讯游戏】腾讯游戏SRE工具链建设实践

  • 【平安银行】数据库智能化运维实践之故障自愈

  • 【浙江移动】“AN”浪潮下数据库智能运维的实践与思考

  • 【光大银行】光大银行智能运维探索与实践

  • 【网易游戏】网易游戏AIOps探索与实践

  • 【vivo】万级实例规模下的数据库可用性保障实践

  • 【微众银行】亿级金融系统智能运维的深度实践

  • 【去哪儿网】大规模混沌工程自动演练实践

  • 【货拉拉】货拉拉智能监控平台的设计与实践

  • (持续更新……)

    点击此处可下载本文PPT,提取码:voos

最新评论
访客 2022年05月03日

写的很好呀!

访客 2022年04月07日

你好,看完文章,有点地方不太明白,想请教下两个问题…

访客 2022年03月30日

想问一下,如何才能发现数据冲突呢

访客 2022年03月30日

d

访客 2022年03月28日

梁老师,您好,看了您写的exadata image升级方案,请…

活动预告