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

[[135922]]

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

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

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

基本原則

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

• 接受失敗
• 分析失敗原因，但不苛責任何相關人員
• 在了解理由后快速修正失敗因素
• 永遠保持迭代

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

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

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

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

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

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

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

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

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

• 哪些員工能夠編寫軟件?是否每位員工都有能力編寫軟件?
• 在學習軟件編寫的過程中，是否存在著明顯的入門壁壘?
• 將工作代碼向同事展示到底有多困難?
• 同事運行我們的展示代碼到底有多困難?
• 哪些員工能夠部署這些軟件?
• 在學習部署軟件的過程中，是否存在著明顯的入門壁壘?
• 我們需要在哪里進行任務分配?
• 我們需要在哪里討論新功能的引入?

#p#

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

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

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

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

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

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

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

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

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

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

前方的道路還很崎嶇，請做好心理準備!

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

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

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

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

內容概述

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

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

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

原文標題：Beginning software delivery acceleration with DevOps