问题管理

基础要点

通过调查分析，以确定事故的根本原因，通过制定变通方法，或是找到长期有效的解决方案，来减少事故的数量和影响。

变通方法：是一种为了减少事故发生的可能性与影响，在未找到完全解决方案事前的方法。变通方法需清晰地定义其适用的症状。

管理的三个阶段：问题识别，问题控制和错误控制。

问题识别阶段包括：根据记录进行趋势分析，检查是否属于重复或重现，识别重现的风险，从外部供应商与合作伙伴处收集信息并进行分析，从内部开发、测试、项目团队处收集信息并分析。

问题控制阶段包括：基于风险的潜在影响与可能性，进行优先级分析，文档化变通方法与已知错误（经由分析尚未解决的问题）。

错误控制阶段包括：定期评估已知错误的状态，以及变通方法的有效性，根据成本、风险和收益触发变更请求。

问题管理与其他管理实践的关系：

问题管理是风险管理的特定案例；

问题管理可利用知识管理系统中的信息来开展调查、诊断和解决；

问题管理不包括实施，需要通过变更控制来启动解决方案；

问题管理可被视为持续改进的一种实践。

解读

至此，ITIL 中有关事件、事故、问题三种管理的最佳实践都已出现，为了理清它们之间的关系，我们一起对照着日常工作实际来比较一下：

1.事件（Event）

一般是指某种IT 服务或是被监控项到达了门限值，而引发的警告；或者是伴随着某项操作所触发的通知等。

例如，数据存储的剩余空间小于已设定的百分比数值，对某个账号的权限变更，或是用户组的成员调整等。当然，正如我们在上面事件管理实践中所讨论过的那样，事故也包括一些尚未产生影响的监控项异常。例如，在做了RAID 5 的磁盘组，有一颗磁盘出现了故障，但整体所提供的服务尚未中断。

2.事故（Incident）

是指计划外的IT 服务中断，或是服务质量的骤降。

例如，由于专线出现问题，某个分公司失去了与总公司的网络连接；或是某用户利用公司内网观看在线视频，而拖慢了整体的内、外网访问速度。

通常情况下，对于处理人员来说，能够快速找到那些能够所谓“能治标不治本”处置方法，可能会比花费更多的时间去研究症结，更容易被用户所接受和认可。

可见，对于事故的管理，我们主要是以止损、抑制不良影响、以及快速恢复为目标。

表4 问题跟踪表格

3.问题（Problem）

如果说处理事故是利用应急措施，去尽快地恢复IT服务的话，那么解决问题则是通过查找根源，预防中断的再次发生，以及对于那些经过分析仍无法解决的问题，通过变通方法来控制其影响的程度与范围。相对于事故管理而言，它往往会涉及到更多的人员角色，也会耗费更长的时间。

例如，软件开发部门协同运维部门一起，对其所发布的产品中所出现代码的漏洞、以及不正确的配置进行安全加固，以消除攻击隐患等。

因此，我们需要通过跟踪那样已知故障、诊断根本原因，引入变更控制，来防止同类问题在整个系统中的复发。

一般而言，由于问题管理主要致力于“治本”，因此企业可设立问题管理委员会来对问题的整个生命周期进行跟踪与评估，其中涉及到的关键绩效指标包括：

问题处置过程的平均耗时；

已确定根源、已解决、以及未关闭问题的占比；

问题解决所消耗的综合成本；

管理前的数量与解决之后复发数量的对比。

实务

在本企业，为了留存在问题处理过程中产生的记录，我们根据业界的处置标准，采用了如表4 所示的问题跟踪表格。

根据上表，我们还制定了如图2 所示问题管理的相关流程。

从管理的角度来说，上述流程的重点在于评估问题和分派问题：

1.在问题产生相关的通知之后，问题管理委员会根据该问题的特征和本团队的经验，对需要人工干预的问题进行二次判断与评估。他们往往会参考我们在变更管理中提到的矩阵列表，对问题的影响范围与程度，进行审查或修正。当然，他们也会参考技术人员的工作量和实际处理能力。

图2 问题管理的相关流程

2.为了将合适的问题分派给合适的处置人员，我们会直接读取系统目录（如：Active Dictionary）里IT角色和相关的组群信息，甚至会在必要时，引入各部门进行联动“会诊”。另外，为了保证始终有人去接手问题，问题管理委员会通过自动化跟踪，来确保如果被分派到的处理人员不在岗，或是无法胜任时，能够升级到其所在的技术团队。而如果某个问题超出了企业内部现有的处理能力，则需要添置相应的专业技术与工具，或是及时转呈给外部资源，以寻求援助。