基于ITIL的运维体系架构设计方案Word文档下载推荐.docx
《基于ITIL的运维体系架构设计方案Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《基于ITIL的运维体系架构设计方案Word文档下载推荐.docx（23页珍藏版）》请在冰豆网上搜索。
。
工具实施
管理体系的设计、流程的制定、流程中相关指标的确立，都需要结合选择的工具以辅助体系实施，从而提高实施的效率。
为了更好地符合企业自身的特点，本文采用在某成熟供应商的成熟产品基础上定制化开发，实现功能相对简单且能满足使用要求的运维服务管理平台。
运维服务管理平台共包含事件管理、自助服务管理、服务请求管理、问题管理、知识管理、变更管理、发布管理、配置资产管理、计划作业（含任务管理）、服务水平管理、报表管理等11个功能
模块，其逻辑框架图。
本文重点阐述已实施的事件管理、自助服务管理、变更管理、配置及资产管理等模块。
（1）事件管理
事件管理又称故障管理（IncidentManagement），其主要目标是尽可能快地恢复到正常的服务运营，将事故对业务运营的负面影响减小到最低，并确保可以维持服务质量和可用性的最高水平。
事故管理的关键环节是：
事件检测与记录、事件分类与初步支持、事件调查与诊断、事件解决与恢复、事件关闭、事件跟踪回顾等环节。
事件管理流程实施得好坏直接关系到项目的成败。
主要考虑如下几点：
1事件的分类。
进行前期的梳理，事件按照类别、子类和条目进行分类。
一级分类包括桌面、网络、系统、信息安全、机房环境和应用。
2确定事件的优先级。
事件的优先级由事件的影响度和紧急度来确定。
影响度通常是考虑受影响的数量、部门，某种意义上将影响度往往等同于系统或设备的重要性。
紧急度一般等同于事件的严重程度，对于业务系统或核心设备，宕机的紧急度大于性能下降的紧急度，性能下降的紧急度又大于单个非核心功能不可用的紧急度。
3谁负责关闭事件。
事件应由服务台和用户进行确认并关闭，也可以允许用户在自助服务系统中确认并关闭。
4转派规则的设计。
同组可以转派，跨组需要回退到服务台才可以转派，或者特定角色的人才可以跨组转派（如事件经理）。
5各个环节如何通知相关的角色和责任人。
一般是通知受理人即可，但重大事件要第一时间通知事件经理、部门经理等主管领导。
对于事件补单的情形，也要通知事件经理。
整个事件处理的环节中事件的分派、等待、解决和关闭环节要及时通知用户。
6事件是否可以过期自动关闭。
事件一般由服务台或者用户自助关闭，对于超过10天未关闭的，系统可以自动实现关闭，并且默认为已经解决。
但是对于重大事件，必须由服务台进行关闭。
7事件满意度的获得。
事件的满意度是ITIL中一个重要的考核指标，高满意度是IT部门的一个主要追求。
项目中实现了基于系统的自动发送满意度征询邮件，用户可以通过邮件或自助服务模块反馈满意度及意见，对于超期未反馈的，邮件再次提醒，三天之内仍然未反馈的由服务台进行回访。
但对于重大事件，事件解决后，服务台第一时间回访满意度。
8告警升级规则的涉及。
服务级别协议（SLA）是指对于供应方在需求方要求下应当完成的活动的清晰描述，一个SLA总是以某种详细程度描述何时、何处以及如何完成这些活动[4]。
由于单位的IT发展还比较弱，信息中心还没有与业务部门签署SLA协议，在这种情况下进行讨论，以一套“预期的”并向业务部门公布作为警告的SLA，并基于此进行升级和告警。
表1所示为基于解决时间的事件警告升级规则。
其中，首次升级时间指事件的解决时限，即事件从创建开始到当前时间或解决时间，在该时间尚未解决即要升级告警的时间；
升级告警对象是升级告警时，从行政或者管理角度的升级告警，即向何种角色或领导升级、告警，以引起重视。
（2）自助服务管理
自助服务管理即“员工自助服务管理”，主要包含在线申报事件、服务请求、查询工单、访问知识库、对工单解决进行评价、授权与委托等。
主要功能是：
按服务目录提交服务请求、在线申报事件、查询用户的历史工单、访问知识库、对工单解决进行满意度评价。
有效地实施自助服务，增加了业务部门和IT部门的渠道沟通，依靠有效的知识库，简单问题还能由用户自助解决，不但提高了业务部门用户IT技能和知识，也减轻了信息中心的工作量。
（3）变更管理变更管理流程通过可控的方法及步骤来管理所有针对IT生产环境的变更，从而消除或最小化变更对IT服务质量的影响，同时提高日常的运维效率。
通过对所有变更的正确评估，可以维护IT环境的完整性；
变更和变更实施得到正确记录，并提供审计记录。
在变更流程的实施中重点关注两个问题：
一是变更类型的定义及审批流程。
变更的核心是审批、授权，及其在变更流程中对变更风险的评估。
二是变更时如何与配置管理数据库（CMDB）衔接，发挥CMDB的价值。
要求所有的变更都要关联CMD，B这样既可以精细化定义变更流程，也可以经过长时间的数据记录，从CMDB的维
度查看一个配置项曾经有过的变更请求，有利于提高运维效率，在出现事故时更快地查找原因。
另外，在变更完成后，要求在变更流程中强化CMDB的同步更新和维护。
（4）配置及资产管理
配置管理的目标是定义IT服务和基础设施的部件，维护与IT部件及利用这些部件提供IT服务有关的记录，并确保这些记录的可靠性；
提供准确的信息和文档以支持其他服务的管理过程[5]。
配置管理控制的范围包括硬件、软件、流程、人员以及相关文档，并在CMDB中集中管理。
其逻辑模型图。
其中记录包含配置对象的
详细配置信息、变更历史信息、生命周期信息、配置之间的关联关系信息以及与事件、问题、变更管理的关联关系信息。
CMDB的建设至关重要，主要有以下几点需要重点考虑：
1CMDB配置模型的设计、管理的范围和颗粒度的选择。
管理的类别，比如主机、网络、存储、应用系统、数据库实例、中间件实例等；
管理的层次属性，可以业务系统为视角加以考虑，哪些业务系统及其支撑业务系统的主机、存储、数据库、中间件要纳入CMDB管理的范畴，一般是先实施核心系统后实施外围系统；
管理范围的关系，配置项的关联有很多种：
连接、依赖、运行、安装部署、父子、主备、等同等，不同类型的配置项之间可能有一种或多种关系。
2要高度重视配置项数据的收集和梳理。
配置项数据的收集是一项费力费时的工作，但方法恰当，可以事半功倍。
建议除网络设备、机房设备（配线架、空调、UPS等）外，以应用系统为维度考虑：
应用系统、主机、存储、数据库、中间件等类别的配置项，先应用系统后主机，然后数据库实例、中间件实例、应用实例，最后考虑网络设备、机房设备等。
3在收集完配置项属性和关系数据并规格化后导入CMD，B并
建立基线。
4构建CMDB的目的和价值在于运用。
在事件、问题等工单的记录中要关联CMDB的配置项，在变更发起和变更计划时要关联CMD，B并基于CMDB评估变更风险和影响。
5为了保证CMDB的数据的完整性和准确性，在有效实施变
更流程的同时，定期对CMDB做“盘点”，即定期审计，主要是看配置项的属性和关系是否与生产环境一致，如果不一致要查明原因，并审查流程和制度规范。
6要考核配置管理数据库如何应用，比如是否有必要和监控系统整合；
与事件、问题、变更、发布等流程的关联关系；
与资产管理的关系等。
既不要高估配置管理的短期价值，但也不要低估配置管理长期的价值。
（5）报表
基于ITIL的核心KPI考虑，包括事件总数、事件关闭的数量、事件成功关闭的数量/比率、规定时间内解决的事件数量/百分比、超时未解决的事件数量、规定时间内响应的事件数量/百分比、平均解决时间、一次成功解决率、问题总数、已找到根本原因的问题数量、趋势分析问题所占比率、通过变通办法解决的问题数量、问题成功解决率等。
上线推广
在完成工具实施后，要进行上线测试、试运行和推广。
在系统正式上线前，需要组织好相关人员参加培训，掌握流程、制度和工具。
由于项目不仅仅涉及到信息部门，自助服务还涉及到业务部门的培训和使用，所以项目中对信息部门先做培训，在应用推广等相对稳定和成熟后，再向业务部门推广自助服务模块。
持续改进
根据戴明质量环所倡导的PDCA的管理思想，流程设计应该是一个持续优化和改进的过程。
业务在发展、技术在进步、成熟度在提升，运维流程也要不断优化和完善。
项目结束后，主要是由流程经理或流程负责人定期或不定期地组织会议、研讨、总结、修订、完善运维流程。
1.1.2.运维服务岗位及职责设置
运维服务组织岗位设置如下：
图1运维服务组织岗位结构图
岗位职责表如下：
岗位
职责
作息时间
运维
经理
1.执行公司运维管理体系及运维运作机制,负责部门内部的日常管
理和整体协调与推进；
2.组织运维项目调研团队，对客户运维需求和系统现状进行调研；
3.跟踪、协调重大事件、紧急故障的处理；
4.制定年度培训计划，提高运维的整体技术和管理水平；
5.公司内部沟通协调，协助运维团队现场技术服务所需相关资源；
6.参加客户运维相关例会,跟踪落实客户提出的意见持续改进运维服务的质量；
每周5天
每天8小
时工作
7.协助运维项目经理完成运维方案的编写工作，并参与评审；
8.执行调度命令和指令；
9.完成公司领导下达的工作任务。
10.编制运维方案并组织相关人员进行评审；
11.协助营销完成运维合同的签订；
12.协调运维所需的相关资源，保障对客户呼叫及时响应和处理；
13.负责与客户运维主管部门领导进行沟通和协调，组织解决运维中存在的问题；
14.编制运维项目的实绩材料向客户进行汇报。
客服
1.遵循运维流程，受理客户的报修，并创建事件进行跟踪，事件处理完毕后，进行事件的反馈；
2.管理故障报告书，收集、统计运维过程的实绩数据。
调度
1.负责故障（或客户投诉）处理时现场生产协调和紧急处置；
2.负责组织编制故障报告书和召集故障分析会；
3.负责设备运行状态、故障情况、预防维护情况信息的收集和传递；
4.负责日常维护、预防维护实施过程的协调、跟踪、检查、整改落实和持续改进；
5.负责调度指令和调度命令的发布；
6.参加客户的生产、设备相关例会；
7.负责故障（或客户投诉）处理时内部协调和外部信息沟通；
8.负责内部信息、外部信息的传递；
9.保持与客户及运维管理部门的信息沟通，执行客户调度命令和指令；
10.发布生产用车辆调度命令和指令。
系统
运维护组组长
1.负责所维护系统及机房的日常管理；
2.负责现场协调和用户间的信息沟通；
3.协助分析故障原因，汇总故障处理信息，负责紧急预案、预防措
施的实施和反馈；
4.制定岗位操作规程，编制日常点检及维护规程，起草定期预防性维护计划与实绩、年度维护报告；
5.执行调度命令和指令。
运维护组组员
1.实施系统日常点检及维护；
2.受理、处理并记录运维过程中的事件，发现问题若不能及时处理，需立即报调度，协调技术支持人员处理；
3.按照规程完成系统的日常备份和相关定时任务工作；
4.执行调度命令和指令；
5.执行组长安排的相关工作。
桌面运维组
组长
1.负责所维护桌面终端的日常管理；
3.制定岗位操作规程，编制日常点检及维护规程；
4.管理组内成员；
组员
1.实施桌面终端日常维护工作；
2.受理、处理并记录运维过程中的事件，发现问题若不能及时处理，需立即上报，协调技术支持人员处理；
3.执行组长安排的相关工作；
4.执行调度命令和指令。
每周5天每天8小时工作
网络
1.负责网络运维日常管理和安全管理工作；
2.协助完成运维方案、运维技术附件的编制和评审工作；
3.负责现场协调和用户间的信息沟通；
4.协助分析故障原因，汇总故障处理信息，负责紧急预案、预防措施的实施和反馈；
5.制定岗位操作规程，编制日常点检及维护规程，起草定期预防性维护计划与实绩、年度维护报告；
6.执行调度命令和指令；
1.
实施网络系统日常点检及维护；
2.
受理、处理并记录运维过程中的事件，发现问题若不能及时处理，
运行
需立即报调度，协调技术支持人员处理；
维护
3.
按照规程完成网络系统的日常巡检、监控、备份和相关定时任务
组组
工作；
员
4.
执行调度命令和指令；
5.
执行组长安排的相关工作。
审核系统预防性维护方案；
应用
审核系统改善建议，编制系统改善方案；
制定重大事件重大故障处理方案；
护组
协助项目经理组建运维项目调研团队、实施团队；
参与运维服务级别协议评审、项目计划书评审；
6.
执行调度命令和指令。
提供对事件处理的技术支持；
实施问题、变更的处理；
编制、审核并完善系统维护规程；
编制、完善系统预防性维护方案并组织实施；
协助项目经理完成年度维护报告中相关内容；
提出系统改善建议；
7.
负责对客户的系统现状进行调研，填写运维服务需求分析调研表；
8.
协助项目经理完成运维服务级别协议的编制工作，并参与运维服
务级别协议评审；
9.
参与运维项目计划书的评审；
10.
协助项目经理完成运维项目结题文档的编制工作；
11.
完善和优化应用系统功能；
12.
调整应用系统与其他系统的接口；
13.
机房
一线
1.事件的录入、受理、处理；
2.日常点检；
3.日常备份；
4.实施一线发布；
5.管理承担运维项目的机房环境及现场各类设备；
6.按交接班制度对工作进行交接；
7.完成组长布置的工作；
8.配合二线人员及其所作相关工作；
9.配合运维交接；
10.按照网络C检计划实施网络C检；
11.对非常规故障建议提出问题并实施跟踪；
12.异常状态及紧急情况下呼出和汇报；
13.熟悉现场生产业务和环境，对危险源能有效辨识；
14.判断故障归属等级及影响范围，把握故障处理进度；
15.执行调度的指令和命令；
16.终端信息安全；
17.项目实施过程中配合项目端工作；
18.PC服务器上的信息安全工作实施（方案二线出，一线实施）
19.安全工作；
20.定修工作（专业维护）；
计划编制，定修实施；
21.服务报告编写（一线负责编写内容的部分）；
22.接入层交换机故障处理。
倒班模式
、三、四线运维支持岗位和职责：
培训并指导运维项目的一线维护人员和现场二线技术人员；
二线技
及时响应并处理武钢有限的系统、网络、应用的服务请求；
术支持
协助一线运行组组长编制日常运维的系统点检、维护规程、定期预防
性维护计划与实绩、年度维护报告；
协助项目现场二线技术人员完成系统软件、硬件、网络、信息安全的预防性维护工作；
协助项目经理完成维护方案的编制工作；
执行调度命令和指令。
指导武钢有限运维项目二线技术支持人员，提供对重大事件和紧急故障处理的技术支持；
三线技
审核紧急故障处理方案；
审核年度预防维护计划；
制定备件策略，编制、审核备件计划；
四线技
提供对重大事件和紧急故障处理的原厂商级别技术支持；
提供原厂商级别的技术标准和规范。
1.1.3.基于ITIL运维服务体系建设原则运维服务体系建设的原则有以下几个方面。
一是以完善的运维服务制度、流程为基础。
为保障运行维护工作的质量和效率，应制定相对完善、切实可行的运行维护管理制度和规范，确定各项运维活动的标准流程和相关岗位设置等，使运维
人员在制度和流程的规范和约束下协同操作。
二是以先进、成熟的运维管理平台为手段。
通过建立统一、集成、开放并可扩展的运维管理平台，实现对各类运维事件的全面采集、及时处理与合理分析，实现运行维护工作的智能化和高效率。
三是以高素质的运维服务队伍为保障。
运维服务的顺利实施离不开高素质的运维服务人员，因此必须不断提高运维服务队伍的专业化水平，才能有效利用技术手段和工具，做好各项运维工作。
1.1.4.基于ITIL运维服务体系的总体架构
运维服务体系由运维服务制度、运维服务流程、运维服务组织、运维服务队伍、运维技术服务平台以及运行维护对象六部分组成，涉及制度、人、技术、对象四类因素，其总体架构如下图所示。
制度是规范运维管理工作的基本保障，也是流程建立的基础。
运维服务组织中的相关人员遵照制度要求和标准化的流程，采用先进的运维管理平台对各类运维对象进行规范化的运行管理和技术操作。
图2运维服务体系总体架构
1.1.4.1.运维服务制度和流程
为确保运维服务工作正常、有序、高效、协调地进行，需要根据管理内容和要求制定一系列管理制度，覆盖各类运维对象，包括从投产管理、日常运维管理到下线管理以及应急处理的各个方面。
此外，为实现运维服务工作流程的规范化和标准化，还需要制定流程规范，确定各流程中的岗位设置、职责分工以及流执行过程中的相关约束。
1.1.4.2.运维服务组织和队伍
根据运维服务工作的内容和流程确定各项工作中的岗位设置和职责分工，并按照相应岗位的要求配备所需不同专业、不同层次的人员，组成专业分工下高效协作的运维队伍。
1.1.4.3.运维服务工作流程
为保障运行维护体系的高效、协调运行，应依据管理环节、管理内容、管理要求制定统一的运行维护工作流程，实现运行维护工作的标准化、规范化。
其环节包括事件管理、问题管理、变更管理和配置管理。
1.1.4.4.运维技术服务平台
运维技术服务平台包含实施运行维护和技术服务的各种手段和工具，通过技术手段固化标准化的流程、积累和管理运维知识并开展主动性运维工作。
1.1.5.运维服务体系建设的内容
1.1.5.1.运维管理制度建设
总结现有的运维管理经验，遵照国内外相关运维标准，结合目前的实际情况，统一制定运维管理制度和规范。
通过定期和不定期的检查，促进各项制度规范的贯彻落实，从而建立起统一、规范的运行维护管理工作方式。
同时，随着信息化建设的不断发展，也要确保各项制度的及时更新。
制度体系内容要涵盖机房管理、网络管理、资产管理、主机和应用管理、存储和备份管理、技术服务管理、安全管理、文档管理以及人员管理等类别。
各类制度具体内容因需要而定，如网络管理制度需覆盖网络的接入管理、用户管理、配置管理及网络日常运行管理和应急处理等。
安全管理制度需覆盖包括机房设施、网络、主机、数据库、中间件、应用软件、数据信息的安全管理、其他机密资源和人员的安全管理以及安全事件的应急处理等。
1.1.5.2.运维技术服务平台运维技术服务平台由运维事件响应中心、运维管理系统、运维知识库和运维辅助分析系统构成,平台采用分布式管理模式。
（1）整合监控平台将监控数据交换到运维事件响应中心、运维流程管理系统、运维知识库、运维辅助分析系统，支撑运维体系。
（2）运维事件响应中心问题接收分
升级会员 