基于ITIL的运维体系架构设计方案

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

1.1.运维架构设计

基于ITIL的运维管理体系的建立是企业在发展路程的一个阶段。而一个良好的运维管理系统,需要有一个清晰的运维流程来支撑。建设运维管理平台是一个长期的、持续的过程。

基于ITIL的运维服务体系建设应包含运维服务制度、流程、组织、队伍、技术和对象等方面的内容。同时结合业务特色,整合运维服务资源,规范运维行为,确保服务质效,形成统一管理、集约高效的一体化运维体系,从而保障数据集中条件下网络和应用系统安全、稳定、高效、持续运行。

1.1.1.基于ITIL运维服务管理机制

基于ITIL建立运维服务管理体系的过程分为以下7个步骤:理念导入、评估现状、确定目标及范围、流程设计、工具实施、上线试运行、持续改进。

理念导入

理念导入是ITSM项目实施的第一步,也是决定项目能够成功实施的关键一步。理念导入主要是学习、研讨、灌输基于ITIL最佳实践运维管理体系框架,包括ITIL的基本知识和实施理念,有共同的语言和目标,并明确运维服务管理的愿景,在组织内进行宣导。培训课程可以采用提问和研讨的方式,让运维人员成为主角。

评估现状

完成理念导入并建立愿景后,需要评估组织当前的服务管理流程成熟度及运维服务管理的现状,并查找分析差距,进一步明确

目标和范围。现状评估就是要通过定性和定量的分析、恰当的研究方法(包括调查问卷和现场访谈、观摩等)全面了解组织的运维服务状况,及其与理想状态之间的差距,并撰写评估报告。这是后面确定运维管理范围、工具实施的基础。

确定目标、范围

根据现状评估结果,制定近期运维服务管理的目标与范围。在不同评估现状下,制定的目标也不同,随着体系的不断改进完善,目标也在不断提升,迭代式地实现已制定的愿景。

梳理并固化服务流程,优化服务模式,通过系统实施和推广优化逐步提升运维服务管理能力,防范运维管理的风险,基于ITIL 构建初步的运维服务管理体系。包括:

(1)基于ITIL思想梳理并固化运维服务管理流程;

(2)实现统一的运维服务台,建立集中的运维知识库;

(3)完成事件、问题、配置和变更发布流程的实施;

(4)构建统一的配置数据库,为运维服务提供精确化的数据支持。

流程设计

有了目标与范围,就需要制定和实施运维服务管理方案,主要包括管理体系的梳理、流程设计的选型等环节。流程设计可以遵从先事件、服务台、问题、知识、服务级别后变更、发布、配置管理等顺序。

流程设计包括流程研讨、流程详细设计、评审确认3个环节。其要点是保证运维人员、管理层的参与度,由咨询顾问带领企业人员共同设计,关键点是要做好评审确认,让运维人员和管理层尽可能达成一致。评审确认会一般有两轮或多轮才能完成。。

工具实施

管理体系的设计、流程的制定、流程中相关指标的确立,都需要结合选择的工具以辅助体系实施,从而提高实施的效率。为了更好地符合企业自身的特点,本文采用在某成熟供应商的成熟产品基础上定制化开发,实现功能相对简单且能满足使用要求的运维服务管理平台。

运维服务管理平台共包含事件管理、自助服务管理、服务请求管理、问题管理、知识管理、变更管理、发布管理、配置资产管理、计划作业(含任务管理)、服务水平管理、报表管理等11个功能模块,其逻辑框架图。本文重点阐述已实施的事件管理、自助服务管理、变更管理、配置及资产管理等模块。

(1)事件管理

事件管理又称故障管理(Incident Management),其主要目标是尽可能快地恢复到正常的服务运营,将事故对业务运营的负面影响减小到最低,并确保可以维持服务质量和可用性的最高水平。事故管理的关键环节是:事件检测与记录、事件分类与初步支持、事件调查与诊断、事件解决与恢复、事件关闭、事件跟踪回顾等环节。

事件管理流程实施得好坏直接关系到项目的成败。主要考虑如下几点:

①事件的分类。进行前期的梳理,事件按照类别、子类和条目进行分类。一级分类包括桌面、网络、系统、信息安全、机房环境和应用。

②确定事件的优先级。事件的优先级由事件的影响度和紧急度来确定。影响度通常是考虑受影响的数量、部门,某种意义上将影响度往往等同于系统或设备的重要性。紧急度一般等同于事件的严重程度,对于业务系统或核心设备,宕机的紧急度大于性能下降的紧急度,性能下降的紧急度又大于单个非核心功能不可用的紧急度。

③谁负责关闭事件。事件应由服务台和用户进行确认并关闭,也可以允许用户在自助服务系统中确认并关闭。

④转派规则的设计。同组可以转派,跨组需要回退到服务台才可以转派,或者特定角色的人才可以跨组转派(如事件经理)。

⑤各个环节如何通知相关的角色和责任人。一般是通知受理人即可,但重大事件要第一时间通知事件经理、部门经理等主管领导。对于事件补单的情形,也要通知事件经理。整个事件处理的环节中事件的分派、等待、解决和关闭环节要及时通知用户。

⑥事件是否可以过期自动关闭。事件一般由服务台或者用户自助关闭,对于超过10天未关闭的,系统可以自动实现关闭,并且默认为已经解决。但是对于重大事件,必须由服务台进行关闭。

⑦事件满意度的获得。事件的满意度是ITIL中一个重要的考核指标,高满意度是IT部门的一个主要追求。项目中实现了基于系统的自动发送满意度征询邮件,用户可以通过邮件或自助服务模块反馈满意度及意见,对于超期未反馈的,邮件再次提醒,三天之内仍然未反馈的由服务台进行回访。但对于重大事件,事件解决后,服务台第一时间回访满意度。

⑧告警升级规则的涉及。服务级别协议(SLA)是指对于供应方在需求方要求下应当完成的活动的清晰描述,一个SLA总是以某种详细程度描述何时、何处以及如何完成这些活动[4]。由于单位的IT发展还比较弱,信息中心还没有与业务部门签署SLA协议,在这种情况下进行讨论,以一套“预期的”并向业务部门公布作为警告的SLA,并基于此进行升级和告警。表1所示为基于解决时间的事件警告升级规则。其中,首次升级时间指事件的解决时限,即事件从创建开始到当前时间或解决时间,在该时间尚未解决即要升级告警的时间;升级告警对象是升级告警时,从行政或者管理角度的升级告警,即向何种角色或领导升级、告警,以引起重视。

(2)自助服务管理

自助服务管理即“员工自助服务管理”,主要包含在线申报事件、服务请求、查询工单、访问知识库、对工单解决进行评价、授权与委托等。主要功能是:按服务目录提交服务请求、在线申报事件、查询用户的历史工单、访问知识库、对工单解决进行满意度评价。有效地实施自助服务,增加了业务部门和IT部门的渠道沟通,

相关文档
最新文档