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

本文根据石鹏老师在〖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)，有兴趣的同学可以去做下了解。

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

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