同一个故障为什么每个月都要出一次？谈谈 IT 问题管理
有一类工单让运维工程师又熟悉又无奈。
打开工单系统，搜索某个关键词，跳出来十几条历史记录，时间跨度一年，处理方式高度雷同：重启服务，恢复正常，关闭工单。下个月，同样的工单又出现了。
这不是个别现象。很多 IT 团队有一个隐性的"月经问题清单"——那些周期性出现、每次都靠重启或者临时修复解决、从来没有被彻底根治的问题。工程师们早就知道怎么处理，但就是没有时间、没有机制去追它的根本原因。
这种状态的代价是双重的：一方面，工程师在重复劳动里消耗精力，疲于奔命；另一方面，业务部门每个月都要忍受一次中断，对 IT 服务的信任在慢慢消耗。
IT 问题管理（Problem Management）要解决的，就是这件事。
一、问题管理和事件管理的本质区别
很多人混淆问题管理和事件管理，觉得两者都是在"处理故障"，区别不大。但这两个流程的目标、节奏和思维方式完全不同。
事件管理关注的是"这一次"：系统现在挂了，怎么最快让它恢复。时间压力极大，容不得慢慢分析，第一目标是止血。
问题管理关注的是"这一类"：为什么这个系统会挂，根本原因是什么，怎么让它不再挂。没有紧迫的时间压力，但需要深入的技术分析和跨团队协作。
用一个比喻来说：事件管理是急诊室，问题管理是慢性病科。急诊室的任务是让病人脱离危险，慢性病科的任务是找到病根、制定长期治疗方案。两者缺一不可，但目标和工作方式截然不同。
正因为这个区别，很多团队在处理事件时，往往把"找根因"和"恢复服务"混在一起做，结果两件事都没做好：服务恢复得慢，根因也没真正找到。把这两件事拆开来，交给不同的流程和不同的角色去负责，才是成熟 IT 团队的做法。
二、问题是怎么被发现的
问题管理的第一步是识别问题，但问题的来源并不只有一个渠道。
从事件中发现，是最常见的来源。当同一类事件反复出现，或者某次事件的影响特别大，就应该触发问题管理流程，立项做根因分析。一般来说，有几种情况应该自动触发问题识别：同一个配置项在一个月内触发了三次以上的事件；单次事件导致核心业务中断超过一小时；事件解决方案是临时绕过而非根本修复。
从趋势分析中发现，是更主动的方式。定期分析工单数据，识别出工单量在上升的问题类型、经常超时处理的事件类型、用户满意度持续偏低的服务领域，这些都可能指向需要深入排查的潜在问题。这种主动发现需要 IT 团队有意识地从数据里找规律，而不是被动等问题暴露出来。
从变更和项目中发现，是容易被忽视的来源。某次系统升级之后，某类问题的频率明显上升；某个新功能上线之后，相关模块的工单量突增——这些信号往往指向变更引入的新问题，需要及时识别并立项处理。
从用户反馈中发现，也不能忽略。用户对某个 IT 服务长期不满意，但每次反馈的都是具体的小问题，没有任何一次构成"大事件"。把这些零散的反馈归集起来看，可能会发现背后有一个系统性的根因在驱动。
三、根因分析怎么做
根因分析（Root Cause Analysis，RCA）是问题管理的核心技术动作，也是最考验团队能力的环节。
很多团队的根因分析流于表面：系统崩溃了，查一下日志，发现内存溢出，得出结论"内存溢出导致崩溃"，然后增加内存，问题关闭。但内存为什么溢出？是代码里有内存泄漏？是某个定时任务占用了大量内存？是并发量超过了系统设计的上限？这些问题没有追下去，"增加内存"只是延缓了下次崩溃的时间，不是真正的根本修复。
有几个常用的根因分析方法，在 IT 领域被广泛应用。
五问法（5 Whys），是最简单也最常被误用的方法。做法是对每一个"为什么"的答案，继续追问"为什么"，重复五次左右，直到找到根本原因。它的价值在于强迫团队不停在表象答案上，而是持续深挖。但它也有局限性：对于复杂的系统性问题，原因往往不是线性的，单一的追问链可能找不到真正的根因。
鱼骨图分析（Ishikawa Diagram），适合多因素交织的复杂问题。把可能导致问题的因素分类列出——人员、流程、工具、环境、配置……对每个类别下的因素逐一评估，找出哪些因素确实对问题有贡献。这个方法有助于避免"只看技术因素、忽视流程和人的因素"的偏差。
时间线分析，适合事故类问题的复盘。把事件发生前后的所有操作和状态变化按时间顺序排列出来，找出异常开始的时间点，以及这个时间点前后发生了什么。很多时候，把时间线拉出来，问题的根因就已经很明显了。
无论用哪种方法，根因分析有一个基本原则要坚守：结论必须有数据支撑，不能靠猜。"可能是数据库的问题"不是根因，"数据库的慢查询日志显示，XX 表的 XX 查询在事件发生期间执行时间超过三十秒，导致连接池耗尽"才是。
四、找到根因之后：修复、记录、知识沉淀
根因找到了，问题管理才走完了一半。后续的处置同样重要。
制定修复方案，区分临时方案和永久方案。很多问题的永久修复需要时间，比如需要做代码重构、需要在下个版本里发布修复、需要采购新的硬件。在永久修复完成之前，需要有一个临时的缓解方案，降低问题再次触发的概率，或者减少触发时的影响。临时方案和永久方案都要明确记录，并设定完成时间节点，确保永久修复不会因为"现在不是紧急问题"而一直被推迟。
评估已知错误（Known Error）的处理策略。在 ITIL 框架里，已知根因但尚未修复的问题，被称为"已知错误"（Known Error）。已知错误的存在是正常的，不可能所有问题都立刻修复，关键是要把它们记录在已知错误数据库（KEDB）里。这样当事件管理团队再次遇到同类事件时，可以立刻查到这是已知错误，直接使用已知的缓解步骤，大幅缩短处理时间，而不是每次都重新排查。
更新知识库，让解决方案可复用。问题管理的产出物，包括根因分析报告、临时缓解方案、永久修复步骤，都应该同步到 IT 知识库，供团队成员查阅。知识库里"如何处理 XX 类故障"的文章，最好的来源就是问题管理的实际分析结果，而不是工程师凭印象写出来的经验总结。
关闭问题单的条件要明确。问题单不是永久方案落地就关闭，而是要确认：根因分析结论已经记录，永久修复方案已经实施并验证有效，知识库已经更新，同类事件在一段时间内没有再次出现。满足这些条件之后，才是真正意义上的"问题关闭"。
五、问题管理为什么难落地
问题管理在 ITSM 体系里是公认最难推行的流程之一，原因不在技术，在管理。
最大的障碍是时间。事件管理是紧急的，总是在抢占工程师的时间；问题管理是重要但不紧急的，在繁忙的日常运维里，总是被推到明天再说。没有人专门负责问题管理，没有人跟进问题单的进展，问题管理就会慢慢名存实亡。解决办法是把问题管理的工作量纳入团队排期，给它分配专门的时间和人力，而不是让它在日常工作的缝隙里自生自灭。
根因分析的质量参差不齐。做根因分析需要一定的方法论基础和技术深度，不是所有工程师都有这个能力和习惯。团队需要在方法上做培训，并且对根因分析报告的质量设定标准——"内存不足"不能作为根因结论，必须追到"为什么内存不足"才算合格。
跨团队协作是常见障碍。很多问题的根因横跨多个团队，需要应用、运维、网络、数据库等多个团队共同分析。但各团队有各自的优先级，协调起来摩擦大、推进慢。问题管理需要有人来承担跨团队协调的角色，确保分析工作不会卡在边界上。
修复方案的落地缺少追踪。根因找到了，修复方案也定了，但谁来确保方案真的被实施了？在没有明确追踪机制的团队里，修复方案很容易停留在纸面上——每个人都知道该怎么修，但没有人真的去做。问题管理系统需要对修复方案的实施状态进行跟踪，设定完成时间节点，超时自动提醒。
IT 问题管理做好了，是整个 IT 运维体系从"救火模式"转向"预防模式"的关键一步。事件量会下降，工程师的重复劳动会减少，业务部门对 IT 服务的信任会逐步建立起来。这个转变不是一蹴而就的，但每一个被彻底根治的问题，都是一步扎实的进展。
如果你的团队正在建立问题管理流程，ManageEngineServiceDesk Plus提供了与事件管理深度集成的问题管理模块，支持从事件工单一键创建问题单，内置已知错误数据库（KEDB），问题根因分析结果可直接关联知识库文章，修复方案的实施进度可追踪，并支持问题与变更管理流程的联动。对于想把问题管理真正跑起来而不只是填表走流程的 IT 团队，可以作为工具选型的参考。