多门店运维闭环全景架构：监控+告警+工单+SLA+复盘，一套最小可用系统怎么串起

一、为什么需要一个"闭环"

先说一个常见的状态：

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

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

• 监控出了告警，值班的人要手动去工单系统开单，有时候忘了开
• 工单开了，但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: "无"

六、模块四：工单流转

6.1 工单状态机

新建(New) → 已接管(Assigned) → 止损中(Mitigating) → 排障中(Investigating) → 已恢复待验证(Resolved_Pending_Verify) → 已关闭(Closed) 任意状态 → 已升级(Escalated) # 超时或手动升级 已关闭 → 重开(Reopened) # 验证不通过或问题复发

6.2 工单最小字段集

6.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: "防止工单长期挂在'等待外部'状态逃避SLA"

7.3 SLA达成率计算

月度SLA达成率 = 在SLA时限内关闭的P1+P2工单数 / 当月P1+P2工单总数 × 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）

几个关键接口：

最后一条"知识库→事件"就是闭环的回路。没有这条回路，所有的复盘只是文档；有了这条回路，复盘变成了值班人员在下一次故障时能直接用的工具。

十一、最小可用版 vs 完整版

上面描述的是完整架构。但如果你的团队刚起步，不需要一次全做到。建议分两步走：

第一步：最小可用版（1~2个月落地）

第二步：完整版（3~6个月迭代）

在最小可用版基础上增加：

• 终端和业务层的监控覆盖
• 智能告警归并（基于拓扑关系的根因归并）
• 自动巡检和异常自动开单
• SOP自动关联和推荐
• 报表体系（SLA达成、MTTR拆分、告警质量、同类事件重复率）
• 问题管理（从事件升级为问题，跟踪根因彻底解决）

十二、写在最后