IT服务管理教学课件作者赵晨干红华蔡晓平郑贤榕IT服务管理平台构建与应用3章节.ppt

IT 服务管理 (IT Service Management),浙江大学软件学院 宁波电子服务研究院 浙江大学电子服务研究中心 赵晨 zhaoc@,2012年2月,第三章 ITIL理论基础,3.1 ITIL概述 ITIL（Information Technology Infrastructure Library，IT基础设施知识库），是英国政府中央计算机与电信管理中心（CCTA）在20世纪80年代中期发布的一套IT服务管理最佳实践指南 ITIL为企业的IT服务管理实践提供了一个客观、严谨、可量化的标准和规范自ITIL发布以来，已经得到了全球几乎所有IT巨头的全力支持并成为ITSM事实上的国际标准 ITIL目前有3个版本：v1版主要是IT管理者的经验积累，包含40多个流程；v2版在v1版基础上对管理流程进行了分类与整理，形成了业务管理、服务管理（ITSM，ITIL核心模块）、IT基础架构管理、应用管理、安全管理、IT服务规划管理与实施等6个模块：v3版强调进行生命周期循环的IT管理，分为服务战略、服务设计、服务转换、服务运行、服务改进5个部分3.2 ITIL v2 — 以流程为中心,ITIL v2版本主要包括六个模块，即服务管理（Service Management）、业务管理（The Business Perspective）、ICT（信息与通信技术）基础设施管理（ICT Infrastructure Management）、应用管理（Application Management）、IT服务管理实施规划（Planning to Implement Service Management）和安全管理（Security Management），如图3-1所示。

图3-1 ITIL v2的整体架构,ITIL的核心流程,Service Level,Continuity,Availability,Release,Incident,Change,Problem,,服务支持,服务提供,,服务水平管理,,能力管理,,IT 服务可,持续度管理,,可用性管理,,财务管理,,发布管理,,配置管理,,事故管理,,变更管理,,问题管理,,,IT基础设施及人员,提供高质量、低成本的IT服务,确保IT服务的稳定与灵活性,IT服务支持与提供管理核心流程示意图,3.2.1 服务台,服务台功能内容讨论的是一项职能、一个组织单元或者说一个部门，而ITIL的其它部分主要介绍的是一些流程服务台在IT服务管理中扮演了至关重要的角色 服务台的目标是通过保证有关的呼叫请求能够到达IT部门和进行一些支持性活动(从不同的流程)来支持约定的服务供应 服务台需要从事与许多ITIL基本流程相关的活动，如图3-2所示图3-2 服务台与相关流程,,3.2.1.1 服务台的结构,服务台的一项重大任务就是确保IT部门的可达性(Accessibility)应该鼓励用户在其碰到任何问题或需要支持时呼叫服务台。

用户呼叫被处理的方式可由系统(PABX，自动用户交换机)进行监控并生成相应的报告 服务台结构有多种选择常见的方式包括： 集中式服务台(Centralised Service Desk)作为所有用户的单一联系点，可能还单独设立了一个服务台来处理用户在业务应用系统方面的问题(职能分离的集中式服务台，Split Function Centralised Service Desk) 本地式(分布式)服务台(Local／Distributed Service Desks)分布在多个地方通常，将服务台划分为多个本地服务台将会导致更加难以管理 虚拟式服务台(Virtual Service Desk)并没有实质性的位置，这是由于使用了通信技术3.2.1.2 服务台的人员,对服务台人员的要求是由服务台的使命和结构来决定的下面列举了几种服务台使命及其相应的人力资源需求： 呼叫中心 非技能型或呼叫记录型服务台 技能服务台 专家型服务台,3.2.1.3 服务台的技术,建立服务台需要许多的技术工具除了一个有效的服务管理工具之外，还包括 ： 集成了系统管理工具的服务管理工具； 通信技术，如计算机技术集成(CTI)或网际协议语音通信(VOIP)； 交互式语音响应系统(IVR)； 电子邮件(E-mail)； 服务器(基于E-mail或互联网的)； 将呼叫请求转发到寻呼机、移动、便携式电脑和掌上型电脑的技术。

知识、搜索和诊断工具(知识库，基于推理的案例)； 自动化系统管理和网络工具； 企业内联网和互联网的自助服务平台3.2.1.4 服务台的活动,1、响应呼叫请求：指用户与服务台进行的联系所有的呼叫请求都应该记录下来以便进行进度监控和为流程控制提供有关的量化指标 事件 — 基本上包括所有的呼叫，除了那些与标准化变更相关的呼叫以外： 变更 — 这些是指不被当作服务请求处理的非标准变更针对这种变更的请求必须遵循标准的变更管理流程，需要提出一项正式的变更请求(RFC) 2、发布信息 3、供应商联络 4、运营管理任务,3.2.1.5 服务台的指标,客户或用户的满意度是反映服务台运作效果的主要指标一些常用的关键绩效指标包括： 对来电是否快速接听(如90％的呼叫在x秒内得到响应)？ 呼叫是否在x分钟内被转到二线支持(如果它们不能在服务台得到解决)？ 服务是否在可接受的时间内得到恢复并且符合SLA的要求？ 针对当前和未来的变更、错误，用户是否及时得到了建议？ 有些绩效指标只能通过客户调查的方式进行测度，如： 接听是否礼貌客气？ 用户是否得到了良好的建议来防止事件的发生？,3.2.2 IT服务支持管理,ITIL v2中《服务支持》(Service Support)主要论述客户和用户如何获得恰当的服务来支持他们的活动和业务，以及这些服务怎样得到支持。

图3-3 IT服务支持管理组成,,,图3-4 IT服务支持管理模型,,3.2.2.1 事件管理,事件管理的首要目标是要解决事件并尽快恢复服务的供应事件被记录下来，并且这种记录的质量能够影响其他多个流程运作的有效性 对事件（Incident）和问题（Problem）加以区分可能是ITIL对IT服务管理领域所作的最广为人知但往往不一定最受欢迎的一项贡献尽管这种区分有时候会令人觉得很迷惑，但它有一个最大的优点在于，它可以区分快速恢复服务以及确认事件产生原因并加以补救之间的区别事件管理,应用:事件可能是：一个应用程序不能正常运行从而使客户不能正常工作；也可能是服务器硬盘的使用容量超过正常阀值等等所有这些影响到与应用相关SLA或使应用不能正常访问的事故（除非与硬件有关）都应归入应用事件类别中 硬件:主要是指硬件功能事故，包括系统宕机，自动切换，打印机错误或其它配置项事故等 服务请求:主要是指客户与应用及硬件无关的请求，包括信息，文档，建议或忘记密码等方面的请求事件管理流程,事件管理的主要活动,事件匹配流程,优先级划分流程,事件升级过程（Escalation）,没有升级的事件控制流程,有升级的事件控制流程,3.2.2.2 问题管理,问题管理是指负责解决IT服务运营过程中遇到的所有问题的流程，目标就是要查明该问题产生的潜在原因。

事件 问题 已知错误 一旦问题产生的原因已经查明并已制定出相关的应急措施，则该问题就归类为已知错误（Known Error），并且需要从业务上决定是否需要进行一次永久性的修改以防止同样的事件再次发生作出修改的流程是通过一项变更请求（RFC）触发的如果从业务上认为没有必要作出修改，但已确认了临时性的应急措施或永久性的解决方案，则该问题仍然被归类为已知错误 问题管理主要活动： 问题控制过程 已知错误控制过程 问题防范控制过程,问题管理生命周期,问题管理流程,问题管理与其它服务管理流程之间关系,信息,信息,记录,匹配信息、应急措施 快速恢复,变更请求RFC,实施后评审PIR,问题控制过程,已知错误控制过程,3.2.2.3 配置管理,配置管理（Configuration Management，CM）主要是关于对不断变化的IT基础设施进行控制（标准化和状态监控），识别基础设施内所有重要的组件，收集、记录和管理有关这些组件的信息，以及为所有其他的流程提供有关这些组件的信息的流程 配置管理的活动是将一个系统中软件和硬件等配置项资源进行识别、定义，并记录和报告配置状态和变更请求、检验配置项的正确性和完整性等。

配置项（CI） 基线（Baseline） 配置管理数据库(CMDB),,配置与配置项（CIs）,硬件配置项 图例,配置管理的主要活动,配置管理数据库（CMDB）－设计原则,配置管理的颗粒度问题全世界没有一个人可以给某个公司正确的配置管理的颗粒度的硬性指导原则，这不是一个硬性或可以测量的事物，但有一些基本的道理在内可以帮助我们思考： 第一原则是颗粒度与我们运维能力成正比，当你可以去修复一台电脑的内存条或硬盘时，你的颗粒度就需要到达内存条这一颗粒度，如果没有这个运维能力，你只需要关注整机； 第二个原则是当你需关注配件时，你的颗粒度最好能够覆盖到这一层级，因为在配置管理中，备用件的信息是起码需要关注的； 第三个原则是你的管理需求决定你关注信息的多少（属性池） CMDB的维护成本问题CMDB的维护成本与颗粒度是与正比的，因为信息越大，维护成本就可能越大： 每个配置项及其版本号； 变更可能会影响到的配置项； 配置项的变更路线及轨迹； 受问题、事故等服务管理流程影响的所有配置项； 计划升级、替换或弃用的配置项； 不同配置项之间的关系– 配置管理数据库（CMDB）－构建原则,自上而下，自下而上的方法：把自已的CI分类搞清楚再说，搞清楚了分类，再去谈属性，最后想好CI如何组装在一起，方便调用，CMDB不是孤立存在的，一定要想好各个其它流程的调用与关联问题，没有想好前，就不要动手设计数据库。

–配置管理数据库（CMDB）的状态分析,业务情况：运维项目较多，有网络、系统的、桌面的、软件的，而且设备都存在共用的情况，比如一个段线路，会属于多个项目使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，IT组件一是数量多（光是需要桌面运维的电脑台数在数千台），二是相互的关系复杂 配置管理规划： Ci分类规划 ； Ci属性设计 ； Ci命名规划 ； Ci模版制作 ； 配置数据收集 ；,一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– 一个配置管理数据库（CMDB）的例子,– Configuration Management,Q&A? 练习与作业（设计一个模拟的CMDB) 客户组织 服务目录 运维对象 运维组织（重点） 兴趣小组：建立浙大软件学院(或其它单位)的CMDB,3.2.2.4 变更管理,变更管理讨论有关对IT基础设施实施变更所进行的审批和控制。

该流程的目标是，通过对变更进行评估，从而确保能够在对IT服务产生最小负面影响的情况下实施这些变更，同时通过在组织内进行有效的协商和沟通，确保所有的变更都具有可追溯性变更是在与配置管理的状态监控活动、变更请求的发起人、问题管理以及其他多个流程进行协调后得到实施的变更的实施需要遵循定义、规划、构建、测试、验收、实施和评估这样一个特定的路径 变更管理基本要素： 变更 变更请求（RFC） 变更实施进度（F。