智能化运维
平台围绕「变更安全」和「告警降噪」两条主线展开。变更侧从工单提交开始，先跑安全预检查，再按资产等级、影响面、命令危险度、变更窗口、灰度比例、历史失败率六个因子算风险分，达到 80 分自动升为 P0 并强制双人审批。
执行侧只走白名单内的 SSH 命令，执行器可切到 mock 模式先在演练环境跑一遍；执行中关键指标越界会触发熔断，剩余步骤直接中止。
告警侧按指纹与拓扑聚合重复告警，输出 Top3 根因与证据链；所有操作记录带 SHA256 指纹，形成可复核的审计链。
智能侧不接外部大模型：根因由拓扑、指标规则、历史 RCA 与知识库案例四路加权；命中白名单的低风险动作可自动执行，带熔断与执行校验。
以上为界面示意，数值为演示数据。
这套系统要解决的，是三件具体的事。
告警太多，没人看得过来
同一台交换机抖动，一个小时能堆出上百条告警；值班的人只能凭经验挑几条看。
按指纹聚合、按资产与业务分组，先给 Top3 根因，再谈处置。
变更靠人盯，出事说不清
谁改的、改了什么、有没有审批，散在聊天记录和临时脚本里，事后很难复核。
工单从草稿到归档十态流转，每步留 SHA256 指纹，改一条就对不上。
权限给出去就收不回
运维账号共用、临时授权长期不回收，是很多事故的起点。
RBAC 按角色授权、MFA 登录、执行器白名单，命令危险度直接参与风险评分。
按功能分区，一条条能对上。
三层安全体系
事前预检查、事中双人复核与熔断、事后审计留痕，三层各自独立生效。
六因子风险评分
资产等级、影响面、命令危险度、变更窗口、灰度比例、历史失败率加权得出 0–100 分。
全状态机工单
草稿→提交→安全预检查→审核→待执行→二次校验→执行→健康校验→验证→归档，越级会被拦下。
告警聚合与根因
按指纹与拓扑聚合重复告警，输出 Top3 根因与证据链，减少无效打扰。
SHA256 审计指纹链
每条操作记录带前一环指纹，改一条就对不上，审计可复核。
RBAC 与 MFA
角色与权限分离，登录走 TOTP 二次验证，关键操作再验一次。
SSH 执行器与白名单
命令走白名单校验，执行器可切 mock 模式，先在演练环境跑一遍。
资产与拓扑
主机、机柜、业务分组统一维护，风险评分直接引用资产等级。
移动端值守
uni-app 移动端接收告警与待办，值班不必守在电脑前。
先把噪音降下来，再把重复活交出去。
智能结论只作为建议，写操作仍走工单与审批，不把执行权交给算法。
告警聚合降噪
同资产同指标 30 分钟内合并，拓扑相邻资产的级联告警并成一个事件，抖动风暴单独标记；压缩率作为验收指标，值班先看事件而不是刷屏。
Top3 根因与证据链
拓扑关联、指标特征规则、历史已闭环根因、知识库相似案例四路加权，输出候选根因、置信度与证据链；证据不足时明说，不硬给结论。
白名单自愈
重启服务、清理日志这类动作进白名单后可自动执行，带全局熔断、每小时次数上限与执行后校验；失败不硬扛，转人工处理。
这套系统用什么搭起来的。
选型不藏：下面这些是实际在用的框架、中间件与运行环境，交付时按同一份清单核对。
- Spring Boot 3.2服务端框架
- JDK 21运行时
- MyBatis-Plus数据访问
- MySQL 8业务库
- Vue 3 + Vite前端工程
- Element Plus界面组件
- ECharts告警与趋势图
- uni-app移动值守
- RBAC + TOTP权限与二次验证
- SSH 执行器白名单与熔断
一条链路走完，责任留在链上。
提交与评估
填写变更内容与影响范围，系统跑安全预检查并给出六因子评分。
审批与复核
按分值走单人或双人审批；≥80 分自动升 P0，必须两人分别确认。
执行与熔断
通过白名单的 SSH 执行，关键指标越界自动熔断并中止剩余步骤。
校验与归档
执行后跑健康校验，验证通过才归档，全程指纹入链。
三种落法，按客户环境选。
| 部署形态 | 适用环境 | 说明 |
|---|---|---|
| 单机 Docker Compose | 中小规模、单机房 | 一台 8 核 16G 服务器即可起步，MySQL、Redis 与后端同机部署，适合先试点。 |
| 集群 K8s | 多机房、较大规模 | 前后端与执行器分开编排，按节点扩容，适合已有 K8s 底座的客户。 |
| 内网离线部署 | 隔离网络环境 | 离线镜像导入，不依赖外网；交付前按客户操作系统与数据库版本做兼容性验证。 |