在過去，基礎(chǔ)設(shè)施部署與應(yīng)用程序更新一直是延緩開發(fā)生命周期的兩大主要障礙。時至今日，云計算的蓬勃發(fā)展讓企業(yè)用戶得以將以往需要耗時數(shù)月的資源配置工作在幾分鐘內(nèi)完成，因此也給應(yīng)用程序的生命周期帶來了相應(yīng)改變。話說回來，雖然DevOps確實(shí)能夠幫上大忙，但只有以超越“文化轉(zhuǎn)變”的角度積極拓展才能真正讓這種新方案實(shí)現(xiàn)持續(xù)部署。

[[109030]] 

正如我在上一篇專題文章中所說，很明顯云計算給應(yīng)用程序帶來更多可能性、強(qiáng)制性以及巨大變化。通過那篇文章，我把重點(diǎn)放在了技術(shù)變化的探討方面，評述云計算對應(yīng)用程序架構(gòu)造成的影響——相信大家已經(jīng)感覺到，如今的應(yīng)用程序架構(gòu)開始把支持不斷提高的規(guī)模與負(fù)載變化、更強(qiáng)烈的性能需求以及由云計算引發(fā)的定價模式轉(zhuǎn)變納入設(shè)計思路當(dāng)中。

但當(dāng)時我并沒有談及云計算所顛覆的另一種傳統(tǒng)應(yīng)用程序要素，也就是應(yīng)用程序生命周期。具體而言，云計算需要與更為迅捷的應(yīng)用程序管理節(jié)奏相匹配，而這將迫使IT部門作出相應(yīng)調(diào)整。

從表面上看，我們可能很難理解為什么云計算所帶來的技術(shù)能力會對IT部門及其運(yùn)作流程產(chǎn)生影響。但是，云計算通過技術(shù)能力所帶來的關(guān)鍵性基礎(chǔ)——也就是自動化特性——必然要求更快的應(yīng)用程序生命周期與之相匹配。

云計算給IT部門——而非基礎(chǔ)設(shè)施——帶來壓力

在云計算出現(xiàn)之前，技術(shù)團(tuán)隊完全可以悠哉悠哉地創(chuàng)建應(yīng)用功能并將其交付到管理者手中，快一點(diǎn)或者慢一點(diǎn)都不是什么大問題。在這種情況下，底層基礎(chǔ)設(shè)施資源將承受巨大壓力，因?yàn)榭焖俑倪M(jìn)應(yīng)用程序功能并針對生產(chǎn)環(huán)境進(jìn)行頻繁更新成為保障運(yùn)作流程的前提。由于采購、安置以及配置基礎(chǔ)設(shè)施所耗費(fèi)的時間太過漫長，因此應(yīng)用程序開發(fā)以及部署所帶來的周期幾乎不會成為主要矛盾。換句話來說，基礎(chǔ)設(shè)施方面的難題將應(yīng)用程序周期掩蓋掉了。

云計算的自動化特性將全部基礎(chǔ)設(shè)施矛盾消弭于無形。時至今日，我們只需要花上幾分鐘時間、就能獲得大量全新計算資源——這在過去根本無法想象，那時候讓全新基礎(chǔ)設(shè)施資源投入運(yùn)作通常要花費(fèi)數(shù)周乃至數(shù)月時間。很明顯，目前基礎(chǔ)設(shè)施配置所需要的具體時長取決于IT部門的執(zhí)行流程，而不再受制于底層基礎(chǔ)設(shè)施資源本身。

與此同時，數(shù)字化信息正越來越多地與主流業(yè)務(wù)產(chǎn)品相集成。以接入互聯(lián)網(wǎng)的Nest恒溫裝置為例，這類產(chǎn)品意味著業(yè)務(wù)執(zhí)行的實(shí)際效果開始高度依賴于應(yīng)用程序功能可用性的交付速度。沒有了基礎(chǔ)設(shè)施帶來的局限，現(xiàn)在的主要障礙已經(jīng)轉(zhuǎn)變?yōu)閼?yīng)用程序生命周期本身。因此，我們可以預(yù)見，下一階段的主要矛盾將由云計算與應(yīng)用程序開發(fā)及部署流程的錯位所引發(fā)。簡而言之，IT部門必須加快應(yīng)用程序生命周期。

面對這樣的矛盾，DevOps粉墨登場。這個混合詞將“開發(fā)（Development）”與“運(yùn)營（Operations）”雜糅于一處，代表著原本彼此獨(dú)立的各組織與流程正式走向融合。這個新名詞所代表的愿景在于由精簡化、集成化組織通過聯(lián)合運(yùn)營流程對應(yīng)用程序更新進(jìn)行加速，從而將過去需要數(shù)周乃至數(shù)月才能完成的應(yīng)用生命周期縮減至如今的數(shù)小時或者最多數(shù)天。

但DevOps要如何才能為我們帶來神奇的提升效果？

文化轉(zhuǎn)變是必要的，但單憑這一點(diǎn)還遠(yuǎn)遠(yuǎn)不夠

文化轉(zhuǎn)變是我們經(jīng)常聽到的解決方案之一。從這個角度出發(fā)，開發(fā)人員與系統(tǒng)管理員通過加入同一團(tuán)隊的方式彼此協(xié)作，從而加強(qiáng)聯(lián)動效果、最終加快應(yīng)用程序生命周期。

我個人對這類方案并不太看好。沒錯，開發(fā)與運(yùn)營體系之間往往存在矛盾，而讓雙方工作人員身處同一團(tuán)隊無疑能夠改善人際關(guān)系。平心而論，這類方案確實(shí)有可能通過促進(jìn)合作、減少指責(zé)來推動當(dāng)前工作狀態(tài)。然而從科學(xué)層面分析，我們很難確切證實(shí)改善人際關(guān)系與加快應(yīng)用程序功能發(fā)布周期之間的必要聯(lián)系。

在任何情況下，漸進(jìn)式改善都還遠(yuǎn)遠(yuǎn)不夠。企業(yè)沒辦法僅僅依賴20%的功能構(gòu)建效率增幅保證自身在未來數(shù)字化業(yè)務(wù)環(huán)境下取得成功。因?yàn)樵谶@種情況下，實(shí)際效果只能是將項目的開發(fā)周期由過去的21天縮短為現(xiàn)在的18天，或者舉個更常見的例子，由原本的六個月縮短至五個月。要在如今的激烈競爭中保持優(yōu)勢，業(yè)務(wù)流程的速度提升至少要達(dá)到200%才算合格。

另外，“文化”這一表述也屬于一種誤導(dǎo)。文化關(guān)注的是人為因素而非流程——這相當(dāng)于對流程的一種顛覆。再有，即使速度有所加快，流程本身也需要真正貫穿應(yīng)用程序生命周期始終才能帶來確切成效。

也就是說，我們已經(jīng)在軟件工程層面上取得了重大進(jìn)展。在過去十年當(dāng)中，開發(fā)實(shí)踐、靈活的工作方式、頻繁登記以及自動化機(jī)制的建立與測試已經(jīng)帶來了非常可觀的加速效果。這場被稱為“持續(xù)集成”的革命幫助我們縮短開發(fā)周期、降低項目事故并使整個項目流程更具可預(yù)測性。

不過對于多數(shù)IT部門而言，在談到將新代碼投入生產(chǎn)體系當(dāng)中時，應(yīng)用程序生命周期的加速步伐往往就此戛然而止。在實(shí)際運(yùn)營情況下，由于每個下游團(tuán)隊都需要利用自己選擇的工具進(jìn)行任務(wù)處理，因此各個環(huán)節(jié)往往都需要以手動方式進(jìn)行一次又一次冗余操作——這就破壞了流程的自動化屬性。

惟一的解決方式在于保證IT部門實(shí)現(xiàn)持續(xù)部署，在這種情況下代碼修改將貫穿整個自動化應(yīng)用程序生命周期始終，業(yè)務(wù)流程快速響應(yīng)所帶來的穩(wěn)定性影響以及頻繁的功能更新也將得到解決。作為負(fù)面影響，持續(xù)集成會助長IT部門對于自主解決方案的信心，導(dǎo)致業(yè)務(wù)部門難以將應(yīng)用程序供應(yīng)商引入整個運(yùn)營體系當(dāng)中。

我曾經(jīng)聽說過很多圍繞持續(xù)部署所展開的爭論。他們的核心分歧在于惡意代碼進(jìn)入生產(chǎn)環(huán)境的可能性，以及在執(zhí)行終端到終端自動化機(jī)制后惡意軟件所將引發(fā)的嚴(yán)重后果。說到底，這場爭論的實(shí)質(zhì)在于，如果沒有人為因素的干預(yù)、自動化流程會出現(xiàn)問題。

我們姑且不談這樣的結(jié)論到底跟廢話有什么區(qū)別，其實(shí)根據(jù)我的個人經(jīng)驗(yàn)，就算存在人為干預(yù)、問題也照樣有可能出現(xiàn)。更進(jìn)一步，人為干預(yù)也可能成為引發(fā)問題的誘因，因此我對這樣的說辭并不買賬。在任何情況下，對于手動執(zhí)行流程的要求最終都會被用戶需求所否決。一味堅持既定方法將是完全徒勞的。如果不相信，大家可以問問VMware的系統(tǒng)管理員——由于他們要求開發(fā)人員等待數(shù)周的審批來使用虛擬巨頭的內(nèi)部資源，這些開發(fā)者直接把自己的虛擬機(jī)交給了Amazon Web Services。

持續(xù)部署需要自動化、集成化與均衡的激勵機(jī)制

為了實(shí)現(xiàn)持續(xù)部署流程，必須滿足以下四點(diǎn)前提條件。

一套簡潔的自動化流程。如果流程當(dāng)中包含由審計委員會設(shè)定的階段性目標(biāo)、未經(jīng)批準(zhǔn)無法進(jìn)入下一步執(zhí)行環(huán)節(jié)或者其它形式的人為監(jiān)督機(jī)制，那么整個體系的運(yùn)作效率必然大打折扣。雖然我們主張將特定變更劃分在自動化流程之外——可能出于復(fù)雜性或者其它特定因素的考量，但這與將全部變更都納入人為干擾范疇完全不同。最理想的方式是在必要情況下引入人為干預(yù)因素，但除此之外的常規(guī)變更都由自動化流程打理。

一套集成化、終端到終端工具鏈。很明顯，除非整個流程都擁有理想工具作為底層支持，否則自動化工作流程根本就是紙上談兵。從本質(zhì)上講，這些工具在某一階段中的輸出內(nèi)容都要能夠?yàn)橄乱浑A段的工具所接納，也就是說各類工具之間能夠順暢銜接。時至今日，我們完全可以在大型廠商手中直接購買昂貴的專有產(chǎn)品、也能夠以開源組件為基礎(chǔ)自主構(gòu)建適合實(shí)際需求的功能集合。任何一種方案都既有長處、也有短板。隨著這一領(lǐng)域重要性的日益增加，市場對其的關(guān)注程度也將水漲船高，相信更多更靈活也更加實(shí)惠的解決方案很快就會出現(xiàn)在市場當(dāng)中。

共享化應(yīng)用程序構(gòu)件。新增工具所采用的構(gòu)件必須能夠與整個體系順利對接。由此帶來的可執(zhí)行文件以及配置創(chuàng)建工作，甚至包括制定自動運(yùn)行說明在內(nèi)，都有可能引發(fā)潛在的出錯風(fēng)險，進(jìn)而對功能的快速可用性產(chǎn)生影響。相比之下，最理想的處理方式是利用單一構(gòu)件集貫穿整個流程，并通過加減權(quán)限劃分出適合需求的組織結(jié)構(gòu)。

在整個企業(yè)內(nèi)保證指標(biāo)與激勵機(jī)制均衡。說到激勵機(jī)制，我們再次回到了“文化”這一話題上來。如前面提到，我個人并不太相信僅僅通過發(fā)展人際關(guān)系就足以將不同群體團(tuán)結(jié)在一起、甚至徹底消除協(xié)作中的摩擦與失誤。要真正實(shí)現(xiàn)這樣的效果，均衡的評比指標(biāo)與激勵機(jī)制才是重中之重。如果我們以功能更新的發(fā)布頻率作為某個團(tuán)隊的評比標(biāo)準(zhǔn)、卻通過運(yùn)行穩(wěn)定性作為另一個團(tuán)隊的評比標(biāo)準(zhǔn)，那么雙方將由于不具可比性而出現(xiàn)績效考核方面的沖突。

我們需要通過一系更措施將每一位成員緊密團(tuán)結(jié)在一起。千萬別以為將前面提到的各類指標(biāo)一股腦塞進(jìn)來就能獲得理想的收效，事實(shí)上要求同一個團(tuán)隊既能頻繁推出更新、又保證成果的運(yùn)行穩(wěn)定性，這本身就會引發(fā)嚴(yán)重不滿——很明顯，這樣的目標(biāo)需要由多個團(tuán)隊協(xié)作才有可能實(shí)現(xiàn)。

當(dāng)然，以上這些建議也存在一定弊端。其中最主要的問題是它們難于實(shí)現(xiàn)，同時也會給現(xiàn)有流程帶來極大顛覆。是的，如果我們生活在十年前的IT世界中，那么根本沒必要采取這樣***破壞性的新革手段。

然而歷史的車輪無法逆轉(zhuǎn)，在如今的技術(shù)世界中、企業(yè)變革的步伐正逐漸加快，我們也不得不對已經(jīng)效力多年的IT流程作出調(diào)整。為了追求效率并降低運(yùn)營成本，我們需要直面否定以往三十年經(jīng)驗(yàn)所帶來的陣痛與阻力。過去總是美好的，但I(xiàn)T部門永遠(yuǎn)不可能重現(xiàn)當(dāng)初那段用三十年時間完成同一項任務(wù)的輕松時光——時至今日，擺在面前的是更嚴(yán)苛、但又絲毫無法妥協(xié)的要求，除了接受別無它法。

英文原文：How DevOps Can Accelerate the Cloud Application Lifecycle