當(dāng)你把自動化運(yùn)維這個話題拋給不同的角色，他們的反應(yīng)也一定是不一樣的，程序員眼中的自動化運(yùn)維可能是可以自助申請資源，可以點點點的進(jìn)行應(yīng)用發(fā)布;應(yīng)用運(yùn)維人員眼中的自動化運(yùn)維可能是自動的監(jiān)控每個應(yīng)用的狀態(tài)有簡單的問題就按照約定的動作去自愈，復(fù)雜的問題通知給我，我去處理或者是過期的日志清理等;基礎(chǔ)資源運(yùn)維人員眼中的自動化運(yùn)維可能是硬件服務(wù)的自助系統(tǒng)安裝，自動的環(huán)境初始化，垃圾文件清理等。

這些理解都沒有錯，但是這些都是一個一個的點，沒有形成一個整體，沒有從方法論的角度去理解自動化運(yùn)維，去建設(shè)自動化運(yùn)維，那么今天我們就來談一談我眼中的自動化運(yùn)維是什么?

一、自動化運(yùn)維是什么?你是不是有什么誤解?

開篇的時候說了對于不同的人眼中的自動化運(yùn)維意味著什么，這些理解站在點的角度上或者說站在非領(lǐng)導(dǎo)的角度上理解都是沒有問題的，但是如果作為一個運(yùn)維方面的領(lǐng)導(dǎo)理解僅僅理解到以上層面那就有點欠缺了，在我看來至少是缺乏了更為抽象的理解，缺少了理論的支持。

我們先拋開這個缺少的理論不說，在運(yùn)維領(lǐng)域，有人會說，運(yùn)維經(jīng)歷了人肉化，腳本化，自動運(yùn)維工具以及平臺化幾個階段(圖一)，這個說法有錯嗎?也沒有。但是細(xì)心地你會發(fā)現(xiàn)，這里提到的演化過程還是一個縱向的演化過程，說白了是通過技術(shù)的更新來推動運(yùn)維的前進(jìn)，而且這樣的演化過程很容易讓人陷入技術(shù)實現(xiàn)的細(xì)節(jié)，不能跳出來從宏觀的角度分析自動化運(yùn)維到底該做什么?不該做什么?邊界在哪里?

圖一

接下來我就說下我理解的自動化運(yùn)維的方法論或者說抽象的理論應(yīng)該是什么，大家仔細(xì)回想開篇提到的場景，無論是開發(fā)想要的資源自助申請，自動發(fā)布，還是運(yùn)維項要的自動裝機(jī)、自助初始化環(huán)境以及故障的自愈等，還是我們從立項開始通過需求分析，詳細(xì)設(shè)計，編碼，測試，運(yùn)維，運(yùn)營，反饋等，這些我們都是在干嘛?對了，我們都是在做端到端的交付!

接下來再想，it系統(tǒng)建設(shè)是干嘛的，是為業(yè)務(wù)服務(wù)的，也就是說業(yè)務(wù)系統(tǒng)實現(xiàn)了業(yè)務(wù)功能就能帶來收益，大家才有飯吃，那么問題就簡單了，最簡單的場景是系統(tǒng)架構(gòu)設(shè)計好了以后所有的工作都圍繞業(yè)務(wù)實現(xiàn)來投入，其他的非功能性需求(這里沒有說非功能性需求不需要)投入的人力越少越好!

到此，自動化運(yùn)維理論的內(nèi)涵和外延都有了，那就是：對于非業(yè)務(wù)的功能性需求，在提供端到端交付的過程中能夠盡量的全自動化(圖二)。

圖二

最近很火的service mesh在微服務(wù)領(lǐng)域就有點這個意思，今天我們不是主要講service mesh，這里先不展開。

二、自動化運(yùn)維落地的實踐基礎(chǔ)

我們在前一個章節(jié)里交待清楚了什么自動化運(yùn)維理論的內(nèi)核和外延，下面開始接地氣的談一談要想落地自動化運(yùn)維理論，需要有什么樣的基礎(chǔ)或者說如何才能更好的落地自動化運(yùn)維理論。

筆者曾工作于國內(nèi)某一線互聯(lián)網(wǎng)公司，同時也是傳統(tǒng)行業(yè)工作過，切身體會到拋開技術(shù)架構(gòu)和人員能力不談，一線互聯(lián)網(wǎng)公司的自動化運(yùn)維比傳統(tǒng)行業(yè)好的不是一個量級，筆者對整個問題進(jìn)行過思考，得到的結(jié)論是：一線互聯(lián)網(wǎng)公司對端到端交付的自動化運(yùn)維理念落實的很到位，而促使他們很好落實端到端交付的自動化運(yùn)維理論的主要抓手有三個：一是對既定規(guī)范的絕對遵守;二是所有資源的抽象化;三是各種標(biāo)準(zhǔn)化(圖三)。

圖三

下面分別介紹一下這三點：

一是對既定規(guī)范的絕對遵守，在一線互聯(lián)網(wǎng)公司，運(yùn)維團(tuán)隊在接手開發(fā)的系統(tǒng)時，會有一個準(zhǔn)入的等級要求，這個要求是對開發(fā)提的，例如你要滿足我的哪些要求，我才會給你提供相應(yīng)的運(yùn)維保障，這里的要求有業(yè)務(wù)系統(tǒng)重要性等級說明、業(yè)務(wù)系統(tǒng)運(yùn)行時間說明、業(yè)務(wù)系統(tǒng)不能依賴低等級的業(yè)務(wù)系統(tǒng)、業(yè)務(wù)系統(tǒng)不能有單點故障等，因為在運(yùn)維團(tuán)隊看來，你只有符合我不同的要求，對我而言對你實現(xiàn)端到端的自動化運(yùn)維保障難度也是不同的。例如，一個非常重要的業(yè)務(wù)系統(tǒng)，可是開發(fā)有很多單點故障問題都沒有解決，很多健康檢查監(jiān)控都沒有實現(xiàn)，那么我運(yùn)維不可能破壞游戲規(guī)則，單獨為你一個系統(tǒng)做特殊高等級的保障，來耗費(fèi)我的人力資源，甚至后續(xù)的背鍋風(fēng)險。絕大多數(shù)情況下，開發(fā)都會按照既定規(guī)范來遵守游戲規(guī)則，對于非要玩特殊化的，那也很簡單，兩邊老大pk。有了規(guī)范，對于運(yùn)維團(tuán)隊而言只需要針對固定數(shù)量的保障等級準(zhǔn)備相應(yīng)的自動化運(yùn)維手段就可以，而避免的過多的個性化需求。

二是資源的抽象化，一線互聯(lián)網(wǎng)公司很多物理資源都是抽象化表示的(編碼化)，例如機(jī)房名字、不同硬件配置的服務(wù)器。這樣的好處一方面便于記憶，另一方面統(tǒng)一了術(shù)語大家在交流的時候不容易出錯，最重要的是抽象表示后很對運(yùn)維場景也變的簡單的。這里的抽象對于很多傳統(tǒng)行業(yè)的同學(xué)可能不太理解，我在這里舉幾個例子，例如一個在上海的聯(lián)通機(jī)房，他的命名可能是cnshu01，簡單解釋下，cnsh代表中國上海，u代表是聯(lián)通，01代表編號;再舉一個例子，我們在傳統(tǒng)行業(yè)購置硬件服務(wù)器的時候，可能是每次根據(jù)需求不同選好硬件配置后再選品牌，在互聯(lián)網(wǎng)公司一般會首先對服務(wù)器的用途進(jìn)行分類，例如計算密集型，內(nèi)存密集型，io密集型等，針對每種會有一個編碼，例如C42代表計算密集型，這樣的好處是需要使用機(jī)器的部門只需要將自己需要機(jī)器的編碼和數(shù)量發(fā)給采購部門就行了，別的就不用關(guān)心了。資源編碼化還有一個好處是當(dāng)需要用程序來管理資源的時候，編碼化最容易處理。

三是各種標(biāo)準(zhǔn)化，每個公司都會面臨一個軟件版本管理的問題，從操作系統(tǒng)版本到軟件版本參差不齊，不同的軟件版本在運(yùn)維時還是有一些差別的，在一線互聯(lián)網(wǎng)公司對于軟件的版本一般會有比較嚴(yán)格的一致性要求，尤其是生產(chǎn)環(huán)境，過一段時間的軟件版本升級工作其實也促使了自動化運(yùn)維的發(fā)展，試想如果沒有高效的自動化運(yùn)維保障，每升級一次操作系統(tǒng)或者軟件版本都是一項巨大的工程，恰恰是這樣相互促進(jìn)的關(guān)系，當(dāng)整個公司都使用統(tǒng)一的操作系統(tǒng)版本和軟件版本時，很多工作的難度就降低了。另外，一線互聯(lián)網(wǎng)公司還對操作系統(tǒng)的目錄結(jié)構(gòu)(主要是指linux操作系統(tǒng))有著標(biāo)準(zhǔn)化的要求，目錄結(jié)構(gòu)標(biāo)準(zhǔn)化的好處是無論誰來處理問題，都能根據(jù)標(biāo)準(zhǔn)化的路徑到達(dá)目的地，找到自己所需的內(nèi)容。綜上所述，既定規(guī)范的絕對遵守、資源的抽象化和標(biāo)準(zhǔn)化，是落地端到端自動化運(yùn)維交付的有力抓手。

三、自動化運(yùn)維和流程管控

這一部分，我們來聊下自動化運(yùn)維與流程管控的關(guān)系。我們知道，運(yùn)維工作中的任何一個需求的執(zhí)行都是有相應(yīng)的流程在進(jìn)行管控的。如果自動化運(yùn)維的動作沒有流程來進(jìn)行管理，那么自動化做了哪些運(yùn)維工作，為什么要做這些運(yùn)維工作，是誰做了這些運(yùn)維工作，對于管理員來說如果都不知道或者不可查，那就太恐怖了。ITIL的規(guī)范里面也對流程管控有很詳細(xì)的描述，但是根據(jù)筆者了解到的情況，在實際企業(yè)中，尤其是業(yè)務(wù)變化比較快的企業(yè)能夠完全按照ITIL流程來的還真是少只又少，ITIL流程還是比較重的，針對ITIL流程做裁剪來適合企業(yè)自身情況這才是正確的方式。在流程管控方面，傳統(tǒng)行業(yè)無論是用了ITIL還是沒有用的，目前都存在以下幾個問題：

一是流程不完善，即流程還是欠缺的不能完全覆蓋所有場景;

二是流程完善了，但是沒有全部系統(tǒng)化;

三是流程完善了，系統(tǒng)化也有了但是流程沒有串起來，還都是一些孤立的點。

以上三種場景都很難對流程做出較強(qiáng)的管控，好的流程管控，應(yīng)該這樣做：

第一步結(jié)合工作的實際情況梳理出我們需要做流程的場景，這一步可以首先讓每位同事把自己認(rèn)為需要做流程管控的場景梳理出來，作為總的一個需求池，然后通過開會討論的方式將需求進(jìn)行合并或者是去重，經(jīng)過這樣一個過程，產(chǎn)出物是一個需要做流程管控的文檔;

第二步針對第一步梳理出來的文檔，標(biāo)注出每一個流程中最關(guān)鍵的點，這個點稱之為要素點。例如新購機(jī)器上架這個流程里，包括送達(dá)機(jī)房，簽收，上架前準(zhǔn)備，上架并加電，更新已上架設(shè)備信息等幾步，在這個流程中，上架并加電是最核心也是對后續(xù)實際使用最有影響的一步，那么這一步就成為要素點;

第三步就是針對第一步梳理出的流程，找到流程之間的銜接點，這也是為了解決流程孤島的問題。在這一步中如果發(fā)現(xiàn)有不能連接在一起而斷層的流程，就需要在這一步解決。

第四步就是系統(tǒng)實現(xiàn)了，這一步無論是自研實現(xiàn)還是外包實現(xiàn)，都需要考慮的一點是如何與現(xiàn)有的自動化運(yùn)維系統(tǒng)以及資源管理系統(tǒng)進(jìn)行對接，因為流程的管控過程肯定會涉及資源的生命周期管理，這里的資源可以是實實在在的物理資源，例如服務(wù)器、防火墻、路由器和交換機(jī)等，也可以是軟件資源，例如安全策略，4/7層的負(fù)載均衡等，這樣的流程管控平臺就涉及到與cmdb、云平臺和容器平臺等的對接工作，這一步一般是比較消耗精力的，倒不是說這里的技術(shù)難度有多難，而是這里一般都涉及接口的調(diào)試工作，如果這些系統(tǒng)都是自研的系統(tǒng)，那對接起來的難度可能還低些，畢竟都是自己公司的團(tuán)隊，如果涉及到與外購系統(tǒng)的對接，這里的時間周期就很難控制了，根據(jù)筆者經(jīng)驗，這里如果是與外購系統(tǒng)對接，每個系統(tǒng)建議預(yù)留1個月的時間。

第五步就是流程管控平臺上線后的與自動化運(yùn)維平臺磨合和優(yōu)化的階段了。在這個階段，要留意觀察自動化運(yùn)維平臺、資源平臺與流程管控平臺的數(shù)據(jù)交互是否正常，這里可以引入敏捷迭代的方式來及時處理問題(圖四)。

圖四

四、實現(xiàn)自動化運(yùn)維常用的工具對比分析

各位看官，在這個階段我主要介紹下實現(xiàn)自動化運(yùn)維工具的三種理念，為了嚴(yán)謹(jǐn)期間說明下這個環(huán)節(jié)說的自動化運(yùn)維工具是要是指x86服務(wù)器層面。實現(xiàn)自動化運(yùn)維工具的三種理念：

第一種是完全自研，例如阿里巴巴集團(tuán)的所有物理機(jī)上都安裝有一個久經(jīng)考驗并且功能強(qiáng)大的代理staragent，阿里巴巴集團(tuán)所有物理機(jī)在系統(tǒng)初始化的時候就安裝了這個staragent，直到生命周期結(jié)束，這個startagent才會被卸載。這里有個問題就是，不是所有的公司都能像阿里巴巴一樣自研一個功能非常強(qiáng)大的agent，因此就有了第二種和第三種理念。

第二種理念是使用市面上已有的自動化運(yùn)維工具，并基于這些工具做成自動化運(yùn)維平臺。目前市面上常見的自動化運(yùn)維工具主要有以下幾種，Puppet、Chef、Ansible和Salt，下面對四種產(chǎn)品做一個對比介紹：

Puppet應(yīng)該是市面上使用最多的，就操作、模塊、界面而言，它是最全面的，Puppet呈現(xiàn)了數(shù)據(jù)中心協(xié)調(diào)的全貌，為各大操作系統(tǒng)提供了深入的工具，初始設(shè)置簡單，只是需要加以管理的每個系統(tǒng)上安裝客戶端代理軟件，CLI簡單直觀，允許通過puppet命令下載和安裝模塊，你可以對配置文件進(jìn)行需要的修改，讓模塊適合所需的任務(wù)，接到指令的客戶端與主服務(wù)器聯(lián)系時，會更改配置文件，也可以是客戶端主動與服務(wù)端通信來獲取到新的配置文件，還有一些模塊可以提供和配置云服務(wù)器實例和虛擬服務(wù)器實例，所有模塊和配置都使用基于Ruby的Puppet專屬語言或者Ruby本身構(gòu)建而成，因而除了系統(tǒng)管理技能外，還需要編程專業(yè)知識。

Chef的總體概念類似Puppet，因為在被管理的節(jié)點上安裝代理軟件，但實際部署又不一樣。除了主服務(wù)器外，安裝的Chef環(huán)境還需要工作站來控制主服務(wù)器。代理軟件可以借助使用SSH來部署的knife工具從工作站加以安裝，減輕了安裝負(fù)擔(dān)。被管理的節(jié)點通過使用證書，完成與主服務(wù)器之間的驗證。與Puppet一樣，Chef得益于一大批的模塊和配置菜譜，那些模塊和配置菜譜又高度依賴Ruby。由于這個原因，Chef非常適合注重開發(fā)的基礎(chǔ)設(shè)施。

Ansible極其類似Salt，而不太類似Puppet或Chef，Ansible關(guān)注的重點是力求精簡和快速，而且不需要在節(jié)點上安裝代理軟件也可以選擇安裝。Ansible能通過SSH執(zhí)行所有功能，Ansible基于Python開發(fā)對于熟悉python的人而言是一大福音，并且是由紅帽進(jìn)行運(yùn)營。Ansible可以從命令行來運(yùn)行，不需要使用配置文件。至于比較復(fù)雜的任務(wù)，Ansible配置通過名為Playbook的配置文件中的YAML語法來加以處理。Playbook還可以使用模板來擴(kuò)展其功能，目前playbook的模板還是非常豐富的。

Salt類似Ansible，因為它也是基于CLI的工具，采用了推送方法實現(xiàn)客戶端通信。它可以通過Git或通過程序包管理系統(tǒng)安裝到主服務(wù)器和客戶端上，客戶端會向主服務(wù)器提出請求，請求在主服務(wù)器上得到接受后，就可以控制該客戶端了。這四款自動化運(yùn)維工具網(wǎng)上的比較很多，但是很難說誰就一定比誰好很多，還是那句話，你的團(tuán)隊具有哪方面的人才就使用哪個，如果非要選出一個我個人推薦ansible，因為基于python實現(xiàn)，開發(fā)人員比較好找，同時社區(qū)資源活躍，相關(guān)的資源和組件也是比較豐富的。

第三種思路是采購市面上商用的自動化運(yùn)維平臺，這種思路對于很多甲方公司還是很現(xiàn)實的一種方案。對于這種思路，需要采購方切實梳理清楚自身的需求，整理出自己真實需要的自動化運(yùn)維場景。這里的建議是，在選擇商用自動化運(yùn)維平臺時和平臺銷售方協(xié)商好以下三件事，一是甲方結(jié)合實際工作中遇到的自動化運(yùn)維場景，把需要馬上滿足的自動化運(yùn)維場景梳理出來，作為第一個模塊，即確定要完成的功能模塊;二是要求平臺銷售方提供自動化運(yùn)維工具的編寫接口，并支持shell和python兩種語言，這個要求是考慮到后續(xù)有些運(yùn)維場景開始沒有考慮到，或者新增了一些場景，自己的人員可以自行通過編寫腳本在這個平臺上實現(xiàn);三是要求平臺銷售方對于產(chǎn)品層面積累的已有的運(yùn)維場景實現(xiàn)要提供給采購方，并且支持后續(xù)當(dāng)產(chǎn)品有新運(yùn)維場景更新時，要免費(fèi)提供給采購方使用。

五、云平臺的自動化運(yùn)維該是什么樣的

目前云平臺還是比較熱的一個話題，末尾這個章節(jié)主要來聊下私有云iaas和paas平臺的自動化運(yùn)維該是什么樣的。先說iaas平臺，iaas平臺主要涉及計算、存儲、網(wǎng)絡(luò)、安全這四大塊(圖五)。

圖五

計算資源應(yīng)該是分為幾種固定的規(guī)格(計算密集型/io密集型/內(nèi)存密集型)，這些規(guī)格由開發(fā)和運(yùn)維團(tuán)隊協(xié)商定制。沒有特殊情況下，無論是誰申請都不會新增新的機(jī)型，同時計算資源無論是開發(fā)人員自助申請，還是開發(fā)人員通過運(yùn)維人員申請，申請完以后系統(tǒng)的初始化環(huán)境應(yīng)該是已經(jīng)自動完成的，這里的初始化環(huán)境包括并不限于IP地址、內(nèi)核參數(shù)、文件目錄結(jié)構(gòu)、計算機(jī)名稱、磁盤卷掛載等。

存儲資源，要能夠做到容量預(yù)警和擴(kuò)容提醒，當(dāng)觸發(fā)容量預(yù)警需要擴(kuò)容時能夠通知到存儲管理員，同時存儲管理員提出擴(kuò)容需求和方案后可以通過流程平臺通知到存儲采購人員，并進(jìn)行采購動作。在存儲資源的服務(wù)能力方面，理想情況是同時具備塊、文件和對象存儲能力，這樣才能滿足云環(huán)境下的應(yīng)用需求，尤其是對象存儲現(xiàn)在越發(fā)受到重視，筆者舉一個小例子，由于經(jīng)過前面的標(biāo)準(zhǔn)化要求，每臺云主機(jī)的文件目錄結(jié)構(gòu)都是統(tǒng)一的，那么當(dāng)應(yīng)用程序需要進(jìn)行文件操作的時候，使用基于S3協(xié)議的對象存儲就很方便，免去了通過nfs或者smba進(jìn)行盤掛載的方式，使用nfs或者smba進(jìn)行掛載的方式會額外增加運(yùn)維人員的維護(hù)成本，并且差異化也是與自動化運(yùn)維的標(biāo)準(zhǔn)化理念相違背的。實際情況是，筆者發(fā)現(xiàn)現(xiàn)在很多傳統(tǒng)行業(yè)還是在使用nfs掛載的方式把文件提供給應(yīng)用程序使用，其中的痛苦大家也都體會過，所以現(xiàn)在也開始逐步進(jìn)行遷移改造工作。

網(wǎng)絡(luò)資源，理想的iaas云平臺網(wǎng)絡(luò)資源首先要能夠提供多種虛擬網(wǎng)絡(luò)設(shè)備，例如路由器、交換機(jī)、4/7層防火墻、4/7層負(fù)載均衡和ip資源池管理等，其次這些虛擬網(wǎng)絡(luò)設(shè)備不但要能夠在管理界面創(chuàng)建，同時還要能夠支持api調(diào)用，能夠通過代碼進(jìn)行管理。

安全資源，云平臺上的安全資源主要是指安全組能力(防火墻放在了網(wǎng)絡(luò)資源里)，通過安全組可以將不同租戶的主機(jī)進(jìn)行隔離，在小公司甚至可以通過安全組在一個云平臺上隔離出來測試環(huán)境、預(yù)部署環(huán)境和生產(chǎn)環(huán)境，這樣就大大降低了基礎(chǔ)設(shè)施的成本。

在paas平臺方面，根據(jù)筆者實際經(jīng)驗，目前主要是兩塊應(yīng)用的比較多：一塊是基于容器和ci/cd進(jìn)行狹義的devops流程來適配當(dāng)下很火爆的敏捷開發(fā);另外一塊是提前定制好一些中間件資源(這里主要是消息隊列、緩存、分布式鎖等)，來供開發(fā)人員直接使用，這些中間件資源可以是基于虛擬機(jī)定制好的模板，也可以是基于容器技術(shù)制作好的鏡像。無論是iaas平臺的自動化運(yùn)維還是paas平臺的自動化運(yùn)維，要想實現(xiàn)自動化，各個資源類型提供相應(yīng)的api是必不可少的，只有提供了api，我們才能夠?qū)⑵浯a化，從而自動化，否則很多場景還是擺脫不了人工手動處理的窘境，人工參與的場景越多，出錯的概率也就越大，距離理想的自動化運(yùn)維也就越遠(yuǎn)。

六、總結(jié)

本文從五個方面對自動化運(yùn)維做了一個介紹，其中很多場景也是筆者根據(jù)實踐經(jīng)驗對一線互聯(lián)網(wǎng)公司和傳統(tǒng)行業(yè)的做法進(jìn)行了對比闡述。我再強(qiáng)調(diào)一下我認(rèn)為的自動化運(yùn)維的理論內(nèi)涵和外延：對于非業(yè)務(wù)的功能性需求，在提供端到端交付的過程中能夠盡量的全自動化。