如何设计问题管理流程将事故影响最小化

　　“休斯敦，我们遇到问题了”，这是来自科学和技术界最伟大的语录之一。

　　然而从技术上来说，当他们用无线电告知在休斯敦的任务控制台时，阿波罗13号的工作人员应该说：“我们遇到了事故”，因为问题是事故表面下的未知原因。

　　事故是任何不属于标准服务运转部分的事件，能引起或是可能造成服务中断或是服务质量下降。谢天谢地，像任何组织良好的项目一样，休斯敦拥有一个中止计划，再加上宇航员们的足智多谋，他们最终能够平安地返回地面。

　　这是一起事故或危机管理的典型案例，目的是尽可能快地恢复服务运转的正常状态，从而将对运行的不利影响降至最低。拥有到位的事故管理计划以及应急响应团队来确保处理任何事故，应该成为任何组织的标准惯例。无论是天灾人祸、恶意攻击或是员工的疏忽，都应该被快速地处理，从而可以继续正常的服务。事故是每天业务生活的一部分，应该有帮助台(help desk)或IT支持人员来处理不太严重的问题，并有紧急响应团队来处理重大的事故。但是，究竟有多少组织拥有问题管理团队呢?

　　问题的定义是某个或多个事故的未知原因，问题管理流程涉及到判断此类事故表面下的原因，然后找到一个永久的解决方案。它不同于事件管理，因为它的关注点在于问题的解决而不是事件本身的响应速度，以防止它恶化成事件。

　　在阿波罗13号甲板上的事故引起了细致的调查以便判断问题的根源。然后用这方面的知识，以确保在未来的任务中问题不会再出现。这种类型的事件后分析可以起到至关重要的作用，确保企业网络运营保持不间断高效运行。没有它，宕机时间会延长，并且时间和金钱可能会浪费在处理重复的事故上。

　　让我们举个简单的例子来突出事件管理和问题管理间的差异：某个出问题的网络文件服务器无法让雇员们访问他们的文档。事件响应团队可能仅是重启服务器以便快速地恢复访问。问题响应团队则会找到让服务器宕机的原因，以便能修正并防止问题再次发生(请注意，问题管理不同于吸取经验教训的工作，后者是评审事故是如何处理的，看是否能改善未来事故的处理)。

　　尽管问题解决和事件响应是有关联的，但它们不一定要求同样的技能，因此参与到这两个流程的人员也是不同的。一些人可能知道如何恢复最近一次的数据库备份，但是不了解造成数据库崩溃的首要原因是什么。问题解决更加倾向于取证和追溯发生了什么引发了事件，而事件管理要求关于如何恢复一个系统的更具有可操作性的知识。

　　问题通常可由之后多个有类似症状的事故辨识——例如跨整个网络的电脑病毒传播并影响它们的性能——或者是从有重要影响的单个事故来辨识的，比如前面提到的情况：没人能访问某个特殊服务器上的文件。

　　一旦成功地诊断出事故表面下的原因，它就成了“已知错误”，随后的任务就是找到一个合适的变通方法或永久的解决方案。变通方法应该只用于将问题的影响最小化，直到找到永久的解决方案，并且问题应该归为已知的错误。

　　辨识问题根本原因的技术之一是使用因果图(Ishikawa diagram，也叫“鱼骨图”)，是用来映射事件起因的工具。潜在的原因通常被归类如人、流程、策略、硬件、软件和环境，在这些类中，任何来源的变化都能帮助找出问题的原因所在。其它技术如阿波罗根源分析方法(Apollo Root Cause Analysis)也能用来辨识原因和寻找解决方案。

　　尽管问题管理与事故管理是紧密关联的，但是在需要快速的解决事故和需要找到问题长期的解决方案间，两者可能有冲突。还是用前面的例子，立刻重启文件服务器可能破坏有用的诊断信息来辨识问题的原因。解决这个冲突的方法之一，是事先达成一致需要什么诊断信息，在恢复服务前允许的诊断时间，以及试图解决该问题会需要的那些必要资源。

　　问题管理的主动性方法是努力在事故发生前辨识和解决问题。这涉及到对日志报告和帮助台请求的趋势分析，接着是相关的新闻组用来对别处发生的问题进行提前预警，以及针对的支持行动。

　　问题管理流程目的是减少业务中事故和问题的次数、严重性和恶劣影响，并且预防与这些错误相关的事故再次发生。团队的成功可以很容易地监控问题诊断和解决的平均时间、重复问题的发生次数、以及重大事故的发生次数，并以此来衡量。拥有到位的问题管理流程会帮助任何组织减少重复的事故发生，并通往更为可靠的网络和应用环境之路。