企業數字化轉型，科技先行。國際知名咨詢機構如麥肯錫、埃森哲、IDC、IBM等，都在解讀數字化定義時提及智能化運營。但要實現智能化，我們還有很長的路要走。

運維部門作為企業科技部門的一部分，在信息化時代的今天，所承受的壓力日益漸增。傳統的運維模式越來越難以適應業務和IT架構的擴張，運維團隊需要尋求突破，來跟上企業變化的步伐。通常來說，企業的運維管理體系分為規范化運維、自動化運維、敏捷化運維和智能化運維四個階段，其中規范化運維到自動化運維的過渡階段是大多數企業所在階段。

隨著近年全球運維大會的火熱舉辦，自動化運維話題被推向了前所未有地熱度。自動化運維并不是炒作的概念，而是隨著信息技術發展的必要趨勢。“大數據”、“容器”、“DevOps”、“微服務”……，不斷涌現的新技術都有共同的特點，大大增加了運維管理的操作單元數量的同時對系統可用性有更高的可用性要求。從IBM、BMC、HP等傳統廠商各類工具產品紛紛面市到Puppet、Ansible、Saltstack等開源解決方案風起云涌，自動化運維已經勢不可擋。

01. 自動化運維的定義

什么是自動化運維？很多人嘗試給自動化運維下定義，“數據中心自動化（DCA）”、“開發運營一體化（DevOps）”……，始終無法形成被統一認可的概念。這里筆者對Gartner對自動運維的定義進一步引深：“通過運維工具或平臺，實現IT基礎設施及業務應用日常任務處理和運維流程的自動化，從而提高效率和降低風險，促進運維組織的成熟和各種能力的升級”，其中：

• 日常任務處理包括：設備發現、腳本執行、操作系統安裝、配置備份、配置檢查、配置變更、補丁分析和分發、作業調度等。
• 運維流程包括：應用發布流程、應用部署流程、變更流程、故障處理流程、災備切換流程、資源交付流程等。
• 能力升級包括：變化適應能力、風險應對能力、合規遵從能力、業務運營能力、事件應對能力等。

自動化運維并不是孤立建設和運行的，筆者認為自動化運維是ITOM中的一部分，如下圖。

“自動化”、“配置管理”、“監控” 是運維管理建設的三駕馬車，三者之間即相互獨立，也相互聯系。筆者在走訪很多企業交流過程中，很多人認為這三者之間存在著依賴關系，一定要先落地其中一個才能建設另外一個。這種理解不能說錯，只是三者的建設路徑其實并沒有嚴格的先后順序，最好的做法的共同建設，共同迭代。

02. 自動化運維的分類

我們常聽到面向業務的監控或者面向應用的監控，筆者認為自動化也是一樣的，可以區分為“面向基礎架構的自動化”、“面向應用的自動化”、“面向業務的自動化”。三個分類既有一定的關聯性，也是相互獨立的，有著各自的目標和場景。

① 面向基礎架構的自動化

這里基礎架構主要指的是IASS和PAAS這兩層。面向基礎架構的自動化運維是相對比較容易落地建設的，往往自動化運維也是從基礎架構這個類別開始建設的。這個類別的自動化建設的主要目標是解放運維人員的工作量，如把運維工作中的日常巡檢、補丁管理、資源創建等內容實現自動化、自助化。

② 面向應用的自動化

顧名思義面向應用的自動化的對象就是以應用為單位，應用中包含了各類的基礎架構資源。然而面向應用的自動化并不依賴于基礎架構自動化完全落地之后才能建設，在筆者為某單位落地自動化運維時，邁出的第一步就是核心應用系統的更新部署自動化，當時還沒有任何基礎架構層面的自動化。當然也不是說應用的自動化完全不依賴基礎架構，如自動縮擴容、自動部署與配置等對基礎架構的自動化程度有較強的依賴性。

③ 面向業務的自動化

面向業務的自動化是IT自動化的最終目標，歸結到底IT還是為業務提供服務。如果能夠將IT自動化建設與業務關聯起來，IT服務的價值也能很好的體現出來。當然，面向業務的自動化也有非常高的建設難度，對業務流程、業務關聯性的系統化梳理往往不是IT部門能夠獨立完成的。

很多企業都在探索自動化運維應該怎樣開展，目前仍然沒有形成相對權威的自動化運維建設路線圖。筆者結合“面向基礎架構的自動化”、“面向應用的自動化”、“面向業務的自動化”的理念，以及過往的項目經驗，斗膽嘗試為自動化運維總結一個成熟度模型，如下圖。這個層級圖表達了一種迭代建設的理念：每部分內容建設都不是一蹴而就的，各部分內容建設也不是強依賴關系。同時筆者認為自動運維的建設的初期應該從下面兩點出發：

• 優先考慮可以立即產生影響的工具，如那些解決重復性工作或冗余性的自動化工具；
• 衡量自動化應該關注：提高維護效率、降低風險或提高敏捷性。

03. 自動化運維的組織模式

很多公司都在招聘或培養DevOps工程師，組建自己的自動化運維團隊，每家企業的組織思路都不一樣。回歸本質思考自動化運維并不神秘，與ERP、OA、監控一樣都是一套軟件系統，同樣存在“需求提出者”、“軟件開發者”、“最終使用者”，將這三者由誰去扮演是自動化運維組織模式的關鍵。筆者借鑒工行侯志榮《一體化和自動化運維體系探索》一文中的觀點，在企業自動化運維建設的組織模式，大致有如下幾種情形：

① 組織模式一：分散式

由各領域、各部門根據需求自行建設，“需求提出者”、“軟件開發者”、“最終使用者”都是同一組人。這種自給自足的建設方式沒有統一規劃，可能使用不同的技術站，也會出現重復建設。很難形成合力，各自為營的局面往往會產生維護成本高，也可能會帶來生產系統穩定性風險。

② 組織模式二：集中式

這是一種中央集權的組織方式，獨立組織一組人員投入自動化運維建設，其他團隊作為需求提出者提出需求。這種模式可以統一規劃和設計，也相對更專業。但集中式的組織模式不容易調動其他團隊的積極性，繁雜的運維需求很難準確收集，無法快速應對不斷變化的運維需求。

③ 組織模式三：平臺式

這種模式綜合了分散式和集中式的特點，組織一個團隊負責自動化基礎平臺建設，各域、各部門根據需求自行在平臺上開發工具。既可以發揮多方的積極性，又可以形成統一的合力，較好兼顧了個性和共性。但這種平臺式的組織模式對平臺本身的建設提出了極高的要求，平臺本身要求能夠提供統一架構、統一認證、統一調用，并且實現自動化工具的敏捷和快速迭代。

平臺式的組織模式對技術平臺的基礎功能和核心框架要求之高，讓很多企業望而卻步，苦于難以找到合適的技術平臺，自研開發又極不現實。嘉為藍鯨數據中心運維自動化解決方案，是基于強大的騰訊藍鯨PaaS平臺，通過作業平臺（作業執行能力）、配置平臺（CMDB）、管控平臺（海量接入管控）、集成平臺（開放與集成能力）、標準運維（靈活調度編排引擎）等能力，幫助企業實現從資源交付上線、巡檢維護、日常變更及批量操作、安全管理等各種自動化運維的場景。