ITIL-功能概念定义

1、服务台Service Desk,14,服务组织的一项职能、组织单元或一个部门 服务提供组织和用户之间的单一联络点（Single Point Of Contact，SPOC） 用户向服务组织报告事件和申请服务请求 服务组织向用户通知事件处理进度、活动等,服务台,15,用户的请求可以在第一时间找到合适的人，并及时得到处理进度的告知 用户可以得到一致的服务 合理地配置服务组织的人员结构，提高效率，降低成本 通过唯一的接入点及首次联系点，充当过滤器，并协调后续的所有流程 作为事件的一线支持，解放二线、三线专家,为什么需要服务台？,16,服务台的功能,提供一线的支持服务,协调二线和三线支持,及时通知客户

2、其请求的当前状态和最新进展,监控服务级别协议 SLA的执行情况,与客户确认后 关闭请求事件,提供系统 管理报告,接受、记录、分级和追踪客户服务请求,17,呼叫中心、帮助台与服务台,呼叫中心（Call Center） 组织中负责处理大规模基于电话交易的部门，如银行、保险等 帮助台（Help Desk） 管理、协调并尽快地解决IT服务运营中发生的意外事故需要确保客户的每个请求能够得以处理 经常使用配置管理及知识工具作为支持技术 服务台（Service Desk） 拓展了服务的范围，通过提供一个全球集中的服务联络点促进了组织业务流程与服务管理基础结构的集成 不仅处理事件、问题，而且提供其它活动的接口

3、，如：客户变更请求、维护合同、软件许可、服务级别管理、配置管理、可用性管理、财务管理及安全管理,18,服务台的主要活动,响应呼叫请求 事件：错误报告、服务请求、标准变更 变更 发布信息 联络供应商 运营管理任务 备份恢复、创建帐号、修改密码等 基础设施监控,19,选择合适的服务台结构,企业或者IT服务规模不断扩大的过程中，服务台结构经历的三个阶段 分布式服务台 集中式服务台 虚拟式服务台 IT组织要根据不同的需求，选择适合自己企业的服务台结构,20,服务台结构选择实践,技术考虑 系统工具的集成，或者所有的服务台共享一套系统 语音的路由 流程考虑 必须建立统一的管理流程，及专门的管理人员 实施考

4、虑： 集中的服务台记录用户的事件及请求 远程提供支持 远程无法解决，则派单至现场服务工程师,21,服务台人员,以客户为中心 发音清晰 有条理 良好的人际沟通能力 具有忍耐性（Tolerant） 能够理解业务目标 真诚地想成为第一级服务的提供者,事件管理Incident Management,23,被动任务，尽快（ASAP）将服务恢复成正常状态 将对业务的负面影响降至最低 确保服务质量和可用性满足SLA,目标,24,事件管理的范围,应用系统 服务不可用 应用bug 超出磁盘限额 硬件 系统Down机、自动告警、配置无法访问 服务请求 请求信息、建议、文档，忘记口令重设,25,基本概念,事件（In

5、cident） 任何不是服务的标准操作发生的、并且导致或可能导致服务质量的下降或中断的事件（Event） 临时措施（Work-Around） 消除事件或问题的方法 服务请求（Service Request） 用户想要获得支持、递送、信息、建议或文档的请求，它并不属于IT基础设施方面的故障 变更请求 (Request For Change, RFC) 新的或增加的服务请求,26,事件生流程,27,步骤1：识别与记录,输入 从服务台或事件管理系统发来的事件详细描述 动作 记录该事件的基本详细资料 需要的话向专家支持组报警 启动服务请求的处理流程 输出： 校正后的该事件详细资料 在配置管理数据库（C

6、MDB）中识别的任何错误 当该事件解决后，通知客户相关信息,28,步骤2：分类与初始支持,输入 记录的事件详细资料 来源于配置管理数据库（CMDB）的配置详细资料 动作 事件分类 与问题和已知错误匹配情况 通告问题管理流程存在不匹配的新问题或多次发生的事件,29,步骤2：分类与初始支持,动作（继续） 分配影响度/紧集度，并据此定义优先级 评估相关的配置细节 提供初步支持（评估事件细节，找出最快的解决方案） 关闭该事件或转给一个专家支持组，并通告用户 输出 该事件解决方案产生的变更请求（RFC） 修订该事件的详细资料，并临时解决此事件 或者将该事件转到2-3线支持,30,事件分类,用户对自己的事

7、件认识是主观的 优先级 对业务的影响度 业务需要解决的紧急度 种类 应用系统 硬件 软件 服务请求,31,优先级矩阵样例,影响度,紧急性,优先级 = 影响度 x 紧急性,32,步骤3：是否为服务请求,服务请求 用户想要获得支持、递送、信息、建议或文档的请求 它并不属于IT基础设施方面的故障 如：请求一份文档、修改口令等 相关处理 标准服务流程 尽量做到自助化处理,33,步骤4：调查和诊断,输入 修正后的事件详细资料 从配置管理数据库（CMDB）中获取的详细配置信息 动作 评估该事件的详细资料 收集和研究所有相关的信息和解决方案 包含任何临时解决方案，或转到下一线支持团队处理 输出 更进一步修订

8、的该事件详细资料，以及选择或需要的临时解决方案描述,34,事件升级,功能性升级（Functional Escalation） 将该事件从1线支持转移到2-3线支持团队称作“功能性升级”，这主要是由于缺乏经验或知识 等级性升级（Hierarchical Escalation） 在处理该事件的过程中，发现不能按时解决或客户满意度下降时，报告给更高级别管理层，这称作“等级性升级”,35,步骤5：解决与恢复,输入 修订的该事件详细资料 任何为有效解决该事件产生的变更请求（RFC）响应 任何得到的临时解决方法和解决方案 动作 采用的解决方案/临时解决方法，或上升为变更请求（RFC）来解决该事件 启动恢复

9、动作 输出 为未来该事件解决方案产生的变更请求（RFC） 已解决的事件，包括恢复细节描述 修正该事件的详细资料,36,步骤6：事件关闭,输入 修订后的该事件详细资料 解决后的该事件 动作 与客户或原始提供者确认该事件的解决 确定“关闭”类型 输出 修订后的该事件详细资料 关闭该事件记录,问题管理Problem Management,38,问题管理的目标,找出事件产生的根本原因 消除引起事件的深层次根源以防止事件再次发生 从而减少事件的发生 主动问题管理 被动问题管理,39,问题管理的效益,对实施组织带来的好处：可以极大地减少事件的数量和IT部门的工作量来提高服务质量 问题管理流程可以 识别IT

10、基础设施的故障，记录故障，并对这些故障进行跟踪直至其得到解决 记录故障的症状以及解决故障的临时性或永久性解决方案 提交变更请求以修复基础设施 防止事件发生,40,问题管理的范围,问题控制 错误控制 主动问题管理 提供信息,41,1：问题控制子流程 1.1 确认问题,面对蜂拥而至的事件? 我们把特征类似的事件分成组,然后再来确定这些组出现的问题. 在明确问题后,我们还要检查事件数据库,看看是否遗漏了某些事件.我们还要将这些事件添加到问题记录中.,42,1.2问题的归类和分配,首先进行影响度分析，即确定问题的严重程度及其对服务的影响程度 确定优先级，根据问题所处的类别分配人员和其它资源，并安排处理

11、问题的时间 归类涉及的方面 类别 影响度 紧急度 优先级 状态,43,1.3问题调查和诊断,目的在于查到潜在的原因 调查活动可以包括一个问题相关事件的临时解决方案 调查和诊断可以直接生成RFC或者转变为已知错误 注意权衡与事件管理之间的关系,44,1.4临时修复,问题导致严重事件，需要临时修复或紧急修复 临时修复需要对基础设施进行改动，必须首先提交变更请求 如果问题非常严重不容耽搁，必须启动紧急变更请求处理程序,45,2：错误控制子流程,46,3.主动问题管理子流程,趋势分析 一个平台上发生的问题可能发生在另一个平台上 同样的故障存在于不同地点 预防性动作 提出一个主动变更请求 提供有关测试、

12、生产、培训和文档的反馈 给服务支持员工和客户预先作培训和教育 改进处理流程,47,4.提供信息,提供管理信息 问题/错误控制报告 定期审计 分发信息 临时性解决方案、永久性解决方案或处理过程的完整信息应分发给报告该问题的人士，也需要分发给其他客户以供参考,变更管理Change Management,49,基本概念,变更Change：在维护过程中对系统或IT服务所作的任何改变，包括增加、修改、减少、移除和其它的修改 变更请求 (RFCs)：用于记录变更请求的电子或书面文档 变更顾问委员会 (CAB)：一组在实施变更时能够为变更管理提供专业意见的人 变更顾问委员会/应急委员会(CAB/EC)：针对

13、紧急变更需求进行相关决策 变更实施进度表（ The Forward Schedules of Change (FSC)）：主要为了控制变更的进度 实施后评审(PIR)：对已作变更的情况进行回顾，看其是否达到预期变更要求，并是否有回退方案,50,变更管理的范围,硬件 通信环境和软件 生产环境的应用软件 所有正使用系统中相关的运行、支持和维护之文档和程序,51,变更管理流程,52,1. 记录,所有接收到的变更请求（RFC）应该被登记和分配一个识别代码 RFC包括：标准变更、非标准变更 RFC来自：用户、问题管理、立法、供应商、计划、IT人员 变更请求（RFC）记录 标识码 关联的问题/已知错误编码

14、 相关配置项的描述和验证 调整和商业利益变更的原因 被变更的配置项当前的和新的版本 变更请求提交人的姓名、地点和联系方式,53,2. 优先级与分类,确定优先级 影响度（高、中、低） 紧急度（立即、高、中、低） 确定类别 次要影响：要求低，风险低。变更经理可定 实质影响：需要做大量工作，且对服务有切实影响。需变更顾问委员会来定，会议之前，传阅相关文档给CAB成员 重大的：需要做大量工作，且对组织重要部分有影响。需要有IT管理或IT筹备委员会的优先级授权。之后提交给CAB 紧急的：变更委员会授权应急委员会来处理,54,3. 变更构建,构建新的产品模块 创建新的软件版本 外购设备或服务 准备修改硬件

15、 制作新文档或修改补充 准备回退方案 准备改正后的内容给用户培训,55,4. 变更测试,性能 安全性 可维护性 可支持性 可用性/可靠性 功能性 回退方案,56,5. 实施后评审（PIR）,该变更已有期望的结果，并且与目标吻合 用户与客户满足变更结果，或者确定任何错误 在功能性、可用性、能力/性能、安全、可维护性等方面没有意外的或不合需要的事情发生 执行变更所用的资源是有计划的 执行计划工作正确 变更按时/按预算执行 回退计划功能正确性,57,6. 变更管理报告,变更请求关闭 变更成果归档 出具变更管理报告,发布管理Release Management,59,设计和监督以确保软件及其相关硬件的

16、首次运行能够成功进行 设计和实施有效的过程来发布和安装IT系统的变更 确保硬件和软件的变更是可追踪的、安全的，并且只有正确的、被授权的和经过测试的版本才能安装 在新版本的规划和首次运行过程中，沟通并管理客户的期望值； 联合变更管理，确定发布的确切内容和首次发布计划 利用配置管理和变更管理中的控制流程，在实际运营环境中实施软件和硬件的新发布；一个发布应在变更管理之后，并由任何硬件、软件、固件和文档配置项联合组成 确保所有最终软件库（DSL）中软件正本的拷贝是安全可靠的、并且在配置管理数据库中得到了更新； 通过配置管理服务，确保所有的硬件均已得到发布，或所有的变更是安全的和可追踪的,目标,60,发

17、布管理的概念,发布是指经过测试并导入实际应用环境的新增或改进的配置项的集合。 发布管理负责计划与实施IT 服务的变更，并描述变更的各个方面。 其主要目标是通过正规的实施变更流程及测试，确保应用系统的质量。,61,发布单元、识别和类型,发布单元 发布单元是指一起发布的一组IT基础构架组件. 发布识别 唯一性识别 配置项用版本号作为参考 发布类型 全发布Full Release 德尔塔发布Delta Release 包发布Package Release,62,发布管理的主要类型,重大发布 （major release） 重要的或众多功能扩展升级的发布 小型发布（minor release） 针对某

18、个特性的功能扩展的发布 紧急修复（emergency release） 只完成个别漏洞或故障修复的补丁发布,63,相关存储,最终软件库（Definitive Software Library，DSL） 最终硬件库（Definitive Hardware Store，DHS） 配置管理数据库（CMDB）,64,发布管理的主要活动,65,1. 制定发布策略,由可定义的发布所控制的IT基础架构的级别 发布的命名和编号规则 有关重大发布（major release）和小型发布（minor release）的具体定义，以及有关签发紧急修复的政策 确定重大发布和小型发布的频率 重大业务灾难时期阻止执行，以

19、能够管理相关发布,对每个类型的发布都能按期望实施 产品策略及对回退（back-out）计划进行测试的程度 有关发布管理控制流程的描述（如评审会、进度评估、升级、影响分析） DSL中配置的文档记录，以及新增软件验收标准的定义,66,2. 发布计划,争取各方在发布内容上达成一致意见 在发布时间和地理位置上达成一致意见 制定一个高级别的发布日程表 执行现场调查以评价现有的软件和硬件 规划资源级别,在角色和责任上达成一致意见 获得供应商有关新硬件、软件和安装服务的详细报价和谈判结果 制定回退计划（back-out plan） 为发布制定一个开发计划,67,3. 发布的设计、构建和配置,输入 发布定义

20、发布规划 输出 详细的发布集合和构建指令，包括精确的操作顺序 购买定单，第三方硬/软件的许可证和保修期 自动安装程序和相关的测试规划 存储到最终软件库（DSL）中的安装介质和手册主要拷贝 回退规划,68,4-6. 发布测试和验收,发布测试应由独立的业务人员和IT人员来执行。 所有的撤销计划都应作为此活动的一部分进行测试 发布验收应在一个可控的测试环境中执行，这个可控环境还要求能够恢复到已知的软硬件配置 如果该发布被否决，则应通过变更管理重新规划,69,7. 首次运行规划,制作确切、详细的时间安排表，以及说明谁将做什么 列明需要安装和卸载的配置项（CI），同时指出处置冗余设备和软件的方法 按执行

21、地点作出行动计划文档，不要在不同时区执行时影响整个计划 制作发布备忘录并和最终用户进行沟通和交流 制作沟通计、采购计划 进行新旧系统并行处理 计划管理层员工和与该发布相关的会议,70,8. 沟通及培训,输入 详细的发布定义和首次安装计划 安装介质和手册的拷贝 当前支持、培训和用户文档的版本 验收的表格 输出 拥护和支持培训材料和文档的最终版本 修订后的发布计划和文档,71,9. 分发及安装,输入 详细的首次安装规划 测试过的安装程序 测试过的发布组件 测试过的撤销程序 输出 修定的IT服务，以及用户和支持文档 修定配置管理数据库（CMDB）记录来反映新的运营组件 退役的配置项（CI） 任何在正

22、运行系统中已知的错误将作为新发布一部分,配置管理Configuration Management,73,目标 通过维护IT基础设施和IT服务的逻辑模式来协助管理IT服务的经济价值，并将此相关的信息提供给其他业务流程 维护与IT组件及运用这些组件提供的IT服务有关的记录并确保这些记录的可靠性 提供准确的信息和文档以支持其它服务管理流程 范围 配置管理覆盖IT组件（包括它们的版本、主要组件和它们之间的关系）的鉴定、记录和报告 包括硬件、软件和相关文档的配置项应该在配置管理的控制下,目标与范围,74,基本概念,配置管理数据库Configuration Management Database(CMDB

23、) 配置项Configuration item(CI) 配置基线Configuration Baseline,75,配置管理数据库,配置管理数据库 Configuration Management Database CMDB是一个数据集合，存储所有配置管理的数据和信息，包括： 配置元素（CI），如硬件，软件，文档，人员，其他信息等。 配置元素属性，如名称，类别 配置元素关系，如连接，父子等 配置元素状态，如维护中，生产中等 其他服务信息，如事件，问题，已知问题，变更请求等,76,配置项,所有必须被管理（必须记录在案，必须跟踪，必须控制）的对象。 包括硬件，软件，文档资料，合同，IT组织机构，及

24、相关的事件记录，问题记录，变更记录等。 一个配置项可以被分解成任意数量的子配置项。 配置项可以组合起来形成配置项集合。,77,活动步骤1：配置管理规划,目标和范围 与支持小组相关的政策、标准和流程 配置管理的角色和职责 配置项命名规则 实施配置管理活动的日程安排和程序 第三方接口控制（如变更管理、供应商等） 配置管理系统的设计 配置管理的内务工作（许可控制、配置项存档等） 计划的配置基准线（系统建立的时间点）、重大发布等等,78,活动步骤2：配置标识,配置项CIs 范围, 配置项级别 和属性 数据搜集和记录 标注和命名规范 控制级别/基线 结构 CI之间的关系 父/子,79,活动步骤3：配置项

25、的控制,注册新的配置项和版本 更新配置项记录 更新与配置项（CI）、状态和执行情况有关的变更请求（RFC） 当CI被撤销或删除时，将相关记录更新、归档 保护配置项的完整性 定期检查与配置管理数据库（CMDB）记载不同的现有物理项后，更新配置项，以确保它具有可用的精确信息,80,活动步骤4：配置状态报告,CI唯一的标识符及其状态 配置基线，发布及其状态 有关系统基线/应用系统的最新软件版本及其状态 状态变更的负责人 变更历史/审计跟踪 开放的问题/变更请求,81,活动步骤5：配置验证和审核,实施新的配置管理系统后 对IT基础架构实施重大变更前后 在一项软件发布和安装被导入实际运作环境之前 灾难恢

26、复之后或事件恢复正常之后 在正常/随机时间间隔 发现未经授权的配置项后,82,活动步骤6：提供配置管理服务,配置管理数据库（CMDB）备份、归档和内务管理 正常的信息和将此配置管理设置内容通告给新成员 配置管理的政策、流程、角色和职责 有效的捕获、维护和删除记录 利用标准流程修正配置列表和信息 库服务管理的方式来控制文档或软件的复制件 许可证管理 配置审计服务,83,活动步骤7：管理报告,配置审计的结果 任何未注册的信息，或者已经被确定为不正确的配置项注册和修正活动 注册的配置项数量信息，以及分层为配置项（CI）种类、类型和状态的配置项版本 成长和容量信息 配置管理员工职位 由其它IT员工完成

27、的被授权工作数量 配置项（CI）分类数据和分析 配置项（CI）的价值 以业务单位、支持组和服务分类的配置项（CI）位置,服务级别管理Service Level Management,85,服务级别管理（SLM）是IT服务提供者根据与IT服务客户之间签订的完全量化的服务级别协议（SLA），实现对IT服务质量的规划、定义、监控和变更的管理。 量化管理 管理客户的期望值 规划服务资源 提升内部IT服务形象 更好地控制成本 建立IT的“防守策略” 平衡IT服务需求和IT服务提供之间的关系,服务级别管理目标,86,服务级别管理的范围,服务级别协议（SLA）应为所有提供的IT服务制定 支持合同（UC）和运

28、营级别协议（OLA）也应适当与供应商结合,87,服务目录、服务级别协议,Helpdesk（IT响应中心）服务 服务描述：为最终用户提供单一的电话响应接口，在线解决用户问题，协调其他服务提供者，记录和汇报相关问题。 服务时间：85，24 7可选 服务质量： 响应时间：15秒， 30秒，电话接听可选 话务丢失率：5%，8%，10%可选 问题在线解决率：60%，70%，80可选 汇报时间：周报，月报可选 服务成本：从US$5/人月到US$50/人月不等,88,1. 流程规划,初始计划活动 计划监控性能 建立初步的服务 支持合同UC和运营级别协议OLA,89,2. 流程实施,制作服务目录 实施客户期望

29、管理 规划SLA结构 确定SLR及草拟SLA 制定SLA 与客户进行协商 建立监测能力 评审UC和OLA 定义报告和评审程序 发布SLA,90,3. 流程运营监控,监测和报告 服务评审会 服务改进计划 SLA/UC/OLA的维护,91,4. 定期回顾,对服务级别协议（SLA）、支持合同（UC）和运营级别协议（OLA）进行回顾 对服务级别管理流程（SLM）进行回顾,IT服务财务管理 Financial Management of IT Services,93,目的与范围,目的 对支持服务运营的IT资产和资源进行成本交易管理 完整计算IT服务的花费，以及按照向组织客户提供的服务项目进行分摊 为管理

30、层提供IT投资决策所需的业务变更到IT服务案例详细资料 范围 与财务部类似，IT 财务管理包括预算、IT核算和计费,94,步骤1. 预算（Budgeting）,概述 目标是要规划和控制组织的活动，公司的战略规划涉及到一个企业的长期目标；预算为这些目标确定了预算期内的财务计划 预算方法 增量预算，零基预算 预算流程 销售和营销预算、生产预算、管理费用预算、成本和投资预算 预算期 财务年度，长期预算等,95,步骤2. IT核算（Accounting）,核算提供IT服务中支出的金钱 计算对内部和外部客户提供IT服务的成本 履行成本-收益，或者投资回报分析 确定变更的成本,96,步骤3. IT计费（C

31、harging）,覆盖所有提供给客户的服务成本 需要的话，将IT组织向一个业务部门那样运营 影响用户和客户行为 确定收费政策、可收费的项目、报价、开帐单等等,容量管理Capacity Management,98,目标,确定正确的、成本合适的IT资源能力，以保证在正确的时间点满足SLA的要求 两个平衡: 成本与容量 供给与需求,99,容量管理范围,所有硬件：从PC机，到文件服务器，以及服务器等 所有的网络设备：局域网，广域网，网桥，路由器等 所有的外围设备：大容量存储设备、打印机等 所有的软件：操作系统和网络软件，自主开发或购买的软件包等 人力资源：由于缺乏人手而导致拖延了端对端响应时间的情况,

32、100,容量管理流程,技术 SLA, SLR及服务目录 业务计划及战略 业务需求及容量 运营计划 发布及开发计划和程序 变更执行计划 事件及问题 服务回顾 SLA违背情况 财务计划 预算,业务容量管理 (BCM) 趋势、预测、模型、原型、规模估计及记录未来业务需求 服务容量管理 (SCM) 监控、分析、调整及报告服务性能，建立服务基线，管理服务需求 资源容量管理 (RCM) 监控、分析、运行及报告组建使用，建立基线和组件使用的描述文件,容量计划 CDB 基线及描述文件 限额及告警 能力报告 SLA & SLR建议 主动变更及服务改进 修正的运营计划 有效性回顾 审计报告,输入,输出,101,容

33、量管理的3个流程/7个活动,102,步骤1. 重复性活动,103,步骤2. 需求管理,目标 控制和影响客户对容量的需求 需求管理为制定、监控和在可能情况下调整能力计划和服务级别协议提供了信息来源 短期需求管理：当IT基础架构中的关键资源出现局部工作不正常时，便需要做短期的需求监督调节。 长期需求管理：当升级费用太高难以做到合理花费时，就可能需要进行长期需求监督调节。,104,步骤3. 模拟,在给定的业务量和各种各样的操作下，对系统的性能进行预测 趋势分析Trend Analysis 分析性模拟Analytical Modelling 仿真模拟Simulation Modelling 基线模拟B

34、aseline Modelling,105,步骤4. 应用选型,对计划性应用系统变更或实施新的应用系统所需资源进行估计，以确保资源的配置能够满足作序服务级别的要求 在初始系统分析和设计阶段就必须确定所需的服务级别 应用选型需要考虑的另一个因素是新建应用系统的弹性,IT服务持续性管理IT Service Continuity Management,107,目标,通过确保在灾难发生之后IT基础设施和IT服务能够在规定的时间内得以恢复，从而支持总体的业务持续管理（BCM） 持续性目标必须基于业务目标而确定 在评估业务持续性所面临的风险时，需要确定这些风险是否处于IT服务持续性管理流程的范围之内,10

35、8,ITSCM范围,IT服务持续性管理聚焦于IT服务需求，从而支持关键的业务流程 IT服务持续性管理（ITSCM）的范围应根据组织结构、文化和战略方向（包括业务和技术），并结合所提供的IT服务以及如何随时间对这些服务进行开发和变更等多方面因素来确定,109,连续性管理的流程,110,步骤1 - 启动,制定策略 定义ITSCM范围及相关领域 分配资源 定义项目组织和控制架构 同意项目和质量计划,111,步骤2 - 需求和战略,业务影响分析（BIA） 风险评估 业务持续性策略,112,步骤3 - 实施,设立组织和开发实施计划 实施备用方案 实施风险降低措施 开发IT恢复计划 开发实施程序 进行初始

36、测试,113,步骤4 - 运营管理,教育和宣传 培训 回顾 演习 变更控制 保证,可用性管理Availability Management,115,目标,提供符合预订可用性级别且成本合理的IT服务，帮助企业实现其业务目标 提供解决方案，以平衡IT部门的可用性提供与客户对可用性的需求 确保可用性级别可以评价和计量，并在必要时进行持续改进,116,范围,所有新增的IT服务，以及已签订服务级别需求（SLR）或服务级别协议（SLA）的IT服务 不一定签订正式的服务级别协议（SLA），但对业务却是极为关键的IT服务 SLA中作为支持IT部门的内部和外部供应商 可能影响可用性的IT基础架构和IT支持部门，包括培