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

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

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

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

下图是本文的整体脉络：

现在各种岗位概念层出不穷、千变万化，很多同学因此会感到焦虑。但无论如何变化，只要回归到岗位核心价值我们就能找到方向。在美图，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)，周边依赖、后端资源的情况，以及各个模块的状态，都会清晰地呈现在这张图表里面。上图我是挑了一个服务异常时间的截图，绿色的模块是正常的，橙色模块状态不健康，红色的模块出现异常，导致达到了一个异常阈值。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

延伸阅读：

• 美图全链路监控实战，成本低还能直接落地

• 史上最长最全！围绕故障管理谈SRE体系建设