ITSM/ITIL有一個非常重要而且和日常運維關(guān)系非常非常密切，但是在我們實踐中往往用不好就是問題管理。從我這么多年的實踐中確實是這樣，發(fā)現(xiàn)用的好的，往往是和應(yīng)用運維和開發(fā)關(guān)系結(jié)合的非常密切。在桌面服務(wù)、應(yīng)用運維、基礎(chǔ)架構(gòu)和基礎(chǔ)設(shè)施運維幾塊運維工作來看，應(yīng)用運維在用好問題管理，是有很多工作可以做的，也是最容易發(fā)揮價值的一塊，也是實施ITSM的難點之一，做好了應(yīng)用運維的問題管理也就做好了問題管理，會是項目的亮點之一，因為它有四個非常重要的價值。

問題管理流程是確定某一事件或具有相同癥狀的一組事件的根本原因，制定和實施解決方案，從而防止事件再次發(fā)生的管理流程。其目的是找出事件根本原因，盡可能的給出解決方案或者臨時應(yīng)對措施。目標(biāo)是降低生產(chǎn)環(huán)境中事件發(fā)生的數(shù)量和嚴(yán)重程度，從而為企業(yè)建立一個穩(wěn)定的 IT 環(huán)境，提高 IT 服務(wù)的可用性。這里涉及到二個核心的概念：問題和已知錯誤。

問題（Problem）：多個有相同現(xiàn)象的事件或一個重大的事件，并且存在某個未知原因的錯誤的情況。

已知錯誤（Known Error）：已經(jīng)成功診斷問題的根源，找到解決方案的情況。

一個問題有幾個觸發(fā)條件，或者說有哪幾個應(yīng)用場景呢？有以下幾個：

（1）同一個事件反復(fù)發(fā)生。這就意味著之前的事件的解決可能只是臨時解決，沒有找到根本原因、解決方案。

（2）同一個現(xiàn)象多次發(fā)生。這類就是可能是同一個系統(tǒng)、同一類設(shè)備，其現(xiàn)象相同或者相似。

（3）重大事件發(fā)生。這類往往對業(yè)務(wù)產(chǎn)生了重大影響，這類事件可能在事件中已經(jīng)臨時、應(yīng)急處理了，需要通過問題管理追查發(fā)生的根本原因和解決方案。也有可能從根本上從技術(shù)層面根本上解決了，但是要從流程、制度、管理上去找原因，為什么不可以避免。

（4）一切由臨時解決方案解決的事件。比如說“萬能的重啟”解決的事件、直接修改異常數(shù)據(jù)解決的事件等等。

（5）因為巡檢等發(fā)現(xiàn)的未知根本原因的潛在問題和重大風(fēng)險。這類可以直接觸發(fā)問題去解決，已經(jīng)發(fā)生的故障的，應(yīng)該通過事件首先處理。

運維服務(wù)的工作，大致上可以分為桌面服務(wù)、應(yīng)用運維、基礎(chǔ)架構(gòu)運維和基礎(chǔ)設(shè)施運維等。這幾塊容易把問題用好的是桌面服務(wù)和應(yīng)用運維。對于基礎(chǔ)架構(gòu)和基礎(chǔ)設(shè)施，我的建議是一個重大事件、一個是巡檢做好，作為問題的兩個輸入即可，這個其實比較好落地，但是在問題管理中應(yīng)用不是主流。如果是就太麻煩了，比如數(shù)據(jù)中心基礎(chǔ)設(shè)施和IT基礎(chǔ)設(shè)施總是出問題不可想象，一般不太會。

桌面運維的事件其實比較多的，但是往往容易應(yīng)急，處于救火的模式，往往是服務(wù)請求和簡單的支持居多。另外，也主要集中在服務(wù)臺和一線運維少數(shù)人，所以把事件升級為問題來處理的動力和意愿不不太強烈。所以我建議是，更多的由服務(wù)臺主管和事件經(jīng)理盡可能多的做一些趨勢分析，主動的問題管理。把第一類（同一事件）和第二類（同一類現(xiàn)象的事件）做實，并在周報和運維報告中體現(xiàn)出來。

對于應(yīng)用運維，其重要性不言而喻，因為都是業(yè)務(wù)系統(tǒng)。我經(jīng)常開玩笑說，花幾千萬幾個億做ERP，花幾十萬一兩百萬上一套永服科技的ITSM把SAP/ERP、CRM這些核心系統(tǒng)運維好支持好還是非常值得的。應(yīng)用系統(tǒng)的問題，除了日常的服務(wù)請求之外，真正意義的故障，還是很難快速解決的。所以我的一個建議是，除了把IT部門的開發(fā)部門給服務(wù)臺做好足夠的賦能做好日常的支持之外，可以把開發(fā)部門的支持團隊作為事件管理的三線的基礎(chǔ)上，把開發(fā)納入到問題管理。前面是在組織層面上，在技術(shù)層面同時把ITSM的問題管理和開發(fā)的相關(guān)系統(tǒng)對接，比如說和開發(fā)的缺陷系統(tǒng)、需求管理系統(tǒng)對接，永服科技這這方面的實踐非常多，比如我們CQ平臺，和JIRA、禪道都對接過，也有一些只記錄缺陷號的。

所有的應(yīng)用系統(tǒng)的缺陷，都納入問題管理，并實現(xiàn)和開發(fā)系統(tǒng)聯(lián)動。這樣其實有四個好處：

這樣把開發(fā)和運維兩個部門拉通。避免大部分的開發(fā)游離在IT服務(wù)管理的大的框架之外，做好開發(fā)和運維的融合，這樣更多的好處就不用多說了，例如在客觀上會提升應(yīng)用的可用性。

流程拉通和事件的閉環(huán)，變更管理也有了一個好的輸入。缺陷解決了，在問題管理管理，直接發(fā)生RFC就很自然了。這樣也就實現(xiàn)了從事件到問題，從問題到變更的有機銜接，做好了應(yīng)用系統(tǒng)的事件的閉環(huán)。

提升了業(yè)務(wù)部門的滿意度。從永服科技的在眾多大型組織的IT服務(wù)管理咨詢和ITSM項目落地的實踐中，也確實看到研發(fā)人員的IT服務(wù)意識的是不夠的，與服務(wù)臺和運維部門的差距挺大的。

有利于ITSM項目在整個組織推廣。傳統(tǒng)的上，研發(fā)往往認為IT服務(wù)管理系統(tǒng)是運維部門的事情，參與感和參與的意愿不強。

我曾見過一個電商和供應(yīng)鏈領(lǐng)域的客戶的CEO對問題和SLA非常關(guān)注，每周四下午固定的問題分析會，就是組織相關(guān)人分析應(yīng)用系統(tǒng)的問題，每個問題都要找根本原因和解決方案，都有SLA。讓我非常感動，覺得這個客戶應(yīng)也應(yīng)該非常有前途，永服科技的ServiceJet-ITSM也能幫到他們。

從我在多年的實踐中，看問題管理用的好，都有上述特點，也就是把研發(fā)納入了問題管理，客觀上也做好了應(yīng)用運維，不管是銀行客戶還是大型的企業(yè)客戶，都是如此。

問題管理的KPI見下表：

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