DevOps，不是一個傳說！

DevOps最近成了熱詞，望文生義，你也能猜個八九不離十，它就是在說"研發團隊"與"營運團隊"之間的那點事兒。那麼，到底什麼是"DevOps"呢？

WikiPedia上說："DevOps是軟體開發、營運和品質保證三個部門之間的溝通、協作和整合所採用的流程、方法和體系的一個集合。它是人們 為了及時生產軟體產品或服務，以滿足某個營運目標，對開發與營運之間相互依存關係的一種新的理解。"這恰好體現了精益管理中的客戶價值原則，即：以客戶的 觀點來確定企業從設計到生產交付的全部過程，實現客戶需求的最大滿足。我們也可以把DevOps看作是一種能力，在缺乏這種能力的組織中，開發與營運之間 存在著資訊"鴻溝"。

如何獲得這種能力呢？關鍵有兩點：一是全域觀：要從軟體交付的全域出發，加強各角色之前的合作；二是自動化：人機互動就意味著手工操作，應選擇那些 支援指令碼化、無需人機互動介面的強大管理工具，比如各種受版本控制的script，以及類似於Nagios這樣的基礎設施監控工具，類似於Puppet、 Chef這樣的基礎設施組態管理工具。

有 人評論說："針對目前國內情況，DevOps還是很遙遠。也許只有行業頂尖的公司，或者新成立的公司會有這樣的嘗試。大多數的企業還未開始進行敏捷的推 進，傳統的重重阻礙會使敏捷的推進進程遙遙無期。" DevOps真的離我們有那麼遠嗎？DevOps應該從哪裡開始呢？

一、讓資料說話

讓我們看一看百度某產品線在半年內的變化吧。首先要說明兩個百度術語。"提測"是指某個項目開發完成後，在正式上線前，將其提交給測試組進行測試的 活動。對於客戶來說，"提測"這個動作本身並不增加什麼價值，但也需要花費一定的時間。"上線"是指某個項目驗證合格後，將其部署到伺服器的過程，其中包 括"上線申請"和"實際部署"兩個活動。也許在各公司中對這兩個活動叫法不同，但在軟體生命週期中，"提測"、"上線"這兩件事無論花長時間，大家可能都 不會感到奇怪。下面兩張圖是該產品線進行改進之後的對比資料。

不難看出，提測和上線部署的效率已大大提高。象百度這樣的互連網企業，產品線多得數不清，幾乎每個產品線每周都有新功能部署。僅從這兩個資料來看，其收益可想而知。那麼，半年前的狀況是什麼樣的呢？

二、流程建模

既然DevOps關注於價值交付的全過程，那就讓我們看看該產品線常見的交付過程吧。

對於單個項目來說，它大體上是一個典型的瀑布開發過程。首先是需求收集與整理，撰寫MRD(Marketing Requirement Document)或總體設計後，進行評審。如果涉及到多模組，每個模組的開發人員會對各自負責的模組進行詳細設計，給出大致的開發計劃，並商定聯調時間 點。之後，開發人員會從主幹上拉出項目分支，並在該分支上進行開發。當到最後聯調點時，幾個開發人員才會在將代碼合在一起，進行聯調。當調通之後，開發人 員再申請提測。測試人員接到提測申請單後，進行測試，記錄Bug，通知開發人員修複，直致品質達到標準。之後，開發人員會填寫上線申請單，經營運人員確認 後，營運人員操作進行上線部署工作。。

開發的複雜性還在於：該產品線有很多並行項目，為了避免互相干擾可能帶來的衝突，每個項目啟動後都會重新在主幹上拉出分支，在上線前才進行合并。如所示。

另外，並行項目太多，導致每個開發人員會同時參與多個處於不同階段的項目。那些周期較長的項目雖然會被分解成多個迭代，但每個迭代內都是同樣的開發流程，只是最後僅有一次上線而已。

總而言之，突出的問題表現在：

1. 同一角色多個人員的合作開發；
2. 各角色部門之間的協作以各自的產品物為目標，如MRD、產品代碼、測試案例、上線操作單；
3. 基於人機互動方式的內部流程管理平台。

三、發現浪費

從精益思想出發，為了儘早交付價值，必須首先找出整個流程中的浪費，並將其消除，從而提高流程效率，讓"一個想法從提出到實現"可在最短時間裡完成。那麼，浪費到底表現在哪裡呢？

• 一些不必要的多分支開發，合并後發生問題的風險高。多重專案中可能都要修改同一個模組的代碼，每次在最後合并代碼時都會出現一些問題，非常痛苦，尤其是修改比較大的時候，合并及修複時間較長。
• 延遲問題被發現的時間。每個開發人員會將需求分解成多個技術任務後開發。所以，所有任務完成之前，應用程式一直處於不可用狀態。當最後在一起聯調時，常常會發現一些意想不到的問題。
• 基於流程平台的溝通。在提測環節中，溝通完全基於內部專案管理平台和立即訊息工具或Email。比如開發人員在提測前，需 要在專案管理平台上申請該項目的4位版本。拿到4位版本後，才能提交平台統一編譯。如果編譯失敗，那麼問題解決後還要再次申請4維版本。如果成功，則在項 目管理平台上填寫表單，回答一系列的問題（比如，是否做過單測？測了哪些功能點？部署步驟是什嗎？），發起提測工作流程，管理平台會自動寄送電子郵件給相關 測試人員，通知他們進行測試。測試人員收到該提測工作流程後，必須在平台上進行相關確認操作，通知開發人員已收到該版本。如果測試人員對部署和測試內容有疑 問的話，還會通過即時通訊工具或郵件與開發人員進行確認。
• 常規的例行工作很難自動化。上線部署也需要通過內部平台來完成。開發人員拿到已測試通過的4位版本後，先要登入到內部平 台，再提交上線申請單，填寫上線步驟。當營運人員收到上線步驟後，再將其"翻譯"成平台可以識別的"半自動上線步驟"，再讓平台來執行。如果營運人員不理 解上線步驟，就要和開發人員通過電子郵件或即時通訊工作等進行反覆確認。部署配置資訊分散在各處。如所示：

另外，該產品的一個重要特徵是需要不斷地嘗試調整程式演算法策略，以得到最佳的流量效果，而這種調整的頻率較高（至少每周一次）。當需要調整策略時， 開發人員修改代碼後重新進行編譯打包，由於產品代碼發生變化，所以測試人員仍需要進行大量的迴歸測試，而營運人員在部署時也需要將對二進位檔案包進行整體 部署，整個周期比較長。

從上面這些內容中，我們不難發現，流程中更傾向於將問題延遲到後面解決（比如最後整合聯調），將工具（平台、郵件、即時通訊）作為協作的基礎，而角 色間的溝通幾乎完全依賴於前一個環節的產物（比如MRD、產品代碼、上線步驟）。那麼我們使用哪些對策進行最佳化，達到消除浪費的目的呢？

四、應對措施1. 無人工幹預方式的指令碼自動化

• 自動化提測——由於已做到了每日整合，所以每天都有可測試的版本，開發人員不再需要為提測進行專門的準備工作，只要從成功構建的列表中選擇一個給測試人員就可以了。使用Hudson平台後，通過外掛程式即可調用自動化指令碼，完成提測版本的標識。
• 統一配置資訊源——將所有的配置項全部放在Subversion庫中進資料列版本設定；並根據應用環境的不同，分別儲存在Dev，Test和Online三個目錄中。

• 常規流程指令碼化——經過各角色的共同討論和可行性分析，最後配置上線部署的實施方案是：由開發人員將產品二進位包與配置項 進行剝離，這樣僅做策略調整時，測試人員只要對已修改的配置項進行相關測試即可。營運人員用一系列的指令碼代替了內部營運平台的手工上線操作，再通過 Hudson平台的外掛程式，以 "Click Button"的方式達到了一鍵式部署。

2. 儘早發現問題，解決問題

• "需求細分，及時開發，及時驗證"——將需求拆分成端到端可測試的需求（即"使用者故事"），這些需求一般可在3天內完成。在實現每個需求之前，開發人員與測試人員進行充分溝通，對需求與驗收準則達成共識。每開發完成一個使用者故事，就進行測試，並用自動化測試進行覆蓋。
• "主幹開發，分支提測"——將原來的多個分支進行合并，統一在主幹上開發，每周結束時拉出一個分支，進行提測，一旦發現問題，就在主幹上修複。
• "持續整合"——為了確保每次提交品質，對主幹開發建立持續整合環境，開發人員和自動化測試人員都嚴格遵守持續整合紀律"Check-in Dance"。

新的開發流程如所示。

分支開發策略變更為Single Branch模式。

五、小結

通過以上改進措施，讓團隊的合作方式發生了重大變化，從"碉堡防禦"走向了"戰線統一"。

原來，各角色僅關注於自己本身的工作，雖然大家都同處於一個項目中，但各自劃分了"領地"，產品經理就應該將MRD寫得清清楚楚，如果開發人員認為 不清楚，那就回去再改。開發人員只管按照MRD上的內容進行開發，很少考慮可測性和易測性問題。測試人員只管按照MRD中內容來測試，有問題通過內部工作 流平台提交問題單。營運人員只管根據開發人員提交的上線操作單進行操作。似乎各角色之間的溝通介質只有各自的"交付物"。

現在，各角色都能夠共同合作，以項目的最終交付為目標，積極討論需求，最佳化實現。因為角色之間的這種緊密合作讓所有人對不同角色都有了深入的瞭解。 開發人員耐心為產品經理解釋技術實現，說明計劃安排，測試人員與開發人員共同討論驗收準則，避免遺漏需求。開發人員讓營運人員瞭解架構設計， 細心聽取營運人員的建議，進行技術改造，使部署工作更快捷有效。

通過這些活動，大家都認識到原有內部管理平台僅是個公文流轉的支撐平台，要想提高工作效率，就要將這種"辦公自動化工具"進一步提升為"全面自動化工具"，使所有人更關注於端到端的價值，而非各角色之間的分界點。

六、結束語

百度剛剛開始敏捷之旅，還沒人談及"DevOps"運動，雖然還沒有什麼強大的工具支撐，但基於"提高效率"的樸素思想進行的流程改善也帶來 了"DevOps"效果。可見，DevOps聽上去很神秘，但其實並不難。只要本著精益思想，聚焦於快速交付價值，不斷髮現並消除浪費，你也一定會有很大 收穫。

轉自：http://www.infoq.com/cn/articles/devops-not-legend

本文是使用 B3log Solo 從 Vanessa 進行同步發布的原文地址：http://vanessa.b3log.org/devops-not-legend