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

[[109030]] 

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

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

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

云計算給IT部門——而非基礎設施——帶來壓力

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

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

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

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

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

文化轉變是必要的，但單憑這一點還遠遠不夠

文化轉變是我們經常聽到的解決方案之一。從這個角度出發，開發人員與系統管理員通過加入同一團隊的方式彼此協作，從而加強聯動效果、最終加快應用程序生命周期。

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

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

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

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

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

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

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

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

持續部署需要自動化、集成化與均衡的激勵機制

為了實現持續部署流程，必須滿足以下四點前提條件。

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

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

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

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

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

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

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

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