AIOps为什么需要从“处理告警“转向“理解业务服务关系“？

告警已经处理了，业务问题仍然没有解决

一个核心业务系统响应变慢，监控平台立即产生大量告警。应用服务器CPU升高，数据库连接数增加，存储延迟出现波动，部分容器发生重启，网络端口也产生丢包警告。

传统告警平台可以完成去重、压缩、分派和通知，却很难回答最关键的问题：这些告警之间有什么关系，哪个异常最接近根因，故障正在影响哪个业务服务？

如果AIOps只是在更快地处理告警，它能够减少人工浏览和分类工作，却无法真正理解生产环境。业务系统由应用、数据库、中间件、虚拟机、容器、服务器、存储和网络共同支撑，一个组件发生异常后，告警会沿着依赖关系不断扩散。

根因分析需要掌握服务之间的真实关系。缺少这张关系地图，AI只能看到许多同时出现的信号，难以判断故障传播方向，也无法准确评估业务影响。

传统AIOps为什么仍然围绕告警打转

早期AIOps通常从事件管理开始。平台接收不同监控系统的告警，再使用规则、统计模型或机器学习进行去重、降噪、聚类和优先级排序。

这类能力可以解决告警数量过多的问题。例如，相同设备产生的重复告警可以合并，短时间内反复恢复的抖动告警可以压缩，维护窗口中的通知可以暂时屏蔽。

然而，告警相似并不代表存在因果关系。两条告警可能在同一时间发生，却属于两个无关事件；一条告警也可能比根因晚出现，却拥有更高的严重级别。单纯依靠文本、时间和历史共现进行分析，容易把相关性当成因果关系。

一些平台依赖CMDB提供资源关系，但CMDB常常更新不及时。应用迁移到新的虚拟机，数据库切换节点，容器重建和硬件变更发生后，原有拓扑可能已经失效。

另一种问题是关系颗粒度过细。企业试图把每个IP、端口、进程和通信连接全部录入知识图谱，项目很快陷入持续维护。排障需要的是清晰的服务依赖链，例如应用服务依赖数据库服务，数据库服务依赖存储服务。过度追求明细完整度，反而会增加模型复杂度。

在缺少可靠服务关系的情况下，即使接入大模型，AI也只能总结告警文本、生成排查建议或复述知识库内容，难以沿真实依赖关系开展根因推理。

CloudSino如何建立面向业务服务的AIOps

CloudSino通过DCOS、iDCOS和SmartBSM，把硬件事实、软件资源关系与业务服务关系连接起来。

DCOS负责服务器、存储、网络、安全和动环等硬件基础设施。它可以提供设备及部件级状态，让AIOps看到操作系统监控容易遗漏的硬盘、内存、电源、风扇、端口、温度和功耗异常。

iDCOS负责操作系统、虚拟机、数据库、中间件、容器、Kubernetes和云资源，并管理配置项及其依赖关系。它帮助平台理解应用运行在哪里、使用哪个数据库、经过哪些中间件，以及底层依赖哪些物理资源。

SmartBSM从更高层组织业务系统、应用服务、技术组件和业务流程。企业可以建立业务拓扑，为服务设置健康指标、重要级别和责任团队，并将底层告警映射到具体业务对象。

当存储延迟导致数据库响应变慢，继而引发订单服务超时和用户提交失败时，SmartBSM可以沿"存储服务、数据库服务、订单服务、业务流程"的关系呈现故障影响。多个技术告警可以被组织为一个业务事件，运维团队能够看到可能的根因、传播路径和影响范围。

这张关系图也为AI提供了推理基础。AI可以结合当前告警、资源状态、近期变更、历史案例和服务依赖提出多个可能原因，并沿不同路径验证假设。

知识库和历史处置记录可以为分析提供补充。经过验证的排查步骤可以沉淀为标准流程，涉及重启、切换或配置修改的动作继续保留人工审批，从而在提高效率的同时控制生产风险。

CloudSino为什么从服务关系出发

CloudSino的第一个差异是覆盖范围贯穿业务与物理基础设施。很多AIOps产品主要面向日志、指标、调用链和云原生环境，CloudSino还能够通过DCOS加入硬件部件与数据中心环境数据。

第二个差异是使用适当的关系颗粒度。根因分析关注清晰的服务依赖和业务影响，同时保留向下查看具体设备与部件的能力。企业无需先完成一张包含全部IP和端口的庞大关系图，便可以从关键业务服务开始建设。

第三个差异是可以利用现有CMDB和监控工具。已有数据可以作为初始关系和信号来源，iDCOS持续治理资源关系，SmartBSM围绕业务服务组织这些信息。企业过去建设的监控体系仍然可以继续发挥作用。

第四个差异是分析过程可验证。工程师可以看到AI使用了哪些告警、资源关系、变更信息和历史案例，也能沿业务拓扑检查故障传播路径。这样的结果更容易获得生产运维团队信任。

AIOps的下一阶段，需要帮助企业理解一个异常如何沿服务链传播，以及它最终影响了哪些客户和业务流程。处理告警只是入口，服务关系才是根因分析、影响判断和自动化处置的基础。

标签

#AIOps #告警处理 #业务服务 #服务关系 #根因分析