企業(yè)IT自動(dòng)化運(yùn)維實(shí)踐分析

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

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

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

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

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

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

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

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

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

10、境，過(guò)一段時(shí)間的軟件版本升級(jí)工作其實(shí)也促使了自動(dòng)化運(yùn)維的發(fā)展，試想如果沒(méi)有高效的自動(dòng)化運(yùn)維保障，每升級(jí)一次操作系統(tǒng)或者軟件版本都是一項(xiàng)巨大的工程，恰恰是這樣相互促進(jìn)的關(guān)系，當(dāng)整個(gè)公司都使用統(tǒng)一的操作系統(tǒng)版本和軟件版本時(shí)，很多工作的難度就降低了。另外，一線互聯(lián)網(wǎng)公司還對(duì)操作系統(tǒng)的目錄結(jié)構(gòu)（主要是指linux操作系統(tǒng)）有著標(biāo)準(zhǔn)化的要求，目錄結(jié)構(gòu)標(biāo)準(zhǔn)化的好處是無(wú)論誰(shuí)來(lái)處理問(wèn)題，都能根據(jù)標(biāo)準(zhǔn)化的路徑到達(dá)目的地，找到自己所需的內(nèi)容。綜上所述，既定規(guī)范的絕對(duì)遵守、資源的抽象化和標(biāo)準(zhǔn)化，是落地端到端自動(dòng)化運(yùn)維交付的有力抓手。自動(dòng)化運(yùn)維和流程管控這一部分，我們來(lái)聊下自動(dòng)化運(yùn)維與流程管控的關(guān)系。我們知道，運(yùn)維工

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

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

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

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

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

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

17、技能外，還需要編程專(zhuān)業(yè)知識(shí)。Chef的總體概念類(lèi)似Puppet，因?yàn)樵诒还芾淼墓?jié)點(diǎn)上安裝代理軟件，但實(shí)際部署又不一樣。除了主服務(wù)器外，安裝的Chef環(huán)境還需要工作站來(lái)控制主服務(wù)器。代理軟件可以借助使用SSH來(lái)部署的knife工具從工作站加以安裝，減輕了安裝負(fù)擔(dān)。被管理的節(jié)點(diǎn)通過(guò)使用證書(shū)，完成與主服務(wù)器之間的驗(yàn)證。與Puppet一樣，Chef得益于一大批的模塊和配置菜譜，那些模塊和配置菜譜又高度依賴(lài)Ruby。由于這個(gè)原因，Chef非常適合注重開(kāi)發(fā)的基礎(chǔ)設(shè)施。Ansible極其類(lèi)似Salt，而不太類(lèi)似Puppet或Chef，Ansible關(guān)注的重點(diǎn)是力求精簡(jiǎn)和快速，而且不需要在節(jié)點(diǎn)上安裝代理軟件也

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

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

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

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