ITIL4發布到現在也就5年多時間，按照以往的更新節奏，ITIL5最早也得2027年之后。但現在IT發展的速度，跟以前完全不是一個量級。AI都快把我們的飯碗搶了（開個玩笑），ITIL要是還按部就班，估計真要被時代拋棄了。

最近行業里確實有不少關于ITIL5的討論，雖然官方還沒有任何消息，但從目前IT服務管理面臨的挑戰來看，下一代框架的輪廓已經若隱若現了。

當前ITIL4的局限性越來越明顯

怎么說呢，ITIL4在2019年發布時確實很先進，引入了價值流、服務價值系統這些概念。但這幾年下來，很多企業在落地時都遇到了新問題。

我們公司去年引入AIOps平臺后，傳統的事件管理流程基本形同虛設。以前一個告警要折騰半天才能定位問題，現在AI直接給你分析出根因，還能預測潛在風險。70%的運維工作都自動化了，但新問題也來了：AI給的建議到底聽不聽？出了問題算誰的？這些ITIL4里可沒說清楚。

還有個更現實的問題。現在業務部門自己用低代碼平臺開發應用，根本不走IT部門的變更流程。一個金融行業的朋友跟我抱怨，他們公司業務部門自己搞的小應用有200多個，IT部門"管都管不住"。ITIL4的變更使能（Change Enablement）在這種場景下，基本就是個擺設。

AI原生將成為核心設計理念

基于這兩年的實踐，我覺得ITIL5肯定會把AI作為核心要素來設計，而不是像現在這樣只是個補充。

比如說，事件管理可能不再是"人工分級-派單-處理"這個流程了，而是"AI預測-自動修復-人工驗證"。我們公司現在就在試點這個模式，大概有60%的常見故障都能自動處理。運維同事終于可以不用半夜爬起來處理磁盤空間告警了。

但這里有個坑。上個月我們的AI系統誤判了一個情況，自動重啟了一個核心服務，結果影響了200多個用戶。雖然只持續了3分鐘，但業務部門還是炸了鍋。所以說，AI再厲害，人的判斷和兜底機制還是不能少。ITIL5估計會花很大篇幅來講人機協作的邊界和原則。

問題管理也會發生根本性變化。現在我們用機器學習分析歷史數據，能提前發現80%的潛在問題。傳統的"事后分析"模式正在向"事前預防"轉變。這個轉變說起來簡單，但對組織能力的要求完全不一樣。你得有數據分析能力，得懂算法，還得能說服業務部門相信你的預測。

業務和IT的邊界將徹底消失

"現在哪還分什么業務和IT啊，業務就是IT，IT就是業務。"這是一個零售行業CIO的原話，我覺得特別有道理。

ITIL5可能會徹底打破IT服務管理的邊界。不是說IT部門為業務部門提供服務，而是大家一起創造價值。我們公司最近在推行"業務運維一體化"，每個產品線都有運維人員embedded進去。他們不僅要保障系統穩定，還要參與產品設計，提供技術視角的建議。

效果還不錯，至少產品上線后的問題少了一半。但說實話，這對IT人員的要求太高了。你不僅要懂技術，還要懂業務，甚至要懂一點產品設計。培養這樣的人才，沒個三五年下不來。

生態協同將取代供應商管理

現在企業用的系統，十有八九都不是自己從頭開發的。我們公司光是第三方服務就有40多個，SaaS、PaaS、各種API，怎么管？ITIL4的多供應商管理（SIAM）理論上挺完美，實際操作起來累死人。

每個供應商都有自己的SLA，出了問題互相推諉。上個季度我們有個核心系統宕機，涉及3個供應商，光是定位問題歸屬就花了2個小時。等問題解決，半天過去了。

ITIL5估計會更強調生態協同。不是你管理供應商，而是大家形成一個生態，共同為客戶創造價值。這個月我們剛跟幾個核心供應商建立了聯合運維機制，建了個共享的監控平臺，出問題大家一起上，不分彼此。當然，這需要很強的信任基礎，商務條款也要重新設計。

敏捷和DevOps將成為默認模式

ITIL4雖然提到了敏捷和DevOps，但還是把它們當作"可選項"。但現在你看，哪個互聯網公司不是DevOps？哪個產品團隊不跑敏捷？

ITIL5大概率會把敏捷和DevOps作為默認模式。變更管理不再是層層審批，而是自動化管道加風險控制。我們現在的做法是，低風險變更走自動化管道，5分鐘內完成部署；高風險變更才走傳統流程。這樣下來，85%的變更都能當天完成。

但這里面的挑戰在于，怎么定義"低風險"？我們花了3個月時間，分析了2000多個歷史變更，才建立起一個相對靠譜的風險評估模型。而且這個模型還在不斷調整，因為業務在變，技術在變，風險特征也在變。

寫在最后

說到底，ITIL只是個工具，關鍵還是看怎么用。我見過太多企業，花大價錢實施ITIL，最后流程是有了，效率反而降低了。為啥？因為光有流程沒用，人的思維不轉變，文化不改變，再好的框架也是擺設。

ITIL5什么時候來，會是什么樣，說實話誰也說不準。但有一點可以肯定：未來的IT服務管理一定會更加智能、更加敏捷、更加以人為本。與其等ITIL5，不如現在就開始探索和實踐。