徐老师分析了在“日志、指标、跟踪”的运维原始数据基础之上，应该如何建立“风险、告警、异常、故障”的健康管理服务体系，以及如何实现大数据平台及业务的健康度衡量。

# 阿里可观测典型业务场景案例

针对阿里可观测的典型业务场景案例做了非常细致的解析，介绍了阿里云对可观测方法论的具体工程实践，以及他们是如何通过一套健康管理体系，来达成可观测的目标。

# 在线问答

阿里云的可观测工程实践里用了哪些开源工具？

阿里会有一些专门的基础设施底层团队，他们会去做监控和日志。而指标这块，云监控有Arms，我们内部也会用。有一套是基于ES和Opentelemetry协议去搞的，它背后的监控是利用Flink大数据，像这种会有一些选型，我们在做选型的时候，前提都是说规模。当规模不一样的时候，所选型的内容肯定是不一样的。

大家可以看到普米斯最经典的理念就是把事情切分，我们以前做传统运维时，对运维监控系统的指标处理能力的要求是很高的。针对大数据指标的处理时，它的商业化产品背后就是用流式的处理系统去做指标的预知的判断、监测和降精度。相当于不同的业务规模会需要采用不同的工具。说白了，开源工具只能解决一些功能性的问题，它基本上不能直接拿来被生产使用。

如何全面、快速、准确地掌握各系统关键业务数据指标？

需要提一个最关键的词：黄金指标。它是一个顶层指标，在这个顶层的指标之下，有很多底层的子系统、子模块指标。一般当一个生产系统出现问题之后，基本上都需要体现在环境指标上，只不过环境指标体现完之后，再进一步去根因分析时，才能定位到问题。今天可能是环节指标挂掉了，业务受损了，但是可能今天是A模块，明天却是B模块，再往下就是诊断系统需要一层一层去做的。

完成业务指标统一监控，有哪些好的经验可以借鉴？

阿里云的系统基本上都是分层的，特别是对于大数据团队来说。需要你对运维去做一个业务的建模。阿里的大数据有自研的，也有开源的，有C++写的，也有HB+的等等，但是不管生产系统如何变化，其实都是可以划出层次的。

所以阿里针对大数据的整套的体系化的监控，我们会分系统层，平台组件层，业务对象层。平台总映层就是我们大数据的平台服务，所以好的经验，就是分层建设，再分配到有经验的同学处理。

能否以某一款大数据产品为示例，介绍它的可观测数据具体包含哪一些，是如何设计的？

举个例子：Flink

这是个流计算平台，它是流式的作业。流式的作业经常会出现有了问题便自动切换到另一个机器上跑的情况。它可能或多或少会产生中断，或者数据延迟。所以我们会在全局上进行监控。我们所有的线上作业，会进到对应的Flink平台日志里面，每天把日志和分析任务做统一的收集，当我们的平台系统做进来之后，每当是一个新版本发布，在它的后台会产生的一些稳定性的情况，这个时候就发挥作用了，怎么样帮开发找到这些稳定性的情况，抓出一些日志的部分模式，给他做一些模式识别，然后再找开发去定位、解决，如果发现了Bug，再去优化改进。这个就是一个比较常见的点，如何驱动一个运维和开发，去达成目的。

SRE画像是如何自动化构建的？

两会是对自1959年以来历年召开的中华其实它就是标签系统，把这些东西都打上标签就ok了，跟抖音和小红书很像。

我们之前做了一套运维画像，包含机器画像，告警画像。拿机器的画像举例，因为我们是分布式的系统，可能会有一些烂机器，或者过保下线的机器。对于这么多集群，如果按照传统的手段，一点点找出来是比较难的，我们把所有机器的属性字段和业务的信息都放到一个宽表里面，把这个宽表看成是一个标签系统，就可以比较快速地做画像。

一个故障对应很多告警，那如何快速识别出业务，影响呢？

我们对于故障的定义基本上就是从“异常”出发。当异常发生的时候，告警系统基本上就已经泛滥了，所以这就是一个反向的过程。那么出现异常之后怎么反过来看？就是我去定位哪一个点，去做一些告警压缩，告警关联相关的能力？我们在数据这一块遇到的问题是常规的模式，通过固定的图判断，但可能解决不了真正的问题。

我们尝试了一些训练, 我们有大量的历史故障和数据，这些故障产生时，会有当时关联告警的数据，我们把那些故障和告警让AI运维的同学做了模式的训练，找出来一些特征，虽然大部分异常产生的告警都相同，但依然有些特殊异常，所以我们通过数据反向训练成一套模式。对于大量的数据，不可能真的等线上系统已经发生了，再数据来做。所以我们搞了一个故障演练，把一个模块当掉，以此去演练系统的行为，观察背后的模式和特征。通过对不同模块故障演练，反向生成了许多故障跟告警相关的数据，再拿这些数据去训练，最后得到比较准确的排查故障的思路。

要想实现智能化运维的目标，就得有一套工程的实践，比如故障演练，得产生大量对应的数据去解决它。如果你们团队能走到这一步，在工程的实践上，配套故障演练背后的风险、告警、故障、异常要有大量对应关联的数据可以获取到。

大数据集群的健康状态指标如何评估的，遇到整个大数据集群故障的情况下，如何保障集群作业/任务快速恢复，缩短MTTR？

一开始，当我们把风险告警异常故障这些模型提供平台服务的能力做出来之后，各个产品也会起来，基于这样的平台能力，再去建设它对应的健康度体系。

这是一个渐进的过程，今天B产品跑得快，把风险、告警、异常都用起来了，对应的算法的公式可能就全一点，但是权重可能是默认的，那就需要调整。

明天B模块不一样了，我没有那么多精力和人力，这时候可能只用了风险，那整个健康管理体系可能就只有盖得住风险模块，所以运维自身要按需去建设整个体系，至于这套体系建设完之后，想要获得对应一致的点，还是得靠自己，得要了解对应的业务，怎么去建风险、异常、告警，最后才能跟日常的事项挂钩。把这套体系建起来之后，你的工程实践就能自动跑，再通过一些故障演练，把常见的场景都覆盖了，这样就是一个正向的循环，最后你的运维系统其实是随着这个正向的循环，不断地打磨每个环节，持续达到理想的目标。

针对监控对象有什么建模的方法论吗？

推荐两本书：《SRE Google运维解密》和《Google SRE工作手册》

我只能说这是一个比较比较长时间的一个过程，需要团队脑暴，针对黄金指标，站在用户的角度，体感的角度，把最顶层的环境指标找到，再往下走。《Google SRE工作手册》里提到把整个Google的线上生产服务，统一抽了几个0和1的可用性，无论什么服务、大数据平台或者微服务的应用，都能从固化的几个维度去定义它，这是常用的方法论。

UGeek大咖说大厂可观测系列往期回顾：UGeek大咖说第五期【移动专场】