數(shù)字化轉(zhuǎn)型這個(gè)話題可謂是老生常談了，2021年我國(guó)頒布了《“十四五”規(guī)劃綱要》，將“數(shù)字化轉(zhuǎn)型”定為國(guó)家產(chǎn)業(yè)發(fā)展的重要方向。

在這樣的背景下，數(shù)字化轉(zhuǎn)型自然引起了公眾的關(guān)注，似乎大家經(jīng)常可以聽(tīng)到一些人把它掛在嘴邊，但如果此時(shí)你問(wèn)他們到底什么是數(shù)字化轉(zhuǎn)型的，得到的答案大概率會(huì)是大數(shù)據(jù)、云計(jì)算、區(qū)塊鏈、物聯(lián)網(wǎng)和人工智能之類的。其實(shí)，這些答案本身并沒(méi)有問(wèn)題，但它們僅僅是數(shù)字化轉(zhuǎn)型的技術(shù)代表。從嚴(yán)格意義上說(shuō)，數(shù)字化轉(zhuǎn)型并沒(méi)有一個(gè)清晰明確的內(nèi)容大綱。

筆者認(rèn)為，數(shù)字化轉(zhuǎn)型的核心，并非是單純的堆砌新技術(shù)，而是將業(yè)務(wù)和技術(shù)深度融合。為了能夠?qū)崿F(xiàn)這一目標(biāo)，我們就離不開(kāi)各種技術(shù)的支撐，這個(gè)時(shí)候，數(shù)字化IT就應(yīng)運(yùn)而生。講到這里，回答其實(shí)已經(jīng)有了，數(shù)字化IT和傳統(tǒng)IT最大的區(qū)別就是前者是以“業(yè)務(wù)”為導(dǎo)向，歸根結(jié)底，是以“人”為導(dǎo)向。

1. 雙態(tài)IT

隨著信息技術(shù)的深入應(yīng)用，企業(yè)業(yè)務(wù)模式從以線下為主轉(zhuǎn)變?yōu)橐跃€上為主，業(yè)務(wù)產(chǎn)品創(chuàng)新頻率提升、創(chuàng)新周期縮短、同業(yè)競(jìng)爭(zhēng)加劇，而不少企業(yè)的IT組織效能卻尚未能提升到滿足業(yè)務(wù)敏捷交付的水平，具體表現(xiàn)為：

• 工具割裂與缺失；
• 規(guī)范執(zhí)行不到位；
• 管理成本居高不下；
• 問(wèn)題信息反饋滯后等

2014年，Gartner提出了“雙模IT”的概念，實(shí)現(xiàn)傳統(tǒng)研運(yùn)模式和敏捷研運(yùn)模式的融合，在此基礎(chǔ)上，國(guó)內(nèi)企業(yè)通過(guò)結(jié)合自身市場(chǎng)情況，提出了“雙態(tài)IT”這一相近的理念，即穩(wěn)態(tài)+敏態(tài)，穩(wěn)態(tài)以業(yè)務(wù)穩(wěn)定性為核心，敏態(tài)以快速響應(yīng)市場(chǎng)變化為核心，這一理念率先得到了互聯(lián)網(wǎng)、金融等領(lǐng)域的認(rèn)可，并逐步變成大眾概念。

2. 研發(fā)域

2.1 天才第一步：敏捷開(kāi)發(fā)轉(zhuǎn)型

為了實(shí)現(xiàn)應(yīng)用的快速開(kāi)發(fā)、交付和迭代，敏捷開(kāi)發(fā)（Agile）就此誕生，其中，Scrum方法論最為大家所熟知，而以敏捷開(kāi)發(fā)為基礎(chǔ)的DevOps（Development和Operations），則是進(jìn)一步整合了研發(fā)團(tuán)隊(duì)和運(yùn)維團(tuán)隊(duì)，通過(guò)組織、流程和工具，以及自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，使得編譯構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地敏捷、頻繁和可靠。

一站式DevOps建設(shè)方法可以用“四縱四橫”來(lái)概括，橫向主要涵蓋端到端工具集成、信息資產(chǎn)流轉(zhuǎn)共享、流程融入工程平臺(tái)、能效顯示與精益改進(jìn)幾個(gè)方面的建設(shè)；縱向主要指從需求、開(kāi)發(fā)、測(cè)試到運(yùn)維各端工藝的平臺(tái)支持與規(guī)則設(shè)定，以及資源間復(fù)雜的拓?fù)潢P(guān)系構(gòu)建。

DevOps的建設(shè)可以按照五個(gè)階段去開(kāi)展：

第一階段：前后延展，打通研發(fā)工具鏈，將生產(chǎn)力的全面貫通，實(shí)現(xiàn)工程能力的自動(dòng)化，提高工程人員整體效率；

第二階段：融合對(duì)接管理流程與工程流程，使得信息盡可能以線上化的形式自動(dòng)流轉(zhuǎn)，同時(shí)保持信息一致性和合規(guī)性，便于可信追溯和安全審計(jì)；

第三階段：各端標(biāo)準(zhǔn)化，從需求、開(kāi)發(fā)、測(cè)試、運(yùn)維等環(huán)節(jié)，形成資產(chǎn)工藝標(biāo)準(zhǔn)化支撐；

第五階段：面向下一代數(shù)字化構(gòu)想，價(jià)值驅(qū)動(dòng)業(yè)務(wù)，構(gòu)建IT內(nèi)部數(shù)字化全流程貫通。

2.2 更上一層樓：從DevOps到BizDevOps

DevOps為IT組織帶來(lái)了效能提升，實(shí)現(xiàn)了其內(nèi)部從開(kāi)發(fā)測(cè)試到運(yùn)維的流程、組織和工具的重構(gòu)，并實(shí)現(xiàn)IT從“穩(wěn)態(tài)”到“敏態(tài)”的轉(zhuǎn)型，提升了IT組織應(yīng)對(duì)市場(chǎng)和業(yè)務(wù)變化的能力。但正如我們之前所說(shuō)，企業(yè)的商業(yè)價(jià)值需要更多由業(yè)務(wù)數(shù)據(jù)來(lái)驅(qū)動(dòng)，前端的業(yè)務(wù)決策、業(yè)務(wù)調(diào)整和執(zhí)行，都需要和IT實(shí)現(xiàn)以及IT運(yùn)營(yíng)數(shù)據(jù)形成更緊密的閉環(huán)。

為了更好的達(dá)成這一目標(biāo)，需要IT組織和業(yè)務(wù)部門更加深度的融合，從DevOps向業(yè)務(wù)端進(jìn)行擴(kuò)展，引入業(yè)務(wù)部門的角色，甚至是產(chǎn)品的最終用戶，允許這些角色在最初期進(jìn)行參與，更有效地統(tǒng)一業(yè)務(wù)需求和IT實(shí)現(xiàn)，在敏捷的基礎(chǔ)上更好實(shí)現(xiàn)方向的正確性；另一方面，在敏捷化的環(huán)境下，業(yè)務(wù)需求、IT應(yīng)用的變更往往是細(xì)粒度而頻繁發(fā)生的，通過(guò)業(yè)務(wù)部門在全流程的參與可以更有效的從業(yè)務(wù)整體視角進(jìn)行全局管控及決策。

3. 運(yùn)維域

3.1 傳統(tǒng)運(yùn)維之痛：運(yùn)維是塊磚，哪用往哪搬

IT運(yùn)維管理即ITOM（IT Operation Management），是指采用專業(yè)的信息技術(shù)和方法，對(duì)軟硬件環(huán)境、網(wǎng)絡(luò)、應(yīng)用系統(tǒng)及運(yùn)維服務(wù)流程等進(jìn)行綜合管理。在傳統(tǒng)模式下，作為業(yè)務(wù)支撐的運(yùn)維團(tuán)隊(duì)，首先需要做的就是保障系統(tǒng)的穩(wěn)定、安全和可靠。因此，相關(guān)人員更關(guān)注可用性指標(biāo)（MTTR、MTTF、MTB等）、可靠性指標(biāo)（RTO、RPO）和安全合規(guī)性，強(qiáng)調(diào)建設(shè)，避免變化，并往往采用“被動(dòng)維持”的工作模式。

通常而言，運(yùn)維的能力建設(shè)主要涵蓋組織、流程和工具三個(gè)方面。在傳統(tǒng)的ITOM建設(shè)中，能夠真正實(shí)現(xiàn)數(shù)字化的工作內(nèi)容并不多，除了分散建設(shè)的監(jiān)控告警系統(tǒng)和不充分利用的CMDB，就是主要用來(lái)維穩(wěn)管控的ITSM，然而隨著技術(shù)的發(fā)展和業(yè)務(wù)模式的變化，傳統(tǒng)模式已經(jīng)有些力不從心，開(kāi)始顯現(xiàn)諸多問(wèn)題：

① 運(yùn)維工具煙囪式建設(shè)：運(yùn)維工具多為解決某一單一運(yùn)維管理場(chǎng)景需求，工具間相互獨(dú)立，導(dǎo)致存在大量的數(shù)據(jù)孤島，同時(shí)造成部分功能的重復(fù)建設(shè)，即使部分運(yùn)維工具能夠通過(guò)定制開(kāi)發(fā)的形式和彼此實(shí)現(xiàn)互通，但后續(xù)的維護(hù)和擴(kuò)展仍然面臨挑戰(zhàn)；

② 自動(dòng)化運(yùn)維能力不足：一些運(yùn)維團(tuán)隊(duì)至今仍嚴(yán)重依賴手工完成發(fā)布上線、系統(tǒng)巡檢等重復(fù)性工作，占用大量的人力資源成本；

③ 流程化程度低：一些運(yùn)維團(tuán)隊(duì)的運(yùn)維工作主要集中在人工的方式，導(dǎo)致運(yùn)維數(shù)據(jù)離散嚴(yán)重。由于缺少統(tǒng)一的流程管理系統(tǒng)，難以將各團(tuán)隊(duì)的運(yùn)維工作進(jìn)行有效串聯(lián)，致使信息失真、溝通成本高的現(xiàn)象普遍存在；

④ 數(shù)據(jù)化運(yùn)營(yíng)程度低：日常的運(yùn)維工作往往沉淀了大量的運(yùn)維數(shù)據(jù)，但很少被充分挖掘利用。很多運(yùn)維工作依然以人工觸發(fā)為主，缺乏數(shù)據(jù)化觸發(fā)手段；同時(shí)，傳統(tǒng)大數(shù)據(jù)平臺(tái)使用門檻過(guò)高，無(wú)法適合運(yùn)維數(shù)據(jù)場(chǎng)景需求。

3.2 好馬配好鞍，敏捷運(yùn)維轉(zhuǎn)型

和研發(fā)管理一樣，IT運(yùn)維同樣需要敏捷轉(zhuǎn)型，其核心同樣也同樣是以“業(yè)務(wù)驅(qū)動(dòng)”為導(dǎo)向。敏捷轉(zhuǎn)型的第一步是理念的轉(zhuǎn)型，需要領(lǐng)導(dǎo)層的重視和自上而下的推進(jìn)，畢竟沒(méi)有人喜歡主動(dòng)改變熟悉的環(huán)境。

萬(wàn)事開(kāi)頭難，有了思想的轉(zhuǎn)變，接下來(lái)就是著手具體的建設(shè)任務(wù)，其內(nèi)容同樣包含了組織、流程和工具三方面的建設(shè)，也就是我們常說(shuō)的PPT或PPTR模型。

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

需要注意的是，不同階段的建設(shè)并不是按部就班的，每個(gè)階段都可能涉及到不同管理實(shí)踐建設(shè)，我們需要結(jié)合自身情況選擇不同側(cè)重點(diǎn)。

敏態(tài)運(yùn)維的建設(shè)可以按照四個(gè)階段去開(kāi)展：

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

4. 總結(jié)

說(shuō)了這么多，總結(jié)起來(lái)，數(shù)字化IT的關(guān)鍵無(wú)非是兩點(diǎn)。

第一點(diǎn)是堅(jiān)持以“業(yè)務(wù)驅(qū)動(dòng)”為導(dǎo)向，IT人員作為技術(shù)出身，重視技術(shù)，這無(wú)可厚非，但I(xiàn)T技術(shù)的本質(zhì)是實(shí)現(xiàn)業(yè)務(wù)價(jià)值的手段，而并非目的。我們需要做的，不僅僅是滿足業(yè)務(wù)部門的響應(yīng)，而是能夠幫助業(yè)務(wù)實(shí)現(xiàn)轉(zhuǎn)型和進(jìn)步，甚至是為業(yè)務(wù)決策帶來(lái)指導(dǎo)性意見(jiàn)。

第二點(diǎn)是“具體問(wèn)題，具體對(duì)待”。盡管敏態(tài)IT模式為企業(yè)業(yè)務(wù)價(jià)值的實(shí)現(xiàn)帶來(lái)了幫助，但這并不意味著它可以適用一切，我們還需要結(jié)合實(shí)際情況進(jìn)行落地，這也是我們?yōu)槭裁葱枰半p態(tài)IT”的原因之一。同樣，在IT建設(shè)的過(guò)程中，不同階段的建設(shè)要做什么，怎么做，并沒(méi)有一個(gè)統(tǒng)一的標(biāo)準(zhǔn)方案。