【毕业学位论文】（Word原稿）业务运维系统在企业中的应用-软件工程

摘 要 I 中图分类号： 学校代码： 10055 密级： 硕 士 专 业 学 位 论 文 业务运维系统在企业中的应用 in 开大学研究生院 二一 三 年 五 月 摘 要 随着数字化、信息化和网络化的快速发展，各国企业对信息化管理平台的需求急剧上升。尤其经过多年的信息化建设和发展，多数企业都在应用办公自动化系统、邮件系统等日常办公平台以及一些业务支撑平台，当业务系统出现异常时，往往给信息管理团队的事故分析和追踪产生了很大的影响。所以，只摘 要 建设或不断完善企业的信息化管理平台，才能改善企业绩效。 天津市建工集团（控股）有限公司 (以下简称建工集团 )的网络系统已经形成多应用、跨地域的大规模综合信息化服务城域网络系统，为建工集团业务发展提供了充分的支持和保障。但是，建工集团信息系统运行维护的管理水平相对滞后，缺乏整体信息管理水平较低，缺乏统一的监控管理平台，缺乏运维服务业务流程保障，缺乏信息化资产管理的技术手段，没有建立一套统一的知识管理系统。 为此，很有必要建设一套以 准的业务运维管理系统。帮助企业的各个业务系统的各项信息化资源及各项信息化服务实现统一、集中、标准、规范的管理以及监控、预警和控制，提高业务运维管理能力和效率，提升信息化服务水平，为企业信息化系统提供稳定、可靠的支撑和保障。 在本期项目中的建设重点是业务运维模式的建立，综合考虑业内普遍的信息化管理方式，业务运维模式更具有简单管理、动态展现、实时统计分析、基于业务自上而下形成自动化事故分析等特点。尤其提出了“三步走”式的监控机制，当出现故障时通过图形化的展示界面即可快速定位到故障点。第一步：排除 周边影响因素。第二步：查清平台级影响因素。第三步：通过业务运维管理系统的服务台，帮助建工集团实现统一故障记录和管理，并通过与监控系统的无缝连接，有监控系统发现问题故障，自动触发相关运维工单，最终实现自动运维管理，最终实现 程化、自动化。 关键字： 信息化 监控 业务运维 of of in of to a or of of to to as of of is of of is of of of of of to a it is to a of of of of to to to of of in of is to of V on of to In to to of T 录 V 目 录 摘 要 . I . 一章 绪论 . 7 第一节 引言 . 7 第二节 项目背景 . 7 第二章 业务运维管理系统需求分析 . 11 第一节 需要解决的问题 . 11 第二节 服务台 . 11 第三节 服务目录 . 12 第四节 事件管理 . 13 第五节 问题管理 . 14 第六节 配置管理 . 15 第七节 知识管理 . 16 第八节 变更管理 . 16 第九节 发布管理 . 17 第十节 服务级别管理 . 17 第十一节 供应商管理 . 18 第十二节 资产管理 . 19 第十三节 监控管理 . 19 第十四节 辅助管理 . 22 第三章 业务运维管理系统设计分析 . 25 第一节 可行性分析 . 25 目 录 二节 系统结构分析 . 26 第三节 系统设计原则 . 31 第四节 开发平台与开发工具 . 32 第四章 业务运维管理系统详细设计 . 36 第一节 系统架构 . 36 第二节 服务台业务数 据 . 37 第三节 服务目录业务数据 . 38 第四节 事件管理业务数据 . 40 第五节 问题管理业务数据 . 41 第六节 配置管理业务数据 . 43 第七节 知识管理业务数据 . 44 第八节 变更管理业务数据 . 46 第九节 发布管理业务数据 . 47 第十节 服务级别管理业务数据 . 49 第十一节 供应商管理业务数据 . 50 第十二节 资产管理业务数据 . 51 第十三节 辅助流程业务数据 . 53 第十四节 二次 开发类定义 . 54 第五章 业务运维管理系统测试与实现分析 . 57 第一节 测试概况 . 57 第二节 测试用例 . 57 第三节 实现主要功能描述 . 76 第六章 总结与展望 . 93 第一章 绪论 第一节 引言 随着数字化、信息化和网络化的快速发展，各国企业对信息化管理平台的需求急剧上升。企业的信息化建设，被公认是一项十分庞大且复杂的系统工程，不同行业、不同企业规模、不同建设阶段都会产生不同的建设需求。尤其经过多年的信息化建设和发展，多数企业当前的业务系统主要采用 B/S 结构进行搭建，应用范围主要涉及到办公自动化系统、邮件系统等日常办公平台以及一些业务支撑平台，且随着业务部门对系统需求的增多，这些业务系统都呈现出结构复杂、关联 备数量庞大、冗余架构设计等 特点，当业务系统出现异常时，往往给信息管理团队的事故分析和追踪产生了很大的影响。所以，只有建设或不断完善企业的信息化管理平台，才能改善企业绩效。这就意味着企业要转变观念，寻找新的时代需求，找准企业追求方向，采用更加先进的思想和方法来管理企业。 第二节 项目背景 题提出 天津市建工集团（控股）有限公司 (以下简称建工集团 )是国资委直接监管的国有独资大型控股集团公司 。 2001 年改制为天津市建工集团（控股）有限公司，其前身是成立于 1952 年的天津市建筑工程局， 是资产与生产混合经营的资金、技术和管理密集的 国有大型控股集团。 经过 60 余年的奋斗，建工集团已经逐步发展为天津建筑行业的领军集团。 是中国 500 强，天津市 100 强和中国承包商及工程设计双 60 强企业之一 。 建工集团 的信息化建设历时八年，截止 2012 年 8 月集团公司网络系统已经发展形成覆盖集团公司所属 123 个办公地点、 132 家分支机构（含外地 9 家） ，承载 基础施工 、 资本运营 、财务管理、物资管理、资产管理、视频会议系统、协同办公管理等 22 个信息系统的综合业务服务平台，多应用、跨地域的大规模综合信息化服务城域网络系统，为集团业务发展提供了充分的支持和保障。但是，受资 源条件和历史原因影响，集团信息系统运行维护的管理水平相对滞后，整体信息管理水平较低。主要存在以下几个问题： 一、缺乏统一的监控管理平台。目前采用通过多个应用平台分别监控机房环境、服务器状态、网络链路状态等情况，无法及时掌握整体运行状况，也没有相应的问题故障预警方法，造成出现故障和问题时不能及时有效的予以处理。 二、运维服务管理缺乏流程保障。维护人员忙于救火，缺乏主动服务。信息化运维缺乏绩效考核标准，职责不清。缺乏有效手段监督人员解决故障的处理效率和处理质量。解决处理故障问题时缺乏协作。 三、信息化资产管理缺 乏技术手段。 建工集团 信息化设备、软件资产众多，受条件限制不能做到定期巡检排查，设备台帐 层级多， 不能方便反映设备维修历史记录；信息化系统、软件的升级、变更等缺乏统一的登记记录；信息化设备采购、调拨、报废等无法形成统一的管理流程。 四、尚未建立统一的知识库，知识分散。目前的问题及故障处理主要依靠工作人员经验和技术能力，但人员岗位变动、流失等因素造成故障和问题不能及时有效地得到处理。 由于上述 现实中存在的问题，严重限制和制约 建工集团 运维服务管理水平，随着 建工集团 信息化建设和发展，建立完善统一的 建工集团 信息化运维服 务管理 平台系统，保障信息化业务系统稳定运行，为 建工集团 提供更加坚实的信息化基础架构，确保出现各种问题和故障时，能够快速有效地应对，提升 建工集团 信息化运维服务满意度，实现由被动式维护向主动式，进而向预防式转变；维护的对象由面向网络和设备转变为面向客户和服务；管理的范围由各级网络分段管理转变为端到端的全程管理，已经成为 建工集团 信息化建设发展中的迫切任务。 设目标 业务运维管理系统建设的总体目标是要以 准为指南， 按照现代企业信息化发展的趋势，根据集团的实际需要和具体情况， 对企 业的各 分支 业务系统的 各种 信息化资源及各项信息化服务实现统一、集中、标准、规范的管理以及监控、预警和控制，提高运维管理能力和效率，提升信息化服务水平，为企业信息化系统提供稳定、可靠的支撑和保障，为企业的信息化发展提供详实、准确的信息化基础资料。整个系统应具有良好的先进性、开放性、实用性、经济性、扩展性、稳定性和安全性。 第一阶段 ： 建设统一集中的 7*24小时地全面主动地监控集团的 信 基础设施和应用系统，在出现故障时能及时报警，管理人员可以 借助 平台，迅速找到故障根源，及时 了解情况，根据实 情 解决 问题 ，尽最大程度减少 务中断时间，并通过综合实时监控展示，为集团领导、运维管理层、支持团队提供不同的视图，帮助其进行管理决策和运维支持工作。 第二阶段： 以 准为指导，结合 建工 集团实际的运维情况，设计满足建工集团 运维需求的事件管理、问题管理、配置管理、变更管理、知识库管理及 服务报告管理等相关流程，规范 建工 集团的 维服务管理的日常工作规范与工作流程，有效整合信息中心、外包服务商、厂商等各种运维资源，建立一套面向 升 量与服务水平。 第三阶段：建设 基于第二部分梳理的运维服务流程，在已实现的监控管理平台的基础上，通过建设部署 化与落实事件管理、问题管理、配置管理、变更管理、知识库管理及服务报告等 维服务管理流程，为 强对运维工作质量、运维效率的管控，规范提升运维服务工作的标准化，降低异常操作、异常变更风险。 第二章 业务运维管理系统 需求分析 第一节 需要解决的问题 一、缺乏统一的监控管理平台。目前采用通过多个应用平台分别监控 机房环境、服务器状态、网络链路状态等情况，无法及时掌握整体运行状况，也没有相应的问题故障预警方法，造成出现故障和问题时不能及时有效的予以处理。 二、运维服务管理缺乏流程保障。维护人员忙于救火，缺乏主动服务。信息化运维缺乏绩效考核标准，职责不清。缺乏有效手段监督人员解决故障的处理效率和处理质量。解决处理故障问题时缺乏协作。 三、信息化资产管理缺乏技术手段。 建工集团 信息化设备、软件资产众多，受条件限制不能做到定期巡检排查，设备台帐不能方便反映设备维修历史记录；信息化系统、软件的升级、变更等缺乏统一的登记记录；信 息化设备采购、调拨、报废等无法形成统一的管理流程。 四、尚未建立统一的知识库，知识分散。目前的问题及故障处理主要依靠工作人员经验和技术能力，但人员岗位变动、流失等因素造成故障和问题不能及时有效地得到处理。 第二节 服务台 为了满足集团内部业务流程的架构需要，和 集团处室 条条 、集团与下属企业框框上的可操作性， 在 设计 业务运维管理系统的体系时，服务台应作为信息中心与用户间的单点联系接口。服务台 总体上要 负责管理事件和服务请求， 实时更新、展示硬件监控信息， 随时 实现与用户的沟通。 本着这样的总体设计理念， 服务台 在 设计 中需 要 满足 五方面的要求，即 支持通过电话、网络、电子邮件等方式向用户提供单点联系接口；支持定制工单分发策略，可以选择自动分发、手动分发等不同策略；支持跟踪服务请求的处理情况，确保所有服务请求能够以闭环方式结束；支持根据服务请求，自动关联出相关的知识库记录；支持与短信平台对接，用邮件或短信方式将事件通知给相关人员。 通过图 明 服务台的作用和重要位置。 在系统 运行 实施时，服务台的服务范围为集团公司 本部机关处室 和 子公司、分公司、所属基层单位 乃至项目组 。 图 三节 服务目录 服务目录是业务运维管理系统 中， 采用定义信息中心所提供服务的种类以及服务，能够在集团的信息化体系的服务平台中，促使信息中心与业务部门之间建立良好的服务关系。因此，对于服务目录的设计，既要考虑到简洁、清晰，业务部门易于阅读 ，又要根据 系统相关性分析功能，通过梳理信息，根据功能模块定 义，应用系统的 处理，列出服务编号、服务名称、服务描述、服务流程、服务相关人等 。 在系统实施时，服务目录功能的实现范围 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 。 第四节 事件管理 事件管理应支持快速记录、跟踪处理集团公司范围内的 础设施和应用系 统中的突发事件，它在业务运维管理系统中 是最为重要的部分， 事件管理 的必要 功能 应支持定义事件记录的分类和分级规则，根据指定的事件分发和事件升级策略，自动分派到相应的运维支持组或个人； 而且要支持事件记录与问题管理、知识库等功能关联；支持和配置管理数据库相关联，显示当前配置项与其它配置项之间的关联关系，帮助快速评估事件影响；还需要扮演服务台的角色，以满足后继 维管理平台上线要求。 在系统实施时，事件管理功能的覆盖范围为 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 。 通过图 件管理的处理和响 应流程。 图 五节 问题管理 问题管理应支持对集团公司范围内各类问题进行跟踪处理，提出解决方案预防已知问题的再次发生。 在集团 的 业务运维管理系统的体系设计时，问题管理 要支持定义问题分派规则，可根据问题的严重级别和影响级别，自动分派问题到指定的单位或个人； 能够支持将当前问题自动关联相关事件、变更、发布、配置、知识库等信息；并且 系统实施时，问题管理功能的覆盖范围为 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 。 通过图 明问题管理的工作流程和 如何 解决 识别错误。 图 六节 配置管理 配置管理功能 在集团 的 业务运维管理系统 中，应该做到 支持记录集团范围内的 础设备设施 和应用系统中各配置项的 各种 关系和状态。 要 支持对配置的自动采集或批量导入，可对配置信息自动更新或同步；支持提供可视化管理功能，通过图形化的方式展现各配置项间的关系；支持自动同步变更、发布等其他管理流程对配置管理数据库的改动数据，可联动监控管理系统实现各类配置的检查机制；支持配置信息的模板化定义和快速批量维护功能。在系统 设计和 实施 中 ，配置管理功能的 能够 覆盖 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 的 所有 础 设备设施 、终端 设备 、应用系统。 第七节 知识管理 在建工集团业务运维管理系统的体系设计时，知识管理（知识库）应支持搜集、分析、存储和共享知识和信息。知识管理功能应支持 多种格式文档进行批量知识导入；支持对知识进行审核、分类、检索、定义关键字等管理功能；提供知识评价功能，支持对已阅读的知识进行评级和关联次数统计；支持与请求、问题、变更、发布等其他管理流程自动关联相关知识。在系统实施时，知识管理功能 应能够 覆盖集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 。 通 过图 述知识管理 所处整个系统的重要地位和工作原理。 图 八节 变更管理 变更管理应支持对变更进行记录和分类，通过规范的变更流程， 在业务运维 管理系统的体系设计 对变更请求的全程进行跟踪和监控。变更管理功能应支持对变更的类别和优先级进行划分，可定义多种类型的变更审批流程；支持将当前变更关联的事件、问题、配置、知识库等相关信息展现出来。在系统实施时，变更管理功能的 应能够 覆盖 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组。 第九节 发布管理 发布管理 在业务运维管理系统的体系设计 中， 应保障运行环境的完整性以及正确的组件被发布。 因此， 发布管理功能应支持发布的分发和安装，可定义多版本发布流程，可配置上线前测试、上线后测试等环节；支持发布管理与配置、变更、服务级别、知识库等其他功能相关联。在系统实施时，发布管理功能的 应能够 覆盖 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组。 第十节 服务级别管理 服务级别管理 为集团的 业务运维管理系统 提供信息中心和业务部门之间关于 维服务的提供质量的约定、检查功能。服务级别管理 必须要 支持端到端的服务级别指标测量功能，提供服务可用性、响应和性能 、完整性和精确性、安全性等方面的指标，并且支持定制各指标的阀值；支持服务级别协议违例通知功能；支持生成定制的服务级别报告。 在系统实施时，服务级别管理功能能够保证覆盖 至 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 。 通过图 明服务级别管理 的功能和作用。 图 十一节 供应商管理 供应商管理将有效管理供应商及其所提供的服务， 在集团业务运维管理系统中，对供应商 涉及到集团产品的质量和效能是否能够达到标准和要求，对其的 管理应更加动态和细致，故此项功能 必须 支持定义运维管理绩效指标，对 供应商进行定期评估，形成评估报告 。对 结果控制 进行 必要的 管理 ，即 支持对外包 维服务质量和效果的控制 。对 过程控制 进行 管理 ，即要 支持从各个运维流程中采集数据，对外包运维人员的工作量和绩效进行统计和定期报告。 并且要掌控 系统实施时，供应商管理功能 要延伸至 集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 ，及时快速的收集到第一手资料和信息。 第十二节 资产管理 资产管理功能 对于建工集团来说，是一个 庞大的工作阵地。单从层级上说，集团公司本部机关处室和子公司、分公司、所属基层单位乃至项目组 的网络设备、服务器 、 印机、计算机配件、软件、备品备件等多种 产 就十分可观，要将它们的 信息的维护、统计以及资产生命周期管理，并支持自动关联资产相关的事件、问题、变更、发布等记录 ，需要精细的工作和对于此项功能的细化，必须满足 资产信息管理功能 能够 支持资产信息的批量导入、更新、查询、批量导出、清单打印功能；提供各类 产的利用率计算功能，以反映资产的使用情况，辅助用户合理使用资产，实现基于资产生命周期状态的统计功能；支持将资产信息的分析统计结果向信息中心和财务部门汇总和同步；支持将 产的采购、入库、维修、借调、领用 、折旧、报废等生命周期各阶段的管理功能与变更、发布管理流程关联。 要 能够将人力从繁杂的基础性工作中解脱出来，还需要对于资产管理的功能支持基于规则的预警功能，如资产过保修期预警、资产报废预警等；支持基于规则的资产维护费用的计算，包括资产维护费用和人员费用等。 第十三节 监控管理 首先通过图 图 、网络设备监控 能够采用多种算法、迅速搜索整个网络内的所有节点，支持共同体名自动寻找、匹配，自动辩识各生产厂商，自动生成整个网络的物理拓扑结构图，包括设备间的冗余连接、备 份连接、均衡负载连接，支持拓扑添加算法，支持滤除无须管理的 络节点，支持拓扑图扩展补充发现；可以为每条设备间连接加以注释，为每台设备设置中文设备名称，监测网络中每台设备的名称、 址、类型、厂商等，并能够自动辨别线路连接类型；能在一个拓扑图上最大限度展示需要的各个方面的信息；可根据网络设备、 存等指标，根据链路、端口的状态、速率等指标，通过不同的色彩展示，产生动态的网络拓扑图；支持网络设备分级权限管理，网络拓扑图的查看和修改也是按照用户域和用户角色定义来严格限制的，保持和网络设备的权限的统 一。 2、主机设备监控 支持对 多平台系统主机进行的统一监控和管理。 3、存储设备监控 支持对光纤存储交换机、磁盘存储设备、磁带设备进行的统一监控和管理。 4、数据库监控 实现对 数据库的监控管理。实现对数据库系统关键参数进行监控及管理。数据库采集，至少需提供 脚本两种采集方式根据不同需求实现对数据库信息的采集。 可以监控数据库运行状态，如数据库 据库状态、数据库表空间（未分配、预留、索引、未使用）、连接数、回滚段、锁 定总数、连接用户数、网络读取、写入等待、完成页面读取数、可用缓存等。可以对数据库的性能，包括内存、 能、碎片、 中率、关键表空间增长情况等进行监控；能够设定相应阀值，实现相关报警。能够监控数据库的活动进程，以及 句的执行状况等。 5、应用系统监控 支持创建业务应用监控视图，能够展现应用系统与应用关键模块的关系；可对应用系统主要页面进行拨测，监控是否正常运行；监控应用主要进程，监控进程是否存活及占用服务器资源情况；分析应用产生的日志；对应用模块间的接口进行监控，接口类型包括但不限于 ： 口表等；对应用存放业务文件的关键目录进行监控；支持对 中间件运行状态的监控；提供对邮件服务进行监控；提供对 务进行监控；提供对 务进行监控。 第十四节 辅助管理 在建工集团业务运维管理系统的体系设计时，系统应支持以下辅助管理功能： 1、网元配置管理 可在任意网元类型建模的基础上建立某种类型设备的实例，将其纳入到的管理范围进行监控，以便对其进行性能分析、故障发现、告警等。 2、数据采集管理 可以对任意网元实现单独或批量的配置 和修改采集方式、采集周期等策略。 3、告警预警管理 数据的分析处理支持灵活的参数和阈值设置、通过灵活的告警公式进行复杂的告警逻辑判断、提供告警和故障的直接处理、对于关键性的故障信息支持自动升级为事件处理流程，与统一流程管理直接对接，形成告警故障的闭环处理。 4、阈值管理 支持告警公式的设计和定义功能，用逻辑表达式的方式描述对特定故障场景的定义。 告警阈值可提供对历史趋势的分析判断，以提高告警的准确性。 5、告警分析 对接收到的故障数据、性能数据、配置数据分别处理，性能数据将根据所配置的告警定义进行告警分析判 断，包括简单的阀值判断、复杂的逻辑算术公式、函数运算，生成原始告警信息。 6、告警展示 系统应有非常良好的故障表达方式，可以将复杂晦涩的技术术语转化为通 俗易懂的语言。 7、告警与故障处理 实现告警的确认和维护记录的管理功能，相同告警再次出现时，能够查看到以往的维护记录并以之作为参考。 8、告警事件通知 告警通知功能是将经过告警分析判断、告警关联分析后的告警信息以短信、邮件、 方式通知相关的运维人员；系统监控平台能够提供各种告警通知的接口，并能够从用户管理模块中获取系统维护人员的各类信息（如手机 号码、 ）；告警通知能够灵活定义，能够通过规则的设定，实现通知时间段的控制。 9、拓扑管理 拓扑图功能完全通过浏览器操作，可在界面上实际操作各种拓扑图的情况。可手动创建示意设备、示意链路，并支持拖拽方式修改拓扑图内容。可按设备类型、名称、 址，管理员可以快速定位网络拓扑图中的设备。拓扑图支持导出打印功能。 10、业务系统管理视图 能够实现基于业务系统视角的 控视图，实现业务逻辑支撑结构呈现，并能够提供业务系统自动化巡检功能。 11、相关性分析 系统应具有相关性分析功能，通过梳理设备 业务之间的对应关系 , 当设备发生故障时，能够快速做相关性分析，导出这个设备的故障将会影响哪些系统和业务。 12、统一的信息化资产管理库 系统提供建立建工集团信息化资产管理库功能，内容包括 建工集团 全部信息化基础设备设施（硬件、软件及计算机终端等附属设备）的购置、产品信息、配件及配置信息、维修维护记录、用途、设备安装地点及变更等进行详细的记录，并能够对于设备使用年限、维修维护次数较多等情况进行自动预警，为 建工集团信息化设备设施整体规划和更新升级提供依据。 第三章 业务运维管理系统 设计分析 第一节 可行性分析 济可行性 经济可行性 即估 计 其 开发 的各项 费用以及最终从开发成功的 系统 所获得的收益 或成效 ， 衡量比较支出的费用和收到的利益 ，并从中得出结论 。 建工集团业务运维管理系统 目前在 建工集团 实施运行，该系统的实施将最大幅度的提高日常业务运维工作效率，降低业务运维 员工 的 工作内容、 工作强度 ，同时降低了工作失误和不能及时发现问题而造成后果的经济损失，从而 降低业务运维人员的人力成本，高效准确的业务数据处理能力使业务运维的服务水平提升到一个新的高度，进而大幅降低维护风险和维护成本。 术可行 性 技术可行性即对业务需求进行 功能 、 性能以及限制条件 的 分析