一、为什么需要一个闭环先说一个常见的状态你的团队已经有了监控系统能看到设备状态有了工单系统能记录故障处理有了企微群或钉钉群能发告警通知。从单个模块看都有了。但日常运行中你会发现这些问题监控出了告警值班的人要手动去工单系统开单有时候忘了开工单开了但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: 无六、模块四工单流转6.1 工单状态机新建(New) → 已接管(Assigned) → 止损中(Mitigating) → 排障中(Investigating) → 已恢复待验证(Resolved_Pending_Verify) → 已关闭(Closed) 任意状态 → 已升级(Escalated) # 超时或手动升级 已关闭 → 重开(Reopened) # 验证不通过或问题复发6.2 工单最小字段集字段必填来源说明ticket_id自动系统生成唯一标识event_id自动事件管理模块关联的事件IDseverity自动事件分级P1/P2/P3site_id自动事件门店IDsite_name自动CMDB门店名称region自动CMDB所属区域title自动事件标题工单标题description自动手动补充事件详情故障描述assignee自动排班表当前值班人员status自动状态机当前状态created_at自动系统工单创建时间sla_response_deadline自动SLA引擎响应截止时间sla_resolve_deadline自动SLA引擎恢复截止时间mitigation_action手动值班人员止损动作记录root_cause手动值班人员根因关闭时必填resolution手动值班人员解决方案关闭时必填business_verified手动值班人员业务恢复验证结果related_sop自动知识库匹配关联的SOP卡片ID6.3 自动派单规则dispatch_rules: - condition: severity P1 assign_to: 当前值班一线 自动通知二线 - condition: severity P2 AND asset_category wan_link assign_to: 网络组值班人员 - condition: severity P2 AND asset_category IN [pos_terminal, printer] assign_to: 桌面运维值班人员 - condition: severity P3 assign_to: 放入值班待处理队列由值班组长分配七、模块五SLA引擎7.1 SLA规则定义sla_rules: P1: response_minutes: 15 # 15分钟内必须有人接管 mitigate_minutes: 30 # 30分钟内必须完成止损 resolve_minutes: 120 # 2小时内必须恢复 escalation: - trigger: response_minutes - 10 # 响应截止前10分钟 action: 通知值班组长 - trigger: response_minutes # 响应超时 action: 自动升级到二线通知区域负责人 - trigger: resolve_minutes - 30 # 恢复截止前30分钟 action: 通知区域负责人 - trigger: resolve_minutes # 恢复超时 action: 通知运维总监 P2: response_minutes: 30 resolve_minutes: 480 # 8小时 escalation: - trigger: response_minutes action: 通知值班组长 - trigger: resolve_minutes - 60 action: 通知区域负责人7.2 SLA计时规则sla_clock: start_event: event_created_at # 从事件创建开始计时不是从工单创建 pause_conditions: - status pending_external # 等待外部供应商响应时暂停 resume_conditions: - status changed from pending_external stop_event: business_verified true # 业务验证通过才停表 pause_limit: max_pause_duration_minutes: 240 # 暂停最多4小时超过自动恢复计时 rationale: 防止工单长期挂在等待外部状态逃避SLA7.3 SLA达成率计算月度SLA达成率 在SLA时限内关闭的P1P2工单数 / 当月P1P2工单总数 × 100%注意不按设备维度算按工单维度算P3/P4不纳入SLA达成率计算但单独统计在SLA时限内指response和resolve都未超时八、模块六复盘管理8.1 自动触发条件postmortem_trigger: conditions: - severity P1 # 所有P1必须复盘 - severity P2 AND resolve_minutes sla_resolve_minutes # 超时的P2 - same_site same_category events 3 in 30 days # 同站点同类事件30天内3次 deadline: 事件关闭后48小时内完成复盘8.2 复盘记录模板postmortem_record: fields: event_id: 关联的事件ID ticket_id: 关联的工单ID timeline: # 分钟级时间线 - { time: 10:03, event: 异常实际发生 } - { time: 10:05, event: 告警触发 } - { time: 10:08, event: 值班人员接管 } - { time: 10:09, event: 开始排查 } - { time: 10:25, event: 定位根因 } - { time: 10:42, event: 业务恢复 } breakpoints: # 断点标注 - { segment: 异常发生→告警触发, duration: 2min, assessment: 正常 } - { segment: 告警→人工接管, duration: 3min, assessment: 正常 } - { segment: 开始排查→定位, duration: 16min, assessment: 偏长排查方向偶偏 } root_cause: 门店网关因固件Bug导致ARP表溢出间歇性丢包 action_items: - { type: platform, action: 该型号网关批量升级固件, owner: 网络组, deadline: 2026-04-30 } - { type: sop, action: 新增SOP该型号网关丢包时优先检查ARP表, owner: 值班组长, deadline: 2026-04-25 } sop_output: # 复盘产出的SOP卡片 sop_id: SOP-NET-012 trigger: XX型号网关出现间歇性丢包告警 steps: - 第一步SSH登录网关执行 show arp 查看ARP表条目数 - 第二步如ARP条目数 4000执行 clear arp-cache 临时清理 - 第三步确认临时恢复后提交固件升级工单8.3 复盘到SOP的闭环复盘产出的SOP卡片写入知识库后需要和事件分类绑定sop_binding: sop_id: SOP-NET-012 match_conditions: - asset_model: XX网关型号 - alert_type: intermittent_packet_loss auto_attach: true # 下次同条件事件产生时自动在工单中关联此SOP这就是闭环的最后一公里——复盘不是写完就结束是通过SOP卡片和事件分类的绑定让结论在下一次同类故障时自动浮出来。九、模块七知识库/SOP管理9.1 SOP卡片结构sop_card: sop_id: SOP-NET-001 title: 区域多门店同时报网络告警 version: v2.1 last_updated: 2026-04-15 source_postmortem: PM-20251220-001 # 来源复盘 trigger_condition: 同一区域 ≥ 3 家门店在 10 分钟内报网络类告警 steps: - order: 1 action: 查区域出口链路状态延迟、丢包、带宽利用率 platform_path: 监控平台 → 网络总览 → 区域出口 - order: 2 action: 判断是否为区域性故障 decision: if_abnormal: 确认为区域链路故障跳到步骤3 if_normal: 逐店排查按门店网络SOP处理 - order: 3 action: 通知受影响门店 联系运营商报障 - order: 4 action: 15分钟未定位 → 升级网络组 escalation_rules: - 介入后15分钟未定位 → 升级网络组 - 业务影响 30分钟 → 升级区域负责人 related_events: [EVT-20251220-xxx, EVT-20260315-xxx] effectiveness: 使用此SOP后同类故障MTTR从平均75分钟降至22分钟9.2 SOP的版本管理SOP不是写完就不动的。每次同类故障复盘后如果产出了新的排查经验应该更新对应的SOP卡片并记录变更历史sop_changelog: - version: v1.0 date: 2025-12-22 change: 首次创建基于华南区域链路故障复盘 - version: v2.0 date: 2026-03-18 change: 华东同类故障后补充备链检查步骤 - version: v2.1 date: 2026-04-15 change: 补充运营商报障话术和工单模板十、模块间的数据流把7个模块串成一条线把所有模块的输入输出接口串起来看完整数据流[CMDB] ──设备清单──→ [监控采集] ──指标数据──→ [告警引擎] ──原始告警──→ [事件管理] │ 事件(Event) │ ▼ [排班表] ──当班人员──→ [工单流转] ←──事件转工单──── [事件管理] │ 工单(Ticket) │ ├──工单状态/时间──→ [SLA引擎] ──超时升级──→ [通知渠道] │ └──P1/P2工单关闭──→ [复盘管理] ──SOP卡片──→ [知识库] │ └──SOP关联──→ [事件管理]下次同类事件自动推SOP几个关键接口接口数据流向串联的两个模块触发条件指标→告警监控采集→告警引擎指标超阈值实时告警→事件告警引擎→事件管理原始告警入队列实时事件→工单事件管理→工单流转P1/P2事件自动创建事件生成时工单→SLA工单流转→SLA引擎工单创建/状态变更实时工单→复盘工单流转→复盘管理P1工单关闭或P2超时关闭关闭时复盘→知识库复盘管理→知识库复盘产出SOP复盘完成时知识库→事件知识库→事件管理事件分类匹配SOP事件生成时最后一条知识库→事件就是闭环的回路。没有这条回路所有的复盘只是文档有了这条回路复盘变成了值班人员在下一次故障时能直接用的工具。十一、最小可用版 vs 完整版上面描述的是完整架构。但如果你的团队刚起步不需要一次全做到。建议分两步走第一步最小可用版1~2个月落地模块最小可用要求监控采集覆盖网关、专线、核心交换机。终端和业务层可以后补告警引擎配好关键设备的告警规则模板事件管理做基础的告警归并和分级至少区分P1/P2/P3工单流转P1/P2事件自动创建工单状态机跑通SLA引擎P1响应15分钟、恢复2小时的超时自动升级复盘管理P1故障手动触发复盘用模板记录知识库先建5~10张高频场景的SOP卡片第二步完整版3~6个月迭代在最小可用版基础上增加终端和业务层的监控覆盖智能告警归并基于拓扑关系的根因归并自动巡检和异常自动开单SOP自动关联和推荐报表体系SLA达成、MTTR拆分、告警质量、同类事件重复率问题管理从事件升级为问题跟踪根因彻底解决十二、写在最后