也来聊聊可观测性

也来聊聊可观测性

成哥的文章对于做运维的人来说是十分值得认真阅读的，最近成哥连续发了两篇关于可观测性（Observabilty）的文章，初读起来，感觉有点刺耳，特别是4月8号那篇《为什么说可观测性Observability对运维没用？》，因为我们这些年做的事情就是和Observabilty有关的，希望打破数据库、中间件等IT运维对象中的黑盒，让运维人员能够通过我们构建的健康模型了解这些运维对象的实际情况。因此初看这种标题，我都有弄块砖拍上去的冲动。不过仔细阅读下来，觉得文章写得还是相当不错的。

实际上成哥在这篇文章中的大多数观点，我基本上是认同的，可观测性是十分复杂的，要想做好不容易，要想在一线生产中的故障处理中发挥直接作用更难。不过对于运维中的可观测性只能在一些日常的小问题上发挥作用，而在系统出现严重故障的时候用处不大的观点似乎还是有些绝对了。如果这句话放到互联网企业里，还是基本上正确的。因为互联网企业的系统高可用，多地多活系统中已经考虑了这方面的问题，同时他们也有资金构建1:1的双活/多活环境，具备了快速自动切换以及业务自动修复的能力，因此当系统出现严重问题的时候，通过切换来快速解决问题永远是第一选择。

套用一张成哥引用过的逻辑图，可观测性分为三个阶段，故障发现、故障处理和根因分析。发现是通过对Metrics通过领域知识，基于SRE方法和设定的服务级别目标，借助于关键指标异常检测和AI能力来进行故障发现。

第二步是故障处置，通过各种trace和CMDB来构建全链路拓扑的跟踪能力，基于核心链路，领域知识，利用AI算法和专家算法，进行问题分析，尝试解决问题。

第三步是根因分析，通过日志，事件等作为输入，通过日志异常检测能力和AI能力来做根因定位。

这基本上就是目前做AIOPS的企业的套路，互联网企业也基本上是基于这样的机制做问题发现和故障处置。互联网企业的信息系统基本上是一种白盒或者半白盒的系统，运维部门对整个系统的业务逻辑，数据逻辑，甚至IT组件的基本运作都已经了然于胸了。因此这种方式的有效性还是很高的。

如果把场景切换到传统行业，那情况就完全不同了，大多数传统行业企业没有构建起完整的系统故障的替代策略，更不要说真正的多活双活系统，很可能也不具备自动化快速切换备用系统的能力，以及切换后脏数据自动处置的能力。

因此对于一个传统行业企业来说，切换备用系统，从而解决当前面临的系统问题，并不是和互联网企业一样十分容易的事情。记得前些年和运营商的朋友讨论最小备用系统的问题，他们在数年前就构建了最小备用系统，不过多年过去了还没有启用过一次，当系统出现问题的时候，他们还是习惯于首先在生产环境解决问题，而不是第一时间考虑启用最小备用系统。“启用最小备用系统肯定是会产生一定的业务收入损失的，真的出问题的时候，没人敢拍板启用，因此这个系统虽然花了不少钱，不过也只能作为一个运维底线存在了”。

仔细阅读一下成哥的这篇文章，我们可以得到一个结论，因为故障发生时，我们最需要是快速恢复，而不是根因定位，因为根因定位没有那么快，因此不是刚需。确实，根因定位在很多时候不是刚需，尽快切换，尽快恢复系统的正常运行才是刚需。不过如何才能恢复系统的正常运行呢？切换到备用系统？没有全尺寸备胎的系统想要切换并不是那么容易的事情；无法做到零数据丢失的系统想要切换备胎更是难上加难，因为每次切换都意味着业务部门要补录数据，要对数据进行全面复核，并不是所有的切换备系统都那么容易。

说到这里可能有朋友会咧开嘴大笑了，还有重启大法啊。诚然，重启可以解决一部分的问题，不过不是全部。传统行业企业的数据库系统往往采用物理复制、存储复制的方式建立备系统，如果你的某张表的统计信息出现问题导致执行计划错误、因为某个热块产生的性能问题或者某个热CURSOR导致的CURSOR争用问题，这些问题通过重启是解决不了的。2005年我给一个运营商做优化的时候就遇到过类似的问题，优化项目组做表分析的时候忘记带percent参数，导致采样结果不准确，大量SQL用错了索引，业务系统几乎无法使用了，经过重启，故障依然存在，没法解决问题。这个故事我收录在了《ORACLE DBA优化日记》这本书里了。

盲目的重启还会带来更严重的后果。十多年前某外资银行出现性能问题，运维部门在没有弄清楚怎么回事的时候武断的怀疑RAC性能有问题了，于是分别重启了RAC的两个节点，导致应用服务器HANG死，把一个因为宕掉一台应用服务器引发的一个小问题演变成一个业务全中断2个半小时的大型事故。

通过切换备用系统、重启系统等快速恢复业务，并不是在任何场景下都能够实现的，但是想要通过可观测性在这种场景下快速解决问题，也并不容易。这也是成哥在文章里所表示出的观点，无论如何快速恢复业务运行依然是最大的刚需。快速的根因溯源能力建设十分困难并不是说可观测性在这种场景下无法发挥作用，而是目前的可观测性技术水平还比较低下，无法满足快速恢复业务的需要。

既然有需求，那么我们这些搞运维的人就应该在这个方向上去做些努力。如果说某类隐患发生前几分钟就能够预警，而且几分钟内就可以大体定位问题根因的方向，并提供事后追溯分析的能力。这种可观测性能力对于系统故障这种场景依然是有用的。

当然构建这种能力所需要的是对应用系统、系统架构、IT组件的深层次的感知能力，这种能力的建设需要资深的专家介入，而且需要一定的时间去积累。前阵子一个金融机构出现问题，利用我们的工具提供的诊断算法辅助，在几分钟内就定位了问题，并采取了正确的方法进行处置，在没有重启系统的情况下，快速排除了一个严重的问题。

在另外一方面，很多人对Observabilty还有很深的误解，这两年不止一个做智能化运维的人和我谈起普罗米修斯加上GRAFANA就是构建运维可观测性的利器。还有人说知识图谱可以构建运维知识的可观测性。实际上我觉得还是没有深刻的理解在运维领域，可观测性是什么，可观测性并不是可以通过GUI界面提供的视觉辅助能力，而是通过自动化的分析可以让我们了解IT系统内部的运行状态的能力。

实际上成哥3月份有一篇关于运维可观测性的文章对这个问题说的挺清楚的，不过这个可观测性是针对系统而言的。构建系统的全链路监控体系，让系统的整体情况能够被全面地让运维人员感知是每个运维团队都希望具有的能力。要想构建这种能力其实并不容易，不是说搭建一套监控采集系统，再用GRAFANA画一些仪表盘就能完成的。这需要十分强大的能力，能够对IT系统、IT基础设施、业务流程等的都进行深度建模才能够实现。

目前已经有很多工具和平台能够建设这种全链路监控的能力，不过如果要实现根因定位，那就需要更为强大的专业技术能力。比如我们要分析Oracle数据库可能存在什么问题，就需要了解Oracle的数百个METRIC，2000多个等待事件，还要了解数据库所在的服务器，操作系统，使用的存储系统，SAN网络的整体情况，才能真正做到在大多数运维故障发生时，进行故障溯源。

套用成哥的一张图，需要强大的领域知识，SRE的方法论，以及AI能力才能够构建起这种能力。这些年，传统行业的运维一直在从互联网行业吸取营养。不过业务特点、IT投入的巨大差异让很多在互联网行业运转得很不错的东西到了传统行业就水土不服了。实际上我们的应用系统还没有真正的解耦，真正的弱化对IT基础设施的依赖；我们的IT基础设施还没有实现真正的冗余、高可用、同城双活、异地多活；我们还没有钱去配置全尺寸备胎，但是我们的管理目标已经在向已经具备这些投资的互联网企业看齐了。

我们可能需要静下心来，首先构建起组成IT系统的各个IT基础组件的可观测性模型，然后才谈得上全链路的可观测性。否则我们哪怕构建了整个信息系统的可观测性模型，也没有办法在发现某个IT组件存在问题的时候去做快速的根因分析。