前言
我給中小型運維團隊的定義是整個團隊人數（所有運維工程師 + 運維開發(fā)工程師）為 20 人以下，一般這樣的團隊，能為自動化投入的資源也許就 1、2 個開發(fā)人員。
BAT 等大公司的 DevOps 平臺功能涵蓋的范圍非常全面而且各種高大上，這么龐大的體系對于中小型運維團隊，要靠手頭頂多 2 名運維開發(fā)工程師來實現落地就懵了，不知該從何入手。所以往往大部分中小型運維團隊要么傳統人肉運維黑路走到底，要么指望公司咬牙上 DevOps 商業(yè)服務。
然而，僅靠購買商業(yè)服務也未必能完全解決問題，主要原因有：
1 . 歷史項目成本考慮：商業(yè)平臺不支持個性化，歷史項目未必能直接對接商業(yè)平臺，需要通過運維與業(yè)務側均重構以適應商業(yè)平臺，對接成本甚至高于自建平臺，且要高速運行的業(yè)務側停下配合也并不靠譜；
2 . 商業(yè)機密數據的考慮：商業(yè)平臺會存儲運維 / 部分業(yè)務相關數據，這對于安全要求較高的行業(yè)來說，自建平臺的可控度更高；
然而，中小型公司的自建平臺大多都算是重復造輪子，雖然各家業(yè)務情況各異，但也有可以抽象成可復用的架構體系，這也是商業(yè)自動化平臺的價值所在，如果團隊是 10 人以下且沒專職開發(fā)人員再且業(yè)務技術歷史債務不重的情況下，選擇商業(yè)服務也不失為明智之舉。
我們經�？吹礁鞣N大廠的自動化平臺一般包含且不限于以下內容：CMDB、配置中心、管控平臺、數據平臺、CI/CD、作業(yè)平臺、容器管理、擴容縮容、輔助運營、監(jiān)控中心 等等，各種高大上詞匯讓人目不暇接。
由于中小型團隊的用人成本必須控制得極其精確，一般不會有太多人力資源投入到自動化平臺的開發(fā)，所以必須找出最核心功能，以達到快速落地投入生產環(huán)節(jié)使用為目的。我們不可能對上述功能點面面俱到，這樣只會讓自己無從下手。
其實最核心的功能模塊只有兩個：CMDB（配置平臺）和作業(yè)平臺。我們作為中小型的運維團隊，其實能把這兩部分完成即可滿足 80% 的業(yè)務需求，在此基礎上，再根據自身業(yè)務需求再考慮開發(fā)其他高級擴展功能如 CI/CD、數據分析、業(yè)務監(jiān)控、輔助運營等。
項目背景
需求驅動導向，大家也不會因為上線一個小項目就招人做自動化平臺，在什么情況下我們才需要做自動化平臺呢？
去年，隨著手游項目的發(fā)展，公司業(yè)務需求處于一個飛速增長的階段，在短時間內已經發(fā)展到將近數十個項目（含各種渠道、平臺、分區(qū)），業(yè)務形態(tài)各異，包括頁游、手游、站點、app 等，這樣眾多的項目運維管理成本非常高，傳統的運維管理方式很難高效率、高質量地管理和把控如此多的產品和項目。
隨著虛擬化、云、微服務等技術的發(fā)展，再加上有眾多的云服務提供商（阿里云、騰訊云、UCloud 等），應用程序的底層運行環(huán)境愈發(fā)多樣化，各種運維對象都需要通過一個平臺進行統一的操作和管理。
為了應對以上問題并高質量完成運維保障服務，我們必須做到：
- 通過平臺統一管理所有運維對象，對項目組、對運維部門的所有操作都程序固化；
- 實現所有項目的持續(xù)集成、自動化部署、項目組自助操作以提升發(fā)布效率和降低故障率；
- 有一個完善的配置中心為所有運維自動化的底層數據和配置基礎，驅動所有運維腳本、工具、組件正常運行；
如何達成目標
明確了目標之后，你會發(fā)現這三個目標正好對應三個運維術語：標準化、流程規(guī)范化和 CMDB。
- 標準化：從主機名、IP、操作系統、文件目錄、腳本等一系列運維對象都制定標準規(guī)范，業(yè)務部門和運維部門都遵守同一套標準，基于這套標準去建設統一的平臺。
- 流程規(guī)范化：主要是涉及 程序文件打包、開發(fā)測試線上環(huán)境管理、發(fā)布流程 等多部門協作的規(guī)范，必須落實到程序固化或者文檔固化，打造 Dev 和 Ops 之間的標準交付環(huán)境。
- CMDB：這是一切運維自動化體系建設的基石，其它如配置管理、作業(yè)執(zhí)行、資產管理等需要基于 CMDB 才能形成體系，構建完善的運維對象生命周期和操作閉環(huán)。
標準化
標準化包含的范疇非常多，從最簡單的操作系統版本、主機名、IP 段、系統帳號密碼到軟件安裝的目錄、參數、配置文件等等，也許不同的公司有其特有習慣和歷史遺留，所以這個沒有一個全業(yè)界的統一模式。
現在只需要把貴司的習慣用文檔的形式固化下來，再徹底檢查生產環(huán)境的情況是否滿足規(guī)范所述，不滿足則按規(guī)范操作。
對于歷史不是太悠久的項目要修正不會太困難，如果連這點都嫌麻煩的話，也不用談什么運維自動化了。
簡單畫個思維導圖，標準化的范疇主要包含但不限于以下內容：
流程規(guī)范化
流程規(guī)范化是在建立了標準化之后，為了規(guī)范運維內部以及與外部門合作的一系列復雜事件的細節(jié)做法，比如要發(fā)布新版本、上線新項目、業(yè)務擴容縮容等。
這一部分不太容易展開，因為不同公司有自己的做法和習慣，無論是怎樣做，請用文檔規(guī)范和約束各部門人員的行為，這樣才能方便程序化和自動化，不然程序就要寫多很多 if-else 語句或者需要配置化來兼容各種不規(guī)范情況，徒增開發(fā)人力消耗。
CMDB
不用贅述，CMDB 的設計肯定是運維自動化建設的重中之重，設計好的話，運維平臺的開發(fā)可以有事半功倍的效果。
CMDB（Configuration Management Database）配置管理數據庫，是記錄所有運維對象信息的數據庫，所有運維流程需要基于 CMDB 的數據進行操作，形成操作閉環(huán)，操作的結果會反饋到 CMDB 中。
此系統提供了一整套接口界面與其它任何需要信息的系統進行對接，這也是設計初衷，將信息從一個統一的、標準的源頭輸出給各垂直或水平業(yè)務功能系統，而運維需要做的就是維護 CMDB 本身基礎數據的完整性、準確性，CMDB 與各流程系統、垂直功能系統結合之后實現信息數據一處變更，處處同步。
一個機器下架的操作：
傳統方式：通過 SSH 登錄到該機器，關閉所有業(yè)務程序，關機，在控制列表刪除該 IP，下架，登錄資源管理系統刪除該機器信息。
自動化方式：在 CMDB 中編輯其狀態(tài)，系統自動調用底層工具關閉服務、關機，并自動將機器信息在 CMDB 中更新狀態(tài)
區(qū)別：傳統方式各個步驟都是非原子性，每一步都可能有錯漏的問題，如忘記刪除控制列表 IP 或者忘記更新資源管理系統信息，運維流程無法達到操作閉環(huán)。而真正的自動化方式是應該需要達到操作閉環(huán)，無需人工干預。
如何設計
CMDB 的設計有一個最大的誤區(qū)是想建立一個大而全的屬性表，恨不得想把全部運維對象的全部屬性都找出來，比如：
從零散的運維對象來拼湊 CMDB 基本都是吃力不討好的，因為這樣的設計方式根本沒有從業(yè)務出發(fā)。
而真正能解決業(yè)務問題的 CMDB 必須回到業(yè)務上面來，從核心的三層關系開始組建 CMDB，這三層概念從大到小分別是：業(yè)務、集群、模塊（游戲行業(yè)術語一般叫項目、分區(qū)、服務）
設計思路應該是這樣的，我所運維一個業(yè)務，它有哪些集群？集群下有哪些模塊？模塊下有哪些機器？機器有哪些屬性？各種屬性之間有什么關聯關系？
通過這樣的思維方式慢慢把真正的 CMDB 組織起來……
當然，運維對象遠不止那么少，還需要大家根據自家業(yè)務多多挖掘，這個過程比較艱辛，但不需要一步到位，先確定好核心對象，再慢慢完善補充其他對象。
配置項屬性
我們把 CMDB 的某個對象稱為配置項，一個典型的配置項如一臺主機、一個域名、一個 IP 。
舉個例子，一臺主機，其屬性獲取的三種方式：
- agent 獲得：如 cpu、memery、disk、ethX 之類的硬件信息，一般用 python psutil 模塊可以獲取大部分所需要的屬性；
- 云服務商 api：有部分屬性不能通過 agent 獲得的如 EIP、Region、Zone 等，如果不是用云主機的就不需要這一部分；
- 手工維護：有些屬性不能自動獲取，只能通過人工錄入，不過這類屬性還是盡量越少越好；
由點到面可以看出，配置項的屬性類別基本可以分成三類：
人工錄入 ： 自動化系統所需的業(yè)務 – 集群 – 模塊關系，每臺主機運行什么服務等等。
外系統 API： 需要通過云服務商 API、Zabbix API、K8s API、其他業(yè)務系統 API 等途徑。
自發(fā)現： 機器內部獲得，如 python psutil、puppet fact、ansible setup 等途徑。
了解屬性類別可以幫助我們更好更快地完善配置項的各種屬性自動獲取機制，盡量避免人工干預。
再聊聊主機，主機是一個承上啟下的核心對象，在它身上有很多屬性會被各種功能所使用，所以我們要先理清它和其他對象的關聯關系。
這里的業(yè)務 – 集群 – 模塊 – 主機屬于物理概念，是機器所在的物理層次關系，因為機器必然伴隨著機房、網絡、光纖之類的硬件概念，雖然說是物理層次，但是你用云服務的話，就不存在主機這個實體。
而服務是機器的一個業(yè)務屬性，一個機器可以對應多個服務，作為服務的下一級別是進程，比如一個 web 服務會有 nginx、tomcat 等若干個進程，定義一個服務則需要與之關聯的進程，進程的主要屬性會有進程名稱、起停命令、占用端口等。
作業(yè)平臺
定義
作業(yè)是一系列運維操作的抽象定義，任何一個運維操作都可以分解成一步一步的操作步驟和操作對象，不論是發(fā)布變更還是告警處理，都是可以分步驟的。
命令： 一個可以獨立的操作，最簡單的如關服、開服、執(zhí)行 xx 腳本等；
文件分發(fā)： 把指定的文件分發(fā)到目標機器的目標路徑；
作業(yè)： 一系列命令、文件分發(fā)的有序組合，作業(yè)的步驟可以由 “命令”、“文件分發(fā)” 以及 “執(zhí)行對象” 組成；
舉一個相對復雜的操作過程，如更新代碼并重啟服務：
1 . 對 web：關閉 tomcat (/home/tomcat/bin/shutdown.sh)
2 . 對 server：關閉業(yè)務主進程 (/home/server/bin/stop.sh)
3 . 對 web：分發(fā)新的站點文件 (scp xxx yyy)
4 . 對 server：分發(fā)服務端文件 (scp xxx yyy)
5 . 對 web：啟動 tomcat (/home/tomcat/bin/startup.sh)
6 . 對 server：啟動業(yè)務主進程 (/home/server/bin/start.sh)
可以看出，流程包含了一系列 “對象”-“操作” 的有序的命令以及文件分發(fā)的集合。“對象”可以是一個組、一個或者多個 IP，在執(zhí)行命令時候可以在系統的頁面動態(tài)指定目標對象。
作業(yè)定義時有各種增刪改查操作，每個執(zhí)行過的作業(yè)需要記錄執(zhí)行人、執(zhí)行時間、結束時間、返回值等信息。
執(zhí)行順序
作業(yè)需要按順序執(zhí)行，當一個步驟成功后才能執(zhí)行下一個步驟，如果執(zhí)行失敗需要停止運行作業(yè)，并保留執(zhí)行的各種日志。
比如一個作業(yè)定義如下：
對 web 組（3 臺機器）：執(zhí)行 stop tomcat；
對 server 組（4 臺機器）：執(zhí)行 stop server；
對 app 組（2 臺機器）：執(zhí)行 stop app；
執(zhí)行細節(jié)是第一步對 web 組的 3 臺機器同時發(fā)起 stop tomcat 命令，等待 3 臺機器全部返回結果后，如果結果返回 0 表示命令執(zhí)行成功，這時候才繼續(xù)進行第二步對 server 組的流程。如果第一步返回結果不為 0，則提示流程執(zhí)行失敗，提示需要人工檢查，終止后面的流程。
主要對象
下面可以大致畫個圖勾勒出作業(yè)平臺的主要對象
作業(yè)這個概念的提出，即可以將運維工作的各種“變更”、“發(fā)布”、“故障處理”等零碎操作分解成一個個可復用、可擴展、可執(zhí)行的獨立操作命令，那么最終平臺化的自動調度將成為可能。
開發(fā)的時候其界面和操作方式可以參考藍鯨的作業(yè)平臺（http：//bk.tencent.com/document/bkprod/000119.html ），我所接觸過的幾個自動化平臺（包括商業(yè)的和網易內部的）都是應用了類似的設計方式 ，這算是一個經過眾多運維團隊考驗的最佳實踐，如果沒有什么特殊業(yè)務需求，基本可以按這種模式啟動以提高開發(fā)效率。
然而，每家公司的具體業(yè)務形態(tài)決定了必然會有差異化的需求，隨意列舉幾個吧。
- 作業(yè)權限系統，不同角色用戶可操作不同級別的作業(yè)；
- 作業(yè)運行前確認，比如某測試同事啟動作業(yè)，需要對應主程或者主策劃確認才啟動；
- 等待確認超時時間，比如等待 30 分鐘，未確認則取消啟動；
- 作業(yè)異常返回則報警郵件通知到運維組以及對應項目組同事；
- 灰度執(zhí)行，按作業(yè)的設置，先在測試服運行，再到正式服；
- 作業(yè)配置克隆，快速搭建新的項目的作業(yè)配置；
差異化需求的開發(fā)可以在后期慢慢迭代改進。
作業(yè)執(zhí)行情況分析
節(jié)約人力預估
因為作業(yè)平臺是一個讓運維定制各種線上操作，封裝任意能通過腳本完成的功能，可以供自己或者項目組自助使用，盡可能做到運維無人值守，運維提供解決方案，那么其最大作用就是為運維部門節(jié)約人力，杜絕重復勞動。
作業(yè)執(zhí)行作為自動化平臺的核心功能，必須挖掘其利用效率，比如根據執(zhí)行日志統計每天、每周、每月執(zhí)行次數，執(zhí)行總耗時等數據，以估算出平臺為運維人員節(jié)省多少人力。
使用平臺前：
項目同事放下手頭工作 ->通過郵件或者 IM 通知運維同事執(zhí)行某項操作 ->運維同事放下手頭工作，讀郵件或 IM，理解項目同事的操作內容 ->執(zhí)行操作 ->通過郵件或者 IM 反饋項目同事 ->運維同事返回原來工作 ->項目同事放下工作讀郵件或 IM 再返回原工作
使用平臺后：
項目同事操作平臺直接執(zhí)行某項操作得到反饋
這個過程對于項目同事和運維同事雙方總共至少能節(jié)約人力 15 分鐘，減少了很多溝通、理解、反饋的時間成本。
對于比較常規(guī)的普通操作則無需運維同事干預，除非執(zhí)行異常才需要運維人員介入。
我們通過統計得知平臺每月執(zhí)行作業(yè)的總次數為 N，每次預計節(jié)約人力資源 15 分鐘（0.25 小時），則每月總節(jié)約人力為 0.25＊N 小時，假設 N 為 1000，則每月節(jié)約運維部門 250 個小時的人力資源。
一個運維人員一天也就工作 8 小時（不加班的話~），一個月為 21*8=168 小時，那么節(jié)約 250 小時則約等于 1.5 個運維人員的月工時。
由此可見當作業(yè)平臺的執(zhí)行次數越大越能形成規(guī)�；�，對人力資源的節(jié)省效果越有利，假設當 N = 10000 的時候，相當于節(jié)約了近 15 個運維人員的月工時，效果還是相當可觀的。
平臺的執(zhí)行數據可以利用 echarts 做報表，讓運維同事實時查看歷史執(zhí)行次數和預計節(jié)約人力。
圖表解析：X 軸是時間，以每個月作為一個時間區(qū)間，統計該月一共執(zhí)行了多少個作業(yè)。Y 軸的是作業(yè)的執(zhí)行總次數（藍色軸，單位次），然后假設每個作業(yè)約節(jié)約人力 15 分鐘，最終計算出每月節(jié)約人力總時間（紅色軸，單位小時）。
作業(yè)異常分析
作業(yè)平臺可以讓運維人員解放了很多勞動力，但是我們也不可能保證每個作業(yè)都能正常運行，若在執(zhí)行異常的情況下，我們可以為異常的原因打上標簽，打標簽可以根據錯誤輸出關鍵字匹配自動分類或者人工歸類，然后統計各種異常情況的比例，再重點分析并處理異常比例高的情況。
圖表解析： 由上圖可以看出這是各種異常的數量分布情況，異常的分類是需要運維預先定義并且有足夠的區(qū)分度。然后根據作業(yè)在一個時間區(qū)間內統計出各種異常的比例，再利用餅狀圖可以方便找到比例最高的若干項，如上圖是【運維腳本 bug】和【業(yè)務代碼異常】比例最高，再著重分析解決這類異常的原因來降低運維操作故障率。
總結
運維自動化平臺的建設本質是運維團隊服務化能力的變現過程，它讓我們從大量重復無規(guī)律的人肉操作中解放出來，專注于運維服務質量的提升。由于文章篇幅所限，未能和大家全面介紹整個自動化平臺的設計思路，按系統的核心程度來劃分，最核心的是 CMDB 和作業(yè)平臺，當完成這兩部分之后，次核心的 CI/CD、數據平臺、監(jiān)控平臺也可以投入開發(fā)，后面的運營輔助、故障自愈、智能擴容縮容甚至 AiOps 等也需要 DevOps 團隊繼續(xù)探索。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：中小型運維團隊如何設計運維自動化平臺
相關文章
