相对于故障管理的步骤，ITIL对问题管理步骤的定义较难把握。ITIL定义了许多控制其他流程的流程以及只适用于大型组织的组织，因而它难免显得有点烦琐。这节我们也将只总结那些有助于解决问题的步骤，而不准备深人探讨所有的支持流程。记住，问题是造成故障的原因，因此，放在扩展这个背景中，它们可能就是你不能扩展到满足最终客户的需求，不能进行经济有效的扩展，或者将来不能轻松扩展的原因。

相对于故障管理的步骤，ITIL对问题管理步骤的定义较难把握。ITIL定义了许多控制其他流程的流程以及只适用于大型组织的组织，因而它难免显得有点烦琐。这节我们也将只总结那些有助于解决问题的步骤，而不准备深人探讨所有的支持流程。记住，问题是造成故障的原因，因此，放在扩展这个背景中，它们可能就是你不能扩展到满足最终客户的需求，不能进行经济有效的扩展，或者将来不能轻松扩展的原因。



在我们的模型中，问题流程是与故障流程并行的，要持续到识别出故障的根本原因为止。因此，尽管一个问题可能是许多故障的原因，但大多数问题持续的时间都比故障长。

就像故障一样，我们需要一个工作流，帮助解决问题。我们需要一个系统或一个地方用来存放所有处于打开状态的问题，确保它们与引发的故障关联在了一起。我们还要能够跟踪这些问题直到问题关闭。在理想状况下，问题关闭的标志是经历了故障的系统得到了修复。之所以如此定义，是因为只有当问题不再引发故障时，问题才不存在。这种定义对股东来说才是最有意义的，因为股东对我们和我们的团队最大化他们的价值寄予了厚望。

在我们看来，问题可以非常小，一个人就足以应付，问题也可以非常大，需要一个团队才能解决。但无论哪种问题，处理它们的工作流和关闭条件都是一样的，只不过所需的个人贡献者和管理的总量有所不同。小问题一个人就能处理，当可以关闭时，它们在通过相应的QA和测试标准验证后，可以由相应的管理人员或者经历了故障或问题的系统的负责人来关闭。

较大的问题更加复杂，需要借助微信小程序特定的流程来确保问题能够被迅速解决。一个大问题可以作为事后分析流程(本章后面将会介绍该流程)的主题，这样会衍生出其他的调查或解决问题的行动步骤。应该定期审查这些行动的结果，可以由负责解决问题的项目经理组成的专门团队进行审查，也可以由负责跟踪问题解决情况的经理进行审查，或者也可以在专J进行故障跟踪和问题解决的会议上进行审查，例如我们推荐的每日故障例会。