学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放

本文出自   转载等请务必保留此出处

从“治标”到“治本”

　　在上一期中，我们提到事故管理可以帮助IT部门更加系统、快速地处理事故，但是，事故管理流程只是“规范”处理事故的过程，并没有消除“事故”本身，或者说没有阻止事故的再次发生。这是一种“治标”的方法。

    为了使对事故的管理有质的提高，我们还必须找到一种“治本”的方法。这就是本期要讲的问题管理流程。

　　问题管理与事故管理有明显的不同，后者是要尽可能快地恢复服务，而前者的主要目的是找出事故产生的根本原因，并彻底地解决问题。为此，问题管理流程甚至可能要求中断服务。

　　进一步，如果问题管理发现一个或多个事故产生的原因，并找到解决这些事故的临时措施，就将其升级为知名错误（Known Error，即整体影响大、出现频率高、应该引起足够重视的事故），并提交变更请求（RFC）以消除事故或问题产生的根本原因。

    治本方略

那么如何进行问题管理呢？考虑到在实际运作IT服务过程中，出现问题是无法避免的，比如网络出现线路故障，或者随着组织IT基础架构复杂性的增加而产生的错误，甚至某些厂商的产品本身的缺陷也可能降低服务质量至用户不可接受的程度。一旦发现问题，我们必须及时对其进行控制，分析其产生的原因，并在必要时把问题升级为知名错误。

        1. 发现问题

　　问题控制的第一步是发现和记录问题。原则上所有原因未知的事故都可称为问题，但我们通常只把重复发生的或非常严重的事故归类为问题。发现问题的途径有多种，如在事故初步和支持（临时处理，以维持服务的连续性）阶段，没能把事故与问题或者知名错误匹配成功、分析事故数据时发现重复出现的事故以及分析IT基础架构时发现可能导致事故的问题等。

　　问题也可能由问题管理小组以外的人发现。但不管是谁发现的，所有问题都应由问题管理流程来处理。

        2. 记录问题

　　问题记录与事故记录类似，但不包括用户名等信息。同时，应该将问题记录与所有与其相关的事故关联起来，事故的解决方案和应急措施也要记录在相应的问题记录中。

        3. 归类问题

　　查明和记录问题后，为便于评价问题对服务级别的影响，确定查找和恢复有故障的配置项所需的人力和资源，可先对问题进行归类。与事故归类类似，问题归类涉及以下四个方面：

• 目录：确定与问题相关联的领域，比如硬件、软件等；
  
• 影响度：问题对业务流程的影响程度；
  
• 紧迫性：问题需要得到解决的紧急程度；
  
• 优先级：综合考虑影响度、紧迫性、风险和可用资源后得出的解决问题的先后顺序；
  
• 状态：描述事故目前所处的状况，如问题、知名错误和已解决等。
  
  
  

    4. 调查和分析问题


调查问题的过程与调查事故的过程类似，但两者的主要目标明显不同：前者是发现事故产生的潜在原因，而后者是尽可能快速地恢复服务。因此，前者比后者调查得更细致、深入，需要调查人员具有更多的经验和技巧，有时还要专家支持组提供相应的支持。
　　同时，问题调查的范围也比事故调查的要大，它包括对事故管理中使用的应急措施的调查。当发现更好的或新的应急措施时，问题管理还要将其在问题记录中更新以便事故控制使用。
　　问题的大部分起因可归结于基础架构（如硬件、软件）方面的错误，但也经常会出现来自于文档、人员或程序方面的错误。因此最好使规程被包括在配置管理数据库（CMDB）中，并对其实行版本控制。类似这样的错误出现时不要立即将其升级为知名错误，而是先在配置管理数据库（CMDB）中为它们增加一个名义上的配置项，然后在适当的时候将它们重新归类为知名错误，或提交RFC报告。
　　问题调查和分析过程需要详细的数据，而很多时候这些数据只有在事故发生时才能收集到，这是一个矛盾。为了解决这个矛盾，问题调查人员应该与事故控制和计算机网络控制等部门协调好有关情况。

       从“被动治本”到“主动治本”

　　上文所描述的实质上还只是一些被动的问题管理活动，事实上，我们完全可以化被动为主动，在事故产生前发现和解决有关问题和知名错误，以尽量减少问题和知名错误对业务的影响，这就是问题预防。或者说是“主动治本”。

　　问题预防的范围非常广泛，既包括单个问题如系统操作困难，也包括有重要影响的战略决策，如投资建设更好的网络，或者为客户提供多种帮助信息，甚至可以是为问题解决人员提供在线支持以提高他们解决问题的速度，减少用户等待时间。问题预防过程分为两步：分析趋势和采取预防措施。

        1. 分析趋势

        分析趋势的目的是为了能够主动采取措施提高服务质量，它可以从多个方面进行，比如找出IT基础架构中的不稳定组件，分析其原因，以便采取措施降低配置项故障对业务的影响；分析已发生事故和问题，发现某些潜在的事故诱发趋势；或是通过其它方式和途径，如会议和用户反馈等来分析趋势。

        2. 采取预防措施

　　趋势分析既可能导致发现、分析和消除IT架构故障，也可能导致发现某些需要支持小组更多关注的一些问题。

　　通过从整体上对已出现的和可能出现的问题的分析，我们可以确立哪个或哪类问题是“真正”需要重点关注和优先解决的。比如，当有些事故出现次数多但影响不大，而有些事故出现次数少但影响巨大且解决这类事故能带来更好的效益时，显然应该优先解决后者。因此，我们可以考虑给每个事故一个“痛苦指数”，指数大少根据以下几点确定：

• 事故出现次数
  
• 受影响的客户数；
  
• 解决事故所需时间和成本；
  
• 业务损失。
  
  
  

　　确定关键问题后，事故管理小组就采取行动解决事故或预防其发生，这些行动包括：

• 提交变更请求（RFC）；
  
• 提交有关测试、规程、培训和文档方面的反馈信息；
  
• 进行客户教育和培训；
  
• 教育和培训服务支持人员；
  
• 确保问题管理和事故管理规程得到遵守；
  
• 改进流程和程序。
  
  

前排顶，很好！

一直在看