多门店运维闭环全景架构：监控+告警+工单+SLA+复盘，一套最小可用系统怎么串起来
适用对象：正在搭建多门店/多分支IT运维体系的团队、MSP交付团队、运维平台架构师
目标：给出一套最小可用的运维闭环架构，覆盖从"设备出问题"到"下次不再出同样问题"的完整链路
阅读建议：全文较长，建议先看架构总览图，再按需跳到感兴趣的模块
一、为什么需要一个"闭环"
先说一个常见的状态：
你的团队已经有了监控系统，能看到设备状态；有了工单系统，能记录故障处理；有了企微群或钉钉群，能发告警通知。从单个模块看，都有了。
但日常运行中你会发现这些问题：
- 监控出了告警，值班的人要手动去工单系统开单，有时候忘了开
- 工单开了，但SLA时限靠组长每天下午扫一遍工单列表来盯
- 故障处理完了，复盘是复盘、工单是工单、SOP是SOP，三个东西存在三个地方，没有关联
- 新来的值班人员接到告警不知道怎么处理，因为之前的经验沉淀在老员工的脑子里
这些问题的根源不是工具不好，而是模块之间没有串起来。每个模块独立运行，数据不流动、状态不传递、知识不复用。
运维闭环要解决的就是这件事：让数据从头到尾流一遍，每个环节的输出自动成为下一个环节的输入，不依赖人手动搬运。
二、全景架构总览
整个闭环链路可以拆成7个模块，串成一条主线：
[1. 监控采集] → [2. 告警引擎] → [3. 事件管理] → [4. 工单流转] → [5. SLA引擎] → [6. 复盘管理] → [7. 知识库/SOP]
↓
回流到 [3. 事件管理]
（下次同类事件自动关联SOP）
每个模块的职责和边界：
| 模块 | 职责 | 输入 | 输出 |
|---|---|---|---|
| 监控采集 | 采集设备/链路/业务指标，存储时序数据 | 设备SNMP/Agent/API数据 | 指标时序数据 |
| 告警引擎 | 基于规则判定异常，生成原始告警 | 指标时序数据 + 告警规则 | 原始告警 |
| 事件管理 | 告警归并、分级、去重、抑制，生成可处置事件 | 原始告警 + 归并规则 | 事件（Event） |
| 工单流转 | 事件自动转工单，派单、流转、记录处理过程 | 事件 + 派单规则 | 工单（Ticket） |
| SLA引擎 | 监控工单时效，超时自动升级 | 工单 + 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/SNMP |
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个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: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 工单最小字段集
| 字段 | 必填 | 来源 | 说明 |
|---|---|---|---|
| ticket_id | 自动 | 系统生成 | 唯一标识 |
| event_id | 自动 | 事件管理模块 | 关联的事件ID |
| severity | 自动 | 事件分级 | P1/P2/P3 |
| site_id | 自动 | 事件 | 门店ID |
| site_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卡片ID |
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）
几个关键接口：
| 接口 | 数据流向 | 串联的两个模块 | 触发条件 |
|---|---|---|---|
| 指标→告警 | 监控采集→告警引擎 | 指标超阈值 | 实时 |
| 告警→事件 | 告警引擎→事件管理 | 原始告警入队列 | 实时 |
| 事件→工单 | 事件管理→工单流转 | 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拆分、告警质量、同类事件重复率）
- 问题管理（从事件升级为问题，跟踪根因彻底解决）
十二、写在最后
运维闭环不是一个产品的名字，是一个架构模式。它的核心思想很简单：让数据从"发现问题"流到"防止再发生"，每一步都有明确的输入、输出和触发条件，不依赖人手动搬运。
很多团队的运维体系停在"有监控、有工单、有告警"这个阶段——各个模块独立运行，中间靠人肉搬运数据。这种方式在管20家门店时还能扛，到了100家规模，靠人搬数据基本跑不动了。
我们自己也是一步步踩坑过来的，这套架构不一定适合所有团队，但里面的思路可以参考。如果你也在搭建或改造多门店运维体系，可以试着把本文的架构图和自己现在的系统对一下：7个模块有几个？模块之间的数据流通了几条？哪条还没接上？从那条断开的线开始补，往往是投入产出比最高的。
浙公网安备 33010602011771号