用户体验监控系统浅介论文

用户体验监控系统浅介论文（共4篇）

用户体验监控系统浅介论文 篇1

“业务正在不断的驱动着IT运维管理朝着以应用为中心发展, 与此同时, 应用也变得越来越难于管理。”—Gartner

目前, 国内电力行业正处于高速发展阶段, 业务量与日剧增。由于各种关键业务和应用都被承载在基础架构、WEB应用、中间件和数据库上, 使得业务的复杂性和维护难度大幅增加。如何对这些复杂的业务系统进行有效监控和风险防范, 保障关键业务的高性能和高可用性, 以及如何对现有的运维流程进行优化, 不断提升管理和运维水平已经成为目前数据中心急需探索和解决的重要问题。

1 河南电力现状

河南电力经过多年的努力, IT运维管理水平有了长足的发展。但是通过对近几年河南电力突发事件应急处置过程及案例进行分析和思考, 可以看出在应用性能监控管理和突发事件应急处置方面仍然存在可以提升的空间:

1.1 缺少对用户真实体验的监控

对于用户的真实体验缺少系统的监控和数据支撑。河南电力现阶段的信息化建设, 投入了很大精力在IT系统的建设和对IT基础架构的维护上, 但即使部署了最先进的基础架构, 并不间断地监控PC、网络、服务器、数据库等组件的性能, 客户还是会偶尔抱怨系统运行缓慢。

1.2 信息高度不对称、突发事件处置效率仍需要提升

由于信息系统复杂, 系统间关联关系强, 涉及环节众多, 而监控系统相对独立, 一旦出现问题, 网络、系统、数据库、应用分头查找原因, 各自为战, 事件处置缺少明确方向, 一方面需要付出较多的沟通和定位问题的时间成本, 另一方面导致事件处理时间过长, 影响被放大。

1.3 故障原因定位存在取证难、效率低, 甚至互相推诿的问题

由于缺少全面的监控, 故障事后分析诊断条件不足, 缺少故障现场溯源数据, 大多情况下只能对设备日志、交易日志等进行分析, 很难拿出有力的证据进行取证, 另外即使有故障现场数据, 问题分析人员面对海量的数据问题分析定位仍需要消耗较长的时间。

2 应用性能管理系统的设计与实现

2.1 系统设计

2.1.1 系统设计原则

系统总体设计需要满足未来的发展需要, 既要安全可靠, 不影响现有的网络和业务, 又要具有一定的先进性。在架构设计和功能模块的划分上, 应充分的分析和整合项目的总体需求和预期的目标, 尽量遵循高内聚、低耦合的设计原则, 既要保证各个模块的独立性, 也要保证模块间联系的简单性和易扩展性。

2.1.2 系统架构设计

根据河南电力信息系统业务数量众多、个别业务系统的访问关系又非常复杂的特点, 本文提出一种以网络和应用性能监控分析平台为核心, 利用网络镜像数据包对网络和关键业务的性能进行实时监控与分析的应用性能管理系统。通过先进的智能告警技术, 将告警信息发送给网管平台进行统一的管理和展现。网络运维人员, 利用监控与分析平台对出现的故障进行快速的分析和定位。如图1所示。

2.1.3 系统功能设计

根据河南省电力公司的网络环境的实际情况, 利用多台流量汇聚设备, 对多个机房、多个监控点的流量进行采集和汇聚, 对流量进行分析、过滤处理后, 按照一定的原则和要求, 将过滤处理后的“干净的”流量输送给业务可视化监控分析平台。如图2所示。

2.1.4 监控指标设计

根据对应用系统性格的分析需要, 系统的监控指标主要分为以下4种:

(1) 网络流量指标:反映业务的网络流量及网络传输效率, 包括丢包、包重传率、往返时间、重传延时等;

(2) 网络性能指标:反映网络传输质量, 包括包吞吐量、包流量、实际吞吐量、数据包净荷等;

(3) 应用性能指标:反映应用性能, 包括交互数、重置率、数据传输时间、响应时间等;

(4) 页面性能指标:反映HTTP访问性能和访问效率, 用户体验, 包括服务器重置率、连接数、连接失败率、连接时间、连接请求数等;

2.1.5 告警规则设计

基于监控设备性能的考量, 从监控指标中甄选出最具代表性, 最能及时反映业务运行质量的指标作为告警监控指标, 设置相应的告警阀值, 以下为系统选取的告警指标:

(1) 服务器响应时间 (Server Response Time) 。

(2) 服务器重置率 (Server Reset Rate) 。

(3) 连接失败率 (Connections Failed Rate) 。

(4) 页面时间 (Page Time) 。

(5) HTTP500错误 (%) 。

2.1.6 数据存储设计

为了能够提供故障现场数据以及数据报表分析功能, 系统需要提供强大的数据存储能力。如图3所示, 系统的数据存储区域分成2部分:

(1) 原始网络数据:采用先进先出的循环滚动式缓冲存储区, 存储所有镜像的网络流量, 提供故障现场数据源。

(2) 归档数据区:与告警有关的信息包在滚存内被打上快照标记, 被复制到归档区, 提供报表分析数据源。

3 系统实施效果

3.1 系统部署

根据河南电力的网络情况, 系统部署采用了两台流量聚合设备和一台数据采集设备, 完成对所有应用系统流量数据的采集和分析, 系统部署图如图4所示。

3.2 应用效果

通过基于用户体现的应用性能管理系统的实施, 在河南电力搭建了统一的网络及应用性能可视化平台, 使基于业务的网络及性能可视化管理在河南电力实现了真正的落地, 在以下几方面取得了良好的实际成果和效果。

3.2.1 在基于业务的监控方面

实现了对业务全面的、精细的、多维度的、可视化监控。既监控了终端用户访问业务的用户体验情况, 又监控了各供电局访问业务的整体性能情况;既监控了业务在前端的平均性能情况, 又监控了业务在后端各个负载均衡、防火墙、服务器等关键节点的性能情况;既监控了业务的网络流量、带宽占用情况, 又监控了业务的网络性能、应用性能情况;使得河南电力对全网所有关键业务“看”的更加全面和清晰;对业务网络流量和性能的统计分析更加便捷和准确;对业务故障问题的分析和定位更加快速和明确。

3.2.2 在业务梳理与主动运维方面

在平台的建设过程中, 总结了一套完整的业务梳理流程, 使得对业务的梳理更加快捷, 业务需求更加明确, 业务访问关系更加准确。同时基于用户体现的应用性能管理系统建立了对业务的预警和告警机制, 形成了问题发现、问题快速分析与定位、问题处理三位一体的主动运维流程。大幅提高了对业务故障的预警能力 (业务故障预警率80%以上) , 缩短了问题发现的时间 (从问题出现到运维人员发现的时间间隔在3-5分钟左右) , 加快了问题分析定位的速度 (对问题的分析和初步定位基本在5-8分钟左右) 。

3.2.3 数据分析方面

系统以分布式存储的方式存储了海量的全网业务流量的原始数据、性能统计数据、故障溯源数据, 通过将网络及应用性能可视化平台集成到大数据环境中, 能够有效消除性能低下、可用性不足及可扩展性不佳所带来的风险和成本, 为基于大数据的数据分析、数据挖掘、云计算等研究提供了基础条件。

4 结束语

应用性能管理不仅仅是包含从网络层面进行分析的性能管理, 完善的应用性能体系还需要很长一段进间的研究和实践, 但用我们可以先整合现有的应用性能监控平台, 并制定详细的应用性能监控体系方案, 逐步提高河南电力应用性能管理水平, 提升信息科技风险管理水平。

摘要：本文在详细分析了河南省电力公司信息系统运维现状的基础上, 设计了一种新的基于用户体验的应用性能管理系统, 借助网络系统承载所有业务流量的先天优势, 利用流量镜像采集技术对网络流量进行可视化和精细化监控与分析, 面向业务, 从最终用户体验出发, 对河南电力关键业务系统网络流量和应用性能进行实时监控, 通过可视化的业务性能和网络性能关键监控指标, 对影响业务的相关性能问题进行主动预警, 快速识别潜在的风险。

关键词：应用性能管理,可视化,用户体验

参考文献

[1] (美) W.Richard Stevens.TCP/IP Illustarated Volume1:The Protocols[M].北京:机械工业出版社, 2005.

[2] (美) David Gourley, Brian Totty.HTTP:The Definitive Guard[M].北京:人民邮电出版社, 2010.

[3]A.Biswas and P.Sinha, "Efficient real-time Linux interface for PCI devices:A study on hardening a Network Intrusion Detection System, "in 5th System Administration and Network Engineering Conference.Aula Congress Centre, Delft, The Netherlands, 2006.

用户体验监控系统浅介论文 篇2

随着现代社会的发展，信息行业以不可预估的速度进行了更新。广大消费者对人性化的理解更加深刻，因此以用户体验为核心进行产品设计成为各个行业发展的必然选择。作为信息媒介交流手段的最基本组成要素，将复杂抽象的信息流转化成可视化的直观界面，利用简约式的交互界面设计实现用户最大化的使用体验是现代软件开发行业的最重要目的。现在从设计人员到体验用户都在谈论情怀、争辩格调。强调体验，因而将交互界面设计进行定位，围绕产品需求和服务目标对android系统进行改进，是实现android系统发展和以android系统为基础系统的手机行业繁荣进步的重要手段。

可视化交互界面

1. android系统现状简析

android系统作为谷歌旗下的一款使用于移动设备的开放源代码操作系统，自android系统应用于智能手机以来，广泛受到用户的欢迎。截止到2011年5月份，android用户的市场占有率以绝对性的优势超越了塞班系统，实现了智能应用软件的全覆盖（除苹果公司iOS系统外）。有数据统计，android系统出现前五年，全世界设备使用量就达到了10亿台，占据了约82%的市场份额，庞大的用户群体对于进一步提升用户体验提供了强大的调研基础。由此来看，android系统有着极为广阔的市场需求。然而软件设计开发需要不可预估的资金支持，android系统的运营收入远不及ios，这使得android在实际运营和系统设计改进中显示出力不从心的状态，从而避其锋芒的选择对现有系统进行细节修补。无疑此举可以改善其现处的尴尬环境，但不利于长期的发展。

2.可视化交互界面简介

可视化界面设计是面向用户对象提出的新型设计理念，旨在通过程序设计实现最大程度化的人机互动，有机的将用户需求和数据处理进行融合，以实现现代产品中的人文关怀。

3.可视化交互界面优势

众所周知，人类对于直观简洁画面的感知能力要远远超过其他方面。动画是软件系统中最容易吸引用户注意和帮助其理解的手段，用户的需求输入，通过数据转换分析，之后转化成直观信息输出，利用对信息的压缩将专业知识进行转化，从而可以满足不同水平的用户需求。

交互界面设计方式

纵览成功的设计案例，都有一个共同的特点，就是他们的服务设计目标非常的明确，在产品上可以直观的展现出专注、极致和解决出现的核心问题的魅力。这些成绩的取得除了资金和技术作为背后支撑，良好的设计过程也是必不可少的重要环节。利用有限的资源和能力给产品的特定群体提供专注服务远比给广泛人群提供低标准的服务更能得到市场环境中的优势地位。在设计环节，“用户画像”作为一种非常实用的设计理念，对android系统的交互界面设计可以提供较大的帮助和启发

1.定性用户需求

在进行产品设计之前，全面而具有代表性的用户调研环节是必不可少的，Google Buzz在这方面做得很好。设计人员有着自己对产品操作使用的认知理解，因此在设计环节中必然会引入他们的主观意识，这在一定程度上草率的代表了用户需求。代替用户发声是设计环节最常见，同时也是最忌讳的现象之一，设计人员从专业角度认为的简洁交互不一定适用于用户的理解和期望，最终导致设计者全身心的投入设计并不能得到用户的认可。因此，小心的找准界面设计的立足点和发力点，从用户角度出发对设计目标进行剖析，是设计团队实现用户“真需求”的最重要方向。

2.定量用户画像

在实际的产品设计流程中，每个环节都有外界因素的干扰。android系统作为全球使用数量最多的移动设备操作系统，不同人群的需求更是多种多样。因此在设计过程中必须对产品进行准确定位，利用大数据分析得出最有市场的需求进行交互设计。当前环境下android的缺陷就是追求全面满足用户而针对性不强，从而造成了服务设计的很多缺失。利用数据对每个设计环节进行干预，修正设计环节不具有针对性的错误观念，将会使android的市场更加广大。

3.模拟现实操作性

产品的诞生必不可少的需要进行实践。交互界面设计的目标就是为用户提供更加人性化的操作方式。因此产品在进入市场流通之前，需要将用户画像和设计产品进行逐步比对，减少实际应用环节中的漏洞修补。这样不仅可以减少后期的成本消耗，还可以增强产品的良好声誉，进而达到设计的最终目的。

结语：在信息化程度高度发展的今天，人们对于移动通信设备的依赖程度不断加深。“人性化”作为各个行业进行产品开发创造的新导向，作为拥有全世界最大用户量的android操作系统，要及时的把握住现代软件创新的方向标，努力建设拥有标志性和创新性的用户体验产品，在人机交互环节加强各项投入，是实现android系统背景下新交互界面创新发展的最重要手段。

（作者单位：重庆工商职业学院）

用户体验监控系统浅介论文 篇3

Compuware公司关于移动互联网使用习惯的报告显示, 71%移动网络用户希望移动网络速度超过PC网络, 多数移动用户可等待网站或应用的最长加载时间是5s, 有74%用户表示如果移动网站无法在5s内加载完毕他们就会退出。也有调查显示, 47%的用户期望网页的加载速度在2s或更少, 40%的人在网页加载速度超过3s便会放弃。根据Nielsen Norman Group的研究结果, 如果移动网页的加载时间超过1秒, 大多数用户就不愿再停留在该页面上了。以往的研究主要针对计算机的网页加载, 对于用户可接受的时间, 每个研究都有不同的说法, Nielsen (1997) [1]提倡限制在10s, Zona Research (1999) [2]则建议8s, Hoxmeier (2000) [3]的研究得出12s的延迟会造成满意度降低, Galletta (2002) [4]等发现, 用户的行为意图及兴趣降低是在4s。那么用户对于进入手机程序及安装手机程序的等待时间是多久呢?

Compuware公司在手机APP启动时间应该多快的调查中显示, 31%的人期望的启动时间是2s, 期望1s、3s、4s及更多时间的都约占20%。CA软件公司的调查显示, 对于应用程序, 用户关心的三个主要特征之一是快速加载, 68%的用户表示, 他们可接受的加载时间少于6秒, 近一半的受访者表示他们可接受的加载时间少于三秒。还有调查显示, 用户能够忍受的最长等待时间大约在6~8秒, 8秒是一个临界值, 如果加载时间在8s以上, 用户可能会选择离开该页面。

在安装手机程序时, 如果安装时间过长, 可能会使用户感到不耐烦甚至放弃安装, 那么多长的安装时间合适, 用户能够容忍的最长安装时间是多少?总的来说, 对于手机程序的进入时间、安装时间尚无明确定论。因此本研究旨在探究人们在进入和安装手机程序时所能容忍的最长等待时间。

二、研究方法

(一) 参加测试用户

本研究总共招募了31名大学生手机用户, 其中男生15人, 女生16人, 均为在校大学生, 年龄在18~26岁之间, 均为智能手机使用者。

(二) 研究装置与软件

研究在3×5m2大小的安静实验室内进行。实验程序中应用的材料分别从真实的手机软件 (翼支付、天翼导航、天翼阅读、天翼Wi Fi、天翼视讯) 中截取, 组成5个应用情境, 其中1个情境用于练习, 其余4个情境用于正式实验。实验程序由JAVA语言编制。

研究设备:触摸屏手机一台 (三星note 4, 5.7英寸, 分辨率2560×1440) , 实验过程中, 手机屏幕亮度调到最大, 关闭所有无关软件。

(三) 研究变量及设计

研究的因变量为用户可忍耐的最长等待时间, 包括程序进入等待时间和程序安装等待时间, 均由原型程序自动记录。其中, 程序进入等待时间包括无反馈条件下的手机程序进入等待时间和有反馈条件下的手机程序进入等待时间;安装程序等待时间包括无反馈条件下的手机程序安装时间和有反馈条件下的手机程序安装时间。

(四) 研究流程

最长可接受手机程序进入时间研究中, 当出现无反馈程序进入及有反馈程序进入界面时, 要求用户尽可能等待, 如果用户觉得程序响应时间太长而无法等待, 可按界面任意位置进入下一界面。以此任务来探究人们所能容忍的手机进入程序的最长等待时间。其中:

无反馈条件下的手机程序进入等待时间指用户打开程序到点击无反馈程序进入界面任意位置的时间间隔。有反馈条件下的手机程序进入等待时间指用户点击无反馈程序进入界面任意位置到点击有反馈程序进入界面任意位置的时间间隔。

核心部分任务流程图如图1:

在最长可接受手机程序安装时间研究中, 当出现无反馈正在安装 (无进度条) 及有反馈正在安装 (有进度条呈现) 界面时, 要求用户尽可能等待, 如果用户觉得程序响应时间太长而无法等待, 可按界面任意位置进入下一界面。以此任务来探究人们所能容忍的手机安装程序的最长等待时间。其中:

无反馈条件下的手机程序安装时间指用户点击“安装”到点击无反馈正在安装界面任意位置的时间间隔。有反馈条件下的手机程序安装时间指用户点击无反馈正在安装界面任意位置到点击有反馈正在安装界面任意位置的时间间隔。

核心部分任务流程图如图2:

在整个研究过程中, 用户尽可能按以往习惯持/扶手机, 并保持一手持/扶, 一手操作任务。

三、结果

(一) 手机程序打开时间结果

实验结果由SPSS20.0软件包处理。在统计用户的等待时间数据时, 为了保证用户反应数据的相对稳定性, 在统计用户的等待时间数据时, 依据三个标准差原则, 12、26、27号用户大部分数据超过3个标准差, 故将他们的数据剔除, 9号用户有部分数据超过3个标准差, 故将他超过3个标准差的数据用平均值替换。以下分析针对28名用户的数据。

对试次 (试次一、试次二、试次三、试次四) 和实验顺序 (先实验一再实验二、先实验二再实验一) 的进入程序无反馈等待时间结果进行重复测量方差分析, 发现试次的主效应不显著, F (3, 2 4) =0.8 8 9, p=0.4 6 1>0.0 5;顺序的主效应不显著, F (1, 26) =0.000, p=0.988>0.05;试次和顺序的交互效应不显著, F (3, 24) =0.982, p=0.418>0.05。说明实验顺序对用户无影响, 用户内设计可行, 其次, 各实验试次无差异, 故可将每个用户的4个试次平均。

对试次 (试次一、试次二、试次三、试次四) 和实验顺序 (先实验一再实验二、先实验二再实验一) 的进入程序有反馈等待时间结果进行重复测量方差分析, 发现试次的主效应不显著, F (3, 2 4) =1.0 7 0, p=0.3 8 1>0.0 5;顺序的主效应不显著, F (1, 26) =0.525, p=0.475>0.05;试次和顺序的交互效应不显著, F (3, 24) =1.028, p=0.398>0.05。说明实验顺序对用户无影响, 用户内设计可行, 其次, 各实验试次无差异, 故可将每个用户的4个试次平均。

由表1可以看出, 对于进入程序的最长等待时间, 在无反馈等待的情况下为3802ms, 在有反馈等待的情况下为5263ms。

对无反馈及有反馈等待的时间进行配对t检验, 发现有反馈情况下等待时间显著长于无反馈情况, t (27) =-4.345, p<0.001。由此可见, 当等待不可避免时, 采取有效的反馈 (如:通过增加生动有趣的进入画面) 可显著降低用户的心理等待时间, 从而增加其可容忍的最长等待时间。

(二) 手机程序安装时间结果

依据三个标准差原则, 27号用户大部分数据超过3个标准差, 故将其剔除, 11、12、24、26号用户有部分数据超过3个标准差, 故将它们超过3个标准差的数据用平均值替换。以下分析针对30名用户的数据。

对试次 (试次一、试次二、试次三、试次四) 和实验顺序 (先实验一再实验二、先实验二再实验一) 的安装无反馈等待时间结果进行重复测量方差分析, 发现试次的主效应不显著, F (3, 2 6) =1.4 4 5, p=0.2 5 3>0.0 5;顺序的主效应不显著, F (1, 28) =3.872, p=0.059>0.05;试次和顺序的交互效应不显著, F (3, 26) =1.662, p=0.200>0.05。说明实验顺序对用户无影响, 用户内设计可行, 其次, 各实验试次无差异, 故可将每个用户的4个试次平均。

对试次 (试次一、试次二、试次三、试次四) 和实验顺序 (先实验一再实验二、先实验二再实验一) 的安装有反馈等待时间结果进行重复测量方差分析, 发现试次的主效应不显著, F (3, 8 4) =1.3 6 4, p=0.2 6 0>0.0 5;顺序的主效应显著, F (1, 28) =4.699, p=0.039<0.05;试次和顺序的交互效应不显著, F (3, 84) =1.886, p=0.138>0.05。说明各实验试次无差异, 可将每个用户的4个试次平均。

由表2可以看出, 对于安装程序的最长等待时间, 在无反馈等待的情况下为8287ms, 在有反馈等待的情况下为17343ms。

对无反馈及有反馈等待的时间进行配对t检验, 发现有反馈情况下等待时间显著长于无反馈情况, t=-6.489, df=29, p<0.001。由此可见, 当等待不可避免时, 采取有效的反馈 (如:通过增加有趣的进度条) 可显著降低用户的心理等待时间, 从而增加其可容忍的最长等待时间。

四、结论

综上所述, 本研究得出以下结论::

对于进入程序的最长等待时间, 在无反馈等待的情况下为3802ms, 在有反馈等待的情况下为5263ms。有反馈情况下等待时间显著长于无反馈情况。

对于安装程序的最长等待时间, 在无反馈等待的情况下为8287ms, 在有反馈等待的情况下为17343ms。有反馈情况下等待时间显著长于无反馈情况。

参考文献

[1]Nielsen, J.The need for speed[R].Jakob Nielsen’s Alertbox, 1997.

[2]Zona.Research:The Need for Speed[R], Zona Market Bulletin, 1999.

[3]Hoxmeier, J.A.and Dicesare, C..System response time and user satisfaction:an experimental study of browser-based applications[A].Proceedings of the Americas Conference on Information Systems[C], 2000, 140-145.

协同故障智能定位与处理系统浅介 篇4

当前, 移动运营商在运营能力获得长足发展的同时, 也面临着市场环境和技术架构的急剧变化。业务保障要求不断提高和重要设备容灾安全水平较低的矛盾日渐突出, 单个设备容量不断增加, 单个设备故障的影响范围也越来越大。用户对网络的安全性要求越来越高, 任何一次网络故障都有可能演变成社会事件。

从信息通信技术的发展趋势看, 对于重要的核心数据与设备, 都需要提供高等级的故障恢复能力, 使单点故障发生时可以迅速恢复正常, 缩短业务中断时间, 因此, 急需能够使各种资源协同工作的平台, 使运维工作显性化、简单化、及时化, 实现运维工作的智能化端到端管理。

2 功能介绍

建设协同工作平台, 面向管理者、技术人员提供全面系统的故障分析定位信息, 方便决策和高效处理。系统着重于协同故障处理的建设, 基于智能分析安全模型, 建设规则化、灵活化、易用化、直观化的协同故障处理系统。充分利用系统对故障发现、分析、处理的智能化方法和手段, 实现对故障的全过程管理和控制, 使故障处理显性化、简单化、及时化。

2.1 安全模型

由于网络固有的复杂性、不确定性, 通常情况下无法获得与网络故障相关的所有信息。如何尽快定位故障, 仍然是一个棘手的问题。如何通过多维立体监控、综合一切可以获得的数据信息 (可能是不确定、不完整的信息) , 以最少的操作、最低的代价, 获得确切的故障信息, 通过诊断操作, 最终准确定位故障, 无疑是重中之重。

重大故障定位安全模型实现如下:

(1) 故障症状发生

通过多维立体监控, 包括信令监测、设备告警、性能指标、仿真和自动拨测等途径, 获取网络运行实时状况信息。对网络运行进行实时监测和分析, 当出现故障表现症状集E中某个或某些表现症状时, 触发故障定位安全模型, 建立当前故障表现症状集Ec={e1, e2, …, es}。

(2) 候选故障判定

针对当前故障表现症状集Ec中的每一个表现症状ei (1≤i≤s) , 通过规则定义, 可以判定可能由一个或多个不同故障引起, 得到对应ei的候选故障集合Fi={f1, f2…, fl}, 从而可以建立针对当前故障表现症状集Ec的候选故障集Fc={f1, f2, …ft}。

表现症状ei的每个候选故障fj (1≤j≤l) 的发生概率P (fj/ei) 可能不同, 有的故障发生概率相对较高, 有的则较低。Ec中的多个表现症状也可能指向同一个可能故障fj, 则此故障fj的发生概率为该故障fj针对各个ei的发生概率之和: (1≤j≤t) , 如果f不属于ei的候选故障集Fi, 则p (f|ei) =0。通过计算可以得到Fc={f1, f2, …, ft}中所有故障fj针对表现症状集合Ec的发生概率, 按照发生概率值, 对所有故障fj进行优先级排序。

(3) 诊断操作

对于网络运行过程中发生的故障, 通过与设备交互或其它方法可以对故障做进一步定位。对于候选故障集Fc={f1, f2, …, ft}中的每个故障fj (1≤j≤t) , 可以通过其中一个或多个诊断操作进行故障定位, 对应诊断操作序列集Oj={o1, o2, …, ok}。根据FC中所有故障的发生概率优先级, 从高到低逐一对故障fj执行诊断操作, 根据操作结果进一步判定故障fj是否确实发生。如果确已发生, 则故障准确定位, 诊断结束, 不再对其它f进行诊断, 直接输出故障fj。如Fc中所有故障都诊断结束, 但是未准确定位, 则输入Fc。

2.2 故障处理

系统从性能监测、告警监测、拨测系统、性能系统实时进行数据接收, 把接收到的数据作为下一个环节的输入, 送入安全模型进行判断、监测, 根据安全模型的监测规则进行模式匹配。

通过场景化的系统故障处理平台, 系统专家、决策者、厂商、维护人员进行系统图形化的故障处理、定位、分析, 借助平台提供的即时工具进行实时沟通, 并利用平台提供的工具进行故障影响分析和故障现场管理。确定故障后, 维护人员在专家的指导下, 经决策者同意, 实施系统方案, 修复故障, 并及时通报修复结果。

故障解决后, 为避免故障再次发生, 同时总结修复经验, 填写故障总结表, 关闭故障场景, 支持故障场景的回放。

下面介绍协同故障智能定位与处理的具体过程。

2.2.1 故障智能定位

网元发生故障后, 根据安全模型的故障定位、诊断结果, 系统进行场景化故障协同处理模块。根据定位的故障网元, 系统自动找到对应场景, 首先支持的场景类型为:MSC场景、MGW场景、BSC场景、HLR场景, 场景支持回放功能。

在整个故障处理场景中, 完成以下工作:

(1) 呈现故障网元

拓扑图呈现出故障网元的网络连接拓扑, 在拓扑图上呈现出与故障网元相关的相邻、相近网元及连接方向。在拓扑中, 与故障网元直接相连的网元在拓扑中呈现真实的物理拓扑连接, 不直接相连的通过虚线画出连接示意图。图中可以呈现故障网元所在机房、承载用户数、下挂基站数量等信息。

(2) 故障信息呈现

在场景中不但要呈现出相应的拓扑连接, 还要结合拓扑图呈现相应的故障信息、定位信息、决策信息、相应的处理预案。

拨测项目中, 每一个项目对应出拓扑图上的相应的矢量连接线。根据拨打测试验证的结果或其他方式判断的结果, 形成最后的结论, 系统通过最终结论来改变连接线的颜色。

每条矢量连接线的状态被改变后, 系统要全局生效, 凡是打开此场景的登录用户都要看到此测试项目的结论和定位点, 拓扑图的矢量连接线都要发生相应的改变。具体的测试项目、测试项目和矢量连接线的关联关系要做到可以进行配置。

(3) 定位信息

每一个定位点对应出拓扑图上的相应节点。根据故障现象或其他方式判断的结果, 形成定位点信息, 系统通过定位点的状态来改变节点的颜色。非正常状态则显示红色。

每个节点状态被改变后, 系统要全局生效, 凡是打开此场景的登录用户都要看到此测试项目的结论和定位点, 拓扑图的节点都要发生相应的颜色改变, 并显示定位原因、定位人信息。

具体的测试项目、测试项目和矢量连接线的关联关系要做到可以进行配置。

(4) 人员信息

当前故障场景中相关联人员的信息及到位情况。

2.2.2 故障影响处理

故障需求和算法实现自动计算功能, 在决策视图中展现。支持故障影响提醒:

(1) 自启动重大故障处理开始计时, 到40分钟时弹出窗口, 提醒60分钟内需要上报集团。

(2) 每20分钟自动计算故障影响。如果达到10万用户小时, 就给出提醒需要上报工信部, 到达工信部上报条件后的计算是否自动待确定。

(3) 提供分公司上报功能, 可随时更新显示故障影响的网元、地域、用户数, 并能回退显示分公司在本次故障中的历次上报内容。

(4) 根据自动拨测系统测试结果, 描述本故障场景中分公司受影响的网元和现象。

2.2.3 故障现场处理

系统为现场处理提供紧急现场管理、拨测验证、故障总结功能。

(1) 现场管理

分公司成立现场领导小组、故障处理小组、预案准备小组、网络测试小组、信息接口小组。小组人员可以事先配置, 场景启动后可以由分公司人员确认哪些人员已经到达现场, 并进行标识。

1) 现场领导小组

制定统一的对外解释口径, 并填报到系统中。与本地客服、市场、综合等部门沟通, 标识是否已经沟通;与帐务中心联系, 及时处理用户数据和话单, 标识是否已经沟通。

2) 故障处理小组

小组人员应参与故障协同处理过程。

3) 预案准备小组

预案是否已经准备完毕。

4) 网络测试小组

小组人员应进行相关拨测验证工作。

5) 信息接口小组

及时上报故障影响、处理过程和拨测情况。

(2) 拨打测试验证

根据定义不同类型的故障, 对需要拨测的项目进行拨测。

故障处理中分公司进行的拨测结果能够及时呈现、上报。

拨测情况能够反映到故障场景中, 自动拨测情况也能体现其中。

(3) 故障总结

固化故障总结模板, 详细分析故障影响。

3 运行效果

(1) 提高故障影响的显性化

结合资源数据库呈现故障网元的拓扑及影响范围, 自动分析故障对用户的影响程度, 根据故障处理过程实时更新影响。

(2) 专家协同会诊, 提高故障的处理效率

充分发挥维护人员、技术支援专家和厂家的力量, 联合进行故障会诊, 提高故障处理效率。

(3) 提高故障的智能诊断水平

系统对故障设备的指标、告警、资源等数据进行智能分析, 诊断故障原因。

(4) 提高故障的决策判断