为什么需要一个“闭环“

先说一个常见的状态你的团队已经有了监控系统能看到设备状态有了工单系统能记录故障处理有了企微群或钉钉群能发告警通知。从单个模块看都有了。但日常运行中你会发现这些问题监控出了告警值班的人要手动去工单系统开单有时候忘了开工单开了但SLA时限靠组长每天下午扫一遍工单列表来盯故障处理完了复盘是复盘、工单是工单、SOP是SOP三个东西存在三个地方没有关联新来的值班人员接到告警不知道怎么处理因为之前的经验沉淀在老员工的脑子里这些问题的根源不是工具不好而是模块之间没有串起来。每个模块独立运行数据不流动、状态不传递、知识不复用。运维闭环要解决的就是这件事让数据从头到尾流一遍每个环节的输出自动成为下一个环节的输入不依赖人手动搬运。二、全景架构总览整个闭环链路可以拆成7个模块串成一条主线[1. 监控采集] → [2. 告警引擎] → [3. 事件管理] → [4. 工单流转] → [5. SLA引擎] → [6. 复盘管理] → [7. 知识库/SOP] ↓ 回流到 [3. 事件管理] 下次同类事件自动关联SOP每个模块的职责和边界模块职责输入输出监控采集采集设备/链路/业务指标存储时序数据设备SNMP/Agent/API数据指标时序数据告警引擎基于规则判定异常生成原始告警指标时序数据 告警规则原始告警事件管理告警归并、分级、去重、抑制生成可处置事件原始告警 归并规则事件Event工单流转事件自动转工单派单、流转、记录处理过程事件 派单规则工单TicketSLA引擎监控工单时效超时自动升级工单 SLA规则升级通知、SLA达成数据复盘管理P1/P2故障关闭后触发复盘流程已关闭的P1/P2工单复盘记录、改进措施知识库/SOP复盘结论沉淀为SOP卡片关联到事件分类复盘结论SOP卡片闭环的关键在最后一步的回流知识库里的SOP卡片和事件分类绑定。下次同类事件产生时工单系统自动把相关SOP推给值班人员。这样复盘的结论不是停在文档里而是在下一次故障时自动被调用。三、模块一监控采集3.1 采集范围多门店场景下监控采集至少覆盖以下层次层次采集对象关键指标采集方式WAN层专线/VPN/SD-WAN延迟、丢包、带宽利用率、可用性SNMP/NetFlow/API网络设备层网关、交换机、AC、防火墙CPU、内存、端口状态、会话数SNMP/SSH无线层AP在线状态、连接终端数、信号强度AC API/SNMP终端层收银机、POS、打印机在线状态、网络连通性Ping/Agent业务层收银系统、ERP、OA接口响应时间、事务成功率HTTP探测/Agent安防层摄像头、NVR在线状态、存储容量ONVIF/SNMP3.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: P34.2 告警规则覆盖率检查每月自动跑一次检查CMDB中所有设备 × 设备类型对应的告警模板 → 标记没有告警规则的设备。覆盖率 有告警规则的设备数 / CMDB中所有活跃设备数 × 100% 目标值100%至少关键设备100%覆盖五、模块三事件管理5.1 告警到事件的转化原始告警不直接推给值班人员而是先经过事件管理模块处理原始告警 → 去重 → 归并 → 分级 → 抑制 → 事件每一步的作用步骤作用示例去重同一告警在未恢复期间不重复生成网关一直不可达每个采集周期都触发告警只保留第一条归并同根因的多条告警合成一条事件同一门店5个AP离线 → 1条AP批量离线事件分级根据影响范围和业务关联自动定级3家以上门店同时受影响 → P1抑制已知的根因告警屏蔽其衍生告警网关不可达时抑制该网关下所有设备的告警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:2208:00, last_alert_at: 2026-04-20T10:05:1108: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: 无六、模块四工单流转