數字化轉型這個話題可謂是老生常談了，2021年我國頒布了《“十四五”規劃綱要》，將“數字化轉型”定為國家產業發展的重要方向。

在這樣的背景下，數字化轉型自然引起了公眾的關注，似乎大家經常可以聽到一些人把它掛在嘴邊，但如果此時你問他們到底什么是數字化轉型的，得到的答案大概率會是大數據、云計算、區塊鏈、物聯網和人工智能之類的。其實，這些答案本身并沒有問題，但它們僅僅是數字化轉型的技術代表。從嚴格意義上說，數字化轉型并沒有一個清晰明確的內容大綱。

筆者認為，數字化轉型的核心，并非是單純的堆砌新技術，而是將業務和技術深度融合。為了能夠實現這一目標，我們就離不開各種技術的支撐，這個時候，數字化IT就應運而生。講到這里，回答其實已經有了，數字化IT和傳統IT最大的區別就是前者是以“業務”為導向，歸根結底，是以“人”為導向。

1. 雙態IT

隨著信息技術的深入應用，企業業務模式從以線下為主轉變為以線上為主，業務產品創新頻率提升、創新周期縮短、同業競爭加劇，而不少企業的IT組織效能卻尚未能提升到滿足業務敏捷交付的水平，具體表現為：

• 工具割裂與缺失；
• 規范執行不到位；
• 管理成本居高不下；
• 問題信息反饋滯后等

2014年，Gartner提出了“雙模IT”的概念，實現傳統研運模式和敏捷研運模式的融合，在此基礎上，國內企業通過結合自身市場情況，提出了“雙態IT”這一相近的理念，即穩態+敏態，穩態以業務穩定性為核心，敏態以快速響應市場變化為核心，這一理念率先得到了互聯網、金融等領域的認可，并逐步變成大眾概念。

2. 研發域

2.1 天才第一步：敏捷開發轉型

為了實現應用的快速開發、交付和迭代，敏捷開發（Agile）就此誕生，其中，Scrum方法論最為大家所熟知，而以敏捷開發為基礎的DevOps（Development和Operations），則是進一步整合了研發團隊和運維團隊，通過組織、流程和工具，以及自動化“軟件交付”和“架構變更”的流程，使得編譯構建、測試、發布軟件能夠更加地敏捷、頻繁和可靠。

一站式DevOps建設方法可以用“四縱四橫”來概括，橫向主要涵蓋端到端工具集成、信息資產流轉共享、流程融入工程平臺、能效顯示與精益改進幾個方面的建設；縱向主要指從需求、開發、測試到運維各端工藝的平臺支持與規則設定，以及資源間復雜的拓撲關系構建。

DevOps的建設可以按照五個階段去開展：

第一階段：前后延展，打通研發工具鏈，將生產力的全面貫通，實現工程能力的自動化，提高工程人員整體效率；

第二階段：融合對接管理流程與工程流程，使得信息盡可能以線上化的形式自動流轉，同時保持信息一致性和合規性，便于可信追溯和安全審計；

第三階段：各端標準化，從需求、開發、測試、運維等環節，形成資產工藝標準化支撐；

第五階段：面向下一代數字化構想，價值驅動業務，構建IT內部數字化全流程貫通。

2.2 更上一層樓：從DevOps到BizDevOps

DevOps為IT組織帶來了效能提升，實現了其內部從開發測試到運維的流程、組織和工具的重構，并實現IT從“穩態”到“敏態”的轉型，提升了IT組織應對市場和業務變化的能力。但正如我們之前所說，企業的商業價值需要更多由業務數據來驅動，前端的業務決策、業務調整和執行，都需要和IT實現以及IT運營數據形成更緊密的閉環。

為了更好的達成這一目標，需要IT組織和業務部門更加深度的融合，從DevOps向業務端進行擴展，引入業務部門的角色，甚至是產品的最終用戶，允許這些角色在最初期進行參與，更有效地統一業務需求和IT實現，在敏捷的基礎上更好實現方向的正確性；另一方面，在敏捷化的環境下，業務需求、IT應用的變更往往是細粒度而頻繁發生的，通過業務部門在全流程的參與可以更有效的從業務整體視角進行全局管控及決策。

3. 運維域

3.1 傳統運維之痛：運維是塊磚，哪用往哪搬

IT運維管理即ITOM（IT Operation Management），是指采用專業的信息技術和方法，對軟硬件環境、網絡、應用系統及運維服務流程等進行綜合管理。在傳統模式下，作為業務支撐的運維團隊，首先需要做的就是保障系統的穩定、安全和可靠。因此，相關人員更關注可用性指標（MTTR、MTTF、MTB等）、可靠性指標（RTO、RPO）和安全合規性，強調建設，避免變化，并往往采用“被動維持”的工作模式。

通常而言，運維的能力建設主要涵蓋組織、流程和工具三個方面。在傳統的ITOM建設中，能夠真正實現數字化的工作內容并不多，除了分散建設的監控告警系統和不充分利用的CMDB，就是主要用來維穩管控的ITSM，然而隨著技術的發展和業務模式的變化，傳統模式已經有些力不從心，開始顯現諸多問題：

① 運維工具煙囪式建設：運維工具多為解決某一單一運維管理場景需求，工具間相互獨立，導致存在大量的數據孤島，同時造成部分功能的重復建設，即使部分運維工具能夠通過定制開發的形式和彼此實現互通，但后續的維護和擴展仍然面臨挑戰；

② 自動化運維能力不足：一些運維團隊至今仍嚴重依賴手工完成發布上線、系統巡檢等重復性工作，占用大量的人力資源成本；

③ 流程化程度低：一些運維團隊的運維工作主要集中在人工的方式，導致運維數據離散嚴重。由于缺少統一的流程管理系統，難以將各團隊的運維工作進行有效串聯，致使信息失真、溝通成本高的現象普遍存在；

④ 數據化運營程度低：日常的運維工作往往沉淀了大量的運維數據，但很少被充分挖掘利用。很多運維工作依然以人工觸發為主，缺乏數據化觸發手段；同時，傳統大數據平臺使用門檻過高，無法適合運維數據場景需求。

3.2 好馬配好鞍，敏捷運維轉型

和研發管理一樣，IT運維同樣需要敏捷轉型，其核心同樣也同樣是以“業務驅動”為導向。敏捷轉型的第一步是理念的轉型，需要領導層的重視和自上而下的推進，畢竟沒有人喜歡主動改變熟悉的環境。

萬事開頭難，有了思想的轉變，接下來就是著手具體的建設任務，其內容同樣包含了組織、流程和工具三方面的建設，也就是我們常說的PPT或PPTR模型。

• 人員組織：組織建設的原則是為企業目標負責，在規劃設計時，需要以企業的戰略為頂層依據，綜合考慮對各利益相關方的影響，根據服務列表（如對內業務、對外業務）等規則劃分組織架構、崗位和職責，并以此為基礎設計考核體系，最后通過和工具、流程的不斷磨合，持續做出優化調整。
• 管理流程：流程設計要為效率負責，其建立的過程需要經過調研分析、概要設計、詳細設計、線上化試驗和線上化運行等多個環節，同組織的建立一樣，管理流程也是一個需要持續優化的過程。
• 技術工具：工具作為運維工作的支撐，其建設原則是將日常的運維工作盡可能流程化、自動化和線上化。在規劃設計時，我們通常可以考慮RASO（Role、Scene、Activity、Object）模型，即什么角色，在什么場景下，完成什么活動，涉及什么對象。

需要注意的是，不同階段的建設并不是按部就班的，每個階段都可能涉及到不同管理實踐建設，我們需要結合自身情況選擇不同側重點。

敏態運維的建設可以按照四個階段去開展：

• 第一階段（“流程標準”階段）：以事件為驅動，圍繞MTTR改善運維工作，仍以被動響應式的工作方式為主，是傳統IT運維的典型表現。該階段的建設重點是打好基礎，全力保障系統的穩定運行，因此我們通常考慮建設統一的監控告警體系和基礎的IT服務管理體系，如事件、問題和服務請求流程；
• 第二階段（“主動管理”階段）：“主動管理”階段是向敏態運維轉型的重要節點，其側重點從“如何快速處理故障”向“如何減少故障”轉變，同時，運維團隊也需要和開發團隊/ISV服務商開展更緊密的合作。在該階段的建設中，我們可以考慮建立應急團隊和規劃團隊，設計變更管理、配置管理和容量管理等流程，并著手于建立一定的故障處置自動化能力，提升故障的處置效率。
• 第三階段（“持續改進”階段）：在保障業務連續性的基礎上，為滿足業務敏捷迭代的需求，IT組織需要全面協作，通過精益、敏捷、DevOps等理念，打破部門墻，為業務的全面敏捷負責。為了能夠實現真正意義上的敏捷，我們可以引入“應用運維團隊”的概念，圍繞應用構建運維工具及管理實踐，保障應用可觀測性和可靠性。
• 第四階段（“價值導向”階段）：在IT運維管理實踐足夠成熟，且通過工程化建設有效較少IT團隊的日常瑣事的前提下，運維團隊可進一步進行價值運營，通過運維中臺和企業服務平臺的建設，進行企業內部的“數字化工作空間”打造任務，比如，基于流程梳理和能力集中，實現非IT領域（HR、財務、管理）等的服務構建和運營。

4. 總結

說了這么多，總結起來，數字化IT的關鍵無非是兩點。

第一點是堅持以“業務驅動”為導向，IT人員作為技術出身，重視技術，這無可厚非，但IT技術的本質是實現業務價值的手段，而并非目的。我們需要做的，不僅僅是滿足業務部門的響應，而是能夠幫助業務實現轉型和進步，甚至是為業務決策帶來指導性意見。

第二點是“具體問題，具體對待”。盡管敏態IT模式為企業業務價值的實現帶來了幫助，但這并不意味著它可以適用一切，我們還需要結合實際情況進行落地，這也是我們為什么需要“雙態IT”的原因之一。同樣，在IT建設的過程中，不同階段的建設要做什么，怎么做，并沒有一個統一的標準方案。