系统运维管理方案.docx
- 文档编号:26237056
- 上传时间:2023-06-17
- 格式:DOCX
- 页数:46
- 大小:949.96KB
系统运维管理方案.docx
《系统运维管理方案.docx》由会员分享,可在线阅读,更多相关《系统运维管理方案.docx(46页珍藏版)》请在冰豆网上搜索。
系统运维管理方案
1系统运维管理方案
运维管理主要为IT人员提供统一的协同式工作环境。
通过IT流程的梳理及固化,实现IT内部纵向、横向,以及其他专业的有效协同。
通过与各类IT专业工具的集成,为IT人员提供日常工作的集中处理环境,实现各项IT工作的规范化、标准化、集中化处理,提高IT人员工作的效率质量。
1.1.1流程引擎
1.1.1.1流程设计
流程设计的灵活性和可配置性是运维管理流程实施的基础和保障,目前在建系统的工作流引擎由本系统公司自主研发,在灵活性和可配置性上已可满足当前港华燃气运维管理的需要,并可根据特殊要求进行相应的定制化功能开发。
⏹图形化、拖拽式的流程绘制
可从画板上拖拽流程的起始节点、流程环节、子流程、连接线到画板区进行流程图的绘制。
⏹流程数据项管理
(1)流程数据项定义
可针对每个流程设计独立的流程数据项,流程数据项是构成流程表单的基本要素,其定义界面如下:
可定义流程数据的名称、数据类型、合法性验证规则、显示控件类型以及与其他流程数据项的映射关系(子流程管理模式)、读写权限等。
(2)离散值
为了规范特定数据项的取值范围并实现与集团编码的一致性,系统还提供离散值定义功能,管理员可按照集团和业务的要求,自主定义离散值,具备离散值的数据项一般采用下拉框的方式进行展示。
(3)数据项联动机制
系统同时支持两个数据项之间的联动功能,当A数据项选值发生变动时,联动数据项B的显示数据将随之发生变化。
(4)计算数据项
针对需要根据某两个数据项的取值自动计算的数据项,如下图所示,预算可根据工作人日和单价的运算自动生成对应的值。
⏹流程文档模板管理
为了简化操作人员填写流程表单的复杂度,并将现有的管理机制与流程引擎进行结合,系统可灵活定义当前流程在流程实际运转过程中的各类文档,如:
需求说明书、发布测试、测试报告等,并根据各类文档的重要性设置文档的必要性,以便在流程运转过程中进行必要性限制。
⏹子流程管理
为方便省、市之间的工作互动需要,系统支持在主流程中嵌套子流程的功能,子流程作为主流程的环节出现,在设计流程时,可指定子流程引用的目标流程。
换言之,针对需求管理我们可以设计省级需求管理流程和地市级需求管理流程,当省级需求管理流程涉及地市需求的时候可以在对应的环节中引用地市级需求管理流程,流程在流转时,可在对应的环节和条件下创建地市级需求单,该需求单在地市级需求管理流程中进行独立的闭环管理,当对应的工单流转完毕后,可返回给省级需求管理流程对应的触发点,省级需求管理单则继续向下继续流程,这样既实现了省、市两级工作的互动,又保障了两级管理流程的独立性和闭环性。
子流程在满足“一级平台、两级应用”的基础上,也可实现多个流程之间的嵌套情形,如:
在需求管理流程中可能会触发发布管理流程,发布管理流程中可以触发测试管理流程。
这样可以保障多个管理流程的串行执行和制约性管理措施的落地,为规范日常的IT运营提供了充分的平台保障。
子流程的设计落地主要通过以下几个方面进行保障:
(1)子流程数据项映射
针对子流程管理模式我们需要定义子流程表单数据项与主流程表单数据项之间的映射关系,以便在创建子流程表单时能够实现从主流程数据项上进行数据的自动继承功能。
(2)子流程在流程图中的体现
在流程图画板上可拖拽子流程图标
到画板区。
点击子流程图标,可配置当前环节关联的子流程:
(3)子流程必要性
决定是否必须触发子流程以及触发后和主流程之间的执行关系:
串行:
子流程执行完毕,主流程方可执行,其间主流程处于锁定状态。
并行:
子流程、主流程同步执行,两者之间没有约束关系。
⏹流程任务管理
Ø流程任务定义
流程任务是流程参与人在流程流转环节需要办理的事情,参与人需要在流程执行时填写相关的任务反馈信息,流程任务填写的数据项信息在一定程度上影响着流程的流转。
流程任务也可以定义对应的任务数据项,任务数据项可与流程数据项建立关联关系,以方便任务执行后可直接影响流程的流转状态。
Ø流程任务参与者
流程任务参与者为流程任务的执行人,当符合对应的条件时,相应的任务将会分配给对应的执行人。
人员参与的方式可选择“推方式”和“拉方式”,“推方式”为符合条件的员工必须办理的任务,“拉方式”为共享任务,只要工作组内的人员办理即可。
Ø流程任务文档
根据管理的需要,流程执行人在办理具体任务时需要提交对应的文档,以方便时候查验。
Ø任务超时配置
当任务分配给执行人后,当对应的任务在规定时间内仍未办理的,系统需要进行超时提醒,并将相应的工单升级或转派给相关人员进行处理。
【不处理】超时后不采取任何行动。
【提醒】进行邮件或短信提醒
【终止】超时后直接终止工单的流转
【转办】由其他人员进行处理,一般由处理人的上级主管处理
Ø任务关联动作
为体现流程间的差异和较少流程执行时不必要的操作,系统支持定义在执行具体任务时可出现的动作选项,如“工单合并”、“工单拆分”、“工单关联”、“回访标志”、“通知标志”等功能,在流程执行时,涉及到的任务才会出现对应的动作,不涉及的则不予以体现。
用户通知:
在流程执行过程中需要通过邮件、短信、公告的方式通知本工单的关联方,为落实相关事宜提供及时、便捷的手段,如应用更新时可能会影响到关联系统在某段时间内与本次发布相关的应用、接口无法正常使用时,则可通过此方式在制定发布计划时发起相应的通知信息。
用户回访:
针对发起请求或流程的人员进行邮件回访,对应环节的执行人员可查看受访人反馈的邮件信息,以便对相关事宜的执行效果得到真实、有效的反馈。
工单拆分:
在需求管理及测试管理过程中因业务和管理的需要,存在将一张需求单或测试单拆分为多张流程单进行流转的情形,为适应该要求,系统支持在流程需要的环节上出现“工单拆分”动作,以方便使用人员操作,拆分后的工单自动建立与原单的关联关系,拆分单的内容可根据业务的需要进行内容的调整和修改,并可指定人员进行向下继续处理,当拆分单都完成后,原单也将自动关闭,同时系统提供从拆分单、原单多个角度的关联工单查看功能。
工单合并:
对不同部门提出的类似的多张需求单、问题单进行合并,合并后的工单将合并原单的关键要素,并可进行修改,并作为新单继续流转,当合并单流转关闭后原单自动关闭。
Ø接口条件
向集团或其他外围接口上报或发送工单信息的条件,当流程执行过程中一旦流程数据符合预设的接口触发条件时系统即可自动调用接口将对应的工单信息自动进行上报或发送。
系统支持定义触发的目标服务以及调用的条件信息(可基于任意流程数据项进行配置)。
⏹流程超时提醒机制
当流程在规定的时间内还未处理完成时,需要进行提醒和转办处理,任务超时只是对当前环节的任务办理情况进行超时判断。
⏹流程关注人配置
流程关注人为流程超时的短信、邮件、工单的接收人,可以为具体的某一个或某几个人,也可以是某个工作组。
1.1.1.2流程角色权限管理
Ø流程发起权限
根据管理和业务需要的不同,系统可设置不同人员发使用的流程,以减少误发单和规范管理的目的。
Ø流程角色管理
系统支持针对流程设置角色的机制,不同流程各定义管理上需要的角色,流程角色作为流程环节的参与者进行配置。
1.1.1.3表单管理
系统可基于流程数据项进行图形化拖拽方式进行排版,自定义一个流程表单,如下图:
可根据管理上的要求对数据项进行的排序和调整,以便更好地方便操作人员使用。
1.1.1.4流程控制
控制流程的实例运转,产生和流转用户的任务工单。
支持以下流程的流转方式:
●正常流转:
表示流程的正常向下一环节流转,即用户选择“完成”的情况。
●回退:
流程往上一环节流转,即用户选择“回退“的情况。
●转办:
表示用户操作时请求其他用户协同办理。
即用户选择“转办“的情况。
转办的时候环节实例表的状态不会改变。
●撤回:
当流程实例的当前实例尚未被“执行“时,前面环节的用户可以撤回。
●接收:
支持对于共享任务和非必办任务提供“接收“功能,共享任务一旦接收则其他用户不能办理,非必办任务一旦接收,变成必办。
1.1.1.5流程监控
通过收集和分析流程运行实例的统计分析数据,实现对流程运行实例运转情况的监控、分析。
统计分析可针对某一个流程实例进行,也可以对基于同一模板的某一类流程进行,通过对流程执行时长,执行数量及超时时长,超时数量等指标的统计分析,可有助于流程管理者监督流程的运行情况,制定流程优化方案等。
图形化的流程流程流转轨迹查看:
亮色表示流经环节,灰色表示没有流经的环节,绿色表示当前驻留的环节。
执行明细集中展现:
按流经的先后顺序展示各个环节任务的办理用时、办理人以及提交的附件信息,并提供查看对应任务办理明细。
1.1.1.6流程查询
提供所有流程对应的流程单信息,系统提供“基本查询”和“高级查询”功能,前者可提供基于工单编号、工单标题、工单创建时间、创建人信息进行查询,后者可提供基于流程表单项的多个条件的组合查询功能,查询条件可自定义。
(1)基本查询
(2)高级查询
支持把流程工单中的任意字段项作为条件进行查询。
1.1.2运维管理流程
1.1.2.1事件管理
事件管理流程是对IT生产环境中导致IT服务中断或潜在中断的事件进行管理,快速恢复IT服务能力的管理流程。
事件的来源包括IT用户报告的事件、监控系统自动转发的事件、客服系统自动转发的IT类事件等。
它的目的是尽快恢复被中断或受到影响的IT服务,是以恢复服务为首要目的,可能采取临时解决方案,而不在于查找根本原因。
主要业务环节包括事件的登记、事件的分配、事件的处理、事件的升级和事件关闭等。
⏹管理目标
事件管理流程的主要功能是尽快解决出现的事件,保持业务支撑系统的稳定性,其目的包括:
⏹确保各类IT事件能够在成本允许的范围内,按照事件的优先级,快速、有序地解决,从而减少IT服务中断造成的影响。
Ø多渠道快速响应服务请求(电话/Web/邮件/即时通信工具等)。
Ø根据事件的优先级,影响度进行综合分类排序,如果判断事件优先级是紧急,则启动紧急事件管理流程进行处理。
Ø为客户提供及时的事件处理状态信息。
Ø监控事件处理过程,必要时进行管理和技术升级。
⏹确保IT事件处理过程中的关键信息能正确记录,为后续事件处理提供知识支持,为流程持续优化提供准确的数据信息。
Ø按规范记录事件信息及解决过程信息。
Ø服务台及后台技术资源利用情况。
Ø服务台、技术支持团队的工作效率。
⏹业务需求点
登记各种渠道上报的事件,并对其进行分类和分级;按照对业务的影响程度和优先级分配事件;支持工程师解决该事件,并记录详细的解决方案;对超期事件进行升级处理;事件处理的解决方案可以形成知识,为后续工作提供参考;对历史事件进行趋势分析,形成问题;根据事件记录考核相关人员的绩效;对于重复上报的事件,能够进行关联处理;对事件处理的过程进行跟踪审计;事件单能够和问题单、故障单等其他流程工单关联。
⏹流程设计
流程图
图:
事件管理流程泳道图
流程表单项
以下为事件流程表单信息项,实施时可结合港华燃气的实际需要进行表单的信息项进行增删:
序号
信息项
说明
1
事件ID
事件单流水号。
2
请求人信息
事件申报人的信息,包括:
姓名、部门、电子邮件、办公电话、手机。
3
登记时间
在服务台生成事件记录的时间
4
地点
事件发生的地点。
5
事件发生时间
针对事件:
指的是业务中断的实际时间(可能早于登记时间,需要调整确认)。
针对其它:
缺省值等于登记时间。
6
业务恢复时间
针对事件的业务恢复实际时间。
7
事件来源
参见“事件来源”定义。
8
用户事件提交渠道
参加”用户事件提交渠道”定义。
9
事件影响度
参见“事件影响度”定义。
10
事件优先级
参见“事件优先级”定义。
11
事件完成期限
对应每一个事件优先级,系统根据流程相关定义中“事件解决时限”自动设定最终的完成期限。
12
所属系统类型
参见“所属系统类型”定义。
13
事件分类
参见“事件分类”定义。
14
事件标题
事件的简要描述。
15
事件描述
对于整个事件内容的详细描述。
16
事件解决人
事件的最终解决人。
17
事件状态
参见“事件状态”定义。
18
分配对象
被分配的技术支持组和人员。
19
事件日志
反映事件信息项的变化历史,如一个事件在处理过程中事件状态变化的时间点等信息。
20
解决方案
事件解决方案的描述。
21
业务中断时长
造成业务计划外中断的时间长度。
22
事件结束代码
参见“事件结束代码”定义。
23
重复事件标记
标记为重复事件。
24
重复事件ID
重复事件中主事件ID。
25
处理是否超时
参见“处理是否超时”定义。
26
实际完成时间
记录事件已解决的时间。
27
事件厂商
参见附录C厂商和集成商名称标准。
28
关联配置项
记录出现事件的配置项代码。
29
关联的问题单号
记录由事件引发问题时,关联的问题单号。
30
关联的故障单号
记录由事件引发故障时,关联的故障单号。
主要活动说明
序号
步骤名称
责任人
说明
100.1
事件记录和分类
服务台
●服务台对来自用户和系统自动产生的事件进行详细记录
●服务台负责在接收到事件后进行分类转发,对申告/告警/咨询/故障类事件进行分类转发
●对于初步判断为紧急的事件马上升级到一/二线人员处理
●对于非业务支撑维护职责范围的事件转给其它相关责任部门
100.2
初始支持
服务台
●属于服务台技能范围内可以处理的事件,服务台应尝试解决,如果无法解决需及时升级到一/二线支持
●不属于服务台职责范围的事件,立即分派到相应的一/二线支持
100.3
一线/二线尝试解决
一线支持/二线支持
●一线/二线支持人员在接受到由服务台派发的事件后,进行调查诊断,尝试解决
●在必要时根据服务协议联系厂商帮助解决并负责核查
●事件解决后,在事件管理平台记录事件解决方案并更新事件状态
●指定时限内不能解决的事件,通告事件经理,升级为故障管理流程
100.5
紧急事件再确认
一线支持
二线支持
●一线支持人员接受到来自服务台的紧急事件后,根据事件优先级别标准再次确认事件是否为紧急事件
●如果优先级确实紧急,则通知相应的管理层,并立即升级到事件经理,转101紧急事件处理子流程
●如不是,转100.3一线尝试解决,开始正常事件解决流程
100.6
记录解决方案细节
服务台
一线支持
二线支持
●在事件得到解决后,各线支持人员负责详细记录事件解决过程及方案并更新事件信息
●针对故障,一线/二线支持必须记录业务恢复时间
100.7
关闭事件
服务台
一线支持
二线支持
●服务台与申报用户确认事件是否已得到解决,如果解决,事件以成功解决或变通方法解决而关闭;否则,事件以不成功关闭,重新开事件记录,并与原记录做关联,分派到原处理人员继续处理
●服务台在关闭事件的同时必须确认事件单记录的业务恢复时间是否准确
●其它由一线或二线人员自行创建的事件单,则由开单人负责关闭
●处理过程对后续工作有指导或参考的,录入知识库
100.8
事件处理的监控
服务台
事件经理
●负责监控所有未关闭的事件的处理状况,对接收到的超时告警应及时关注
●事件经理负责协调资源,保证事件的最终解决
101
紧急事件处理流程
事件经理
●事件经理负责协调紧急事件的处理,具体过程见紧急事件处理子流程
角色及职责说明
事件经理
事件经理负责事件解决过程中的协调和监控,事件升级的判断和具体执行。
职责:
❑负责对事件的解决协调资源,保证事件的最终排除。
❑确保和问题管理流程经理的有效合作。
❑确保正确和广泛地收集和分析事件数据,发现IT和业务相关的问题。
服务台人员
服务台人员负责接收所有的事件,对事件进行初步的处理,并根据实际情况将事件分派到合适的二线支持工程师。
与服务台一起工作进行事件处理的技术人员定义为一线人员。
职责:
❑负责24×7的值班和系统监控。
❑响应客户投诉工单、热线电话、邮件、传真等事件报告。
❑完整记录所有接收的事件信息,包括:
记录事件报告人的详细联系方式、事件特征表现、描述、发生时间等。
❑对事件进行适当的分类、为事件分配优先级等。
❑尝试使用工具对事件进行初步诊断,分析相关信息并解决问题。
❑对服务台解决不了的事件,分配给最合适的二线支持小组/人员来处理。
❑检查事件的处理进度,保持与事件报告人的联系,适时通知事件处理进展。
❑与用户确认事件解决结果,关闭事件。
二线支持人员
二线支持人员是燃气行业内部相关问题领域的专家。
负责提供对一线支持人员无法解决的问题进一步进行调研,找出解决方案并尽快恢复服务。
在省公司的实际情况中,技术人员一般会按照所维护的应用、系统进行分工,如:
网络支持、主机支持、应用支持等。
这些技术人员都可以映射为二线支持人员,在流程中不明确区分。
职责:
❑验证事件的描述和信息,进一步收集相关信息。
❑进行深入调查研究或协调厂商支持,提供有效的解决方案。
❑实施事件解决方案。
❑更新事件解决信息,将已解决的事件转回服务台。
三线支持人员
包括应用开发厂商的后端研发团队、提供远程支持的设备厂商、或厂商的现场服务。
职责:
❑提供远程接入方式的支持,协助进行事件诊断及恢复。
❑必要时提供现场支持和深入调查研究,提供有效的解决方案。
参与重大事件解决方案的实施。
与其他流程关系
⏹与监控系统的交互
监控系统发现故障或异常后,可以通过事件管理的接口将重大故障自动传递到事件管理,注册为一个事件,并能自动填写事件ID、配置项、事件标题、事件描述、优先级、最终期限等。
主要功能包括:
✧支持监控系统/其他系统自动生成事件的接口,并将监控到的故障信息填写到相应的事件单中。
✧支持与监控系统的双向同步。
即当事件关闭时,自动确认监控系统中的相关告警。
而监控系统中的告警消除后,应能自动关闭事件。
✧监控系统的后续相同告警可以追加的方式添加到事件单中。
⏹与客服系统的交互
客服系统在处理用户事件时,如果认为应当由IT服务部门解决,可以通过接口将用户事件自动传递到事件管理,注册为一个事件,并能自动填写事件ID、配置项、事件标题、事件描述、优先级、最终期限等。
主要功能包括:
✧支持客服系统自动生成事件的接口,并将客服系统中记录的信息填写到相应的事件单中。
✧作为客服系统的子流程,处理结束后通知客服系统,由客服系统和用户做最终的确认。
✧客服系统中相同事件的后续信息可以追加的方式添加到事件单中。
⏹与问题管理的交互
对于重大事件或者统计分析得到的事件发生趋势,可以产生相应的问题记录。
主要功能包括:
✧支持通过重大事件生成问题记录单,将事件中的相应信息自动拷贝到问题单中。
✧支持问题单和事件单的关联,一个问题单可以关联多个事件单。
✧当关闭问题单时,应能够自动通知关联的所有事件单。
⏹与知识库管理的交互
✧在任何环节都可以查询知识库系统。
✧在关闭事件时,可以将解决方案标记为备选的知识,提交给知识管理审核。
⏹流程功能
各种渠道事件登记
登记各种渠道上报的事件工单,并对其进行分类和分级。
✧WEB方式,由请求人通过运维监控管理平台自助填写事件工单并提交,并在表单上填写请求分类和紧急程度。
✧电话方式,请求人拨打服务台统一热线,由服务台受理后代发事件工单。
✧邮件方式,请求人可编写固定格式的请求邮件发送到运维监控管理平台的系统邮箱中,邮件接口程序解析后生成事件工单。
✧即时通信,请求人通过在线客服模块与服务台工作人员在线点对点沟通并由服务台人员代发事件工单。
根据影响程度和优先级分配事件
根据事件工单填写的影响程度和优先级,分配紧急的和影响范围大的事件单给专人优先处理。
事件处理过程记录
流程引擎对事件的每个处理环节保存该环节的处理信息,包括环节派发时间、处理开始时间、处理结束时间、处理人、处理结果、处理意见。
并以图形的方式展示整个事件的处理过程。
对超期事件进行升级处理
根据事件的紧急程度,设定事件工单业务超时时间,在达到超时时间时可根据预设规则进行升级,包括:
通知当前人、通知服务请求管理员、通知当前人上级领导、将工单转办其他人。
事件处理的解决方案可以形成知识
在事件回顾环节配置知识库关联规则,回顾人可点击“入知识库”按钮对事件处理结果进行知识入库。
对历史事件进行趋势分析,形成问题
可定期统计历史事件单,获取还存在问题的事件并发起问题工单进行关联跟踪,分析角度包括:
统计长期未处理完成的事件、统计大量重复发生的事件、统计影响严重的事件单、统计解决方案为变通解决的事件。
考核支持工程师的绩效
配置事件考核报表,统计支持工程师的绩效,包括:
支持工作量、支持效率、重复处理情况、请求人反馈满意度
关联处理重复事件单
在每个办理环节,均可以对当前工单进行重复关联,当选择重复关联时,本单将同步原重复单的处理状态:
1)原单正在处理,则本单锁定等待原单处理完成后本单同步完成,并通知请求人
2)原单已处理完成,则本单直接结束并通知处理结果给请求人
对事件处理的过程进行跟踪审计
在事件管理流程最后增加“处理审批”环节,进行事后跟踪审核处理。
事件单能够和问题单、故障单等其他流程工单关联
事件处理结果,可选择“发起问题跟踪”或者“发起变更解决”的选项,当选择该两个选项的其中之一后,进入子工单启动环节,可设置为人工启动也可以设置为自动启动,从而启动关联的问题单或者故障单进行关联处理。
1.1.2.2故障管理
主要由事件/问题人工升级到故障管理流程,分配给故障经理进行跟进处理,由系统自动记录故障处理/分派过程,故障的关闭由升级人进行。
故障管理流程即上节事件管理流程图中的紧急事件处理子流程。
⏹流程设计
流程图
图:
故障管理流程泳道图
流程表单项
以下为故障流程表单信息项,实施时可结合港华燃气的实际需要进行表单的信息项进行增删:
序号
信息项
说明
1
故障ID
故障单流水号。
2
请求人信息
故障升级人的信息,包括:
姓名、部门、电子邮件、办公电话、手机。
3
登记时间
生成故障记录的时间
4
地点
故障发生的地点。
5
故障发生时间
针对故障:
指的是业务中断的实际时间(可能早于登记时间,需要调整确认)。
针对其它:
缺省值等于登记时间。
6
业务恢复时间
针对故障的业务恢复实际时间。
7
故障影响度
参见“故障影响度”定义。
8
故障完成期限
要求故障的完成期限。
9
所属系统类型
参见“所属系统类型”定义。
10
故障分类
参见“故障分类”定义。
11
故障标题
故障的简要描述。
12
故障描述
对于整个故障内容的详细描述。
13
故障解决人
故障的最终解决人。
14
故障状态
参见“故障状态”定义。
15
分配对象
被分配的技术支持组和人员。
16
故障日志
反映故障信息项的变化历史,如一个故障在处理过程中故障状态变化的时间点等信息。
17
解决方案
故障解决方案的描述。
18
业务中断时长
造成业务计划外中断的时间长度。
19
故障结束代码
参见“故障结束代码”定义。
20
重复故障标记
标
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 系统 管理 方案