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