全新ITIL（第五版）Foundation中文版于2026年4月23日正式发布，安言咨询的顾问团队di1时间带来新版本ITIL的专业解读，today要为大家解读的管理实践是问题管理。

在ITIL v5 Foundation实践体系中，问题管理已经不再只是传统意义上的根因分析（RCA）和故障复盘，而是围绕问题识别、已知错误管理、技术债务治理以及组织知识积累建立的一套持续预防机制。其he心目标，是通过发现和消除潜在风险，减少重复故障发生，让组织逐步从“被动救火”走向“主动预防”。

一、实践目的-ITIL

问题管理的he心目标，是通过识别事件发生的实际原因和潜在原因，并管理临时解决方案（Workaround）与已知错误（Known Error），从而降低事件发生的概率以及对业务造成的影响。

顾问解读

很多企业做了多年运维，事件处理能力越来越强，但故障总量却没有明显下降。一个数据库连接池满了，重启解决；过几天又满了，再重启。应用卡顿了，扩容解决；业务增长后又开始卡顿。团队每天都在解决问题，却很少有时间去思考问题为什么发生。问题管理存在的意义，就是让组织从“解决症状”转向“解决病因”，让同样的问题不再反复出现。

二、实现目标的关键要求-ITIL

组织需要：

• 识别并理解问题及其对服务产生的影响

• 持续优化问题的解决与缓解能力

顾问解读

很多运维团队都有一种无力感：故障处理了一堆，但总觉得没有真正进步。原因往往是团队关注的是事件，而不是问题。事件解决的是当下，问题解决的是未来。比如一台服务器频繁宕机，事件管理关注的是尽快恢复；问题管理关注的是为什么频繁宕机，是硬件老化、容量不足还是架构设计缺陷。只有找到背后的原因，服务质量才可能真正改善。

三、he心流程-ITIL

1. 主动式问题识别

包括：提交信息评审→ 问题登记→ 初步问题分类与分派

主动式问题识别强调通过趋势分析、监控数据、容量分析、风险分析等方式，在事件发生之前发现潜在问题。

2. 被动式问题识别

包括：问题登记→ 初步问题分类与分派

被动式问题识别通常来源于重大事件、重复事件或业务投诉。

3. 问题控制

包括：问题调查→ 已知错误沟通

这一阶段的目标是寻找根本原因，并及时将调查结果共享给相关团队。

4. 错误控制

包括：制定问题解决方案→ 发起问题解决→ 已知错误监控与评审→ 问题关闭这一阶段重点关注问题彻底消除以及长期跟踪验证。

顾问解读

现实中的问题管理，很少是一开始就知道答案的。很多时候是某个故障连续发生三次、五次之后，大家才意识到这不是偶然。于是开始收集日志、分析趋势、召开专题会，慢慢把隐藏在表象背后的根因找出来。问题管理流程看起来简单，但真正考验的是组织能不能从海量事件中识别规律，把“偶发事件”变成“可管理的问题”。

四、实践成功建议-ITIL

• 尽早建立问题记录机制，并确保由合适人员负责

• 问题管理需要采用蜂群协作（Swarming）模式，而非依赖单个问题经理

• 根据业务价值对问题进行优先级排序，并建立重点问题清单

• 虽然问题管理没有SLA要求，但其finally目标是提升服务质量

• 重视用户和客户反馈

• 在条件允许的情况下积极应用AI与自动化能力

顾问解读

很多企业的问题管理last流于形式，不是因为不会分析，而是因为没有坚持。问题单开了很多，根因分析报告写了一堆，但last没人推动解决。时间久了，大家就把问题管理当成了文档工作。实际上，真正有效的问题管理一定要和业务价值挂钩。那些影响客户体验、影响收入、影响he心业务的问题，应该优先投入资源解决，而不是平均用力。

五、关键指标-ITIL

问题管理通常关注以下指标：

• 尚未形成已知错误记录的事件数量

• 已识别的问题数量

• 需要紧急开展问题调查的事件数量

• 因问题解决而避免再次发生的事件数量

• 通过问题调查得到解决的事件数量

• 当前开放状态的已知错误数量

顾问解读

问题管理尤其怕的一件事，就是把自己变成“统计管理”。统计了多少问题、多少已知错误、多少分析报告，看起来数据很好看，但业务故障一点没少。一个成熟团队更关心的是：重复故障是不是减少了？客户投诉是不是下降了？因为问题解决而避免的故障是不是越来越多？真正有价值的指标，finally都应该能够反映到业务稳定性和客户感知上。

六、支撑工具-ITIL

问题管理常见支撑工具包括：

• 监控与事件管理工具

• 工作流与协同管理工具

• 知识管理工具

• CMDB配置管理数据库工具

• 数据分析与报表工具

顾问解读

很多企业买了监控平台、工单系统、CMDB、知识库，last问题分析还是靠几个老员工翻日志。工具本身并不会自动产生问题管理能力。真正重要的是这些工具之间能不能形成关联。一次故障发生后，监控数据、配置数据、历史事件、知识库经验能不能快速串起来。如果做不到，问题调查还是会停留在“靠经验”和“靠运气”的阶段。

七、关键角色-ITIL

关键角色包括：

问题经理负责：

• 问题管理机制建设

• 问题调查组织协调

• 根因分析推动

• 已知错误管理

• 问题关闭审批

问题协调员负责：

• 跟踪问题处理进展

• 协调相关技术团队

• 推动问题解决方案落地

• 组织问题评审活动

顾问解读

问题经理这个岗位听起来很像管理岗位，但现实里往往更像一个“组织协调者”。因为绝大多数问题都不是一个团队能解决的。一个he心交易系统故障，可能涉及开发、运维、数据库、中间件、网络多个团队。问题经理真正的价值，不是自己会多少技术，而是能够把不同团队拉到一起，共同找到问题根因，并推动解决方案真正落地。

八、关键术语-ITIL

1. Problem（问题）

一个或多个事件的实际原因或潜在原因。

问题并不一定已经引发事件，但未来可能导致事件发生。

2. Workaround（临时解决方案）

在问题尚未彻底解决之前，用于降低或消除事件或问题影响的临时性措施。

例如：

• 重启服务

• 切换备用节点

• 人工处理业务

都属于典型的Workaround。

3. Known Error（已知错误）

已经完成分析、明确原因，但尚未彻底解决的问题。

例如：

已确认某软件版本存在缺陷，但升级方案尚未实施。

此时该问题即被记录为Known Error。

4. Technical Debt（技术债务）

由于采用临时解决方案而非长期系统性解决方案所积累的待处理工作和风险。

例如：

为了快速恢复业务：

• 跳过架构优化

• 长期使用脚本修补

• 持续依赖人工操作

这些行为都会不断积累技术债务。

5. Problem Model（问题模型）

针对某一类问题建立的标准化处理方法和处理路径。

例如：

数据库连接池耗尽问题处理模型；

应用服务器内存泄漏问题处理模型；

网络链路抖动问题处理模型。

通过建立问题模型，可以提高问题调查和解决效率。

顾问解读

很多企业比较大的风险，不是故障，而是技术债务。today为了赶上线，先绕过去；明天为了不影响业务，再绕一次。几年之后，系统里到处都是临时方案和历史包袱。很多重大故障其实不是突然发生的，而是技术债务积累到一定程度后的集中爆发。所以ITIL为什么强调Workaround、Known Error和Technical Debt？因为它提醒组织：临时方案可以救急，但不能永远代替真正的解决方案。

九、实践he心理解-ITIL

在很多ITIL实践里，问题管理往往是一个容易被忽视的实践。相比于事件管理，问题管理很难在短时间内体现价值。系统故障了，业务受到影响了，大家都能直观感受到事件处理的重要性；但问题管理做得好不好，往往需要几个月甚至更长时间才能看到效果。

这也是为什么很多企业在资源紧张的时候，首先压缩的往往是问题分析、根因调查和长期整改工作，而把更多精力投入到故障响应和事件处理上。

从短期来看，这种做法似乎没有问题。业务恢复了，系统运行了，用户投诉减少了。但随着时间推移，企业会逐渐发现一些现象：

• 同样类型的故障不断重复发生；

• 同一个系统每隔几个月就会出现类似问题；

• 运维团队越来越忙，但系统稳定性却没有明显改善；

• 很多经验只能依赖少数he心人员掌握。

这些现象背后，本质上都反映出组织缺少持续发现问题、分析问题和解决问题的能力。

在实际咨询项目中，我们经常会看到一种情况：客户建立了较完善的事件管理机制，监控体系、工单体系、值班机制都比较成熟，但故障数量始终无法有效下降。深入分析之后会发现，大量时间都花在处理已经发生的事件上，而真正用于分析根因和推动长期整改的时间却非常有限。

从这个角度来分析，事件管理和问题管理实际上是在解决两个不同层面的问题。事件管理关注的是如何尽快恢复服务，减少业务影响；而问题管理关注的是为什么会发生，以及如何避免再次发生。

一个成熟的运维组织，不*要具备快速恢复服务的能力，更需要具备持续消除风险源头的能力。因为真正影响系统长期稳定运行的，往往不是某一次故障，而是长期存在却始终没有得到解决的问题。

随着企业数字化程度越来越高，系统之间的依赖关系越来越复杂，技术架构越来越庞大，单纯依靠经验和人工排查已经越来越难支撑持续稳定运行。问题管理的重要性，也正在从传统运维领域逐步延伸到架构治理、技术债务治理、数据治理以及数字化治理等更广fan的领域。

从这个意义上讲，问题管理不*only是一种运维实践，更是一种组织持续改进能力的体现。它帮助企业把一次次故障积累的经验转化为组织知识，把一次次临时处置转化为长期优化，把被动应对风险逐步转变为主动预防风险。

对于数字化时代的企业来说，减少一次故障固然重要，但比减少一次故障更重要的，是让同样的问题不再反复发生。

Q1：为什么很多企业做了根因分析，但同样的问题还是反复发生？

A：这是很多企业都遇到过的问题。故障发生后，团队召开复盘会，编写根因分析报告，提出整改措施，看起来整个流程都做完了。但过了一段时间，类似的问题又出现了。

问题往往不在于没有分析，而在于分析停留在表面。

例如：

• 操作失误

• 配置错误

• 代码缺陷

这些通常只是直接原因，而不是根本原因。继续往下追问：为什么会出现操作失误？为什么配置能够未经审核直接上线？为什么测试阶段没有发现缺陷？

很多时候，真正的问题其实隐藏在流程设计、组织协同、技术架构或者管理机制之中。

所以问题管理真正重要的，不是写一份根因分析报告，而是推动问题真正被解决。

Q2：为什么很多企业的问题管理last变成了技术团队自己的事情？

A：这是一个非常典型的误区。现实中很多问题的根因并不完全来自技术。

例如：

• 需求变更频繁

• 上线周期过短

• 资源投入不足

• 供应商管理不到位

这些问题往往涉及：

• 业务部门

• 项目管理部门

• 开发团队

• 运维团队

• 外部合作伙伴

如果问题管理始终局限在技术团队内部，那么很多真正的根因其实根本无法解决。

问题管理本质上是组织治理活动，而不*only是技术活动。

Q3：问题管理和持续改进到底是什么关系？

A：很多人觉得这两个实践很像。实际上，两者关注点并不相同。

很多企业的问题管理做得不好，并不是因为不会分析，而是因为缺少持续改进机制去推动落实。

数智安全 关注安言