引言

我在自動(dòng)化部署，特別是公有云的自動(dòng)化部署上工作多年，因此本文主要就這方面進(jìn)行展開(kāi)。

注意：這里提到的云主要指基礎(chǔ)設(shè)施服務(wù)層，即IaaS，且泛指包括公有云、私有云或者混合云在內(nèi)的所有IaaS層形態(tài)。

基本背景

由于工作關(guān)系，我在上一家公司(Autodesk)時(shí)從2008年底開(kāi)始使用某國(guó)外公有云。當(dāng)時(shí)參與項(xiàng)目中很重要的一部分工作就是幫助用戶(hù)在我們的平臺(tái)上(注：我們的平臺(tái)運(yùn)行在該云上)完成自動(dòng)化部署。

由于整個(gè)部署非常重，涉及到平臺(tái)自身部署、基礎(chǔ)軟件部署和用戶(hù)傳統(tǒng)軟件部署。每次部署需要數(shù)個(gè)小時(shí)的時(shí)間，非常影響整個(gè)團(tuán)隊(duì)的工作效率。所以，我們花費(fèi)了比較多的時(shí)間在構(gòu)建自己的云自動(dòng)化部署系統(tǒng)。

進(jìn)入現(xiàn)在公司后，個(gè)人也推進(jìn)了所在項(xiàng)目的部分自動(dòng)化部署流程。盡管這個(gè)項(xiàng)目并不直接運(yùn)行在云上，但在原來(lái)項(xiàng)目中總結(jié)出的辦法還是有一定通用性。其中的部分經(jīng)驗(yàn)也得以落實(shí)，最終效果也不錯(cuò)(整個(gè)系統(tǒng)的部署時(shí)間有了數(shù)量級(jí)的縮短)。

經(jīng)歷上面兩個(gè)完全不同的項(xiàng)目，個(gè)人意識(shí)到，系統(tǒng)自身的可部署性，是能否落實(shí)自動(dòng)化部署的關(guān)鍵所在(當(dāng)然，這個(gè)結(jié)論的前提是團(tuán)隊(duì)已經(jīng)認(rèn)同自動(dòng)化部署是團(tuán)隊(duì)效率和質(zhì)量的基礎(chǔ)性制度保證)。

而系統(tǒng)的可部署性是從架構(gòu)設(shè)計(jì)到最終運(yùn)維整個(gè)流程都需要考慮的因素。所以需要整個(gè)工程團(tuán)隊(duì)(開(kāi)發(fā)、測(cè)試和運(yùn)維)在系統(tǒng)可部署性上要達(dá)成一致，制定相關(guān)準(zhǔn)則，整個(gè)自動(dòng)化部署才能順利推進(jìn)。

所以，這里我從系統(tǒng)的“可部署實(shí)踐準(zhǔn)則”角度來(lái)分析如何保證自動(dòng)化部署的成功實(shí)施：

盡管這里提到的很多準(zhǔn)則不僅僅是針對(duì)云上系統(tǒng)，但是由于個(gè)人經(jīng)驗(yàn)主要在云上系統(tǒng)的部署，同時(shí)個(gè)人相信未來(lái)絕大部分IT系統(tǒng)也都會(huì)運(yùn)行在云上，所以會(huì)以云上系統(tǒng)的自動(dòng)化部署為主來(lái)分享我的具體做法。

持續(xù)交付

在討論自動(dòng)化部署時(shí)，一定會(huì)涉及到持續(xù)交付。從邏輯的角度上看，自動(dòng)化部署是持續(xù)交付的一個(gè)階段。但是，自動(dòng)化部署流程和系統(tǒng)仍然是可以獨(dú)立于整個(gè)持續(xù)交付流程而獨(dú)立運(yùn)行。下圖描述常見(jiàn)的持續(xù)交付流程以及自動(dòng)化部署在其中的位置。

如上圖所示，整個(gè)自動(dòng)化部署流程會(huì)涉及到IT系統(tǒng)生命周期中的所有環(huán)境(開(kāi)發(fā)、測(cè)試，預(yù)發(fā)和生產(chǎn))。在這其中，由于生產(chǎn)系統(tǒng)的敏感性以及發(fā)布流程上的一些要求(如發(fā)布窗口期)，需要人工審批并觸發(fā)部署流程。其他環(huán)境更推薦持續(xù)部署來(lái)加快迭代周期，盡早發(fā)現(xiàn)問(wèn)題。

可部署實(shí)踐準(zhǔn)則

系統(tǒng)的可部署性一定是一個(gè)產(chǎn)品技術(shù)團(tuán)隊(duì)共同的職責(zé)：

• 云上IT系統(tǒng)應(yīng)該遵循的準(zhǔn)則有部分是流程上的，可能需要運(yùn)維人員做標(biāo)準(zhǔn)化;
• 有些部分則是系統(tǒng)開(kāi)發(fā)設(shè)計(jì)時(shí)的，需要開(kāi)發(fā)人員考慮;
• 當(dāng)然，測(cè)試工作也要考慮可部署性。

Rule 0 用版本管理系統(tǒng)(VCS)管理要發(fā)布的所有東西

這條規(guī)則比較容易理解，絕大部分團(tuán)隊(duì)也應(yīng)該都在實(shí)際項(xiàng)目中很好得落實(shí)了這點(diǎn)。

需要注意的是，VCS系統(tǒng)不僅僅是用來(lái)管理你的代碼，所有要發(fā)布的東西(包括代碼、文檔、視頻等等)都可以(也應(yīng)該)由統(tǒng)一的VCS來(lái)管理。至于VCS系統(tǒng)的選擇，主流的軟件(SVN、Git或者Perforce等)都能夠很好支持整個(gè)持續(xù)交付和自動(dòng)化部署流程。

Rule 1 統(tǒng)一管理構(gòu)建出來(lái)的Artifacts

這條規(guī)則是很多團(tuán)隊(duì)容易忽視，但對(duì)自動(dòng)化部署落實(shí)又非常重要的基礎(chǔ)性準(zhǔn)則。

什么是Artifacts?

Artifacts是指構(gòu)建系統(tǒng)產(chǎn)生的任何需要部署的輸出，如代碼包、文檔、靜態(tài)資源等。

參考上面的持續(xù)集成流程圖，可以看出Artifacts是所有自動(dòng)部署流程的輸入，它的管理質(zhì)量直接會(huì)影響到部署流程的順利程度和效率。關(guān)于Artifacts管理，現(xiàn)實(shí)工程中經(jīng)常出現(xiàn)的幾種情況如下：

團(tuán)隊(duì)完全無(wú)Artifacts管理。需要部署時(shí)直接從構(gòu)建系統(tǒng)拷貝出來(lái)，通過(guò)郵件或者其他文件分享工具在團(tuán)隊(duì)內(nèi)部傳輸。這種情況會(huì)導(dǎo)致整個(gè)部署流程完全失控，并且無(wú)法跟蹤部署記錄。

團(tuán)隊(duì)僅關(guān)注生產(chǎn)環(huán)境下的Artifacts管理。對(duì)于開(kāi)發(fā)、測(cè)試或者預(yù)發(fā)環(huán)境的Artifacts管理沒(méi)有任何規(guī)劃和標(biāo)準(zhǔn)。這種情況會(huì)無(wú)法保證整個(gè)生命周期的部署一致性，極大影響團(tuán)隊(duì)的迭代效率。

對(duì)于Artifacts的管理完全等同于對(duì)于文件的管理，沒(méi)有對(duì)Artifacts的metadata信息進(jìn)行任何有效管理。由于缺乏Artifacts的metadata信息，導(dǎo)致部署流程和系統(tǒng)不容易獲取當(dāng)前Artifacts的元數(shù)據(jù)并以此采取相關(guān)操作。會(huì)讓部署流程實(shí)現(xiàn)困難，部署質(zhì)量無(wú)法保證。

在實(shí)際工程中，團(tuán)隊(duì)越早在Artifacts管理上達(dá)成統(tǒng)一標(biāo)準(zhǔn)，團(tuán)隊(duì)在推進(jìn)自動(dòng)化部署落地的難度就越小。個(gè)人認(rèn)為，一個(gè)好的Artifacts管理方式需要有下面幾個(gè)原則：

• 統(tǒng)一管理所有需要部署的Artifacts，包括開(kāi)發(fā)、測(cè)試、預(yù)發(fā)和生產(chǎn)環(huán)境。只有這樣，才能夠?yàn)槲磥?lái)自動(dòng)化部署流程和系統(tǒng)提供統(tǒng)一的輸入。
• 統(tǒng)一的Artifacts元數(shù)據(jù)格式，包括當(dāng)前Artifacts的構(gòu)建信息、版本信息、可部署的環(huán)境等。
• 提供對(duì)接構(gòu)建系統(tǒng)和部署系統(tǒng)的API接口。只有API接口才能夠保證未來(lái)自動(dòng)化的落地。

目前，市面上已經(jīng)有很多Artifacts管理工具(如開(kāi)源的Nexus)，可以幫助大家快速搭建整個(gè)Artifacts管理系統(tǒng)。如果你的系統(tǒng)是在云上部署，云供應(yīng)商提供的對(duì)象存儲(chǔ)服務(wù)也是不錯(cuò)的選擇。

Rule 2 讓部署系統(tǒng)管理你的云上基礎(chǔ)設(shè)施

之所以把這一點(diǎn)放在前面，是因?yàn)樗匾?，而且也是和傳統(tǒng)IT環(huán)境下自動(dòng)化部署流程非常不同的地方。

在云上，一個(gè)非常重要的變化就是：所有的基礎(chǔ)設(shè)施都可編程。

今天，所有的云供應(yīng)商都必須提供基礎(chǔ)設(shè)施的編程接口(如虛機(jī)啟停API，存儲(chǔ)接口，網(wǎng)絡(luò)配置接口)。而有些更成熟的云供應(yīng)商已經(jīng)提供如CloudFormation服務(wù)，讓你的IT系統(tǒng)基礎(chǔ)設(shè)施能夠完全可精確描述。

正因?yàn)槿绱?，云上自?dòng)化部署系統(tǒng)可以完全管理起來(lái)自己的基礎(chǔ)設(shè)施，并且通過(guò)API或者如CloudFormation服務(wù)快速、精確構(gòu)建一致的IT運(yùn)行基礎(chǔ)設(shè)施。

當(dāng)系統(tǒng)的自動(dòng)化部署流程完全包括基礎(chǔ)設(shè)施管理后，有如下幾個(gè)明顯好處：

• 任何時(shí)刻都可以獲取環(huán)境完全一致的IT基礎(chǔ)設(shè)施來(lái)運(yùn)行系統(tǒng)(包括資源申請(qǐng)，環(huán)境搭建和軟件部署)。這樣，可以做到真正從零開(kāi)始快速部署系統(tǒng)，而無(wú)需依賴(lài)任何其他部門(mén)(如IT部門(mén))。
• IT基礎(chǔ)設(shè)施的任何變化都能夠被部署系統(tǒng)自動(dòng)感知并采取相應(yīng)的行動(dòng)，保證IT系統(tǒng)的穩(wěn)定性。
• IT系統(tǒng)可以根據(jù)系統(tǒng)當(dāng)前情況隨時(shí)向部署系統(tǒng)要求調(diào)整IT基礎(chǔ)設(shè)施(如彈性伸縮)。

這里需要提到的一點(diǎn)就是，以Docker為代表的容器技術(shù)讓運(yùn)行時(shí)標(biāo)準(zhǔn)化和可編程化變得極其容易和輕量級(jí)。

但是，整個(gè)IT系統(tǒng)基礎(chǔ)設(shè)施不僅僅包括系統(tǒng)的運(yùn)行時(shí)環(huán)境，還包括網(wǎng)絡(luò)規(guī)劃、存儲(chǔ)管理、計(jì)算資源管理等等。

而這些基礎(chǔ)設(shè)施的程序化目前還只能通過(guò)云上IaaS層API或者類(lèi)似CloudFormation來(lái)完成。所以，從這個(gè)角度看，Docker和IaaS并不是相互沖突，而是非常好的搭檔，一同把整個(gè)IT系統(tǒng)的運(yùn)維、管理成本大幅降低。

Rule 3 使用相同的部署流程管理你的開(kāi)發(fā)、測(cè)試、預(yù)發(fā)和生產(chǎn)環(huán)境

這是一條在傳統(tǒng)IT和云上都應(yīng)該遵循的原則。在現(xiàn)實(shí)中，很多團(tuán)隊(duì)都喜歡把部署系統(tǒng)這個(gè)事情拖到上線前的***一刻才開(kāi)始。而且，即使有自動(dòng)化部署流程，也是和生產(chǎn)環(huán)境硬耦合，只能用于生產(chǎn)系統(tǒng)的部署。

這種做法雖然短時(shí)間來(lái)得快，但是在長(zhǎng)期IT系統(tǒng)部署管理中會(huì)帶來(lái)不少麻煩，個(gè)人覺(jué)得至少會(huì)包括如下兩點(diǎn)：

• 這種部署方式導(dǎo)致不同環(huán)境的不一致性成為一個(gè)必然發(fā)生的事情，而這個(gè)問(wèn)題最終會(huì)給你的生產(chǎn)環(huán)境帶來(lái)致命故障。
• 這種部署方式導(dǎo)致開(kāi)發(fā)、測(cè)試和上線過(guò)程極為低效。其實(shí)，在不同環(huán)境中，生產(chǎn)環(huán)境的部署頻率是***的，而開(kāi)發(fā)、測(cè)試部署幾乎是工程團(tuán)隊(duì)每天都要做的事情。通過(guò)完全自動(dòng)化的部署流程來(lái)管理所有環(huán)境將極大提高日常開(kāi)發(fā)、測(cè)試效率。

所以，對(duì)于一個(gè)新項(xiàng)目，***在項(xiàng)目啟動(dòng)之初就能夠把整個(gè)IT系統(tǒng)的自動(dòng)化部署流程搭建成功，而且包括所有的環(huán)境。

而對(duì)于已經(jīng)運(yùn)行的項(xiàng)目，也要積極推動(dòng)部署流程和部署環(huán)境的解耦。具體來(lái)說(shuō)，常見(jiàn)的解決思路包括下面幾個(gè)點(diǎn)：

• 使用不同的代碼分支對(duì)應(yīng)不同的環(huán)境，方便進(jìn)行代碼管理;
• 抽象、提出所有和環(huán)境相關(guān)的配置，并以配置服務(wù)的方式提供訪問(wèn);
• 所有部署階段都需要接受環(huán)境參數(shù)輸入(可以是環(huán)境變量，也可以是參數(shù))，并按照不同環(huán)境做相應(yīng)部署操作;
• 給不同環(huán)境設(shè)置不同的部署頻率和時(shí)間窗口;
• 給不同環(huán)境設(shè)置不同的部署操作和訪問(wèn)權(quán)限，以控制部署風(fēng)險(xiǎn)。

***，可能很多團(tuán)隊(duì)根本不可能有完整開(kāi)發(fā)、測(cè)試和生產(chǎn)環(huán)境(或者這幾個(gè)環(huán)境的差異性太大)，讓同一套部署流程很難適配不同的環(huán)境。但是，因?yàn)樵频某霈F(xiàn)，讓我們獲取不同環(huán)境的IT基礎(chǔ)設(shè)施變得容易很多。

正因?yàn)槿绱?，落?shí)這條準(zhǔn)則的難度在大幅下降(其實(shí)，開(kāi)發(fā)測(cè)試已經(jīng)成為很多企業(yè)用戶(hù)開(kāi)始嘗試云的***站)，而這條規(guī)則帶來(lái)的開(kāi)發(fā)效率提升會(huì)讓團(tuán)隊(duì)收益匪淺。

#p#

Rule 4 使用相同的部署流程管理全球各地的同一個(gè)IT系統(tǒng)

這是一條看起來(lái)對(duì)很多團(tuán)隊(duì)沒(méi)什么用的準(zhǔn)則。但是，云的出現(xiàn)讓全球化部署變得非常容易，很多非常小的團(tuán)隊(duì)都可以做全球部署和運(yùn)營(yíng)。在云上，全球部署就是在云服務(wù)供應(yīng)商的全球不同Region部署你的IT系統(tǒng)。

當(dāng)然，即使在國(guó)內(nèi)，為提供更好的系統(tǒng)訪問(wèn)速度，云供應(yīng)商也會(huì)提供多個(gè)Region。由于云供應(yīng)商不同的Region提供的服務(wù)都已經(jīng)標(biāo)準(zhǔn)化，訪問(wèn)接口也都統(tǒng)一，這讓使用相同部署流程管理全國(guó)(乃至全球)各地服務(wù)容易很多。為此，你的部署系統(tǒng)需要注意幾點(diǎn)：

• 抽象、提出任何和部署Region相關(guān)的配置，并以配置服務(wù)的方式提供訪問(wèn)(配置服務(wù)有可能是集中化服務(wù));
• 所有部署階段都需要接受Region相關(guān)信息輸入(可以是環(huán)境變量，也可以是參數(shù));
• 需要提供不同Region的部署協(xié)調(diào)機(jī)制(例如，不同Region可能會(huì)在不同時(shí)區(qū)，這是處理和時(shí)間相關(guān)的部署任務(wù)需要特別小心的地方)。
• 一旦能夠統(tǒng)一不同Region的部署流程，將會(huì)使得業(yè)務(wù)擴(kuò)展時(shí)的IT部署變得容易很多，這也是整個(gè)系統(tǒng)可擴(kuò)展性的重要體現(xiàn)。

現(xiàn)在，IT系統(tǒng)擴(kuò)展性很多時(shí)候被局限在同一套系統(tǒng)在同一個(gè)地方能否快速伸縮，而忽略了IT系統(tǒng)在不同地點(diǎn)的快速?gòu)?fù)制能力。而這種快速?gòu)?fù)制能力不僅僅是業(yè)務(wù)全球化的需求，有時(shí)候也是解決系統(tǒng)自身容量擴(kuò)展性的重要途徑。

Rule 5 部署流程要優(yōu)先滿足熱升級(jí)、熱切換需求

在傳統(tǒng)IT工程中，由于熱升級(jí)和熱切換實(shí)現(xiàn)起來(lái)可能比較困難，而系統(tǒng)升級(jí)、切換的頻率也不一定高，很多時(shí)候這種功能性需求就會(huì)被當(dāng)成“二等公民”看待。但這條準(zhǔn)則恰恰相反，著重在強(qiáng)調(diào)“優(yōu)先滿足”。究其原因，個(gè)人認(rèn)為有如下幾點(diǎn)：

• “一直在線”已經(jīng)成為新的剛需。
• 隨著IT系統(tǒng)從后臺(tái)支撐逐步轉(zhuǎn)向前臺(tái)直接服務(wù)客戶(hù)。那種定期停機(jī)升級(jí)系統(tǒng)的方式已經(jīng)不再可以接受。
• 尤其是互聯(lián)網(wǎng)和移動(dòng)互聯(lián)網(wǎng)的普及，用戶(hù)對(duì)于在線服務(wù)的默認(rèn)期待已經(jīng)是“任何時(shí)候，任何地點(diǎn)都可以訪問(wèn)”。在這種情況下，無(wú)論是架構(gòu)設(shè)計(jì)還是部署流程都需要考慮“一直在線”這個(gè)目標(biāo)。
• 熱升級(jí)、熱切換是持續(xù)交付的基礎(chǔ)，是最終支撐業(yè)務(wù)快速發(fā)展的關(guān)鍵所在。實(shí)際工程中，產(chǎn)品團(tuán)隊(duì)的所有工作最終都得到生產(chǎn)環(huán)境接受檢驗(yàn)。
• 只有整個(gè)部署流程完全支持熱升級(jí)、熱切換，產(chǎn)品的任何改進(jìn)或需求確認(rèn)才能夠快速推到生產(chǎn)環(huán)境進(jìn)行驗(yàn)證。如果部署流程無(wú)法支持熱升級(jí)、熱切換，那持續(xù)部署就必然造成頻繁中斷服務(wù)，進(jìn)而影響業(yè)務(wù)。

正因?yàn)樯厦娴脑?，在整個(gè)架構(gòu)和部署流程的設(shè)計(jì)過(guò)程中就需要優(yōu)先考慮熱升級(jí)、熱切換，并堅(jiān)持走下去。否則搭建的整個(gè)持續(xù)交付或者自動(dòng)化部署流程都會(huì)事倍功半，最終走向失敗。

在云上，由于基礎(chǔ)設(shè)施資源的獲取非常容易，在升級(jí)過(guò)程中讓不同版本完全獨(dú)立運(yùn)行并逐步切換流量已經(jīng)是一個(gè)成本不高的實(shí)踐方式。所以，云上系統(tǒng)的熱升級(jí)及熱切換實(shí)現(xiàn)難度也有一定程度上的降低。

Rule 6 自動(dòng)化、自動(dòng)化還是自動(dòng)化

就如“自動(dòng)化部署”的名字所表述，自動(dòng)化是其核心訴求，也是能夠最終成功實(shí)踐的技術(shù)保障。關(guān)于自動(dòng)化的好處，相信不用展開(kāi)說(shuō)大家也都明白。但在現(xiàn)實(shí)過(guò)程中，大家面臨的問(wèn)題常常是如何實(shí)現(xiàn)平滑的實(shí)現(xiàn)自動(dòng)化。個(gè)人推薦下面幾個(gè)實(shí)踐經(jīng)驗(yàn)：

• 不要在自動(dòng)化技術(shù)和工具上猶豫太久。
• 選擇什么樣的自動(dòng)化部署工具對(duì)于還沒(méi)有自動(dòng)化流程的團(tuán)隊(duì)來(lái)說(shuō)不是***要?jiǎng)?wù)。重要的是團(tuán)隊(duì)有決心、花時(shí)間去開(kāi)始行動(dòng)。
• 如果在選擇技術(shù)和工具上真有什么建議的話，那就選團(tuán)隊(duì)最熟悉的技術(shù)和工具，這樣對(duì)于快速出結(jié)果最為有利。而讓團(tuán)隊(duì)盡快看到自動(dòng)化部署的優(yōu)勢(shì)，從而堅(jiān)定在這條路上走下去比選擇什么樣的工具要重要得多。
• 盡早建立“one-click”部署流程。這樣可以讓團(tuán)隊(duì)在“one-click”上有更早的約束，而不是在推進(jìn)過(guò)程中不斷妥協(xié)，***完全無(wú)法自動(dòng)化。
• 在有“one-click”部署流程的前提下分步推進(jìn)各個(gè)組件達(dá)到自動(dòng)化部署的要求。
• 在分步驟推進(jìn)過(guò)程中，一個(gè)好的策略是區(qū)分模塊中的“常量”和“變量”。

這里的“常量”指系統(tǒng)部署中不經(jīng)常變化的部分(如基礎(chǔ)操作系統(tǒng)，基礎(chǔ)軟件等等)。對(duì)于這些部分，開(kāi)始可以使用“預(yù)制模式”(如系統(tǒng)鏡像)加入部署系統(tǒng)。而部署過(guò)程中經(jīng)常變的“變量”部分，則需要在部署系統(tǒng)中重點(diǎn)考慮。當(dāng)然，“常量”和“變量”的劃分也不是絕對(duì)的。一般來(lái)說(shuō)，部署系統(tǒng)都是從自動(dòng)化最頻繁變化的“變量”部分開(kāi)始，逐步覆蓋較少變化的“常量”部分。因?yàn)檫@樣可以盡早***化自動(dòng)化流程帶來(lái)的價(jià)值。

Rule 7 讓模塊有自啟動(dòng)、自發(fā)現(xiàn)和自部署能力

在實(shí)施自動(dòng)化部署的過(guò)程中，估計(jì)最容易讓團(tuán)隊(duì)沮喪的就是不同模塊之間的部署依賴(lài)關(guān)系。很多傳統(tǒng)部署軟件也試圖通過(guò)各種方式(如可視化依賴(lài)關(guān)系)來(lái)降低維護(hù)部署依賴(lài)的難度，但很多時(shí)候最終效果并不好。

究其原因，個(gè)人覺(jué)得在業(yè)務(wù)場(chǎng)景的頻繁變化中，讓模塊之間的緊耦合依賴(lài)關(guān)系很難長(zhǎng)期保持穩(wěn)定，部署系統(tǒng)也就很難高效維護(hù)這種多變的部署依賴(lài)關(guān)系。隨著微服務(wù)概念的流行，更多人開(kāi)始相信每個(gè)微服務(wù)模塊都應(yīng)該是獨(dú)立部署、運(yùn)維并提供服務(wù)。

這點(diǎn)體現(xiàn)在部署上，就是讓每個(gè)模塊有自啟動(dòng)、自發(fā)現(xiàn)和自部署的能力。具體來(lái)說(shuō)，其包括下面幾個(gè)方面：

• 每個(gè)模塊在部署到系統(tǒng)中，都能夠在無(wú)外接主動(dòng)觸發(fā)的前提下自我啟動(dòng);
• 每個(gè)模塊在啟動(dòng)后，都能夠在無(wú)需外接主動(dòng)告知的前提下發(fā)現(xiàn)自己承擔(dān)的角色是什么;
• 每個(gè)模塊在發(fā)現(xiàn)自我角色后，都能夠在無(wú)需外接主動(dòng)推送的前提下完成對(duì)自我角色的部署、配置、依賴(lài)檢查并啟動(dòng)對(duì)外服務(wù)。

基于上面幾點(diǎn)要求，個(gè)人在實(shí)踐過(guò)程中采取的常見(jiàn)方法包括：

• 優(yōu)先選擇“運(yùn)行時(shí)部署”，而不是“預(yù)定義模式”(最常見(jiàn)的預(yù)定義模式就是鏡像交付);
• 每個(gè)模塊需要自我描述如何完成自己的部署流程(如某大云的CodeDeploy服務(wù)，其中的appspec.yaml文件其實(shí)就是其對(duì)應(yīng)模塊自我部署的描述文件);
• 讓每個(gè)模塊獨(dú)立進(jìn)行部署，不要求必須有前置或者后置的模塊部署。而模塊之間的依賴(lài)則優(yōu)先使用動(dòng)態(tài)發(fā)現(xiàn)的模式進(jìn)行。

#p#

Rule 8 讓部署變成服務(wù)

當(dāng)團(tuán)隊(duì)完成了整個(gè)自動(dòng)化部署流程，記得在往前一步，把你的部署工具變成一個(gè)對(duì)內(nèi)的部署服務(wù)，讓團(tuán)隊(duì)每個(gè)人(包括非技術(shù)人員或者新來(lái)的同事)也能夠快速完成部署。

為讓部署成為服務(wù)，你可能需要實(shí)現(xiàn)一個(gè)Portal，或者再添加一個(gè)郵件通知服務(wù)。當(dāng)然，你也可以把整個(gè)部署服務(wù)做得更好，甚至服務(wù)于其他團(tuán)隊(duì)。無(wú)論如何，這都會(huì)給團(tuán)隊(duì)帶來(lái)很大的好處，因?yàn)樗档土苏麄€(gè)系統(tǒng)的使用門(mén)檻，讓更多的人從中獲益。

Rule 9 用戶(hù)全面監(jiān)控保障自動(dòng)化部署

這是***一條準(zhǔn)則，但是可能也是很多開(kāi)始嘗試自動(dòng)化部署的團(tuán)隊(duì)最擔(dān)心的問(wèn)題：如果自動(dòng)化部署出問(wèn)題了咋辦?

人工部署時(shí)候還可以一步步觀察結(jié)果，由人來(lái)把關(guān)部署流程，避免不良后果快速擴(kuò)大。其實(shí)，在回答這個(gè)問(wèn)題之前，如果大家仔細(xì)回顧人肉部署帶來(lái)的各種故障，一定會(huì)發(fā)現(xiàn)人為失誤引起的故障比例會(huì)大得驚人。

而自動(dòng)化部署的一個(gè)目標(biāo)恰恰就是為了減少人為失誤導(dǎo)致的故障。當(dāng)然，為了避免自動(dòng)化部署的負(fù)面影響，你需要注意下面幾個(gè)方面：

• 請(qǐng)為你的服務(wù)提供全面的監(jiān)控。這不僅僅是日常運(yùn)維的需要，也是自動(dòng)化部署的需要。而且，這里的監(jiān)控需要包括很多應(yīng)用級(jí)別的監(jiān)控，而不僅僅是類(lèi)似CPU、Memory這些基礎(chǔ)性監(jiān)控。這樣，可以方便團(tuán)隊(duì)及時(shí)發(fā)現(xiàn)自動(dòng)部署引起的系統(tǒng)服務(wù)問(wèn)題。
• 在部署流程中提供快速回滾(Rollback)方案?？煽康幕貪L方案會(huì)讓你推進(jìn)自動(dòng)化部署的時(shí)候有更多的信心。
• 對(duì)每個(gè)模塊每個(gè)部署階段做更多的pre-check和post-check。想想如果你人肉做部署的時(shí)候是怎樣check每一個(gè)部署階段是否成功，如何判斷是否問(wèn)題，然后盡量把這些判斷邏輯都自動(dòng)化起來(lái)。

***，如果你是團(tuán)隊(duì)內(nèi)希望推動(dòng)自動(dòng)化部署的同學(xué)，下面兩點(diǎn)經(jīng)驗(yàn)或許在你推進(jìn)過(guò)程中能幫助到你：

• 痛點(diǎn)原則。在推進(jìn)自動(dòng)化部署過(guò)程中，一個(gè)常見(jiàn)的問(wèn)題就是時(shí)間問(wèn)題。團(tuán)隊(duì)總是會(huì)被不同的業(yè)務(wù)需求推著往前走，而自動(dòng)化部署這種非功能性需求經(jīng)常無(wú)法得到資源保障。這時(shí)候，你需要不斷問(wèn)自己的一個(gè)問(wèn)題是“如果我現(xiàn)在只能在自動(dòng)化部署方面做一見(jiàn)事情，那我需要做什么”。記得找到痛點(diǎn)***的唯一一件事情作為突破口，盡快讓團(tuán)隊(duì)感受到自動(dòng)化部署帶來(lái)的優(yōu)勢(shì)，才能夠得到團(tuán)隊(duì)更多的支持。
• 不回頭原則。在推進(jìn)自動(dòng)化部署過(guò)程中，團(tuán)結(jié)經(jīng)常會(huì)因?yàn)樽詣?dòng)化部署帶來(lái)的問(wèn)題或者自動(dòng)化部署流程不完善而放棄嘗試。這時(shí)候，作為主動(dòng)推進(jìn)的人，一定要及時(shí)跟進(jìn)發(fā)現(xiàn)系統(tǒng)問(wèn)題，而不是讓團(tuán)隊(duì)輕易走回頭路。

當(dāng)然，你肯定會(huì)說(shuō)搞定老板才是最核心的保障。如果你能夠有一個(gè)完全支持你的老板，那你是幸運(yùn)的。

更多時(shí)候，老板會(huì)是一種半信半疑的態(tài)度對(duì)待自動(dòng)化部署。這時(shí)候，找到突破點(diǎn)，快速見(jiàn)效并能堅(jiān)持下去可能就是你能說(shuō)服老板的***策略。

http://blog.xuguilin.me/2014/01/22/autodeploy-on-aws.html

作者介紹

徐桂林

阿里云日志服務(wù)技術(shù)專(zhuān)家，碩士畢業(yè)，曾任職AutoDesk等公司，擅長(zhǎng)云計(jì)算，DevOps等。

如何一起愉快地發(fā)展

“高效運(yùn)維”公眾號(hào)(如下二維碼)值得您的關(guān)注，作為高效運(yùn)維系列微信群的唯一官方公眾號(hào)，每周發(fā)表多篇干貨滿滿的原創(chuàng)好文：來(lái)自于系列群的討論精華、運(yùn)維講壇線上精彩分享及群友原創(chuàng)。“高效運(yùn)維”也是互聯(lián)網(wǎng)專(zhuān)欄《高效運(yùn)維***實(shí)踐》及運(yùn)維2.0官方公眾號(hào)。

提示：目前高效運(yùn)維兩個(gè)微信主群僅有少量珍貴席位，如您愿意，可添加蕭田國(guó)個(gè)人微信號(hào) xiaotianguo 為好友，進(jìn)行申請(qǐng);或申請(qǐng)加入技術(shù)交流群(技術(shù)討論為主，沒(méi)主群那么多規(guī)矩，更熱鬧)。

重要提示：除非事先獲得授權(quán)，請(qǐng)?jiān)诒竟娞?hào)發(fā)布2天后，才能轉(zhuǎn)載本文。尊重知識(shí)，請(qǐng)必須全文轉(zhuǎn)載，并包括本行及如下二維碼。