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

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

一、自動化運維是什么?你是不是有什么誤解?

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

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

圖一

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

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

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

圖二

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

二、自動化運維落地的實踐基礎

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

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

圖三

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

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

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

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

三、自動化運維和流程管控

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

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

二是流程完善了，但是沒有全部系統化;

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

以上三種場景都很難對流程做出較強的管控，好的流程管控，應該這樣做：

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

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

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

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

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

圖四

四、實現自動化運維常用的工具對比分析

各位看官，在這個階段我主要介紹下實現自動化運維工具的三種理念，為了嚴謹期間說明下這個環節說的自動化運維工具是要是指x86服務器層面。實現自動化運維工具的三種理念：

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

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

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

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

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

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

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

五、云平臺的自動化運維該是什么樣的

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

圖五

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

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

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

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

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

六、總結

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