智能运维的管理系统需求规格说明书Word下载.docx

智能运维的管理系统需求规格说明书Word下载.docx

《智能运维的管理系统需求规格说明书Word下载.docx》由会员分享，可在线阅读，更多相关《智能运维的管理系统需求规格说明书Word下载.docx（22页珍藏版）》请在冰豆网上搜索。

3.1.2.用例分析8

3.1.3.参与者列表8

3.2.专用监控功能模块9

3.2.1.场景描述9

3.2.2.用例分析9

3.2.3.参与者列表10

3.3.故障告警模块10

3.3.1.场景描述10

3.3.2.用例分析11

3.3.3.参与者列表11

3.3.4.用例描述11

3.4.数据配置管理模块11

3.4.1.场景描述11

3.4.2.用例分析11

3.4.3.参与者列表12

3.5.故障切换管理模块12

3.5.1.场景描述12

3.5.2.用例分析12

3.5.3.参与者列表13

3.6.数据接口13

3.6.1.场景描述13

3.6.2.用例分析13

3.6.3.参与者列表13

3.7.故障处理13

3.7.1.场景描述13

3.7.2.用例分析13

3.7.3.参与者列表14

4.系统非功能性需求14

4.1.易用性需求14

4.1.1.方便增加监测设备14

4.1.2.方便删除监测设备14

4.1.3.方便定位故障或者异常设备15

4.1.4.监测设备在启动与停顿监测之间方便转换15

4.2.性能、并发性需求15

4.2.1.对性能及并发性的特殊要求16

4.3.扩展性需求16

4.3.1.采集和监控效劳器的集群支持16

4.3.2.支持公司AFP平台的整合16

4.3.3.支持公司单点登录系统的整合17

4.3.4.支持对物联网智能设备的直接监测17

4.4.平安及性需求18

4.4.1.敏感数据加密18

4.4.2.敏感操作进展确认18

4.5.可靠性需求18

4.5.1.运行可靠性18

4.5.2.数据可靠性19

4.6.可维护性需求19

4.6.1.监测设备配置优化19

4.7.软硬件环境约束20

4.8.系统备份与恢复要求21

4.9.系统日志21

4.10.其它需求21

5.外部接口说明21

5.1.短信发送接口21

5.2.应用软件效劳监测接口21

1.文档介绍

1.1.文档目的

在?

智能运维管理系统V2.0立项建议书?

的根底上对各个功能模块做出详细的需求分析，为工程后续的设计和开发提供依据。

1.2.文档围

本文档包括效劳器监测、数据库监测、交换机监测、21平台监测、物联网智能设备监测、应用软件效劳监测、个性化主题展现、配置管理的需求规格说明，同时也包括整个系统平台的建立目标、总体构造、网络构造、系统接口描述、用户界面需求和软硬件环境方面的需求规格说明。

1.3.读者对象

1.-IOMSV2.0工程的系统设计人员、系统开发人员、系统测试人员以及配置管理人员；

2.公司部-IOMSV2.0工程的其干系人、领导、专家等。

1.4.参考文档

智能运维管理系统V1.0立项建议书，，2013-09

物联网智能数据采集和控制平台需求规格说明书，，2012-03

监控系统V2.0用户指南，2011-11

1.5.术语与缩写解释

缩写、术语

解释

IOMS

智能运维管理系统

ICD

物联网智能数据采集设备

物联网智能设备

连接到物联网智能数据采集设备上的智能设备，如传感器、智能空调、温湿度计等。

测点

系统采集的数据点，如温度、湿度都算一个测点。

21平台

作为CTI中间件平台，是整个呼叫中心的一个根底软件平台，为整个系统提供底层效劳核心支撑，主要包括消息通信效劳、CTI效劳、ACD效劳、统一接入效劳等。

ModbusTCP协议

ModbusTCP协议是简单的、中立厂商的用于管理和控制自动化设备的Modbus系列通讯协议的派生产品，是作为一种〔实际的〕自动化标准发行的。

2.系统概述

2.1.系统建立目标

公司目前在监控系统方向有两个产品，都是基于B/S构造，一个是监控系统，另外一个是物联网智能设备监控系统。

监控系统是公司提出的系统集成监控解决方案，其主要目标是监控IT系统中的各种信息节点（效劳器、数据库、交换机、21平台）的运行状态，提供故障的显示、告知，以及故障恢复功能。

物联网智能设备监控系统是市的科研课题，由硬件〔数据采集与控制终端简称ICD〕和软件〔嵌入式软件和智能设备监控系统〕两局部组成。

ICD设备提供和有线或者无线终端设备的接口，ICD设备的嵌入式系统负责终端设备的数据采集和控制、数据处理和封装以及对通信协议的转换，与上层软件统一采用ModbusTCP协议进展通信。

智能设备监控系统通过ModbusTCP协议收集终端设备测点的数据，监控ICD设备及终端设备的状态，个性化显示监测数据和状态，在监测数据和状态异常情况下通过声、光、短信告警，提供历史数据和历史事件查询，并可以通过配置的方式很方便的实现对各种不同类型、不同通信协议终端设备的监控。

监控系统搭配公司其它产品在、等几个省份部署，物联网智能设备监控系统通过课题组专家的验收，在监控系统使用的过程中以及物联网智能设备监控系统开发和验收的过程中，收到用户、领域专家、公司领导、公司专家和潜在用户的意见和建议，通过总结和分析这些意见和建议，得出本系统建立的目标如下：

1.基于B/S架构实现运维管理系统的整体框架；

2.实现对Windows操作系统的效劳器进展监测；

3.实现对SQLServer和Oracle数据库进展监测；

4.实现对公司部交换机进展监测；

5.实现对21平台进展监测（包括CTI效劳器、通信效劳器和坐席效劳器）；

6.实现异常事件监测；

7.实现短信告警规那么；

8.实现告警记录及查询；

9.实现操作记录及查询；

10.实现对物联网智能设备进展监测；

11.实现对物联网智能设备的配置管理；

12.实现主题的个性化配置；

13.封装个性化展现控件；

14.实现对公司三台合一接处警系统效劳的监测；

对公司部的关键设备进展监控。

2.2.系统总体构造

图中，AFP根底业务平台框架是整个智能运维管理系统的根底架构。

21平台、三台合一、警情分析、预案系统、PGIS系统和其他系统是本系统需要监测的应用软件，本系统提供给用软件效劳监测接口，各需要监测的应用软件实现此应用软件效劳监测接口。

短信效劳平台为本系统提供短信发布效劳，本系统提供发送短信所需要的发送人、接收人、发送容等信息。

效劳器监测、数据库监测、交换机监测、21平台监测、智能设备监测、应用软件效劳监测、配置管理、监测数据管理、告警规那么管理、异常规那么管理、主题管理和操作日志管理是本系统提供的主要功能。

2.3.用户的特点

本系统的用户主要有：

公司部的系统运维管理员；

购置本公司产品的客户运维管理员；

人防领域的潜在用户。

公司部的系统运维管理员主要通过本系统了解本公司产品部署在全国各地客户方的运行状态，重点关注监测对象的危险和故障事件。

公司部的系统运维管理员对计算机知识比拟熟悉，通过简单的培训即可很好的使用本系统，使用本系统的频度一般也比拟高。

购置本公司产品的客户一般是公安和消防，这类客户的运维管理员对系统维护和计算机相关知识一般不是很熟悉，通常仅使用本系统的故障告警功能，使用频度一般也不会很高。

人防领域的潜在用户和公安、消防的用户差不多，这类用户对系统维护和计算机相关知识一般不是很熟悉，因此通常也是仅使用故障告警功能，使用频度较低，一般情况是系统自动运行，等发现问题以后通过告警的方式通知用户来解决问题。

2.4.设计和实现上的限制

约束于公司在JAVA平台上开发的技术选型。

3.系统功能性需求

3.1.双活中心工作运行状态监控模块

3.1.1.场景描述

Ø

市局、分局两级架构的系统监控。

双中心监控支持图形化构造、拓扑构造、列表构造等展示坐席当前登录区域，双中心话务量统计等信息。

权限管理，对市局及分局的不同使用者的账号进展集中管理。

3.1.2.用例分析

1.支持两级架构的系统监控

2.市局通过公安网与分局进展连接，获取分局监控数据。

3.使用浏览器作为最终展现界面，支持多种方式信息查看

4.以图形方式、拓扑构造、列表构造等所有坐席当前登录区域，监控警情话务量统计数据、监控负荷分担情况等。

5.通过拓扑图方式，展现当前系统的节点及连接关系。

并通过不同的图示、颜色等方式，标注异常情况的节点和连接。

6.展示系统的软件系统构造图。

并通过不同的图示或颜色，标注其中的异常节点。

7.对于数值化的监控数据，通过图表的方式进展直观展示。

8.采集数据可以实时展现。

9.权限管理

10.监控平台对市局及分局的不同使用者的账号进展集中管理，根据用户的不同管理权限，向不同用户开放的不同的控制权限。

让不同职能的管理人员做到各行其职，提高监控管理的规性及平安性。

3.1.3.参与者列表

信息系统负责人、信息系统管理员、运维工程师、研发工程师

3.2.专用监控功能模块

3.2.1.场景描述

排队调度机、信令链路、2M通信链路、通信效劳软件、CTI效劳、坐席效劳、复用设备、手机定位、短信报警、录音系统、WEB效劳、处警分配效劳、二级接入效劳、报警用户信息效劳、数据库同步监控

各分局、直属单位、联动单位监控

3.2.2.用例分析

1.软件监控主要是通过监控效劳器对双中心的各自运行软件的效劳处理实时监控同步，提以及各类应用程序的检测。

能够检测当前程序的运行状态。

2.提供通用接口供给用程序上传自身详细信息。

可对应急联动双活中心的接入大屏系统、警情分析系统、录音系统、统一门户平台、值班排班系统、查询统计软件、科所队系统、分局二级接入效劳器软件、二级分配效劳器软件实时状态监控以及软件和应用程序的进程、效劳、端口等的运行状况，对系统日志进展分类扫描查询。

3.排队调度机、信令链路、2M通信链路、通信效劳软件、CTI效劳、坐席效劳、复用设备、手机定位、短信报警、录音系统、WEB效劳监控。

4.坐席效劳监控

✧对两个中心的坐席效劳的运行状态进展监控；

✧当坐席效劳异常停顿那么进展告警，并监控切换状态。

✧监控双中心之间坐席效劳消息同步状态。

✧对双中心坐席效劳器的链路情况进展监控。

5.处警分配效劳监控

✧对双中心处警分配效劳的运行状态进展监控，

✧如任一个中心的处警分配效劳发生异常停顿那么进展告警，并监控切换状态。

✧监控双中心分配效劳器消息同步状态。

✧对双中心分配效劳器链路进展监控。

6.二级接入效劳监控

✧对16个分局二级接入效劳的运行状态进展监控，

✧对16个分局二级接入效劳的登入到双中心处警分配效劳器的情况进展监控。

✧当双中心系统故障时，对16个分局的切换状态进展监控。

✧对16个分局的接入效劳异常停用等情况进展监控

✧对接入效劳器链路进展监控。

7.手机定位效劳监控

✧对两个中心的手机定位效劳的运行状态进展监控；

✧当手机定位效劳异常停顿那么进展告警，并监控切换状态。

✧监控双中心之间手机定位消息同步状态。

✧对双中心手机定位效劳器的链路情况进展监控。

8.短信报警效劳监控

✧对两个中心的短信报警效劳的运行状态进展监控；

✧当短信报警效劳异常停顿那么进展告警，并监控切换状态。

✧监控双中心之间短信报警消息同步状态。

✧对双中心手机短信报警效劳器的链路情况进展监控。

9.报警用户信息效劳监控

✧对两个中心的报警用户信息效劳的运行状态进展监控；

✧当报警用户信息效劳异常停顿那么进展告警，并监控切换状态。

✧监控双中心之间报警用户信息的消息同步状态。

✧对双中心手机报警用户信息效劳器的链路情况进展监控。

10.数据库同步监控

✧对双中心数据库同步进展监控；

✧当主用数据库的软件、硬件发生故障时进展告警；

✧当主备库切换时，对切换的全过程进展监控；

✧当启用数据库离线模式时，对所有暂存效劳进展监控；

11.WEB效劳监控

✧对查询统计系统等WEB应用效劳的监控，监控效劳运行状态。

12.通信链路状态监控

通信链路状态监控主要是2M中继线路、2MSDH传输线路、信令链路监控等专用链路的实时监测监控。

✧在拓扑上展现设备、机箱、远端以及链路，并通过子网进展划分。

✧所有的设备在拓扑上都有节点对应，所有的远端设备在拓扑上都有节点对应，默认情况下，局端板卡不在拓扑上显示。

✧拓扑实时显示资源的当前状态。

3.2.3.参与者列表

3.3.故障告警模块

3.3.1.场景描述

对异常事件及故障进展客户端告警以及短信告警〔需要与短信平台对接〕。

颜色告警和声音告警并提示负责人及联系方式信息。

3.3.2.用例分析

1.监控模块应当具备故障告警功能

2.能够自定义告警的条件和级别，并能够定义组合条件的告警

3.提供防误报机制，提供防误报机制〔缓冲机制〕，只有在故障时间超过限值后，才对其作为故障处理。

对于在缓冲时间恢复的故障，不作为故障处理〔但需要记录〕。

4.提供故障告警的编辑界面，要求方便易用

5.提供多种故障告警方式：

a）声光告警：

在客户端上通过声音和颜色的方式，提醒当前有故障需要处理

b）短信告警：

对于严重告警，需要通过短信模块，将故障短信及时发送到维护人员的手机上

c）对承受理台和其他系统：

由于监控模块是B/S构造，声光告警无法保证能及时得到处理。

监控模块应当对承受理台或大屏系统，在界面上显示严重的故障信息，从而保证故障能及时得到处理

6.在用户修复故障之前，将反复进展故障告警，从而保证故障能得到及时的处理

告警策略可以扩展，常用的告警策略有超过告警值即告警、一段时间超过告警值几次即告警、一段时间最多只告警一次。

3.3.3.参与者列表

3.3.4.用例描述

3.4.数据配置管理模块

3.4.1.场景描述

对双中心平台的坐席、排队调度机、故障阀值、平安权限进展配置并且同步。

3.4.2.用例分析

1.提供系统配置功能：

a）能够添加、删除、编辑各种监控节点信息

b）配置各类数据的告警阈值和告警条件

c）配置各类软件信息

2.监控模块应当提供方便易用的监控维护界面

3.仅有授权用户可以进展维护操作

提供设备管理、监控管理、告警管理、配置同步、权限分配和系统管理等功能。

3.4.3.参与者列表

3.5.故障切换管理模块

3.5.1.场景描述

数据库一键切换管理。

调度机话路切换管理。

通信平台切换管理。

切换专设权限认证管理。

3.5.2.用例分析

1.平安管理

a）在进展任何切换操作前，必须对用户进展身份认证。

b）所有的切换操作必须记录到文件日志和数据库记录中，便于事后核实。

2.交换机汇接模式切换：

a）在正常情况下，运行监控模块实时监视排队交换机和CTI系统的运行状态

b）当某个中心的CTI系统或者应用系统整体瘫痪，此时需要将该中心交换机的所有报警呼叫都切换到另一个中心的排队交换机进展处理

c）可以通过监控模块管理客户端发出切换指令到交换机，切换到汇接模式。

系统修复后，可以通过切换指令切回正常模式

3.数据库效劳器主备切换：

a）在正常情况下，运行监控模块实时监视中心接警坐席的数据库连接情况

b）一旦需要从主用数据库切换到备用数据库，可以通过监控模块管理客户端下达切换指令，通知各接警坐席切换至备用数据库

c）各接警坐席收到切换指令后，断开主用数据库的连接，自动连接至备用数据库

d）监控模块发送切换指令时，CTI〔呼入记录〕、二级分配效劳器等效劳器和应用程序也一并进展主备数据库的切换

从备用数据库切换至主用数据库，监控模块管理客户端通过再次发送切换指令，即可以到达目标

3.5.3.参与者列表

3.6.数据接口

3.6.1.场景描述

效劳器监控的数据由第三方提供，然后开发接口对接。

短信平台由市局提供，然后开发接口对接。

3.6.2.用例分析

1.效劳器监控的数据具体指那些数据？

3.6.3.参与者列表

3.7.故障处理

3.7.1.场景描述

对故障处理结果进展记录和查询。

3.7.2.用例分析

故障应该进展分类。

对故障进展记录要考虑到网络〔离线、高延时、频繁掉包〕的情况。

记录信息应该完整，设备运行地点、设备编号、故障时间，故障类型等。

查询要考虑组合条件过滤。

3.7.3.参与者列表

4.系统非功能性需求

4.1.易用性需求

4.1.1.方便增加监测设备

1）提出者信息

a）提出者

b）提出者分类

工程经理

c）提出时间

-IOMSV2.0立项阶段

2）提出原因和考虑

系统上线以后所有监测设备一般都处于被监测状态，不会被停顿，这时候用户可能还会增加新的监测设备。

3）易用性需求描述

可以在整个系统处于被监测状态下增加新的监测设备而不需要停顿监测所有设备。

4.1.2.方便删除监测设备

系统上线以后所有监测设备一般都处于被监测状态，不会被停顿，这时候用户可能会删除一些目前正处于监测状态的设备。

可以在整个系统处于被监测状态下删除某个监测设备〔可以直接删除或者先停顿被监测设备后再删除〕而不需要停顿监测所有的设备。

4.1.3.方便定位故障或者异常设备

系统上线以后所有监测设备一般都处于被监测状态，不会停顿，被监测的设备大局部时间处于正常状态，但肯定会有一些被监测设备会出现故障或者异常，这时我们需要了解是哪些设备出现了故障或者异常。

在系统运行的过程中如果出现故障或者异常设备，能够很方便的定位到具体出现故障或者异常的设备。

4.1.4.监测设备在启动与停顿监测之间方便转换

大局部时间整个系统的所有监测设备都处于被监测状态，但是某一时刻可能会由于某种原因想停顿监测某个设备或者启动监测某个设备，在操作的过程中对其它监测设备不产生影响。

可以对单个设备进展启动监测和停顿监测；

在启动监测的时候能够重新读取该监测设备的最新配置。

4.2.性能、并发性需求

系统在满足软硬件环境约束的条件下，对系统整体性能及并发性要求要满足以下几点：

1.满足5000小时不连续工作；

2.满足同时监测100个终端设备；

3.满足100个用户同时访问监测页面；

4.数据采集间隔时间大于和等于5秒。

4.2.1.对性能及并发性的特殊要求

4.2.1.1.监测数据的存储性能要求

系统可以同时监测的设备比拟多，一个监测设备下又包含很多测点，测点下还包含多个监测指标，每个监测指标都需要存储到数据库中，这样就会导致同一时间或一段时间会产生大量的数据需要存储。

3）性能特殊要求描述

所有监测的数据都要保存到数据库中不能遗漏，保存数据的性能和监测数据的性能相匹配。

4.3.扩展性需求

4.3.1.采集和监控效劳器的集群支持

本系统未来将会监测成千上万的监测设备，单台效劳器无法支撑和处理这么大的数据量和并发量。

3）扩展性需求描述

当系统监测设备的个数到达一定数量级，单台效劳器无法支撑和处理这么大的数据量和并发量时，可以通过集群的方式解决。

4.3.2.支持公司AFP平台的整合

公司JAVA方向的统一平台AFP已经立项，本系统属于JAVA方向，所以未来本系统会和AFP平台整合到一起。

能通过少许的改动将AFP平台整合进来。

4.3.3.支持公司单点登录系统的整合

公司的单点登录系统已经立项，未来公司部所有系统都需要整合公司的单点登录系统。

不需要再单独开发登录系统，通过少许的改动就可以将公司单点登录系统整合进来。

4.3.4.支持对物联网智能设备的直接监测

目前系统是通过ICD设备来间接监测物联网智能设备的，有一定的局限性，两种方法都满足，可以增加系统的灵活性。

通过扩展可以满足对物联网智能设备的直接监测。

4.4.平安及性需求

4.4.1.敏感数据加密

在一个软件系统中，用户的密码是最重要的，用户密码外泄将严重威胁到系统的平安、系统重要数据的平安，为此系统应该提供对用户密码数据的加密保护功能。

3）平安性需求描述

在系统中需要用户输入密码的地方以“*〞显示，用户密码在网络传输和存储时应加密处理，防止用户密码外泄。

4.4.2.敏感操作进展确认

敏感操作对系统的影响较大，可能导致系统数据的丧失。

对敏感操作进展用户密码再确认。

4.5.可靠性需求

4.5.1.运行可靠性

运维管理是一个长期的过程，系统上线后会长时间不连续运行。

3）可靠性需求描述

系统至少保证1000小时不连续正常运行；

对于功能性错误要给出友