在软考信息系统管理工程师、系统规划与管理师的历年选择题中，事件管理与问题管理是两条几乎逢考必出的流程。不少考生背了定义却答不对题，原因在于这两条流程的边界不是靠背概念就能分清的，而是要理解它们在整个IT服务管理体系中所处的层次和承担的不同使命。事件管理解决的是“现在怎么办”的问题，问题管理解决的是“为什么会这样”的问题，前者追求速度，后者追求彻底。本文从概念定义出发，逐层拆解两条流程的运行机制、流程接口和命题陷阱，并结合历年真题还原命题人的出题思路。
要准确区分事件管理与问题管理，必须先回到ITIL体系给出的标准定义。在IT服务管理最佳实践框架ITIL中，事件（Incident）指的是非计划内的服务中断、服务质量的下降，或者尚未影响到服务但已经失效的配置项。服务器宕机、应用响应时间远超约定、核心交换机的某个冗余模块告警失效，都属于典型的事件。事件管理的目标表述得非常明确：在最短的时间内恢复服务的正常级别，把对业务的影响降到最低。这里有一个关键点需要牢牢记住--事件管理关注的是症状的消除，它并不负责追究病因。一台数据库服务器发生故障，把业务切到备用节点上恢复服务，事件的使命就完成了，至于主节点为什么会故障，那是另一条流程的事情。
问题(Problem)在ITIL中的标准定义是一个或多个事件的未知根因。定义里有三个字容易被忽略--“未知”的。当一个事件的原因当场查明并且可以立即修复时，它不构成问题;只有当同类事件反复出现、或者重大事件的原因一时无法定位时，才进入问题的范畴。问题管理的目标是找出根本原因，提出永久性的解决方案或临时规避措施，从根本上防止事件再次发生。仍以数据库故障为例，如果查明是某个版本的存储引擎在特定负载下存在缺陷，那么“存储引擎缺陷”就是问题，升级版本或打补丁就是永久性解决方案，而在方案落地前先把负载分流到其他实例则属于规避措施。
与事件容易混淆的还有服务请求。服务请求是用户主动提出的、标准化的日常服务需求，比如重置密码、申请账号、申请安装软件、请求开通权限，这类请求不涉及服务中断，处理方式也高度标准化。ITIL将服务请求的履行从事件管理中剥离出来，形成独立的请求履行流程，软考命题经常把服务请求混在事件的选项里让考生辨析。
还需要掌握一个衍生概念--已知错误(Known Error)。当问题的根因已经诊断确认，并且组织已经为其制定了规避措施时，该问题就升级为已知错误，记录已知错误的数据库称为已知错误数据库(KEDB)。考生务必注意，“已知错误”不等于“已解决的问题”，它只是“已经查明且有临时对策”的状态，永久性解决方案可能仍然在变更流程中排队等待实施。理解了这个状态定义，也就理解了为什么IT服务组织会维护一份看似“没有修完”的数据库--它的价值恰恰在于，一线支持人员在受理事件时先匹配已知错误数据库，直接套用规避措施，可以大幅压缩恢复时间。
在ITIL的流程版图中，事件管理、问题管理、变更管理、发布管理、配置管理等都属于服务运营阶段的核心流程。国际标准ISO/IEC 20000同样将事件管理与问题管理列为服务管理体系必备的过程。我国软考中，信息系统管理工程师科目将这一体系作为重点考查对象，中级与高级两个层次的题目都反复出现。
事件管理的运行机制可以概括为一条有严格先后顺序的处理流水线。理解这条流水线的每一个环节，是回答流程类选择题的基础。
事件管理流程包含五个主要活动。第一步是事件的检测与记录，事件可以通过用户电话报障、服务台邮件受理、监控系统自动告警等多种渠道进入流程，凡是受理的事件都必须记录，记录内容包括事件描述、受影响配置项、报障人信息、时间戳等，不记录就意味着不可管理、不可审计。第二步是分类与初始支持，服务台按照预定义的分类规则为事件分类，并尝试用知识库中的方案进行一线处理。第三步是调查与诊断，当一线无法解决时，事件被派单到相应的技术小组，由技术人员排查故障。第四步是解决与恢复，技术人员实施解决方案，验证服务恢复。第五步是事件关闭，由服务台与用户确认问题解决后关闭事件。流程中的两个核心时间指标--响应时间与解决时间，由服务级别协议约定，直接决定事件管理的绩效考核结果。
升级机制是流程中容易被忽视但考试常考的细节。事件升级分为两类：功能升级与层级升级。功能升级指的是把事件转交给技能更高或资源更充足的技术支持组，属于横向移交;层级升级指的是把事件上报到管理层，目的是调动更多资源、调整优先级、必要时向客户通报进展，属于纵向上报。区分这两类升级，是辨析题的高频考点。
事件的优先级不是拍脑袋定的，它由两个变量共同决定：影响度与紧急度。影响度衡量事件对业务的影响程度，通常由受影响用户数量、涉及业务系统的关键程度等因素确定;紧急度衡量事件需要解决的速度，比如是否马上导致业务停摆、是否存在快速恶化的趋势。优先级等于影响度与紧急度的组合结果，它决定事件的排队顺序和目标解决时限。命题人最爱在这里设置的一个陷阱是：优先级由业务影响决定，而不是由技术复杂度决定。一台核心交易服务器进程卡死的技术原因可能很简单，但它影响全体用户，优先级必然最高;而一台测试机的复杂内核崩溃，技术上再难查，因为不影响生产业务，优先级也不高。
服务台是事件管理得以运转的组织载体。它是用户与IT服务组织之间唯一的官方接口，业界称为单一联系点。服务台承担响应呼叫请求、记录并跟踪事件、一线处理、派单转派、向用户反馈进展等职能，同时还要承担服务信息发布、供应商联络、运营任务执行、基础设施监控等工作。一线解决率是衡量服务台能力的关键指标，指在一线服务台层面直接解决、无需转派到二线的事件占比。需要特别明确的是，服务台是一个职能而非一条流程，它与事件管理流程的关系是：流程定义了做什么，服务台职能定义了由谁来做。这个概念边界在选择题中反复出现，考生务必分清职能与流程两个层次的表述。
如果说事件管理解决的是眼前恢复的问题，那么问题管理解决的是组织长期的服务质量根基。问题管理的运行机制与事件管理有着本质不同的目标函数。
问题的来源主要有四类：一是重复发生的事件，同类事件在一段时间内多次出现，往往意味着背后存在未消除的根因;二是重大事件的复盘，任何重大事件在处理完毕后都必须进行回顾分析，查明根本原因;三是主动趋势分析，通过对事件历史数据的统计分析发现异常趋势;四是供应商公告、行业预警等外部信息，比如厂商发布的产品缺陷通告。按照触发方式，问题管理分为被动型与主动型两种模式。被动型问题管理由已发生的事件驱动，是大多数组织的基础形态;主动型问题管理在事件发生之前就开展活动，通过对事件趋势、可用性数据、容量数据的分析，提前发现潜在问题并推动解决，是更高成熟度组织的特征。
问题管理流程的核心活动包括问题识别、问题记录、问题分类、问题调查与诊断、已知错误的识别与记录、解决方案的提出与实施验证、问题关闭等环节。在调查与诊断环节，常用的根因分析技术包括因果分析图，也就是鱼骨图，从人、机、料、法、环等维度系统排查原因;还包括头脑风暴、时序分析、Kepner-Tregoe决策分析等方法。当根因查明后，组织将问题标记为已知错误，写入已知错误数据库，并附上规避措施。永久性解决方案通常涉及对生产环境的改动，必须提交变更请求，经变更管理审批后实施。问题管理的产出物里，规避措施供事件管理一线人员直接使用，永久方案进入变更与发布流程落地，这就是问题管理与下游流程的接口逻辑。
两条流程的分工可以概括为：事件管理追求恢复速度，问题管理追求根因消除;事件记录是问题管理的重要输入，问题管理的成果又反哺事件管理。当一线工程师受理事件时，先检索已知错误数据库，若命中则直接套用规避措施快速恢复，恢复效率因此提升;事后问题经理分析事件记录，挖掘重复事件的规律，又可能识别出新的问题。这种双向接口构成了一个自我强化的闭环。考生在做辨析题时，可以抓住一个判据：题目描述的活动中，凡是以“尽快恢复服务”为目的的，属于事件管理;凡是以“查明原因、防止再发生”为目的的，属于问题管理。
事件管理与问题管理不可能孤立运转，它们与变更管理、发布管理、配置管理、可用性管理等流程共同构成服务运营的生态。理解这个生态中每条流程的职责边界，是软考选择题的重要得分区。
问题管理找到的永久性解决方案，凡是涉及生产环境改动的，都必须通过变更管理才能实施。变更管理流程对每一项变更进行评估、审
本篇完！