观澜 AIOps 智能告警分析平台

大约 11 分钟

观澜 AIOps 智能告警分析平台

项目定位

这是一个面向运维与平台团队的 AIOps 平台，解决告警太多、重复告警多、定位慢、知识散、应急流程不统一的问题。AI 负责归纳和检索，Java 负责告警流转、规则执行和统计归档。

项目背景

微服务、容器、数据库、中间件和云资源持续产生指标、日志、链路、变更和告警。一个故障往往会在多个系统中同时产生大量重复告警，值班人员需要先判断影响范围，再查找 Runbook、发布记录和历史案例，定位速度高度依赖个人经验。观澜 AIOps 智能告警分析平台通过统一接入、告警治理和知识沉淀，帮助运维团队建立稳定的故障响应流程。

业务概述

平台接入业务系统和第三方监控数据，对信号进行标准化、去重、聚合、抑制和升级，形成统一的告警事件。值班人员在预警工作台查看影响服务、拓扑关系、最近变更和历史案例，系统给出根因候选和 Runbook 建议，处置结果、时间线和复盘结论沉淀到知识库。

主要业务场景包括：

指标、日志、链路、变更和工单数据统一接入；
重复告警合并、噪声抑制、优先级调整和升级；
服务拓扑、影响范围、变更关联和根因候选分析；
值班排班、协同群组、Runbook 和工单联动；
MTTA、MTTR、告警量、恢复率和服务趋势分析。

技术架构选型

1. 整体架构

采用事件驱动和可观测性架构，数据接入、规则计算、告警中心、拓扑服务、分析服务和通知服务独立部署。采集数据进入消息总线后进行标准化和规则计算，告警状态由事件中心统一维护，AI 只读取授权数据生成摘要和诊断建议。

2. 后端技术

Spring Boot / Spring Cloud Alibaba：构建告警、规则、拓扑和分析服务；
Spring Security：控制租户、服务、值班组和敏感运维数据访问；
MySQL：保存告警、规则、服务、变更、工单和审计数据；
Elasticsearch：存储日志、事件、时间线和历史案例，支持高速查询。

3. 中间件与 AI 能力

Kafka / RabbitMQ：承载监控信号、告警事件和通知消息；
Redis：保存时间窗口、去重指纹、拓扑缓存和抑制状态；
时序数据库：保存指标和资源趋势数据；
向量库 + RAG：检索 Runbook、历史故障和复盘案例；
XXL-JOB：执行告警扫描、聚合、报表和知识同步。

主要业务模块

1. 数据接入与信号管理

适配指标、日志、链路、云资源和第三方系统，统一字段、服务标识、时间和严重等级，支持失败重试和补偿。

2. 预警工作台

集中展示待确认、处理中、已恢复和已关闭告警，支持确认、分派、升级、协同和处置时间线。

4. 服务拓扑与风险分析

维护应用、主机、数据库和中间件依赖关系，结合变更记录和告警时间计算影响范围和根因候选。

5. 应急处置与通知

管理值班表、群组、Runbook、工单和多渠道通知，生产执行动作需要权限、审批和回执校验。

6. 报表、审计与运维

统计告警量、重复率、响应时长、恢复时长和服务趋势，记录规则变更、告警处理、工具调用和数据导出。

技术要点与应用价值

每次告警合并、抑制和升级都记录规则、时间窗口和关联对象，保证降噪可解释；
通过指纹、时间窗口和状态机解决重复告警、延迟恢复和乱序消息问题；
AI 输出根因候选和证据，不能直接重启服务或修改生产配置；
故障时间线和人工结论经审核后沉淀为 Runbook，持续降低重复排障成本；
通过 MTTA、MTTR 和告警趋势帮助团队评估稳定性治理效果。

陪跑价值与学习收获

AIOps 项目直接面对线上系统的稳定性问题：告警来自不同平台，重复、噪声和关联关系让定位变慢，值班人员还要在压力下查 Runbook、看变更和组织处置。你会把告警接入、降噪聚合、拓扑分析、根因建议和复盘知识串成闭环，理解 AI 如何帮助运维人员更快判断，而不是替代生产操作。

学会设计告警去重、抑制、升级、恢复和事件状态机。
掌握指标、日志、链路、变更、服务拓扑和 Runbook 的关联方式。
理解生产环境中的 Tool Calling、审批、回执和安全边界。

你将带走的成果

一套从告警产生到故障复盘的 AIOps 项目讲解框架。
一份体现可观测性、异步处理、降噪策略和可靠性的技术亮点。
一套适合平台研发、后端和 AI 工程岗位的面试素材。

业务背景与建设目标

微服务、容器、数据库、中间件和云资源持续产生监控指标、日志、链路和告警。单个故障往往会在多个系统中产生大量重复告警，值班人员需要先判断影响范围，再查找 Runbook、变更记录和历史案例，定位速度高度依赖个人经验。

观澜 AIOps 智能告警分析平台把指标、日志、链路、变更和工单统一接入，以“采集、去重、聚合、分派、诊断、处置、复盘”为主线建立运维闭环。AI 用于告警摘要、相似事件检索、根因分析建议和 Runbook 问答，Java 服务负责规则计算、告警状态、责任人、应急流程和审计，确保自动化动作可控。

业务模块与关键流程

业务模块	核心能力	Java / AI 落点
数据接入	指标、日志、链路、事件和变更记录接入	适配器、消息消费、批量写入和失败重试
告警中心	去重、合并、抑制、升级、确认和恢复	规则引擎、时间窗口聚合和状态机
服务拓扑	应用、主机、数据库、中间件和依赖关系	拓扑查询、影响范围计算和权限过滤
故障分析	相似事件、变更关联、根因候选和影响评估	RAG 检索 Runbook，AI 生成分析草稿
应急处置	值班排班、协同群组、Runbook、工单和复盘	Tool Calling 只读查询，执行动作需审批
可观测分析	MTTA、MTTR、告警量、重复率和服务趋势	定时聚合、看板接口和异常报告

工程化难点与应用价值

告警降噪可解释：每次合并、抑制和升级都记录规则、时间窗口和关联对象，方便值班人员理解告警为何变化。
根因分析有边界：模型给出候选原因和证据，不能直接重启服务或修改配置；生产操作必须经过权限、审批和回执校验。
拓扑与变更联动：把服务依赖、发布记录和故障时间线放到同一视图，帮助快速判断是代码、配置、资源还是外部依赖问题。
复盘反哺知识库：故障工单、时间线和最终结论经人工审核后沉淀为 Runbook 和案例，持续降低重复排障成本。

模块流程图

技术架构

技术	作用
Spring Boot	告警、复盘、通知接口
MySQL	告警记录、规则、复盘单
Redis	告警去重、上下文、热点缓存
MQ	事件分发、通知、异步处理
Elasticsearch / 向量库	Runbook、故障手册、复盘文档
Spring AI	告警摘要、分析建议、问答

AI 接入点

RAG：Runbook、故障手册、历史复盘、应急预案。
Tool Calling：服务依赖、部署信息、告警详情、值班信息。
Agent：摘要、归因建议、应急步骤、升级人工。

项目亮点

很适合讲“告警降噪”和“根因分析”。
能自然体现可观测性和平台工程能力。
适合有工作经验的表达方式。

面试追问

告警降噪规则怎么设计？
根因分析为什么不能只靠模型？
Runbook 检索失败怎么降级？

1 分钟介绍

这个项目是一个 Java+AI 企业级项目，核心不是单独做聊天机器人，而是把大模型能力接入真实业务流程。我的讲法会先说明业务痛点，再讲 Java 后端负责流程、权限、事务和审计，最后说明 RAG、Tool Calling 和 Agent 分别解决知识检索、业务查询和多步骤编排问题。

3 分钟介绍

我会先从业务背景讲起：这个项目要解决的是传统系统中信息分散、流程依赖人工经验、处理效率不稳定的问题。整体链路上，用户先发起业务请求，Java 后端完成鉴权、参数校验、状态流转和数据落库；AI 层负责理解意图、检索知识、调用受控工具并生成草稿或建议。

技术上，项目通常会用 Spring Boot 承接核心业务接口，用 MySQL 保存业务主数据、状态记录和审计日志，用 Redis 做热点缓存、会话上下文和幂等控制，用 MQ 解耦通知、索引同步和统计任务。AI 能力上，RAG 负责检索企业知识和历史案例，Tool Calling 负责受控查询业务数据，Agent 负责编排多步骤任务。正式写操作和高风险动作不会让模型直接执行，而是进入人工确认或 Java 业务服务事务边界。

面试时我会重点强调三点：第一，AI 只是辅助理解和生成建议，不能绕过权限和审计；第二，所有工具调用都要做白名单、参数校验、限流和日志；第三，模型超时、无召回、低置信度或输出不合法时，要能降级到规则模板、人工处理或只展示已有业务数据。

简历一句话写法

我负责 AIOps 智能告警分析平台的 Java+AI 设计，覆盖告警归并、Runbook 检索、故障归因和应急辅助。