|
|
|
系统运转过程中出现的故障经过处理恢复都得到了暂时解决。其中部分故障可以得到控制解决，这通常是一些故障原因单一的局部性问题，影响也不大；但某些故障出现之后会有同样或者类似的故障接连重复发生，这是故障处理“治标不治本”的后果。要根本解决这类故障，需要从引起这些某一类问题的根本原因出发进行控制，我门将存在这些导致潜在故障的原因的情形称为问题。故障管理后续工作还要延伸到对问题和错误的控制和管理，以及进行故障预防。
|
|
|
|
|
|
|
|
（1）问题，问题的是存在某个未知的潜在故障原因的一种情况，这种原因会导致一起和多起故障。问题经常是分析多个呈现相同症状的故障后被发现的。问题也可从单个重要的事物中确认以表示一项错误。这种错误产生的原因虽然未知，但其产生的影响却可能是非常严重的。
|
|
|
|
（2）已知错误，已知错误是指问题经过诊断分析后找到故障产生的根本原因并制定出可能的解决方案时所处的状态。在这种状态下，一种临时性的权宜措施和永久性的解决方案已经得到确认。如果一个问题转化成了一个已知错误，则应当提出一个变更请求。但是，在通过一项变更将此已知错误永久性地修复之前它仍将作为一个已知错误。
|
|
|
|
（3）问题控制，问题控制流程是一个有关怎样有效处理问题的过程，其目的是发现故障产生的根本原因（如配置项出现故障）并向服务台提供有关应急措施的意见和建议。
|
|
|
|
问题控制过程与故障控制过程极为相似并密切相关。故障控制重在解决故障并提供响应的应急措施。一旦在某个或某些事物中发现了问题，问题控制流程便把这些应急措施记录在问题记录中，同时也提供对这些措施的意见和建议。
|
|
|
|
与故障管理的尽可能快地恢复服务的目标不同，问题管理是要防止再次发生故障，因此，问题管理流程需要更好地进行计划和管理，特别是对那些可能引起业务严重中断的故障更要重点关注并给予更高的优先级。
|
|
|
|
（4）错误控制，错误控制是解决已知错误的一种管理活动。由于财务和技术方面的原因，影响IT基础架构的错误不可能全部得到纠正。错误控制就是要对这些错误进行管理，从而使受其影响的用户能够意识到这些错误的影响。除了消除错误之外，通过错误控制还可能将现有错误的负面影响降到最低。
|
|
|
|
（5）问题预防，问题预防是指在故障发生之前发现和解决有关问题和已知错误，从而使故障对服务的负面影响其与业务相关的成本降到最低的一种管理活动。通过化被动为主动，IT支持组织提供了更好的服务并提高了自身的资源使用效率。
|
|
|
|
|
|
|
|
（1）将由IT基础架构中的错误引起的故障和问题对业务的影响降到最低限度。
|
|
|
|
（2）找出出现故障和问题的根本原因，防止再次发生与这些错误有关的故障。
|
|
|
|
（3）实施问题预防，在故障发生之前发现和解决有关问题。
|
|
|
|
|
|
（1）故障是任何不符合标准操作，并且已经引起或可能引起服务中断和服务质量下降的事件。它产生的原因可能比较明显，不需进一步调查就可解决（比如采取补救措施、临时办法和通过变更请求），甚至可不用了解其原因而直接由客户自己解决（比如重启计算机、重新设置通信线路等）。
|
|
|
|
（2）问题是指，导致一起和多起故障的潜在的、不易发现的原因。问题需要被调查后才能确认，其影响度得确定需要综合考虑它的业务的实际或潜在影响以及起因相同或相似的故障（包括已解决的和未解决的）的数量。故障和问题之间不是一对一的关系，而是多对多的关系：一个故障可能有多种原因，一个故障可能对应着某个问题，同样，一个问题可能是对多个故障的调查后被确认的。
|
|
|
|
（3）已知错误是一个故障和问题，而且产生这个故障和问题的根本原因已查明，并已找到解决它的临时办法和永久性的替代方案。解决的过程需要提交变更请求，不过在实施变更以永久性解决它之前，它将一直存在。已知错误和问题之间的关系与故障和问题之间的关系类似，也是多对多。
|
|
|
|
（4）变更请求适用于记录有关变更内容的书面文件和电子文档。这种变更是针对基础架构的配置项以及与基础架构相关的程序和规章制度而进行的。
|
|
|
|
故障、问题、已知错误和变更请求之间的逻辑关系可用下图表示
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.已解决问题的记录（如果已消除了故障产生的原因）。
|
|
|
|
|
|
|
|
问题管理流程主要涉及问题控制、错误控制、问题预防和管理报告4种活动，下面分别对这4种活动做简要介绍。
|
|
|
|
|
|
在实际运用IT服务过程中，出现问题是无法避免的，比如网络出现线路故障，和随着组织IT基础架构复杂性的增加而产生的错误，甚至某些厂商的产品本身的缺陷也可能降低服务质量到不可接受的水平。一旦发现问题，我们必须及时对企业进行控制，分析它产生的原因并在必要时把问题升级为已知错误。问题控制过程如下图所示
|
|
|
|
|
|
|
|
|
|
问题控制的第一步是发现和记录问题。原则上所有原因未知的故障都可被称为问题，但我们通常将重复发生的和非常严重的故障归类为问题。发现问题的途径有很多种，常见的问题如下。
|
|
|
|
.在故障初步阶段和支持阶段没能把故障与问题或者已知错误匹配成功
|
|
|
|
|
|
.分析故障数据排除已与存在的问题和已知错误成功匹配的故障；
|
|
|
|
|
|
问题也可能被问题管理小组以外的人发现。但不管是谁发现的，所有问题都应由问题控制管理流程来处理。
|
|
|
|
问题记录与故障记录类似，但不包括用户名等信息，同时问题记录应该关联到所有与其相关的故障，故障的解决方案和应急措施也要被记录在相应的问题记录中。
|
|
|
|
|
|
查明和记录问题后，为便于评价问题对服务级别的影响，确定查找和恢复有故障的配置向所需的人力和资源，可先对问题进行归类。以故障归类类似，问题归类的标准仍然涉及以下4个方面。
|
|
|
|
.目录，确定与问题相关联的领域，比如硬件、软件等。
|
|
|
|
|
|
|
|
.优先极，综合考虑影响度、紧迫性、风险和可用资源后得出的解决问题的先后顺序。
|
|
|
|
|
|
调查问题的过程与调查故障的过程类似，但两者的主要目标明显不同：前者是发现故障产生的潜在原因，而后者是尽可能快速地恢复服务。因此，前者比后者调查得更细致深入，需要调查人员掌握更多的经验和技巧，有时还需要专家的支持：同时，问题调查的范围也比故障调查的要广，它包括对故障处理中使用的应急措施的调查等。当发现更好的和新的应急措施时，问题管理还要将其在问题记录中更新以便故障控制使用。
|
|
|
|
问题调查和分析过程需要详细的数据，而很多时候这些数据只有在故障发生时才能被收集到，这是一个矛盾。为了解决这个矛盾，问题调查人员应该与故障控制和计算机网络控制部门协调好有关情况。
|
|
|
|
问题分析方法主要有4种：Kepner&Tregoe法、鱼骨图法、头脑风暴法和流程图法。这里我们重点介绍Kepner&Tregoe法和鱼骨图法。
|
|
|
|
（1） Kepner&Tregoe法。Kepner&Tregoe是一种分析问题的方法，即出发点是解决问题是一个系统的过程，应该最大程度上利用已有的知识和经验。它把问题分析分为以下5个阶段。
|
|
|
|
①定义问题。调查是根据定义问题进行的，因此问题定义必须明确指出IT服务偏离服务级别协议的情况。在这里我们要避免这样一种情况，即认为产生问题的最可能的原因已经明朗，因而不用经过进一步调查而可直接做出结论。这可能导致一开始就选错调查的方向。
|
|
|
|
|
|
|
|
|
|
|
|
.规模和范围。问题的规模和范围多大？哪些部分将受到影响？
|
|
|
|
③找出产生问题的可能原因。根据第二步的比较和实施的变更，尽量发现问题产生的可能原因。
|
|
|
|
④测试最可能的原因。评价每个可能原因以确认其是否就是形成问题症状的原因。
|
|
|
|
⑤验证问题原因。通过上一步的测试后，剩余的可能原因需经进一步测试以确认其是否是产生某个问题的真正原因。一般应优先消除那些可以简单快速验证的起因。
|
|
|
|
（2）鱼骨图法。鱼骨图法是分析问题原因常用的方法之一。在问题分析中，“结果”是指故障或者问题现象，“因素”是指导致问题现象的原因。鱼骨图就是将系统或服务的故障或者问题作为“结果”、以导致系统发生失效的诸因素作为“原因”绘出图形，进而通过图形分析从错综复杂、多种多样的因素中找出导致问题出现的主要原因的一种图形。因此，鱼骨图又叫因果图法。日本质量管理专家石川馨最早使用了这种方法，故有时特性因素图又被称为石川图。
|
|
|
|
|
|
①按具体需要选择因果图中的“结果”，放在因果图的最“右边”（相当于“鱼头”）。
|
|
|
|
|
|
③通过调查分析，判别影响“结果”的所有原因。先画出“大原因”，用直线与主干线相连，并在直线的尾端常用长方形框（或圆圈）框（或圈）起来，在框（或圈）内填入“大原因”的内容；进而依次细分所属的全部原因，直至能采取解决问题的措施为止。各大、小原因之间用不同的直线表示因果之间的关系。
|
|
|
|
④主要的或关键的原因常用框框起来，以表示醒目。根据实际需要，对这些关键的或主要的原因还可以做单独的特性因素图，以便进一步重点深入分析。
|
|
|
|
|
|
|
|
|
|
（3）头脑风暴法。头脑风暴法是一种激发个人创造性思维的方法，它常用于解决问题的方法的前三步：明确问题、原因分类和获得解决问题的创新性方案。针对问题，我们可以应用头脑风暴法来提出所有可能的原因。
|
|
|
|
应用头脑风暴法必须遵守下列4个原则：畅所欲言、强调数量、不做评论、相互结合。
|
|
|
|
（4）流程图法。流程图法通过梳理系统服务的流程和业务运营的流程，画出相应的流程图，关注各个服务和业务环节交接可能出现异常的地方，分析问题的原因所在。流程图中应该包括系统服务中涉及到的软硬件设备、文件、技术和管理人员等所有问题的相关因素。
|
|
|
|
以上每种问题分析方法有其优点和缺点，问题管理人员应选择合适的方法来分析问题。
|
|
|
|
|
|
错误控制是管理、控制并成功纠正已知错误的过程，它通过变更请求向变更管理部门报告需要实施的变革，确保已知错误被完全消除，避免再次发生故障。错误控制对所有已知错误从其被发现至被解决的全过程进行控制，涉及公司的许多不同部门。错误控制的过程主要分为三个阶段，如下图所示。其中跟踪和监督错误活动将覆盖问题的整个生命周期。
|
|
|
|
|
|
|
|
|
|
一旦确定了问题产生的根本原因，问题就将转变为一项错误；如果找到对付错误的应急措施，错误又将成为已知错误。错误或已知错误的确定是错误控制过程的开始。
|
|
|
|
错误控制系统中有关已知错误的数据来源主要有两个：运行过程和开发过程。前者主要指在问题控制过程中把某个问题升级为已知错误时，在问题调查和分析阶段记录的数据可直接作为错误控制所需错误信息的基础；后者如应用系统包含了开发阶段形成的错误，但直到正式实施时才会被发现，则有关这些错误的信息应该按要求输入到错误控制系统的数据库中。
|
|
|
|
|
|
发现和记录错误后，问题管理人员与支持组将一道对错误可能的解决方法进行初步评估。如果他们发现不能消除错误，就将通过变更请求向变更管理部门报告有关情况。变更管理部门根据错误对业务的影响、紧迫性、严重性来确定变更管理请求的优先级。
|
|
|
|
|
|
错误控制系统应该详细记录每个已知错误的解决过程，特别是与已知错误有关的配置项、症状和解决方案（或替代方案），记录的信息保存于问题管理数据库中。这些信息可用于故障匹配中，为以后的故障调查和解决提供指导，也可用于管理报告中。
|
|
|
|
|
|
在实施变更已成功消除错误后，可以终止已知错误及其相关的故障和问题，并通过实施后评审确认已知错误的解决效果。对故障来说，实施后评审延续就是简单地打电话询问客户是否满意，但对问题和已知错误来说，实施后评审应该是一个正式的和规范的过程。
|
|
|
|
|
|
变更管理流程将负责处理变更请求，而错误控制需要对已知错误的解决过程进行监控。在整个解决过程中，问题管理需要从变更管理获得有关问题和错误解决情况的正规报告。
|
|
|
|
|
|
到目前为止，我们说明的主要是一些被动的问题管理活动，事实上，我们完全可以化被动为主动，在故障发生前发现和解决有关问题和已知错误，以尽量减少问题和已知错误对业务的影响，这就是本节要讲的问题预防管理。
|
|
|
|
问题预防的范围非常广泛，既涉及单个问题，如与系统某一特征相关的重复性故障，也包括有重要影响的战略性决策，如投资建设更好的网络，或者为客户提供多种帮助信息，甚至可以是为问题解决人员提供在线支持以提高他们解决问题的速度、减少用户等待时间。
|
|
|
|
问题预防的流程主要包括两项活动：趋势分析和制定预防措施。
|
|
|
|
|
|
趋势分析的目的是为了能够主动采取措施提高服务质量，它可以从以下几个方面进行：
|
|
|
|
（1）找出IT基础架构中不稳定的组件，分析其原因，以便采取措施降低配置项的故障对业务的影响。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
通过趋势分析，问题管理人员既可以发现和消除存在于IT基础架构中的故障，也可以探明哪些问题是支持小组必须重点关注的。
|
|
|
|
为了有效地引导有限的服务支持资源配置到恰当的问题领域，问题的方案管理需要调查哪些领域占有了最多的服务支持。通过从整体上对已出现的和可能出现的问题的分析，我们可以确定哪个问题和哪类问题是真正需要重点关注的和优先解决的。比如，当有些故障出现次数多但影响不大，而有些故障出现少而影响巨大，并且解决这类故障的效益更好时，显然应该优先解决后者。因此，我们可以考虑给每一类故障一个“损害指数”作为测度指标，指数大小可以根据以下几点确定。
|
|
|
|
|
|
|
|
|
|
|
|
这种方法避免了将过多的精力放在一些数量较大但对业务影响较小的故障和问题上面，从而忽略了那些数量较小但影响巨大的故障和问题。事实上，将服务支持资源投入那些出现次数虽少但影响重大的故障和问题上，往往能取得更大的效益。
|
|
|
|
在确定服务支持人员应重点关注的问题之后，问题管理人员就应当采取适当的行动以预防其发生。这些行动如下。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
问题管理流程应定期或不定期地提供有关问题、已知错误和变更请求等方面的管理信息，这些管理信息可用做业务部门和IT部门的决策依据。其中，提供的管理报告应说明调查、分析和解决问题和已知错误所消耗的资源和取得的进展。具体来说包括以下几个方面：
|
|
|
|
（1）事件报告。支持小组和供应商花费与问题同质、错误控制和问题地方的时间。
|
|
|
|
（2）产品质量。根据故障、问题和已知错误信息发现经常受错误影响的产品，并确认供应商的产品是否符合要求。
|
|
|
|
（3）管理效果。说明问题解决前后故障的数量、变更请求数量和解决的已知错误的数量。
|
|
|
|
（4）常规问题管理与问题预防管理之间的关系。积极的预防比消极的应对故障的出现更能体现出问题管理流程运营的成熟性。
|
|
|
|
（5）问题状态和行动计划。说明已对问题采取了何种行动、将采取何种行动及所需的时间和资源。
|
|
|
|
（6）改进问题管理的意见和建议。根据上面的信息，判断问题管理流程是否达到了服务质量计划的目标。如果没有到达，则审计管理流程，提出改进的意见和建议，并估计所需的资源和费用。
|
|
|
|
最后的管理报告与问题管理的范围有很大关系。如果范围扩展到产品和服务开发阶段，则问题管理甚至从这个阶段就要开始定义和监督已知问题和已知错误，从而管理报告也要包括这个阶段的有关问题和已知错误的解决和预防情况。
|
|
|
