這里所謂的中小公司，是我的個人定義，服務(wù)器數(shù)量在5000以下的公司。大公司通常都已經(jīng)走上了這條路，應(yīng)該不會看我這篇文章了：）

運(yùn)維平臺收益

先說說為啥要開啟自動化運(yùn)維這條路，其實簡單，主要目的有二：

• 業(yè)務(wù)運(yùn)行可用可靠
• 業(yè)務(wù)迭代既穩(wěn)又快

我們希望通過構(gòu)建一整套運(yùn)維平臺，來規(guī)范研發(fā)的變更流程，來及時發(fā)現(xiàn)線上問題，能夠快速止損故障，同時把機(jī)器管理明白，權(quán)限分配清楚，服務(wù)梳理透徹。規(guī)范化之后，后面做一些統(tǒng)一的服務(wù)治理或者一些公共組件/服務(wù)，都可以依托平臺的元信息來搞，說是基石也不為過也。

從痛點處著手

首先胸中需有丘壑，胸中需有藍(lán)圖，運(yùn)維藍(lán)圖可參看我之前的文章：《運(yùn)維藍(lán)圖思考》。知道未來理想狀態(tài)了，然后低頭看現(xiàn)狀，最后制定達(dá)到理想狀態(tài)的路徑。

有句話說的好，“架構(gòu)是演進(jìn)出來的，不是設(shè)計出來的”，各個公司的情況各異，需要有針對性的實施。從哪里著手？從自己公司的當(dāng)前痛點著手。在這個階段，我個人猜測，可能會有下面的困擾：

• 有部分機(jī)器給了業(yè)務(wù)A，部分機(jī)器給了業(yè)務(wù)B，需要有個地方來記錄這個對應(yīng)關(guān)系，記錄機(jī)器上面部署了什么服務(wù)，接口人是誰，要不然，機(jī)器要做什么操作的時候，或者機(jī)器報警了，都不知道該聯(lián)系誰
• 機(jī)器經(jīng)常要做一些批量操作，批量安裝lib，調(diào)整配置，查看機(jī)器配置，跑個腳本，需要控制權(quán)限，業(yè)務(wù)A的機(jī)器只能業(yè)務(wù)A的同學(xué)才能操作，操作歷史要可審計，誰干了啥都得有記錄。中控機(jī)信任關(guān)系管理麻煩，批量操作速度慢，結(jié)果不好查看不好篩選
• 安裝一些常見軟件，比如MySQL、redis、kafka等，不同業(yè)務(wù)安裝的方式、版本、參數(shù)配置千差萬別，缺少一個最佳實踐，也沒有很好的沉淀，自己需要自己攢，業(yè)務(wù)A的同學(xué)對這些軟件的知識積累，業(yè)務(wù)B的同學(xué)無法享受到
• 線上出了問題，有很多時候是客戶先發(fā)現(xiàn)，我們被通知，非常被動。我們的業(yè)務(wù)有一些營收指標(biāo)，需要有個系統(tǒng)來看展示歷史趨勢圖，重要業(yè)務(wù)指標(biāo)如果下跌也得及時報警。當(dāng)然，機(jī)器硬件出問題，進(jìn)程掛了等基礎(chǔ)問題也是需要及時報警出來的

針對上面的問題，我們可以構(gòu)建一些基本的平臺系統(tǒng)來解決。下面挨個闡述...

服務(wù)機(jī)器管理

這是第一個系統(tǒng)，記錄管理了很多元數(shù)據(jù)，要求數(shù)據(jù)準(zhǔn)確，其他系統(tǒng)會依賴此系統(tǒng)的數(shù)據(jù)。系統(tǒng)構(gòu)建思路：

1，機(jī)器要想知道歸屬哪個團(tuán)隊哪個業(yè)務(wù)線，部署了哪個服務(wù)哪個模塊，首先系統(tǒng)里得先有團(tuán)隊、業(yè)務(wù)線、服務(wù)、模塊這些概念，要不然機(jī)器跟什么關(guān)聯(lián)呢
2，本質(zhì)上是對機(jī)器做了分組，常見分組機(jī)制就是一維的扁平分組和多維的標(biāo)簽，類似你的博客系統(tǒng)?？梢詫σ黄┪闹付ǚ诸?，也可以同時打多個標(biāo)簽
3，由于機(jī)器可能混部，一個機(jī)器需要同時屬于多個分組，這種情況用一維的分組就不好描述了，首推標(biāo)簽的方式，標(biāo)簽可以是K=V的方式，K實際是個維度信息，比如dept=sre,service=minos,module=web，假設(shè)有5臺機(jī)器打上了這3個標(biāo)簽，其意為：部門這個維度上來看，這5臺機(jī)器屬于sre這個部門，服務(wù)這個維度上來看，這5臺機(jī)器屬于minos這個服務(wù)，模塊這個維度上來看，這5臺機(jī)器部署了web這個模塊
4，看起來很完美，但是，標(biāo)簽最致命的一點是不夠直觀，比如我想通過標(biāo)簽搜索機(jī)器，首先你得知道有哪些標(biāo)簽，這個是最麻煩的
5，所以筆者待過的四家公司都是用樹狀結(jié)構(gòu)來描述這個分組關(guān)系，相對會直觀很多，樹的每個節(jié)點其實是有業(yè)務(wù)語義的，類似一個標(biāo)簽，只是這個標(biāo)簽具備了層級關(guān)系

批量執(zhí)行平臺

常見的運(yùn)維批量操作工具有很多，比如pssh、ansible、fabric、salt等，各有優(yōu)劣，對我而言，他們或多或少存在這些問題：

• 安全性，不方便和內(nèi)部權(quán)限配置系統(tǒng)整合
• 效率低，基于SSH的方案通常在大批量操作時比較費勁
• 結(jié)果不好查看，哪些機(jī)器成功，哪些機(jī)器失敗，哪些機(jī)器超時，需要做一些工作才能篩選，腳本的輸出也不是很好查看
• 不好審計，哪些人執(zhí)行過哪些腳本沒有歷史記錄
• 不好沉淀，可以自己總結(jié)一些腳本，但是系統(tǒng)層面沒有管理類的支持
• 沒有良好的并發(fā)控制、暫停點支持，但業(yè)務(wù)一般是灰度發(fā)布

所以，我們建議自研一套，解決如上問題，構(gòu)建思路也比較簡單：
1，所有機(jī)器部署一個agent，用來執(zhí)行命令
2，agent周期性跟server心跳，詢問我有哪些腳本任務(wù)要跑
3，拿到要跑的腳本在本地執(zhí)行，完了將結(jié)果匯報
4，server端提供一個web和api讓用戶來創(chuàng)建任務(wù)，展示結(jié)果
5，server端提供一個調(diào)度模塊來調(diào)度大批量機(jī)器的執(zhí)行，控制并發(fā)度，如果有失敗的機(jī)器可以及時停下來

監(jiān)控系統(tǒng)

這是第三個迫切需要構(gòu)建的系統(tǒng)，由于前面兩個要自研，監(jiān)控有不少開源軟件，所以很多情況都是現(xiàn)有監(jiān)控：）

對于監(jiān)控系統(tǒng)，我們不能只停留在OS、硬件、進(jìn)程相關(guān)監(jiān)控上，業(yè)務(wù)的訂單量、庫存余量這類直接反應(yīng)業(yè)務(wù)健康狀況的指標(biāo)更是尤為重要。由于服務(wù)通常有容災(zāi)能力，部署多個實例，某個機(jī)器掛了，可能影響不大，但是業(yè)務(wù)指標(biāo)下跌，比如訂單下跌，問題就大了，需要第一時間跟進(jìn)。

常見的監(jiān)控系統(tǒng)比如zabbix、nagios、open-falcon、prometheus等，因為筆者是open-falcon的早期開發(fā)人員，自然推薦open-falcon，讀者可以自行選擇：）

上面提到的機(jī)器/服務(wù)管理、批量執(zhí)行、權(quán)限系統(tǒng)，我們正在搞一個開源版本，有興趣的可以參與進(jìn)來