DevOps，不是一個(gè)傳說！

DevOps，不是一個(gè)傳說！

7月12，VMware網(wǎng)絡(luò)云博會(huì)，iPhone4S,iPad,XBox360等你拿，點(diǎn)擊了解詳情

WikiPedia上說："DevOps是軟件開發(fā)、運(yùn)維和質(zhì)量保證三個(gè)部門之間的溝通、協(xié)作和集成所采用的流程、方法和體系的一個(gè)集合。它是人們?yōu)榱思皶r(shí)生產(chǎn)軟件產(chǎn)品或服務(wù)，以滿足某個(gè)業(yè)務(wù)目標(biāo)，對(duì)開發(fā)與運(yùn)維之間相互依存關(guān)系的一種新的理解。"這恰好體現(xiàn)了精益管理中的客戶價(jià)值原則，即：以客戶的觀點(diǎn)來(lái)確定企業(yè)從設(shè)計(jì)到生產(chǎn)交付的全部過程，實(shí)現(xiàn)客戶需求的最大滿足。我們也可以把DevOps看作是一種能力，在缺乏這種能力的組織中，開發(fā)與運(yùn)維之間存在著信息"鴻溝"。

如何獲得這種能力呢？關(guān)鍵有兩點(diǎn)：一是全局觀：要從軟件交付的全局出發(fā)，加強(qiáng)各角色之前的合作；二是自動(dòng)化：人機(jī)交互就意味著手工操作，應(yīng)選擇那些支持腳本化、無(wú)需人機(jī)交互界面的強(qiáng)大管理工具，比如各種受版本控制的script，以及類似于Nagios這樣的基礎(chǔ)設(shè)施監(jiān)控工具，類似于Puppet、Chef這樣的基礎(chǔ)設(shè)施配置管理工具。

有人評(píng)論說："針對(duì)目前國(guó)內(nèi)情況，DevOps還是很遙遠(yuǎn)。也許只有行業(yè)頂尖的公司，或者新成立的公司會(huì)有這樣的嘗試。大多數(shù)的企業(yè)還未開始進(jìn)行敏捷的推進(jìn)，傳統(tǒng)的重重阻礙會(huì)使敏捷的推進(jìn)進(jìn)程遙遙無(wú)期。" DevOps真的離我們有那么遠(yuǎn)嗎？DevOps應(yīng)該從哪里開始呢？

一、讓數(shù)據(jù)說話

讓我們看一看百度某產(chǎn)品線在半年內(nèi)的變化吧。首先要說明兩個(gè)百度術(shù)語(yǔ)。"提測(cè)"是指某個(gè)項(xiàng)目開發(fā)完成后，在正式上線前，將其提交給測(cè)試組進(jìn)行測(cè)試的活動(dòng)。對(duì)于客戶來(lái)說，"提測(cè)"這個(gè)動(dòng)作本身并不增加什么價(jià)值，但也需要花費(fèi)一定的時(shí)間。"上線"是指某個(gè)項(xiàng)目驗(yàn)證合格后，將其部署到服務(wù)器的過程，其中包括"上線申請(qǐng)"和"實(shí)際部署"兩個(gè)活動(dòng)。也許在各公司中對(duì)這兩個(gè)活動(dòng)叫法不同，但在軟件生命周期中，"提測(cè)"、"上線"這兩件事無(wú)論花長(zhǎng)時(shí)間，大家可能都不會(huì)感到奇怪。下面兩張圖是該產(chǎn)品線進(jìn)行改進(jìn)之后的對(duì)比數(shù)據(jù)。

從圖中不難看出，提測(cè)和上線部署的效率已大大提高。象百度這樣的互聯(lián)網(wǎng)企業(yè)，產(chǎn)品線多得數(shù)不清，幾乎每個(gè)產(chǎn)品線每周都有新功能部署。僅從這兩個(gè)數(shù)據(jù)來(lái)看，其收益可想而知。那么，半年前的狀況是什么樣的呢？

二、流程建模

既然DevOps關(guān)注于價(jià)值交付的全過程，那就讓我們看看該產(chǎn)品線常見的交付過程吧。

對(duì)于單個(gè)項(xiàng)目來(lái)說，它大體上是一個(gè)典型的瀑布開發(fā)過程。首先是需求收集與整理，撰寫MRD(Marketing Requirement Document)或總體設(shè)計(jì)后，進(jìn)行評(píng)審。如果涉及到多模塊，每個(gè)模塊的開發(fā)人員會(huì)對(duì)各自負(fù)責(zé)的模塊進(jìn)行詳細(xì)設(shè)計(jì)，給出大致的開發(fā)計(jì)劃，并商定聯(lián)調(diào)時(shí)間點(diǎn)。之后，開發(fā)人員會(huì)從主干上拉出項(xiàng)目分支，并在該分支上進(jìn)行開發(fā)。當(dāng)?shù)阶詈舐?lián)調(diào)點(diǎn)時(shí)，幾個(gè)開發(fā)人員才會(huì)在將代碼合在一起，進(jìn)行聯(lián)調(diào)。當(dāng)調(diào)通之后，開發(fā)人員再申請(qǐng)?zhí)釡y(cè)。測(cè)試人員接到提測(cè)申請(qǐng)單后，進(jìn)行測(cè)試，記錄Bug，通知開發(fā)人員修復(fù)，直致質(zhì)量達(dá)到標(biāo)準(zhǔn)。之后，開發(fā)人員會(huì)填寫上線申請(qǐng)單，經(jīng)運(yùn)維人員確認(rèn)后，運(yùn)維人員操作進(jìn)行上線部署工作。如圖所示。

開發(fā)的復(fù)雜性還在于：該產(chǎn)品線有很多并行項(xiàng)目，為了避免互相干擾可能帶來(lái)的沖突，每個(gè)項(xiàng)目啟動(dòng)后都會(huì)重新在主干上拉出分支，在上線前才進(jìn)行合并。如下圖所示。

另外，并行項(xiàng)目太多，導(dǎo)致每個(gè)開發(fā)人員會(huì)同時(shí)參與多個(gè)處于不同階段的項(xiàng)目。那些周期較長(zhǎng)的項(xiàng)目雖然會(huì)被分解成多個(gè)迭代，但每個(gè)迭代內(nèi)都是同樣的開發(fā)流程，只是最后僅有一次上線而已。

總而言之，突出的問題表現(xiàn)在：

1. 同一角色多個(gè)人員的合作開發(fā)；
2. 各角色部門之間的協(xié)作以各自的產(chǎn)品物為目標(biāo)，如MRD、產(chǎn)品代碼、測(cè)試用例、上線操作單；
3. 基于人機(jī)交互方式的內(nèi)部流程管理平臺(tái)。

三、發(fā)現(xiàn)浪費(fèi)

從精益思想出發(fā)，為了盡早交付價(jià)值，必須首先找出整個(gè)流程中的浪費(fèi)，并將其消除，從而提高流程效率，讓"一個(gè)想法從提出到實(shí)現(xiàn)"可在最短時(shí)間里完成。那么，浪費(fèi)到底表現(xiàn)在哪里呢？

• 一些不必要的多分支開發(fā)，合并后發(fā)生問題的風(fēng)險(xiǎn)高。 多個(gè)項(xiàng)目中可能都要修改同一個(gè)模塊的代碼，每次在最后合并代碼時(shí)都會(huì)出現(xiàn)一些問題，非常痛苦，尤其是修改比較大的時(shí)候，合并及修復(fù)時(shí)間較長(zhǎng)。
• 推遲問題被發(fā)現(xiàn)的時(shí)間。 每個(gè)開發(fā)人員會(huì)將需求分解成多個(gè)技術(shù)任務(wù)后開發(fā)。所以，所有任務(wù)完成之前，應(yīng)用程序一直處于不可用狀態(tài)。當(dāng)最后在一起聯(lián)調(diào)時(shí)，常常會(huì)發(fā)現(xiàn)一些意想不到的問題。
• 基于流程平臺(tái)的溝通。 在提測(cè)環(huán)節(jié)中，溝通完全基于內(nèi)部項(xiàng)目管理平臺(tái)和即時(shí)消息工具或Email。比如開發(fā)人員在提測(cè)前，需要在項(xiàng)目管理平臺(tái)上申請(qǐng)?jiān)擁?xiàng)目的4位版本。拿到4位版本后，才能提交平臺(tái)統(tǒng)一編譯。如果編譯失敗，那么問題解決后還要再次申請(qǐng)4維版本。如果成功，則在項(xiàng)目管理平臺(tái)上填寫表單，回答一系列的問題（比如，是否做過單測(cè)？測(cè)了哪些功能點(diǎn)？部署步驟是什么？），發(fā)起提測(cè)工作流，管理平臺(tái)會(huì)自動(dòng)發(fā)送電子郵件給相關(guān)測(cè)試人員，通知他們進(jìn)行測(cè)試。測(cè)試人員收到該提測(cè)工作流后，必須在平臺(tái)上進(jìn)行相關(guān)確認(rèn)操作，通知開發(fā)人員已收到該版本。如果測(cè)試人員對(duì)部署和測(cè)試內(nèi)容有疑問的話，還會(huì)通過即時(shí)通訊工具或郵件與開發(fā)人員進(jìn)行確認(rèn)。
• 常規(guī)的例行工作很難自動(dòng)化。 上線部署也需要通過內(nèi)部平臺(tái)來(lái)完成。開發(fā)人員拿到已測(cè)試通過的4位版本后，先要登錄到內(nèi)部平臺(tái)，再提交上線申請(qǐng)單，填寫上線步驟。當(dāng)運(yùn)維人員收到上線步驟后，再將其"翻譯"成平臺(tái)可以識(shí)別的"半自動(dòng)上線步驟"，再讓平臺(tái)來(lái)執(zhí)行。如果運(yùn)維人員不理解上線步驟，就要和開發(fā)人員通過電子郵件或即時(shí)通訊工作等進(jìn)行反復(fù)確認(rèn)。部署配置信息分散在各處。如下圖所示：
  

  

另外，該產(chǎn)品的一個(gè)重要特征是需要不斷地嘗試調(diào)整程序算法策略，以得到最佳的流量效果，而這種調(diào)整的頻率較高（至少每周一次）。當(dāng)需要調(diào)整策略時(shí)，開發(fā)人員修改代碼后重新進(jìn)行編譯打包，由于產(chǎn)品代碼發(fā)生變化，所以測(cè)試人員仍需要進(jìn)行大量的回歸測(cè)試，而運(yùn)維人員在部署時(shí)也需要將對(duì)二進(jìn)制文件包進(jìn)行整體部署，整個(gè)周期比較長(zhǎng)。

從上面這些內(nèi)容中，我們不難發(fā)現(xiàn)，流程中更傾向于將問題推遲到后面解決（比如最后集成聯(lián)調(diào)），將工具（平臺(tái)、郵件、即時(shí)通訊）作為協(xié)作的基礎(chǔ)，而角色間的溝通幾乎完全依賴于前一個(gè)環(huán)節(jié)的產(chǎn)物（比如MRD、產(chǎn)品代碼、上線步驟）。那么我們使用哪些對(duì)策進(jìn)行優(yōu)化，達(dá)到消除浪費(fèi)的目的呢？

四、應(yīng)對(duì)措施

1. 無(wú)人工干預(yù)方式的腳本自動(dòng)化

• 自動(dòng)化提測(cè) ——由于已做到了每日集成，所以每天都有可測(cè)試的版本，開發(fā)人員不再需要為提測(cè)進(jìn)行專門的準(zhǔn)備工作，只要從成功構(gòu)建的列表中選擇一個(gè)給測(cè)試人員就可以了。使用Hudson平臺(tái)后，通過插件即可調(diào)用自動(dòng)化腳本，完成提測(cè)版本的標(biāo)識(shí)。
• 統(tǒng)一配置信息源 ——將所有的配置項(xiàng)全部放在Subversion庫(kù)中進(jìn)行版本控制；并根據(jù)應(yīng)用環(huán)境的不同，分別保存在Dev，Test和Online三個(gè)目錄中。
  

  

• 常規(guī)流程腳本化 ——經(jīng)過各角色的共同討論和可行性分析，最后配置上線部署的實(shí)施方案是：由開發(fā)人員將產(chǎn)品二進(jìn)制包與配置項(xiàng)進(jìn)行剝離，這樣僅做策略調(diào)整時(shí)，測(cè)試人員只要對(duì)已修改的配置項(xiàng)進(jìn)行相關(guān)測(cè)試即可。運(yùn)維人員用一系列的腳本代替了內(nèi)部運(yùn)維平臺(tái)的手工上線操作，再通過Hudson平臺(tái)的插件，以 "Click Button"的方式達(dá)到了一鍵式部署。

2. 盡早發(fā)現(xiàn)問題，解決問題

• " 需求細(xì)分，及時(shí)開發(fā)，及時(shí)驗(yàn)證 " ——將需求拆分成端到端可測(cè)試的需求（即"用戶故事"），這些需求一般可在3天內(nèi)完成。在實(shí)現(xiàn)每個(gè)需求之前，開發(fā)人員與測(cè)試人員進(jìn)行充分溝通，對(duì)需求與驗(yàn)收條件達(dá)成共識(shí)。每開發(fā)完成一個(gè)用戶故事，就進(jìn)行測(cè)試，并用自動(dòng)化測(cè)試進(jìn)行覆蓋。
• " 主干開發(fā)，分支提測(cè) " ——將原來(lái)的多個(gè)分支進(jìn)行合并，統(tǒng)一在主干上開發(fā)，每周結(jié)束時(shí)拉出一個(gè)分支，進(jìn)行提測(cè)，一旦發(fā)現(xiàn)問題，就在主干上修復(fù)。
• " 持續(xù)集成 " ——為了確保每次提交質(zhì)量，對(duì)主干開發(fā)建立持續(xù)集成環(huán)境，開發(fā)人員和自動(dòng)化測(cè)試人員都嚴(yán)格遵守持續(xù)集成紀(jì)律"Check-in Dance"。

新的開發(fā)流程如下圖所示。

分支開發(fā)策略變更為Single Branch模式。

五、小結(jié)

通過以上改進(jìn)措施，讓團(tuán)隊(duì)的合作方式發(fā)生了重大變化，從"碉堡防御"走向了"戰(zhàn)線統(tǒng)一"。

原來(lái)，各角色僅關(guān)注于自己本身的工作，雖然大家都同處于一個(gè)項(xiàng)目中，但各自劃分了"領(lǐng)地"，產(chǎn)品經(jīng)理就應(yīng)該將MRD寫得清清楚楚，如果開發(fā)人員認(rèn)為不清楚，那就回去再改。開發(fā)人員只管按照MRD上的內(nèi)容進(jìn)行開發(fā)，很少考慮可測(cè)性和易測(cè)性問題。測(cè)試人員只管按照MRD中內(nèi)容來(lái)測(cè)試，有問題通過內(nèi)部工作流平臺(tái)提交問題單。運(yùn)維人員只管根據(jù)開發(fā)人員提交的上線操作單進(jìn)行操作。似乎各角色之間的溝通介質(zhì)只有各自的"交付物"。

現(xiàn)在，各角色都能夠共同合作，以項(xiàng)目的最終交付為目標(biāo)，積極討論需求，優(yōu)化實(shí)現(xiàn)。因?yàn)榻巧g的這種緊密合作讓所有人對(duì)不同角色都有了深入的了解。開發(fā)人員耐心為產(chǎn)品經(jīng)理解釋技術(shù)實(shí)現(xiàn)，說明計(jì)劃安排，測(cè)試人員與開發(fā)人員共同討論驗(yàn)收條件，避免遺漏需求。開發(fā)人員讓運(yùn)維人員了解架構(gòu)設(shè)計(jì)， 細(xì)心聽取運(yùn)維人員的建議，進(jìn)行技術(shù)改造，使部署工作更快捷有效。

通過這些活動(dòng)，大家都認(rèn)識(shí)到原有內(nèi)部管理平臺(tái)僅是個(gè)公文流轉(zhuǎn)的支撐平臺(tái)，要想提高工作效率，就要將這種"辦公自動(dòng)化工具"進(jìn)一步提升為"全面自動(dòng)化工具"，使所有人更關(guān)注于端到端的價(jià)值，而非各角色之間的分界點(diǎn)。

六、結(jié)束語(yǔ)

百度剛剛開始敏捷之旅，還沒人談及"DevOps"運(yùn)動(dòng)，雖然還沒有什么強(qiáng)大的工具支撐，但基于"提高效率"的樸素思想進(jìn)行的過程改進(jìn)也帶來(lái)了"DevOps"效果。可見，DevOps聽上去很神秘，但其實(shí)并不難。只要本著精益思想，聚焦于快速交付價(jià)值，不斷發(fā)現(xiàn)并消除浪費(fèi)，你也一定會(huì)有很大收獲。

DevOps，不是一個(gè)傳說！