日韩人妻无码专区一本二本,99久久久无码国产精品AAA,国产免国产免费

　　當(dāng)軟件行業(yè)進(jìn)入互聯(lián)網(wǎng)時代，市場對軟件產(chǎn)品和服務(wù)的交付提出了更高的要求：不僅要快速實現(xiàn)需求，而且要快速發(fā)布上線，并且必須保證業(yè)務(wù)可靠、高效運行。為了滿足這些要求，IT組織需要強有力的流程、技術(shù)和人員作為保障。

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

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

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

　　問題

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

　　快速響應(yīng)

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

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

　　不能有效縮短部署上線的周期，就無法真正實現(xiàn)快速響應(yīng)業(yè)務(wù)需求、快速實現(xiàn)業(yè)務(wù)價值。如何縮短發(fā)布和運維工作的周期，已經(jīng)成為困擾很多軟件組織領(lǐng)導(dǎo)者的問題。

圖1：迭代式開發(fā)+瀑布式發(fā)布^[2]

　　質(zhì)量

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

開發(fā)人員對生產(chǎn)環(huán)境缺乏了解，在代碼中引入了只有在生產(chǎn)環(huán)境才會暴露的缺陷。
開發(fā)人員對非功能性需求缺乏關(guān)注，并且沒有相應(yīng)驗證環(huán)境，導(dǎo)致非功能性缺陷。
生產(chǎn)環(huán)境和測試環(huán)境缺乏有效管理，因為環(huán)境差異引入缺陷。
部署和維護(hù)工作缺乏自動化，在發(fā)布過程中手工操作引入缺陷。
缺乏針對生產(chǎn)環(huán)境的回歸測試，導(dǎo)致缺陷不能及時被發(fā)現(xiàn)。

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

　　敏捷拉通的嘗試

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

開發(fā)團(tuán)隊與運營團(tuán)隊的關(guān)注點不同。開發(fā)團(tuán)隊重視以功能性需求實現(xiàn)業(yè)務(wù)價值；運營團(tuán)隊重視以非功能性需求（穩(wěn)定性、性能、安全性等）實現(xiàn)業(yè)務(wù)價值。
開發(fā)團(tuán)隊與運營團(tuán)隊的技能結(jié)構(gòu)不同。開發(fā)人員通常缺乏服務(wù)器管理的技能，運營人員通常缺乏軟件編程的技能。
開發(fā)團(tuán)隊與運營團(tuán)隊日常使用的工具不同。針對開發(fā)階段引入的配置管理、IDE、測試工具等很少為運營團(tuán)隊使用。
開發(fā)團(tuán)隊與運營團(tuán)隊日常工作的環(huán)境不同。開發(fā)人員通常在公司內(nèi)的桌面電腦上工作，運營人員經(jīng)常在客戶現(xiàn)場、在服務(wù)器上工作。
開發(fā)團(tuán)隊與運營團(tuán)隊通常屬于不同的部門。

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

　　對策

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

　　DevOps是一組流程、技術(shù)與工具的統(tǒng)稱，用于促進(jìn)開發(fā)、技術(shù)運營和質(zhì)量保障部門之間的溝通、協(xié)作與整合。“DevOps”這個名稱即是指開發(fā)（dev）與運營（op）的無縫融合。具備DevOps能力的組織能夠開展快速、反應(yīng)靈敏同時又穩(wěn)定可靠的業(yè)務(wù)運維，使其能夠與開發(fā)過程的創(chuàng)新保持同步，從而使得敏捷開發(fā)的優(yōu)勢在組織層面上得到展現(xiàn)。

　　精益運維

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

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

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

圖2：應(yīng)用程序以平滑的速率逐漸生長^[4]

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

　　敏捷開發(fā)

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

圖3：DevOps與敏捷既相關(guān)又不同^[5]

迭代式開發(fā)。已經(jīng)習(xí)慣于固定的短周期迭代的開發(fā)團(tuán)隊能夠更好地融入快速交付的整體節(jié)奏。
自動化測試。有效的自動化測試套件能在軟件生命周期的各個環(huán)節(jié)保障系統(tǒng)質(zhì)量，避免引入缺陷。
持續(xù)集成。擁有成熟的項目自動化機制和能力，開發(fā)團(tuán)隊能幫助運營團(tuán)隊更快地建立發(fā)布與維護(hù)過程的自動化體系，從而實現(xiàn)軟件價值的持續(xù)交付。

　　收益

　　通過建設(shè)DevOps能力，軟件組織能夠明顯軟件產(chǎn)品發(fā)布和運營過程中的質(zhì)量與效率。具體而言，可感知的收益包括：

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

　　案例I：Flickr

　　Flickr是全球最大的圖片共享網(wǎng)站。根據(jù)2007年的統(tǒng)計數(shù)據(jù)^[6]，F(xiàn)lickr擁有超過850萬注冊用戶，存放了超過30億張照片，每秒鐘響應(yīng)4萬個照片訪問請求。

　　通過自動化基礎(chǔ)設(shè)施、共享版本控制、自動化構(gòu)建和部署、共享度量體系、強化溝通機制等手段，F(xiàn)lickr在保證網(wǎng)站穩(wěn)定性和性能的同時，達(dá)到了每天能部署10次以上的需求響應(yīng)水平，同時在開發(fā)團(tuán)隊與運營團(tuán)隊之間建立起互相尊重、彼此信任的協(xié)作關(guān)系。

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

　　案例II：某在線社交網(wǎng)站

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

圖5：通過價值流分析發(fā)現(xiàn)浪費^[8]

　　ThoughtWorks幫助該網(wǎng)站進(jìn)行了DevOps能力建設(shè)，尤其加強了基礎(chǔ)設(shè)施自動化、環(huán)境自動化、測試自動化和部署自動化能力，并改進(jìn)了開發(fā)和運營團(tuán)隊的工作流程，使得典型需求的交付時間縮短50%以上，有效工作時間比達(dá)到90%以上，從而使該網(wǎng)站能夠?qū)崿F(xiàn)全面的業(yè)務(wù)敏捷。

　　挑戰(zhàn)

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

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

　　軟件的發(fā)布過程是一個整體系統(tǒng)，需要對其進(jìn)行端到端的流程優(yōu)化。ThoughtWorks采用精益價值流改善（Lean Value Stream Improvement）作為DevOps建設(shè)的框架，并在其中嵌入針對軟件構(gòu)建、發(fā)布、運營的知識和實踐，以迭代方式管理改善活動，全程以可視化形式直觀展現(xiàn)工作進(jìn)展?fàn)顟B(tài)，從而最大程度地保障改善得以成功實施。

　　[1] 《軟件開發(fā)沉思錄》，人民郵電出版社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] 數(shù)據(jù)來源：April 2007 MySQL Conf and Expo和Flickr網(wǎng)站。

　　[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內(nèi)部數(shù)據(jù)