维护人员既要做分析、又要去操作，可能最后分析没做好、操作无法落实。维护人员就是解决设备问题。现有的运维机制是：设备产生告警、监控收告警派工单、维护人员处理工单、监控核实回单质量完成闭环。看似多么完美的管理流程。实际上，维护人员在看到告警的时候可能无法准确定位问题根因。这就对维护人员的技能水平提出了较高的要求。只有具有较高的技能水平、多年的维护经验，才能够具有从虚虚实实的告警信息中分析出关键问题点。这仅仅是做了第一步。其次还要具备处理问题的能力。这个问题该如何处理?可能需要更换板卡的能力、可能需要联系承载网、周边网元协同处理等等的协同能力。

实际上，人员真实技能和实际工作技能需求的缺口始终存在。这就导致一个大家都不想看到的但又是实际存在情况：有时我们又没做好故障分析、也没做好故障处理。

维护人员故障处理能力的提升需要大量的案例来支撑，而实际上核心网没有大量的故障案例来支撑大批的维护人员提升能力。这就导致：维护人员间的故障处理能力始终不是均衡的。这就好比医生看病一样，医生的经验来源于大量的临床经验。我们之所以相信老中医、老医生，是因为这些医生处置过大量的病例(=故障案例)，处置这些病例的同时也提升了医生自身的能力和水平。如果仅仅是依靠看书学习病例，是无法显著提升医生的水平的。同样的道理，维护工作也类似医生，既需要学习也需要案例来支撑能力提升。这就是为什么一些核心网的前辈们所说的：培养一个成熟的核心网人员至少需要3年以上的原因。

现在的设备监控模式是：设备产生告警然后发送给厂家OMC，厂家OMC再发送给集中故障系统，集中故障系统再派EOMS工单给维护人员(监控人员同步人工通知部分告警情况。)这个监控模式不仅仅适用于核心网设备，也应用于所有无线、传输、动力等专业的设备。不仅仅适用于网络管理中心，也应用于所有的分公司。这个模式通过多年的运营已经暴露出至少三大主要问题：

• 第一大问题：故障通知存在时延问题

核心网不发生故障是难以实现的，核心网的维护目标应该定位成：不发生重大故障。重大故障不是从0瞬间突变成重大故障，而是从0变成小故障，再发展成大故障。在故障监管上，核心网需要告警通知的时延足够短，多短?我认为15分钟以内就是目标。而实际上，现有的模式下部分告警时延已经超过1小时甚至更多。

• 第二大问题：告警没有聚类分析，监管无法准确定位到根因

举一个例子：所有的核心网设备都会上承载网，就是和CE相连。如果CE出了点动静必然导致和它相连的设备出现故障告警。不同类型的核心网设备同时出故障的几率相对不大，所以这种情况下，应该同步判断CE是否有故障，同步通知承载网专业。简而言之，就是故障根因定位(尤其是跨专业的故障根因定位)在当前运维体系下至少是缺失的。这就导致监控人员和专业人员在判断故障的标准不一致，监控人员判断故障只有告警，而专业人员在故障判断上会有多种手段。这就导致出现了监控只有通知功能，无法发挥“指挥调度”功能。

• 第三大问题：监管系统自身的故障将导致告警通知体系失灵

所以的设备都有故障率，区别只在于故障率的大小而已!那么，我们的故障监控体系会不会失灵呢?监管体系是一个依靠多专业、多人员配合的体系。多专业配合：涉及核心网设备的告警准确上报、厂家网管的稳定运行、集中故障系统软\硬件的稳定运行等大量异厂家的配合问题。还存在中间环节的升级改造等情况。任何一个环节的失灵都将导致监控系统的失灵。

我举一个例子：在一个周六的早上，有领导问我，为什么核心网的故障数量增长这么多?(指每天的监控日报)这个事情我从接到任务开始一直弄到下午4点，才做完全部分析。领导的疑问在机制上至少反映了三方面问题：

• 问题1：管理人员视图和维护人员视图不一致

这是什么意思呢?这个监控日报是没有发到维护人员手上的。维护人员没有掌握这个生产资料，这就会导致管理人员的要求和维护人员的工作没办法统一。简单的说，领导有这个信息，维护人员没这个信息，维护人员可能就没有去关注。

• 问题2：管理视图和维护视图的定位出现了偏差

我并非对日报本身持否定意见。我是把日报定位成管理视图，就是领导看到的或者需要知道的信息。领导看到的信息应该是各级信息分析处理后的汇总。管理视图的定位到底是用于驱动工作的实施还是用于获取信息?就监控日报而言，我觉得这个管理视图更多的应该是用于信息总结。它还缺少一个维护人员视图和监控日报管理视图相结合用于驱动工作实施。简单的说：监控日报现在的分析只是分析专业告警总量，没有就各类设备、各台设备的告警量进行统计分析。需要对各类设备、每台设备的告警量进行分析，这些分析将用于三级经理、主管层级的管理人员实施管理，同时这个维护视图还需要维护人员用于管理设备。而到了更高级别的领导，他们的管理视图是具备信息下钻的能力：既能看总量，又能看各专业的详细分析。简而言之，管理视图可以直接看到具体某类、某台设备的告警数量、类型变化以及变化趋势，能够直接看到责任人。而这个工作不需要人来做，而应该由系统自动完成。这就是最理想的情况：管理者通过管理界面可以获取各类信息，能够有一览众山小、一切尽在掌握的感觉。维护人员通过维护界面可以获取处理问题的必要信息，越是分析到末梢越好。

最后用一段来自总部对当前运维囧境的总结：

网络的平稳运行仍需依靠运维人员的维护操作，无法做到即插即用、无法做到自治自愈。流程没有端到端打通、数据和系统割裂，完成一个或一类任务需要跨系统，没有统一完整的视图。规则主要靠人的经验，支撑手段靠数据驱动、算法驱动、AI驱动的程度不足。数据自动采集、自动呈现手段能力不足，大量宝贵的人力资源消耗的数据收集、整理、反馈的工作中。

面向5G时代，核心网的稳定性更加重要，如何实现高可靠的设备稳定性，这对网络运维提出了更高的要求。我们不是生存在刀耕火种的年代，现代化的网络运维工作必须依靠智能化的工具和系统来获取运维信息、提升运维效率，同时具备自动发现问题、自动定位问题、自动解决问题的能力，这就是我们常说的“智慧运维”。

原文来自：

本文地址：//gulass.cn/cero-network.html编辑：roc_guo，审核员：清蒸github

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：