AIOps 平台业务流程与规则规范（企业级）

1. 文档说明

1.1 文档目的

本文档规范 AIOps 平台的核心业务流程、模块交互规则、数据流转逻辑及运维保障要求，为平台开发、测试、运维及迭代提供统一依据，确保系统按企业级标准实现自动化、智能化运维闭环。

1.2 适用范围

适用于 AIOps 平台全生命周期管理，覆盖开发人员、测试人员、运维人员及相关业务对接人员。

1.3 术语定义

术语	定义
AIOps	基于人工智能的运维自动化平台，实现指标采集、异常检测、自动处置全流程智能化
traceId	全链路追踪标识，贯穿指标采集、异常检测、处置及回滚全流程，用于问题定位
采集规则	定义指标采集的服务范围、频率、数据源及格式要求的配置规则
自动处置	平台针对检测到的异常，按预设策略自动执行的修复操作（如扩容、重启、配置调整）
验证模式	仅检测异常不执行实际处置操作的模式，用于功能验证及策略调优

2. 项目概述

AIOps 平台是面向企业级运维场景的智能化平台，核心目标是通过 AI 技术实现运维流程自动化，降低人工干预成本，提升故障处置效率。平台核心能力覆盖指标采集、异常检测、自动处置、配置备份及回滚操作，采用模块化架构设计，支持与真实监控系统、日志系统、服务管理平台无缝集成。

当前平台支持模拟数据演示，实际部署时可快速对接 Prometheus（监控）、ELK（日志）、K8s（服务管理）等企业级基础设施。

3. 系统架构设计

3.1 整体架构图

3.2 核心模块详解

模块名称	核心职责	关键组件	依赖模块	可扩展点
aiops-front	提供可视化交互界面，支持流程监控、规则配置、异常处置	Vue 组件、路由配置、Axios 请求封装	aiops-api	支持自定义仪表盘、个性化告警配置
aiops-api	统一接口入口，处理 HTTP 请求，实现权限控制与参数校验	Controller 类、全局异常处理器、ResultDTO 响应封装	aiops-core、aiops-common	支持接口版本控制、接入 API 网关实现限流熔断
aiops-core	核心业务逻辑实现，含指标采集、异常检测、自动处置核心流程	MetricCollectService、AnomalyDetectService、AutoDisposeService	aiops-model、aiops-common、数据存储层	支持自定义采集规则、处置策略插件化扩展
aiops-model	提供异常检测 AI 能力，支持指标趋势分析、异常根因定位	AnomalyDetectAIService、模型训练接口	aiops-core、数据存储层	支持接入多算法模型（如 LSTM、孤立森林），支持模型版本管理
aiops-common	提供共享资源，统一规范系统常量、工具类、数据模型	AnomalyConstant、ResultDTO、日志工具、加密工具	所有模块	支持自定义常量扩展、工具类插件化
aiops-prometheus-mock	生成模拟监控指标数据，支持调试与演示场景	PrometheusMockService、模拟数据生成器	aiops-core	支持自定义模拟数据模板、对接真实 Prometheus 数据源
BackupService	高风险操作前配置备份，支持备份管理与恢复	备份生成器、多存储适配器（内存/文件/数据库）	数据存储层、aiops-common	支持备份策略自定义、异地备份扩展
RollbackService	执行处置操作回滚，恢复服务原始状态	回滚策略处理器、备份读取器	BackupService、aiops-core	支持自定义回滚规则、增量回滚扩展

3.3 模块交互规范

模块间通过接口调用实现交互，遵循以下规范：

• 接口调用采用 RESTful 风格，统一使用 JSON 数据格式

• 核心流程通过 traceId 实现全链路追踪，确保问题可追溯

• 跨模块调用需处理异常降级，避免单点故障影响整体流程

• 共享数据通过 aiops-common 模块定义的 DTO 传输，禁止直接传输数据库实体

3.3.1 核心交互链路

4. 核心业务流程规范

所有核心流程遵循「触发-处理-校验-存储-反馈」闭环原则，确保流程可追溯、可监控、可回滚。

4.1 指标采集流程

4.1.1 流程概述

定时采集目标服务的核心运维指标，完成数据清洗与标准化后存储，为异常检测提供数据支撑。

4.1.2 流程图

4.1.3 核心规则

• 采集频率：默认每分钟 1 次，支持通过 collect_rule 表配置个性化频率（最小粒度 10 秒）

• 指标范围：严格限制比率类指标 0-100%，数值类指标为正数，超出范围的数据标记为无效并丢弃

• 容错机制：采集失败时触发重试（最多 3 次，间隔 2 秒），重试失败记录告警日志并跳过当前采集周期

4.2 异常检测流程

4.2.1 流程概述

基于采集的指标数据与日志信息，结合阈值规则与 AI 模型实现异常判定，输出异常级别与根因分析。

4.2.2 流程图

4.2.3 核心规则

指标名称	阈值	异常级别映射
api_timeout_rate	≥5%	≥5% 且 <10%：MEDIUM；≥10%：HIGH
api_error_rate	≥5%	≥5% 且 <10%：MEDIUM；≥10%：HIGH
cpu_usage	≥70%	≥70% 且 <90%：MEDIUM；≥90%：CRITICAL
memory_usage	≥80%	≥80% 且 <95%：MEDIUM；≥95%：CRITICAL
response_time	≥500ms	≥500ms 且 <1000ms：LOW；≥1000ms：MEDIUM
补充规则：多指标同时异常时，取最高级别作为最终异常级别；AI 模型判定权重高于阈值规则（占比 60%）。

4.3 异常处置流程

4.3.1 流程概述

根据异常级别与类型执行差异化处置策略，高风险操作前自动备份配置，确保处置过程可回滚。

4.3.2 流程图

4.3.3 核心规则

• 处置优先级：CRITICAL 级异常立即处置（0 延迟），HIGH 级 10 秒内处置，MEDIUM/LOW 级按队列顺序处置

• 备份要求：高风险处置操作必须先备份，备份失败则终止处置并告警

• 重试机制：自动处置失败最多重试 3 次，每次间隔 5 秒，重试失败降级为手动模式

4.4 回滚操作流程

4.4.1 流程概述

针对处置失败或处置后出现次生问题的场景，通过备份数据执行回滚操作，恢复服务原始配置与状态。

4.4.2 流程图

4.4.3 核心规则

• 回滚权限：仅系统管理员可触发回滚操作，触发前需二次确认

• 备份有效性：回滚前校验备份数据完整性与时效性（备份时间≤7 天），无效则拒绝回滚

• 结果同步：回滚成功后同步更新异常记录状态为「已回滚」，失败则标记为「回滚失败」并触发人工告警

4.5 配置备份流程

4.5.1 流程概述

在执行高风险处置操作前自动触发配置备份，支持多存储介质备份与自动清理，保障回滚数据可用性。

4.5.2 流程图

4.5.3 核心规则

• 备份时机：仅高风险处置操作（如资源扩容、核心配置修改）触发自动备份，低风险操作可选择性备份

• 存储规范：备份文件命名严格遵循预设格式，文件系统存储需按服务名分类归档

• 清理机制：系统每日凌晨自动清理过期（超 7 天）备份数据，避免存储冗余

5. 数据存储设计

5.1 核心数据表结构

5.1.1 collect_rule（采集规则表）

字段名	字段类型	是否主键	默认值	备注
id	BIGINT	是	-	自增主键
service_name	VARCHAR(64)	否	-	服务名称，唯一
prometheus_url	VARCHAR(255)	否	-	Prometheus 数据源地址
log_path	VARCHAR(255)	否	-	日志文件路径
collect_interval	INT	否	60	采集间隔（秒）
enabled	TINYINT	否	1	是否启用（1-启用，0-禁用）
create_time	DATETIME	否	CURRENT_TIMESTAMP	创建时间

5.1.2 metric（指标数据表）

字段名	字段类型	是否主键	默认值	备注
id	BIGINT	是	-	自增主键
service_name	VARCHAR(64)	否	-	服务名称
metric_name	VARCHAR(64)	否	-	指标名称（如 cpu_usage）
metric_value	DECIMAL(10,2)	否	-	指标值
timestamp	BIGINT	否	-	时间戳（毫秒）

5.1.3 其他核心表

包括 anomaly（异常记录表）、log（日志表）、backup（备份表）、dispose_record（处置记录表），结构规范与上述表一致，核心字段均包含 service_name、timestamp、traceId 等用于全链路追踪与关联分析的字段。

5.2 数据存储优化

• 索引设计：metric 表建立 (service_name, metric_name, timestamp) 联合索引，提升查询效率；anomaly 表建立 (traceId, service_name) 索引

• 数据归档：指标数据按天归档，超过 30 天的历史数据迁移至归档库，提升查询性能

• 备份存储：核心备份数据采用「数据库+文件系统」双存储，确保数据安全性

6. 关键技术与最佳实践

6.1 定时任务优化

采用 Spring Scheduled 实现定时任务，结合线程池优化并发执行：

• 核心线程池配置：核心线程数 5，最大线程数 10，队列容量 100，避免任务堆积

• 任务隔离：不同类型任务（指标采集、日志采集、模拟数据生成）分配独立线程池，避免相互影响

• 任务监控：通过 Spring Boot Actuator 监控定时任务执行状态，失败时触发告警

6.2 全链路追踪实践

基于 traceId 实现全链路追踪，覆盖从指标采集到回滚的完整流程：

6.3 异常处理最佳实践

• 全局异常处理：通过 @RestControllerAdvice 实现全局异常捕获，统一返回 ResultDTO 格式响应

• 异常分级：按严重程度分为系统异常、业务异常、外部依赖异常，分别执行不同的处理策略

• 日志规范：异常日志需包含 traceId、异常类型、堆栈信息、发生时间，便于问题定位

6.4 可扩展性设计

• 插件化架构：核心流程（如异常检测算法、处置策略）支持插件化扩展，通过 SPI 机制加载自定义实现

• 配置驱动：关键参数（如采集频率、阈值、备份保留时间）均支持配置化，无需修改代码即可调整

• 接口标准化：模块间交互接口采用标准化设计，支持替换底层实现（如将模拟数据替换为真实数据源）

7. 运维保障规范

7.1 监控告警

• 系统监控：监控平台核心模块运行状态、CPU/内存/磁盘使用率，超出阈值触发告警

• 流程监控：监控定时任务执行成功率、异常检测准确率、处置成功率，低于 95% 触发告警

• 告警渠道：支持邮件、短信、企业微信多渠道告警，按异常级别区分告警优先级

7.2 版本迭代

• 迭代策略：采用小步快跑模式，每次迭代聚焦 1-2 个核心功能，避免大规模变更

• 灰度发布：新版本上线前先在测试环境验证，再通过灰度发布逐步覆盖生产环境

• 回滚机制：版本发布失败时，支持快速回滚至历史稳定版本，确保系统可用性

7.3 安全保障

• 权限控制：实现基于角色的权限管理（RBAC），不同角色分配不同操作权限

• 数据安全：敏感配置数据加密存储，传输过程采用 HTTPS 加密

• 接口安全：API 接口支持令牌验证、签名验证，防止非法调用

8. 总结与展望

8.1 总结

本规范明确了 AIOps 平台的企业级设计标准，通过模块化架构、闭环业务流程、标准化交互规则，实现了运维流程的自动化、智能化与可扩展化。平台当前基于模拟数据实现完整流程演示，后续可通过对接真实基础设施，快速落地企业级运维场景。

8.2 展望

• 扩展 AI 能力：引入根因自动定位、运维知识图谱，提升异常处置智能化水平

• 对接更多生态：支持对接云原生环境（K8s、Docker）、容器化部署，扩大平台适用范围

• 可视化增强：优化前端交互体验，支持自定义仪表盘、流程可视化拖拽配置