一种运维保障服务管理平台的配置管理系统的制作方法

1.本发明涉及运维保障服务管理技术领域，尤其涉及一种运维保障服务管理平台的配置管理系统。


背景技术：

2.运维保障服务管理平台的配置管理是实现其操作的基础，但传统的配置管理系统在使用过程中仍存在不足，无法及时对故障进行预防，以至于无法消除和减少生产环境中事件发生的数量和严重程度，导致其使用安全性和灵活性降低，因此，为了解决此类问题，我们提出了一种运维保障服务管理平台的配置管理系统。


技术实现要素：

3.本发明提出的一种运维保障服务管理平台的配置管理系统，解决了现有的运维保障服务管理平台的配置管理系统存在的无法及时对故障进行预防，导致其使用安全性和灵活性降低的问题。
4.为了实现上述目的，本发明采用了如下技术方案：
5.一种运维保障服务管理平台的配置管理系统，包括变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享，所述运维保障服务管理平台的配置管理基于服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享对各种硬件软件设备进行信息记录、信息维护，信息更新，维护设备资产信息。
6.优选的，所述变更管理通过统一的标准方法和步骤管理和控制所有对it生产环境有影响的变更，it部门管理和引导用户变更需求，对所有变更进行正确的评估，且对变更请求和变更实施得到正确记录，并提供统计，且变更管理流程始于变更的接收，结束于变更回顾。
7.优选的，所述变更管理流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。
8.优选的，所述资源配置库房管理通过对数据进行查询，并接受接口传递的外部事务，通过模型设计对其进行赋值，从而获取数据，实现对其的管理。
9.优选的，所述配置管理中运维保障服务管理平台应现配置项数据的分类统计，包括按数据信息、所属部门、所属系统、区域等内容生成报表文档及图形结合进行展示分析，并可以对配置项进行新增、修改、导入、导出、删除操作，配置项使用精确查询和模糊查询方式进行检索，所有人工维护时对配置项属性的变更，运维保障服务管理平台能通过审核后才能生效，在审核时提供配置属性变化比对，与平台中流程管理系统联动，直接创建变更工单，在工单中对配置项属性进行调整，待工单关闭后，配置项属性的变更会自动生效。
10.优选的，所述关系管理中运维保障服务管理平台应该对配置项进行电子化管理，通过在web界面点击的方式，实现对配置项相关联的配置项设置，以及根据关联类型对该类型的配置项进行查询。
11.优选的，所述文档管理中运维保障服务管理平台应实现文档的电子化管理，按照文档的用途进行分类，支持自定义文档目录及目录的层级设置，支持多种文档格式上传，文档大小无限制，可同时上传多个文档，上传过程中有进度提示，运维保障服务管理平台能够对文档进行检索，包括文档关键内容信息查询。
12.优选的，所述信息共享中运维保障服务管理平台将要支持各个业务系统进行信息共享的功能，当信息发生改变之后，系统会检测到信息的更改并通过接口的方式提供给其他系统信息，在配置模块可以根据设置配置来对信息共享的方式进行修改。
13.本发明的有益效果为：基于变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享对各种硬件软件设备进行信息记录、信息维护，信息更新，维护设备资产信息，形成不断完善改进it服务的循环机制，且结合问题管理流程主动提供故障预防性措施，通过分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生，消除和减少生产环境中事件发生的数量和严重程度，安全性高，在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。
14.综上所述，该运维保障服务管理平台的配置管理系统具有灵活的可扩充性和高度的可配置管理性，使用安全性、灵活性高。
具体实施方式
15.下面将对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。
16.实施例1
17.一种运维保障服务管理平台的配置管理系统，包括服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享，所述运维保障服务管理平台的配置管理基于服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享对各种硬件软件设备进行信息记录、信息维护，信息更新，维护设备资产信息。
18.所述服务台及事件管理包括服务台管理和事件管理，所述服务台管理通过对记录下来的用户问题和用户请求数据的统计整理，形成可供管理层分析研究的数据报告，管理层通过对这些数据报告的定期分析和研究，可以发现在提供it服务的过程中需要完善的地方并采取行动加以改进，从而形成不断完善改进it服务的循环机制；
19.所述事件管理范围包括所有it生产环境所产生的申告、故障、告警、咨询和客户投诉，其始于事件的接收和报告，结束于事件的解决，该流程包含下述主要内容：
20.事件检测和记录，这个环节是事件管理流程的起点，所有用户或系统报告的it事件必须由此步骤开始，此步骤的目的是在事件发生时快速准确地发现，以协助事件的诊断和解决并通知相关人员，在此步骤中将会收集创建事件记录所需的信息，该环节的关键是信息的准确性和完整性；
21.分类和初步支持，对于每个事件，需要确立优先级和分类，若没有现成的解决方案
或临时解决措施，该事件将分配给合适的支持人员对此进行调查；
22.调查和诊断，若支持人员无法解决事件，可运用自身技能、知识库、诊断工具等进行更加深入的分析以找到恢复服务的临时措施，必要时可调用多名支持人员以寻求解决措施；
23.解决和恢复，支持人员实施事件的解决方案，并将解决完毕的事件转回服务台，由服务台通知用户解决的结果，并得到用户的确认；
24.优先级为紧急的事件和事件升级，对于紧急事件，服务台应立即提交给二线人员，由二线人员判断，上报给事件负责人和相关的管理层，由事件负责人决定紧急事件的处理方式，确保其得到最快速的解决，当事件处理超过预期时限，将通知处理人员和相应管理层，以引起相关人员和管理人员的重视和参与；
25.结束事件，当用户确认事件解决后，此时可结束该事件；
26.其主要功能是尽快解决出现的事件，保持业务支撑系统的稳定性，其目的包括：
27.在成本允许的范围内尽快恢复it服务；
28.进行事件控制；
29.提供it管理信息。
30.所述事件管理与其它流程的关系如下：
31.1.1、和问题管理流程的关系
32.事件管理流程将提供事件的详细、精确的记录信息给问题管理流程来定位问题及分析问题的趋势，以及在优先级为紧急的事件解决并恢复服务后作为问题进行进一步的分析和处理；
33.1.2、和配置管理流程的关系
34.需要从配置管理数据库中查询配置项的属性和配置项间的关联关系来定位故障和帮助快速的恢复；
35.1.3、和变更管理流程的关系
36.服务台应了解变更管理流程中目前正在进行的变更信息，检测因变更而可能引发的事件，在事件的解决过程中，必要时需要发起变更请求来解决事件；
37.1.4、和知识管理的关系
38.事件得到解决后，解决的过程中所获得的经验以及相关解决方案可以进入知识库，作为知识保存，为后续的工作提供指导。
39.实施例2
40.一种运维保障服务管理平台的配置管理系统，包括服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享，所述服务台及事件管理应坚守以下流程执行原则：
41.a、常规原则
42.b、所有业务支撑部门事件管理范围内发生的事件，都应该记录在运维保障服务管理平台中，记录的信息应足够详细，包括事件处理交互过程，详细的解决方案和相应的附件；
43.所有it支持人员对优先级较高的事件所采取的服务恢复行动，在比对其它行动的时候，将拥有优先处理级别；
44.应该每月产生事件管理报表，并对重复发生的事件和变通方法解决的事件，应该举行定期的事件管理会议对这些事件进行评估；
45.应该半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进事件管理流程。
46.b、所有权原则
47.所有权原则用来确保每个事件在任何时段都有适当的人员负责，服务台是事件的负责人。
48.c、再分派原则
49.事件的再分派原则是确保事件在服务目标时段内处理和解决的重要因素，因此，应当尽量减少事件单再分派的几率，事件单可以分配到个人，或者分配到组，由组内的支持人员处理；
50.服务台可以将事件单分配给二线支持；
51.二线支持可以将事件单重新分配给其他二、三线支持人员和厂商人员；
52.现场厂商人员直接使用系统记录处理情况，没有条件使用系统的厂商，由二线支持代为记录。
53.d、重复事件原则
54.重复事件是指在一个较短时间段，由运维保障服务管理平台上报的同一个配置项上现象相同的事件或一人/多人申告的同一来源现象相同的事件，当被报告的事件与某个已经创建且尚未解决的事件单相同，则该事件被认为是重复的，由于此时已创建的事件尚未解决，还没有采取修正措施来恢复服务，因此，新报告的事件被认为是原有事件单的重复事件单。在原有事件单获得解决时，所有的重复事件单获得解决；
55.运维保障服务管理平台应该自动过滤重复告警，避免将重复的告警发送到服务管理平台；
56.重复的事件信息必须被标识，并且不计入事件流程的关键衡量指标；
57.如果服务台可以判断到重复事件，则由服务台对重复事件标识，否则由二线支持人员负责重复事件的处理。
58.e、关闭原则
59.由it用户申报的事件单，关闭必须由服务台完成，事件处理人员在解决完成事件时，根据实际解决情况填写事件的结束代码，采用临时措施恢复服务时，结束代码为“变通方法解决”，服务台负责和it用户再次确认事件的解决；
60.由it用户认可获得关闭的事件单的结束代码为“成功解决”关闭；
61.已解决的事件单如果没有得到it用户的认可，则首先关闭该事件单，结束代码修改为“不成功”，同时创建一个新的事件单重新分配到原处理人员继续处理；
62.已关闭的事件单不允许重开，如果事件重复发生，则创建一个新的事件单；
63.二线人员自行创建的事件单，本着“谁开单，谁负责关闭”的原则；
64.运维保障服务管理平台自动发送的事件单，第一次接收的维护人员负责关闭。
65.f、升级原则
66.制定升级原则的目的是确保事件在规定的解决时限内能够及时通知相关技术人员和领导，引起更多的重视，提供合适的资源，从而快速找到解决事件的方案；
67.优先级为紧急的事件，服务台应立即派发到中心领导或二线支持，由其再次确认，如果确认了优先级为紧急，则立即升级到事件负责人，并通知相应的管理层，由事件负责人启动紧急事件处理流程；
68.各支持人员应及时响应和处理分配到本组或自己的事件单，如果超出规定的响应时限和解决时限，服务台系统应将事件信息通报事件负责人和相应的管理层，事件负责人负责协调资源，并督促事件能够及时被响应和处理；
69.服务台应及时将不能解决的事件升级，若未及时升级，事件负责人应及时介入，负责协调升级处理。
70.实施例3
71.一种运维保障服务管理平台的配置管理系统，包括服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享，所述事件管理主要是被动应付突发事件和故障，故障消除、业务恢复后事件管理应结束，如需进行进一步分析，找出故障深层原因和根本解决方案，通过变更请求、变通方法或建议的预防性措施来防止同类故障的再次发生，应启动问题管理流程，问题管理流程是主动提供预防性措施，通过分析并确定事件的根本原因，找到最终解决方案，以防止此类事件再次发生，消除和减少生产环境中事件发生的数量和严重程度；
72.问题管理流程着重于消除事件或减少事件发生，确定事件的根本原因，主要活动包括分析事件、找出问题、分派问题、确定根本原因以及找出解决方案、回顾及关闭，以消除事件或在其发生时降低对用户或业务的影响，其主要内容如下：
73.分析事件，定期分析事件，找出潜在问题；
74.生成问题记录，在系统中生成问题记录并把所有相关事件与此记录关联起来；
75.分派，根据问题内容将问题记录分派给适当的技术小组；
76.根本原因分析，被分派的小组人员将调查问题以期找出其原因，提出解决方案、变通方法或预防性措施，以消除产生原因，或在重发时使其影响力最小化，记录必须被更新以反映它是已定位原因状态，并且把任何变通方法、避免或最小化负面影响的动作行为也记录下来；
77.开发、确认、提出实施解决方案，对问题的解决方案进行评估、测试，提出变更请求或实施具体的解决方案；
78.回顾及关闭，对问题的解决方案进行回顾，确认解决方案达到了预期的效果，确认问题的信息记录填写完整，提交知识库，并关闭问题记录。
79.所述问题管理与其它流程的关系如下：
80.2.1、和事件管理的关系
81.事件在恢复服务后仍需后续分析处理的，应结束事件单，创建问题单；
82.2.2、和变更管理的关系
83.问题处理过程中，如果需要对系统进行变更，必须按照变更管理的定义，提交变更请求单，变更完成后，继续问题单的处理；
84.2.3、和配置管理的关系
85.问题处理过程中，可以通过配置管理查询相关的配置项信息；
86.问题处理过程中，如果可以将根本原因定位到某个配置项，则必须将问题单与该
配置项关联；
87.2.4、和知识管理的关系
88.问题处理完成后，均应整理提交到知识库中，以便在国家移民管理局运维保障服务管理平台共享。
89.实施例4
90.一种运维保障服务管理平台的配置管理系统，包括服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享，所述变更管理通过统一的标准方法和步骤管理和控制所有对it生产环境有影响的变更，it部门管理和引导用户变更需求，对所有变更进行正确的评估，且对变更请求和变更实施得到正确记录，并提供统计，且变更管理流程始于变更的接收，结束于变更回顾。
91.所述变更管理流程始于变更的接收，结束于变更回顾，该流程包含下述主要内容：
92.提交变更请求，填写变更分类、变更类型、风险级别、优先级以及详细描述信息，若是紧急变更，应通过e-mail等书面方式申请；
93.审核变更请求，所有变更请求都需要递交到变更协调员，由变更协调员对变更信息的完整性及规范性进行审核；
94.变更实施任务分派，变更负责人将任务分派给变更实施人员进行变更实施；
95.监控变更实施效果，变更实施任务完成后，由变更负责人对变更实施结果进行监控和审核，首先判断其是否需要进行回退操作，如果无须回退则判断变更是否成功，其次判断是否需要对配置项进行更新操作，如果需要则更新相关配置项信息，如果无须进行配置项更新操作，则进行变更回顾及归档操作；
96.配置项更新，如涉及到配置项变更，则由变更负责人安排配置项负责人进行配置项更新；
97.变更回顾及关闭，变更协调员协同变更负责人和相关成员负责从技术、管理、业务角度去回顾变更，确保变更请求得到了预期效果，并寻找流程改进机会或针对该变更的后续行动计划，随后更新变更记录并将工单归档，变更管理流程结束。
98.所述变更管理流程可以从其他的服务管理流程接收到变更请求，所述变更管理流程与其它流程关系如下：
99.4.1、和配置管理流程的关系
100.变更管理涉及到的配置改变应当在配置管理数据库中得到体现，改变的数据可能包括配置项、配置项间的关系或配置项的某些属性，变更的评估需要从配置管理数据库中获取相关的信息进行分析；
101.4.2、和事件管理流程的关系
102.事件的解决可能需要触发变更管理流程来实现，变更成功实施后应当通知事件管理流程；
103.4.3、和问题管理流程的关系
104.问题管理流程中对于错误的修正可能需要触发变更管理流程，变更成功实施后应当通知问题管理流程；
105.4.4、和发布管理流程的关系
106.发布管理为变更管理提供支持，负责计划与实施变更，通过正规的实施变更流程
及测试确保应用系统的质量，变更计划实施的过程中，软件版本上线类变更和统一工程割接类变更会触发发布管理流程，如果发布管理流程是由变更管理流程触发，则发布记录必须与变更记录相关联。
107.实施例5
108.一种运维保障服务管理平台的配置管理系统，包括服务台及事件管理、变更管理、资源配置库房管理、配置管理、关系管理、文档管理和信息共享，所述变更管理流程的实现是通过不同的流程角色以及其被赋予的职责来实现的，因此流程的每一个角色可以被定义为一系列职责的集合，在实际的管理操作中，不同的人员将被赋予不同的职责，也可能一个人被赋予多个职责，同时也可以将其职责授权给其管理结构之下的人员，因此，以下所提及的管理流程和角色的目的是为了在充分满足流程所需角色的基础上，为具体的实现提供足够的灵活性。
109.所述资源配置库房管理通过对数据进行查询，并接受接口传递的外部事务，通过模型设计对其进行赋值，从而获取数据，实现对其的管理。
110.所述配置管理中运维保障服务管理平台应现配置项数据的分类统计，包括按数据信息、所属部门、所属系统、区域等内容生成报表文档及图形结合进行展示分析，并可以对配置项进行新增、修改、导入、导出、删除操作，配置项使用精确查询和模糊查询方式进行检索，所有人工维护时对配置项属性的变更，运维保障服务管理平台能通过审核后才能生效，在审核时提供配置属性变化比对，与平台中流程管理系统联动，直接创建变更工单，在工单中对配置项属性进行调整，待工单关闭后，配置项属性的变更会自动生效。
111.所述关系管理中运维保障服务管理平台应该对配置项进行电子化管理，通过在web界面点击的方式，实现对配置项相关联的配置项设置，以及根据关联类型对该类型的配置项进行查询。
112.所述文档管理中运维保障服务管理平台应实现文档的电子化管理，按照文档的用途进行分类，支持自定义文档目录及目录的层级设置，支持多种文档格式上传，文档大小无限制，可同时上传多个文档，上传过程中有进度提示，运维保障服务管理平台能够对文档进行检索，包括文档关键内容信息查询。
113.所述信息共享中运维保障服务管理平台将要支持各个业务系统进行信息共享的功能，当信息发生改变之后，系统会检测到信息的更改并通过接口的方式提供给其他系统信息，在配置模块可以根据设置配置来对信息共享的方式进行修改。
114.以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，根据本发明的技术方案及其发明构思加以等同替换或改变，都应涵盖在本发明的保护范围之内。