一次又一次，我們不斷聽說眾多企業(yè)客戶利用DevOps機(jī)制實現(xiàn)快速交付。各大廠商每天也在不斷宣揚著利用此類部署獲得成功的實際案例，并鼓吹稱借此能夠?qū)崿F(xiàn)每天十套、五十套甚至上百套業(yè)務(wù)線的部署工作。而在LinkedIn、Netflix、Etsy、Facebook以及其它成熟企業(yè)當(dāng)中，這一數(shù)字甚至能夠突破上千套。不過，這一切到底意思著什么?

IT領(lǐng)導(dǎo)者最喜歡談?wù)撨@些看起來令人振奮的數(shù)字，而且往往會將快速交付作為對話的主要關(guān)注焦點。然而這類軟件交付方式到底是否穩(wěn)定可靠?其中哪些部署方案能夠切實取得成功?整個部署流程又由哪些步驟來構(gòu)成?

這些問題往往最終造成分析癱瘓，但卻給不出任何一種有實際意義的結(jié)論。事實上，企業(yè)最常見的反往往是“在我們公司，我們沒辦法實現(xiàn)某種目標(biāo)，因為……”我們知道這種說法根本站不住腳。那些以瀑布式機(jī)制通過單一部署流程按月或者按季度進(jìn)行產(chǎn)品交付的傳統(tǒng)企業(yè)完全能夠與其它團(tuán)隊一樣，成功過渡至快速部署并由此擁有理想的交付能力。

那么我們要如何才能以軟件交付為起點享受此類成功果實?世界上并不存在萬靈藥或者一步到位的解決方案，但大家卻能夠通過方法論指導(dǎo)自身達(dá)成快速交付目標(biāo)。下面讓我們一同了解起步階段的必要任務(wù)。

基本原則

讓我們通過以下這些關(guān)鍵性原則來照亮通往光明彼岸的道路。它們分別是：

接受失敗

分析失敗原因，但不苛責(zé)任何相關(guān)人員

在了解理由后快速修正失敗因素

永遠(yuǎn)保持迭代

簡而言之，我們的目標(biāo)應(yīng)該是快速部署、快速失敗、快速學(xué)習(xí)而后快速改進(jìn)。這是一項永無止境的任務(wù)，而且我們也需要始終以這樣的思路看待整個流程。相信大家都曾經(jīng)經(jīng)歷過，一個項目在啟動過程中會將這些原則考量在內(nèi)，但隨著項目的終結(jié)、這一切最佳實踐也隨之消散。除非將持續(xù)改進(jìn)作為核心訴求傳遞給交付對象，否則任何一種努力都有可能隨著時間的推移而最終失效。

在將上述原則牢記在心之后，我們接著邁出下一步。

軟件是怎樣被開發(fā)出來的?

我們的第一站有時候并不從屬于交付組織，而體現(xiàn)在開發(fā)組織當(dāng)中。這也就是“移情”思維的作用所在，即站在對方的角度看待問題。DevOps概念也恰恰是針對這一焦點; 我們首先需要確保負(fù)責(zé)交付功能的開發(fā)人員具備獲得成功的一切要素。

軟件到底是如何被開發(fā)出來的?這一切對于生產(chǎn)流程究竟意味著什么?大家不妨向自己提出以下問題：代碼是如何被引入源代碼樹的?可接受代碼應(yīng)該具備哪些特點?(舉例來說，是否存在代碼格式指南或者必要測試等支持機(jī)制。)

一旦弄清了以上問題，接下來的關(guān)鍵就是將代碼進(jìn)行改善，從而將其推向交付的下一個階段。但這往往正是瓶頸的出現(xiàn)之處：雖然過去的歷史案例能夠起到有效的指導(dǎo)作用，從而以引入檢查點的方式來嘗試并改進(jìn)產(chǎn)品質(zhì)量，但這些檢查點通常以人為方式驅(qū)動——很明顯，人為方式總是有著種種自身缺陷。

最重要的一點是分清楚代碼交付或者功能交付與軟件本身交付之間的區(qū)別所在。雖然二者對于下一階段的工作來講都是非常重要的前提性條件，但雙方的職責(zé)往往各有所專。在整體系統(tǒng)當(dāng)中，我們的需求始終是一致的：尋求機(jī)會，通過拆分流程步驟的方式降低摩擦(即那些由傳統(tǒng)機(jī)制帶來的毫無價值的非必要因素)或者利用自動化方式推進(jìn)整個周期。

考慮到這一點，開發(fā)團(tuán)隊與運營團(tuán)隊之間的對話將帶來持久的啟發(fā)性成效，因為在充分交流之后、雙方都將清醒地意識到導(dǎo)致流程緩慢的原因所在。請大家繼續(xù)集中精神，讓我們繼續(xù)進(jìn)入下一個議題。

接下來的幾個問題請務(wù)必牢牢記在心中：

哪些員工能夠編寫軟件?是否每位員工都有能力編寫軟件?

在學(xué)習(xí)軟件編寫的過程中，是否存在著明顯的入門壁壘?

將工作代碼向同事展示到底有多困難?

同事運行我們的展示代碼到底有多困難?

哪些員工能夠部署這些軟件?

在學(xué)習(xí)部署軟件的過程中，是否存在著明顯的入門壁壘?

我們需要在哪里進(jìn)行任務(wù)分配?

我們需要在哪里討論新功能的引入?

以“高檔位”推動流程加速

到這一步，大家可能已經(jīng)擁有了一套軟件方案當(dāng)中需要改進(jìn)的各項條目的明確列表。但是，我們該把關(guān)注重點放在哪里?當(dāng)下的默認(rèn)思路是先理清發(fā)布機(jī)制，而后再嘗試與外部團(tuán)隊進(jìn)行良好協(xié)作。然而這其實是最不明智的作法，因為它最終將導(dǎo)致開發(fā)與運營團(tuán)隊之間產(chǎn)生無法逾越的鴻溝。因此對于大家來說，最好的判斷也許是將對接放在第一位。

我們的第一步工作應(yīng)當(dāng)集中在兩大主要目標(biāo)身上。第一是將自身嵌入到開發(fā)工作流程當(dāng)中……通過現(xiàn)有流程從開發(fā)任務(wù)內(nèi)提取項目元素，并提出針對性的主張。這些主張將成為我們的“第一個追蹤對象”，并幫助我們理解哪些變更能夠?qū)嶋H起效、而哪些不能。此外，它們還能夠帶來有價值且中肯的反饋意見，這往往是其他對項目進(jìn)度并不關(guān)注——或者說其主要精力集中在了其它工作上——的同事所無法提供的?？偠灾?，從小處著手幾乎是必要且最理想的處理方式。

在這一階段，DevOps會提出大量的所謂“移情”性觀點。無論是在改善產(chǎn)品方面投入怎樣的努力，一旦摩擦元素開始在開發(fā)者的日常工作當(dāng)中出現(xiàn)，那么變更帶來真正成功的可能性也將變得愈發(fā)低下。舉例來說：對大家而言，對底層交互平臺的變更也許能顯著改善溝通效果，但如果這種作法破壞了現(xiàn)有交付通道，那么結(jié)交新朋友的幾率很可能反而有所下降。

將自己的主張整理成開發(fā)報告，并提交給所在團(tuán)隊——反之亦然——最后將其納入整個執(zhí)行流程。另外，也不要忘記始終遵循前面提到過的基本原則……快速部署、快速失敗、快速學(xué)習(xí)與快速改進(jìn)。盡快修復(fù)易于處理的流程漏洞。再有，高度關(guān)注任何給定時間段內(nèi)引入的變量數(shù)量，不要害怕進(jìn)行變更，但同時始終保持變更的一致性并加以衡量。只要能夠長期堅持做到以上幾點，我們的整個交付流程將得到理想的調(diào)整與改進(jìn)。

與之同理，通過這一流程建立起真正的項目成果。早期的成功能夠確保開發(fā)人員得以通過最低限度的努力運行任意代碼版本(無論是git檢查版本還是其它主要版本)。

這使我能夠利用來自其他同事的代碼測試自己的開發(fā)成果修復(fù)效果、確認(rèn)漏洞以及其它類似的工作。擁有了運行任意代碼的能力，我們就能夠合作加快代碼的開發(fā)流程、降低開發(fā)末期可能遭遇的問題數(shù)量，這意味著大部分難題在流程早期就已經(jīng)得到了解決。這樣的效果對于階段性交付環(huán)境——很可能是本地開發(fā)環(huán)境——而言非常重要。不過除此之外，構(gòu)建起一套允許開發(fā)人員以小型獨立任務(wù)方式運行代碼的平臺同樣能夠有效支撐起后續(xù)的生產(chǎn)交付流程。

一旦大家發(fā)現(xiàn)流程及開發(fā)工作當(dāng)中出現(xiàn)了失誤，請千萬牢記一點：針對該失誤進(jìn)行分析與修復(fù)，但不要因此則苛責(zé)任何人。首先，這類問題的項目早期階段會大量出現(xiàn)，相信這也是我們每個人的共識。John Allspaw在他的文章當(dāng)中談到了這一點，并將激勵作為最主要的思維立足點：

“因為工程師們在心態(tài)上往往認(rèn)為自己針對特定故障的機(jī)制、原理以及操作方式給出理解所必需的細(xì)節(jié)信息的作法不會受到鼓勵、甚至可能因此而遭受指責(zé)。這種關(guān)于 問題發(fā)生原因的認(rèn)知缺失往往不斷重復(fù)出現(xiàn)。而如果后期負(fù)責(zé)相關(guān)工作的工程技術(shù)人員有所變動，那么未來還將有更多故障不斷涌現(xiàn)。”

另一個經(jīng)常被忽視的問題是這些解決方案的具體實現(xiàn)手段。此類修復(fù)流程不應(yīng)該由某一個人或者自上而下的方式予以驅(qū)動。相反，團(tuán)隊中的所有成員必須都能夠成為解決方案的組成部分。時間與鼓勵將在長期工作當(dāng)中起到非常積極的促進(jìn)作用。

最后，部署。項目的最終意義就是部署代碼。到這一步工作已經(jīng)基本結(jié)束，接下來要做的就是專注于開發(fā)與運營團(tuán)隊之間的相互作用，不過雙方也需要在一部分任務(wù)當(dāng)中共同協(xié)作。除非大家能夠以毫無瑕疵的方式完成日常部署，否則彼此溝通將貫穿整個部署流程。在每天的工作當(dāng)中，我們都應(yīng)該嘗試一次代碼部署——無論我們是否能夠預(yù)見到其實際效果。另外，每天找出一到兩個問題并加以修復(fù)：包括流程中的故障或者手動階段中的問題。重復(fù)這些任務(wù)，直到我們能夠以最低命令數(shù)量完成日常部署目標(biāo)(最好是一行命令就搞定)。

前方的道路還很崎嶇，請做好心理準(zhǔn)備!

在不斷推進(jìn)的過程中，我們將反復(fù)面對兩大關(guān)鍵性主題。第一就是通過溝通解決問題。隨著時間的推移，部署工作的推進(jìn)速度將不斷加快或者愈發(fā)精簡，但即使是最出色的團(tuán)隊也需要想辦法克服由溝通障礙所帶來的挑戰(zhàn)。

第二則是解決相關(guān)工具的使用能力問題。一旦工程師們開始引入實現(xiàn)過程所必需的工具，一切人為及流程因素都將居于次要地位——或者說以工具為核心加以適應(yīng)。這往往是道難以克服的關(guān)隘，因此此類工具要求軟件交付相關(guān)組織之內(nèi)的各位成員真正參與到溝通當(dāng)中。

考慮到這一點，我向大家推薦兩款能夠切實幫助各位突破阻礙的工具：CahtOps與Workflow。二者都屬于非常出色的解決方案，值得我們用專門的章節(jié)來加以闡述。不過受限于篇幅，我們在這里一言以蔽之：它們是軟件交付工作中必不可少的組成元素。

“ChatOps能夠?qū)⑽覀円呀?jīng)完成的工作以背景信息的方式添加到對話中來。” – James Fryman

“ Workflow所使用的可讀機(jī)器腳本語言絕不受限于對話范疇。它已經(jīng)成為在實時系統(tǒng)當(dāng)中以動態(tài)方式創(chuàng)建、上傳并更新工作流程的必要因素，并應(yīng)當(dāng)被作為“基礎(chǔ)設(shè)施即代碼”予以重視。” – Dmitri Zimine

請記?。簡栴}的關(guān)鍵并不限于單一工具。這些工具只是達(dá)成目標(biāo)的一種手段。人與流程需要成為對話中的核心組成部分。ChatOps能夠通過溝通及合作來創(chuàng)造并推動開發(fā)進(jìn)程。Workflow則從基礎(chǔ)設(shè)施流程角度出發(fā)實現(xiàn)整體協(xié)作。二者都應(yīng)該成為軟件交付工作中的必備元素。

內(nèi)容概述

為了獲得成功，作為技術(shù)人員的我們需要了解自己的組織當(dāng)中發(fā)生了什么、技術(shù)手段如何幫助交付流程達(dá)到預(yù)期效果，而技術(shù)元素又是如何被部署并被哪些用戶使用的。如果沒有清晰的理解，我們將陷入遇到問題就引入工具，但工具的出現(xiàn)反而增加了問題復(fù)雜性的惡性循環(huán)。在這種情況下，工具往往會成為流程推進(jìn)的瓶頸或者徹底淪為花瓶——因為人們根本就不打算真正加以使用。在快速發(fā)展的今天，精益化業(yè)務(wù)流程不會允許我們把時間浪費在故障身上。

您是否了解所在團(tuán)隊是如何交付軟件并在流程中實現(xiàn)協(xié)作的?您的團(tuán)隊與服務(wù)交付對象之間是否存在著緊密的反饋通道?您是否有能力實現(xiàn)快速行動，甚至以更快速度修復(fù)問題?

時至今日，軟件交付速度已經(jīng)被廣泛視為市場競爭中差異性優(yōu)勢的典型代表。通往這一目標(biāo)的道路既不平坦也不順暢，但一旦實現(xiàn)、我們的組織也就同時做好了邁入下一個快速成長階段的準(zhǔn)備。