云计算运维管理体系方案设计Word格式.docx
《云计算运维管理体系方案设计Word格式.docx》由会员分享，可在线阅读，更多相关《云计算运维管理体系方案设计Word格式.docx（104页珍藏版）》请在冰豆网上搜索。
根据PDCA指导思想结合数据中心现状，我方将运维服务体系建设及平台实施划分为五个阶段：
IT战略阶段、管理体系设计、整理数据模型、工具实施、运行与改进阶段。
第一步是IT战略阶段
IT战略阶段的任务是帮助管理层设定实施ITIL的整体战略，明确管理层对于运维服务管理的承诺。
在IT战略阶段，通过现状评估、差距分析、目标确立等活动，明确管理目标建设的优先等级。
IT战略阶段的目标：
通过现状评估全面了解IT运维服务管理流程和活动的成熟度，并以ITIL作为近期服务改进的目标，分析、评估运维服务管理现状以及与最佳实践的差距，同时提出改进建议。
帮助企业运维部门全面认识现有运维服务管理水平，并作为项目下阶段规划与设计双方交流的基础。
第二步管理体系设计：
明确IT战略之后，需要对组织的管理体系进行梳理和改进。
管理体系阶段主要包括以下内容：
组织架构分析
明确岗位职责
规范管理制度
运维流程设计
考核体系
第三步整理数据模型：
数据模型阶段分为以下三个步骤：
1.模型建立
H3C为客户提供基于长期实践经验得出的数据模型工具帮助客户梳理流程及数据，并将流程及数据固化到系统中。
2.数据采集
基于前期阶段顾问咨询的成果，按照数据模型的标准格式，转换成可被统计、量化并被系统识别的数据。
3.数据整理
整理优化数据，通过手工流程检验数据的合理性和可操作性。
第四步工具实施:
工具实施阶段分为以下五个步骤：
1.系统配置及部署
完成运维管理产品的部署，管理资源、组织、人员、权限录入，监控告警策略设置，接口集成等。
2.流程导入
将已构建的运维管理流程导入到运维管理系统中，实现各个流程在系统平台中的落地。
3.系统测试
在测试环境中检验系统及数据的可操作性，并进行适当的调整。
4.工具培训
产品操作培训，确保使用人员熟练掌握工具，并可自行配置和调整。
5.系统上线
运维管理系统正式部署上线，支持业务运行。
第五步运行与改进：
IT运营阶段将全新的H3C运维管理解决方案集成到数据中心IT架构中，并提供日常的运行、监视、维护和管理服务。
该阶段包括以下内容：
评估与改进：
监视、评估H3C服务管理平台的运行情况。
将信息反馈回评估小组，以进行持续改进。
它包括：
评估已交付的服务是否实现了预期价值；
识别哪方面的要求发生了变化。
运维服务管理体系的建立并不能只实施一次就实现所有运维服务管理建设的目标，它只是企业在建设符合ITIL规范的IT服务管理系统的诸多循环中的一次过程。
配合以不断的项目回顾和持续改进，才能使得企业的IT服务管理不断的向设定的目标远景靠近。
1.3运维管理体系设计示例
需根据对数据中心现状调研与差距分析的结果，结合数据中心已有流程，针对ISO20000/ITIL要求，结合数据中心实际情况建设符合数据中心的IT服务管理体系。
我们将为数据中心设计管理流程与策略（包括流程策略、流程图、流程活动描述、流程输入与输出、角色与职责、流程KPI等）、定义相关代码（如优先级的定义、升级定义、角色职责定义等）、制定相关模板（如事件记录单模板、事件请求单模板、重大事故报告模板）。
本部分以事件管理、问题管理、变更&
变更管理三个流程举例说明实施中的关键点，如：
流程设计、角色划分、角色职责等。
❑事件管理
⏹目的：
规范事件与服务请求管理流程的相关策略及活动，确保事件与服务请求管理流程的执行质量和执行有效性。
⏹术语和定义：
事件和服务请求：
事件和服务请求管理流程的目的是尽快解决事件或服务请求与恢复服务。
事件和服务请求记录的信息决定了其它许多流程的效率。
重大事件：
影响度为一级和二级的事件为重大事件。
影响度：
表明事件对服务所产生的业务影响，它是事件的处理优先级的一个重要影响因素。
临时措施：
是解决事件的临时修复方法或技术，目的是使用替代措施暂时消除用户对服务的依赖和减少事件对用户的影响，该事件的永久解决措施有赖于对该事件潜在问题的最终解决。
通过临时措施，用户能够在没有中断的情况下继续使用服务。
临时措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多的磁盘空间。
⏹角色职责：
事件和服务请求经理：
协调事件管理的日常操作
确定和执行流程本身的变更
鉴别流程执行过程中的例外和异常情况,进行管理
传达流程的新政策和更新的政策（Policy）
确保流程标准和步骤得到遵循
作出资源的承诺和分配
鉴别和实施流程的改进建议
创建和分派流程管理的报表
对事件管理流程的负责人提出鉴别问题/改进的建议
作为流程的集中联络点，负责与用户、服务供应商、管理层之间的沟通
对于不遵守流程的情形进行受理
确保对于严重等级为1的事件进行事后回顾
主持事件回顾会议
在需要的时候，按照升级政策的途径进行升级
对不遵从事件管理流程的参与者作出通告
执行日常的流程管理
出席会议并传达和协调有关事件和问题
确保日常操作中所采集信息的完整性
管理所有事件管理的模板和报表
准备和分析报表
管理资源的分配
确保每个事件都被分派给适当的人员，并在服务水平或其他服务协议规定的时间范围内进行受理
监控尚未关闭的事件故障单：
关联类似的事件、确定超时的事件、对于未在规定时间内受理的、并且分派错误的事件进行重新分配、负责受理事件受理员升级报告的事件、鉴别需要特别注意和需要升级的事件。
事件和服务请求记录员：
接受用户的联系
收集基本的联系信息
收集用户的请求信息
分析请求信息
创建或者更新事件和服务请求单
验证用户的基本信息，如有需要，更新用户的资料
鉴别请求的种类（例如：
被动运维服务请求，应用提升类服务请求等）
对不同的请求，收集适当的信息
初步评估请求的严重等级
请求的初步受理
确定适当的分派（包括：
在适用的情况下，对现有的问题或者是请求作出连接）
若用户要求了解事件状态，则将事件的当前状况通知用户
更新和关闭事件和服务请求单
事件和服务请求受理员：
决定恢复服务所需要的必要条件，并启动适当的行动，这些行动包括：
创建变通方法
确定事件
执行变通方法，如果可行
执行解决方案，如果可行
在流程工具平台更新事件的解决方法
更新事件关闭的信息
根据事件的严重等级提供有效的解决方案
安装/执行事件的永久解决方案
确定可以作为知识库候选对象的事件
如有需要，与第三方和其他小组人员协同合作
⏹角色映射
事件管理流程中定义的角色
对应的数据中心人员
事件和服务请求经理
事件和服务请求事件记录员
事件和服务请求事件受理员
⏹流程描述
此流程描述为示例，实施中需要根据实际和ITIL最佳实践做出调整。
⏹流程图
概览图
事件和服务请求的识别与记录
事件和服务请求的初步支持和分派
事件和服务请求调查和诊断
事件和服务请求解决和恢复
事件和服务请求的关闭
主要活动说明
活动
序号
活动名称
详细描述
相关表单
1
事件和服务请求识别和记录
●鉴别用户
●验证用户信息（必要时进行更新）
●鉴别并记录事件和服务请求表现症状
事件和服务请求单
2
事件和服务请求分派和初步支持
●鉴别所影响的部件和服务
●初判严重等级和类别等
●与已知的变通方法或解决方案进行匹配
●事件和服务请求的初步处理支持
●将无法解决的事件和服务请求分配给事件和服务请求处理员，以获得进一步的分析解决
3
事件和服务请求调查与诊断
●查找相似的表现症状
●查找变通方法
●需要的话，准备进行根源分析，进入问题管理流程
4
事件和服务请求解决与恢复
●执行变通方法（需要的话使用变更管理流程）
●若成功，验证变通方法结果
5
事件和服务请求关闭
●目前集中由事件和服务请求经理统一关闭
●关闭时须与用户验证结果，征求用户同意关闭事件或服务请求
●根据知识库决定是否需要进行后续操作
●关闭事件和服务请求，设定适当的关闭代码
⏹流程间的关系
⏹相关数据
事件分类：
分类级别采用三级分类方式，即类别、子类、项目。
优先级：
事件或服务请求优先级也可理解为处理事件或服务请求的优先顺序
优先级由影响度和紧急度两个因素决定
优先级在事件、服务请求的生命周期中是可以改变的。
关于更改事件单或服务请求单优先级的原因和行为应该在事件单或服务请求单中记录。
优先级的准确评定需要不断地回顾事件、服务请求，从而优化事件、服务请求/问题的分类和设定准确的优先级。
为了避免一线人员缺乏经验无法判断优先级。
我们需要工程师在现有事件和服务请求分类的基础上，基于事件和服务请求优先级的设定原则，设置默认的优先级，并在将来的工作中逐步优化。
影响度
定义
1–极高
•关键业务系统的全局性故障
•基础架构的全局性故障
2–高
•关键业务系统和基础架构的局部故障
•普通应用系统的全局故障
3-中
•普通应用系统的局部故障
•影响关键用户或多个普通用户
4–低
•单点故障
•影响普通用户
紧急度
客户接受的可耽搁时间：
2小时需解决
4小时需解决
8小时需解决
4-低
无时限规定
优先级
极高
高
中
低
紧急度
请求来源：
事件和服务请求来源
描述
电子邮件
❑通过电子邮件收到一个请求;
电话
❑通过电话收到一个请求;
Web
❑通过Web提交的请求;
巡检和监控
❑通过巡捡和系统监控工具主动监控得到的请求;
内部通讯软件
❑内部及时通讯
服务方式：
事件和服务请求服务方式
❑通过电话支持提供服务;
远程
❑远程诊断和解决提供服务;
现场
❑现场工程师现场处理服务;
状态代码：
事件和服务请求状态代码
待处理
❑一个事件或服务请求被记录或创建;
已分派
❑一个事件或服务请求已被分派给二线支持人员或事件和服务请求经理；
处理中
❑任何一个支持人员或第三方（供应商）接受了事件或服务请求并开始处理;
挂起
事件或服务请求信息不完整，或在某些情况下阻止事件或服务请求处理员对事件或服务请求进行处理，等待的原因为：
❑需要客户提供更详细的信息
❑不能联系到用户人员
❑升级到供应商处理
❑采购定单的批准
❑不可抗拒力原因
已完成
❑为一个事件或服务请求找到解决方案或变通方法;
已关闭
❑事件或服务请求经用户确认已关闭;
考核指标：
衡量指标
指标计算说明
事件或服务请求总数
数量：
在事件单或服务请求单中根据以下条件过滤
1.【重复事件或服务请求标记】为空
2.【事件或服务请求发生时间】在统计周期内
事件或服务请求关闭的数量/比率
数量：
在事件或服务请求总数中过滤【事件或服务请求状态】＝‘关闭’
比率：
数量/事件或服务请求总数×
100%
事件或服务请求成功关闭的数量/比率
在事件或服务请求总数中过滤【事件或服务请求结束代码】＝‘成功解决’or‘变通方法解决’
用户反馈超时关闭的数量/比率
在事件或服务请求总数中过滤【事件或服务请求结束代码】＝‘反馈超时关闭‘
超时解决的事件或服务请求数量/比率
在事件或服务请求总数中过滤【解决是否超时】＝‘超时’and【事件或服务请求结束代码】＝‘成功解决’or‘变通方法解决’
数量/事件或服务请求总数×
6
超时分配的事件或服务请求数量/比率
在事件或服务请求总数中过滤【分配是否超时】＝‘超时’and【事件或服务请求结束代码】＝‘成功解决’or‘变通方法解决
7
服务台及时解决率
在事件或服务请求总数中过滤所有【解决是否超时】＝‘未超时’and【事件或服务请求解决人角色】＝‘服务台工程师’
8
二线及时解决率
在事件或服务请求总数中过滤所有【解决是否超时】＝‘未超时’and【事件或服务请求解决人角色】＝‘二线工程师’
9
平均解决时间
完成的事件或服务请求：
在事件或服务请求总数中过滤所有【事件或服务请求状态】＝‘已解决’or‘已关闭’的事件或服务请求
平均解决时间：
累加完成事件或服务请求的（【事件或服务请求解决时间】－【事件或服务请求登记时间】）/完成的事件或服务请求数量
10
服务台解决率
在事件或服务请求总数中过滤所有【事件或服务请求分配次数】＝‘0’
11
二线解决率
在事件或服务请求总数中过滤所有【事或服务请求件解决人角色】＝‘二线工程师’
12
用户满意度
所有事件或服务请求记录中【用户满意度】分值总计/事件或服务请求总数
❑问题管理
⏹目的
规范问题管理流程的相关策略及活动，确保问题管理流程的执行质量和执行有效性。
⏹术语和定义
问题：
表示引起一个或多个现存或潜在事件的深层根源。
已知错误：
是指问题经过诊断分析后找到其产生的根源后所处的状态（KnownErrors）。
问题管理：
是负责管理问题所有生命周期的流程，包括诊断故障根本原因和确定这些问题解决办法的活动。
还要确保通过合适的控制过程实施解决办法，特别是变更管理和发布管理。
规避措施：
通过规避措施，用户能够在没有中断的情况下继续使用服务。
规避措施通常会使用户的工作方式发生变化，比如从使用另一台PC、使用早期版本的软件、或临时提供更多的磁盘空间。
⏹角色职责
问题经理
协调问题管理流程的日常操作
对问题的有效性进行判断
确保问题分派给问题分析专家
确保问题分析专家在其管辖范围内的可用性和能力
问题实施结果的评审与确认
问题提交人
记录问题基本信息并将其与相应事件、CI进行关联
将问题归类，初步设定其优先级
将问题提交给问题经理
与问题经理共同确认问题实施结果
问题分析专家
进行深入的问题分析，以找出根本原因，并提供解决方案
问题实施人
实施问题解决方案，如有需要，提起变更
记录问题实施结果，提请问题经理确认
问题管理流程中定义的角色
1.1
拟似问题信息收集并初步分类
●收集相关事件信息
●关联事件和配置
●初步将问题进行分类
事件和服务请求单；
问题工单
1.2
问题单提交
●问题提交人将生成的工单流转到问题经理
1.3
是否为问题
●问题经理根据问题定义判定问题如果是则转入1.4，否则注明原因，关闭问题单
1.4
确认问题单分类并排定优先级
●问题经理对问题分类、优先级进行确认
1.5
问题单分派
●根据问题类别将问题工单分派给相应问题分析专家
2.1
调查并诊断
●根据知识库排查故障判定是否为已知问题
●根据相关联配置项、历史事件排查问题根本原因
●制定解决方案/规避措施
2.2
是否挂起
●无法找到解决方案则挂起
●解决方案无法实施则挂起
●需要供应商操作则挂起
●其他情况转入1.11
2.3
●由问题经理将问题工单挂起
2.4
评审会议
●定期召开会议评审目前挂起问题工单处理方式
2.5
是否关闭问题
●当评审会议上问题分析专家一致决定无需解决的问题关闭
●评审会议决定强制关闭
●其他情况转入1.6
2.6
给出解决方案/规避措施
●问题分析专家给出问题的相关解决方案或规避措施
2.7
评审并分派
●问题经理确认方案可行性
●分派给相关问题实施人
2.8
实施方案
●根据解决方案进行相关实施活动
2.9
是否需要变更
●判定实施活动是否触发变更流程，如果触发则进入变更流程，如果不触发则转入1.15
2.10
解决问题
●变更流程关闭
●解决方案活动完成
3.1
评审
●对问题是否解决进行确认
●评审解决方案的有效性
3.2
问题是否解决
●最终判定问题是否解决，如解决则转入1.18，未解决则转入1.6
3.3
更新知识库
●将问题原因、解决方案/规避措施作为知识库更新的输入
3.4
关闭问题单
●问题经理关闭问题单
⏹流程间的关系
问题分类
●优先级由影响度和紧急度两个因素决定
●优先级在问题管理的生命周期中是可以改变的。
关于更改问题单优先级的原因和行为应该由问题经理进行操作。
•关键业务系统
升级会员 