ITSM问题管理中存在的问题

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

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

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

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

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

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

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

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

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

本文摘要节选自来源于

https://www.itsmcn.com/qitazhishi/704.html