12.2 devops理念
devops(development和operations的組合)是一組過程、方法與系統的統稱,用于促進開發(應用程式/軟體工程)、技術營運和品質保障(qa)部門之間的溝通、協作與整合。它的出現是由于軟體行業日益清晰地認識到,為了按時傳遞軟體産品和服務,開發和營運工作必須緊密合作。
12.2.1 development和operations的組合
可以把devops看作開發(軟體工程)、技術營運和品質保障(qa)三者的交集。
傳統的軟體組織将開發、it營運和品質保障設為各自分離的部門。在這種環境下如何采用新的開發方法(如靈活軟體開發)是一個重要的課題。按照從前的工作方式,開發和部署不需要it支援或者qa深入的、跨部門的支援,卻需要極其緊密的多部門協作。然而devops考慮的不止是軟體部署,它是一套針對這幾個部門間溝通與協作問題的流程和方法。
devops的引入能對産品傳遞、測試、功能開發和維護起到意義深遠的影響。在缺乏devops能力的組織中,開發與營運之間存在着資訊“鴻溝”。例如,營運人員要求更好的可靠性和安全性,開發人員則希望基礎設施響應更快,而業務使用者的需求則是更快地将更多的特性釋出給最終使用者使用。這種資訊鴻溝就是最常出現問題的地方。
以下幾個因素可能促使一個組織引入devops:
(1)使用靈活或其他軟體開發過程與方法。
(2)業務負責人要求加快産品傳遞的速率。
(3)虛拟化和雲計算基礎設施(可能來自内部或外部供應商)日益普遍。
(4)資料中心自動化技術和配置管理工具的普及。
有一種觀點認為,占主導地位的“傳統”美國式管理風格(斯隆模型vs豐田模型)會導緻“煙囪式自動化”,進而造成開發與營運之間的鴻溝,是以需要devops來克服由此引發的問題。
devops經常被描述為“開發團隊與營運團隊之間更具協作性、更高效的關系”。由于團隊間協作關系的改善,整個組織的效率是以得到提升,伴随頻繁變化而來的生産環境的風險也能得到降低。
12.2.2 對應用程式釋出的影響
在很多企業中,應用程式釋出是一項涉及多個團隊、壓力很大、風險很高的活動。然而在具備devops能力的組織中,應用程式釋出的風險很低,原因如下。
1.減少變更範圍
與傳統的瀑布式開發模型相比,采用靈活或疊代式開發意味着更頻繁的釋出、每次釋出包含的變化更少。由于部署經常進行,是以,每次部署不會對生産系統造成巨大影響,應用程式會以平滑的速率逐漸生長。
2.加強釋出協調
靠強有力的釋出協調人來彌合開發與營運之間的技能鴻溝和溝通鴻溝;采用電子資料表、電話會議、即時消息、企業門戶(如wiki、sharepoint)等協作工具來確定所有相關人員了解變更的内容并全力合作。
3.自動化
強大的部署自動化手段可以確定部署任務的可重複性、減少部署出錯的可能性。
12.2.3 遇到的問題
很多組織将開發和系統管理劃分成不同的部門。開發部門的驅動力通常是“頻繁傳遞新特性”,而營運部門則更關注it服務的可靠性和it成本投入的效率。二者目标的不比對,就在開發與營運部門之間造成了鴻溝,進而減慢了it傳遞業務價值的速度。
更小、更頻繁的變更意味着更少的風險,讓開發人員更多地控制生産環境,更多地以應用程式為中心來了解基礎設施,定義簡潔明了的流程,盡可能地自動化,促成開發與營運的協作。
一般而言,當企業希望将原本笨重的開發與營運之間的工作移交過程變得流暢無礙時,他們通常會遇到以下三類問題。
(1)釋出管理問題:很多企業都有釋出管理問題。他們需要更好的釋出計劃,而不止是一份共享的電子資料表。他們需要清晰了解釋出的風險、依賴、各階段的入口條件,并確定各個角色遵守既定流程行事。
(2)釋出/部署協調問題:有釋出/部署協調問題的團隊需要關注釋出/部署過程中的執行。他們需要更好地跟蹤釋出狀态,更快地将問題上升,嚴格執行流程控制和細粒度的報表。
(3)釋出/部署自動化問題:這些企業通常有一些自動化工具,但他們還需要以更靈活的方式來管理和驅動自動化工作,而不必将所有手工操作都在指令行中加以自動化。理想情況下,自動化工具應該能夠在非生産環境下由非營運人員使用。
要開始優化釋出流程,可以從問題識别開始:看看上面提到的哪種問題在你的團隊中具有最高的優先級。
12.2.4 協調人
這是企業級it組織中一個新出現的角色,其主要任務就是協調安排将企業級軟體部署到預生産環境。對釋出協調人的需求來自以下幾方面的原因。
(1)需要彌合開發與營運之間的鴻溝。
(2)基礎設施日益變得複雜:為了營運web應用,需要多層基礎設施和多種平台。
(3)釋出頻率上升(由于靈活和疊代式開發的引入)。
(4)分布式團隊:位于全球多個地點的、包含外包人員的、混合開發/測試/基礎設施的團隊。
釋出協調人的角色(也被稱為部署協調人或內建協調人)源自釋出管理或釋出工程團隊。這個角色與航空交通管制有些類似:實時協調不同團隊的行動,有效使用共享的資源(空域、航道、跑道、航站門),達到組織的總體目标(安全起降)。
傳統意義上的釋出管理往往隻關注軟體變更的計劃與管理,而釋出協調則需要控制“将特定軟體變更釋出至生産環境”的整個過程。這項工作需要系統地管理所有與“将代碼建構并部署到生産環境”相關的技術任務,也被稱為“釋出工程”。
變更管理是跟蹤企業it環境中各種變化(不管是應用程式還是基礎設施的變化)的基本原則。變更管理是itil v3的核心之一。
12.2.5 成功的關鍵
1.文化沖擊
平穩的文化過渡是讓devops獲得長期成功應用和增強釋出軟體産品的綜合能力的關鍵。第一步是明确devops的定義,調動開發和營運部門之間的協作,鼓勵營運人員采納軟體開發方法,并利用雲計算基礎設施來完成真實的測試和代碼部署。
在軟體開發、測試、品質保證(qa)、內建、預生産和生産部署等方面的任何舊小團隊必須打散,因為每個小團隊都可能拖延開發周期,并且帶來不可預料的問題。
以上政策能更好地整合開發和營運人員,通過整合團隊成員來産生效益。例如,在讨論營運解決方案或擾亂事後評估報告時應該邀請開發人員加入。相反,應該邀請營運人員列席開發人員規劃會議。讓交叉組合的工作模式成為制度,可以讓團隊之間合作融洽,消除溝通不暢導緻的延誤或疏忽,使devops的推進更加有效。
這種文化上的改革并不容易,它需要公司提供統一的考核标準,以相同的形式衡量開發人員和運維人員的業績;培養一種團隊精神,讓大家一起朝着一個共同的目标努力,而不再隻是為了從前各自的狹隘的小團體目标。在這裡,有時可以運用崗位輪換或者知識共享的方法。
2.齊全的工具箱
想要超越文化的影響,組織還必須依靠各種devops工具。例如,開發人員編寫代碼需要工具,qa測試人員完成新版軟體的部署需要工具,環境準備、将新代碼在測試系統和生産系統之間遷移也必須用到雲資源排程工具。工具本身都不是問題,重要的是能夠讓各種工具互相配合,在軟體的生命周期内提供支援。