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