是否只有實現了容器化、自動編排等等才算是實現了運維自動化？

何為資料中心的自動化運維？很多人把 DevOps與運維自動化緊綁，認為只有實現了容器化，只有實現了自動編排等等才算是實現了運維的自動化。且不說有多少企業可以完全實現這種IT轉型，就概念本身而言，我覺得這也是一種不太合乎邏輯的思維。我們來看Gartner對運維自動化的理解“透過運維工具或平臺，實現IT基礎設施及業務應用日常任務處理和運維流程的自動化，從而提高效率和降低風險，促進運維組織的成熟和各種能力的升級”。從傳統企業資料中心運維工程師角度來看，所謂自動化運維，即在最少的人工干預下，結合運用指令碼與第三方工具，保證業務系統7*24小時高效穩定執行。所以，筆者認為最接地氣的運維自動化即為在企業資料中心原有IT基礎架構條件下，能夠實現IT資源標準化定義，並且實現運維資料採集、加工、分析的自動化流程，最終能保障IT運維的及時性和效率化的建設體系。

2. 運維自動化框架

首先，我們先來從企業資料中心運維發展的歷史階段來分析運維自動化。從很多傳統企業來看，尤其是金融企業的資料中心，大部分已經經歷了三個階段：

（1）復運維工作精簡化的階段，利用標準統一的工作流來避免重複的人力工作；

（2）區域性運維工作自動化的階段，在不同的系統上部署針對不同物件的指令碼來收集處理運維資料；

（3）IT運維平臺整合自動化的階段，平臺實現IT基礎架構的半自動化運維。

總結以上歷史階段的發展過程，運維自動化的最初目的是為了提高效率和準確率的基礎之上減少人力成本投入。運維具體工作內容包括：日常監控任務中的日誌配置、資料採集、報警過濾等；日常運維任務當中的 指令碼執行、系統安裝、配置備份、配置檢查、配置變更、補丁分發 等；作業排程 中的 應用釋出流程、應用部署流程、變更流程、故障處理、災備切換、資源交付等 。那麼，要實現對以上所有工作內容的自動化整合需要經歷以下三個步驟的建設：

首先，實現標準化是實現自動化的前提條件，因為自動化的工作流是必須要在標準化的基礎之上才能實現識別、判斷、處理等相關動作。標準化又包括資源定義的標準化、工作流程的標準化以及資料的標準化；然後，需要選擇資料採集的工具和方式，因為所有的自動化動作都是基於資料判斷的基礎上採取的後續步驟；最後需要對採集來的資料進行加工處理以及最終的分析和決策，這裡麵包括常規性的決策、為後續採取動作需做的評估和預警、需要根據資料變化及時做出的動態調整等。

3. 資料標準化體系建設

3.1 資源標準化

所謂資源的標準化，涉及到的資源主要包括裝置、系統、軟體等三類物件資源 。

針對物理裝置的標準化，首先，我們需要做到對物理裝置的資產定義標準化。例如：對裝置的命名、地址、位置、配置、引數、管理等一系列屬性資訊的定義需要有統一規劃標準。不一定是一個標準，但是一定要建立一系列標準模板。其次，我們需要對物理裝置的規劃使用設定標準。例如：裝置的網路配置、遠端控制、儲存配置等方面的配置使用標準。最後，我們需要對裝置使用設定運維管理標準。例如：裝置當中的硬體環境 的報警閥值規則定義。

針對系統層面的標準化，首先，與物理裝置類似的資產定義標準化。例如：作業系統的主機名稱、型別、版本等相關資產屬性資訊的標準化定義。其次，關於系統的標準化配置管理。例如：作業系統的初始化配置（地址、閘道器、掩碼、DNS、NTP、核心引數調優、日誌、儲存使用、Agent）。最後，我們需要對作業系統設定運維監控標準。例如：CPU使用率、記憶體使用率、硬碟使用率、IO延時、網路狀況、程式指標、執行時間等。一方面需要確定運維監控的指標，另外一方面需要確定每一個指標或者指標組合的閥值預警判定規則。

針對軟體（主要是指系統上執行的資料庫及應用中介軟體）層面的標準化，首先，我們需要對應用中介軟體的使用進行標準化管理。例如：資料庫的型別和版本、同類中介軟體的型別和版本。其次，需要對所有軟體的初始化以及配置使用進行標準化管理。例如：軟體安裝配置規範、配置檔案規範、配置指令碼規範、日誌收集規範、埠監聽規範等。最後，我們同樣需要對軟體的運維監控設定標準。也就是需要監控的軟體服務指標體系，以此來判斷軟體提供的服務的正常與否以及效能如何。

3.2 流程標準化

所謂流程標準化就是指在資料中心運維管理過程當中涉及到的日常工作流程的標準化管理。如果沒有工作流程的標準化規範，那麼所有的運維工作就會變成隨機性流程，這樣的流程是沒有辦法利用指令碼或者軟體工具來實現自動化的。具體說來，資料中心運維工作流程的標準化需要做到以下幾個方面：

（1） 資源管理流程：包括軟硬體資源的申請、審批、提供、銷燬等；

（2） 資源初始化流程：包括作業系統、資料庫、中介軟體、應用等方面的初始化配置工作；

（3） 資源動態管理流程：包括資源在使用過程中根據監控資料進行動態調整的各類流程；

（4） 事件處理流程：包括預警、報警、常規事件、常規故障的標準處理流程；

（5） 監控管理流程：包括監控資料收集、加工、報送、分析、處理等各環節的處理方法及步驟；

（6） 應急處理流程：預定義的系列應急處理流程，例如：流量限制、容災切換。

3.3 資料標準化

很多做運維平臺的廠家到了客戶現場進行調研的時候都會發現一個非常頭痛的問題 。客戶實際環境當中的軟體、硬體、應用等各方面的日誌資料會呈現出很多形態。既有加密日誌（日誌表現形式為程式碼，需要根據程式碼查詢日誌解釋說明才能定位問題的日誌）也有非加密日誌；既有欄位形式表示的也有不加任何分割的文字串表示的，而且內容表示的方式也是各有千秋；既有文字檔案也有壓縮包或者其他非文字檔案形式；既有儲存在資料庫的又有儲存在目錄當中的。總而言之，運維資料從形態、內容、載體等各個方面都沒有經過標準化規範，最終導致運維平臺可做的工作非常有限。

要實現運維自動化，資料是前提條件，沒有資料的支撐就不會有後續的預警、報警以及與之相匹配的自動化運維處理過程。因此在系統、中介軟體、應用上線之前的設計階段， IT運維的標準化規範就應該輸入到規劃設計當中。

4. 資料收集手段和工具的使用

4.1 指令碼工具

很多人覺得談指令碼有點落伍，應該談一些高大上的自動化運維整合工具或者產品。其實看到本質上，任何自動化運維平臺底層都是靠一些指令碼去完成具體工作的，只不過是選取的指令碼根據不同的運維任務在型別、定義、執行方式等方面會有所區別。拋開上層管理整合平臺，聚焦到指令碼本身來看的話，指令碼工具在自動化運維過程當中應該在以下幾個方面發揮作用：

（1） 資料收集：從很多企業的運維來看，大家都會部署一些指令碼來收集硬體、系統、軟體等各維度的運維資訊，有些是基於實時執行結果的收集，有些是基於一定週期內的日誌檔案內容；

（2） 資料加工：面對大量的原始日誌資訊，相信依靠人力去完成價值資訊的提煉是比較耗費時間的，這個時候就需要指令碼基於已經收集的原始日誌資訊進行重複加工，最終提煉價值資訊。

（ 3 ）任務流程處理：所謂任務處理就是要根據預定義的一些需求輸入資料，串聯或者並聯一些工作步驟，從而完成一個完整的運維任務工作流程，例如：系統初始化、軟體安裝、資源擴充套件；

4.2 工具使用

首先，多數實現運維自動化的思維是選擇一個大而全的產品，然後讓這個產品滲透到運維工作的各個維度，從而實現整體的自動化。但是結果往往差強人意，你選擇的產品最終沒有辦法與你現有的環境非常融洽的相處，所謂的自動化只是一個區域性而已。所以，筆者認為真正落地的思路是先選擇設計好運維工作每一個角落的指令碼工具，然後再考慮上層的管理整合。

其次，當我們在聚焦於某一個資料採集環節或者某一個運維工作任務的工具的時候，要考慮到工具本身的擴充套件性以及互動性。比如 Shell和Python，大多數資料採集的工具都是用Shell實現的，無論從效率上還是從與系統的融洽度角度來考慮，它都是最佳選擇。但是某些需要人機互動的自動化任務就只能靠Python了，比如輸入登入資訊這個操作。

再次，從運維管理整體的整合角度，我們需要考慮到頂層運維工作和底層運維任務的整合邏輯。完整的運維工作解耦分解之後就是一個個聚焦到有限動作的運維任務，但是這些運維任務要組成一個完整的運維工作流是需要嚴密的判斷邏輯和控制機制的。

5. 運維資料分析及自動化決策

運維自動化與監控自動化最大的區別就在於是否有後續的動作 。當我們把所有的運維資料都採集完成並且按照既定邏輯進行加工處理之後，就下來就是價值資訊的提取和有效動作的實施。

什麼是價值資訊的提取呢？舉個例子：比如我們想看儲存裝置的負載是否正常，是否需要調整資源配置？傳統模式下，工程師需要收集儲存上的各種效能日誌（埠效能、儲存控制器 CPU及快取、儲存卷的IO效能、吞吐量等等 ），而且是需要收集一定週期內的均值和峰值資料。然後綜合判斷之後，決策需要調整資源或者無需調整。如果是自動化運維，我們就需要把工程師如何分析和判斷的邏輯以及經驗設計到指令碼當中。邏輯可以提煉成演算法，經驗可以提煉為歷史資料的機率演算法。

什麼是有效動作的實施呢？舉個例子：比如大多數金融企業都會面臨的購物刷卡的特殊節日或者時間段，如果是可預知的情況，很多相關的工程師會提前值守，應用工程師實時觀察應用處理業務的情況， IT工程師觀察計算、網路、儲存等各類資源的使用情況，一旦監控出現異常情況，IT工程師會把提前準備好的相關伺服器資源安裝配置好應用之後丟進資源池，這是通常的應急處理方法。如果是自動化運維，我們就需要把工程師對應用、系統、網路等各方面實時監控到的資訊進行判斷的邏輯進行標準固化，同時需要將準備資源、初始化資源、分配資源以及對外提供服務的一系列操作進行指令碼化。

6. 結語

總結而言，運維自動化是企業IT運維追求的重要目標。實現運維自動化的前提條件在於標準化，保障運維自動化質量的關鍵在於運維資料的利用，落地運維自動化專案的思路在於從下往上的設計思路。