智能运维管理系统-需求规格说明书-V2.0.doc

智能运维管理系统V2.0需求规格说明书 文件状态： 草稿 正在修改 正式发布受控状态： 受控 非受控当前版本：文 件 名：作 者：审 核 人：批 准 人：保密等级：批准日期：修订日期版本号修订说明修订人目 录 1.文档介绍51.1.文档目的51.2.文档范围51.3.读者对象51.4.参考文档51.5.术语与缩写解释52.系统概述62.1.系统建设目标62.2.系统总体结构72.3.用户的特点72.4.设计和实现上的限制83.系统功能性需求83.1.双活中心工作运行状态监控模块83.1.1.场景描述83.1.2.用例分析83.1.3.参与者列表83.2.专用监控功能模块93.2.1.场景描述93.2.2.用例分析93.2.3.参与者列表103.3.故障告警模块103.3.1.场景描述103.3.2.用例分析113.3.3.参与者列表113.3.4.用例描述113.4.数据配置管理模块113.4.1.场景描述113.4.2.用例分析113.4.3.参与者列表123.5.故障切换管理模块123.5.1.场景描述123.5.2.用例分析123.5.3.参与者列表133.6.数据接口133.6.1.场景描述133.6.2.用例分析133.6.3.参与者列表133.7.故障处理133.7.1.场景描述133.7.2.用例分析133.7.3.参与者列表144.系统非功能性需求144.1.易用性需求144.1.1.方便增加监测设备144.1.2.方便删除监测设备144.1.3.方便定位故障或者异常设备154.1.4.监测设备在启动与停止监测之间方便转换154.2.性能、并发性需求154.2.1.对性能及并发性的特殊要求164.3.扩展性需求164.3.1.采集和监控服务器的集群支持164.3.2.支持公司AFP平台的整合164.3.3.支持公司单点登录系统的整合174.3.4.支持对物联网智能设备的直接监测174.4.安全及保密性需求184.4.1.敏感数据加密184.4.2.敏感操作进行确认184.5.可靠性需求184.5.1.运行可靠性184.5.2.数据可靠性194.6.可维护性需求194.6.1.监测设备配置优化194.7.软硬件环境约束204.8.系统备份与恢复要求214.9.系统日志214.10.其它需求215.外部接口说明215.1.短信发送接口215.2.应用软件服务监测接口211. 文档介绍1.1. 文档目的在智能运维管理系统V2.0立项建议书的基础上对各个功能模块做出详细的需求分析，为项目后续的设计和开发提供依据。1.2. 文档范围本文档包括服务器监测、数据库监测、交换机监测、21平台监测、物联网智能设备监测、应用软件服务监测、个性化主题展现、配置管理的需求规格说明，同时也包括整个系统平台的建设目标、总体结构、网络结构、系统接口描述、用户界面需求和软硬件环境方面的需求规格说明。1.3. 读者对象1. -IOMS V2.0项目的系统设计人员、系统开发人员、系统测试人员以及配置管理人员；2. 公司内部-IOMS V2.0项目的其干系人、领导、专家等。1.4. 参考文档智能运维管理系统V1.0立项建议书，2013-09物联网智能数据采集和控制平台需求规格说明书，2012-03监控系统V2.0用户指南，2011-111.5. 术语与缩写解释缩写、术语解 释IOMS智能运维管理系统ICD物联网智能数据采集设备物联网智能设备连接到物联网智能数据采集设备上的智能设备，如传感器、智能空调、温湿度计等。测点系统采集的数据点，如温度、湿度都算一个测点。21平台作为CTI中间件平台，是整个呼叫中心的一个基础软件平台，为整个系统提供底层服务核心支撑，主要包括消息通信服务、CTI服务、ACD服务、统一接入服务等。Modbus TCP协议Modbus TCP协议是简单的、中立厂商的用于管理和控制自动化设备的Modbus系列通讯协议的派生产品，是作为一种（实际的）自动化标准发行的。2. 系统概述2.1. 系统建设目标公司目前在监控系统方向有两个产品，都是基于B/S结构，一个是监控系统，另外一个是物联网智能设备监控系统。监控系统是公司提出的系统集成监控解决方案，其主要目标是监控IT系统中的各种信息节点(服务器、数据库、交换机、21平台)的运行状态，提供故障的显示、告知，以及故障恢复功能。物联网智能设备监控系统是上海市的科研课题，由硬件（数据采集与控制终端简称ICD）和软件（嵌入式软件和智能设备监控系统）两部分组成。ICD设备提供和有线或者无线终端设备的接口，ICD设备内的嵌入式系统负责终端设备的数据采集和控制、数据处理和封装以及对通信协议的转换，与上层软件统一采用Modbus TCP协议进行通信。智能设备监控系统通过Modbus TCP协议收集终端设备测点的数据，监控ICD设备及终端设备的状态，个性化显示监测数据和状态，在监测数据和状态异常情况下通过声、光、短信告警，提供历史数据和历史事件查询，并可以通过配置的方式很方便的实现对各种不同类型、不同通信协议终端设备的监控。监控系统搭配公司其它产品在湖北、江苏等几个省份部署，物联网智能设备监控系统通过课题组专家的验收，在监控系统使用的过程中以及物联网智能设备监控系统开发和验收的过程中，收到用户、领域专家、公司领导、公司专家和潜在用户的意见和建议，通过总结和分析这些意见和建议，得出本系统建设的目标如下：1. 基于B/S架构实现运维管理系统的整体框架；2. 实现对Windows操作系统的服务器进行监测；3. 实现对SQL Server和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中继线路、2M SDH传输线路、信令链路监控等专用链路的实时监测监控。 在拓扑上展现设备、机箱、远端以及链路，并通过子网进行划分。 所有的设备在拓扑上都有节点对应，所有的远端设备在拓扑上都有节点对应，默认情况下，局端板卡不在拓扑上显示。 拓扑实时显示资源的当前状态。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) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑系统上线以后所有监测设备一般都处于被监测状态，不会被停止，这时候用户可能还会增加新的监测设备。3) 易用性需求描述可以在整个系统处于被监测状态下增加新的监测设备而不需要停止监测所有设备。4.1.2. 方便删除监测设备1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑系统上线以后所有监测设备一般都处于被监测状态，不会被停止，这时候用户可能会删除一些目前正处于监测状态的设备。3) 易用性需求描述可以在整个系统处于被监测状态下删除某个监测设备（可以直接删除或者先停止被监测设备后再删除）而不需要停止监测所有的设备。4.1.3. 方便定位故障或者异常设备1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑系统上线以后所有监测设备一般都处于被监测状态，不会停止，被监测的设备大部分时间处于正常状态，但肯定会有一些被监测设备会出现故障或者异常，这时我们需要了解是哪些设备出现了故障或者异常。3) 易用性需求描述在系统运行的过程中如果出现故障或者异常设备，能够很方便的定位到具体出现故障或者异常的设备。4.1.4. 监测设备在启动与停止监测之间方便转换1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑大部分时间整个系统的所有监测设备都处于被监测状态，但是某一时刻可能会由于某种原因想停止监测某个设备或者启动监测某个设备，在操作的过程中对其它监测设备不产生影响。3) 易用性需求描述可以对单个设备进行启动监测和停止监测；在启动监测的时候能够重新读取该监测设备的最新配置。4.2. 性能、并发性需求系统在满足软硬件环境约束的条件下，对系统整体性能及并发性要求要满足以下几点：1. 满足5000小时不间断工作；2. 满足同时监测100个终端设备；3. 满足100个用户同时访问监测页面；4. 数据采集间隔时间大于和等于5秒。4.2.1. 对性能及并发性的特殊要求4.2.1.1. 监测数据的存储性能要求1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑系统可以同时监测的设备比较多，一个监测设备下又包含很多测点，测点下还包含多个监测指标，每个监测指标都需要存储到数据库中，这样就会导致同一时间或一段时间会产生大量的数据需要存储。3) 性能特殊要求描述所有监测的数据都要保存到数据库中不能遗漏，保存数据的性能和监测数据的性能相匹配。4.3. 扩展性需求4.3.1. 采集和监控服务器的集群支持1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑本系统未来将会监测成千上万的监测设备，单台服务器无法支撑和处理这么大的数据量和并发量。3) 扩展性需求描述当系统监测设备的个数达到一定数量级，单台服务器无法支撑和处理这么大的数据量和并发量时，可以通过集群的方式解决。4.3.2. 支持公司AFP平台的整合1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑公司JAVA方向的统一平台AFP已经立项，本系统属于JAVA方向，所以未来本系统会和AFP平台整合到一起。3) 扩展性需求描述能通过少许的改动将AFP平台整合进来。4.3.3. 支持公司单点登录系统的整合1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑公司的单点登录系统已经立项，未来公司内部所有系统都需要整合公司的单点登录系统。3) 扩展性需求描述不需要再单独开发登录系统，通过少许的改动就可以将公司单点登录系统整合进来。4.3.4. 支持对物联网智能设备的直接监测1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑目前系统是通过ICD设备来间接监测物联网智能设备的，有一定的局限性，两种方法都满足，可以增加系统的灵活性。3) 扩展性需求描述通过扩展可以满足对物联网智能设备的直接监测。4.4. 安全及保密性需求4.4.1. 敏感数据加密1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑在一个软件系统中，用户的密码是最重要的机密，用户密码外泄将严重威胁到系统的安全、系统重要数据的安全，为此系统应该提供对用户密码数据的加密保护功能。3) 安全性需求描述在系统中需要用户输入密码的地方以“*”显示，用户密码在网络传输和存储时应加密处理，防止用户密码外泄。4.4.2. 敏感操作进行确认1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑敏感操作对系统的影响较大，可能导致系统数据的丢失。3) 安全性需求描述对敏感操作进行用户密码再确认。4.5. 可靠性需求4.5.1. 运行可靠性1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑运维管理是一个长期的过程，系统上线后会长时间不间断运行。3) 可靠性需求描述系统至少保证1000小时不间断正常运行；对于功能性错误要给出友好提示；系统错误恢复时间小于1小时/次。4.5.2. 数据可靠性1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑本系统提供的信息是提供给系统运维管理员做决策使用的，所以数据的可靠性非常重要。3) 可靠性需求描述采集的数据要与监测设备的实际数据相一致；监测显示的数据要与采集的数据相一致。4.6. 可维护性需求4.6.1. 监测设备配置优化1) 提出者信息a) 提出者b) 提出者分类项目经理c) 提出时间-IOMS V2.0立项阶段2) 提出原因和考虑项目实施的过程中会配置很多监测设备，且这些监测设备的类型大部分相同或者分为几类，需要考虑配置的优化。3) 可维护性需求描述对于同一类监测设备的配置可以复制然后再做细小的修改；对于类型不同的监测设备的配置项最好给出枚举项供选择。4.7. 软硬件环境约束1) 硬件环境要求类别标准配置最低配置备注监测服务器2.4G+ CPU 四核16G+ RAM500G+ Disk100M+ Network2.4G CPU 双核4G RAM100G Disk100M Network数据库服务器2.4G+ CPU 四核16G+ RAM500G+ Disk100M+ Network2.4G CPU 双核4G RAM100G Disk100M Network采集服务器2.4G+ CPU 四核16G+ RAM500G+ Disk100M+ Network2.4G CPU 双核4G RAM100G Disk100M Network客户端2G+ CPU4G+ RAM160G+ Disk100M+ Network1.6G CPU2G RAM80G Disk100M Network2) 软件环境要求a) 服务器操作系统：Windows Server 2008 R2b) 客户端操作系统：Windows 7/ Windows 8/ Windows 8.1/ Windows 10c) 浏览器：IE8以上版本/Google Chrome 55.0以上版本d) 数据库：MongoDB 3.4.0以上版本软件版本备注Windows Server 2008 R2Windows XP / Windows 7IE8 / IE9操作系统包含MongoDB3.4.0以上开源Spring Boot1.5.6以上开源Tomcat8.0以上开源IIS7.0以上免费4.8. 系统备份与恢复要求数据库需要每天进行一次增量备份，每周进行一次完整备份，该备份为系统自动备份，如出现数据库异常，可恢复至上一个备份点数据库。保存期为一月，超过一周的数据库转移到计算机外部介质中，超过一个月的备份数据可删除。应用程序每次改动前需要备份，该备份为人工备份，如出现异常可恢复最近一次的备份。保存最近五次的备份，超过五次的备份可删除。4.9. 系统日志1. 日志文件的类型1) 用户登录日志2) 用户操作日志3) 系统错误日志2. 日志文件的保存方式1) 创建新的日志文件并自动增长大小2) 达到最大容量时重新创建新的日志文件3) 日志文件个数达到最大时循环覆盖最早的日志文件3. 日志文件的访问控制根据日志文件的重要性，设置访问控制权限。4.10. 其它需求无5. 外部接口说明5.1. 短信发送接口通过两种方式实现系统短信发送的功能：1. 采用UDP方式向短信服务平台发送规定格式的消息，短信服务平台解析该消息完成短信发送；2. 直接调用短信猫提供的DLL发送指令，短信猫根据该指令完成短信发送。5.2. 应用软件服务监测接口1. 本系统制定应用软件服务监测接口的参数、返回值以及传递参数、返回值的格式；第三方应用软件服务根据该接口的规范实现该接口。其中专业理论知识内容包括：保安理论知识、消防业务知识、职业道德、法律常识、保安礼仪、救护知识。作技能训练内容包括：岗位操作指引、勤务技能、消防技能、军事技能。二培训的及要求培训目的安全生产目标责任书为了进一步落实安全生产责任制，做到“责、权、利”相结合，根据我公司2015年度安全生产目标的内容，现与财务部签订如下安全生产目标：一、目标值：1、全年人身死亡事故为零，重伤事故为零，轻伤人数为零。2、现金安全保管，不发生盗窃事故。3、每月足额提取安全生产费用，保障安全生产投入资金的到位。4、安全培训合格率为100%。二、本单位安全工作上必须做到以下内容： 1、对本单位的安全生产负直接领导责任，必须模范遵守公司的各项安全管理制度，不发布与公司安全管理制度相抵触的指令，严格履行本人的安全职责，确保安全责任制在本单位全面落实，并全力支持安全工作。 2、保证公司各项安全管理制度和管理办法在本单位内全面实施，并自觉接受公司安全部门的监督和管理。 3、在确保安全的前提下组织生产，始终把安全工作放在首位，当“安全与交货期、质量”发生矛盾时，坚持安全第一的原则。 4、参加生产碰头会时，首先汇报本单位的安全生产情况和安全问题落实情况；在安排本单位生产任务时，必须安排安全工作内容，并写入记录。 5、在公司及政府的安全检查中杜绝各类违章现象。 6、组织本部门积极参加安全检查，做到有检查、有整改，记录全。 7、以身作则，不违章指挥、不违章操作。对发现的各类违章现象负有查禁的责任，同时要予以查处。 8、虚心接受员工提出的问题，杜绝不接受或盲目指挥；9、发生事故，应立即报告主管领导，按照“四不放过”的原则召开事故分析会，提出整改措施和对责任者的处理意见，并填写事故登记表，严禁隐瞒不报或降低对责任者的处罚标准。 10、必须按规定对单位员工进行培训和新员工上岗教育；11、严格执行公司安全生产十六项禁令，保证本单位所有人员不违章作业。 三、 安全奖惩： 1、对于全年实现安全目标的按照公司生产现场管理规定和工作说明书进行考核奖励；对于未实现安全目标的按照公司规定进行处罚。 2、每月接受主管领导指派人员对安全生产责任状的落