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

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

2018年3月

目录

1概述 (3)

2平台架构 (3)

2.1平台整体架构 (3)

2.2平台技术架构 (4)

3平台特点 (5)

3.1稳定性 (5)

3.2易用性 (5)

3.3扩展性 (6)

3.4开放性 (6)

3.5标准性 (6)

3.6组件化 (7)

4第四章平台特色功能 (7)

4.1自助服务台 (7)

4.2工作区 (8)

4.3事件管理 (9)

4.4问题管理 (11)

4.5变更管理 (16)

4.6发布管理 (17)

4.7配置管理 (19)

4.8值班管理 (24)

4.9知识库管理 (26)

4.10自定义流程 (30)

4.11移动运维 (36)

4.12运维报表 (37)

5第五章平台技术参数 (41)

5.1服务器端配置要求 (41)

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 工作区

Apex OssWorks为了能够在一个界面上呈现来自不同系统的数据，将个人用户最常用的功能、最关注的业务数据进行统一集成，能够一目了然的看到各个子系统的运行状态，作为用户日常工作的快捷方式汇集。通过个人工作台，用户可快速定位到所需要进行的工作，提高系统应用的效率，方便日常维护支持工作。

个人工作台

组件化的服务台

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

组件自定义

4.3 事件管理

Apex OssWorks事件管理流程是负责解决IT服务的突发事件、客户投诉和请求的运维流程。设计目的是尽快恢复被中断或受到影响的IT服务，它的特点是以快速解决故障为目的，而对反复出现或者重大故障可升级到问题管理来分析根本原因，防止以后再次出现。

流程说明

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

图11：事件流程图

对流程的描述如下：

?服务台工作人员根据客户的请求创建事件工单流程，此时流程进入“待处理”状态；

如果在创建的同时选择了处理人，则流程直接进入“处理中”状态，同时处理人将得到邮件通知

?运维人员在事件工单池中看到有待处理的工单，即执行接单操作，此时流程进入

“处理中”状态，此时接单人也即流程的当前处理人将得到邮件通知

?运维人员可以拒绝分配给他的工单，此时流程进入“被拒绝”状态，同时工单的创建

人将得到邮件通知

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

件通知

?流程处于“被拒绝”状态可以重新提交，流程进入“重新打开”状态，此时工单的当前

处理人将得到邮件通知

?流程处于“重新打开“状态时可以再次拒绝，流程进入“被拒绝”状态，此时工单的创

建人将得到邮件通知

?流程处于“重新打开”状态时如果处理人解决了故障，则流程进入“已解决”状态，此

时工单的创建人将得到邮件通知

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

直接解决

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

工单，而不用提交后在工单详情界面中再次点击“解决工单”按钮，加快操作者的速度。

升级工单

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

状态跟踪

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

与知识库的联动

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

4.4 问题管理

问题管理的目标在于尽量减少由于IT基础设施的故障导致的业务故障，并防止与这些错误相关的问题再次出现。重点就是在于发现问题产生的根本原因，并随后采取措施改善或者纠正这种情况。问题是导致一些或者多起事故的潜在原因，Apex OssWorks问题管理就是尽量减少服务基础架构、人为错误和外部事件等缺陷或过失对客户造成的影响，并防止它们重复发生的过程。问题管理与事件管理有明显的不同，后者是尽可能快的恢复服务，而前者的主要目的是找出事故产生的根本原因。为此，它甚至可能要求中断服务。

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

1.将突发事件减到最小

2.找出突发事件的根本原因

3.避免相关事件或问题再次发生流程说明

基于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属性定制功能自定义科学合理的软硬件资源基础数据模型。