一种运维服务管理方法及管理平台与流程

本发明涉及运维服务管理技术领域，更为具体来说，本发明为一种运维服务管理方法及管理平台。

背景技术：

目前，随着燃气行业的不断发展，燃气企业的信息系统也越来越复杂；虽然有些燃气企业建立了相关的监控和运维管理系统，但往往是面向设备的单方面分散管理，传统的管理方式存在诸多问题，主要体现在以下几个方面。

一、故障处理效率低：由于传统的运维服务管理方式无法直观地反映整个企业信息系统的运行状态和告警情况，直接导致单一问题出现后多处报警、多方排查等问题，而且完全依靠人工排查、人工报修及人工维护，这个过程浪费了大量人力和物力，故障处理效率非常低；严重影响了燃气业务的正常开展。

二、故障处理响应迟：传统运维管理方法只有在故障发生之后才进行维护，这种“后知后觉”的常规运维管理方案导致了故障报警过于滞后的问题，从而延长了故障的排除时间，更严重影响了燃气业务的正常开展。

因此，如何提高故障处理效率、提前对故障作出响应，成为了本领域技术人员亟待解决的技术问题和始终研究的重点。

技术实现要素：

为解决常规燃气企业运维服务管理方法存在的故障处理效率低、故障处理响应迟等诸多问题，本发明创新提出了一种运维服务管理方法及管理平台，通过本发明能够实现故障发生时进行报警和故障发生前进行预警，本发明能够有效指导管理人员迅速确定故障根源并及时解决，最大程度地减少燃气业务的服务中断时间，本发明还可通过综合实时监控展示为相关负责人提供不同的视图，帮助其进行管理决策和运维支持工作。

为实现上述技术目的，本发明公开了一种运维服务管理方法，该管理方法包括如下步骤：

状态获取步骤，获取以关系矩阵的形式设置的各个被监控对象的运行状态信息；

状态分析步骤，自动识别所述运行状态信息，根据识别结果判断当前运行状态信息对应的被监控对象是否发生或可能发生故障，并在故障发生或可能发生的情况下执行故障报警步骤；

故障报警步骤，自动判断已发生或可能发生的故障的故障等级，根据所述故障等级所处级别发出对应的报警信息；

故障锁定步骤，报警信息产生后，利用所述故障等级和关系矩阵锁定故障根源；

故障排除步骤，对锁定的故障根源进行修复、排除被监控对象已发生或可能发生的故障。

基于关系矩阵的设计，本发明将燃气企业下的所有相关设备进行统一监控，达到从总体上管理燃气企业的信息系统的目的，避免单一问题导致多处报警、多处排查的问题，有效地提高了故障处理效率；基于事先预警机制，实现故障发生前进行报警，本发明解决了常规运维方案存在的故障处理响应迟的问题；因此，本发明能够达到避免燃气业务因故障而中断、保护燃气业务的正常开展的目的。

进一步地，在所述状态分析步骤中，包括对被监控对象的当前运行状态信息和历史运行状态信息进行识别的步骤，通过识别被监控对象的当前运行状态信息生成第一识别结果，通过识别被监控对象的历史运行状态信息生成第二识别结果；通过所述第一识别结果判断被监控对象是否发生故障，通过所述第一识别结果和第二识别结果共同预测被监控对象是否可能发生故障。

基于上述改进的技术方案，本发明能够更准确地判断出被监控对象的状态，实现对被监控对象的有效预警，从而保证燃气业务的正常开展。

进一步地，该管理方法还包括关系构建步骤；

所述关系构建步骤，在状态获取步骤之前，通过层次分析法和/或专家经验法的方式将所有被监控对象划分为相互联系的元素，根据元素间上下层次之间的隶属关系和同一层次两两元素之间的依赖关系构建所述关系矩阵。

基于上述改进的技术方案，本发明能够更科学、合理地对被监控对象进行客观划分，不仅实现了对被监控对象的全局管理，而且为故障根源的定位做了充足的准备，提高了本发明故障处理的效率。

进一步地，在所述关系构建步骤中，识别出被监控对象的类别，根据被监控对象的类别确定其监控方式，所述监控方式包括周期监控和实时监控。

基于分类监控的方式，本发明能够在保证监控质量的基础上有效减少对平台资源的占用，在实现本发明运维服务功能的基础上降低资源投入，从而极大地节约成本。

进一步地，在所述状态获取步骤中，对发生过故障且其监控方式为周期监控的被监控对象，将此被监控对象的监控方式调整为实时监控。

基于上述改进的技术方案，本发明能够更有针对性地对易发生故障的被监控对象进行重点监控，从而更有效地提高了本发明的预警能力和报警能力。

为实现上述的技术目的，本发明还公开了一种运维服务管理平台，该管理平台包括状态获取模块、状态分析模块、故障报警模块、故障锁定模块及故障排除模块；

所述状态获取模块，用于获取以关系矩阵的形式设置的各个被监控对象的运行状态信息；

所述状态分析模块，用于自动识别所述运行状态信息，根据识别结果判断当前运行状态信息对应的被监控对象是否发生或可能发生故障，并在故障发生或可能发生的情况下通知故障报警模块；

所述故障报警模块，用于自动判断已发生或可能发生的故障的故障等级，根据所述故障等级所处级别发出对应的报警信息；

所述故障锁定模块，用于在报警信息产生后利用所述故障等级和关系矩阵锁定故障根源；

所述故障排除模块，用于对锁定的故障根源进行修复、排除被监控对象已发生或可能发生的故障。

基于关系矩阵的设计，本发明将燃气企业下的所有相关设备进行统一监控，达到从总体上管理燃气企业的信息系统的目的，避免单一问题导致多处报警、多处排查的问题，有效地提高了故障处理效率；基于事先预警机制，实现故障发生前进行报警，本发明解决了常规运维方案存在的故障处理响应迟的问题；因此，本发明能够达到避免燃气业务因故障而中断、保护燃气业务的正常开展的目的。

进一步地，所述状态分析模块包括第一分析单元和第二分析单元；

所述第一分析单元，用于对被监控对象的当前运行状态信息进行识别，通过识别被监控对象的当前运行状态信息生成第一识别结果，通过所述第一识别结果判断被监控对象是否发生故障；

所述第二分析单元，用于对被监控对象的历史运行状态信息进行识别，通过识别被监控对象的历史运行状态信息生成第二识别结果，通过所述第一识别结果和第二识别结果共同预测被监控对象是否可能发生故障。

基于上述改进的技术方案，本发明能够更准确地判断出被监控对象的状态，实现对被监控对象的有效预警，从而保证燃气业务的正常开展。

进一步地，该管理平台还包括关系构建模块；

所述关系构建模块，用于在状态获取步骤之前通过层次分析法和/或专家经验法的方式将所有被监控对象划分为相互联系的元素，根据元素间上下层次之间的隶属关系和同一层次两两元素之间的依赖关系构建所述关系矩阵。

基于上述改进的技术方案，本发明能够更科学、合理地对被监控对象进行客观划分，不仅实现了对被监控对象的全局管理，而且为故障根源的定位做了充足的准备，提高了本发明故障处理的效率。

进一步地，所述关系构建模块包括监控方式确定单元；

所述监控方式确定单元，用于识别出被监控对象的类别，根据被监控对象的类别确定其监控方式，所述监控方式包括周期监控和实时监控。

基于分类监控的方式，本发明能够在保证监控质量的基础上有效减少对平台资源的占用，在实现本发明运维服务功能的基础上降低资源投入，从而极大地节约成本。

进一步地，所述状态获取模块包括监控方式调整单元，对发生过故障且其监控方式为周期监控的被监控对象，监控方式调整单元用于将此被监控对象的监控方式调整为实时监控。

基于上述改进的技术方案，本发明能够更有针对性地对易发生故障的被监控对象进行重点监控，从而有效地提高了本发明的预警和报警能力。

本发明的有益效果为：本发明有效实现了对燃气企业各业务系统实现统一、集中、标准、规范的监控和预警，提高了运维管理的能力和效率，提升了信息化服务水平，为燃气企业信息化提供稳定、可靠的支撑和保障，为燃气企业的信息化发展提供详实、准确的信息化基础资料。本发明还具有良好的系统性、先进性、开放性、实用性、经济性、扩展性、稳定性及安全性等突出优点。

本发明既可以丰富开发新业务系统时的非业务功能需求，使开发团队在系统设计阶段，把以后运维阶段需要关注的监控指标内嵌到应用系统中，起到事前预防的作用；又可以在旧系统改造过程中增加指标的监控功能，起到事后补充完善的效果；同时，本发明对于运维管理团队全面、有效地部署和配置各类运维监控管理工具也起到有效的指导作用。

附图说明

图1为本发明运维服务管理方法流程示意图。

图2为本发明运维服务管理平台结构示意图。

具体实施方式

下面结合说明书附图对本发明进行详细的解释和说明。

实施例一：

如图1所示，本发明公开了一种运维服务管理方法，该管理方法具体包括如下步骤。

关系构建步骤，在状态获取步骤之前，通过层次分析法和/或专家经验法的方式将所有被监控对象划分为相互联系的元素，根据元素间上下层次之间的隶属关系和同一层次两两元素之间的依赖关系构建关系矩阵。本实施例以层次分析法(ahp)为例进行举例说明：通过层次分析法将网络、主机、中间件、数据库、应用等监控对象划分为相互联系的各个元素，各个元素的数据颗粒度根据业务需要和实际环境而定，之后依据维护人员和技术人员经验比较客观地将这些元素进行有效结合，根据上下层次之间的隶属关系以及同一层次内两两元素之间的依赖关系进行定量描述，构建出一个关系矩阵，最后通过对所有层次内所有元素计算相对权重的方式进行总排序。本实施例以四个层次为例进行说明：从上至下分别是应用服务层、系统资源层、网络服务层和基础设施层，全面覆盖应用系统、数据库、中间件、服务器、存储、网络和机房环境各个领域，确保任何一个领域出现风险隐患时，运维人员均可以主动、及时地发现、预警、分析和处置，把风险控制在初始状态，确保燃气业务连续性。在应用服务层面上可以分为业务进程类、业务数据类、日常自动处理运行类和日志、报文类、错误信息类，能够实时反映业务应用进程的运行状态。其中业务进程类指标包括业务功能队列的使用情况、资源消耗情况；业务数据类指标包括业务事件数、业务平均响应时间、在线用户数；与业务相关文件类指标包括业务报文数量、业务日志中的错误信息等。在系统资源层面可以分为数据库类、中间件、操作系统类和存储四大类。其中数据库类的指标可以分别反映服务器的运行状态、实例的运行状态、会话数、监听器的运行状态。中间件类根据不同的使用特性，如业务中间件、消息中间件等，细分为tomcat、weblogic和iis三种。操作系统类可以按照使用环境分为windows、linux和unix三种，客观反映各种主流操作系统的运行状态。存储系统类可分为光纤交换机、光纤交换机端口、存储系统和光纤链路，客观反映存储系统端到端的运行状况。在网络层面按照管理特性可分为网络或安全设备的处理器、内存、风扇、温度、电源、系统、设备端口、运行协议等不同维度客观反映网络环境的运行情况和运行质量。在机房基础设施层面可以按照管理设备种类分为电量、ups、空调等，反映机房基础设施的使用情况和运行质量。通过标准化的数据采集接口收集整理、分类汇总和关联分析，进行信息化统一运维监控管理，实现了事件管理、性能管理、告警管理、故障分析等风险处置功能。同时还能提高运维管理工作的日常监督和及时提醒功能。为了促进监控指标有效落地，充分发挥监控预警作用，需开发和运维团队积极配合，围绕逐步优化和完善指标体系开展工作，从指标梳理、指标设置、指标权重计算、指标评估、体系建立五个阶段，形成持续优化的闭环工作过程。开发和运维团队需要根据业务特点和系统情况，结合实际运维工作需要，可以采用专家经验法，以调查问卷的方式选取相应的监控指标形成特定的监控指标集，即所有被监控对象的集合。

在关系构建步骤中，还包括：识别出被监控对象的类别，根据被监控对象的类别确定其监控方式，在本实施例中，监控方式包括周期监控和实时监控，例如，可以对服务器进行实时监控，对存储器进行周期监控等。

具体实施时，本发明可利用基于tcp/ip协议的简单网络管理协议(snmp，全称为simplenetworkmanagementprotocol)进行信息化监控，通过使用嵌入到设备中的代理软件来收集网络通信信息和有关设备的统计数据，代理软件不断地收集统计数据，并把这些数据记录到管理信息库(mib)中。其中，具体的被监控对象可包括机房、燃气网络、服务器、存储器、数据库、中间元件、应用系统中至少一个；比如，eam设备资产管理系统、物资管理系统、用户管理系统、第三方缴费平台、用户发展管理系统、呼叫平台、财务银企互联系统、协同管理平台、人力资源管理系统、集团门户网站等业务系统中的至少一个系统；再比如，营业收费站点的接入层与汇聚层设备、链路、网络设备；再比如，现有信息中心机房监控管理软件的集成，包括电源、空调、视频监控、门禁、环境温湿度等的机房环境的监控等；再比如，服务器和网络的硬件资源、性能、带宽、端口、进程、服务等。且本发明通过建立关系矩阵等手段消除管理对象之间的差别、数据采集手段的差别、管理软件的差别，对各种不同数据来源实现统一管理、统一规范、统一处理、统一展现、统一用户登录以及统一权限控制，从而实现了一个贯穿整个信息化系统全过程且实现了规范化、自动化、智能化的信息化资源大运维的监控管理。

状态获取步骤，获取以关系矩阵的形式设置的各个被监控对象的运行状态信息；在状态获取步骤中，对发生过故障且其监控方式为周期监控的被监控对象，将此被监控对象的监控方式调整为实时监控，但是如果此监控对象在一定时间内再次发生故障，可以考虑采取更换元件等措施，以避免故障重复出现，导致系统运行效率低，更换新元件后，监控方式可以采用初始监控方式，比如，周期监控。

状态分析步骤，自动识别运行状态信息，根据识别结果判断当前运行状态信息对应的被监控对象是否发生或可能发生故障，并在故障发生或可能发生的情况下执行故障报警步骤；具体来说，本实施例中，在状态分析步骤中，包括对被监控对象的当前运行状态信息和历史运行状态信息进行识别的步骤，通过识别被监控对象的当前运行状态信息生成第一识别结果，通过识别被监控对象的历史运行状态信息生成第二识别结果；通过第一识别结果判断被监控对象是否发生故障，通过第一识别结果和第二识别结果共同预测被监控对象是否可能发生故障。其中，具体的故障可以包括网络故障、服务器故障、信息系统故障等。

故障报警步骤，自动判断已发生或可能发生的故障的故障等级，根据故障等级所处级别发出对应的报警信息；对于故障等级的划分，本发明可采用阈值衡量的方式，将阈值分为基准阈值、关注阈值和告警阈值三种；阈值的设置可遵循“基准阈值<关注阈值<告警阈值”的原则；阈值的初始设置可依据系统的运行特性，结合维护团队技术人员经验而定，在实际使用过程中，可根据指标监控情况进行调整。比如，当某被监控对象的某项阈值达到关注阈值时，则可认为其可能发生故障；当某被监控对象的某项阈值达到告警阈值时，则可认为其已经发生故障。其中，具体的报警信息可以包括蜂鸣报警信息、网络报警信息、电话报警信息等；例如，当燃气充值终端发生故障时，可以先在终端平板上显示故障；当服务器发生故障时，可以通过网络告警，例如发送警报邮件给管理员或者发出蜂鸣警报给管理员等；本发明也可以开展网络、电话等方式的告警服务等。

故障锁定步骤，报警信息产生后，利用故障等级和关系矩阵锁定故障根源；具体地，根据故障等级确定导致当前被监控对象故障的目标范围，在该目标范围内根据关系矩阵锁定出故障根源或故障根源范围，从而减少故障根源的查找时间，提高故障处理效率。

故障排除步骤，对锁定的故障根源进行修复、排除被监控对象已发生或可能发生的故障。具体实施时，如果能够通过管理平台自动修复的方式排除故障，则进行自动修复工作；如果不能，则通知相应的管理人员进行手动修复。

实施例二：

如图2所示，本实施例与实施例一具有相同的发明构思，对应实施例一中公开的一种运营服务管理方法，本实施例公开了一种运维服务管理平台，该管理平台包括关系构建模块、状态获取模块、状态分析模块、故障报警模块、故障锁定模块及故障排除模块，具体内容如下。

关系构建模块，用于在状态获取步骤之前通过层次分析法和/或专家经验法的方式将所有被监控对象划分为相互联系的元素，根据元素间上下层次之间的隶属关系和同一层次两两元素之间的依赖关系构建关系矩阵。本实施例中，关系构建模块包括监控方式确定单元。具体的构建过程参考实施例一中内容所述。

监控方式确定单元，用于识别出被监控对象的类别，根据被监控对象的类别确定其监控方式，监控方式包括周期监控和实时监控。

状态获取模块，用于获取以关系矩阵的形式设置的各个被监控对象的运行状态信息；本实施例中，状态获取模块包括监控方式调整单元，对发生过故障且其监控方式为周期监控的被监控对象，监控方式调整单元用于将此被监控对象的监控方式调整为实时监控。

状态分析模块，用于自动识别运行状态信息，根据识别结果判断当前运行状态信息对应的被监控对象是否发生或可能发生故障，并在故障发生或可能发生的情况下通知故障报警模块；本实施例中，状态分析模块包括第一分析单元和第二分析单元。

第一分析单元，用于对被监控对象的当前运行状态信息进行识别，通过识别被监控对象的当前运行状态信息生成第一识别结果，通过第一识别结果判断被监控对象是否发生故障。

第二分析单元，用于对被监控对象的历史运行状态信息进行识别，通过识别被监控对象的历史运行状态信息生成第二识别结果，通过第一识别结果和第二识别结果共同预测被监控对象是否可能发生故障。

故障报警模块，用于自动判断已发生或可能发生的故障的故障等级，根据故障等级所处级别发出对应的报警信息。

故障锁定模块，用于在报警信息产生后利用故障等级和关系矩阵锁定故障根源。

故障排除模块，用于对锁定的故障根源进行修复、排除被监控对象已发生或可能发生的故障。

在本发明的基础上，可开发故障显示模块，用于显示故障相关信息，比如，故障相关信息可包括故障的元件、故障代码、故障对应的解决方案、故障对应的联系人等信息。具体实施时，若是在管理平台发现故障前人为发现故障，故障申报人通过故障显示模块的显示信息，可以直接获取故障解决方案信息，也可以直接联系故障处理人，从而可以加速故障处理时间，加快信息系统的运行，故障报警模块可以核实故障申报人发出的故障申报信息，并在核实通过后进行报警，使得故障管理人员可以及时发现故障，及时解决。

在本发明的基础上，还可开发故障统计模块，用于根据故障信息生成分类显示信息，比如故障部门信息、故障岗位信息、故障处理信息、故障发生频率信息等。通过对故障信息进行统计整理，可及时掌握系统的运行情况，对系统内的运行元件有所掌握，便于及时维修更换设备。通过提供全局资源统计报表和运维分析报表，从各个侧面、各个角度反映信息化运维工作的开展情况、人员的配置、绩效情况，为运维工作质量评估、运维人员绩效考核以及下一阶段运维组织改进和优化提供科学依据。

本发明能够实现对燃气信息系统进行7*24小时的实时监控，在监测到信息系统内的对象发生故障时及时报警，并可根据本发明迅速找到故障根源，以及时进行解决、最大程度减少信息化服务的中断时间，并可以在本发明的基础上进行综合实时监控显示，为信息化运维管理层、支持团队提供不同的视图，帮助其进行管理决策和运维服务支持工作。

本发明有效地发挥了运维服务管理的预警作用，有效提升了各类运维监控指标的覆盖率和完备率。在管理层面，本发明减少了管理人员花费在了解复杂、繁琐的信息系统架构和技术细节上的时间，而有更多的时间在决策上；而从服务定义、服务水平管理、服务监控、服务诊断的角度，本发明实现信息系统实时精准告警，有效减少和降低告警总体次数，使管理人员随时动态了解信息系统运行健康情况，从而既满足了企业要求的服务水平、确保最佳的业务系统运行状态，又辅助支撑燃气企业的业务运营与信息化决策。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

在本说明书的描述中，参考术语“本实施例”、“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

附图中的流程图和框图显示了根据本发明的多个实施案例的平台的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明实质内容上所作的任何修改、等同替换和简单改进等，均应包含在本发明的保护范围之内。