老鐵，你是不是對自動化運維有什麼誤解？
當你把自動化運維這個話題拋給不同的角色，他們的反應也一定是不一樣的，程式員眼中的自動化運維可能是可以自助申請資源，可以“點點點”地進行應用釋出；應用運維人員眼中的自動化運維可能是，自動的監控每個應用的狀態有簡單的問題就按照約定的動作去自愈，複雜的問題通知給我，我去處理或者是過期的日誌清理等；基礎資源運維人員眼中的自動化運維可能是硬體服務的自助系統安裝，自動的環境初始化，垃圾檔案清理等。
這些理解都沒有錯，但是這些都是一個一個的點，沒有形成一個整體，沒有從方法論的角度去理解自動化運維，去建設自動化運維，那麼今天我們就來談一談我眼中的自動化運維是什麼。
一、你對 自動化運維存在 誤解嗎？
開篇的時候說了 不同人眼中的自動化運維意味著什麼，這些理解站在點的角度上或者說站在非領導的角度上理解都是沒有問題的，但是如果作為一個運維方面的領導僅僅理解到以上層面那就有點欠缺了，在我看來至少是缺乏了更為抽象的理解，缺少了理論的支援。
我們先拋開這個缺少的理論不說，在運維領域，有人會說，運維經歷了人肉化、指令碼化、自動運維工具以及平臺化幾個階段：
這個說法有錯嗎？也沒有。但是細心地你會發現，這裡提到的演化過程還是一個縱向的演化過程，說白了是通過技術的更新來推動運維的前進，而且這樣的演化過程很容易讓人陷入技術實現的細節，不能跳出來從巨集觀的角度分析自動化運維到底該做什麼？不該做什麼？邊界在哪裡？
接下來我就說下我理解的自動化運維的方法論或者說抽象的理論應該是什麼，大家仔細回想開篇提到的場景，無論是開發想要的資源自助申請、自動釋出，還是運維項要的自動裝機、自助初始化環境以及故障的自愈等，還是我們從立項開始通過需求分析、詳細設計、編碼、測試、運維、運營、反饋等，這些我們都是在幹嘛？對了，我們都是在做端到端的交付。
接下來再想，IT系統建設是幹嘛的，是為業務服務的，也就是說業務系統實現了業務功能就能帶來收益，大家才有飯吃，那麼問題就簡單了，最簡單的場景是系統架構設計好了以後所有的工作都圍繞業務實現來投入，其他的非功能性需求（這裡沒有說非功能性需求不需要）投入的人力越少越好。
到此，自動化運維理論的內涵和外延都有了，那就是：對於非業務的功能性需求，在提供端到端交付的過程中能夠儘量的全自動化。
最近很火的Service Mesh在微服務領域就有點這個意思，今天我們不是主要講Service Mesh，這裡先不展開。
二、自動化運維落地的實踐基礎
我們在第一個章節裡交待清楚了自動化運維理論的核心和外延，下面開始接地氣的談一談要想落地自動化運維理論，需要有什麼樣的基礎或者說如何才能更好的落地自動化運維理論。
筆者曾工作於國內某一線網際網路公司，同時也在傳統行業工作過，切身體會到拋開技術架構和人員能力不談，一線網際網路公司的自動化運維比傳統行業好的不止一個量級，筆者對整個問題進行過思考，得到的結論是：
一線網際網路公司對端到端交付的自動化運維理念落實的很到位，而促使他們很好落實端到端交付的自動化運維理論的主要抓手有三個：
-
對既定規範的絕對遵守；
-
所有資源的抽象化；
-
各種標準化，如下圖所示：
下面分別介紹這三點：
1、絕對遵守既定規範
對既定規範的絕對遵守，即在一線網際網路公司，運維團隊在接手開發的系統時，會有一個准入的等級要求，這個要求是對開發提的，例如你要滿足我的哪些要求，我才會給你提供相應的運維保障，這裡的要求有業務系統重要性等級說明、業務系統執行時間說明、業務系統不能依賴低等級的業務系統、業務系統不能有單點故障等，因為在運維團隊看來，你必須符合我不同的要求，因為對我而言實現你端到端的自動化運維（產生的）保障難度也是不同的。
例如，一個業務系統非常重要，可是開發有很多單點故障問題都沒有解決，很多健康檢查監控都沒有實現，那麼我運維不可能破壞遊戲規則，單獨為你一個系統做特殊高等級的保障，來耗費我的人力資源，甚至後續的背鍋風險。絕大多數情況下，開發都會按照既定規範來遵守遊戲規則，對於非要玩特殊化的，那也很簡單，兩邊老大PK。有了規範，對於運維團隊而言只需要針對固定數量的保障等級準備相應的自動化運維手段就可以，而避免的過多的個性化需求。
2、資源的抽象化
資源的抽象化，即一線網際網路公司很多物理資源都是抽象化表示的（編碼化），例如機房名字、不同硬體配置的伺服器。這樣的好處一方面便於記憶，另一方面統一了術語大家在交流的時候不容易出錯，最重要的是抽象表示後很多運維場景也變的簡單了。
這裡的抽象對於很多傳統行業的同學可能不太理解，我在這裡舉幾個例子，例如一個在上海的聯通機房，命名可能是cnshu01，簡單解釋下，cnsh代表中國上海，u代表是聯通，01代表編號；再舉一個例子，我們在傳統行業購置硬體伺服器的時候，可能是每次根據需求不同選好硬體配置後再選品牌，在網際網路公司一般會首先對伺服器的用途進行分類，例如計算密集型，記憶體密集型，IO密集型等，針對每種會有一個編碼，例如C42代表計算密集型，這樣的好處是需要使用機器的部門只需要將自己需要機器的編碼和數量發給採購部門就行了，別的就不用關心了。資源編碼化還有一個好處是當需要用程式來管理資源的時候，編碼化最容易處理。
3、標準化
各種標準化，即每個公司都會面臨一個軟體版本管理的問題，從作業系統版本到軟體版本參差不齊，不同的軟體版本在運維時還是有一些差別的。
在一線網際網路公司對於軟體的版本一般會有比較嚴格的一致性要求，尤其是生產環境，過一段時間的軟體版本升級工作其實也促使了自動化運維的發展，試想如果沒有高效的自動化運維保障，每升級一次作業系統或者軟體版本都是一項巨大的工程，恰恰是這樣相互促進的關係，當整個公司都使用統一的作業系統版本和軟體版本時，很多工作的難度就降低了。
另外，一線網際網路公司還對作業系統的目錄結構（主要是指Linux作業系統）有著標準化的要求，目錄結構標準化的好處是無論誰來處理問題，都能根據標準化的路徑到達目的地，找到自己所需的內容。
綜上所述，既定規範的絕對遵守、資源的抽象化和標準化，是落地端到端自動化運維交付的有力抓手。
三、 自動化運維和流程管控
這一部分，我們來聊下自動化運維與流程管控的關係。我們知道，運維工作中的任何一個需求的執行都是有相應的流程在進行管控的。如果自動化運維的動作沒有流程來進行管理，那麼自動化做了哪些運維工作？為什麼要做這些運維工作？是誰做了這些運維工作？對於管理員來說，如果都不知道或者不可查，那就太恐怖了。
ITIL的規範裡面也對流程管控有很詳細的描述，但是根據筆者瞭解到的情況，在實際企業中，尤其是業務變化比較快的企業能夠完全按照ITIL流程來的還真是少之又少，ITIL流程還是比較重要的，針對ITIL流程做裁剪來適合企業自身情況這才是正確的方式。
在流程管控方面，傳統行業無論是用了ITIL還是沒有用的，目前都存在以下幾個問題：
-
流程不完善，即流程還是欠缺的，不能完全覆蓋所有場景；
-
流程完善了，但是沒有全部系統化；
-
流程完善了，系統化也有了但是流程沒有串起來，還都是一些孤立的點。
以上三種場景都很難對流程做出較強的管控，好的流程管控，應該這樣做：
Step 1： 結合工作的實際情況梳理出我們需要做流程的場景，這一步可以首先讓每位同事把自己認為需要做流程管控的場景梳理出來，作為總的一個需求池，然後通過開會討論的方式將需求進行合併或者是去重，經過這樣一個過程，產出物是一個需要做流程管控的文件；
Step 2： 針對第一步梳理出來的文件，標註出每一個流程中最關鍵的點，這個點稱之為要素點。例如新購機器上架這個流程裡，包括送達機房、簽收、上架前準備、上架並加電、更新已上架裝置資訊等幾步，在這個流程中，上架並加電是最核心也是對後續實際使用最有影響的一步，那麼這一步就成為要素點；
Step 3： 就是針對第一步梳理出的流程，找到流程之間的銜接點，這也是為了解決流程孤島的問題。在這一步中如果發現有不能連線在一起而斷層的流程，就需要在這一步解決。
Step 4： 就是系統實現了，這一步無論是自研實現還是外包實現，都需要考慮的一點是如何與現有的自動化運維繫統以及資源管理系統進行對接，因為流程的管控過程肯定會涉及資源的生命週期管理，這裡的資源可以是實實在在的物理資源，例如伺服器、防火牆、路由器和交換機等，也可以是軟體資源，例如安全策略、4/7層的負載均衡等。
這樣的流程管控平臺就涉及到與CMDB、雲平臺和容器平臺等的對接工作，這一步一般是比較消耗精力的。倒不是說這裡的技術難度有多難，而是這裡一般都涉及介面的除錯工作，如果這些系統都是自研的系統，那對接起來的難度可能還低些，畢竟都是自己公司的團隊；如果涉及到與外購系統的對接，這裡的時間週期就很難控制了，根據筆者經驗，這裡如果是與外購系統對接，每個系統最好預留1個月的時間。
Step 5： 就是流程管控平臺上線後的與自動化運維平臺磨合和優化的階段了。在這個階段，要留意觀察自動化運維平臺、資源平臺與流程管控平臺的資料互動是否正常，這裡可以引入敏捷迭代的方式來及時處理問題。
四、實現自動化運維常用的工具對比
在這個階段我主要介紹下實現自動化運維工具的三種理念，為了嚴謹起見，說明下這個環節說的自動化運維工具是要是指x86伺服器層面，實現自動化運維工具的三種理念：
1、完全自研
第一種是完全自研，例如阿里巴巴集團的所有物理機上都安裝有一個久經考驗並且功能強大的代理StarAgent，阿里巴巴集團所有物理機在系統初始化的時候就安裝了這個StarAgent，直到生命週期結束，這個StartAgent才會被解除安裝。這裡有個問題就是，不是所有的公司都能像阿里巴巴一樣自研一個功能非常強大的Agent，因此就有了第二種和第三種理念。
2、使用已有自動化運維工具
第二種理念是使用市面上已有的自動化運維工具，並基於這些工具做成自動化運維平臺。目前市面上常見的自動化運維工具主要有以下幾種：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實現，開發人員比較好找；同時社群資源活躍，相關的資源和元件也是比較豐富的。
3、採購商用自動化運維平臺
第三種思路是採購市面上商用的自動化運維平臺，這種思路對於很多甲方公司還是很現實的一種方案。對於這種思路，需要採購方切實梳理清楚自身的需求，整理出自己真實需要的自動化運維場景。這裡的建議是，在選擇商用自動化運維平臺時和平臺銷售方協商好以下三件事：
-
甲方結合實際工作中遇到的自動化運維場景，把需要馬上滿足的自動化運維場景梳理出來，作為第一個模組，即確定要完成的功能模組；
-
要求平臺銷售方提供自動化運維工具的編寫介面，並支援Shell和Python兩種語言，這個要求是考慮到後續有些運維場景開始沒有考慮到，或者新增了一些場景，自己的人員可以自行通過編寫指令碼在這個平臺上實現；
-
要求平臺銷售方對於產品層面積累的已有的運維場景實現要提供給採購方，並且支援後續當產品有新運維場景更新時，要免費提供給採購方使用。
五、雲平臺的自動化運維該是怎樣的
目前雲平臺還是比較熱的一個話題，最後這個章節主要來聊下私有云IaaS和PaaS平臺的自動化運維該是什麼樣的。
1、IaaS平臺
先說IaaS平臺，IaaS平臺主要涉及計算、儲存、網路、安全這四大塊：
計算資源：
計算資源應該是分為幾種固定的規格（計算密集型/IO密集型/記憶體密集型），這些規格由開發和運維團隊協商定製。
沒有特殊情況下，無論是誰申請都不會新增新的機型，同時計算資源無論是開發人員自助申請，還是開發人員通過運維人員申請，申請完以後系統的初始化環境應該是已經自動完成的，這裡的初始化環境包括並不限於IP地址、核心引數、檔案目錄結構、計算機名稱、磁碟卷掛載等。
儲存資源：
要能夠做到容量預警和擴容提醒，當觸發容量預警需要擴容時能夠通知到儲存管理員，同時儲存管理員提出擴容需求和方案後可以通過流程平臺通知到儲存採購人員，並進行採購動作。
在儲存資源的服務能力方面，最佳情況是同時具備塊、檔案和物件儲存能力，這樣才能滿足雲環境下的應用需求，尤其是物件儲存現在越發受到重視，筆者舉一個小例子，由於經過前面的標準化要求，每臺雲主機的檔案目錄結構都是統一的，那麼當應用程式需要進行檔案操作的時候，使用基於S3協議的物件儲存就很方便，免去了通過NFS或者smba進行盤掛載的方式，使用NFS或者smba進行掛載的方式會額外增加運維人員的維護成本，並且差異化也是與自動化運維的標準化理念相違背的。
實際情況是，筆者發現很多傳統行業還是在使用NFS掛載的方式把檔案提供給應用程式使用，其中的痛苦大家也都體會過，所以現在也開始逐步進行遷移改造工作。
網路資源：
理想的IaaS雲平臺網路資源首先要能夠提供多種虛擬網路裝置，例如路由器、交換機、4/7層防火牆、4/7層負載均衡和IP資源池管理等，其次這些虛擬網路裝置不但要能夠在管理介面建立，同時還要能夠支援API呼叫，能夠通過程式碼進行管理。
安全資源：
雲平臺上的安全資源主要是指安全組能力（防火牆放在了網路資源裡），通過安全組可以將不同租戶的主機進行隔離，在小公司甚至可以通過安全組在一個雲平臺上隔離出來測試環境、預部署環境和生產環境，這樣就大大降低了基礎設施的成本。
2、PaaS平臺
在PaaS平臺方面，根據筆者實際經驗，目前主要是兩塊應用的比較多：
-
一塊是基於容器和CI/CD進行狹義的DevOps流程來適配當下很火爆的敏捷開發。
-
另外一塊是提前定製好一些中介軟體資源（這裡主要是訊息佇列、快取、分散式鎖等），來供開發人員直接使用，這些中介軟體資源可以是基於虛擬機器定製好的模板，也可以是基於容器技術製作好的映象。無論是IaaS平臺的自動化運維還是PaaS平臺的自動化運維，要想實現自動化，各個資源型別提供相應的API是必不可少的，只有提供了API，我們才能夠將其程式碼化，從而自動化，否則很多場景還是擺脫不了人工手動處理的窘境，人工參與的場景越多，出錯的概率也就越大，距離理想的自動化運維也就越遠。
六、總結
本文從五個方面對自動化運維做了一個介紹，其中很多場景也是筆者根據實踐經驗對一線網際網路公司和傳統行業的做法進行了對比闡述。最後再強調一下我認為的自動化運維的理論內涵和外延：對於非業務的功能性需求，在提供端到端交付的過程中能夠儘量的全自動化。歡迎大家後續交流。
作者：王洋
來源： talkwithtrend訂閱號（ID：talkwithtrend）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]