随着这些年去IOE以及正在轰轰烈烈进行着的国产化替代，以数据库为核心构建应用系统的这种架构逐渐变成了传统架构。再加上目前的国产数据库还无法承担应用核心的角色，所以核心前移是必然的。最近和一些传统行业客户交流智能运维的事情，大家都觉得虽然目前遇到的系统问题大多数还是数据库引发的，而且数据库引发的系统故障也是最难定位，最难解决的，但是他们都觉得系统运维的核心已经逐渐转向应用了。再加上目前对系统的SLA要求越来越高，他们目前也必须开始考虑从更前端去发现系统存在的隐患。因为数据库存在的大多数隐患不会直接引发系统故障，而应用系统存在的隐患，大概率是会引发大故障的。

不过想要做应用的隐患排查和早期问题发现并不容易，因为应用千奇百怪，形态各异，不像数据库这种通用型IT基础设施这样有规律性。另外一方面，应用的可观测问题也是一个难点。绝大多数应用系统并不采集和发布可观测性的指标数据，目前应用客观性的采集接口往往只有应用日志，甚至很多应用并不输出自己的日志，只能从应用服务器上去采集日志来进行分析。

近些年也有一些APM/NPM厂商提供了一些应用的采集接口，通过埋入探针、ebpf采集、网络抓包分析等方式采集应用的相关信息，构建出一些应用的指标数据，与日志一起来构建更强的应用可观测性体系。这些方法被证明是有一定的效果的，不过这些数据与应用之间建模的难度较大，工作量更是巨大，因此，大多数建设应用可观测性的企业在做了一段时间之后都遇到了各种各样的瓶颈。

AI技术兴起之后，出现了一些利用算法来解决这个问题的企业。当时很多用户对此也是十分期待的。希望利用各种AI检测算法来自动发现规律，定位问题，从而解决应用可观察性平台抓取的数据与应用、业务之间建模的难题。几年下来，发现效果依然不佳。前些年这个领域声音比较响的几家企业，好像现在都不太听得见声音了。

其实应用的可观测性与数据库的可观测性尤其共同点的，想要把指标与应用的实际情况挂钩的最 佳方式还是来自于对于应用本身的理解。某个模块的平均响应时间以及时间是否合理，这些数据的发布最好是由应用自己发布。就像我们以前在分析Oracle数据库的性能的时候，某些指标都是通过系统统计数据对减，再除以采集周期，获得平均值，而Oracle的Metric接口发布后，Oracle发布的指标比我们自己计算出来的准确了不止一个数量级，而且Oracle还能提供直方图数据，从而可以更加清晰地了解数据库内部发生了什么。

不过想要让应用像数据库一样发布一些关键指标也非易事，需要企业在应用开发之初就做一些设计，在开发平台底层提供指标数据采集、发布的接口。几年前我曾经给一个企业提出过这个设想，最终因为实施难度较大而未被采纳。对于研发采用的基础框架相对稳定的企业，其实平台底层的APM埋点都是存在或者很容易实现的，只是推广某个标准的成本较高，而且是企业级的，因此实施起来有些困难。如果无法在开发阶段完成数据采集和发布，那么在运行阶段就只能采用APM/NPM等工具了。

采集目前并不是做不到，处理数据成为下一个瓶颈。传统的方式想要做出一个分析应用可观测性数据库的系统是个十分巨大的工程，一般都依赖于APM/NPM开发商或者第三方开发商。规划一个项目，等开发完成之后，应用都不知道变成啥样了，所以这些项目往往事倍功半。这也是企业级的可观测性项目叫好不叫座的主要原因。大家都需要，但是很难做好。

随着AIOPS技术的发展，以数据推理为核心的系统为可观测性项目打开了一个新的通道。不是通过固化的程序和算法去分析数据，而是用数据推理的方式去分析问题。这会让应用可观测性系统的建设周期大大缩短，问题分析的能力大幅提升。这几天我一直在拜访客户的路上，也一直在思考这些问题。随着系统运维核心的迁移，DBAIOPS也将会更加亲近应用，我们想在这个领域做一些探索，也希望和有此想法的用户或者可观测性平台的厂商一起共同做些探索。