演讲实录｜吴亚昆：云时代智能运维与可观测性探索

前情提要

8 月 19 - 20 日，GOPS 全球运维大会 2022 · 深圳站正式开幕。观测云首席布道师吴亚昆受邀参加大会，并带来「云时代智能运维与可观测性探索」精彩主题演讲。

演讲目录

传统运维问题显著

云时代的智能运维新思路

可观测性的探索方向

演讲实录

大家好，我是来自观测云的吴亚昆，今天分享主题是「云时代智能运维与可观测性探索」。

传统运维问题显著

首先，我们看一看传统运维存在的问题有哪些？

首先，我们看一看传统运维存在的问题有哪些，回头看 20 多年整个运维阶段的发展，我还没有毕业的时候用的基本上是 IBM 的一套东西，那套东西非常繁重，比如大机、小机。但是在整个业务发展过程中，包括 X86、虚拟化、云计算甚至到现在微服务整个过程，它其实有非常明确的演进方向。最开始架构非常简单，就是从前端 Web 端到中间处理端，最后到后端数据库的三层，它整个层次架构非常清晰。

原来我们怎么去处理这个问题呢？原来很简单，就是运维「三板斧」，「重启、重装、换电脑」，先是重启，重启不行就重装，重装不行就换一台设备，换一台设备之后绝大部分问题就解决了。

但是到虚拟化和云计算时代，我们会发现这样的处理方式其实已经没有那么容易去解决这些问题了，重启虚机并不一定能够恢复业务，尤其是到现在微服务化比较普及了，服务的调用链非常长，很难快速定位到问题根因。

回过头来看一下当年怎么做，我自己就是从最早从蹲机房的运维开始做起，我们原来做主机监控很简单，机房里面会有一个小推车，大家应该很熟悉，它背后其实是有一个显示器、键盘、鼠标，直接接到服务器背后，就可以查看这台服务器的状态了。

后来量多了，大家比较懒，我们就坐在机房旁边的操作室，用 SSH 方式远程登录，再往上是网络监控，交换机数量不是特别多的情况，我们通过 Console 线管理设备、用 Telnet 远程登录，因为我们信息化发展在往上走，当我们整体设备数量开始变多之后，我们需要有一些监控系统，比如说我们会用 Cacti，它可以监控所有的网络设备，这个年代到这一层基本定型了，设备有问题换设备就好了，真正的业务跑的状态怎么样其实没有太多人知道。

所以随着信息化继续发展，大家也都开始逐渐关注一些更细颗粒度的东西，比如说我们开始用虚拟化平台，我们会想看平台本身的问题；我们也会有公有云、私有云平台，可以在平台上做一些基础监控，看整体 CPU 利用率、磁盘剩余空间、账单明细等等。但对于我们单台起的设备它的指标我们依然是用传统方式去做监控，比如说 Zabbix，以及商业化做的还不错的 Solarwinds 等等，这一层我们也只是看到它本身的静态或者固定的指标，它的模板其实非常少。

再往上我们开始做一些用户体验相关的东西，会去做指标上的自定义，比如说用户行为、业务埋点等等，但是这些数据也没办法展示系统本身的异常情况。

上述的各部分的监控都没有办法单独解决系统问题，造成这样情况的原因在于，每一套监控系统数据都是独立存储，彼此之间是完全割裂的。

为什么造成这样的原因，这个和康威定律有关。造成这样的结果是因为整个组织架构设定就是这样的，很多传统公司现在组织架构把平台运维、网络运维、系统运维、应用运维等等都拆成了不同岗位，彼此之间职责边界明确，因此各个系统之间的职责边界也很明确，导致相互之间没有办法做关联。

云时代的智能运维新思路

到了云原生时代，我们整个系统产生的数据是海量的，在海量数据情况下我们面临一个明显且巨大的挑战，怎么基于非常复杂的调用关系、非常复杂的访问关系做到每一层监控，并把每一层监控做好之后做到快速定位到问题？

可以聊一聊在这个时代下我们新的思路，在讲新的思路之前，我们先来一个灵魂拷问，监控那么多数据的目的是什么？

CPU、内存、静态指标等数据的监控，这些是数据量极其庞大，但是密度非常低的数据，比如说昨天的 CPU 对于我们已经没有任何意义了，但是它的量是实时不断产生的，所以它是低密度的数据。

其实我们监控目的只有一个，就是为了保障业务稳定性。通过快速定位业务故障，快速恢复业务状态，实现整个业务的质量目标，这是运维监控这件事情唯一的目的，如果大家了解我们企业架构，就能理解技术永远是支撑业务的，技术很难独立业务存在，除非自己技术本身就是业务。

回到这个话题，我们监控这么多数据，就是为了手里面有东西可以去做分析，可以快速定位故障。但是如何实现？

这里有一些前提条件。当我们要去做分析这些海量数据的时候，需要统一的存放、关联和分析，在这里，1+1 的价值是远远大于 2 的。如果统一的存放、关联和分析的能力缺失的话，比如按照传统方式，不同系统独立存储这些数据，它发挥不了太大价值。

各位运维的同学可以回想一下自己的经历，大半夜接到一个电话说业务挂了，网络运维上线拨 VPN 到系统里面去看半天，说网络正常，也没有丢包，带宽也 OK，系统运维可能登上来看一下，整体利用率正常，也没有什么异常日志，最后大家都把自己的系统查了一遍，都会说我这边没问题，但是业务还没有恢复，问题依然存在。

我们有很多监控系统，这些监控系统展示给客户和运维同学看的时候，都是非常直观的图形，可以看到整个访问情况都是绿的，状态都挺好的。

当某一个时候出现了问题，用户打开页面非常慢，或者报错，作为管理员来说，我需要再联系这些系统对应的责任人。

每一个责任人登到系统之后，他们需要去做故障排查，在传统协作方面会浪费很多时间，大家会不停去找故障。单个节点的故障率其实不是特别高，但是所有系统组合到一起之后，你会发现整体系统的故障率就变得非常非常高了。

因此，可能原来数据库的一年挂两次，这频率已经很高了，但是当整体系统故障率变得非常高的时候，整个系统所有数据库加一起一年可能挂 20 次，其实大家的工作量就提升了 10 倍，这个效率就变成非常低了。

我们认为在这件事情下，有一个比较好的设想，当出现了一个问题之后，所有数据做了关联，我就知道这个问题所经过的链路到底是哪一个，当我发现用户那边访问有问题的时候，就知道故障根因在哪里，可以快速定位到故障点甚至快速定位到故障原因以及关联责任人，可能一年处理 20 次故障的 DBA，可以快速定位到是应用写的有 bug，跟数据库和网络都没有关系，应用自己修复就好了。

绿色的点就是我们认为在整条链路上通过海量数据展示出来，这些节点正常的现象，这些正常现象的人就不需要去关注自己的问题了。

还有一个比较好的方面，当我们把这套模式做下来之后，不同部门、不同团队对于自己的 SLO，对于整个部门会有明确 KPI 界限划分，比如说你的系统出问题了，每次说系统问题最后甩锅到网络运维，网络运维说我整个网络一直都是好的，一直都没什么问题，结果到年底在老板面前发现，你的网络好像每天都在出问题，但是当我们把整个模式跑通之后，网络那边一直都可能会是正常状态，因此「出镜率」不是特别高。

从中，我们可以看到，按照不同层次去做划分，从基础设施到网络，到应用，再到用户体验相关的东西，不同层次数据监控起来之后我们需要做到对应的关联，做到统一存放，并且在一个地方去做分析。

再来思考一个问题，怎么才能实现统一存放、全面关联、数据分析？

我们可以按数据层次进行划分，并按颗粒度更细的角度去做展示，监控数据是非常多维的，也就是说我们可能从数据中心的动环开始，一直到最上面的应用和云里面的接口数据，所有数据在收上来之后，其实我们应该是对这些数据打上标记，因为打标的时候我们可以非常明确知道，一个用户的访问行为，或者叫用户旅程，到底经过了哪些系统组件。

我们中间开源了采集端，我们叫 DataKit 采集端，这个开源产品大家可以了解一下，我们整个做的还不错，把我们所有数据打到 DataKit 之后，我们会做一个数据映射和格式化，做好映射和格式化之后就推到我们后端平台，因为是开源的，我们也没有强绑死说一定要推到观测云，其实我们也可以推到第三方平台。

通过数据「前」治理的方式，我们可以把所有数据关联的压力从后端释放出来，通过分布式方式直接把压力分散到所有采集节点上，所有数据都采集完成并在我们平台存储之后，我们看到做了几个挺有意思的场景。

这个场景叫做智能推断，一是做了内存泄露推断，基于整个应用关于内存的使用率，并且我们做了未来时间的预测；二是磁盘利用率推断，我们可以看到它接下来利用率可能会是多少，什么时候会有异常；三是应用异常推断，我们可以融合 APM 数据、用户数据、其他各个维度数据做应用本身异常的定位；四是故障根因定位相关的推断，这张图和我刚才描述的抽象那张图很像，可以非常快速看到，问题出现的时候可以快速找到异常点在哪里。

可观测性的探索方向

可观测性，其实所有数据监控、数据采集、数据智能推断本质都是可观测性的一个维度，有一个很有趣的说法，叫做「一切皆可观测」，当然后面是我们的探索方向，有些我们已经落地了，有些我们在探索。

首先看一下整个技术的趋势，这是 Gartner 今年发布的一个技术趋势报告，红框标出来的地方就是可观测性，处在热度非常高的位置，所以现在基本上大家都在聊这个话题。

Gartner 的另外一个报告里面给出了稍微抽象一些的图，它把我们运维数据治理阶段分成了 4 个部分，从最左边的数据采集到中间的数据聚合，再到分析，到行动，分成这么几个步骤。

这张图上方的曲线非常清晰地展示了监控、AIOps、可观测性之间的关系，监控更多强调数据采集，比如说要采集 CPU、内存等等，AIOps 可能更多强调在数据聚合，把所有数据进行清洗聚合，但是对于可观测性来说包含两部分，但不仅仅局限于这两部分，因为还涵盖了分析和行动。

对于整个可观测性来说，刚才聊到我们观测云第一个产品是 DataKit，它已经开源了，可以兼容非常多中间件。第二个是我们画在左边的采集平台，它是我们的编程开放平台 Dataflux Func，有点像是 python 沙箱，也开源了。

这个平台特别有意思，很多探索的东西是在这里面去做的，比如说我们通过开放编程平台，我们在里面去做了很多模板，它可以一键对接很多云资源账单，阿里云、腾讯云等等我们可以直接把账单数据拉过来。它也可以对接很多传感器，比如电表，我们北京一个同事，他把家里所有电表数据都拉出来，然后在仪表板上可以看到昨天用了多少电、对应电费是多少。第三个是我们在探索的东西，比如说对接特斯拉、新能源汽车，只要有开放接口就可以了。最后可以对接已经落地的流程时效数据，提交代码周期以及每一位研发同学代码提交的频次等等。

我们把所有可观测领域，从 DevOps 运维视角往 Dev 方面扩展了一下，因此我们觉得这是不错的探索方向，我们非常希望在座有一些好的想法的同学可以和我们一起去做开放场景，因为我们开放编程平台资源利用率很低，树莓派也可以运行。我们脚本市场里面也放了很多现成的脚本，大家有兴趣可以去动手玩一下。

这是我们做的仪表板，这是根据 SRE 方法论做的落地，我们把所有监控指标包装成 SLO，我们认为我们关注的某一些指标就应该是某一个服务模块，再包了一个总的 SLO，有可能我们对某一个 SLO 做了指标值设定，比如说 99.9%、99.99% 等等，我们在这里面会发现，当它有问题之后会自动去扣预算，然后展示出来，这样也会对我们运维团队做 KPI 考核非常直观。

我们可以通过左边的 SLO 大的宏观模板，直接下钻到用户体验这个部分，继续下钻到可能产生的错误分析，一层一层下钻的能力，其实我们做的非常成熟了，实现这个能力的基础是我们刚才所说的统一数据的关联、统一数据的存储、统一数据的分析。

我们来看看整个运维故障定位的流程，当故障发生之后可以往下钻，可以看到我们的错误是什么，错误点开来之后可以看到访问请求，我们点到其中一条访问请求，就可以继续往下钻，可以跳转到它的调用链。所有东西都是在一个平台里面完成的，不需要像传统运维平台，发现一个问题之后要同时打开 3-4 套工具，不同工具交叉做对比，不仅仅是效率比较低，而且有可能有些数据丢掉了你看不到。

我们刚才聊到在探索的方向，左上角是北京同事他把他家里电表数据展现上来的仪表板，右边是我们做的线上大学可视化，左下角是运动手环运动数据，我们也可以接进去展示，只要它开放了接口。右下角这个场景是我们最近在探索的挺有意思的项目，我们我们把桥梁上面的传感器全部数据接到整个观测云平台，用开放平台 DataFlux Func 做的数据对接。

这是我们做的云平台成本优化，我们可以直接通过脚本市场对接云账单，我们可以看到云账单里面收费每一条项目是哪一个资源收了什么项目，打上标签之后我们是可以看得到这个资源过往一段时间内它的利用率是什么，我们可以知道这个资源可能闲置非常高，但是利用率非常高，我们可以做成本优化。

简单介绍我们公司，我们是国内首批可观测性平台被信通院评为先进级的公司，其实该有的资质基本上也都有。

我们也是最近入选了 CNCF Landscape，在可观测性领域里，大家可以看到这边有一个截图，其实入选的基本上都是还不错的厂商。

最后是我们的客户展示，我们现在整个产品形态，我们建议大家往 SaaS 方向走，这样会比较灵活。

我们公司认为有一个观点，我们 2018 年、2019 年就开始聊可观测性，那时候大家来智能运维，聊 AIOps，没有聊太多可观测，我们开始把公司的域名叫做 guance.com，注册好之后，发现国内各大厂商也都开始聊可观测，所以我们认为中国的可观测性我们应该算是第一家提出这个理念的，因此，中国可观测性始于观测云！

为帮助广大技术爱好者更好地了解全球技术趋势、可观测性最佳实践、观测云产品功能等前沿干货，我们特别成立了观测云官方社区交流群，为大家提供一个交流互动的平台。还没有入群的小伙伴，可以扫码加微信入群，一起参与到我们的技术社群来！