ITSM/ITIL有一个非常重要而且和日常运维关系非常非常密切，但是在我们实践中往往用不好就是问题管理。从我这么多年的实践中确实是这样，发现用的好的，往往是和应用运维和开发关系结合的非常密切。在桌面服务、应用运维、基础架构和基础设施运维几块运维工作来看，应用运维在用好问题管理，是有很多工作可以做的，也是最容易发挥价值的一块，也是实施ITSM的难点之一，做好了应用运维的问题管理也就做好了问题管理，会是项目的亮点之一，因为它有四个非常重要的价值。

问题管理流程是确定某一事件或具有相同症状的一组事件的根本原因，制定和实施解决方案，从而防止事件再次发生的管理流程。其目的是找出事件根本原因，尽可能的给出解决方案或者临时应对措施。目标是降低生产环境中事件发生的数量和严重程度，从而为企业建立一个稳定的 IT 环境，提高 IT 服务的可用性。这里涉及到二个核心的概念：问题和已知错误。

问题（Problem）：多个有相同现象的事件或一个重大的事件，并且存在某个未知原因的错误的情况。

已知错误（Known Error）：已经成功诊断问题的根源，找到解决方案的情况。

一个问题有几个触发条件，或者说有哪几个应用场景呢？有以下几个：

（1）同一个事件反复发生。这就意味着之前的事件的解决可能只是临时解决，没有找到根本原因、解决方案。

（2）同一个现象多次发生。这类就是可能是同一个系统、同一类设备，其现象相同或者相似。

（3）重大事件发生。这类往往对业务产生了重大影响，这类事件可能在事件中已经临时、应急处理了，需要通过问题管理追查发生的根本原因和解决方案。也有可能从根本上从技术层面根本上解决了，但是要从流程、制度、管理上去找原因，为什么不可以避免。

（4）一切由临时解决方案解决的事件。比如说“万能的重启”解决的事件、直接修改异常数据解决的事件等等。

（5）因为巡检等发现的未知根本原因的潜在问题和重大风险。这类可以直接触发问题去解决，已经发生的故障的，应该通过事件首先处理。

运维服务的工作，大致上可以分为桌面服务、应用运维、基础架构运维和基础设施运维等。这几块容易把问题用好的是桌面服务和应用运维。对于基础架构和基础设施，我的建议是一个重大事件、一个是巡检做好，作为问题的两个输入即可，这个其实比较好落地，但是在问题管理中应用不是主流。如果是就太麻烦了，比如数据中心基础设施和IT基础设施总是出问题不可想象，一般不太会。

桌面运维的事件其实比较多的，但是往往容易应急，处于救火的模式，往往是服务请求和简单的支持居多。另外，也主要集中在服务台和一线运维少数人，所以把事件升级为问题来处理的动力和意愿不不太强烈。所以我建议是，更多的由服务台主管和事件经理尽可能多的做一些趋势分析，主动的问题管理。把第一类（同一事件）和第二类（同一类现象的事件）做实，并在周报和运维报告中体现出来。

对于应用运维，其重要性不言而喻，因为都是业务系统。我经常开玩笑说，花几千万几个亿做ERP，花几十万一两百万上一套永服科技的ITSM把SAP/ERP、CRM这些核心系统运维好支持好还是非常值得的。应用系统的问题，除了日常的服务请求之外，真正意义的故障，还是很难快速解决的。所以我的一个建议是，除了把IT部门的开发部门给服务台做好足够的赋能做好日常的支持之外，可以把开发部门的支持团队作为事件管理的三线的基础上，把开发纳入到问题管理。前面是在组织层面上，在技术层面同时把ITSM的问题管理和开发的相关系统对接，比如说和开发的缺陷系统、需求管理系统对接，永服科技这这方面的实践非常多，比如我们CQ平台，和JIRA、禅道都对接过，也有一些只记录缺陷号的。

所有的应用系统的缺陷，都纳入问题管理，并实现和开发系统联动。这样其实有四个好处：

这样把开发和运维两个部门拉通。避免大部分的开发游离在IT服务管理的大的框架之外，做好开发和运维的融合，这样更多的好处就不用多说了，例如在客观上会提升应用的可用性。

流程拉通和事件的闭环，变更管理也有了一个好的输入。缺陷解决了，在问题管理管理，直接发生RFC就很自然了。这样也就实现了从事件到问题，从问题到变更的有机衔接，做好了应用系统的事件的闭环。

提升了业务部门的满意度。从永服科技的在众多大型组织的IT服务管理咨询和ITSM项目落地的实践中，也确实看到研发人员的IT服务意识的是不够的，与服务台和运维部门的差距挺大的。

有利于ITSM项目在整个组织推广。传统的上，研发往往认为IT服务管理系统是运维部门的事情，参与感和参与的意愿不强。

我曾见过一个电商和供应链领域的客户的CEO对问题和SLA非常关注，每周四下午固定的问题分析会，就是组织相关人分析应用系统的问题，每个问题都要找根本原因和解决方案，都有SLA。让我非常感动，觉得这个客户应也应该非常有前途，永服科技的ServiceJet-ITSM也能帮到他们。

从我在多年的实践中，看问题管理用的好，都有上述特点，也就是把研发纳入了问题管理，客观上也做好了应用运维，不管是银行客户还是大型的企业客户，都是如此。

问题管理的KPI见下表：

————————————————