“休斯敦，我們遇到問題了”，這是來自科學和技術界最偉大的語錄之一。

然而從技術上來說，當他們用無線電告知在休斯敦的任務控制臺時，阿波羅13號的工作人員應該說：“我們遇到了事故”，因為問題是事故表面下的未知原因。

事故是任何不屬于標準服務運轉部分的事件，能引起或是可能造成服務中斷或是服務質量下降。謝天謝地，像任何組織良好的項目一樣，休斯敦擁有一個中止計劃，再加上宇航員們的足智多謀，他們最終能夠平安地返回地面。

這是一起事故或危機管理的典型案例，目的是盡可能快地恢復服務運轉的正常狀態，從而將對運行的不利影響降至最低。擁有到位的事故管理計劃以及應急響應團隊來確保處理任何事故，應該成為任何組織的標準慣例。無論是天災人禍、惡意攻擊或是員工的疏忽，都應該被快速地處理，從而可以繼續正常的服務。事故是每天業務生活的一部分，應該有幫助臺（help desk）或IT支持人員來處理不太嚴重的問題，并有緊急響應團隊來處理重大的事故。但是，究竟有多少組織擁有問題管理團隊呢？

問題的定義是某個或多個事故的未知原因，問題管理流程涉及到判斷此類事故表面下的原因，然后找到一個永久的解決方案。它不同于事件管理，因為它的關注點在于問題的解決而不是事件本身的響應速度，以防止它惡化成事件。

在阿波羅13號甲板上的事故引起了細致的調查以便判斷問題的根源。然后用這方面的知識，以確保在未來的任務中問題不會再出現。這種類型的事件后分析可以起到至關重要的作用，確保企業網絡運營保持不間斷高效運行。沒有它，宕機時間會延長，并且時間和金錢可能會浪費在處理重復的事故上。

讓我們舉個簡單的例子來突出事件管理和問題管理間的差異：某個出問題的網絡文件服務器無法讓雇員們訪問他們的文檔。事件響應團隊可能僅是重啟服務器以便快速地恢復訪問。問題響應團隊則會找到讓服務器宕機的原因，以便能修正并防止問題再次發生（請注意，問題管理不同于吸取經驗教訓的工作，后者是評審事故是如何處理的，看是否能改善未來事故的處理）。

盡管問題解決和事件響應是有關聯的，但它們不一定要求同樣的技能，因此參與到這兩個流程的人員也是不同的。一些人可能知道如何恢復最近一次的數據庫備份，但是不了解造成數據庫崩潰的首要原因是什么。問題解決更加傾向于取證和追溯發生了什么引發了事件，而事件管理要求關于如何恢復一個系統的更具有可操作性的知識。

問題通?？捎芍蠖鄠€有類似癥狀的事故辨識——例如跨整個網絡的電腦病毒傳播并影響它們的性能——或者是從有重要影響的單個事故來辨識的，比如前面提到的情況：沒人能訪問某個特殊服務器上的文件。

一旦成功地診斷出事故表面下的原因，它就成了“已知錯誤”，隨后的任務就是找到一個合適的變通方法或永久的解決方案。變通方法應該只用于將問題的影響最小化，直到找到永久的解決方案，并且問題應該歸為已知的錯誤。

辨識問題根本原因的技術之一是使用因果圖（Ishikawa diagram，也叫“魚骨圖”），是用來映射事件起因的工具。潛在的原因通常被歸類如人、流程、策略、硬件、軟件和環境，在這些類中，任何來源的變化都能幫助找出問題的原因所在。其它技術如阿波羅根源分析方法（Apollo Root Cause Analysis）也能用來辨識原因和尋找解決方案。

盡管問題管理與事故管理是緊密關聯的，但是在需要快速的解決事故和需要找到問題長期的解決方案間，兩者可能有沖突。還是用前面的例子，立刻重啟文件服務器可能破壞有用的診斷信息來辨識問題的原因。解決這個沖突的方法之一，是事先達成一致需要什么診斷信息，在恢復服務前允許的診斷時間，以及試圖解決該問題會需要的那些必要資源。

問題管理的主動性方法是努力在事故發生前辨識和解決問題。這涉及到對日志報告和幫助臺請求的趨勢分析，接著是相關的新聞組用來對別處發生的問題進行提前預警，以及針對的支持行動。

問題管理流程目的是減少業務中事故和問題的次數、嚴重性和惡劣影響，并且預防與這些錯誤相關的事故再次發生。團隊的成功可以很容易地監控問題診斷和解決的平均時間、重復問題的發生次數、以及重大事故的發生次數，并以此來衡量。擁有到位的問題管理流程會幫助任何組織減少重復的事故發生，并通往更為可靠的網絡和應用環境之路。