當軟體行業進入網際網路時代，市場對軟體產品和服務的交付提出了更高的要求：不僅要快速實現需求，而且要快速發布上線，並且必須保證業務可靠、高效執行。為了滿足這些要求，it組織需要強有力的流程、技術和人員作為保障。
thoughtworks很早就認識到發布與運營對於成功交付的重要性。我們的創始人roy singham在《走完業務軟體的「最後一公里」》
[1]一文中指出：
所謂[軟體開發的]「最後一公里」，是指軟體滿足了功能需求之後，尚未投入實際執行並創造業務價值的階段。軟體開發者──尤其是面對交付壓力的軟體開發者──常常對「最後一公里」視而不見。但它確實正在成為業務軟體交付中最大的壓力點。本文將分析大型軟體組織在軟體發布與運營維護階段常見的典型問題，並介紹一種行之有效的解決對策。
眾多大型軟體組織在軟體的發布、運營和維護過程中體會到以下兩方面的壓力：
傳統觀念中規模龐大、發布周期長達數月乃至數年的軟體產品研發方式正在發生變化。在「快魚吃慢魚」的網際網路時代，上市時間（time to market）成為衡量軟體組織能力的重要因素：能快速接納需求、快速完成開發、快速上線投入使用的軟體產品，才能有效占領市場、吸引使用者。
在以迭代式開發為特徵的敏捷開發方法和以ruby on rails為代表的一批高效開發工具幫助下，很多軟體組織在實現功能性需求方面的能力得到了顯著提公升。然而從業務負責人的角度來說，僅僅提公升開發階段的效率還不足以實現端到端的快速響應。很多軟體組織雖然以迭代方式進行開發，但發布和部署仍然按照從前的節奏，每隔幾個月才進行一次。這時從客戶與終端使用者的視角看來，這些軟體組織的交付仍然是以瀑布方式進行：客戶與終端使用者並沒有直接感知到開發能力提公升所帶來的利益（如圖1）。
不能有效縮短部署上線的週期，就無法真正實現快速響應業務需求、快速實現業務價值。如何縮短發布和運維工作的週期，已經成為困擾很多軟體組織領導者的問題。
圖1：迭代式開發+瀑布式發布
[2]大型軟體組織通常都很重視產品質量，並在開發/測試階段投入大量成本與精力進行質量保障活動。但軟體產品的質量問題不僅在開發階段引入，靠傳統意義上的測試工作也不能完全發現。有相當比例的質量問題是在開發/測試階段之後引入或發現的。造成這一現象的原因有：
通過引入自動化測試、測試驅動開發、持續整合等敏捷實踐，開發/測試階段的質量保障活動能夠得到有效改善。然而對於客戶和終端使用者來說，不論哪個環節引入的缺陷都同樣會給業務造成損失。如何在部署上線的緊迫壓力下保證質量，這也是眾多軟體組織領導者關注的乙個問題。
一些軟體組織意識到這些問題的存在，並希望以敏捷開發方法為出發點，將下游的發布、部署、運維等工作環節拉通，從而提公升整體響應能力。但由於軟體開發與運營之間存在一些固有的差異，這樣的拉通活動往往困難重重：
由於存在這些固有的差異，單純從開發團隊的角度出發、將敏捷軟體開發的實踐推廣到運營團隊，很難有效幫助運營團隊改善。需要從運營維護工作本身的特點出發，引入符合客觀情況的流程、技術和工具，才能有效改善運營維護工作的質量和效率。
針對現代大型軟體組織在軟體發布、運營與維護過程中面臨的種種挑戰，thoughtworks建議在軟體組織中建設devops
[3]能力，從而提公升整個組織的it融合程度，改善軟體交付「最後一公里」的質量和效率，為實現業務敏捷打好基礎。
devops是一組流程、技術與工具的統稱，用於促進開發、技術運營和質量保障部門之間的溝通、協作與整合。「devops」這個名稱即是指開發（dev）與運營（op）的無縫融合。具備devops能力的組織能夠開展快速、反應靈敏同時又穩定可靠的業務運維，使其能夠與開發過程的創新保持同步，從而使得敏捷開發的優勢在組織層面上得到展現。
傳統的軟體運營人員通常傾向於盡量避免修改功能，從而降低滿足非功能性需求的風險。但如果拒絕了小的修改，而給定時間段內需要修改的總量不變，那麼每次變更的規模就會變大，從而增加每次發布的風險（因為變更涉及的範圍更大）。
devops的指導思想是「精益運維」。精益生產的很多原則，例如縮短交付週期、消除浪費、重視價值流動、拉動式生產、質量內建等，在devops中都得到了體現。與傳統的軟體發布方式相比，devops主要通過以下幾方面的改變來提公升效率和質量：
圖2： 應用程式以平滑的速率逐漸生長
[4]
從工作流程、協調機制、技術工具等幾個方面同時著手，就能在軟體組織中建立起devops能力，從而將精益運維變成現實。
devops與敏捷軟體開發同樣具有精益的指導思想，在實踐層面也有很多共通之處。可以把敏捷軟體開發看作精益思想在需求、研發階段的實施，devops則是精益思想在發布、運營階段的實施（如圖3）。儘管建設devops能力並不必須要求軟體組織具備敏捷軟體開發能力，不過以下敏捷實踐會對devops能力建設產生尤為明顯的幫助：
圖3：devops與敏捷既相關又不同
[5]通過建設devops能力，軟體組織能夠明顯軟體產品發布和運營過程中的質量與效率。具體而言，可感知的收益包括：
flickr是全球最大的共享**。根據2023年的統計資料
[6]，flickr擁有超過850萬註冊使用者，存放了超過30億張**，每秒鐘響應4萬個**訪問請求。
通過自動化基礎設施、共享版本控制、自動化構建和部署、共享度量體系、強化溝通機制等手段，flickr在保證**穩定性和效能的同時，達到了每天能部署10次以上的需求響應水平，同時在開發團隊與運營團隊之間建立起互相尊重、彼此信任的協作關係。
圖4：全球最大的分享**flickr每天有超過10次部署上線
[7]
該**從2023年開始運營，目前擁有超過3000萬註冊使用者。隨著業務發展，該**的運營團隊感受到來自業務負責人和終端使用者的壓力。根據thoughtworks所做的價值流分析，該**從接納乙個需求到最終將其上線投入使用需要15～40天，其中超過50%時間是被浪費的。
圖5：通過價值流分析發現浪費
[8]
thoughtworks幫助該**進行了devops能力建設，尤其加強了基礎設施自動化、環境自動化、測試自動化和部署自動化能力，並改進了開發和運營團隊的工作流程，使得典型需求的交付時間縮短50%以上，有效工作時間比達到90%以上，從而使該**能夠實現全面的業務敏捷。
devops能力建設是一項系統工程，很多方面的因素可能對其造成影響。以下列舉幾項最常見的風險：
軟體的發布過程是乙個整體系統，需要對其進行端到端的流程優化。thoughtworks採用精益價值流改善（lean value stream improvement）作為devops建設的框架，並在其中嵌入針對軟體構建、發布、運營的知識和實踐，以迭代方式管理改善活動，全程以視覺化形式直觀展現工作進展狀態，從而最大程度地保障改善得以成功實施。
[1] 《軟體開發沉思錄》，人民郵電出版社2023年，第二章
[3] wikipedia的「devops」詞條：
團隊建設之能力賬戶
識人用人是指識別和發掘下屬的優勢與潛能，用人之長。對於不足的部分，也可以有效地加以補強。雖然這個 工作很重要，但相關的研究和方法五花八門。個人覺得適合就好，倒不一定非要熟讀九型人格，然後再加以套用,並且不見得合適。準確的認識乙個人總需要一些過程，中間需要多次修正，才可能比較完整。結合所從事軟體開發工...
通用技能 職場能力建設
關於向上管理的解釋中，最為人接受的莫過於彼得 德魯克的這句話 任何能影響自己績效表現的人，都值得被管理。領導自己，是為了走的更好。而領導你的上司，是為了走的更遠。任何能影響自己績效表現的人，都值得被管理。有效的向上管理，是能夠超預期的解決問題 在職場上，乙個人的不可替代性就看這個詞 專業。你是否有過...
DevOps的四種核心能力
devops 的成功取決於速度和穩定性。你可以改善哪四個核心概念來讓你的devops更加努力地為你工作呢?毫無疑問，devops 對組織是非常有價值的。根據近期發布的 state of devops report，高效的 it 組織可能會將利潤率 市場份額和生產力目標提高兩倍。但是，他們是如何做到的...