综合运维管理平台技术白皮书.docx

综合运维管理平台技术白皮书.docx

《综合运维管理平台技术白皮书.docx》由会员分享，可在线阅读，更多相关《综合运维管理平台技术白皮书.docx（34页珍藏版）》请在冰豆网上搜索。

综合运维管理平台技术白皮书

综合运维管理平台

技术白皮书

2018年3月

1

概述

OSSWorks综合运维管理系统，是结合国内外ITSM的方法论以及最佳实践，并分析了中国IT管理现状和需求后，基于ITIL理念自主研发而成。

秉承以客户为中心、流程为导向的理念，实现对IT资源的全面管理，完美整合了人员、技术和流程三大要素，帮助用户以较低的成本提供稳定、优质的服务，共同实现IT服务的目标。

2平台架构

2.1平台整体架构

2.2平台技术架构

3

平台特点

3.1稳定性

系统基于稳定且优化的jdk1.6版本开发和编译，采用JBOSS中间件作为web服务器，标配Mysql数据库。

安装包在出厂前均对各个组件经过优化，对安装环境依赖度度不高，系统自身运行稳定。

3.2易用性

系统采用B/S架构，界面友好，交互性好，易于使用。

另外，系统内置多种标准对接接口，出厂时就已经具备了与多种第三方接口对接的能力，如短信、邮件系统、呼叫中心、AD域、第三方监控系统等。

方便用户的使用，降低实施成本。

3.3扩展性

系统基于可扩展的多层MVC模型，面向接口进行开发，各个组件均具有很强的扩展性。

3.4开放性

为了方便与第三方系统的对接，系统提供了基于HTTP的Restful对外接口，目前已经开发的接口有工单接口和权限接口。

将来还会陆续开放资产，CMDB等其他接口。

3.5标准性

1）从开发角度：

我们基于CMMI3，ISO90001的标准来进行产品的研发和管理。

2）从功能角度：

作为运维工具厂商，我们的系统提供了标准的ITILv2+v3的标准功能。

3.6组件化

系统各模块之间耦合性低，各模块可以自由组合，面向不同的用户可提供不同的组件功能菜单。

并通过license控制各个模块的可用性。

4第四章平台特色功能

4.1自助服务台

自助服务台提供主动管理的有效工具，它既可以提供给用户的报障、各类咨询和服务请求的统一入口，让用户对事件的处理过程进行查看，提高事件的处理效率和客户的满意度。

用户可登录到自助服务台，可提交问题咨询或者提交IT服务请求，是提供给用户的报障、各类咨询和服务请求的统一入口。

用户在填写IT服务请求或者提交问题咨询时，系统采用主动链技术，自动将电话、姓名等关键项目显示到界面上，用户不用每个信息依次填写。

用户可通过自助服务台查看自己提交的事件请求的处理过程，包括处理的流程、每一步的处理人、每一步的处理情况、当前所在的流程节点位置等信息。

提供查询功能，可按照待处理、处理中、已处理等状态对提交的工单进行过滤。

提交IT服务请求

当提交的服务请求处理结束时，用户可对IT部门提供的服务进行评价。

用户评价服务情况

4.2工作区

ApexOssWorks为了能够在一个界面上呈现来自不同系统的数据，将个人用户最常用的功能、最关注的业务数据进行统一集成，能够一目了然的看到各个子系统的运行状态，作为用户日常工作的快捷方式汇集。

通过个人工作台，用户可快速定位到所需要进行的工作，提高系统应用的效率，方便日常维护支持工作。

个人工作台

组件化的服务台

个人工作台采用组件式管理，系统默认定义了多种组件，各个组件的刷新时间等可自定义。

组件自定义

4.3事件管理

ApexOssWorks事件管理流程是负责解决IT服务的突发事件、客户投诉和请求的运维流程。

设计目的是尽快恢复被中断或受到影响的IT服务，它的特点是以快速解决故障为目的，而对反复出现或者重大故障可升级到问题管理来分析根本原因，防止以后再次出现。

流程说明

基于ITIL标准的事件流程图如下：

图11：

事件流程图

对流程的描述如下：

⏹服务台工作人员根据客户的请求创建事件工单流程，此时流程进入“待处理”状态；如果在创建的同时选择了处理人，则流程直接进入“处理中”状态，同时处理人将得到邮件通知

⏹运维人员在事件工单池中看到有待处理的工单，即执行接单操作，此时流程进入“处理中”状态，此时接单人也即流程的当前处理人将得到邮件通知

⏹运维人员可以拒绝分配给他的工单，此时流程进入“被拒绝”状态，同时工单的创建人将得到邮件通知

⏹运维人员如果解决了故障，则流程进入“已解决”状态，此时工单的创建人将得到邮件通知

⏹流程处于“被拒绝”状态可以重新提交，流程进入“重新打开”状态，此时工单的当前处理人将得到邮件通知

⏹流程处于“重新打开“状态时可以再次拒绝，流程进入“被拒绝”状态，此时工单的创建人将得到邮件通知

⏹流程处于“重新打开”状态时如果处理人解决了故障，则流程进入“已解决”状态，此时工单的创建人将得到邮件通知

⏹只要工单被关闭，则流程进入“已关闭”状态，工单的处理人将得到邮件通知。

直接解决

对于事件工单，由于是以快速解决为目的，而且实际中，服务台在接到IT服务请求时，往往能够在接听电话的同时就解决了故障，比如很多咨询类的IT服务请求或一些简单的事件故障，对于这些简单的IT请求，服务台工作人员通过自身经验判断以及搜索知识库，是可以现场解决的，在创建事件工单的时候，提供“直接解决”按钮，可以直接解决工单，而不用提交后在工单详情界面中再次点击“解决工单”按钮，加快操作者的速度。

升级工单

当发现表现现象相同的故障经常发生或者事件管理无法解决某个故障时，可以由事件经理将事件升级为问题，交由问题管理流程来解决故障背后的深层次问题以防止事件再次发生。

状态跟踪

系统还提供用户对已开始执行的流程状态查询和跟踪功能。

用户通过流程跟踪功能将对每个开始执行的流程实例进行跟踪和记录，保存流程的活动记录，包括各个环节信息传递发送和到达的时间、部门环节处理的历时、处理该环节的运维人员等。

与知识库的联动

事件管理可实现与知识库的互动，当输入事件的简要信息后，系统可根据输入的信息检索出知识库中的相同事件的处理办法。

供工作人员参考。

4.4问题管理

问题管理的目标在于尽量减少由于IT基础设施的故障导致的业务故障，并防止与这些错误相关的问题再次出现。

重点就是在于发现问题产生的根本原因，并随后采取措施改善或者纠正这种情况。

问题是导致一些或者多起事故的潜在原因，ApexOssWorks问题管理就是尽量减少服务基础架构、人为错误和外部事件等缺陷或过失对客户造成的影响，并防止它们重复发生的过程。

问题管理与事件管理有明显的不同，后者是尽可能快的恢复服务，而前者的主要目的是找出事故产生的根本原因。

为此，它甚至可能要求中断服务。

问题管理流程将会带来以下好处：

将突发事件减到最小

找出突发事件的根本原因

避免相关事件或问题再次发生

流程说明

基于ITIL标准的问题流程图如下：

创建工单

问题工单创建的方式，可以是直接提交问题工单或者是由事件工单升级为问题工单。

评估工单

提交的问题工单需要进行评估，评估的结果有两种，一种是问题确实存在需要解决，运维人员接受该工单，点击“开始调查”超链接，相应的工单状态变为“调查中”；另一种是认为不需要解决或者提交的工单描述不清楚，拒绝调查，点击“拒绝调查”，相应的工单状态变为“被拒绝”。

开始调查

“开始调查”是一个动作，执行后工单状态相应的变为“调查中”，表示目前正在调查和诊断该问题产生的原因，调查和诊断可能是一个反复的过程，需要重复进行多次，而重复一次均更加接近我们想要的解决方案。

执行开始调查不需要输入备注，只是一个动作，用来将工单状态从“评估中”转换到“调查中”，以表明当前运维人员已经着手处理该问题了。

在这里系统会和配置管理以及基础架构组件联动。

可关联配置信息、产品的供应商信息、产品的技术说明及错误信息等，关联产生问题的节点运行情况信息，例如可用性报告、性能报告等。

为工作人员分析问题原因提供依据。

拒绝调查

“拒绝调查”是一个动作，发生在工单经评估后不认为是一个问题或者问题描述不清，则可拒绝调查该问题，拒绝时需要输入拒绝的理由，工单状态变为“被拒绝”。

处于“被拒绝”状态的工单可以重新提交，重新提交后工单状况再次变为“评估中”。

结束调查

“结束调查”是一个动作，当问题分析人员找到问题原因并找到解决该问题的临时或永久解决方案时可结束调查，在ITIL规范中，问题此时被转换为“已知错误”状态，结束调查时必须输入调查出来的问题原因，执行动作后工单状态变为“已知错误”。

制定方案

“制定方案”是一个动作，表明该问题背后的故障已经找到了，目前正在制定解决方案，工单状态进入“方案制定中”。

提交方案

方案制定结束，需要提交给问题经理审批，提交方案有两种方式，一种是直接输入具体方案；另外一种也可以将一份解决方案文档作为附件上传（分析人员也是很有可能在制定方案时写了几份文档），提交后工单状态进入“方案审批中”。

审批方案

对于提交的问题解决方案，需要经过问题经理的评审，问题经理会从方案所需要的时间、对业务的影响程度、人力成本，财务成本等多方面做出综合考量后来做出审批决定，审批结果有2中：

方案不通过被退回，要求改进解决方案；审批通过，工单状态进入“解决中”。

提出变更

一旦工单状态进入“解决中”，则表明运维人员正在根据解决方案解决问题，此时有2种情况，一种是不需要对IT基础设施做出变更即可解决问题，比如规章制度上的修改、客户IT知识的培训等等；另外一种是必须对IT基础实施做出变更才能彻底解决问题的，这个时候可以发起变更请求。

在单个问题工单的生命周期里面，可以发起多次变更请求，要发起变更请求，问题工单必须进入“解决中”状态，否则不能发起变更请求，也就是说处于“解决中”状态的问题工单页面上必须出现“提交RFC”超链接，当然如果问题无需变更即可解决的话，运维人员是不需要点击该链接而直接可以选择解决工单。

解决工单

在解决问题的过程中，如果问题导致了严重的事件，如果一时半会找不到永久解决问题的方案而又需要紧急解决的话，那么制定的方案可能是一个临时方案；或者说问题综合考虑下来不需要修复，比如公司自己的信息中心开发了一套业务系统出现了逻辑上的bug，需要修改源代码，但由于之前开发的人员已经走了，修改的难度、时间、成本都很大，而公司已经决定在年底购买商业软件公司的产品了，那么此时该问题很可能做出的决定就是不修复。

解决问题后，点击“解决问题”按钮，此时提供3个选项来表明解决是临时修复或永久修复或不修复，用下拉列表框选择，保存后工单状态变为“已解决”，这3个属性只是额外附加用来说明解决的性质的，不管选择的是哪一种，工单的状态均为“已解决”。

如果在问题管理流程中提交了RFC，则意味着该工单有一个到多个与之相关联的RFC，只有在所有这些相关联的RFC全部解决并关闭后，才能够将该问题工单标记为已解决，这个问题管理工单才算是真正解决。

重新打开

如果问题没有真正解决却被置为“已解决”，那么可以重新打开，执行重新打开操作后工单状态变为“重新打开”。

关闭工单

问题经过核实确实得到解决后被具备“关闭问题工单”权限的人员关闭，可输入备注，工单被关闭后状态变为“已关闭”，表明该工单生命流程结束。

4.5变更管理

基于ITIL标准的变更管理流程如下图：

变更的发起

变更的发起一般是由变更申请人提出，主要收集变更的目的、类别、变更风险、变更的执行计划，计划开始时间、计划结束时间等相关信息，此处的关键在于变更的相关信息要完整、准确地记录下来，以便变更经理和CAB委员会有足够的信息对变更的可行性、风险进行准确评估。

尤其需要注意的是每次变更均应该尽可能地记录下来，以便企业能够按照季度、年度对变更的数量和质量做出评估，提高IT服务的质量。

与CMDB的关联

CMDB中保存着各种各种的信息资源配置项，变更实际上是对这些资源配置项进行修改的过程，在对业务进行变更时，落实到CMDB中会有增加新的配置项、修改已有的配置项或者删除不再存在的配置项，所以在提交变更请求时，有必要将本次变更会涉及到的配置项一并关联起来，在进行变更风险评估的时候，变更经理或CAB可以很清晰的看到本次变更会影响到哪些配置项。

变更风险的评估

这一步是变更计划是否能够通过的关键所在，一般较小的对业务影响范围不大的变更由变更经理直接决定，影响较大的或者是变更经理无法直接决策的变更，可以由变更委员会来审判，变更委员会一般由企业内部的CIO、CTO、项目经理、总经理等组成，负责对重大的变更请求作出评估、决策，只有通过变更经理或CAB审核通过的变更才能够由发布流程去实施。

变更完成后的评审

关闭变更工单之前必须对变更进行实施后评审，如果变更成功实施，那么相关联的问题工单和变更工单才可以关闭，评审时填写一个单子，针对本次实施，给出评审意见，支持电子格式的评审意见文档作为附件上传。

更新CMDB

变更完成以后，本次变更涉及到的配置项需要由配置管理员更新到CMDB中，否则会造成CMDB中的配置项数据与生产环境下的数据不一致。

4.6发布管理

发布管理，指将一组新增的或经过改动的配置项成功导入实际运营环境，发布管理负责计划与实施IT服务的变更，主要应用于大型的或关键软硬件的上线、割接，简单来说，变更管理流程负责审核变更对业务所带来的影响，评估风险以做出是否要实行变更的决定，发布管理流程负责落实审批通过的变更，根据变更计划安排人员，分解任务并监督任务的执行，最终成功的实施变更，默认的发布流程如下图所示（可以根据实际情况作出调整）：

确定发布政策和规划

变更审核通过后，需要启动发布流程来实施变更，一个发布流程的结束对应的是一次变更的完成，启动发布时首先需要制定好完整的发布计划，包括发布类型、发布时间、参与人员、任务分工，计划完成时间、发布失败时的回滚计划，然后提交一份发布计划工单，发布计划需要由相应的发布经理进行审核后才能执行。

注意发布计划不能单独提交，只能由变更管理流程触发，只有变更的风险评估通过后才能启动发布流程，创建发布工单。

审核发布计划

发布计划制定好以后，需要进行审核以确保发布计划的正确性和合理性，只有审批通过的发布计划才允许执行，审判通过后发布经理根据计划安排分配具体的任务，一项发布可以分解为若干具体的子任务，交给不同的人去协同完成。

测试、试运行及验收

发布完成后需要进行全面的测试，发布应该由用户代表对其进行功能测试并由IT管理人员进行操作测试，只有测试通过以后才可以进入试运行的阶段，测试还应该涉及到安装配置手册、用户操作指导书等文档的验证，只有发布成功后，与该发布相关联的变更才允许关闭。

与变更流程的关系

一般而言，发布流程均是因为企业要对当前环境内的软件系统、硬件配置、网络基础设施等进行变更而导致的，所以是从变更管理流程中启动发布流程，如下图所示，在一个变更流程的详情界面中，当变更审批通过后，可以点击“启动发布流程”按钮来提交发布计划。

变更管理还需要确保对发布进行了充分的测试，只有当整个发布流程完整结束后，才能够关闭该发布流程所关联的变更流程。

4.7配置管理

配置管理负责提供这样一个虚拟数据库，来记录大量的这些基础信息和它们之间的关系，并提供科学化的流程来负责核实IT基础设施中实施的变更、配置项之间的关系是否被正确地记录下来、监控IT组件的运行状态，以确保配置管理数据库能够准确地反映现存配置项的实际版本情况，一般来讲，对配置项的修改不应直接进行，必须由变更管理流程发起，因此配置管理与变更管理是紧密结合的，变更管理流程引发和控制对配置项的修改，相反，配置管理向变更管理提供详细的信息，以帮助变更经理分析评估比变更带来的影响。

实施配置管理的好处：

●所有配置项被正确识别；

●确保配置项信息的完整性，并保留配置项历史变更记录；

●必须准确描述配置项之间的各种关联关系，并随时监控这些配置项的状态；

●协助处理变更、识别和解决问题并为用户提供支持，能够提供高质量的IT服务；

●帮助确定受影响的配置项的位置，并负责对配置项的修改和替换进行管理，能够有效地解决问题；

●提供有关维护成本和维护合同、许可证和许可证有效日期等方面的信息，以便帮助IT运维部门制定更精确的支出计划；

●问题发生时，配置管理可以帮助进行快速而准确的影响度分析，从而可以更快速而有效地处理变更。

CMDB的分类

配置项分类实际上是在实施CMDB之前要做的一项工作，根据企业的实际情况进行配置项分层，过少的层次和过深的层次都有不利影响，系统出厂时自带的配置项类别如下所示，真正实施时，可以根据实际情况做调整。

配置管理数据库包括的资源数据如下：

1）网络系统：

核心交换机、接入交换机、核心路由器、接入路由器

2）计算机系统：

小型机、Pc服务器、刀片服务器、负载均衡设备、操作系统、数据库、中间件、存储备份设备

3）安全系统：

补丁分发系统、病毒监控预警系统、防病毒软件升级系统、入侵监测系统、防火墙、PKI/PMI系统、漏洞扫描系统

4）辅助设施：

动力、空调、消防、防雷、门禁

5）动态资源：

IP地址、域名、邮件

6）业务应用系统：

重要应用系统、门户网站

7）IT组织：

组织、人员、供应商、工作组、角色、其他

CI属性

针对CMDB分类中的各CI的属性，可根据CI属性定制功能自定义科学合理的软硬件资源基础数据模型。

CMDB建立

配置管理数据库的建立是一个逐步完善的过程，由于各种各样的信息数据均可以加入到CMDB，这出现一个颗粒度的问题，究竟什么样的数据才应该放到CMDB中，什么样的数据不应该放到CMDB中，提供了手工和自动相结合的方式来录入资源数据，包括：

1.从监控系统中自动导入，依托监控管理模块强大的自动发现能力，-可以轻易的自动发现网络环境内的各种网络设备（交换机、路由器、防火墙等），服务器（支持Windows、Linux、Solaris、IBM-AIX等多种操作系统）、数据库（Oracle、MS-SQL、MYSQL、DB2等）、中间件（JBoss、Tomcat、Weblogic、WebSphere等）等发现的资源可以自动进入CMDB。

2.从Excel中导入，对于用户手工维护的信息资源，提供了Excel模板，用户仅需要按照模板规定的格式，将信息资源数据写入Excel，即可使用系统提供的Excel导入功能导入到CMDB中

3.手工添加，根据选择的配置项类型，逐项填入配置项实例的各种属性保存到CMDB

配置项关联管理的设置

各种配置项之间并不是孤立的，而是存在着多种物理或逻辑上的关系，-配置管理模块提供可视化的关联关系映射功能，可以在拓扑图上通过拖拉的方式定义各个配置项之间的关系，包括：

⏹构成：

这个指配置项之间的父子关系，比如某块硬盘构成了某个服务器的一部分

⏹安装于：

这个指配置项之间的物理位置关系，比如某台路由器被安装在了某个机柜上

⏹连接：

如某台服务器连接到了某台交换机的某个端口上

⏹需要：

如某套应用系统需要服务器的支持

⏹关联：

如某台应用服务器与某个数据库实例之间的关联关系

⏹其它用户自定义的关系，用户可以根据实际需要对系统出厂自带的配置项关系进行扩充以满足CMDB可视化展示的实际业务需要。

配置项的变更

CMDB一旦建立好以后，为了确保配置项属性和当前生产环境的匹配，杜绝随意变更对数据完整性、准确性带来的负面影响，有必要规范配置项的变更流程，配置项的变更包括以下几种类型：

✧配置项类型的改变：

这涉及到配置项数据结构的变动，包括增加新的配置项类型，修改现有配置项类型的属性种类，通常是由于管理上的需要而需要对数据结构做出改变

✧配置项实例的改变：

这包括增加新的CI或删除现有的CI，通常是因为新的IT基础设施被引入到现有环境：

设备报废引起的从现有环境移除等操作

✧修改配置项的属性：

这个指对现有配置项的属性进行改变，比如某台服务器的口令发生了变化、服务器的CPU个数发生了变化、网络内配置的VLAN发生了变化等，此时就需要对配置管理数据库中相应的CI进行变更，否则会造成生产环节下的数据与CMDB中的数据不匹配，造成不必要的负面影响，一般情况下，应该对CI的修改应该首先发起变更申请，由变更流程来评估修改配置项对业务造成的影响，在可控的范围内由人工或系统自动的方式对配置项进行修改。

CMDB关系可视化

CMDB中的配置项数量庞大，如何将这些硬件网络设备、服务器、数据库、中间件、网站、邮件服务、FTP服务以及客户积累下来的各种业务系统之间的物理和逻辑关系映射可视化，使得IT运维人员能够从业务的角度可视化的理解这些配置项之间的依赖关系，并分析各个配置项对业务整体带来的影响？

如果能够提供配置项可视化的视图，IT运维人员看图就可以了解其对业务的影响，无疑可以大大提高IT服务的水平，-配置管理模块提供CMDB的可视化功能，通过拖、拉的方式绘制业务拓扑图，并可以在拓扑图上直接划线连接各个配置项，实现对配置项之间各种关联、依赖关系的定义与维护。

CMDB灵活定制

支持类别的自定义功能，类别的定义采用树状结构，父节点下可定义多个子节点。

父节点和子节点的CI属性之间有依赖关系，子节点自动继承父节点的所有属性，子节点可在父节点属性的基础上增加自身的特色属性。

不同分类的配置项，其属性并不相同，支持根据CI分类自定义其属性，可以添加新属性、删除旧属性，一旦添加新属性，则所有该分类的CI实例则自动同步增加该属性，比如为分类二层交换机增加一个交换能力属性，则当前系统中的所有二层交换机实例都必须自动新增一个称之为“交换能力”的属性，至于属性值则可以为空，但添加属性值时可以设置默认值，如有默认值，则所有CI实例也必须同步添加该默认值。

删除属性时，系统必须判断当前有没有对应该分类的CI实例，如果有的话则需要提醒用户。

4.8值班管理

为了确保IT业务系统7×24正常运转，响应客户的IT服务请求，IT部门安排人员值班是非常有必要的，值班表模块用来对IT运维部门人员的值班工作进行管理，确保值班人员安排有计划、有步骤的执行，不乱套，有案可查。

产品默认提供了值班管理模块，ApexOssWorks值班表管理模块支持自由创建值班类型，可以根据创建的值班类型创建值班模板，并可将值班模板应用到月，并支持打印功能，IT运维中心人员可以在服务台上方便的看到任意月份与某天的各种值班类型的人员安排情况。

班次设置

班次设置是排班的基础，用户可以自定义班次，定义班次的名称，指定时间段，已经颜色标识（颜色标识用来在不同的视图上展示）。

排班管理

产品默认提供两种排班方式，按天为周期进行排班，按周为周期进行排班。

也可以根据用户的特定规则，进行自动排班。

调班管理

对于已经排好的班次，可以进行调班。

已经调班的人员，在值班视图上会用不同的颜色标记加以区分。

值班表视图

排班周视图

以周为单位，显示本周的各个班次的排班情况。

调过班的人员通过特定标记与其他人员区分开来。

排班月视图

4.9知识库管理

运维管理系统建设的目的不仅仅是规范、记录、督促等管理工作，而且还要帮助各级运维人员提高技能水平，简化IT服务任务。

知识管理负责搜集、分析、存储和共享知识和信息，其主要目的是通过确保提供可靠和安全的知识和信息以提高管理决策的质量。

同时也是降低对具体某个个人依赖的手段。

这些需要通过知识经验的积累和共享来完成。

对于IT运维来说，管理经验的积累与传播是非常重要的一个手段，新的IT运维人员可以通过老员工累积下来的知识记录迅速提升运维经验，老员工忘记后也可以随时查阅知识库记录。

因此知识库系统包括了知识提交、知识审核、知识检索等功能。

知识库管理员通常由具备丰富IT运维经验的资深专家来担任，只有他们才知道方案的正确、完善与否，否则知识库中一旦出现错误的信息，会导致不可预料的后果。

统一知识库贯穿于系统的各个层次，包括采集、分析、运维知识库等不同层次，包括信息内容、专家技能、标准规范、考核指标等不同内容，通过知识建设降低对个人依赖