为什么需要一个“闭环“

先说一个常见的状态：

你的团队已经有了监控系统，能看到设备状态；有了工单系统，能记录故障处理；有了企微群或钉钉群，能发告警通知。从单个模块看，都有了。

但日常运行中你会发现这些问题：

• 监控出了告警，值班的人要手动去工单系统开单，有时候忘了开
• 工单开了，但SLA时限靠组长每天下午扫一遍工单列表来盯
• 故障处理完了，复盘是复盘、工单是工单、SOP是SOP，三个东西存在三个地方，没有关联
• 新来的值班人员接到告警不知道怎么处理，因为之前的经验沉淀在老员工的脑子里

这些问题的根源不是工具不好，而是模块之间没有串起来。每个模块独立运行，数据不流动、状态不传递、知识不复用。

运维闭环要解决的就是这件事：让数据从头到尾流一遍，每个环节的输出自动成为下一个环节的输入，不依赖人手动搬运。

二、全景架构总览

整个闭环链路可以拆成7个模块，串成一条主线：

[1. 监控采集] → [2. 告警引擎] → [3. 事件管理] → [4. 工单流转] → [5. SLA引擎] → [6. 复盘管理] → [7. 知识库/SOP] ↓ 回流到 [3. 事件管理] （下次同类事件自动关联SOP）

每个模块的职责和边界：

闭环的关键在最后一步的回流：知识库里的SOP卡片和事件分类绑定。下次同类事件产生时，工单系统自动把相关SOP推给值班人员。这样复盘的结论不是停在文档里，而是在下一次故障时自动被调用。

三、模块一：监控采集

3.1 采集范围

多门店场景下，监控采集至少覆盖以下层次：

3.2 采集器架构

多门店场景推荐分布式采集架构：

总部监控平台 ├── 区域采集节点（华东） │ ├── 门店01采集器 │ ├── 门店02采集器 │ └── ... ├── 区域采集节点（华南） │ ├── 门店51采集器 │ └── ... └── 区域采集节点（华北） └── ...

• 门店采集器：部署在门店本地（可以是软件Agent或轻量级采集盒子），负责采集本店设备数据，通过专线/VPN回传到区域节点。
• 区域采集节点：汇聚该区域所有门店数据，做初步预处理（聚合、压缩），再上报总部。
• 总部监控平台：存储全量数据，做告警判定、大屏展示、报表分析。

分布式采集的好处：门店网络断了，本地采集器仍在运行，网络恢复后数据补报。不会因为一段网络抖动就丢失监控数据。

3.3 采集器健康监控

上一层的监控，也需要被监控。采集器必须有心跳机制：

collector_heartbeat: interval_seconds: 60 alert_on_miss: 3 # 连续3次心跳缺失触发告警 alert_severity: "P2" # 采集器离线视为P2 alert_title: "采集器离线：{site_name}"

四、模块二：告警引擎

4.1 告警规则模板

按设备类型定义告警规则模板，新设备接入时自动继承：

alert_templates: network_gateway: rules: - name: "网关不可达" condition: "ping_status == 'unreachable' for 3 cycles" severity: "P1" - name: "网关高延迟" condition: "avg_latency > 100ms for 5min" severity: "P2" - name: "网关CPU高" condition: "cpu_usage > 85% for 15min" severity: "P3" - name: "网关丢包" condition: "packet_loss > 5% for 5min" severity: "P2" wireless_ap: rules: - name: "AP离线" condition: "status == 'offline' for 2 cycles" severity: "P3" # 单AP离线是P3 - name: "AP批量离线" condition: "offline_ap_count >= 3 in same_site within 5min" severity: "P2" # 同店3个以上AP离线升级为P2 wan_link: rules: - name: "专线中断" condition: "link_status == 'down'" severity: "P1" - name: "专线高延迟" condition: "latency > 80ms for 10min" severity: "P2" - name: "专线带宽饱和" condition: "bandwidth_utilization > 90% for 15min" severity: "P3"

4.2 告警规则覆盖率检查

每月自动跑一次检查：CMDB中所有设备 × 设备类型对应的告警模板 → 标记没有告警规则的设备。

覆盖率 = 有告警规则的设备数 / CMDB中所有活跃设备数 × 100% 目标值：100%（至少关键设备100%覆盖）

五、模块三：事件管理

5.1 告警到事件的转化

原始告警不直接推给值班人员，而是先经过事件管理模块处理：

原始告警 → 去重 → 归并 → 分级 → 抑制 → 事件

每一步的作用：

5.2 事件数据结构

{ "event_id": "EVT-20260420-0015", "title": "上海浦东47号门店 网关不可达", "severity": "P1", "status": "open", "site_id": "SITE-SH-047", "site_name": "上海浦东47号门店", "region": "华东", "asset_category": "network_gateway", "alert_type": "unreachable", "alert_count": 8, "first_alert_at": "2026-04-20T10:03:22+08:00", "last_alert_at": "2026-04-20T10:05:11+08:00", "affected_assets": [ {"asset_id": "GW-SH047", "type": "gateway", "alert": "unreachable"}, {"asset_id": "SW-SH047-01", "type": "switch", "alert": "unreachable", "suppressed": true}, {"asset_id": "AP-SH047-01", "type": "ap", "alert": "offline", "suppressed": true} ], "business_impact": "收银系统不可用", "suggested_sop": "SOP-NET-001", "auto_ticket": true }

关键设计：

• suppressed: true标记被抑制的衍生告警——它们被归入了这条事件，但不会单独产生新事件
• suggested_sop自动关联知识库中的SOP卡片
• auto_ticket: true标记这条事件是否自动创建工单

5.3 事件到工单的自动转化规则

auto_ticket_rules: - severity: "P1" action: "立即创建工单并派给当前值班人员" notification: "电话+企微" - severity: "P2" action: "立即创建工单并派给当前值班人员" notification: "企微" - severity: "P3" action: "创建工单放入待处理队列" notification: "企微（低优先级频道）" - severity: "P4" action: "仅记录，不创建工单" notification: "无"

六、模块四：工单流转