企業(yè)IT自動化運維實踐分析

1、 企業(yè)IT自動化運維實踐分析目 錄 TOC o 1-3 h z u HYPERLINK l _Toc522786788 1.前言 PAGEREF _Toc522786788 h 3 HYPERLINK l _Toc522786789 2.自動化運維的定義 PAGEREF _Toc522786789 h 3 HYPERLINK l _Toc522786790 3.自動化運維落地的實踐基礎(chǔ) PAGEREF _Toc522786790 h 5 HYPERLINK l _Toc522786791 4.自動化運維和流程管控 PAGEREF _Toc522786791 h 7 HYPERLINK l _T

2、oc522786792 5.自動化運維常用的工具分析 PAGEREF _Toc522786792 h 9 HYPERLINK l _Toc522786793 6.基于云平臺的自動化運維 PAGEREF _Toc522786793 h 11 HYPERLINK l _Toc522786794 7.總結(jié) PAGEREF _Toc522786794 h 13前言本文介紹自動化運維這個話題。當(dāng)你把自動化運維這個話題拋給不同的角色，他們的反應(yīng)也一定是不一樣的，程序員眼中的自動化運維可能是可以自助申請資源，可以點點點的進行應(yīng)用發(fā)布；應(yīng)用運維人員眼中的自動化運維可能是自動的監(jiān)控每個應(yīng)用的狀態(tài)有簡單的問題就按

3、照約定的動作去自愈，復(fù)雜的問題通知給我，我去處理或者是過期的日志清理等；基礎(chǔ)資源運維人員眼中的自動化運維可能是硬件服務(wù)的自助系統(tǒng)安裝，自動的環(huán)境初始化，垃圾文件清理等。這些理解都沒有錯，但是這些都是一個一個的點，沒有形成一個整體，沒有從方法論的角度去理解自動化運維，去建設(shè)自動化運維，本文就來談一談自動化運維是什么，以及如何實現(xiàn)企業(yè)自動化運維。自動化運維的定義對于不同的人眼中的自動化運維意味著什么，這些理解站在點的角度上或者說站在非領(lǐng)導(dǎo)的角度上理解都是沒有問題的，但是如果作為一個運維方面的領(lǐng)導(dǎo)理解僅僅理解到以上層面那就有點欠缺了，在我看來至少是缺乏了更為抽象的理解，缺少了理論的支持。我們先拋開這

4、個缺少的理論不說，在運維領(lǐng)域，有人會說，運維經(jīng)歷了人肉化，腳本化，自動運維工具以及平臺化幾個階段（圖一），這個說法有錯嗎？也沒有。但是細(xì)心地你會發(fā)現(xiàn)，這里提到的演化過程還是一個縱向的演化過程，說白了是通過技術(shù)的更新來推動運維的前進，而且這樣的演化過程很容易讓人陷入技術(shù)實現(xiàn)的細(xì)節(jié)，不能跳出來從宏觀的角度分析自動化運維到底該做什么？不該做什么？邊界在哪里？圖一接下來我就說下我理解的自動化運維的方法論或者說抽象的理論應(yīng)該是什么，大家仔細(xì)回想開篇提到的場景，無論是開發(fā)想要的資源自助申請，自動發(fā)布，還是運維項要的自動裝機、自助初始化環(huán)境以及故障的自愈等，還是我們從立項開始通過需求分析，詳細(xì)設(shè)計，編碼，測

5、試，運維，運營，反饋等，這些我們都是在干嘛？對了，我們都是在做端到端的交付！接下來再想，it系統(tǒng)建設(shè)是干嘛的，是為業(yè)務(wù)服務(wù)的，也就是說業(yè)務(wù)系統(tǒng)實現(xiàn)了業(yè)務(wù)功能就能帶來收益，大家才有飯吃，那么問題就簡單了，最簡單的場景是系統(tǒng)架構(gòu)設(shè)計好了以后所有的工作都圍繞業(yè)務(wù)實現(xiàn)來投入，其他的非功能性需求（這里沒有說非功能性需求不需要）投入的人力越少越好！到此，自動化運維理論的內(nèi)涵和外延都有了，那就是：對于非業(yè)務(wù)的功能性需求，在提供端到端交付的過程中能夠盡量的全自動化（圖二）。圖二最近很火的service mesh在微服務(wù)領(lǐng)域就有點這個意思，今天我們不是主要講service mesh，這里先不展開。自動化運維落地

6、的實踐基礎(chǔ)我們在第一個章節(jié)里交待清楚了什么自動化運維理論的內(nèi)核和外延，下面開始接地氣的談一談要想落地自動化運維理論，需要有什么樣的基礎(chǔ)或者說如何才能更好的落地自動化運維理論。筆者曾工作于國內(nèi)某一線互聯(lián)網(wǎng)公司，同時也是傳統(tǒng)行業(yè)工作過，切身體會到拋開技術(shù)架構(gòu)和人員能力不談，一線互聯(lián)網(wǎng)公司的自動化運維比傳統(tǒng)行業(yè)好的不是一個量級，筆者對整個問題進行過思考，得到的結(jié)論是：一線互聯(lián)網(wǎng)公司對端到端交付的自動化運維理念落實的很到位，而促使他們很好落實端到端交付的自動化運維理論的主要抓手有三個：一是對既定規(guī)范的絕對遵守；二是所有資源的抽象化；三是各種標(biāo)準(zhǔn)化（圖三）。圖三下面分別介紹一下這三點：一是對既定規(guī)范的絕

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

8、照既定規(guī)范來遵守游戲規(guī)則，對于非要玩特殊化的，那也很簡單，兩邊老大pk。有了規(guī)范，對于運維團隊而言只需要針對固定數(shù)量的保障等級準(zhǔn)備相應(yīng)的自動化運維手段就可以，而避免的過多的個性化需求。二是資源的抽象化，一線互聯(lián)網(wǎng)公司很多物理資源都是抽象化表示的（編碼化），例如機房名字、不同硬件配置的服務(wù)器。這樣的好處一方面便于記憶，另一方面統(tǒng)一了術(shù)語大家在交流的時候不容易出錯，最重要的是抽象表示后很對運維場景也變的簡單的。這里的抽象對于很多傳統(tǒng)行業(yè)的同學(xué)可能不太理解，我在這里舉幾個例子，例如一個在上海的聯(lián)通機房，他的命名可能是cnshu01，簡單解釋下，cnsh代表中國上海，u代表是聯(lián)通，01代表編號；再舉一

9、個例子，我們在傳統(tǒng)行業(yè)購置硬件服務(wù)器的時候，可能是每次根據(jù)需求不同選好硬件配置后再選品牌，在互聯(lián)網(wǎng)公司一般會首先對服務(wù)器的用途進行分類，例如計算密集型，內(nèi)存密集型，io密集型等，針對每種會有一個編碼，例如C42代表計算密集型，這樣的好處是需要使用機器的部門只需要將自己需要機器的編碼和數(shù)量發(fā)給采購部門就行了，別的就不用關(guān)心了。資源編碼化還有一個好處是當(dāng)需要用程序來管理資源的時候，編碼化最容易處理。三是各種標(biāo)準(zhǔn)化，每個公司都會面臨一個軟件版本管理的問題，從操作系統(tǒng)版本到軟件版本參差不齊，不同的軟件版本在運維時還是有一些差別的，在一線互聯(lián)網(wǎng)公司對于軟件的版本一般會有比較嚴(yán)格的一致性要求，尤其是生產(chǎn)環(huán)

10、境，過一段時間的軟件版本升級工作其實也促使了自動化運維的發(fā)展，試想如果沒有高效的自動化運維保障，每升級一次操作系統(tǒng)或者軟件版本都是一項巨大的工程，恰恰是這樣相互促進的關(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)化，是落地端到端自動化運維交付的有力抓手。自動化運維和流程管控這一部分，我們來聊下自動化運維與流程管控的關(guān)系。我們知道，運維工

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

12、程完善了，但是沒有全部系統(tǒng)化；三是流程完善了，系統(tǒng)化也有了但是流程沒有串起來，還都是一些孤立的點。以上三種場景都很難對流程做出較強的管控，好的流程管控，應(yīng)該這樣做：第一步結(jié)合工作的實際情況梳理出我們需要做流程的場景，這一步可以首先讓每位同事把自己認(rèn)為需要做流程管控的場景梳理出來，作為總的一個需求池，然后通過開會討論的方式將需求進行合并或者是去重，經(jīng)過這樣一個過程，產(chǎn)出物是一個需要做流程管控的文檔；第二步針對第一步梳理出來的文檔，標(biāo)注出每一個流程中最關(guān)鍵的點，這個點稱之為要素點。例如新購機器上架這個流程里，包括送達(dá)機房，簽收，上架前準(zhǔn)備，上架并加電，更新已上架設(shè)備信息等幾步，在這個流程中，上架并

13、加電是最核心也是對后續(xù)實際使用最有影響的一步，那么這一步就成為要素點；第三步就是針對第一步梳理出的流程，找到流程之間的銜接點，這也是為了解決流程孤島的問題。在這一步中如果發(fā)現(xiàn)有不能連接在一起而斷層的流程，就需要在這一步解決。第四步就是系統(tǒng)實現(xiàn)了，這一步無論是自研實現(xiàn)還是外包實現(xiàn)，都需要考慮的一點是如何與現(xiàn)有的自動化運維系統(tǒng)以及資源管理系統(tǒng)進行對接，因為流程的管控過程肯定會涉及資源的生命周期管理，這里的資源可以是實實在在的物理資源，例如服務(wù)器、防火墻、路由器和交換機等，也可以是軟件資源，例如安全策略，4/7層的負(fù)載均衡等，這樣的流程管控平臺就涉及到與cmdb、云平臺和容器平臺等的對接工作，這一步

14、一般是比較消耗精力的，倒不是說這里的技術(shù)難度有多難，而是這里一般都涉及接口的調(diào)試工作，如果這些系統(tǒng)都是自研的系統(tǒng)，那對接起來的難度可能還低些，畢竟都是自己公司的團隊，如果涉及到與外購系統(tǒng)的對接，這里的時間周期就很難控制了，根據(jù)筆者經(jīng)驗，這里如果是與外購系統(tǒng)對接，每個系統(tǒng)最好預(yù)留1個月的時間。第五步就是流程管控平臺上線后的與自動化運維平臺磨合和優(yōu)化的階段了。在這個階段，要留意觀察自動化運維平臺、資源平臺與流程管控平臺的數(shù)據(jù)交互是否正常，這里可以引入敏捷迭代的方式來及時處理問題（圖四）。圖四自動化運維常用的工具分析各位看官，在這個階段我主要介紹下實現(xiàn)自動化運維工具的三種理念，為了嚴(yán)謹(jǐn)期間說明下這個

15、環(huán)節(jié)說的自動化運維工具是要是指x86服務(wù)器層面。實現(xiàn)自動化運維工具的三種理念：第一種是完全自研，例如阿里巴巴集團的所有物理機上都安裝有一個久經(jīng)考驗并且功能強大的代理staragent，阿里巴巴集團所有物理機在系統(tǒng)初始化的時候就安裝了這個staragent，直到生命周期結(jié)束，這個startagent才會被卸載。這里有個問題就是，不是所有的公司都能像阿里巴巴一樣自研一個功能非常強大的agent，因此就有了第二種和第三種理念。第二種理念是使用市面上已有的自動化運維工具，并基于這些工具做成自動化運維平臺。目前市面上常見的自動化運維工具主要有以下幾種，Puppet、Chef、Ansible和Salt，下

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

17、技能外，還需要編程專業(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é)點上安裝代理軟件也

18、可以選擇安裝。Ansible能通過SSH執(zhí)行所有功能，Ansible基于Python開發(fā)對于熟悉python的人而言是一大福音，并且是由紅帽進行運營。Ansible可以從命令行來運行，不需要使用配置文件。至于比較復(fù)雜的任務(wù)，Ansible配置通過名為Playbook的配置文件中的YAML語法來加以處理。Playbook還可以使用模板來擴展其功能，目前playbook的模板還是非常豐富的。Salt類似Ansible，因為它也是基于CLI的工具，采用了推送方法實現(xiàn)客戶端通信。它可以通過Git或通過程序包管理系統(tǒng)安裝到主服務(wù)器和客戶端上，客戶端會向主服務(wù)器提出請求，請求在主服務(wù)器上得到接受后，就可以

19、控制該客戶端了。這四款自動化運維工具網(wǎng)上的比較很多，但是很難說誰就一定比誰好很多，還是那句話，你的團隊具有哪方面的人才就使用哪個，如果非要選出一個我個人推薦ansible，因為基于python實現(xiàn)，開發(fā)人員比較好找，同時社區(qū)資源活躍，相關(guān)的資源和組件也是比較豐富的。第三種思路是采購市面上商用的自動化運維平臺，這種思路對于很多甲方公司還是很現(xiàn)實的一種方案。對于這種思路，需要采購方切實梳理清楚自身的需求，整理出自己真實需要的自動化運維場景。這里的建議是，在選擇商用自動化運維平臺時和平臺銷售方協(xié)商好以下三件事，一是甲方結(jié)合實際工作中遇到的自動化運維場景，把需要馬上滿足的自動化運維場景梳理出來，作為第

20、一個模塊，即確定要完成的功能模塊；二是要求平臺銷售方提供自動化運維工具的編寫接口，并支持shell和python兩種語言，這個要求是考慮到后續(xù)有些運維場景開始沒有考慮到，或者新增了一些場景，自己的人員可以自行通過編寫腳本在這個平臺上實現(xiàn)；三是要求平臺銷售方對于產(chǎn)品層面積累的已有的運維場景實現(xiàn)要提供給采購方，并且支持后續(xù)當(dāng)產(chǎn)品有新運維場景更新時，要免費提供給采購方使用?；谠破脚_的自動化運維目前云平臺還是比較熱的一個話題，最后這個章節(jié)主要來聊下私有云iaas和paas平臺的自動化運維該是什么樣的。先說iaas平臺，iaas平臺主要涉及計算、存儲、網(wǎng)絡(luò)、安全這四大塊（圖五）。圖五計算資源應(yīng)該是分為

21、幾種固定的規(guī)格（計算密集型/io密集型/內(nèi)存密集型），這些規(guī)格由開發(fā)和運維團隊協(xié)商定制。沒有特殊情況下，無論是誰申請都不會新增新的機型，同時計算資源無論是開發(fā)人員自助申請，還是開發(fā)人員通過運維人員申請，申請完以后系統(tǒng)的初始化環(huán)境應(yīng)該是已經(jīng)自動完成的，這里的初始化環(huán)境包括并不限于IP地址、內(nèi)核參數(shù)、文件目錄結(jié)構(gòu)、計算機名稱、磁盤卷掛載等。存儲資源，要能夠做到容量預(yù)警和擴容提醒，當(dāng)觸發(fā)容量預(yù)警需要擴容時能夠通知到存儲管理員，同時存儲管理員提出擴容需求和方案后可以通過流程平臺通知到存儲采購人員，并進行采購動作。在存儲資源的服務(wù)能力方面，最佳情況是同時具備塊、文件和對象存儲能力，這樣才能滿足云環(huán)境下的應(yīng)用需求，尤其是對象存儲現(xiàn)在越發(fā)受到重視，筆者舉一個小例子，由于經(jīng)過前面的標(biāo)準(zhǔn)化要求，每臺云主機的文件目錄結(jié)構(gòu)都是統(tǒng)一的，那么當(dāng)應(yīng)用程序需要進行文件操作的時候，使用基于S3協(xié)議的對象存儲就很方便，免去了通過nfs或者smba進行盤掛載的方式，使用nfs或者smba進行掛載的方式會額外增加運維人員的維護成本，并且差異化也是與自動化運維的標(biāo)準(zhǔn)化理念相違背的。實際情況是，筆者