av不卡在线看,四虎影城,日韩一二区

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

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

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

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

　　問題

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

　　快速響應(yīng)

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

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

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

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

　　質(zhì)量

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

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

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

　　敏捷拉通的嘗試

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

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

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

　　對(duì)策

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

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

　　精益運(yùn)維

　　傳統(tǒng)的軟件運(yùn)營(yíng)人員通常傾向于盡量避免修改功能，從而降低滿足非功能性需求的風(fēng)險(xiǎn)。但如果拒絕了小的修改，而給定時(shí)間段內(nèi)需要修改的總量不變，那么每次變更的規(guī)模就會(huì)變大，從而增加每次發(fā)布的風(fēng)險(xiǎn)（因?yàn)樽兏婕暗姆秶螅?/p>

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

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

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

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

　　敏捷開發(fā)

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

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

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

　　收益

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

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

　　案例I：Flickr

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

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

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

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

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

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

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

　　挑戰(zhàn)

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

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

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

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

　　[2] 圖片來(lái)源：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] 圖片來(lái)源：Wikipedia的“DevOps”詞條（http://zh.wikipedia.org/wiki/DevOps）

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

　　[6] 數(shù)據(jù)來(lái)源：April 2007 MySQL Conf and Expo和Flickr網(wǎng)站。

　　[7] 圖片來(lái)源：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] 圖片來(lái)源：ThoughtWorks內(nèi)部數(shù)據(jù)