前言

我給中小型運維團隊的定義是整個團隊人數（所有運維工程師 + 運維開發工程師）為 20 人以下，一般這樣的團隊，能為自動化投入的資源也許就 1、2 個開發人員。

BAT 等大公司的 DevOps 平臺功能涵蓋的範圍非常全面而且各種高大上，這麼龐大的體系對於中小型運維團隊，要靠手頭頂多 2 名運維開發工程師來實現落地就懵了，不知該從何入手。所以往往大部分中小型運維團隊要麼傳統人肉運維黑路走到底，要麼指望公司咬牙上 DevOps 商業服務。

然而，僅靠購買商業服務也未必能完全解決問題，主要原因有：

1 . 歷史專案成本考慮：商業平臺不支援個性化，歷史專案未必能直接對接商業平臺，需要通過運維與業務側均重構以適應商業平臺，對接成本甚至高於自建平臺，且要高速執行的業務側停下配合也並不靠譜；

2 . 商業機密資料的考慮：商業平臺會儲存運維 / 部分業務相關資料，這對於安全要求較高的行業來說，自建平臺的可控度更高；

然而，中小型公司的自建平臺大多都算是重複造輪子，雖然各家業務情況各異，但也有可以抽象成可複用的架構體系，這也是商業自動化平臺的價值所在，如果團隊是 10 人以下且沒專職開發人員再且業務技術歷史債務不重的情況下，選擇商業服務也不失為明智之舉。

我們經常看到各種大廠的自動化平臺一般包含且不限於以下內容：CMDB、配置中心、管控平臺、資料平臺、CI/CD、作業平臺、容器管理、擴容縮容、輔助運營、監控中心 等等，各種高大上詞彙讓人目不暇接。

由於中小型團隊的用人成本必須控制得極其精確，一般不會有太多人力資源投入到自動化平臺的開發，所以必須找出最核心功能，以達到快速落地投入生產環節使用為目的。我們不可能對上述功能點面面俱到，這樣只會讓自己無從下手。

其實最核心的功能模組只有兩個：CMDB（配置平臺）和作業平臺。我們作為中小型的運維團隊，其實能把這兩部分完成即可滿足 80% 的業務需求，在此基礎上，再根據自身業務需求再考慮開發其他高階擴充套件功能如 CI/CD、資料分析、業務監控、輔助運營等。

專案背景

需求驅動導向，大家也不會因為上線一個小專案就招人做自動化平臺，在什麼情況下我們才需要做自動化平臺呢？

去年，隨著手遊專案的發展，公司業務需求處於一個飛速增長的階段，在短時間內已經發展到將近數十個專案（含各種渠道、平臺、分割槽），業務形態各異，包括頁遊、手遊、站點、app 等，這樣眾多的專案運維管理成本非常高，傳統的運維管理方式很難高效率、高質量地管理和把控如此多的產品和專案。

隨著虛擬化、雲、微服務等技術的發展，再加上有眾多的雲服務提供商（阿里雲、騰訊雲、UCloud 等），應用程式的底層執行環境愈發多樣化，各種運維物件都需要通過一個平臺進行統一的操作和管理。

為了應對以上問題並高質量完成運維保障服務，我們必須做到：

• 通過平臺統一管理所有運維物件，對專案組、對運維部門的所有操作都程式固化；
• 實現所有專案的持續整合、自動化部署、專案組自助操作以提升釋出效率和降低故障率；
• 有一個完善的配置中心為所有運維自動化的底層資料和配置基礎，驅動所有運維指令碼、工具、元件正常執行；

如何達成目標

明確了目標之後，你會發現這三個目標正好對應三個運維術語：標準化、流程規範化和 CMDB。

• 標準化：從主機名、IP、作業系統、檔案目錄、指令碼等一系列運維物件都制定標準規範，業務部門和運維部門都遵守同一套標準，基於這套標準去建設統一的平臺。
• 流程規範化：主要是涉及 程式檔案打包、開發測試線上環境管理、釋出流程 等多部門協作的規範，必須落實到程式固化或者文件固化，打造 Dev 和 Ops 之間的標準交付環境。
• CMDB：這是一切運維自動化體系建設的基石，其它如配置管理、作業執行、資產管理等需要基於 CMDB 才能形成體系，構建完善的運維物件生命週期和操作閉環。

標準化  

標準化包含的範疇非常多，從最簡單的作業系統版本、主機名、IP 段、系統帳號密碼到軟體安裝的目錄、引數、配置檔案等等，也許不同的公司有其特有習慣和歷史遺留，所以這個沒有一個全業界的統一模式。

現在只需要把貴司的習慣用文件的形式固化下來，再徹底檢查生產環境的情況是否滿足規範所述，不滿足則按規範操作。

對於歷史不是太悠久的專案要修正不會太困難，如果連這點都嫌麻煩的話，也不用談什麼運維自動化了。

簡單畫個思維導圖，標準化的範疇主要包含但不限於以下內容：

流程規範化

流程規範化是在建立了標準化之後，為了規範運維內部以及與外部門合作的一系列複雜事件的細節做法，比如要釋出新版本、上線新專案、業務擴容縮容等。

這一部分不太容易展開，因為不同公司有自己的做法和習慣，無論是怎樣做，請用文件規範和約束各部門人員的行為，這樣才能方便程式化和自動化，不然程式就要寫多很多 if-else 語句或者需要配置化來相容各種不規範情況，徒增開發人力消耗。

CMDB  

不用贅述，CMDB 的設計肯定是運維自動化建設的重中之重，設計好的話，運維平臺的開發可以有事半功倍的效果。

CMDB（Configuration Management Database）配置管理資料庫，是記錄所有運維物件資訊的資料庫，所有運維流程需要基於 CMDB 的資料進行操作，形成操作閉環，操作的結果會反饋到 CMDB 中。

此係統提供了一整套介面介面與其它任何需要資訊的系統進行對接，這也是設計初衷，將資訊從一個統一的、標準的源頭輸出給各垂直或水平業務功能系統，而運維需要做的就是維護 CMDB 本身基礎資料的完整性、準確性，CMDB 與各流程系統、垂直功能系統結合之後實現資訊資料一處變更，處處同步。

一個機器下架的操作：

傳統方式：通過 SSH 登入到該機器，關閉所有業務程式，關機，在控制列表刪除該 IP，下架，登入資源管理系統刪除該機器資訊。

自動化方式：在 CMDB 中編輯其狀態，系統自動呼叫底層工具關閉服務、關機，並自動將機器資訊在 CMDB 中更新狀態

區別： 傳統方式各個步驟都是非原子性，每一步都可能有錯漏的問題，如忘記刪除控制列表 IP 或者忘記更新資源管理系統資訊，運維流程無法達到操作閉環。而真正的自動化方式是應該需要達到操作閉環，無需人工干預。

如何設計

CMDB 的設計有一個最大的誤區是想建立一個大而全的屬性表，恨不得想把全部運維物件的全部屬性都找出來，比如：

從零散的運維物件來拼湊 CMDB 基本都是吃力不討好的，因為這樣的設計方式根本沒有從業務出發。

而真正能解決業務問題的 CMDB 必須回到業務上面來，從核心的三層關係開始組建 CMDB，這三層概念從大到小分別是：業務、叢集、模組（遊戲行業術語一般叫專案、分割槽、服務）

設計思路應該是這樣的，我所運維一個業務，它有哪些叢集？叢集下有哪些模組？模組下有哪些機器？機器有哪些屬性？各種屬性之間有什麼關聯關係？

通過這樣的思維方式慢慢把真正的 CMDB 組織起來……

當然，運維物件遠不止那麼少，還需要大家根據自家業務多多挖掘，這個過程比較艱辛，但不需要一步到位，先確定好核心物件，再慢慢完善補充其他物件。

配置項屬性

我們把 CMDB 的某個物件稱為配置項，一個典型的配置項如一臺主機、一個域名、一個 IP 。

舉個例子，一臺主機，其屬性獲取的三種方式：

• agent 獲得：如 cpu、memery、disk、ethX 之類的硬體資訊，一般用 python psutil 模組可以獲取大部分所需要的屬性；
• 雲服務商 api：有部分屬性不能通過 agent 獲得的如 EIP、Region、Zone 等，如果不是用雲主機的就不需要這一部分；
• 手工維護：有些屬性不能自動獲取，只能通過人工錄入，不過這類屬性還是儘量越少越好；

由點到面可以看出，配置項的屬性類別基本可以分成三類：

人工錄入 ： 自動化系統所需的業務 – 叢集 – 模組關係，每臺主機執行什麼服務等等。

外系統 API： 需要通過雲服務商 API、Zabbix API、K8s API、其他業務系統 API 等途徑。

自發現： 機器內部獲得，如 python psutil、puppet fact、ansible setup 等途徑。

瞭解屬性類別可以幫助我們更好更快地完善配置項的各種屬性自動獲取機制，儘量避免人工干預。

再聊聊主機，主機是一個承上啟下的核心物件，在它身上有很多屬性會被各種功能所使用，所以我們要先理清它和其他物件的關聯關係。

這裡的 業務 – 叢集 – 模組 – 主機 屬於物理概念，是機器所在的物理層次關係，因為機器必然伴隨著機房、網路、光纖之類的硬體概念，雖然說是物理層次，但是你用雲服務的話，就不存在主機這個實體。

而 服務 是機器的一個業務屬性，一個機器可以對應多個服務，作為服務的下一級別是程序，比如一個 web 服務會有 nginx、tomcat 等若干個程序，定義一個服務則需要與之關聯的程序，程序的主要屬性會有程序名稱、起停命令、佔用埠等。

作業平臺

定義

作業是一系列運維操作的抽象定義，任何一個運維操作都可以分解成一步一步的操作步驟和操作物件，不論是釋出變更還是告警處理，都是可以分步驟的。

命令： 一個可以獨立的操作，最簡單的如關服、開服、執行 xx 指令碼等；

檔案分發： 把指定的檔案分發到目標機器的目標路徑；

作業： 一系列命令、檔案分發的有序組合，作業的步驟可以由 “命令”、“檔案分發” 以及 “執行物件” 組成；

舉一個相對複雜的操作過程，如更新程式碼並重啟服務：

1 . 對 web：關閉 tomcat (/home/tomcat/bin/shutdown.sh)

2 . 對 server：關閉業務主程序 (/home/server/bin/stop.sh)

3 . 對 web：分發新的站點檔案 (scp xxx yyy)

4 . 對 server：分發服務端檔案 (scp xxx yyy)

5 . 對 web：啟動 tomcat (/home/tomcat/bin/startup.sh)

6 . 對 server：啟動業務主程序 (/home/server/bin/start.sh)

可以看出，流程包含了一系列 “物件”-“操作”  的有序的命令以及檔案分發的集合。“物件”可以是一個組、一個或者多個 IP，在執行命令時候可以在系統的頁面動態指定目標物件。

作業定義時有各種增刪改查操作，每個執行過的作業需要記錄執行人、執行時間、結束時間、返回值等資訊。

執行順序  

作業需要按順序執行，當一個步驟成功後才能執行下一個步驟，如果執行失敗需要停止執行作業，並保留執行的各種日誌。

比如一個作業定義如下：

1. 對 web 組（3 臺機器）：執行 stop tomcat；
2. 對 server 組（4 臺機器）：執行 stop server；
3. 對 app 組（2 臺機器）：執行 stop app；

執行細節是第一步對 web 組的 3 臺機器同時發起 stop tomcat 命令，等待 3 臺機器全部返回結果後，如果結果返回 0 表示命令執行成功，這時候才繼續進行第二步對 server 組的流程。如果第一步返回結果不為 0，則提示流程執行失敗，提示需要人工檢查，終止後面的流程。

主要物件

下面可以大致畫個圖勾勒出作業平臺的主要物件

作業這個概念的提出，即可以將運維工作的各種“變更”、“釋出”、“故障處理”等零碎操作分解成一個個可複用、可擴充套件、可執行的獨立操作命令，那麼最終平臺化的自動排程將成為可能。

開發的時候其介面和操作方式可以參考藍鯨的作業平臺（http://bk.tencent.com/document/bkprod/000119.html ），我所接觸過的幾個自動化平臺（包括商業的和網易內部的）都是應用了類似的設計方式 ，這算是一個經過眾多運維團隊考驗的最佳實踐，如果沒有什麼特殊業務需求，基本可以按這種模式啟動以提高開發效率。

然而，每家公司的具體業務形態決定了必然會有差異化的需求，隨意列舉幾個吧。

• 作業許可權系統，不同角色使用者可操作不同級別的作業；
• 作業執行前確認，比如某測試同事啟動作業，需要對應主程或者主策劃確認才啟動；
• 等待確認超時時間，比如等待 30 分鐘，未確認則取消啟動；
• 作業異常返回則報警郵件通知到運維組以及對應專案組同事；
• 灰度執行，按作業的設定，先在測試服執行，再到正式服；
• 作業配置克隆，快速搭建新的專案的作業配置；

差異化需求的開發可以在後期慢慢迭代改進。

作業執行情況分析

節約人力預估

因為作業平臺是一個讓運維定製各種線上操作，封裝任意能通過指令碼完成的功能，可以供自己或者專案組自助使用，儘可能做到運維無人值守，運維提供解決方案，那麼其最大作用就是為運維部門節約人力，杜絕重複勞動。

作業執行作為自動化平臺的核心功能，必須挖掘其利用效率，比如根據執行日誌統計每天、每週、每月執行次數，執行總耗時等資料，以估算出平臺為運維人員節省多少人力。

使用平臺前：

專案同事放下手頭工作 ->通過郵件或者 IM 通知運維同事執行某項操作 ->運維同事放下手頭工作，讀郵件或 IM，理解專案同事的操作內容 ->執行操作 ->通過郵件或者 IM 反饋專案同事 ->運維同事返回原來工作 ->專案同事放下工作讀郵件或 IM 再返回原工作

使用平臺後：

專案同事操作平臺直接執行某項操作得到反饋

這個過程對於專案同事和運維同事雙方總共至少能節約人力 15 分鐘，減少了很多溝通、理解、反饋的時間成本。

對於比較常規的普通操作則無需運維同事干預，除非執行異常才需要運維人員介入。

我們通過統計得知平臺每月執行作業的總次數為 N，每次預計節約人力資源 15 分鐘（0.25 小時），則每月總節約人力為 0.25＊N 小時，假設 N 為 1000，則每月節約運維部門 250 個小時的人力資源。

一個運維人員一天也就工作 8 小時（不加班的話~），一個月為 21*8=168 小時，那麼節約 250 小時則約等於 1.5 個運維人員的月工時。

由此可見當作業平臺的執行次數越大越能形成規模化，對人力資源的節省效果越有利，假設當 N = 10000 的時候，相當於節約了近 15 個運維人員的月工時，效果還是相當可觀的。

平臺的執行資料可以利用 echarts 做報表，讓運維同事實時檢視歷史執行次數和預計節約人力。

圖表解析：X 軸是時間，以每個月作為一個時間區間，統計該月一共執行了多少個作業。Y 軸的是作業的執行總次數（藍色軸，單位次），然後假設每個作業約節約人力 15 分鐘，最終計算出每月節約人力總時間（紅色軸，單位小時）。

作業異常分析

作業平臺可以讓運維人員解放了很多勞動力，但是我們也不可能保證每個作業都能正常執行，若在執行異常的情況下，我們可以為異常的原因打上標籤，打標籤可以根據錯誤輸出關鍵字匹配自動分類或者人工歸類，然後統計各種異常情況的比例，再重點分析並處理異常比例高的情況。

圖表解析： 由上圖可以看出這是各種異常的數量分佈情況，異常的分類是需要運維預先定義並且有足夠的區分度。然後根據作業在一個時間區間內統計出各種異常的比例，再利用餅狀圖可以方便找到比例最高的若干項，如上圖是【運維指令碼 bug】和【業務程式碼異常】比例最高，再著重分析解決這類異常的原因來降低運維操作故障率。

總結

運維自動化平臺的建設本質是運維團隊服務化能力的變現過程，它讓我們從大量重複無規律的人肉操作中解放出來，專注於運維服務質量的提升。由於文章篇幅所限，未能和大家全面介紹整個自動化平臺的設計思路，按系統的核心程度來劃分，最核心的是 CMDB 和作業平臺，當完成這兩部分之後，次核心的 CI/CD、資料平臺、監控平臺也可以投入開發，後面的運營輔助、故障自愈、智慧擴容縮容甚至 AiOps 等也需要 DevOps 團隊繼續探索。

作者介紹

溫崢峰

百田資訊運維技術專家，DevOps team leader，運維自動化平臺負責人，曾就職於網易遊戲，專注於運維自動化建設、DevOps 實踐與海量遊戲技術運營。知乎 id @Hi 峰兄

原文來自微信公眾號：高效開發運維