當軟件行業進入互聯網時代，市場對軟件產品和服務的交付提出了更高的要求：不僅要快速實現需求，而且要快速發布上線，并且必須保證業務可靠、高效運行。為了滿足這些要求，IT組織需要強有力的流程、技術和人員作為保障。

　　ThoughtWorks很早就認識到發布與運營對于成功交付的重要性。我們的創始人Roy Singham在《走完業務軟件的“最后一公里”》^[1]一文中指出：

所謂[軟件開發的]“最后一公里”，是指軟件滿足了功能需求之后，尚未投入實際運行并創造業務價值的階段。軟件開發者──尤其是面對交付壓力的軟件開發者──常常對“最后一公里”視而不見。但它確實正在成為業務軟件交付中最大的壓力點。

　　本文將分析大型軟件組織在軟件發布與運營維護階段常見的典型問題，并介紹一種行之有效的解決對策。

　　問題

　　眾多大型軟件組織在軟件的發布、運營和維護過程中體會到以下兩方面的壓力：

　　快速響應

　　傳統觀念中規模龐大、發布周期長達數月乃至數年的軟件產品研發方式正在發生變化。在“快魚吃慢魚”的互聯網時代，上市時間（Time To Market）成為衡量軟件組織能力的重要因素：能快速接納需求、快速完成開發、快速上線投入使用的軟件產品，才能有效占領市場、吸引用戶。

　　在以迭代式開發為特征的敏捷開發方法和以Ruby on Rails為代表的一批高效開發工具幫助下，很多軟件組織在實現功能性需求方面的能力得到了顯著提升。然而從業務負責人的角度來說，僅僅提升開發階段的效率還不足以實現端到端的快速響應。很多軟件組織雖然以迭代方式進行開發，但發布和部署仍然按照從前的節奏，每隔幾個月才進行一次。這時從客戶與最終用戶的視角看來，這些軟件組織的交付仍然是以瀑布方式進行：客戶與最終用戶并沒有直接感知到開發能力提升所帶來的利益（如圖1）。

　　不能有效縮短部署上線的周期，就無法真正實現快速響應業務需求、快速實現業務價值。如何縮短發布和運維工作的周期，已經成為困擾很多軟件組織領導者的問題。

圖1：迭代式開發+瀑布式發布^[2]

　　質量

　　大型軟件組織通常都很重視產品質量，并在開發/測試階段投入大量成本與精力進行質量保障活動。但軟件產品的質量問題不僅在開發階段引入，靠傳統意義上的測試工作也不能完全發現。有相當比例的質量問題是在開發/測試階段之后引入或發現的。造成這一現象的原因有：

• 開發人員對生產環境缺乏了解，在代碼中引入了只有在生產環境才會暴露的缺陷。
• 開發人員對非功能性需求缺乏關注，并且沒有相應驗證環境，導致非功能性缺陷。
• 生產環境和測試環境缺乏有效管理，因為環境差異引入缺陷。
• 部署和維護工作缺乏自動化，在發布過程中手工操作引入缺陷。
• 缺乏針對生產環境的回歸測試，導致缺陷不能及時被發現。

　　通過引入自動化測試、測試驅動開發、持續集成等敏捷實踐，開發/測試階段的質量保障活動能夠得到有效改善。然而對于客戶和最終用戶來說，不論哪個環節引入的缺陷都同樣會給業務造成損失。如何在部署上線的緊迫壓力下保證質量，這也是眾多軟件組織領導者關注的一個問題。

　　敏捷拉通的嘗試

　　一些軟件組織意識到這些問題的存在，并希望以敏捷開發方法為出發點，將下游的發布、部署、運維等工作環節拉通，從而提升整體響應能力。但由于軟件開發與運營之間存在一些固有的差異，這樣的拉通活動往往困難重重：

• 開發團隊與運營團隊的關注點不同。開發團隊重視以功能性需求實現業務價值；運營團隊重視以非功能性需求（穩定性、性能、安全性等）實現業務價值。
• 開發團隊與運營團隊的技能結構不同。開發人員通常缺乏服務器管理的技能，運營人員通常缺乏軟件編程的技能。
• 開發團隊與運營團隊日常使用的工具不同。針對開發階段引入的配置管理、IDE、測試工具等很少為運營團隊使用。
• 開發團隊與運營團隊日常工作的環境不同。開發人員通常在公司內的桌面電腦上工作，運營人員經常在客戶現場、在服務器上工作。
• 開發團隊與運營團隊通常屬于不同的部門。

　　由于存在這些固有的差異，單純從開發團隊的角度出發、將敏捷軟件開發的實踐推廣到運營團隊，很難有效幫助運營團隊改善。需要從運營維護工作本身的特點出發，引入符合客觀情況的流程、技術和工具，才能有效改善運營維護工作的質量和效率。

　　對策

　　針對現代大型軟件組織在軟件發布、運營與維護過程中面臨的種種挑戰，ThoughtWorks建議在軟件組織中建設DevOps^[3]能力，從而提升整個組織的IT融合程度，改善軟件交付“最后一公里”的質量和效率，為實現業務敏捷打好基礎。

　　DevOps是一組流程、技術與工具的統稱，用于促進開發、技術運營和質量保障部門之間的溝通、協作與整合。“DevOps”這個名稱即是指開發（dev）與運營（op）的無縫融合。具備DevOps能力的組織能夠開展快速、反應靈敏同時又穩定可靠的業務運維，使其能夠與開發過程的創新保持同步，從而使得敏捷開發的優勢在組織層面上得到展現。

　　精益運維

　　傳統的軟件運營人員通常傾向于盡量避免修改功能，從而降低滿足非功能性需求的風險。但如果拒絕了小的修改，而給定時間段內需要修改的總量不變，那么每次變更的規模就會變大，從而增加每次發布的風險（因為變更涉及的范圍更大）。

　　DevOps的指導思想是“精益運維”。精益生產的很多原則，例如縮短交付周期、消除浪費、重視價值流動、拉動式生產、質量內建等，在DevOps中都得到了體現。與傳統的軟件發布方式相比，DevOps主要通過以下幾方面的改變來提升效率和質量：

• 減少每次發布的變更范圍。與傳統的瀑布式開發模型相比，采用迭代的工作方式意味著更頻繁的發布、每次發布包含的變化更少。由于部署經常進行，因此每次部署不會對生產系統造成巨大影響，應用程序會以平滑的速率逐漸生長（如圖2）。與傳統開發方法那種大規模的、不頻繁的發布（通常以“季度”或“年”為單位）相比，具備DevOps能力的組織大大提升了發布頻率（通常以“天”或“周”為單位）。
• 加強開發與運營協調。通過強有力的發布協調機制來彌合開發與運營之間的技能鴻溝和溝通鴻溝；采用電話會議、即時消息、企業門戶（wiki、sharepoint）等協作工具來確保所有相關人員理解變更的內容；使用統一的流程和工具，例如故事墻、燃盡圖、在線項目管理工具（ 例如Mingle、JIRA）、配置管理工具（例如Subversion、Git、Mercurial）等。
• 自動化。借助強大的部署自動化手段和標準化的環境管理來降低部署操作的成本、確保部署任務的可重復性、減少部署出錯的可能性。例如：
  • 用VMWare或Xen等虛擬化技術標準化生產環境，實現生產環境的快速復制和快速恢復。
  • 用Puppet或Chef等工具自動化環境設置、軟件安裝/配置等操作，將配置信息轉化為源代碼，實現環境配置的版本控制。
  • 用Capistrano等工具自動化軟件產品的部署，實現部署過程的版本控制。
  • 用dbdeploy等工具自動化數據庫變更，實現數據遷移的版本控制。
  • 用Selenium、Cucumber等工具自動化生產環境的冒煙測試和回歸測試。

圖2： 應用程序­以平滑的速率逐漸生長^[4]

　　從工作流程、協調機制、技術工具等幾個方面同時著手，就能在軟件組織中建立起DevOps能力，從而將精益運維變成現實。

　　敏捷開發

　　DevOps與敏捷軟件開發同樣具有精益的指導思想，在實踐層面也有很多共通之處。可以把敏捷軟件開發看作精益思想在需求、研發階段的實施，DevOps則是精益思想在發布、運營階段的實施（如圖3）。盡管建設DevOps能力并不必須要求軟件組織具備敏捷軟件開發能力，不過以下敏捷實踐會對DevOps能力建設產生尤為明顯的幫助：

圖3：DevOps與敏捷既相關又不同^[5]

• 迭代式開發。已經習慣于固定的短周期迭代的開發團隊能夠更好地融入快速交付的整體節奏。
• 自動化測試。有效的自動化測試套件能在軟件生命周期的各個環節保障系統質量，避免引入缺陷。
• 持續集成。擁有成熟的項目自動化機制和能力，開發團隊能幫助運營團隊更快地建立發布與維護過程的自動化體系，從而實現軟件價值的持續交付。

　　收益

　　通過建設DevOps能力，軟件組織能夠明顯軟件產品發布和運營過程中的質量與效率。具體而言，可感知的收益包括：

• 縮短交付周期，新需求能更快投入使用并創造業務價值。
• 增加軟件發布的可靠性，減少上線后的質量事故。
• 減少發布和運營中的浪費，提高運營團隊的工作效率。
• 可視化度量軟件交付過程，以便快速識別問題、持續改善。
• 在開發與運營團隊之間建立更加高效的協作關系。

　　案例I：Flickr

　　Flickr是全球最大的圖片共享網站。根據2007年的統計數據^[6]，Flickr擁有超過850萬注冊用戶，存放了超過30億張照片，每秒鐘響應4萬個照片訪問請求。

　　通過自動化基礎設施、共享版本控制、自動化構建和部署、共享度量體系、強化溝通機制等手段，Flickr在保證網站穩定性和性能的同時，達到了每天能部署10次以上的需求響應水平，同時在開發團隊與運營團隊之間建立起互相尊重、彼此信任的協作關系。

圖4：全球最大的圖片分享網站Flickr每天有超過10次部署上線^[7]

　　案例II：某在線社交網站

　　該網站從2000年開始運營，目前擁有超過3000萬注冊用戶。隨著業務發展，該網站的運營團隊感受到來自業務負責人和最終用戶的壓力。根據ThoughtWorks所做的價值流分析，該網站從接納一個需求到最終將其上線投入使用需要15～40天，其中超過50%時間是被浪費的。

圖5：通過價值流分析發現浪費^[8]

　　ThoughtWorks幫助該網站進行了DevOps能力建設，尤其加強了基礎設施自動化、環境自動化、測試自動化和部署自動化能力，并改進了開發和運營團隊的工作流程，使得典型需求的交付時間縮短50%以上，有效工作時間比達到90%以上，從而使該網站能夠實現全面的業務敏捷。

　　挑戰

　　DevOps能力建設是一項系統工程，很多方面的因素可能對其造成影響。以下列舉幾項最常見的風險：

• 跨部門協作。很多大型軟件組織都將開發與運營劃分為不同的部門，而DevOps需要開發人員與運營人員無縫融合、緊密協作，這必然涉及部門之間的協調。如果處理不當，部門墻有可能嚴重損害軟件組織交付業務價值的能力。
• 高層領導投入。相比傳統的瀑布式發布，DevOps是工作方式的變革，涉及到技術、流程乃至團隊文化的改變。如果缺乏高層領導的關注，或者如果高層領導只把DevOps看作小范圍、技術性的改善，DevOps建設將很難收到預期的效果。
• 團隊穩定性。傳統意義上的“運維”是技術含量較低的崗位，人員流動率也相對較高。DevOps要求開發團隊和運營團隊（尤其是運營團隊）掌握更全面的技能，尤其是項目自動化技能。如果不能保證團隊相對穩定，學習投資就會被浪費。

　　軟件的發布過程是一個整體系統，需要對其進行端到端的流程優化。ThoughtWorks采用精益價值流改善（Lean Value Stream Improvement）作為DevOps建設的框架，并在其中嵌入針對軟件構建、發布、運營的知識和實踐，以迭代方式管理改善活動，全程以可視化形式直觀展現工作進展狀態，從而最大程度地保障改善得以成功實施。

　　[1] 《軟件開發沉思錄》，人民郵電出版社2009年，第二章

　　[2] 圖片來源：Damon Edwards的博客“什么是DevOps”（http://dev2ops.org/blog/2010/2/22/what-is-devops.html，或http://article.yeeyan.org/view/139515/170072）

　　[3] Wikipedia的“DevOps”詞條：http://zh.wikipedia.org/wiki/DevOps

　　[4] 圖片來源：Wikipedia的“DevOps”詞條（http://zh.wikipedia.org/wiki/DevOps）

　　[5] 圖片來源：Damon Edwards的博客“什么是DevOps”（http://dev2ops.org/blog/2010/2/22/what-is-devops.html，或http://article.yeeyan.org/view/139515/170072）

　　[6] 數據來源：April 2007 MySQL Conf and Expo和Flickr網站。

　　[7] 圖片來源：10+ Deploys Per Day: Dev and Ops Cooperation at Flickr（http://www.slideshare.NET/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr）

　　[8] 圖片來源：ThoughtWorks內部數據

it知識庫：建設DevOps能力，實現業務敏捷，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。