智能运维管理系统需求规格说明书V20讲课教案文档格式.docx

智能运维管理系统需求规格说明书V20讲课教案文档格式.docx

《智能运维管理系统需求规格说明书V20讲课教案文档格式.docx》由会员分享，可在线阅读，更多相关《智能运维管理系统需求规格说明书V20讲课教案文档格式.docx（24页珍藏版）》请在冰点文库上搜索。

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小时不间断正常运行；

对于功能性错误要给出友好提示；

系统错误恢复时间小于1小时/次。

4.5.2.数据可靠性

本系统提供的信息是提供给系统运维管理员做决策使用的，所以数据的可靠性非常重要。

采集的数据要与监测设备的实际数据相一致；

监测显示的数据要与采集的数据相一致。

4.6.可维护性需求

4.6.1.监测设备配置优化

项目实施的过程中会配置很多监测设备，且这些监测设备的类型大部分相同或者分为几类，需要考虑配置的优化。

3）可维护性需求描述

对于同一类监测设备的配置可以复制然后再做细小的修改；

对于类型不同的监测设备的配置项最好给出枚举项供选择。

4.7.软硬件环境约束

1）硬件环境要求

类别

标准配置

最低配置

备注

监测服务器

2.4G+CPU四核

16G+RAM

500G+Disk

100M+Network

2.4GCPU双核

4GRAM

100GDisk

100MNetwork

数据库服务器

采集服务器

2.4GCPU