概述

每天凌晨的人工巡检，看的是告警台、指示灯和几张KPI截图——它只能发现“已病”，发现不了“将病”。本文以某省运营商核心网700余个网元的真实改造过程为例，回答三个问题：人工巡检为什么会漏检、自动化巡检的体检单该怎么设计、工具链如何用现成开源件在半年内搭起来。文章给出巡检清单七大类64项的完整拆解、四层工具链架构图，以及三个靠“趋势”而非“门限”提前发现的疑难病例，并对照TM Forum自智网络分级与ETSI ZSM闭环架构，讨论自动化与人力的真实边界。

目录

• 一、从一次话单延迟说起：人工巡检的天花板
• 二、先把体检单重写：七大类六十四项
• 三、工具链怎么搭：四层架构与开源选型
• 四、门限会撒谎：三个“将病”病例
• 五、别迷信全自动：人机划界的两条线
• 六、成效与两条负面教训
• 结语

一、从一次话单延迟说起：人工巡检的天花板

先讲一个我们自己的病例。

2024年12月，话务高峰时段，计费侧话单延迟从常态的5分钟以内恶化到4小时，营业厅投诉单半天堆了几百张。排查结果并不戏剧化：某AMF资源池的计费服务器日志盘使用率到了100%，话单文件先落本地缓存，盘满了就排队，排在后面的就是几个小时的话单延迟。

尴尬的是，出事前一夜的例行人工巡检记录上，这台设备写的是“正常”。巡检表上磁盘那一栏的门限是90%，当时实际使用率87%——没过线，所以是“正常”。没人看斜率：这块盘已经连续19天按每天1.5个百分点的速度爬坡，照这个速度，出事当天正好写满。事后复盘时翻历史数据，19天里任何一天看一眼趋势，都能提前两周报出这场故障。

这件事把我们组里争论了很久的一个问题钉死了：人工巡检是“点检”，它的设计目标就不是发现慢性病。三个天花板绕不过去：

1. 覆盖面靠抽样。一个省级核心网，AMF/SMF/UPF/PCF/UDM/NRF加上EPC和IMS，700多个网元、几千个虚拟机。人工巡检实际就是抽二三十个关键设备看看灯，覆盖率三成不到。
2. 频率一天一次。慢性病恰恰发生在两次巡检之间。夜里两点的磁盘爬坡，早八点的巡检永远看不见过程。
3. 经验存在人脑里。哪块盘该多少天清一次、哪个资源池月末话务有什么脾气，都在几个老师傅脑子里。人休假，经验跟着休假。

所以我们的结论是：不是把现有巡检表电子化，而是按“自动化能做什么”把体检单重写一遍。

二、先把体检单重写：七大类六十四项

很多团队的巡检自动化，第一步就走歪了：把人工巡检表原样搬进脚本。人工巡检表是为“人的注意力”设计的，天生保守；机器不怕多查，怕查错方向。我们重新梳理后的体检单分成七大类64项，核心变化是把“一致性核对”这类人工根本做不了的项加了进去：

三点设计原则说明一下。

第一，能用“关系”判定的，不用“门限”判定。门限需要拍数字，拍低了告警洪水，拍高了形同虚设。而“NRF里登记的网元集合”必须等于“资产台账里的在网集合”，“POOL内各AMF的TAC列表”必须完全一致——这类判定不需要门限，只有相等和不相等，误报率天然是零。

第二，每项标注数据来源和采集代价。64项里只有12项需要登录网元取数，其余全部走北向接口和现成话统文件。这是刻意为之：巡检系统对现网的侵入性必须压到最低，改造初期如果因为采数把现网搞出问题，这个项目就死了。

第三，检查项必须带“病例字段”。每一项都要回答：历史上它抓到过什么？说不出来的项，一个季度后清掉。这份清单才会越用越准，而不是越攒越长。

三、工具链怎么搭：四层架构与开源选型

架构上我们没有买大平台，用现成开源件加自研胶水，半年上线。整体分四层：

flowchart TD
    A["网元层<br/>核心网与无线700余个网元"] --> B["采集层<br/>SNMP/NETCONF/REST/SSH"]
    B --> C["总线层<br/>Kafka削峰"]
    C --> D["数据层<br/>时序库存指标"]
    D --> E["分析层"]
    E --> F["规则引擎<br/>门限与一致性核对"]
    E --> G["趋势预测<br/>斜率与同比环比"]
    E --> H["核对模块<br/>双源交叉比对"]
    F --> I["处置层"]
    G --> I
    H --> I
    I --> J["人工工单<br/>高风险变更"]
    I --> K["自动处置<br/>仅低风险项"]
    I --> L["日报与大屏"]

采集层走四条通道：SNMP取资源类指标，NETCONF/RESTful取配置类数据，管理接口拉性能文件，少数老设备只能SSH跑命令。原则只有一条：只读，不写。所有采集账号权限裁剪到最小，每条通道带超时和熔断——某类采集连续失败即挂起该类，绝不在话务高峰对网元发起重试风暴。

总线与数据层用Kafka做削峰，指标进时序库（选型是Prometheus体系，它的拉模型和告警规则语法是公开文档最全的，团队上手最快，官方文档在 prometheus.io），配置快照进对象存储按天留存——快照这东西平时占地方，出事时就是“案发现场”。

分析层是三套引擎并行：规则引擎跑门限和一致性核对；趋势引擎算斜率和同比环比，负责“将病”；核对模块做双源交叉。分析结果统一进处置层，按风险分流：高风险出工单走人，低风险（清临时文件、切备用采集通道）允许自动执行，全部留痕。

看板用Grafana搭，但我们的经验是：巡检系统最重要的输出不是大屏，是每天早上七点自动发出的那封“体检日报”——异常项置顶，正常项一行带过。值班员只读日报，大屏是给汇报用的。

这里要对齐一下业界的参照系。ETSI在2019年发布的ZSM参考架构（GS ZSM 002）把管理自动化拆成若干管理域，每个域内跑自己的闭环，域间再做编排；TM Forum的自智网络白皮书把网络运维自动化分成L0到L4五级（2019年白皮书《Autonomous Networks: Empowering Digital Transformation for Intelligent Operating》提出框架，后续版本持续细化，中国运营商常引用其分级）。我们这套东西，单看“检查”这一环到了L3，但整个运维闭环算总账，L2——这个差距后面会讲。

四、门限会撒谎：三个“将病”病例

体检单和工具链都就位后，真正值钱的发现全来自“趋势”和“核对”这两个引擎。挑三个病例。

病例一：日志盘的19天慢病

就是开头那场话单延迟的原型复现。系统上线第二个月，趋势引擎报了一条预告：某AMF资源池计费服务器日志盘使用率89%，日增速1.5个百分点，预测11天后写满，恰逢月末出账高峰。工单派下去，工程师上去一看：三个月前一次版本升级留下的调试日志没关，加上一批陈旧的核心转储文件。清理加临时扩容一个维护窗口搞定，使用率回落到41%。

有意思的是预测精度：按斜率外推“第11天写满”，实际是第12天触顶，误差一天。对慢性病来说，斜率比任何静态门限都诚实。

timeline
    title 一场慢病的前置处置
    第1天 : 趋势引擎报出日志盘89%
    第3天 : 预测11天后写满并撞上出账高峰
    第5天 : 定位陈旧转储与调试日志
    第6天 : 维护窗口完成清理与扩容
    第7天 : 使用率回落至41%

病例二：注册成功率的温水煮青蛙

某地市注册成功率从99.1%两周内缓降到98.4%，单日从未跌破98%这条告警门限，网管一声不吭。趋势引擎按“7日均值环比降幅超0.3个百分点”触发核查。拉信令发现，异常来自一批物联网终端：固件缺陷导致周期性TAU反复重发，该号段信令量涨了18%，注册信令被拖慢、超时率抬升。协调卡商远程升级固件后，指标三天回稳。

这个病例的教训是：KPI门限本质上是“用户开始投诉”的门限。98%听着只降了0.7个百分点，但它对应的都是真实用户重试。等跌破门限再动手，面对的就是投诉风暴了。

病例三：TAC列表的七条漂移

配置一致性核对上线第一周就抓到：POOL内两套AMF的TAC列表差了7条——某新开商圈的三个基站被规划进了资源池，但只在一套AMF上加了数据。表现是商圈用户偶发注册变慢，重选到另一套AMF才成功。这种故障靠人工巡检十年也查不出来：两套设备各自看自己都“正常”，只有把两份配置摆在一起比对，差异才存在。处置只用了十分钟补数据，但随后全量核对又扫出4处历史漂移，全部清零。

五、别迷信全自动：人机划界的两条线

平台跑顺之后，最容易犯的错是头脑发热往“全自动”冲。我们的划界经验是两条线。

第一条线：自动“看”和“判”大胆做，自动“动”只做低风险。采集、比对、趋势计算，100%交给机器——机器看数比人全、比人勤、比人稳定。但所有涉及网元重启、参数修改、版本动作的处置，一律工单加双人复核。ETSI ZSM的闭环架构和TM Forum的分级给的是方向，不是工期表：分级里L4的“高度自智”含义是网络能自治并自我进化，我们很清楚自己账面上是L2，单项巡检到L3。挂横幅没有意义，把每一项巡检做成“可度量、可闭环、可移交”的最小闭环，级别自然往上爬。

第二条线：巡检脚本本身也是生产资产。入库、评审、变更走流程、可回滚，和网元配置同等待遇。原因是吃过亏：早期有个采集脚本依赖某台跳板机上的密钥，跳板机迁移后采集断了42个小时，全组没人发现——巡检系统自己病了，没人给它巡检。后来加了一条铁律：采集通道自身的心跳必须在被巡检范围内，采集中断本身就是最高优先级告警。

六、成效与两条负面教训

跑了四个季度，账面变化：

• 例行巡检耗时从每天约2小时压到8分钟（机器跑数）加15分钟（人读日报）；
• 巡检覆盖率从不足30%的抽样变成700余网元全量，64项全跑；
• 故障前置发现占比（在用户投诉前发现并处置）从改造前的约15%升到58%，口径是季度复盘逐单认定；
• 证书和许可类有效期预警实现了零过期。

两条负面教训比成绩单更值钱。

教训一：告警洪水反噬。上线初期阈值拍得太敏感，最多的一天产出1200条巡检告警，值班员第一周还看，第二周整组屏蔽——差点把真告警一起埋了。整改花了两个月：门限尽量换成一致性判定和斜率判定，必须用门限的按设备基线自学习，再按“可拖延性”分三级收敛。现在日均巡检告警稳定在两位数，条条有人接。记住这个比值：巡检系统的公信力，是值班员的注意力，告警洪水烧的就是它。

教训二：别把“查出来的问题”当成巡检系统的KPI。季度考核曾把“发现问题数”设为指标，结果团队开始倾向于保留低价值的敏感阈值来凑数。后来改成考核“前置发现占比”和“误报率”两个数，方向才扭回来。度量什么，就会得到什么。

结语

回到开头那块写满的磁盘。它不是被某次天才排查救的，是被一条斜率预报救的——而这只是700个网元、64个检查项里最不起眼的一项。巡检自动化的终点从来不是“无人值守”四个字，而是把人从“看数”里解放出来，去干机器干不了的事：判断哪条预告值得追、哪个漂移背后有故事、哪次变更该按住不放。TM Forum把L4画在白皮书里，我们把它拆在每天早上七点那封日报里——一天清掉几个“将病”，级别就是这么一级一级长出来的。

参考来源

1. TM Forum Autonomous Networks（自智网络项目页） — 自智网络L0–L4分级框架与系列白皮书主入口，本文第五节人机分级的参照系
2. ETSI ZSM：Zero-touch service Management — 零接触服务管理工作组页面，GS ZSM 002参考架构（2019年发布）提出按域拆分的闭环自动化
3. Prometheus 官方文档 — 本文工具链时序存储与告警选型的依据，拉模型与规则语法文档
4. Grafana OSS — 巡检看板与体检日报的可视化组件官方页面
5. 3GPP Portal（SA5管理系列，TS 32.101、TS 28.541等） — 电信管理原则与5G网络资源模型相关规格的官方查询入口

本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。