建站
咨詢
售后
建站咨詢
新聞中心
在過(guò)去，基礎(chǔ)設(shè)施部署與應(yīng)用程序更新一直是延緩開發(fā)生命周期的兩大主要障礙。時(shí)至今日，云計(jì)算的蓬勃發(fā)展讓企業(yè)用戶得以將以往需要耗時(shí)數(shù)月的資源配置工作在幾分鐘內(nèi)完成，因此也給應(yīng)用程序的生命周期帶來(lái)了相應(yīng)改變。話說(shuō)回來(lái)，雖然DevOps確實(shí)能夠幫上大忙，但只有以超越“文化轉(zhuǎn)變”的角度積極拓展才能真正讓這種新方案實(shí)現(xiàn)持續(xù)部署。
正如我在上一篇專題文章中所說(shuō)，很明顯云計(jì)算給應(yīng)用程序帶來(lái)更多可能性、強(qiáng)制性以及巨大變化。通過(guò)那篇文章，我把重點(diǎn)放在了技術(shù)變化的探討方面，評(píng)述云計(jì)算對(duì)應(yīng)用程序架構(gòu)造成的影響——相信大家已經(jīng)感覺到，如今的應(yīng)用程序架構(gòu)開始把支持不斷提高的規(guī)模與負(fù)載變化、更強(qiáng)烈的性能需求以及由云計(jì)算引發(fā)的定價(jià)模式轉(zhuǎn)變納入設(shè)計(jì)思路當(dāng)中。
但當(dāng)時(shí)我并沒有談及云計(jì)算所顛覆的另一種傳統(tǒng)應(yīng)用程序要素，也就是應(yīng)用程序生命周期。具體而言，云計(jì)算需要與更為迅捷的應(yīng)用程序管理節(jié)奏相匹配，而這將迫使IT部門作出相應(yīng)調(diào)整。
從表面上看，我們可能很難理解為什么云計(jì)算所帶來(lái)的技術(shù)能力會(huì)對(duì)IT部門及其運(yùn)作流程產(chǎn)生影響。但是，云計(jì)算通過(guò)技術(shù)能力所帶來(lái)的關(guān)鍵性基礎(chǔ)——也就是自動(dòng)化特性——必然要求更快的應(yīng)用程序生命周期與之相匹配。
云計(jì)算給IT部門——而非基礎(chǔ)設(shè)施——帶來(lái)壓力
在云計(jì)算出現(xiàn)之前，技術(shù)團(tuán)隊(duì)完全可以悠哉悠哉地創(chuàng)建應(yīng)用功能并將其交付到管理者手中，快一點(diǎn)或者慢一點(diǎn)都不是什么大問(wèn)題。在這種情況下，底層基礎(chǔ)設(shè)施資源將承受巨大壓力，因?yàn)榭焖俑倪M(jìn)應(yīng)用程序功能并針對(duì)生產(chǎn)環(huán)境進(jìn)行頻繁更新成為保障運(yùn)作流程的前提。由于采購(gòu)、安置以及配置基礎(chǔ)設(shè)施所耗費(fèi)的時(shí)間太過(guò)漫長(zhǎng)，因此應(yīng)用程序開發(fā)以及部署所帶來(lái)的周期幾乎不會(huì)成為主要矛盾。換句話來(lái)說(shuō)，基礎(chǔ)設(shè)施方面的難題將應(yīng)用程序周期掩蓋掉了。
云計(jì)算的自動(dòng)化特性將全部基礎(chǔ)設(shè)施矛盾消弭于無(wú)形。時(shí)至今日，我們只需要花上幾分鐘時(shí)間、就能獲得大量全新計(jì)算資源——這在過(guò)去根本無(wú)法想象，那時(shí)候讓全新基礎(chǔ)設(shè)施資源投入運(yùn)作通常要花費(fèi)數(shù)周乃至數(shù)月時(shí)間。很明顯，目前基礎(chǔ)設(shè)施配置所需要的具體時(shí)長(zhǎng)取決于IT部門的執(zhí)行流程，而不再受制于底層基礎(chǔ)設(shè)施資源本身。
與此同時(shí)，數(shù)字化信息正越來(lái)越多地與主流業(yè)務(wù)產(chǎn)品相集成。以接入互聯(lián)網(wǎng)的Nest恒溫裝置為例，這類產(chǎn)品意味著業(yè)務(wù)執(zhí)行的實(shí)際效果開始高度依賴于應(yīng)用程序功能可用性的交付速度。沒有了基礎(chǔ)設(shè)施帶來(lái)的局限，現(xiàn)在的主要障礙已經(jīng)轉(zhuǎn)變?yōu)閼?yīng)用程序生命周期本身。因此，我們可以預(yù)見，下一階段的主要矛盾將由云計(jì)算與應(yīng)用程序開發(fā)及部署流程的錯(cuò)位所引發(fā)。簡(jiǎn)而言之，IT部門必須加快應(yīng)用程序生命周期。
面對(duì)這樣的矛盾，DevOps粉墨登場(chǎng)。這個(gè)混合詞將“開發(fā)（Development）”與“運(yùn)營(yíng)（Operations）”雜糅于一處，代表著原本彼此獨(dú)立的各組織與流程正式走向融合。這個(gè)新名詞所代表的愿景在于由精簡(jiǎn)化、集成化組織通過(guò)聯(lián)合運(yùn)營(yíng)流程對(duì)應(yīng)用程序更新進(jìn)行加速，從而將過(guò)去需要數(shù)周乃至數(shù)月才能完成的應(yīng)用生命周期縮減至如今的數(shù)小時(shí)或者最多數(shù)天。
但DevOps要如何才能為我們帶來(lái)神奇的提升效果？
文化轉(zhuǎn)變是必要的，但單憑這一點(diǎn)還遠(yuǎn)遠(yuǎn)不夠
文化轉(zhuǎn)變是我們經(jīng)常聽到的解決方案之一。從這個(gè)角度出發(fā)，開發(fā)人員與系統(tǒng)管理員通過(guò)加入同一團(tuán)隊(duì)的方式彼此協(xié)作，從而加強(qiáng)聯(lián)動(dòng)效果、最終加快應(yīng)用程序生命周期。
我個(gè)人對(duì)這類方案并不太看好。沒錯(cuò)，開發(fā)與運(yùn)營(yíng)體系之間往往存在矛盾，而讓雙方工作人員身處同一團(tuán)隊(duì)無(wú)疑能夠改善人際關(guān)系。平心而論，這類方案確實(shí)有可能通過(guò)促進(jìn)合作、減少指責(zé)來(lái)推動(dòng)當(dāng)前工作狀態(tài)。然而從科學(xué)層面分析，我們很難確切證實(shí)改善人際關(guān)系與加快應(yīng)用程序功能發(fā)布周期之間的必要聯(lián)系。
在任何情況下，漸進(jìn)式改善都還遠(yuǎn)遠(yuǎn)不夠。企業(yè)沒辦法僅僅依賴20%的功能構(gòu)建效率增幅保證自身在未來(lái)數(shù)字化業(yè)務(wù)環(huán)境下取得成功。因?yàn)樵谶@種情況下，實(shí)際效果只能是將項(xiàng)目的開發(fā)周期由過(guò)去的21天縮短為現(xiàn)在的18天，或者舉個(gè)更常見的例子，由原本的六個(gè)月縮短至五個(gè)月。要在如今的激烈競(jìng)爭(zhēng)中保持優(yōu)勢(shì)，業(yè)務(wù)流程的速度提升至少要達(dá)到200%才算合格。
另外，“文化”這一表述也屬于一種誤導(dǎo)。文化關(guān)注的是人為因素而非流程——這相當(dāng)于對(duì)流程的一種顛覆。再有，即使速度有所加快，流程本身也需要真正貫穿應(yīng)用程序生命周期始終才能帶來(lái)確切成效。
也就是說(shuō)，我們已經(jīng)在軟件工程層面上取得了重大進(jìn)展。在過(guò)去十年當(dāng)中，開發(fā)實(shí)踐、靈活的工作方式、頻繁登記以及自動(dòng)化機(jī)制的建立與測(cè)試已經(jīng)帶來(lái)了非常可觀的加速效果。這場(chǎng)被稱為“持續(xù)集成”的革命幫助我們縮短開發(fā)周期、降低項(xiàng)目事故并使整個(gè)項(xiàng)目流程更具可預(yù)測(cè)性。
不過(guò)對(duì)于多數(shù)IT部門而言，在談到將新代碼投入生產(chǎn)體系當(dāng)中時(shí)，應(yīng)用程序生命周期的加速步伐往往就此戛然而止。在實(shí)際運(yùn)營(yíng)情況下，由于每個(gè)下游團(tuán)隊(duì)都需要利用自己選擇的工具進(jìn)行任務(wù)處理，因此各個(gè)環(huán)節(jié)往往都需要以手動(dòng)方式進(jìn)行一次又一次冗余操作——這就破壞了流程的自動(dòng)化屬性。
惟一的解決方式在于保證IT部門實(shí)現(xiàn)持續(xù)部署，在這種情況下代碼修改將貫穿整個(gè)自動(dòng)化應(yīng)用程序生命周期始終，業(yè)務(wù)流程快速響應(yīng)所帶來(lái)的穩(wěn)定性影響以及頻繁的功能更新也將得到解決。作為負(fù)面影響，持續(xù)集成會(huì)助長(zhǎng)IT部門對(duì)于自主解決方案的信心，導(dǎo)致業(yè)務(wù)部門難以將應(yīng)用程序供應(yīng)商引入整個(gè)運(yùn)營(yíng)體系當(dāng)中。
我曾經(jīng)聽說(shuō)過(guò)很多圍繞持續(xù)部署所展開的爭(zhēng)論。他們的核心分歧在于惡意代碼進(jìn)入生產(chǎn)環(huán)境的可能性，以及在執(zhí)行終端到終端自動(dòng)化機(jī)制后惡意軟件所將引發(fā)的嚴(yán)重后果。說(shuō)到底，這場(chǎng)爭(zhēng)論的實(shí)質(zhì)在于，如果沒有人為因素的干預(yù)、自動(dòng)化流程會(huì)出現(xiàn)問(wèn)題。
我們姑且不談這樣的結(jié)論到底跟廢話有什么區(qū)別，其實(shí)根據(jù)我的個(gè)人經(jīng)驗(yàn)，就算存在人為干預(yù)、問(wèn)題也照樣有可能出現(xiàn)。更進(jìn)一步，人為干預(yù)也可能成為引發(fā)問(wèn)題的誘因，因此我對(duì)這樣的說(shuō)辭并不買賬。在任何情況下，對(duì)于手動(dòng)執(zhí)行流程的要求最終都會(huì)被用戶需求所否決。一味堅(jiān)持既定方法將是完全徒勞的。如果不相信，大家可以問(wèn)問(wèn)VMware的系統(tǒng)管理員——由于他們要求開發(fā)人員等待數(shù)周的審批來(lái)使用虛擬巨頭的內(nèi)部資源，這些開發(fā)者直接把自己的虛擬機(jī)交給了Amazon Web Services。
持續(xù)部署需要自動(dòng)化、集成化與均衡的激勵(lì)機(jī)制
為了實(shí)現(xiàn)持續(xù)部署流程，必須滿足以下四點(diǎn)前提條件。
一套簡(jiǎn)潔的自動(dòng)化流程。如果流程當(dāng)中包含由審計(jì)委員會(huì)設(shè)定的階段性目標(biāo)、未經(jīng)批準(zhǔn)無(wú)法進(jìn)入下一步執(zhí)行環(huán)節(jié)或者其它形式的人為監(jiān)督機(jī)制，那么整個(gè)體系的運(yùn)作效率必然大打折扣。雖然我們主張將特定變更劃分在自動(dòng)化流程之外——可能出于復(fù)雜性或者其它特定因素的考量，但這與將全部變更都納入人為干擾范疇完全不同。最理想的方式是在必要情況下引入人為干預(yù)因素，但除此之外的常規(guī)變更都由自動(dòng)化流程打理。
一套集成化、終端到終端工具鏈。很明顯，除非整個(gè)流程都擁有理想工具作為底層支持，否則自動(dòng)化工作流程根本就是紙上談兵。從本質(zhì)上講，這些工具在某一階段中的輸出內(nèi)容都要能夠?yàn)橄乱浑A段的工具所接納，也就是說(shuō)各類工具之間能夠順暢銜接。時(shí)至今日，我們完全可以在大型廠商手中直接購(gòu)買昂貴的專有產(chǎn)品、也能夠以開源組件為基礎(chǔ)自主構(gòu)建適合實(shí)際需求的功能集合。任何一種方案都既有長(zhǎng)處、也有短板。隨著這一領(lǐng)域重要性的日益增加，市場(chǎng)對(duì)其的關(guān)注程度也將水漲船高，相信更多更靈活也更加實(shí)惠的解決方案很快就會(huì)出現(xiàn)在市場(chǎng)當(dāng)中。
共享化應(yīng)用程序構(gòu)件。新增工具所采用的構(gòu)件必須能夠與整個(gè)體系順利對(duì)接。由此帶來(lái)的可執(zhí)行文件以及配置創(chuàng)建工作，甚至包括制定自動(dòng)運(yùn)行說(shuō)明在內(nèi)，都有可能引發(fā)潛在的出錯(cuò)風(fēng)險(xiǎn)，進(jìn)而對(duì)功能的快速可用性產(chǎn)生影響。相比之下，最理想的處理方式是利用單一構(gòu)件集貫穿整個(gè)流程，并通過(guò)加減權(quán)限劃分出適合需求的組織結(jié)構(gòu)。
在整個(gè)企業(yè)內(nèi)保證指標(biāo)與激勵(lì)機(jī)制均衡。說(shuō)到激勵(lì)機(jī)制，我們?cè)俅位氐搅恕拔幕边@一話題上來(lái)。如前面提到，我個(gè)人并不太相信僅僅通過(guò)發(fā)展人際關(guān)系就足以將不同群體團(tuán)結(jié)在一起、甚至徹底消除協(xié)作中的摩擦與失誤。要真正實(shí)現(xiàn)這樣的效果，均衡的評(píng)比指標(biāo)與激勵(lì)機(jī)制才是重中之重。如果我們以功能更新的發(fā)布頻率作為某個(gè)團(tuán)隊(duì)的評(píng)比標(biāo)準(zhǔn)、卻通過(guò)運(yùn)行穩(wěn)定性作為另一個(gè)團(tuán)隊(duì)的評(píng)比標(biāo)準(zhǔn)，那么雙方將由于不具可比性而出現(xiàn)績(jī)效考核方面的沖突。
我們需要通過(guò)一系更措施將每一位成員緊密團(tuán)結(jié)在一起。千萬(wàn)別以為將前面提到的各類指標(biāo)一股腦塞進(jìn)來(lái)就能獲得理想的收效，事實(shí)上要求同一個(gè)團(tuán)隊(duì)既能頻繁推出更新、又保證成果的運(yùn)行穩(wěn)定性，這本身就會(huì)引發(fā)嚴(yán)重不滿——很明顯，這樣的目標(biāo)需要由多個(gè)團(tuán)隊(duì)協(xié)作才有可能實(shí)現(xiàn)。
當(dāng)然，以上這些建議也存在一定弊端。其中最主要的問(wèn)題是它們難于實(shí)現(xiàn)，同時(shí)也會(huì)給現(xiàn)有流程帶來(lái)極大顛覆。是的，如果我們生活在十年前的IT世界中，那么根本沒必要采取這樣***破壞性的新革手段。
然而歷史的車輪無(wú)法逆轉(zhuǎn)，在如今的技術(shù)世界中、企業(yè)變革的步伐正逐漸加快，我們也不得不對(duì)已經(jīng)效力多年的IT流程作出調(diào)整。為了追求效率并降低運(yùn)營(yíng)成本，我們需要直面否定以往三十年經(jīng)驗(yàn)所帶來(lái)的陣痛與阻力。過(guò)去總是美好的，但I(xiàn)T部門永遠(yuǎn)不可能重現(xiàn)當(dāng)初那段用三十年時(shí)間完成同一項(xiàng)任務(wù)的輕松時(shí)光——時(shí)至今日，擺在面前的是更嚴(yán)苛、但又絲毫無(wú)法妥協(xié)的要求，除了接受別無(wú)它法。
英文原文：How DevOps Can Accelerate the Cloud Application Lifecycle
分享標(biāo)題：DevOps如何加快云應(yīng)用程序生命周期
網(wǎng)頁(yè)路徑：http://fisionsoft.com.cn/article/cogcice.html
