问题控制活动包括了哪几个ITSS阶段和要点？
20150720淡然续上
1.6问题控制的活动
实际上，由于计算机设备和通信线路的偶然出错，发生事故是不可避免的。许多其它事故不是由随机产生的故障引起的，而是由组织日益复杂的IT基础架构某处错误造成的。即使可预料的计算或通信设备故障也会由于提供商的产品中的错误，导致无法接受的影响。ITSS培训被动问题控制关注于识别事故真正的底层原因，以阻止将来的重复发生。在问题控制流程中有三个阶段：v问题的识别和记录；v问题的分类－根据对业务的影响；v问题的调查和诊断。图2问题控制当检测到根本原因时，就开始错误控制流程。
1.6.1问题识别和记录
问题识别发生在：v在事故的初始支持和分类阶段，不能够找到匹配的既有问题和知名错误；v事故数据的分析揭示了重复发生的事故；v事故数据的分析揭示了还存在没有与能够与既有的问题和知名错误匹配的事故；vIT基础架构的分析表明存在可能导致事故的问题；v重大或明显的事故（对客户的服务具有严重的不利影响）发生，需要找到结构化的解决方案。注意有些问题可能在问题管理小组之外被某个识别，如在能力管理中。无论如何，所有的问题应该通知问题管理流程被记录。可用性管理流程的许多方面关注于IT基础架构中的问题和事故的检测和避免，这两个领域的配合对提高服务质量具有重大的价值。*要点问题管理要求效力和资源，因此是昂贵的。组织要能够判定对某些类型的未能匹配的事故付出努力和成本是划算的－例如能够快速解决，影响较小或重复发生的可能性很小的事故。在这种情况下，可以在CMDB中引入虚构的问题记录，关联到所有有联系的事故、知名错误、变更请求以及配置项。问题记录需要记录在数据库（理想情况下是CMDB），这一点类似于事故记录。它们通常不包括某些不适用的标准事故数据（如用户数据）。然而问题记录应该连接到所有相关的事故记录。事故的解决方案和临时措施应该被记录在相关的问题记录中，以便另外相关的事故发生时能够访问。
图3事故匹配处理流程问题识别的流程如上图所示，包括基本的问题分类。受影响的配置项的数据应该准确地追加到这个基本分类数据中。理想情况下，这些配置可被单独修改的最低层的项目－例如，应用代码块或硬件组件。然而在问题识别阶段对于有问题的配置项的识别达到这个层次经常是不可能的
。1.6.2问题的分级当问题被识别时，需要较大的努力来检测和恢复断定存在故障的配置项。因此意识到问题对既有服务水平的影响是很重要的。这个流程被称为“分级”（classification）。在实践中，支持努力被分配到连接到单个事故的小面积的问题上。问题分级的步骤类似于事故分级的步骤，这些步骤决定：v类别v影响v紧急程度v优先级问题被归类到相关的组或域（例如硬件、软件、支持软件以及相应的其它种类）。这些组能够与机构的职责匹配，或者以用户和客户为基础归类，是将问题分配给支持职员的基础。附录A给出一个简单但对问题归类有效的结构。新问题的识别应该在受其影响的对象（也就是它对业务的影响）分析之后。登记在CMDB中的IT基础架构中的组件间的关系有助于判断问题的影响。组织应该根据它们的业务需要设计自己的影响代码系统。影响代码对于有效地分配支持力度是最有用的机制。更进一步包括优先级、从属影响，提供了全面的控制机制。当判断问题的影响时，登记在CMDB中的IT基础架构中组件间的关系是个极大的帮助。通过查询CMDB，可能识别事故涉及到IT基础架构中的配置项，以及同样的或依赖的配置项。ITSS认证紧急程度是指问题或错误的解决所能承受的延迟程度，它不应该与优先级混淆。优先级指明一系列项目－无论是事故、问题、变更或错误－应该被解决的相应次序。这会受到风险的考虑和资源可用性的影响，但更主要地是由紧急程度和影响的组合来决定。尽管较低的业务影响，但要求紧急解决的事情经常要放在较高的潜在业务影响但较低的紧急程度的事情之前处理。为每个方面分配数字值有帮助的，由此衍生出数字优先级，但是，对于所有的服务管理，这样的数字是凭人的直觉和业务意识来修改的。然而，对每个问题的紧急程度和影响赋予1－4的数值，对它们求和给出相应的优先级，是一个简单而实用的起点。那样做了，组织应该精密地监控和检查计算出的优先级，监控对应需求的功能。影响紧急程度的方面如：v临时修复的可用性；v存在临时措施；v计划推迟解决的可能性；v对业务未来影响的意识，如支持月末处理的设备需求。每个事故、问题和变更将都会对业务服务和紧急程度有影响：v影响－描述了业务受到破坏的可能；v紧急程度－表明了可用来转移或降低影响的时间。
*要点在最早的时机为所有问题分配影响代码。当这项工作完成后，重要的是在详细调查开始前，使所有问题归属到被管理的职员分配流程。被分配的人负责问题的解决，成为协调问题解决活动的中心。根据影响计划工作量，重要问题要立即引起注意。对低影响的问题可以允许超出特定的时间限制。影响分析流程遭遇一个重大的约束：它只反映当时的看法。虽然一个问题被正确地分配了低影响代码，但接下来属于该问题的事故数量陡然上升可能要求这个问题需要立即引起注意。需要设置事故限制来解决这个困难。如图3所示，问题管理流程被设计要维护与问题（和知名错误）记录匹配的事故的数量。问题和错误控制系统周期性扫描这个数值，将它与预先定义的限制值比较。当数量等于或超出这个限制，这样的问题/知名错误应该被升级到立即注意。然而，注意数量并不总是等于重要：当你发现订单不能输入超过$999,999.99的值，即使这样的情况只有0.5%，也必须被看做是关键的问题。
1.6.3问题调查和诊断
问题调查流程类似于事故调查流程－但是这两个流程的基本目标明显不同。事故管理的目的是迅速恢复服务，而问题管理的目的是诊断出底层原因。调查活动应该包括与该问题相关事故可用的临时措施，它登记在事故记录数据库。问题管理活动还包括更改问题记录中推荐的临时措施，以支持事故控制。
诊断结果经常表明问题的原因不是登记的配置项（硬件、软件、文档或程序）的错误，而是过程上的。例如，发布的程序版本不正确。这种情况下，问题以适当的分类代码来关闭，但不会达到有知名错误的状态。为了确保这类问题有章可循，采取措施解决它们，考虑为这种过失过程创建虚构的配置项，作为一个知名错误重新分级问题，或产生变更请求。
诊断揭示了原因是登记的配置项的错误，这时应该自动将问题的状态转成知名错误，由错误控制系统和过程接管。正如前面所指出的，问题调查的目标经常会与事故解决的目标相冲突。例如，问题调查可能要求详细的诊断数据，这些数据只有在事故出现时才能得到，而获得这些数据可能会明显地推迟正常服务的恢复。确保将事故控制与计算机操作或网络控制功能紧密联系，对于此类的活动给予适当的时间平衡。
1.6.4问题分析的方法
一些文献对于结构化问题分析和诊断提供了许多方法。这样的文献有：vKepnerandTregoe(参见附录B)vIshikawadiagrams(参见附录C)v头脑风暴会话v流程图方法问题管理应该选择最适合本组织目的的方法。
1.6.5问题控制的要点
以下是在问题控制中值得记住的要点：v事故分类是向问题定义发展的第一步，因此问题管理应该与事故管理紧密关联，考虑建立公用的事故和问题分类。对于报告的事故以及最终检测的原因应该给予适当的分类，事故分类应该用“客户术语”，而检测的原因归类用“IT术语”来表达。v如果可能的话，建立具有不同经验的人的小组，例如问题管理，在调查的时候，大家尽可能从不同的角度来参与。v为了参与的支持专家能够有效地执行他们的任务，确保他们有合适的工具和诊断协助工具。v如果问题不是由系统组件中的错误引起的，而是由于没有对用户培训引起的，解决并关闭问题记录。另外，创建新的配置项记录－在这个例子中是“培训问题”－按照通常的方法将问题转化为知名错误。确保检测的原因反映实际状况，例如，缺乏用户知识培训。v在事故或问题控制流程的诊断过程中，要求IT基础架构中的所有产品的文档可用，以支持职员在处理过程中作为参考。这些文档包括：u应用系统u系统软件u内部工具程序u网络硬件和软件u全局配置/网络图表v除了产品信息，具有有效的过程来收集诊断以解决问题也是必要的。支持职员熟悉这些过程特别重要，因为在事故处理的过程中不适当的使用会推迟正常IT服务的恢复。因此需要这些过程来支持和加强流程的需求－这些过程可能包括适当的培训、认证等。v支持专家会经常同时参与事故管理流程和问题管理流程，切记这两个流程的目标不同（快速解决对结构化解决），在这两个流程中，将专家的时间按固定的百分比分配证明是有用的，可能是事故管理占80%，问题管理占20%。这可以防止支持专家完全陷入被动事故管理。v在事故和问题的诊断过程中，问题管理职员也要求精确地记录最近的变更，因为这些可能是问题的原因。ITSS考试
待续：http://www.ITILxf.com/thread-51765-1-1.html
本帖关键字：ITSS
页:
[1]