掌上综合运维的支撑研究

2015-12-03 03:30
网络安全和信息化 2015年6期
关键词:消息运维用户

在移动互联网的大潮中,电信运营商的OSS支撑体系中的各类业务系统纷纷推出了适用于智能手机的客户端,广泛运用在一线运维人员的智能手机中。但正是由于OSS支撑系统众多,而各个业务系统的App没有统一的标准,用户不得不安装大量的移动应用程序,而各个应用之间没有任何关系,这样既增加了智能终端的硬件负担,也不利于一线运维人员开展工作,从而给系统建设和推广使用都带来了一定的困难。

一、需求与技术分析

我们分别从移动应用的系统和移动应用的形态演进两个角度来看看企业移动信息化的发展趋势。

对于制造业而言,其核心的系统主要为“进销存+研发管理”等系统,其移动化的路线图为销→存→进,此外针对高层用户的决策类信息也会逐步移动化;对于服务业而言,在线服务订购类和在线客服类系统(即所谓的O2O应用)应用大量出现,如各类酒店预订、打车App、团购应用等;对于电信运营商而言,CRM中的营销和客服类模块目前已经在逐步移动化。除了上述的各类业务系统,在各类企业应用中被大量使用的办公类系统(OA和邮件等)和协作类系统(即时通信等)对移动信息化的需求也是最迫切的。此外,我们也注意到,目前企业移动信息化还处于比较初级的阶段,大部分企业的移动应用都是各自独立,很少有从整体上统一考虑的。

从企业移动应用的形态上看,基于平台原生语言的App应用大行其道,在iOS平台上这类应用主要基于苹果的AppStore进行分发,在Android平台上大量应用如雨后春笋般出现也催生了很多类AppStore的应用分发类工具,如91助手、豌豆荚等。微信及其第三方公共平台的出现使O2O类应用和企业营销类应用的形态发生了巨大变化,人们忽然发现,千姿百态需要不断学习的各类原生APP其实还是敌不过最自然的人与人的沟通以及隐藏在这种沟通形态之后不断强大的人工智能。与此同时,越来越多的互联网公司开始采用WebApp技术,原因是伴随着智能终端处理能力的增强,基于Html5的WebApp技术将会占据主流。融合通信和WebApp的技术发展,让我们看到传统的AppStore虽然还占有一定的市场,但会逐步衰落,而基于融合通讯(电话、即时消息)技术和WebApp技术的企业应用的结合将成为企业移动信息化的主流。

图1 综合掌上运维整体的业务架构

从另一方面,维护人员跨组织、部门,相互交流、沟通较少,容易形成业务壁垒,造成知识共享不够,维护人员业务水平成长缓慢。为此,维护人员有强烈的意愿打破沟通壁垒,形成扁平化的交流、沟通业务线条,便于彼此共享专业知识。在互联网浪潮中,融合通信越来越多的承担起人与人远程沟通、分享的责任,而企业应用很少顾及融合通信的需求,往往依赖于外部媒体通信工具,这些通信软件在企业应用方面支撑甚少,不支持企业内部的业务系统接入、不支持话费落地、不支持企业加密的消息传输没有安全性可言等等,因此,构建融合通讯的掌上运维系统,实现维护人员的扁平化沟通迫在眉睫。

二、技术方案

该方案的主要目标是建设综合化的掌上运维系统,其中包括四大网络运维维度:掌上数据中心、掌上维护中心、掌上知识中心和掌上协作中心。

这四大应用中心依托于统一的消息推送和应用仓库的集成,统一消息接入所有外部应用系统向用户推送的各种消息,并推送到客户端,由客户端进行汇总后统一呈现;应用仓库负责接入所有WebApp和Native原生应用,包括数据中心所需的业务数据存储,均在该模块中实现。

通过上述的需求与技术分析,综合掌上运维整体的业务架构如图1所示。

统一消息推送主要解决人机交互、人人交互的消息整合过程,由消息接入对消息源进行消息整合、清洗与标准化,并通过消息引擎路由给相应的用户。

四个中心特点

根据需求的分析,四个中心各有特点。首先,协作中心是人人、人机沟通的核心模块,可以浏览查询企业通讯录,发起对话、建立群组、组织会议等。因此我们融合了消息界面,使之可以将人-人消息、人-机消息有效地结合在一起,提供更加直观的操作界面。

其次,维护中心主要面向人-机远程操作,这里会根据业务能力集成各类面向网络操作类的应用工具,因此,该中心以集成各类手机应用为主,实现应用仓库功能。

再其次,数据中心提供用来支撑各类用户工作的关键数据,这些数据通过其他业务生产系统生产,综合掌上运维系统通过采集获得。采集后的数据经过建立关联关系、清洗、标准化后进入数据中心的存储层,并由本系统向订阅这些数据的用户进行分发。

最后,知识中心在处理故障、网络调优时提供关联案例进行推送,并提供知识分享、下载、阅览的操作,帮助维护人员提升工作能力。

这四个中心以协作为核心,通过实际业务场景串接起每个中心的功能,系统手机客户端的界面如图2所示。

图2 手机客户端的界面

数据建模方案

掌上运维的数据中心的特点是推送、呈现和查询业务数据,那么就需要在系统中接入大量的网络数据报表,这些报表中的数据是数据来源系统负责提供的,由于数据来源系统的界面样式的不确定性和操作模式的多样性,为保证用户的使用体验,我们必须对数据来源系统提供的数据进行存储,并提供统一的数据消费体验。

在本案中,我们重点分析30多种来源于不同业务系统的数据格式,并整理出业务场景对数据维度的要求,这些统计维度主要包括部门、用户、区域、时间、设备、网络等。按这些数据维度进行数据模型的抽象,建立逻辑模型和物理模型。这些模型用来存储最终呈现的数据样式,本案系统并不承担数据的加工、清洗和汇总的数据处理过程,该过程由数据来源系统承担。图3是数据模型构建时逐级汇总的过程。

通过上述模型的梳理和建设,对接采集业务系统的生产数据,这样就在本系统内实现了综合掌上运维所需的业务数据存储平台,能够对上层的业务应用提供数据支撑了。

三、知识管理运营方案

图3数据模型构建时逐级汇总过程

图4运营管理方法

在本案中,涉及到网络维护知识管理,知识的收集与分发工作不只是行政命令或完全基于个人意愿的简单分享,需要更多的思考用户行为,并不断运营知识,才可以使用户对知识的发布、分享、使用变得更有效率。在知识运营管理中,运用的运营管理方法如图4所示。

首先从产品设计上满足知识管理体现要求的支撑平台,将内容建设作为运营管理的基础工作。本案中,根据用户主体工作需要,主要面向故障处理、设备维护操作、日常维护等几个方面进行建设,引导用户主动分享故障处理过程、设备维护经验等。

其次,通过内容编辑审核、话题挖掘、内容推送保证知识质量,吸引用户兴趣,并为用户实际工作提供帮助。该部分内容涉及到管理岗位、职责的定义,需要在开展实际项目前落实管理职责。同时,保证知识的质量需要大量的工作量,为了避免简单粗暴的考核式管理,我们对知识的质量设置阈值,让每个用户既是参与者也是评分者。那么,这些就需要系统能够提供对知识的评分,并能够让真正帮助维护人员解决实际问题的知识获得更高认同度。

最后,持续的分析用户访问情况、功能使用情况等数据,优化系统功能,并策划专题活动,保持内容和产品功能的充分结合。因此,在知识管理运营的过程,我们需要对知识的贡献者提供一些奖励,在该功能模块中,我们提供贡献度排名、专家知识排名、知识评分排名等,对于位于排名前列的部门、专家、维护人员,给予精神和物质上的奖励,使员工在贡献知识的时候可以获得极强的满足感,推动知识的积累和完善。

四、总结

本方案充分考虑到移动化办公对电信运营商企业内部的变革,提出了全新的综合化移动办公方案,并结合代维知识的运营,推动代维组织的技术发展。电信运营商可以根据自身特点及管理办法,利用本案的技术架构来实现符合自身运维能力的综合化移动运维平台。

猜你喜欢
消息运维用户
一张图看5G消息
运维技术研发决策中ITSS运维成熟度模型应用初探
风电运维困局
杂乱无章的光伏运维 百亿市场如何成长
关注用户
关注用户
基于ITIL的运维管理创新实践浅析
关注用户
如何获取一亿海外用户
消息