从黑屏到AIOps：论知识与数据在智能运维中的连接演进

在传统的运维模式里，整个流程几乎完全依赖于领域专家。专家们就像一位经验丰富的侦探，他们的核心工作，正是利用自己头脑中的知识和过往经验，去主动“连接”散落各处的数据，最终拼凑出故障的真相，达成修复目标。

从“黑屏时代”谈起：依赖专家的经验驱动

让我们把时钟拨回到早期的“黑屏运维”时代。想象这样一个典型场景：当用户反馈系统出现问题时，DBA（数据库管理员）的第一反应是什么？

首先，他们会详细了解故障发生的具体场景。然后，就像在脑海中打开一个庞大的案例库，他们会开始搜索：这个问题我或我的团队以前遇到过吗？解决思路是什么？如果自己的经验库里没有直接答案，他们就会转向外部的知识库，比如Oracle的MOS（My Oracle Support）或公司内部的应急预案库，试图查找类似的案例记录。

获得这些初步的“知识”线索后，下一步就是行动：去查找定位问题所需的各种数据。这可能包括检查特定的日志文件、查询实时的性能指标、分析SQL执行计划等等。整个过程就像一个不断试错和排除的侦探游戏：不断排除已被证明无效的诊断路径，确认某些可能的路径，并随时准备根据新发现的数据，开辟全新的调查方向。

在这个过程中，DBA们也会尝试一些临时的解决方案。有时运气不错，某个尝试恰好解决了问题，那么大家皆大欢喜。但此时，问题的根因可能还没有被真正、完整地定位出来。在事后撰写故障报告时，DBA们往往需要根据已知的“推测根因”去反向补充数据，试图完善整个推理过程中的“证据链”。

不得不承认，在黑屏运维的场景中，很多时候是“问题解决了，但根因未明”。推理过程中的证据链条可能残缺不全，一些关键数据由于时过境迁已经无法采集，只能通过旁证来补充，甚至报告中的结论部分，最终也只能以“推测”来完成。

“白屏运维”的理想与现实：数据采集的局限

“白屏运维”（通常指带图形化界面的运维监控平台）的诞生，其最初愿景绝不仅仅是简化黑屏运维中繁琐的数据采集命令。大家更宏大的目标是：希望能够预测故障，并且能够自动化完成问题分析。

然而，现实与理想存在差距。目前绝大多数白屏运维工具所采集的数据，其广度和深度还远远无法支撑大多数复杂场景下的自动化根因定位。我们见到过的几乎所有运维工具演示的“智能预警”场景，往往都是一些相对简单的阈值告警，比如存储空间即将用尽、发现明显的锁阻塞链等。

一个普遍的现象是：几乎所有使用白屏运维工具的团队，当面对真正的系统级故障时，依然很难仅依靠运维平台本身来定位和解决问题。核心原因就在于——数据不充分。

运维人员面对告警，流程又回到了熟悉的模式：打开仪表盘，依靠自己脑子里的经验和知识来分析那些曲线和图表，然后不断发出指令，补充查询更多维度的数据。接着，将这些数据与自己的经验库、已知案例库进行比对。如果幸运地“命中”了过往案例，可能很快就能找到答案。

但如果没有现成案例可循呢？那就只能回归原点：根据自己所掌握的数据库或系统底层原理，做出根因假设，然后不断地尝试用新数据去验证或推翻自己的推理，如此循环，直到找到答案。

复杂系统的挑战：为何经验有时也会失灵？

对于像数据库这样的复杂系统，一个表面的故障现象，背后往往对应着多种可能的根因。这时，如果经验不足的DBA仅仅依赖有限的、表面的案例库去匹配，错误率会非常高。

举个例子，某些ORA-600内部错误。许多DBA可能只知道根据错误信息的第一个参数去MOS上搜索解决方案。而资深一些的DBA，会知道第二、第三个参数的不同组合可能代表着完全不同的故障场景。但真正的专家会指出：调用栈（Stack）中关键位置的函数信息，才是定位此类问题根因的核心，并且他们大脑里就存储着一些常见场景下栈特征的“知识图谱”。

显然，传统的、以仪表盘和固定告警规则为核心的白屏运维工具，难以解决如此复杂的、需要深度推理的故障场景。因此，对于专家而言，这些工具在复杂故障定位中，往往只能充当一个“不完善的历史指标查询库”的角色。

迈向智能运维：AI成为连接知识与数据的新桥梁

实际上，以固定“仪表盘”为中心的“白屏”模式，已经不再是企业级IT运维工具建设的优选方向。随着AI时代的到来，一种新的范式正在浮现：围绕智能体（Agent） 来构建连接知识和数据的工具形态，这无疑是运维进化的未来。

其核心逻辑是：如果我们能够将运维知识（如故障处理逻辑、最佳实践）和专家经验（如对特定栈特征的理解）都进行数字化，同时，运维对象的全量指标数据能被充分采集，所需的非指标数据（如日志文本、配置上下文）也能自动提取，那么，大语言模型（LLM） 就成了连接“知识”与“数据”的绝佳桥梁。

让AI去“阅读”这些数字化的知识，并以此为指导，去分析海量的可观测性数据，完成推理、分析，甚至最终的执行动作。在AI时代，存储这些数字化知识和经验的载体也不再是问题，无论是知识图谱、向量数据库，还是可被调用的技能（Skills），都可以成为它们的归宿。

当下火热的“AI运维”：我们离真正的智能还有多远？

最近，基于大语言模型的AI应用（常被戏称为“龙虾”）大热，一些公司也顺势推出了面向运维领域的“龙虾”解决方案。但在我看来，它们目前更多是解决了一个基础框架和交互平台的问题，远未触及“智能运维”的核心。

与一些已经能出色完成创意写作或代码生成的领域不同，想让“龙虾”自己从零开始学习运维知识、完善运维能力，目前来看并不现实。因为运维领域的许多深层知识和“潜规则”，尤其是那些关于复杂系统交互和故障研判的“ tacit knowledge”（隐性知识），很难从公开文档中获取，它们大多沉淀在企业内部专家的头脑里。

因此，要想“养好”一只真正能解决实际问题的运维“龙虾”，运维领域的数字化改造和知识数字化工程，依然是一道必须迈过去的坎。这不仅仅是工具升级，更是一场关于运维方法论和工作流程的深刻变革。如果您对这个领域持续保持兴趣，欢迎来 云栈社区 的运维板块，与更多同行一起探讨智能运维的实践与未来。