ITIL Foundation Series （2）事件管理、问题管理.ppt

ITIL Foundation Series（2）事件管理、问题管理,ITIL服务支持与服务管理职能与流程,服务支持服务台（职能）事件管理问题管理变更管理配置管理发布管理,服务提供服务级别管理可用性管理IT服务财务管理能力管理IT服务持续性管理,涉及客户和用户如何获得恰当的服务来支持他们的活动和业务,涉及客户需要用来支持其业务运作的服务以及为提供这些服务所需要的资源,ITIL框架（2.0）,业务,技术,IT服务管理的实施规划,业务管理,IT基础架构管理,应用管理,服务管理,服务提供,服务支持,安全管理,Service Support流程,事件 问题和已知错误 变更 发布 配置项关系CMDB,管理工具,事件,事件管理,问题管理,变更管理,发布管理,配置管理,事件,服务台,事件调查报告,事件请求、需求,沟通、更新和权益措施,业务客户用户,变更,发布,Service Delivery流程,可用性管理,服务级别管理,需求、目标和绩效,业务客户用户,警告和期望调整,管理工具和IT基础架构,IT服务持续性管理,能力管理,IT服务财务管理,沟通、更新和报告,请求、需求,事件管理Incident management,启示,治标、治本是个问题？,概述基本概念主要活动关键角色与其他流程之间的关系成本效益及可能的问题分析关键成功因素和绩效指标总结,议题,概述,定义-事件管理是负责记录、归类和安排专家处理事件，并监督整个处理过程直至 事件得到解决和终止的流程。目标-在给用户和公司正常的业务活动带来最小影响的情况下，尽快地恢复到SLA 中定义的正常服务级别。-保留事件的有效记录以便能够权衡并改进处理流程，给其他的服务管理流 程提供合适的信息，以及正确报告进展情况。,理解要点：事件管理是一个被动性的任务，也就是减少或消除存在或可能存在与IT服务中干扰因素给IT服务带来的影响，以确保用户可以尽快的恢复自己的正常工作。对于业务而言，更及时地解决事故可减少对业务的影响；提供用户的工作效率；独立的面向用户的事件监控；基于SLA的业务管理信息的可用性；对于IT部门来讲，改善监控，对于SLA的执行情况可以进行更为准确的评测；更好地有效的使用人力；避免事件和服务请求的丢失或不正确的记录；更准确的配置管理数据库（CMDB）；提高用户和客户的满意度；,基本概念（1）事件/服务请求/变更请求,事件（incident）-在某一服务中不属于标准操作的，并可能导致或可能导致这个服务的中断或服务质量下降的任何事件；-不仅包括软、硬渐渐的错误，还包括服务请求。基本上包括服务台接收到的所有呼叫只要可记录和可监控的；服务请求（service request）-用户想要获得有关的支持、提供、信息、建议或文挡而提出的请求，它不属于IT基础架构方面的故障；-一个服务请求可能是要求进行一个标准变更，但是只要它属于“标准服务”的范畴，那么就应当由事件管理而不是变更请求流程进行处理；标准服务是根据服务级别协议（SLA）提供的，是根据既定的程序进行，而这些程序是经过协商的，并且具有适当的检查和控制功能；-例如：状态查询；口令重置；功能方面的问题或请求；要求提供具有一定IT技能或服务的新雇员的请求；对批处理活动、恢复以及口令认证的请求；变更请求（request for change，RFC）-变更请求如果被请求的服务不是事先已经定义好的“标准服务”，并且它将改变IT基础设施的状态，那么我们将据此提交一个变更请求；-变更管理流程的正式组成部分，用于记录在一个基础架构内对任何配置项或服务、程序以及与基础架构相关的项目进行变更的需求的详细情况；,基本概念（2）影响度/紧急度/优先级,影响度-影响度指所影响的用户或业务数量而言，事件偏离正常服务级的程度；-重要事故是指哪些对用户带来非常严重影响的事件，而有些在时间上极度紧迫的事件，也应当作为重要事件来处理；紧急度-解决故障时，对用户或业务来说可接受的耽误时间；优先级-决定处理事件和问题的先后顺序；-根据事件对用户和正常业务带来的影响的严重程度来决定。由服务台与用户进行协商，根据SLA确定事件优先级，当事件提升到二线/三线时，其优先级的维护及调整仍是在与服务台进行协商后确定；,受影响的用户数；受影响的系统数；用户要求；服务级别协议；错误的严重性；,影响度,紧急度,优先级,评估：人力；资源；时间；,优先级=影响度X紧急度X职务（？）,优先级,解决时间,影响度,紧急度,高,中,低,高,中,低,紧急,1h,高,高,中,中,中,低,低,计划中,8h,24h,8h,24h,48h,24h,48h,已有计划,事件的影响度和紧急度在生命周期中有可能变化,基本概念（3）升级,定义-如果某个事件不能在规定的时间内由一线支持小组解决，那么更多的有经验的人员或有更高权限的人员将不得不参与进来，这就是升级。它可能发生在事件解决过程的任何时间和任何支持级别；职能性升级（Functional Escalaton，水平升级）-需要具有更多时间、专业技能或接入特权（技术机构）的人员来参与事件的解决。-这种升级可能会超越部门界限而且可能会包含外部支持者；结构性升级（垂直升级）-当经授权的当前级别的机构不足以保证事件能够及时、满意的得到解决时，需要更高级别的机构参与进来解决；-例子：服务台-服务台主管-问题管理经理-服务经理/客户经理-IT总监/第三方总监-一般情况应优先使用职能性升级，只有当在某些事件不能得到及时解决时才考虑使用结构性升级；-如果是后一种方式，最好尽可能早于SLA规定的时间开始有关行动，比如外聘专家；-事件管理经理对于事件管理流程负有全部责任，他的目标是为了满足一个事件的职能性升级的需要做好预备工作，以避免结构性升级的发生；,基本概念（4）一线/二线/三线/N线支持,一线支持（也称第1排支持人员）通常由服务台提供二线支持则由管理部门提供；三线的支持由软件开发人员和系统结构人员提供；四线的支持由供应商提供事件管理经理可在相关部门指定的故障协调人来支持自己的工作。协调人在整个事件管理过程中处于各线的支持机构之间充当接口的角色，每个协调人协调他本身所在的支持团队。,主要活动,接收和记录归类和初步支持匹配调查和诊断解决与恢复终止跟踪与监控,负责解决事件并跟 踪、监督、控制和协调解决过程,事件检测、接收和记录,初步归类和支持,事件调查和分析,解决事件而后恢复服务,终止事件,处理服务请求,服务请求,1、避免无人负责监控和升级事件；2、避免专业人员经常面对用户；3、避免与用户和服务相关的关系信息缺乏,输入：事件详细来源于服务台配置管理数据库中配置项信息已知错误和解决方案于问题和已知错误匹配的事件响应,输出：已知错误变更请求更新规避措施或解决答案记录客户沟通管理信息提交,主要活动,WHY记录？已有的事件记录可帮助对新发生的事件进行诊断；问题管理可通过对事件的记录来发现问题的原因；如果所有的来电呼叫都被记录下来，那么对于某一事件的影响度的判断会容易一些；如果没有事件记录，那么将不能监控经过协商服务级别是否得到履行；避免在解决问题时出现几个人同时解决同样的问题，或在对某一事件的处理过程中什么工作都没有做等情形；WHO报告？由某一用户发现；由系统发现；由某一服务台员发现；由另一IT 部门的人发现；,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,主要活动,记录WHAT？事件编号（唯一的）；事件类别；记录事件的时间和日期；事件记录人（或组）的姓名（或ID）；有关用户的姓名、部门、电话和工作地点；回复用户的方式（如电话、电子邮件等）；时间症状描述；HOW记录？分配一个时间索引序号-大多数情况下系统自动分配一个唯一的时间索引序号。通常，在后续沟通过程中用户可使用通过提供的查询序号来查看事件状态；记录基本的诊断信息；-时间、症状、用户、处理问题的人、地点、以及受影响的服务或硬件等信息；附加事件信息-包括与事件相关的其他信息（例如一个脚本或交谈程序记录）或配置管理数据库中的一些信息（通常以数据库中定义的关系为基础）；警告-如果存在一个具有高影响度的事件，例如某一个重要服务器的瘫痪，则应警告其他用户和管理部门；,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,主要活动,类别：与中央处理过程相关：包括介入、系统、应用等故障；与网络相关：包括路由器、整流片、集线器、IP地址等故障；与工作站相关，包括显示器、网卡、磁盘驱动器、键盘等故障；同样功能和使用相关：服务、能力、可用性、备份、手册等相关故障；与组织和过程相关：与命令、请求、支持、沟通等相关；与服务请求相关：用户对服务台提出的请求，要求提供支持、交付、信息、建议或文档等，这可能会备一个单独的过程所覆盖，也可能会按其他时间一样的方法进行处理；优先级=影响度X紧急度服务,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,事件警告,事件查明和记录,调查CMDB,定义优先级,初步评价事件,安排特定支持小组,请求？,服务台能解决的事件？,解决事件,终止事件,事件调查和分析,处理服务请求,是,否,是,否,根据事件的类型状态、影响度、紧急度、优先级、SLA等进行分类，并向用户提供建议来解决处理问题,主要活动,支持小组如果服务台不能再预先确定的时间范围内解决时间，决定应该由那个支持小组来负责处理该事件；时间表以优先级和SLA 为基础，受影响的用户将会被通知预计解决问题的最长时间（一个周期时间）。以及什么时候进行进一步的升级。事件索引号工作流状态 新建：已接受己计划：已分配活跃状态：已暂停已解决：已终止,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,事件警告,事件查明和记录,调查CMDB,定义优先级,初步评价事件,安排特定支持小组,请求？,服务台能解决的事件？,解决事件,终止事件,事件调查和分析,处理服务请求,是,否,是,否,归纳和初步支持,事 件 故 障 单,事件说明,事件症状,系统,组件,项目,严重等级,请求者信息,步骤,解决方案,事件来源,事件ID,事件处理人员,事件类型,状态,等待原因,关闭代码,事件产生日期,请求者提交的事件故障单,附件,用户号,登陆名,24小时电话,提交者,主要活动,对于事件进行分类之后，要检查以前是否发生过类似的事件。如果发生过，则查看是否存在解决方法和应急措施。如果新事件与某一问题或某一已知错误具有相同症状，那么可将事件指向这些已知的问题或错误。,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,新的突发事件,问题,已知错误/规避措施,是否是新的突发事件？突发事件是否与已有的问题相关？是否存在已知的规避措施？,搜索知识库,主要活动,服务台将那些没有快速解决方法或超过他们专业水平的事件安排给具有更高专业水平和技术能力的支持群体；支持小组将对事件进行调查并尽快加以解决，如不能解决，则将其转交给其他的支持小组；,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,安排支持人员,收集基本信息,查询历史数据,将事件处理责任反馈给服务台,终止事件调查,请求？,CMDB,事件、问题和知名错误数据库,搜索调查数据,事件,否,是,主要活动,成功完成对事件的分析解决之后，负责解决问题的支持小组应在系统中记录故障的解决方法；对某些解决方法来说，必须要向变更管理发送一个变更请求（Request For Change，RFC）最糟糕的情况是，如果没有找到解决事件的方法，那么事件依然保持开发（Open）状态；,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,主要活动,一旦解决方法执行完毕，支持小组要把事件处理情况反馈给服务台；服务台应联系事件的报告人以确认问题的确已经得到解决；如果服务台可以确定问题已经得到很好解决，那么事件就可以关闭（Close）了，否则需要在适当的地方重新开始处理流程；在事件关闭的过程中，必须要对事件的记录进行更新以指明对事件最终的分类和优先级，受影响的服务、用户、客户以及导致事件发生的配置项（CI）等；,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,主要活动,作为所有事件的拥有者，服务台负责对事件的发展情况进行监控以及通知用户有关事件的状态；用户在某一状态变更后可能作出适当的反馈，如在预期的事件周期内发生的进一步的事件移交安排或变更等；在对事件进展进行跟踪和监控时，可能需要将事件进行职能性升级，转交给其他支持小组来处理，或进行结构性升级，以加强处理事件的力度；,接收记录,归类和初步支持,匹配,调查诊断,解决恢复,终止,跟踪监控,关键角色,事件经理 对以下事情负责：监控事件处理流程的效果和效率；控制支持小组的工作；为改进工作提供建议；开发维护事件管理系统；支持小组人员 一线支持小组负责记录、分类、匹配、转交、解决（除指派给其他支持小组之外的）和终止事件；其他的支持小组主要参与调查、诊断和恢复工作，这和对事件设定的优先级有关；,在很多公司，事件经理就是服务台经理,与其他流程之间的关系概述,服务台,计算机操作,网络,规程,其他事件源,服务请求,配置管理数据库,问题管理,事件管理流程,监控和记录分类和一线支持匹配调查和诊断解决和恢复事件终止事件的所有权、监控 跟踪和沟通,配置细节,转交和监控,事件信息,应急措施,变更管理,变更请求,解决方案,可用性管理,报告,能力管理,报告,服务级别管理,报告,SLA参数,输入：事故输出：解决方案应急措施,事件可能由基础架构的任何部分引起，通常由用户报告。也可能由组织的其他部门发现或监控系统自动跟踪应用事件和基础架构事件,管理信息,已知错误数据库,与其他流程之间的关系,事件管理与配置管理配置管理显示基础架构的某一部分由谁来负责，这样当与这一部分相关的事件发生时可以迅速地进行追踪；CMDB还有助于决定合适的应急措施，如转移打印队列，将用户转移到另一个服务器等；在进行事件注册时，配置的详细信息也被连接到了事件记录以提供更好的相关错误信息；,事件管理与问题管理问题管理需要了解事件记录以便查出任何潜在错误问题管理通过提供与特定问题相关的信息、已知错误、应急措施以及当前修补方法等来给事件管理提供帮助；,事件管理与变更管理可通过实施变更来解决事件，如更换监视器等，变更管理为事件管理提供关于预定变更及其状态的信息；不正确的变更实施或者包含错误的变更可能引发事件，此时，事件管理也可以为变更管理提供关于这类事件的信息；,事件管理与服务级别管理服务级别管理监控与用户就是提供的服务支持达成的协议。事件管理必须熟悉服务级别协议（SLA），以便在与用户进行沟通时可用到这些信息。事件记录可以用来生成报告来判断是否真正地提供了规定级别的服务；,事件管理与可用性管理可用性管理需要使用由配置管理提供的事件记录和状态监控；,事件管理与能力管理能力管理关注与其职能相关的事件，如由缺少磁盘空间或响应时间过长导致的事件，业务经理、系统经理或系统本身可将这些事件通报事件管理系统；,成本效益分析和可能的问题,成本初始执行成本（如对流程和过程的定义以及相互间的沟通）；培训和指导人员成本（客户和支持人员）；选择和购买支持流程的工具等；与人事和工具使用相关的成本；可能的问题用户和IT人员故意避开事件管理程序；事件处理超载和堆积；过多的升级可能会打乱专业技术人员的正常工作而产生负面影响；缺乏清楚的定义和协议，如果支持的服务和产品以及支持的级别没有定义或没有符合SLA 或OLA或支持合同，事件管理很难达到客户和用户的期望的要求；缺少奉献精神，用基于流程的方法解决事件，需要管理和工作人员具有很高的奉献精神；,与事件管理结构、活动范围和责任以及流程有关的场地数量等有关,关键成功因素和绩效指标,成功的事件管理需要：及时更新的CMDB来帮助估计事件的影响度和紧急度；知识库（例如一个最新的问题数据库或已知错误数据库）帮助识别事件，以及有什么解决方法和应急措施可以使用；适当的自动系统用于记录、跟踪以及监控事件；与服务级别管理间的紧密联系以确保适当的优先级和解决时间；事件管理流程的关键绩效指标：事件的总数；平均解决时间；每个事件的平均支持成本；在SLA的目标之内解决的事件所占的百分比；不需要拜访用户就解决的事件数；每个服务台工作站或每个服务台员工平均解决的事件数；由一线支持解决（不将事件转交）的事件所占的百分比；初步分类正确的事件数量（或所占的比例）；正确转交的事件数量（或所占的比例）；按照优先级计算的平均解决时间；,1、指标可测量；2、由事件经理定期（每周）报告，以获得一些可据此判断事件发展趋势的历史数据；,问题管理Problem Management,议程,概述基本概念主要活动关键角色与其他流程之间的关系成本、效益和问题关键成功因素和绩效指标总结,概述,定义通过调查和分析IT基础架构的薄弱环节、查明事件产生的潜在原因，并制定解决事件的方案和防止事件再次发生的措施，将由于问题和事件对于业务产生的负面影响减少到最低的服务管理流程；目标将由IT基础架构中错误引起的事件和问题对业务的影响减少到最低程度；查明事件或问题产生的根本原因，制定解决方案和防止事件再次发生的预防措施；实施主动问题管理，在事件发生之前发现和解决可能导致事件产生的问题；,理解要点：1、通过结构化、系统化的问题管理方法，查明事件发生的潜在原因，并找到解决此事件的方法或防止其再次发生的措施。2、,事件（incident）,问题（problem）,已知错误（known errors）,RFC,根本原因未知的一个或多个事件,成功诊断除问题根本原因后的状态,导致服务中断或质量下降，不属于标准服务,基本概念（1）：问题/已知错误/变更请求,如果出现了一个已知错误，则应当提出一个变更请求，但是，在通过一项变更将此已知错误永久性地修复之前，它仍将作为一个已知错误。,变更请求说明了变更的内容及与变更有关的配置项。根据请求，变更管理小组和用户及其他有关人员对变更实施结果进行评价并计划进一步的变更,基本概念（2）：事件管理/问题管理/应急措施,事件管理/问题管理问题管理的主要目的是查明事件发生的潜在原因并找到解决此事件的方法或防止其再次发生的措施；事件管理的主要目标是在事件发生后尽可能快地恢复客户服务，即使采用的是一些应急措施而不是永久性的解决方案；事件管理强调速度，问题管理强调质量，把速度放在第二位；为了发现事件原因和防止事件再次发生，问题管理可能需要花费更多的时间解决事件且可能推迟恢复服务；应急措施解决某个时间的替代方案，这种方案可在限定的时间内产生一个可接受的结果,问题,已知错误,变更,错误数据,问题数据,事件,事件数据库,事件管理,问题管理,变更管理,记录,匹配信息,问题控制,错误控制,解决方法,变更请求,应急措施和临时修复,应急措施和临时修复,匹配信息,问题记录,错误记录,调查诊断,趋势/频率/影响,基本概念（3）：问题控制/错误控制,问题控制 问题控制是问题管理流程的第一项活动。问题控制负责找出问题并调查其根源，其目标是通过确定问题根源并采取应急措施来把问题转化成已知错误；错误控制 错误控制指监控和管理已知错误直到其尽可能地得到适当的处理。为此，它需要向变更管理提交变更请求（RFC），并在实施变更后对变更进行实施后评审以评估其效果；,基本概念（4）：实施后评审（）,实施后评审（）用户解决问题、已知错误及相关事件的变更一旦实施后，在终止有关记录工作之前必须对变更进行实施后评审（Post-Implementation Review,PIR）。如果变更成功实施，那么对所有问题和已知错误及相关事件的记录工作都可以终止了。许多公司进行实施后评审是为了确保与问题相关的所有事件终止（包括确认客户是否同意终止事件）之后才能终止此问题。如果与其相关的所有事件没有全部终止，则需将该问题重新置为“未解决”状态,主要活动,问题控制-建立已知错误错误控制-关闭已知错误主动问题管理-化被动为主动,主要活动,如何确定问题？举例对某一事件进行分析表明该事件可能再次发生，或者有大量发生并且加重的趋势；对于基础架构进行分析可以找处可能会产生事件的薄弱环节（也可由可用性管理和能力管理来进行分析）；服务级别可能会受到威胁（能力、性能、成本等）；记录下来的事件不能与一个现有的问题或已知错误发生关联；,问题控制,错误控制,主动问题管理,发现和记录,归类和分配,调查和分析,临时修复措施,错误控制,跟踪和监督,问题数据库,鱼骨图法；头脑风暴法；流程图法；Kepner&Tregoe法；,主要活动,如何分类？范畴：确定问题的相关领域，如是硬件还是软件问题；影响度：主要指对业务流程的影响；紧急度：也包含多长时间的延期可以接受；优先级：紧急度、影响度、风险和所需资源的结合；状态：如问题、已知错误、已接、已关闭但正在进行事实后评审等；,问题控制,错误控制,主动问题管理,发现和记录,归类和分配,调查和分析,临时修复措施,错误控制,处理服务请求,问题数据库,主要活动,问题控制,错误控制,主动问题管理,问题控制,确定和记录错误,错误评估,确定解决方案,实施后评估,问题终止,监控和管理已知错误得到适当处理,问题数据库,变更管理,问题数据库,RFC,变更实施,如何错误控制？确定问题产生的根本原因，把问题转为已知错误或与某各现有已知错误相关联；问题管理人员和支持组一起评估解决问题或已知错误的所需的资源，根据多种因素，比较不同的方案；一旦确定合适的解决方案，提交RFC，通过变更管理负责接方案的实际执行；用于解决问题、已知错误及相关事件的变更一旦实施后，必须进行评审，如果成功实施，对于所有问题和已知错误的记录工作可以终止，在问题数据库中标志为“已解决”；,主要活动,问题控制,错误控制,主动问题管理,描述 根据对IT基础架构进行的分析，问题管理可以找到可能出现问题的薄弱环节，在事件发生前发现和解决有关问题和已知错误，以尽量减少问题和已知错误对业务的影响。,制定预防措施 提交变更请求（RFC）；提交有关测试、规程、培训和文档方面的反馈信息；进行客户教育和培训；对服务支持人员进行教育和培训；确保遵守问题管理和事件管理的规程；改进相关的流程和程序。,趋势分析 找出IT基础架构中不稳定的组件，分析其原因 以便采取措施降低配置项故障对业务的影响；分析已发生的事件和问题，研究其变化趋势；通过其他方式和途径分析，比如系统管理工 具、用户反馈等。,化被动为主动，预防为主,提供二线/三线事件支持,问题识别及诊断,趋势分析,启动相关变更,监视变更管理,其他系统/应用上的问题预防,关键角色,问题经理 开发并维护问题控制和错误控制流程；帮助提高问题控制和错误控制的效率和效用；提供管理信息并运用这些信息主动预防事件和问题的发生；对问题管理人员进行管理；获取问题管理行为所需要的资源；开发并改进问题控制和错误控制系统；对主动性问题管理的有效性进行分析和评价。问题支持人员 被动性职责：通过分析事件细节确定并记录问题；以问题的优先级为基础对其进行调查和管理；提出RFC；监控已知错误的进展情况；为事件管理的应急措施和暂时修复提供建议；实行重大问题评审；主动性职责：确认问题的发展趋势；提出RFC；防止问题扩散到其他系统,发现IT 基础架构故障，并记 录直到解决；记录故障症状及解决临时或 永久性解决方案；提交变更请求，修复基础架构；防止可以避免的事故发生；获得关于IT基础架构质量及 管理基础架构的流程的质量方面 的报告,问题管理流程与其他流程之间的关系概述,问题管理问题控制错误控制主动性问题管理,事件管理,能力管理,配置管理,服务级别管理,可用性管理,变更管理,问题数据库,规避措施记录,信息（输入）,事件/配置信息 输入,变更请求（RFC）输出,实施后评审（PIR）输入,匹配信息应急措施临时修复输出,提高IT服务质量和管理水平；提高拥护效率；提高支持人员的效率；提升IT服务的声誉；改善对事故的记录水平；提高一线支持解决率；,与其他流程之间的关系,问题管理与配置管理配置管理提供关于基础架构、设计图、硬件和软件配置及服务等组件的重要信息，这些关系对问题管理的调查工作致关重要，因为他们定义了整个IT基础架构之间的相互关系；,问题管理与变更管理变更管理流程负责控制执行变更，包括由问题管理为消除问题而发出的RFC；变更管理通知问题管理关于纠正性变更的进展和完成情况。这些纠正性变更的评价需要与问题管理进行磋商；,问题管理与可用性管理问题管理通过找出服务失败的原因及补救方法来支持可用性管理的工作；可用性管理致力于基础架构的结构及设计、通过优化可用性的设计、规划和监控来防止问题和事件的发生，问题管理在分析服务失败的原因时与可用性管理一起工作；,问题管理与能力管理能力管理为问题管理提供用于定义问题的重要信息；而问题管理找出与能力有关的问题，查明原因并进行纠正，以此来支持能力管理的工作；,问题管理与事件管理有效的事件记录对于成功地进行问题管理来说非常重要，因为这些信息是用于发现问题的。问题管理支持事件管理流程的工作，它为事件管理提供应急措施；,问题管理与服务级别管理服务级别管理包括就是实施IT服务时的服务质量问题进行协商和谈判；服务级别管理为问题管理提供用于定义问题的信息，而问题管理过程应当遵守、支持规定的服务级别；,成本、效益和问题,成本 购买支持和诊断工具成本；人力成本；从外部供应商和支持机构雇佣额外的专业人员所需的成本。：提高IT服务的质量和管理水平:基础架构中的失败或错误已被记录并已消除；提高用户的效率：服务质量的提高；提高支持人员的效率：解决办法已被记录下来，事件管理代理可更加快速有效的解决事件；提升IT服务的信誉：因为提高了服务的稳定性，顾客在开展新的业务时会更加信赖IT机构；加强管理，增加操作知识，提高学习能力：问题管理保存的历史信息可用户确定事件或问题发展的趋势，因此可阻发生新的可避免事件。历史信息也有助于在准备RFC时的调查准备工作。改善对事件的记录水平：问题管理为事件的记录和分类引入标准，以有效的找出问题及其症状。它同时也可提高事件的报告水平。更高的第一线支持问题解决率：由于问题管理使事件和问题的解决方法和应急措施在知识库中可用，所以事件或问题由第一线支持人员解决的可能性更大。,成本、效益和问题（续）,问题：事件管理和问题管理之间的联系不密切如果事件细节和问题以及已知事件细节间的界面不是很清楚，那么事件管理将很难注意到对问题采取的应急措施，同时，问题管理也很难实现对问题的影响度进行评估和监控。这样还可能造成关于基础架构的专业知识记录以及历史数据的减少。问题管理的成功很大程度上取决于事件管理和问题管理这两个流程之间的协调。从开发环境到现场生产环境关于已知错误的沟通欠缺送交到生产环境的软件和技术架构应该同时包括关于任何已知错误细节的相关说明。在系统采用这些组件时，递交这些关于已知错误的信息能够避免公司在诊断先前已经了解的错误上浪费时间。因此，这两个环境中的记录保存系统之间应该保持有效的数据交换，或者建立统一的记录保存系统。缺少奉献精神如果公司以前采取的方法并不正规，那么在实施正规的问题管理上可能会受到一部分人的抵制，特别是关于文件管理和及时记录方面。因此，与问题管理行为相关人员在实施过程中应该保持对开发情况的信息畅通,关键成功因素和绩效指标,关键成功因素：一个定义清楚的流程框架和一系列流程的目标、接口和资源一系列广泛并详细记录的过程良好的事件管理数据以及事件管理和问题管理之间有效的合作。当分配任务时，你应该清楚地了解事件管理所作的“灭火”工作与问题管理进行的调查“火灾原因”的工作之间的区别。关键绩效指标：通过管理和解决问题，使事件的数量减少；解决问题所需的事件减少；与解决故障相关的成本降低。,