1、,2011年10月,基础培训,IT Infrastructure Library,信息技术基础设施库,第三章 ITIL十大流程简介,第三章 ITIL十大流程简介,ITIL 十大流程,服务提供流程 服务级别管理IT服务财务管理IT服务持续性管理可用性管理能力管理服务支持流程事故管理问题管理配置管理变更管理发布管理管理职能服务台,服务提供Service Delivery,服务支持Service Support,工作目标：提供与客户的单点联系促进日常服务的恢复（作为突发时间的跟踪者）生成报告，沟通和推广服务为组织增加价值活动：为IT客户提供建议和指导为IT客户快速恢复日常服务从被动支持到更多主动服务
2、监控并支持SLA服务目标的完成沟通和推广服务产生和报告IT管理信息,服务台 Service Desk,思考：服务台如何支持 SLA目标的完成？举例：向最终客户承诺了每月网络Link Down 3小时以内，如果突发一个Link Down故障，服务台如何定义该故障级别？可能1：当月未发生过Link Down可能2：当月已发生Link Down 2.5小时,服务台的职责：接听客户呼叫电话，提供一线支持记录，设定优先级并跟踪突发事件使客户了解服务请求处理进展状态升级服务请求协调二线/三线支持团队向客户确认并终止事件生成报告重点：发生的主要事件、问题、变更，已经与之相关的应急措施客户不满意事件运行不良的
3、IT设施下周计划的变更,服务台 Service Desk,思考：1、呼叫中心、帮助台（HELP DESK）和服务台的关系2、服务台跟踪突发事件处理过程的作用和意义3、如何通过电子化手段与最终客户建立个性化的联系，建立个性化档案（特别适用于桌面PC服务）4、如果网管监控人员发现故障，应该首先做什么？,如何评估服务台的工作,衡量(Measures),让我们衡量ServiceDesk.定量： 首次呼叫解决率 % 所有问题解决率 % 客户满意度 rating range 升级到二线的问题 %定性：完备的审计功能使责任到人,摒弃了工作中的推诿问题自动升级上报机制大大提高整体服务水平等级知识共享减少了大量
4、的重复工作,服务台服务质量参数（举例）,每天需要升级的事件可能违背SLA的地方所有显著/特别的事件每周一周内经常发生的，占用员工最多处理时间的事件需生成问题记录的事件已知错误与变更请求违背SLA的地方客户满意度影响业务的趋势员工工作量,如何评估服务台的工作（举例）,每月服务可用性整体绩效、成绩与趋势分析客户感受与满意度级别最终客户培训与教育需求员工绩效技术性能回顾评审报告的内容提供服务的成本,服务支持流程之间的关系,突发事件（Incident）会引起或可能引起服务中断、服务质量下降的任何事件 硬件故障、软件故障、服务请求,事件管理 Incident Management,定义,任务,目标,尽快
5、将服务恢复到正常状态最小化突发事件对业务运作的负面影响确保服务质量和可用性满足SLA指标,探测和记录分类和在线支持确认优先级 (影响和紧急度)调查和诊断解决和恢复结束职责、监控、跟踪和交流,变通方案应急方案举例：计算机重启；打印机故障，将打印任务分配到其他打印机上；服务请求：除了IT基础设施（硬件、软家）故障外的事件都是服务请求思考：举例：邮件收得慢，是否算突发事件？答：要根据事先约定的阀值来判断事先约定，能收下来即可，不算突发事件事先约定，10M邮件3秒钟下载完成，有可能算,事件管理 Incident Management,突发事件生命周期,思考：事件发生并得到处理后，由谁来结束事件？为什么
6、？强调责任、避免客户请求丢失,事件管理 Incident Management,事件管理 Incident Management,并非所有的事件都能由服务台和一线支持加以解决。在不能解决的情况下，事件必须转交给后续支持组。为了及时获得后续支持组的协助，我们需要建立事件升级机制,思考：以什么标准决定是否需要升级？时间自动触发分工事先确定举例：有一天一线人员很忙，有一些应该由一线处理的到时仍未处理，应否升级？从客户视角看,该流程的输入为：来源于服务台、网络和计算机等事件的详细信息相关操作来自配置管理数据库(CMDB)的详细配置信息事件与问题或已知错误是否匹配的反馈以往相关解决方案的详情相关事件变更
7、请求（RFC）的反馈,突发事件流程的输入和输出,该流程的输出是以某种方式尽快恢复服务，例如：事件解决方案的变更请求 更新的事件记录（包括解决方案和或临时解决措施）已解决和结束的事件与客户交流的相关信息管理信息（报告）思考：如何提高记录的效率？不是记录而是匹配,a、用户绕过事件管理的程序如果用户没接收该流程的培训，他们可能不遵循正确的程序，而是自己试图去解决错误。结果，事件记录不能准确的更新。b、事件超负荷出现以下情况，可能超负荷- 没有对事件进行清楚归类。- 没有正确分配和转送事件。c、事件升级（escalation）的增加如果支持团队不具备适当的技能和资源，事件可能迅速升级到更高级别的支持团
8、队。这将给专家支持团队增加不必要的工作量。d、服务级别协议没有清楚定义如果事件管理流程支持的服务没有在服务级别协议(SLAs) 中清楚地定义，事件管理人员不知道哪些报告的错误和需求可以作为事件。e、组织中文化的变更组织中实施事件管理流程需要以流程为导向。结果，更多的任务、责任和更严格的纪律要求可能超出员工的预料，一些人就会产生抵触情绪。,事件管理中可能发生的问题, 1. 除非在服务级别协议说明，不可绕过服务台（单一联络点）。 2. 服务台软件工具将包括与问题管理、变更管理、配置管理系统的高度集成。 3. 所有呼叫的解决必须在系统中存档。 4. 需要为判断突发事件，使用配置管理数据库。 5. 突
9、发事件解决的进度必须主动通知最终客户，应由服务台人员完成。,事件管理最佳实践1,6. 为了统一和经济，服务台可作为IT的主要通讯手段来与最终客户交互：突发事件/服务状态，正在解决的问题，变更管理状态，服务停止和服务可用性。 7. 呼叫升级的过程必须存在。基于业务影响的自动呼叫升级必须存在。 8. 服务台应对计划的和最近已实施的变更高度感知。 9. 来自监控报警的输入将自动输入系统。 10.建议采用已知错误数据库和专家系统。,事件管理最佳实践2,问题（Problem）从多个具有相同现象的突发事件或一个重大的突发事件获取的、表明存在某个未知原因的错误的情况。已知错误（Known Error） 已成
10、功诊断问题的根源、找到解决方案的情况。,问题管理 Problem Management,定义,任务,目标,最小化由于IT基础架构错误引起的突发事件和问题的负面影响，防止与错误相关的突发事件的再次发生。问题管理负责查找问题根源并采取措施消除已知错误。,问题控制已知错误控制积极的问题管理 趋势分析 重大问题回顾,什么样的突发事件会去分析？,举例：1、二三层网络不匹配；2、Office2003与2000不太兼容,关注事件的根本解决和预防分析潜在问题，找出根本原因产生问题解决的变更请求问题趋势分析产生管理报告思考：如何做好主动式问题管理？,问题管理问题控制,问题跟踪和监控,问题分析,问题识别和记录,问
11、题分类和分配,问题调查和诊断,(已知错误控制),问题管理已知错误控制, - 解决问题前后事件发生的数量对比 - 解决问题花费的时间 - 解决问题过程中发生的成本（人力、物力资源等）,关键绩效指标,变更（Change ） 导致一项或多项IT基础架构CI状态变化的一个行动。标准变更 (事先经过审批)变更请求 (RFC)变更下一步日程安排 (FSC)变更顾问委员会 (CAB),变更管理 Change Management,定义,任务,目标,确保通过标准化的手段和流程有效的控制和处理所有变更，以最小风险、高效的、高费效比的来实施被批准的变更,受理、记录、批准、计划、测试、实施并回顾审视变更请求提供IT
12、基础设施的变更报告驱动CMDB的修改,思考：何时实施变更？为什么？ 以服务器迁移为例。要评估能否在非服务时间实施变更；能否同时实施多个变更，以降低对客户/业务的影响,识别和定义配置项 Identifying and defining Configuration Items (CI) 规划、定义与管理配置管理数据库 Planning, design & management of Configuration Management Database (CMDB)定期验证CMDB的准确性和完整性 Regular verification of CMDB accuracy IT资产的详细报告 Deta
13、iled reporting of assets,配置管理 Configuration Management,硬件 CI举例,FILE SERVERS,NETWORK,MODEM,HUB,MODEM,SCOPE,CI LEVEL,关联关系Is connected toIs part of,属性Owner, Status, Location, Version,Serial Number,Keyboard,CPU,Mouse,MAINFRAME,发布增量发布（Delta Release）完整发布（Full Release）包发布（Package Release）紧急发布（Emergency Rel
14、ease）发布策略（Release Policy）,发布管理 Release Management,定义,任务,目标,发布管理全面考核对IT服务的变更，确保综合考虑一项发布的各个方面，包括技术和非技术因素。,发布规划设计、开发和配置一项发布发布审核上线计划交流、准备和培训分发和安装,28,June 12, 2018,Service Delivery,服务提供流程之间的关系,SLAs, SLRs OLAs服务报告服务目录意外报告审计报告,应急计划风险分析需求定义控制中心容灾计划审计报告,服务级别管理,效益提高客户满意度提高服务质量降低运行费用,主要活动评估特定客户的服务需求将标准服务映射到客户需
15、求定义定制服务协商并生成书面的SLA建立服务业绩评估周期设计定制服务分析与服务级别有关的业绩数据创建客户报告进行服务业绩评估建议服务改进内容,服务级别管理流程根据预先确定的标准服务参数来定义、协商、监控、报告和控制针对具体客户的服务级别；该流程还可以按照客户的服务级别协议(SLA)的要求创建定制服务,服务级别管理 Service Level Management,服务级别管理架构,典型的服务级别协议(SLA)包含:,服务时间 (service hours)可用性 (availability)双方协议的工作量和吞吐量 (agreed workload and throughput)用户支持级别
16、(user support levels)响应性 (responsiveness)限制条件 (restrictions)功能 (functionality)应急处理 (contingency)安全 (security)成本和收费 (costs and charges),制定与控制IT预算对IT成本进行分类、核算、控制 服务的支付 IT财务报告,财务管理 Financial Management,财务管理,效益产生IT收入提高费效比(ROI)提高客户满意度改善投资决策提高IT规划的质量提高服务质量,主要活动计算预期的服务成本分析预计收入制定服务预算分析服务的使用情况和费用建议服务改进内容(关于成
17、本),财务管理流程定义IT的成本和收费分配结构，该分配结构支持服务预算以保证成本可以回收；该流程还包括按服务和按客户跟踪和控制实际成本，以及向获得了服务的客户收费。,计费并生成发票收款建立成本和收费分配结构跟踪和分析IT资产的财务状况计算总体拥有成本,35,June 12, 2018,成本要素分类,Invested in purchasing fixed assetsComputer equipmentSoftware packages( owned, not licensed )Buildings,Day-to-day costs of running IT servicesStaff co
18、stSoftware license feeElectricity, water, gasConsumables,Apportioned across multiple customersCost of operations staff,Directly attributed to a single Customer or group of CustomersExcessive usage of server by a single customer,vary with some factor, such as usage or timeOut-of-hours coverageEquipme
19、nt re-location,Fixed irrespective of resource usageCorporate software licenseServer maintenance contract,36,June 12, 2018,定价方法,决定因素：市场对服务的需求外部可用的选择法规、管理以及税等因素精确直接以及间接成本,能力管理 Capacity Management,业务能力管理 (BCM),服务能力管理 (SCM),资源能力管理 (RCM),重复活动,需求管理,建模,存储能力管理数据,CDB,制定能力计划,涵盖BCM、SCM、RCM的各个方面,平衡成本、性能，IT供应与需求
20、跟踪、监控IT基础设施的性能制定并持续改进性能计划,关键点,38,June 12, 2018,能力管理活动,监控Monitoring分析Analysis调整Tuning实施Implementation需求分析Demand Management应用大小Application Sizing建模Modeling制定能力计划Produce Capacity Plan确保以最有效和实时的方式提供目前和未来因业务成长所需要的IT容量.,IT 服务持续性管理 (ITSCM)业务持续性管理 (BCM)危机IT服务持续性规划是一套系统化的方法以创建计划、流程（需要定期更新和测试），以预防、处理和恢复关键服务。,
21、IT服务连续性管理IT Service Continuity Management,对IT基础设施进行风险分析与管理采取相应的对策减低危机的影响开发、维护并定期测试连续性计划重在预防,定义,目标,确保所需的IT技术和服务设施在规定时间内恢复,关键点,任务,保证,培训,阶段四 运作管理,IT服务连续性管理IT Service Continuity Management,不采取任何措施保险手动备份程序与具有相似设备的组织签署互惠协议安装灾难屏蔽装置; 屏蔽灾难逐渐恢复冷支持 72小时或更常时间恢复服务中期恢复暖支持 24小时内重建关键系统紧急恢复热支持 几分钟内恢复服务可用性使用内部/外部/固定的
22、/便携/可移动的中心,灾难备份措施的选择,可用性管理,效益确保使用了合适的基础设施提高服务的可用性指明IT的方向和重点提高费效比降低运行费用降低客户风险提高客户满意度,主要活动决定可靠性和适用性需求决定安全性需求提出关于应急计划的需求分析服务可用性的风险进行可用性差距分析提出购买或自己建立的建议(关于可用性)制定用于购买或自己建立的详细规范(关于可用性),可用性管理流程定义、跟踪、控制客户对IT服务的访问；该流程决定服务连续、应急、环境和数据安全等方面的计划和策略，同时管理供应商以确保对服务可用性。,建立与供应商之间的关系分析可用性实绩建议服务改进内容(关于可用性)评估供应商演习和评估应急计划
23、,可用性Availability可靠性Reliability可维护性Maintainability（内部）可服务性Serviceability（外部）安全性Security ( 保密性、完整性和可用性）,可用性管理 Availability Management,业务与客户满意度的核心分析与报告IT基础设施的性能提供数据给服务级别管理流程根据可用性计划产生变更请求改善IT基础设施性能从而降低风险,关键点,44,June 12, 2018,Incident Lifecycle - Expanded,Incident,Incident,Restore,MTBSI,MTTR,MTBF,MTTR -
24、Mean Time To Repair (Downtime)MTBF Mean Time Between Failures (Uptime)MTBSI Mean Time Between System Incidents (Reliability),Detect,Diagnose,Repair,Recovery,Detection Time,ResponseTime,FixTime,RecoveryTime,MTTR全称是Mean Time To Repair，即平均恢复时间。就是从出现故障到恢复中间的这段时间。MTTR越短表示易恢复性越好。 MTTR（时间/次）=总修复时间/故障次数MTBF
25、全称是Mean Time Between Failure，即平均失效间隔。就是从新的产品在规定的工作环境条件下开始工作到出现第一个故障的时间的平均值。MTBF越长表示可靠性越高正确工作能力越强 。 MTBF（时间/次）=总运行时间/总故障次数MTTF全称是Mean Time To Failure，即平均无故障时间。系统平均能够正常运行多长时间，才发生一次故障。系统的可靠性越高，平均无故障时间越长。可用性A(Availability)=MTBF/(MTBF+MTTR),术语,目标：IT环境可用性达到99.5%,客户/服务器应用结构,可用性,客户端应用软件,99.5%,服务器端软件,99.5%,个人电脑,99.5%,局域网LAN,99.5%,广域网WAN,99.5%,HP-UX 服务器,99.5%,数据库软件,99.5%,总可用性,96.552%,结果！,365x(1- 99.5%) =1.825天,365x(1-96.552%) =12.775天,
