DevOps中國(guó)調(diào)查研究*

劉博涵, 張 賀, 董黎明

(計(jì)算機(jī)軟件新技術(shù)國(guó)家重點(diǎn)實(shí)驗(yàn)室(南京大學(xué)),江蘇 南京 210023)

回顧過去十年軟件工程的發(fā)展,2009 年一定是具有里程碑意義的一年,在這一年的DevOpsDays(https://www.devopsdays.org/)上,Debois 首次提出了一個(gè)合成詞——DevOps,軟件工程的新時(shí)代就此拉開序幕.

向前追溯到2001 年,Beck 等人成立敏捷聯(lián)盟,集結(jié)其余20 位軟件工程專家,發(fā)起了敏捷宣言(http://agilemanifesto.org/iso/zhchs/manifesto.html).其主要目的是使軟件組織適應(yīng)業(yè)務(wù)變更日趨頻繁的市場(chǎng)環(huán)境,充分而有效地響應(yīng)需求[1].以響應(yīng)變化、快速交付價(jià)值為宗旨的敏捷開發(fā)衍生出了各種不同的敏捷開發(fā)方法以適應(yīng)不同的組織、團(tuán)隊(duì)和項(xiàng)目的特征,其中,最主要的有Scrum[2]、極限編程(extreme programming)[3]、精益開發(fā)(lean development)[4]、Kanban[5]等.

然而,隨著(移動(dòng))互聯(lián)網(wǎng)應(yīng)用的爆發(fā)式增長(zhǎng),同質(zhì)化產(chǎn)品之間的競(jìng)爭(zhēng)日益激烈,用戶需求的多樣性及用戶對(duì)產(chǎn)品穩(wěn)定性要求的日益增長(zhǎng),敏捷開發(fā)也不再能夠滿足所有業(yè)務(wù)場(chǎng)景.其中一個(gè)重要的原因在于,現(xiàn)有的敏捷方法只關(guān)注迭代過程,而忽略了整個(gè)軟件生命周期中的大多數(shù)其他活動(dòng),尤其是運(yùn)維.在傳統(tǒng)的軟件企業(yè)中,往往將開發(fā)和運(yùn)維分設(shè)兩個(gè)部門(有時(shí)單獨(dú)設(shè)立的質(zhì)量保證部門也會(huì)被考慮進(jìn)來(lái)),敏捷開發(fā)僅僅覆蓋了開發(fā)部門的主要工作.這導(dǎo)致了開發(fā)部門與運(yùn)維部門僅關(guān)注各自的工作與職責(zé),缺乏溝通,且由于工作性質(zhì)的差異,部門文化也相去甚遠(yuǎn),開發(fā)部門受到敏捷開發(fā)的熏陶在內(nèi)部形成了敏捷文化,而運(yùn)維部門的同僚或在堆積如山的各種瑣碎的配置、部署任務(wù)中應(yīng)接不暇,或疲憊地奔走于分散各地的客戶現(xiàn)場(chǎng).這種隔閡使得開發(fā)和運(yùn)維的步調(diào)難以保持一致,這意味著,即使開發(fā)部門能夠在敏捷的驅(qū)動(dòng)下快速響應(yīng)變更,但缺少了運(yùn)維的支持,依然無(wú)法將產(chǎn)品迅速地交付給市場(chǎng).

一條順理成章的思路是,讓運(yùn)維團(tuán)隊(duì)也敏捷起來(lái).于是,DevOps,開發(fā)(development)和運(yùn)維(operations)的融合誕生了.目前,對(duì)于DevOps 還沒有一個(gè)一致且明確的定義,但為什么我們需要DevOps 是明確的,在市場(chǎng)的激勵(lì)下,軟件組織必須在保證質(zhì)量的前提下盡可能地減少將產(chǎn)品新特性交付到市場(chǎng)的時(shí)間.Bass[6]以一個(gè)架構(gòu)師的視角將 DevOps 定義為一組旨在減少?gòu)奶峤蛔兏阶兏鳛楫a(chǎn)品交付的時(shí)間,同時(shí)確保高質(zhì)量的實(shí)踐.Smeds[7]整理了現(xiàn)有關(guān)于DevOps 的不同定義,有些人認(rèn)為這是一場(chǎng)組織革命,有些人認(rèn)為這是一次文化運(yùn)動(dòng).關(guān)于DevOps 定義的多樣性恰恰體現(xiàn)出了DevOps 的這種試圖涵蓋完整的軟件生命周期,并影響整個(gè)組織及其內(nèi)部的每一個(gè)人的包羅萬(wàn)象的特征,這本身就是對(duì)行業(yè)未來(lái)的一種顛覆;另一方面也體現(xiàn)出了DevOps 還處于萌芽階段,無(wú)論在學(xué)術(shù)界還是工業(yè)界都沒有形成一套完整而又成熟的知識(shí)體系.

近兩年,DevOps 在國(guó)內(nèi)的熱度不斷攀升,與DevOps 相關(guān)的會(huì)議遍地開花,小到十幾人、大到上萬(wàn)人的企業(yè)紛紛摩拳擦掌.但即便如此,國(guó)內(nèi)對(duì)于DevOps 的反應(yīng)還是明顯滯后于國(guó)外,Puppet Labs 在2013 年[8]即開始了全球DevOps 現(xiàn)狀的問卷調(diào)查,彼時(shí),DevOps 在國(guó)內(nèi)還只為很小一部分人所知曉,從Puppet Labs 的調(diào)查結(jié)果我們也可以發(fā)現(xiàn),來(lái)自亞洲的參與者占比極少.截至2016 年,國(guó)內(nèi)還依然沒有一份關(guān)于DevOps 中國(guó)現(xiàn)狀的調(diào)查面世;截至目前,國(guó)內(nèi)也還沒有一篇關(guān)于DevOps 中國(guó)發(fā)展現(xiàn)狀的調(diào)查發(fā)表.本研究期望填補(bǔ)這一空白,通過近兩年對(duì)企業(yè)中實(shí)踐DevOps 的相關(guān)從業(yè)人員的調(diào)查,描繪了DevOps 在中國(guó)的現(xiàn)狀及其發(fā)展趨勢(shì),并通過與國(guó)外的現(xiàn)狀與發(fā)展進(jìn)行對(duì)比,對(duì)DevOps 在中國(guó)的所處階段進(jìn)行了定位.我們分別在2016 年和2018 年對(duì)國(guó)內(nèi)DevOps 從業(yè)人員進(jìn)行了兩次問卷調(diào)查.問卷從IT 性能表現(xiàn)、組織文化及相關(guān)實(shí)踐、開發(fā)與運(yùn)維實(shí)踐、工具支持、領(lǐng)導(dǎo)力、工作比例、員工敬業(yè)度及滿意度、障礙這8 個(gè)方面進(jìn)行了調(diào)研.結(jié)果顯示,隨著DevOps 實(shí)驗(yàn)經(jīng)驗(yàn)的增長(zhǎng),團(tuán)隊(duì)在IT 性能表現(xiàn)等方面可以得到顯著提高.目前,國(guó)內(nèi)DevOps 團(tuán)隊(duì)在敏捷方法和DevOps 相關(guān)工具的采用實(shí)踐較好,不同團(tuán)隊(duì)在具體方法和工具的選擇上呈現(xiàn)出了多樣性.然而,在其他方面,尤其是組織投入上,還明顯不足,尤其是與國(guó)際水平存在明顯差距,從各方面來(lái)衡量,雖然我們看到了從2016 年～2018 年呈現(xiàn)出來(lái)的一定進(jìn)步,但目前還處于大約4 年前的國(guó)際水平.

1 DevOps

DevOps 是開發(fā)和運(yùn)維這兩個(gè)領(lǐng)域的合并.它為開發(fā)和運(yùn)維構(gòu)建橋梁,避免開發(fā)和運(yùn)維之間的脫節(jié),同時(shí)讓團(tuán)隊(duì)以更高效的方式進(jìn)行合作,實(shí)現(xiàn)工作流程上的無(wú)縫對(duì)接[9].DevOps 通常是指軟件行業(yè)新興的專業(yè)化運(yùn)動(dòng),是一組文化、流程與工具整合后的統(tǒng)稱[10,11].DevOps 通過自動(dòng)化流程來(lái)使得軟件構(gòu)建、測(cè)試、發(fā)布更加快捷、頻繁和可靠.

DevOps 生命周期始于需求定義,覆蓋開發(fā)、構(gòu)建、測(cè)試、部署和交付反饋等階段[10].DevOps 是軟件開發(fā)生命周期從瀑布式到敏捷再到精益的演化(如圖1 所示).瀑布模型的特征是,在進(jìn)入下一階段之前,每個(gè)階段目標(biāo)必須100%地完成.相對(duì)于瀑布開發(fā)模式,敏捷開發(fā)過程的一個(gè)基本原則就是以更快的頻率交付最小化可用的軟件.在敏捷的目標(biāo)里,最明顯的是在每個(gè)Sprint 的迭代周期末尾,都具備可以交付的能力.DevOps 是敏捷開發(fā)的延續(xù),它與敏捷相輔相成,因?yàn)樗卣购屯晟屏顺掷m(xù)集成和發(fā)布流程,因此可以確保代碼是生產(chǎn)上可用的,并且確實(shí)能給客戶帶來(lái)價(jià)值[10].

Fig.1 The evolution of software development process model圖1 軟件開發(fā)模型演化

DevOps 提倡開發(fā)和IT 運(yùn)維之間的高度協(xié)同,在高頻率部署的同時(shí),要保證高質(zhì)量的完成,高質(zhì)量即代表要提高生產(chǎn)環(huán)境的可靠性、穩(wěn)定性、彈性和安全性等能力[10].

DevOps 的一個(gè)基本點(diǎn)是強(qiáng)調(diào)整個(gè)系統(tǒng)的穩(wěn)定性,而非將性能局限于特定的工作領(lǐng)域里,這個(gè)領(lǐng)域可以大到一個(gè)部門(例如開發(fā)和IT 運(yùn)維)或者小到一個(gè)個(gè)人貢獻(xiàn)者(例如開發(fā)者,系統(tǒng)管理員等),由IT 推動(dòng)業(yè)務(wù)價(jià)值流.DevOps 通過高部署率快速地把一個(gè)想法變成價(jià)值交付到客戶手中,即“概念落地”.并且在不影響客戶的基礎(chǔ)上,快速地完成并部署很多小的變更.DevOps 的目標(biāo)不僅只是增加變更的頻率,而且也支持在不中斷和破壞當(dāng)前服務(wù)的基礎(chǔ)上,確保功能部署成功,同時(shí)也可以快速檢測(cè)和修復(fù)缺陷.

IT 價(jià)值流中存在著巨大浪費(fèi),這些浪費(fèi)源于開發(fā)和運(yùn)維之間交接的不順暢,突如其來(lái)的計(jì)劃外工作,以及各種原因?qū)е碌慕桓镀谙尥七t.在開發(fā)和IT 運(yùn)維之間,DevOps 不僅聚焦在創(chuàng)建快速和穩(wěn)定的計(jì)劃工作流,而且DevOps 也有一個(gè)更全面的方法來(lái)系統(tǒng)地消除計(jì)劃外工作,定義開發(fā)彈性準(zhǔn)則,并負(fù)責(zé)管理和減少技術(shù)負(fù)債.

DevOps 使得開發(fā)人員能夠通過持續(xù)集成和標(biāo)準(zhǔn)化的發(fā)布慣例(持續(xù)測(cè)試的文化)來(lái)維持高頻率部署,在此基礎(chǔ)上,確保質(zhì)量和信息安全.一種常見的組織級(jí)標(biāo)準(zhǔn)是,一旦代碼被提交,自動(dòng)測(cè)試便開始運(yùn)行,且一旦發(fā)現(xiàn)問題,則必須馬上解決.

企業(yè)在應(yīng)用了DevOps 之后可以得到以下幾個(gè)方面的業(yè)務(wù)優(yōu)勢(shì):產(chǎn)品快速推向市場(chǎng)(比如,縮短開發(fā)周期時(shí)間和更高的部署頻率),提高質(zhì)量(比如,提高可用性,提高變更成功率,減少故障)并提高組織的有效性(比如,將時(shí)間花在價(jià)值增加活動(dòng)中,減少浪費(fèi),同時(shí)交付更多的價(jià)值至客戶手中).

2 問卷調(diào)查

2016 年末,我們?cè)贒evOps 中國(guó)社區(qū)(http://www.devopschina.org/)的支持下,開展了首次國(guó)內(nèi)范圍的DevOps中國(guó)現(xiàn)狀的問卷調(diào)查.基于對(duì)調(diào)查結(jié)果的整理,2017 年,我們發(fā)布了中國(guó)第1 份DevOps 年度調(diào)查報(bào)告——《DevOps 中國(guó)·2016 年度調(diào)查報(bào)告》(http://softeng.nju.edu.cn/devops/report2016).在前一次的調(diào)查和報(bào)告過程中,我們積累了豐富的經(jīng)驗(yàn),于是緊隨其后,在2018 年中旬發(fā)布了第2 份報(bào)告——《DevOps 中國(guó)·2018 年度調(diào)查報(bào)告》(http://softeng.nju.edu.cn/devops/report2018).我們期望通過一線實(shí)踐者對(duì)于DevOps 的理解和實(shí)踐情況,了解DevOps 在中國(guó)的現(xiàn)狀與發(fā)展趨勢(shì).未來(lái),我們計(jì)劃每年年初(第1 季度)開展基于問卷調(diào)查的數(shù)據(jù)收集活動(dòng),并于第2 季度發(fā)布調(diào)查報(bào)告.本文將基于對(duì)已經(jīng)完成的兩次調(diào)查結(jié)果的整理與分析加以闡述與討論.

2.1 問卷設(shè)計(jì)

本研究采用問卷調(diào)查的方式進(jìn)行數(shù)據(jù)收集,在2016 年的問卷(http://softeng.nju.edu.cn/devops/devops2016 cn)中,為了盡可能地涵蓋DevOps 的方方面面,我們從基本信息、概念、經(jīng)驗(yàn)、性能表現(xiàn)、文化、自動(dòng)化、標(biāo)準(zhǔn)化、質(zhì)量保證、監(jiān)控、過程、服務(wù)、工具、投入、領(lǐng)導(dǎo)與授權(quán)、工作量、員工滿意度和障礙共17 個(gè)方面設(shè)計(jì)了38 個(gè)問題.在DevOps 所涵蓋方面以及文化、自動(dòng)化、質(zhì)量保證等具體實(shí)踐的問題設(shè)置上,我們參考了關(guān)于DevOps 的文獻(xiàn)綜述的技術(shù)報(bào)告中所整理出的DevOps 推薦實(shí)踐[12].

Fig.2 The evolution of the structure and questions of questionnaires圖2 問卷結(jié)構(gòu)及問題演變

此外,考慮到期望與國(guó)際現(xiàn)狀進(jìn)行對(duì)比,所以我們還大量地參考了Puppet Labs 從2013 年～2017 年已進(jìn)行的5 次全球DevOps 現(xiàn)狀調(diào)查[8,13-16].Puppet Labs 于2017 年發(fā)布的最新報(bào)告有超過3 000 名分別來(lái)自全球六大洲(不含南極洲)的IT 從業(yè)人員參與調(diào)查,其中,10%來(lái)自于亞洲.除在工業(yè)界已經(jīng)產(chǎn)生了極大的影響力外,其報(bào)告的結(jié)果在學(xué)術(shù)界也被廣泛地認(rèn)可和引用[17,18].

? 在2018 年的問卷(http://softeng.nju.edu.cn/devops/devops2018cn)中,我們以結(jié)構(gòu)更加清晰的方式,將自動(dòng)化、標(biāo)準(zhǔn)化等實(shí)踐在分類上合并為開發(fā)與運(yùn)維實(shí)踐,將文化與投入兩類合并為組織文化與實(shí)踐,去除了概念類問題.此外,還針對(duì)部分問題進(jìn)行了調(diào)整,并在持續(xù)交付、架構(gòu)、工具等方面增加了新的問題,最終共45 個(gè)問題.兩次問卷的詳細(xì)演變過程如圖2 所示,具體來(lái)說(shuō):在2016 年我們提出了一個(gè)開放性問題,“請(qǐng)說(shuō)明您如何理解和定義DevOps?”,從結(jié)果來(lái)看,受訪者對(duì)DevOps 的解釋各不相同,值得注意的是,最多被提及的兩個(gè)概念是“一體化”和“自動(dòng)化”,然而,由于解釋的差異性過大,即便在學(xué)術(shù)界,目前也還沒有對(duì)DevOps 有一個(gè)明確且一致的定義,所以結(jié)果難以進(jìn)行分析,我們?cè)?018 年的問卷中,考慮到新增問題較多,而問卷耗時(shí)對(duì)問卷的反饋率和反饋質(zhì)量都有一定影響,最終去掉了這個(gè)難以分析的問題以縮短受訪者的答題時(shí)間.

? 由于在2016 年忽略了開發(fā)實(shí)踐,所以在2018 年增加了一個(gè)問題“您的團(tuán)隊(duì)在開發(fā)過程中,滿足以下哪些實(shí)踐?”,問題選項(xiàng)中的實(shí)踐均來(lái)源于Puppet Labs 報(bào)告中推薦的最佳實(shí)踐.

? 持續(xù)交付是DevOps 的一個(gè)核心價(jià)值和目標(biāo),所以對(duì)于自動(dòng)化部分,我們?cè)?018 年專門針對(duì)持續(xù)交付,增加了一個(gè)問題,即“在持續(xù)交付中,您的團(tuán)隊(duì)有過以下哪些實(shí)踐?”.問題選項(xiàng)中的實(shí)踐同樣來(lái)源于Puppet Labs報(bào)告.

? 在2016 年,我們沒有加入架構(gòu)的相關(guān)問題.但通過參與工業(yè)界的相關(guān)會(huì)議,我們發(fā)現(xiàn),架構(gòu)反而是工業(yè)界對(duì)于DevOps 最關(guān)注的主題之一,所以,2018 年我們?cè)黾恿藘蓚€(gè)聚焦架構(gòu)的問題,“以下哪些架構(gòu)屬性與您正在開發(fā)的應(yīng)用/服務(wù)的架構(gòu)相吻合?”,鑒于微服務(wù)是當(dāng)前工業(yè)界在DevOps 上討論最多的架構(gòu),另一個(gè)問題是“微服務(wù)架構(gòu)在您企業(yè)中的實(shí)施狀態(tài)是?”.

? 2016 年僅針對(duì)團(tuán)隊(duì)采用的DevOps 方法進(jìn)行了調(diào)查,2018 年新增了精益生產(chǎn)管理相關(guān)實(shí)踐的調(diào)查.

? 在2016 年,我們基于Ebert 等人推薦的DevOps 自動(dòng)化工具列表[19],設(shè)置了工具實(shí)踐的問題選項(xiàng),但基于我們的最新研究結(jié)果[20],該列表并不全面,且與當(dāng)前工業(yè)界工具使用的現(xiàn)狀不完全吻合,所以基于我們的研究結(jié)果,對(duì)受訪者使用了哪些工具的選項(xiàng)進(jìn)行了更新.

? Puppet Labs 最新的報(bào)告[16]指出了領(lǐng)導(dǎo)力對(duì)于DevOps 實(shí)踐有著舉足輕重的影響,所以我們?cè)?018 年也新增了對(duì)于領(lǐng)導(dǎo)力的調(diào)查.

2.2 受訪對(duì)象

問卷以在線的形式進(jìn)行發(fā)布,通過DevOps 社區(qū)及InfoQ China(https://www.infoq.com)等軟件開發(fā)領(lǐng)域的技術(shù)社區(qū)進(jìn)行擴(kuò)散式的傳播,此外,還在南京(全球)軟件大會(huì)(NJSD)(http://www.njsd-china.org/)等會(huì)議上進(jìn)行宣傳以吸引更多的開發(fā)者參與.為了盡可能地收集到更多數(shù)據(jù),在2018 年的問卷分發(fā)過程中,我們還第一時(shí)間將問卷發(fā)送給了所有2016 年的受訪者.考慮到受訪群體均屬于高收入且對(duì)于新技術(shù)有著濃厚興趣的群體,在激勵(lì)參與問卷的方式上,我們沒有采用禮品等與金錢相關(guān)的激勵(lì)方式,而是以受訪者均能第一時(shí)間獲取調(diào)查報(bào)告為激勵(lì),采用該激勵(lì)方式也能夠更好地屏蔽掉對(duì)于DevOps 沒有興趣和經(jīng)驗(yàn)的開發(fā)者,收集到的數(shù)據(jù)能夠保證一個(gè)較高的質(zhì)量.最終,2016 年我們共計(jì)收到了74 家組織或個(gè)人開發(fā)者的有效反饋,2018 年為了開始實(shí)現(xiàn)每年一發(fā)布,明顯縮短了問卷收集時(shí)間,所以反饋數(shù)量略有減少,共計(jì)收到了66 家組織或個(gè)人開發(fā)者的有效反饋.目前,我們已建立數(shù)據(jù)庫(kù),收集和存儲(chǔ)曾經(jīng)參與過或下載過我們所發(fā)布報(bào)告的相關(guān)從業(yè)者的郵箱,相比其他IT 從業(yè)者,他們對(duì)于DevOps 以及我們的調(diào)查更感興趣,這意味著他們有較高的概率會(huì)參與或繼續(xù)參與到我們未來(lái)的調(diào)查中.在未來(lái)的每次調(diào)查中,我們會(huì)通過郵件向他們發(fā)出邀請(qǐng),并不斷更新和維護(hù)郵箱列表,這將為我們收集到更多有效的反饋提供支持.此外,隨著與InfoQ 合作的不斷深入,其也將協(xié)助我們加大對(duì)于年度調(diào)查的宣傳與推廣.

兩次調(diào)查的受訪者在地域、行業(yè)、崗位、所處部門、所處組織規(guī)模和DevOps 經(jīng)驗(yàn)等方面覆蓋面較廣,根據(jù)調(diào)查問卷的發(fā)放形式,即通過技術(shù)社區(qū)及相關(guān)技術(shù)會(huì)議進(jìn)行分發(fā),參與者質(zhì)量較高(這一點(diǎn)從反饋中沒有無(wú)效問卷亦可見一斑),具有一定的代表性.以下將根據(jù)2016 年和2018 年的受訪者的基本信息對(duì)其分布進(jìn)行簡(jiǎn)要描述.

地域.受訪者主要來(lái)源于上海、北京、深圳、南京、杭州等軟件及互聯(lián)網(wǎng)產(chǎn)業(yè)較發(fā)達(dá)地區(qū),其中,來(lái)自上海的受訪者在兩次調(diào)查中均占比最高(兩年分別為23%和18%).這從一個(gè)側(cè)面反映了對(duì)于新技術(shù)、新文化的接受和實(shí)踐程度與一個(gè)地區(qū)的行業(yè)發(fā)展水平有著密切的關(guān)系.在兩次調(diào)查中,我們均未發(fā)現(xiàn)有非一、二線城市的開發(fā)者參與到其中,這很大程度上是由大規(guī)?；騽?chuàng)新型的軟件企業(yè)在國(guó)內(nèi)的地域分布所決定的.

行業(yè).受訪者來(lái)自于和DevOps 有關(guān)的各行各業(yè),涵蓋了科技、互聯(lián)網(wǎng)、金融、教育等領(lǐng)域,但以科技(45%)和互聯(lián)網(wǎng)(22%)企業(yè)為主.所涉行業(yè)之廣說(shuō)明了DevOps 目前已經(jīng)為各行各業(yè)的軟件從業(yè)人員所了解,結(jié)合近兩年各地舉辦的開發(fā)者大會(huì)上關(guān)于DevOps 的火熱討論來(lái)看,DevOps 在國(guó)內(nèi)的宣傳已經(jīng)初見成效,其對(duì)于軟件組織及相關(guān)從業(yè)人員極具吸引力.但考慮到兩次調(diào)查的參與人數(shù)相對(duì)有限,又說(shuō)明了真正在引領(lǐng)國(guó)內(nèi)DevOps 發(fā)展,已經(jīng)積累了一定DevOps 實(shí)踐經(jīng)驗(yàn)的組織及個(gè)人還相對(duì)較少,下文將要詳細(xì)介紹受訪者的實(shí)踐經(jīng)驗(yàn).

崗位.受訪者處于不同工作崗位,包含了在軟件生命周期中負(fù)責(zé)不同階段工作的工程師以及項(xiàng)目和組織的管理者,如圖3 所示,由于兩次調(diào)查的選項(xiàng)不同,所以不具有可比性,但可以看到,兩年的受訪者中DevOps 工程師的占比均較高.這體現(xiàn)了DevOps 已經(jīng)引起了組織中各級(jí)人員的關(guān)注,對(duì)于DevOps 這樣一個(gè)旨在打破開發(fā)和運(yùn)維壁壘,重鑄企業(yè)文化的理念而言,是個(gè)好消息.

Fig.3 The distribution of respondents’ jobs圖3 受訪者崗位分布

部門.受訪者分屬于不同的部門,如圖4 所示,展示了2016 年和2018 年兩次調(diào)查受訪者的所屬部門分布.其中最值得注意的是DevOps 部門的設(shè)立,且占比相當(dāng)可觀(兩年均超過了10%),這體現(xiàn)了其企業(yè)對(duì)于DevOps 的重視,為轉(zhuǎn)型DevOps 設(shè)立了專門的DevOps 部門.結(jié)合受訪者所處崗位進(jìn)行分析,我們發(fā)現(xiàn),2016 年有14%的受訪者為DevOps 工程師,2018 為12%,這表明,幾乎所有的DevOps 工程師均來(lái)自于DevOps 部門,企業(yè)往往不會(huì)在原有部門中增設(shè)DevOps 工程師這一職位,說(shuō)明不同企業(yè)基于DevOps 對(duì)組織結(jié)構(gòu)和人員投入上的差距兩極分化較為明顯.

組織規(guī)模.由于部分企業(yè)并非僅有軟件開發(fā)業(yè)務(wù),例如電商企業(yè)往往還有大量的商業(yè)策劃、商品的售前、售后等人員.所以,基于人數(shù)來(lái)考量組織規(guī)模是不合理的,于是我們從與企業(yè)軟件業(yè)務(wù)能力密切相關(guān)的服務(wù)器數(shù)量上進(jìn)行考量.對(duì)于受訪者所在組織的規(guī)模,2016 年和2018 年的差異不明顯,從20 臺(tái)服務(wù)器以內(nèi)到超過1 000臺(tái)服務(wù)器的組織數(shù)量分布平均,說(shuō)明從小型到大型再到超大規(guī)模的企業(yè)均對(duì)DevOps 有所關(guān)注和實(shí)踐.

經(jīng)驗(yàn).鑒于DevOps 還處于萌芽階段,且中國(guó)大部分企業(yè)相對(duì)起步較晚,經(jīng)驗(yàn)將是衡量DevOps 實(shí)踐水平的一個(gè)重要依據(jù),所以我們從3 個(gè)不同的角度了解受訪者的經(jīng)驗(yàn),包括個(gè)人經(jīng)驗(yàn)、其所在團(tuán)隊(duì)的成員平均經(jīng)驗(yàn)以及其組織經(jīng)驗(yàn)(即已推行DevOps 多少年).如圖5 所示,受訪者個(gè)人經(jīng)驗(yàn)與其所在團(tuán)隊(duì)和組織經(jīng)驗(yàn)基本持平,且超過半數(shù)受訪者的經(jīng)驗(yàn)少于1 年,同時(shí)也不乏一些經(jīng)驗(yàn)超過3 年的個(gè)人或團(tuán)隊(duì).

性別.兩年的結(jié)果相近,超過9 成受訪者為男性,且超過5 成受訪者其所在團(tuán)隊(duì)的女性成員比例低于10%,超過1 成的受訪者所在團(tuán)隊(duì)中沒有女性.整個(gè)行業(yè)仍以男性為主.

Fig.4 The distribution of respondents’ departments圖4 受訪者所屬部門分布

Fig.5 The distribution of respondents’ experiences圖5 受訪者經(jīng)驗(yàn)分布

2.3 分析方法

在此次調(diào)查中,數(shù)量統(tǒng)計(jì)是最基本和最常用的方法.但是為了更深入地分析組織間的差異,我們結(jié)合組織的IT 性能來(lái)分析不同的實(shí)踐因素是否對(duì)其產(chǎn)生影響,DevOps 的目標(biāo)是在保證甚至提高質(zhì)量的前提下,盡可能地縮短從變更提交到變更作為產(chǎn)品一部分交付的時(shí)間,所以我們使用兩個(gè)主要緯度來(lái)衡量IT 性能,即代碼吞吐量和系統(tǒng)穩(wěn)定性.為了更好地衡量DevOps 對(duì)一個(gè)組織的生產(chǎn)活動(dòng)的影響,我們將以上兩個(gè)方面進(jìn)行了量化,最終體現(xiàn)在部署頻率、交付周期、平均修復(fù)時(shí)長(zhǎng)、變更失敗比例這4 個(gè)參數(shù)上.DevOps 讓軟件過程更快,體現(xiàn)在“部署頻率”和“交付周期”上.DevOps 讓軟件過程更穩(wěn),體現(xiàn)在“平均修復(fù)時(shí)長(zhǎng)”和“變更失敗比例”上,我們又根據(jù)收集到的數(shù)據(jù)分布,基于IT 性能區(qū)分了高性能和低性能的團(tuán)隊(duì)進(jìn)行對(duì)比.為了分析DevOps 如何讓開發(fā)人員幸福感提升,我們主要分析了員工計(jì)劃外工作時(shí)間、是否恐懼代碼部署員工以及凈推薦值等幾個(gè)參數(shù)的關(guān)系.為了更進(jìn)一步地了解高性能團(tuán)隊(duì)的驅(qū)動(dòng)因素,主要分析了高性能團(tuán)隊(duì)在DevOps 方面的技術(shù)實(shí)踐,具體分為:(1)實(shí)踐活動(dòng),包括自動(dòng)化、標(biāo)準(zhǔn)化、質(zhì)量保證、敏捷方法、監(jiān)控手段;(2)架構(gòu),團(tuán)隊(duì)正在開發(fā)應(yīng)用/服務(wù)架構(gòu);(3)工具,DevOps各個(gè)階段所對(duì)應(yīng)的工具.為了了解團(tuán)隊(duì)負(fù)責(zé)人如何幫助團(tuán)隊(duì)獲得成功,在2018 年度調(diào)查中,我們使用了Rafferty和Griffin[21]于2004 年提出的變革型領(lǐng)導(dǎo)力模型來(lái)衡量團(tuán)隊(duì)負(fù)責(zé)人的工作表現(xiàn),分別從愿景、智力激發(fā)、個(gè)人認(rèn)可、鼓舞人心和支持型領(lǐng)導(dǎo)這5 個(gè)緯度進(jìn)行分析.另外,我們結(jié)合2016 年度與2018 年度的調(diào)查報(bào)告,綜合統(tǒng)計(jì)出了阻礙DevOps 推行的各方面因素.

3 國(guó)內(nèi)現(xiàn)狀與進(jìn)展

基于上一節(jié)的結(jié)果,從整體來(lái)看,兩次調(diào)查的受訪對(duì)象分布差異較小,這對(duì)于我們基于兩年的數(shù)據(jù)來(lái)對(duì)比分析國(guó)內(nèi)DevOps 的發(fā)展趨勢(shì)提供了基礎(chǔ).基于問卷中問題的設(shè)置,受訪者的基本信息和經(jīng)驗(yàn)兩個(gè)方面已在上一節(jié)中給出詳細(xì)描述,本節(jié)將從IT 性能表現(xiàn)、組織文化及相關(guān)實(shí)踐、開發(fā)與運(yùn)維實(shí)踐、工具支持、領(lǐng)導(dǎo)力、工作比例、員工敬業(yè)度及滿意度和障礙這8 個(gè)方面進(jìn)行討論.

3.1 IT性能表現(xiàn)

從商業(yè)層面上來(lái)說(shuō),我們說(shuō)一個(gè)組織是高效的,意味著該組織不僅可以快速地向市場(chǎng)提供具有關(guān)鍵業(yè)務(wù)的應(yīng)用,并且具有能夠規(guī)避那些可能中斷其商業(yè)價(jià)值的服務(wù)的能力.

對(duì)于IT 組織,在保持對(duì)市場(chǎng)需求的高敏感度的同時(shí),它們還要提供穩(wěn)定、安全并且可預(yù)測(cè)的IT 服務(wù).即:

? 組織是否能夠快速地把一個(gè)想法變成價(jià)值交付到客戶手中?

? 是否具備持續(xù)的提供有價(jià)值的產(chǎn)品的能力?

? 組織的活動(dòng)是否是有效的?

換言之,組織需要實(shí)現(xiàn)既“快”且“穩(wěn)”.“快”可以通過部署頻率和交付周期來(lái)體現(xiàn),而“穩(wěn)”可以通過平均修復(fù)時(shí)長(zhǎng)和變更失敗比例來(lái)體現(xiàn).

高頻率部署也意味著快速和持續(xù)的部署,這有利于組織對(duì)市場(chǎng)需求及時(shí)反應(yīng),使組織能夠通過自動(dòng)化的構(gòu)建、測(cè)試和部署循環(huán)來(lái)快速交付高質(zhì)量的軟件.2016 年的調(diào)查中有32.4%的團(tuán)隊(duì)可以實(shí)現(xiàn)一天之內(nèi)進(jìn)行多次部署,而2018 年基本持平,有33.8%的團(tuán)隊(duì)可以實(shí)現(xiàn).結(jié)合團(tuán)隊(duì)經(jīng)驗(yàn)數(shù)據(jù)我們發(fā)現(xiàn),DevOps 經(jīng)驗(yàn)豐富的團(tuán)隊(duì),部署頻率更高.

交付周期是指團(tuán)隊(duì)從一次代碼提交到成功運(yùn)行于產(chǎn)品中所需要的時(shí)長(zhǎng),主要用于衡量組織應(yīng)對(duì)變更的能力.2016 年的調(diào)查中實(shí)現(xiàn)交付周期少于一天的團(tuán)隊(duì)占比23.5%,而2018 年這一比例增長(zhǎng)了近3 倍,有67.2%的團(tuán)隊(duì)實(shí)現(xiàn)了一天內(nèi)完成交付.此外,結(jié)合團(tuán)隊(duì)經(jīng)驗(yàn)數(shù)據(jù)我們發(fā)現(xiàn),DevOps 經(jīng)驗(yàn)豐富的團(tuán)隊(duì),交付周期更短.

變更失敗比例也就是在對(duì)于應(yīng)用或服務(wù)進(jìn)行變更時(shí),導(dǎo)致了服務(wù)的降級(jí)或隨后修復(fù)的比例情況,所謂變更失敗就是在變更之后導(dǎo)致服務(wù)受損、服務(wù)中斷,需要熱修復(fù),回滾、打補(bǔ)丁等.2016 年有66.2%的受訪團(tuán)隊(duì)可以將變更失敗比例控制在15%以內(nèi),而2018 年80%的團(tuán)隊(duì)可以實(shí)現(xiàn)這一目標(biāo),其中,36.4%的團(tuán)隊(duì)能夠?qū)⒆兏”壤刂圃?%以內(nèi).此外,隨著團(tuán)隊(duì)DevOps 經(jīng)驗(yàn)的增加,變更失敗比例>30%的可能性會(huì)越來(lái)越小;變更失敗比例在16%～45%之間的團(tuán)隊(duì)DevOps 經(jīng)驗(yàn)均小于2 年;DevOps 經(jīng)驗(yàn)在3～5 年之間的團(tuán)隊(duì)均控制在10%之間.

平均修復(fù)時(shí)長(zhǎng)刻畫了一個(gè)團(tuán)隊(duì)?wèi)?yīng)對(duì)意外故障的能力,它指的是當(dāng)線上的產(chǎn)品發(fā)生故障時(shí),平均需要多長(zhǎng)時(shí)間能夠修復(fù)故障并上線.很多組織都無(wú)法忍受哪怕是幾分鐘的故障修復(fù)時(shí)間,因?yàn)檫@往往意味著數(shù)以百萬(wàn)計(jì)利潤(rùn)的流失與用戶滿意度的下降.在這一指標(biāo)上,2016 年(32.4%)和2018 年(30.8%)的調(diào)查結(jié)果基本持平.此外,平均修復(fù)時(shí)長(zhǎng)同樣隨著DevOps 經(jīng)驗(yàn)的增長(zhǎng)而縮短.

發(fā)現(xiàn)1.DevOps 經(jīng)驗(yàn)豐富的團(tuán)隊(duì),IT 性能表現(xiàn)更好;從2016 年～2018 年,交付周期和變更失敗比例性能有著明顯提升,但部署頻率和平均修復(fù)時(shí)長(zhǎng)基本不變.

基于這4 項(xiàng)指標(biāo),我們將團(tuán)隊(duì)區(qū)分為準(zhǔn)高性能和準(zhǔn)低性能團(tuán)隊(duì),劃分標(biāo)準(zhǔn)見表1,圖6 展示了受訪團(tuán)隊(duì)中團(tuán)隊(duì)性能的分布比例,可以看到,2018 年準(zhǔn)高性能明顯增多,這與發(fā)現(xiàn)1 的結(jié)果一致,主要是由于2016 年大量團(tuán)隊(duì)在交付周期和失敗變更比例上難以達(dá)到準(zhǔn)高性能標(biāo)準(zhǔn).后文中將基于該劃分標(biāo)準(zhǔn)結(jié)合團(tuán)隊(duì)性能對(duì)DevOps 實(shí)踐的效果進(jìn)行分析.

Table 1 The standard of IT performance for different teams表1 團(tuán)隊(duì)性能劃分

Fig.6 The proportion of quasi-high performance and quasi-low performance teams圖6 準(zhǔn)高和準(zhǔn)低性能團(tuán)隊(duì)比例

3.2 組織文化及相關(guān)實(shí)踐

組織文化是影響組織經(jīng)濟(jì)表現(xiàn)的最直接的因素之一.人是組織中最關(guān)鍵的資產(chǎn),對(duì)員工的投資將提高員工的企業(yè)認(rèn)同感和工作積極性.對(duì)于文化,借鑒了Puppet Labs 2016 年的報(bào)告,我們主要從組織的氛圍、特質(zhì)、技術(shù)共享和投資4 個(gè)角度進(jìn)行分析.氛圍包含了組織對(duì)于DevOps 的支持和促進(jìn),以及員工能夠從組織氛圍中感受到的認(rèn)同感,比如組織是否鼓勵(lì)員工在軟件的開發(fā)方式中使用DevOps 理論和實(shí)踐,是否信任并給予員工責(zé)任等;技術(shù)共享是指組織是否促進(jìn)開發(fā)人員與運(yùn)維人員之間的溝通來(lái)達(dá)到技術(shù)共享等等.特質(zhì)指的是組織的結(jié)構(gòu)或規(guī)章是否符合DevOps 文化,例如組織是否淡化部門與團(tuán)隊(duì)之間的界限;同一個(gè)項(xiàng)目的各個(gè)團(tuán)隊(duì)是否分散在各地等等.投資指的是組織是否計(jì)劃或正在投資支持DevOps 工具的購(gòu)買或開發(fā);是否投資技術(shù)人員的培訓(xùn)或發(fā)展等等.

我們對(duì)于技術(shù)分享和氛圍占比最高的兩項(xiàng)實(shí)踐進(jìn)行分析,相對(duì)于準(zhǔn)低性能團(tuán)隊(duì)的組織,準(zhǔn)高性能的組織的DevOps 文化氛圍及相關(guān)實(shí)踐做得更好,它們的員工有更高的企業(yè)認(rèn)同感,且其企業(yè)在技術(shù)共享上更加出色.具體體現(xiàn)在4 個(gè)方面,如圖7 所示,在文化氛圍上體現(xiàn)為員工更能感受到組織在乎自己;組織信任員工并給予員工責(zé)任,在技術(shù)分享上體現(xiàn)為組織創(chuàng)建開發(fā)與運(yùn)維共同使用的知識(shí)管理系統(tǒng),組織促進(jìn)開發(fā)與運(yùn)維人員之間的溝通.在特質(zhì)上,準(zhǔn)低和準(zhǔn)高團(tuán)隊(duì)沒有明顯差異,兩年的結(jié)果也基本接近,組織特質(zhì)主要體現(xiàn)為組織有同時(shí)具備開發(fā)和運(yùn)維能力的員工(2016 年占比68%,2018 年占比82%),員工的工作不僅僅只是常規(guī)職業(yè)描述的內(nèi)容(2016年占比34%,2018 年占比30%).在投資上,如圖8 所示,2016 年準(zhǔn)低和準(zhǔn)高團(tuán)隊(duì)在技術(shù)人員和DevOps 支持工具上的投資沒有明顯差距,兩次調(diào)查的準(zhǔn)低團(tuán)隊(duì)也沒有明顯差異;而2018 年的準(zhǔn)高團(tuán)隊(duì)投資上明顯好于2016 年.然而,無(wú)論準(zhǔn)高還是準(zhǔn)低團(tuán)隊(duì),組織在DevOps 上還有明顯不足,平均低于三成的團(tuán)隊(duì)已投資人員培訓(xùn)或支持工具.

發(fā)現(xiàn)2.準(zhǔn)高性能團(tuán)隊(duì)在員工的企業(yè)認(rèn)同感和技術(shù)共享實(shí)踐上做得更好,但在企業(yè)特質(zhì)方面,對(duì)DevOps 的投資上,沒有發(fā)現(xiàn)與準(zhǔn)低性能團(tuán)隊(duì)的明顯差異,雖然2018 年的準(zhǔn)高性能團(tuán)隊(duì)相比2016 年在投資上有明顯提高,但仍處于較低水平.

Fig.7 Cultural atmosphere and technology sharing圖7 文化氛圍與技術(shù)分享

Fig.8 Investment in technicians and supporting tools圖8 技術(shù)人員和支持工具投資

3.3 開發(fā)與運(yùn)維實(shí)踐

開發(fā)與運(yùn)維實(shí)踐主要體現(xiàn)在4 個(gè)方面,即自動(dòng)化、標(biāo)準(zhǔn)化、質(zhì)量保證和開發(fā)方法,其中,開發(fā)方法主要考慮的是團(tuán)隊(duì)是否使用敏捷方法以及使用了哪種敏捷方法.

自動(dòng)化的一大目的是打造完全自動(dòng)化的Delivery Pipeline.自動(dòng)化過程可以使得開發(fā)人員更關(guān)心軟件的邏輯而不用與復(fù)雜的配置打交道.自動(dòng)化也是提高可測(cè)試性、一致性、穩(wěn)定性、部署頻率和實(shí)現(xiàn)持續(xù)交付的核心方法[22].在軟件的構(gòu)建、測(cè)試、部署、發(fā)布和運(yùn)維階段的監(jiān)控和恢復(fù)這些過程中,均能實(shí)現(xiàn)自動(dòng)化過程,所以我們調(diào)查了生命周期不同階段對(duì)應(yīng)的自動(dòng)化過程的實(shí)踐情況,如圖9 所示.受訪的團(tuán)隊(duì)均實(shí)現(xiàn)了部分過程的自動(dòng)化,其中以自動(dòng)構(gòu)建和自動(dòng)部署最為普遍.另外,近半數(shù)的團(tuán)隊(duì)實(shí)現(xiàn)了自動(dòng)測(cè)試以及自動(dòng)監(jiān)控,比例最低的為自動(dòng)恢復(fù).可見,受訪團(tuán)隊(duì)關(guān)注的重點(diǎn)主要在于構(gòu)建、部署、測(cè)試以及監(jiān)控.兩次調(diào)查結(jié)果相似,其中,自動(dòng)更改審批流程為2018 年新增項(xiàng),所以對(duì)2016 年不適用.差異主要體現(xiàn)在自動(dòng)監(jiān)控和基礎(chǔ)設(shè)施自動(dòng)配置管理上,2018 年的調(diào)查結(jié)果中這兩項(xiàng)實(shí)踐的占比反而相比2016 年有所降低,我們認(rèn)為這并不意味著2018 年反而相比2016 年在自動(dòng)化實(shí)踐上有退步,例如大量企業(yè)選擇放棄自動(dòng)化這種解放生產(chǎn)力的方式是不合常理的,所以我們相信,這種差異是由兩次調(diào)查的樣本之間存在的差異造成的.當(dāng)然,這一結(jié)果也揭示出,自動(dòng)監(jiān)控和基礎(chǔ)設(shè)施自動(dòng)配置管理這兩項(xiàng)實(shí)踐的普及率可能并不像2016 年調(diào)查結(jié)果中的那么高.

Fig.9 The ratio of process automation practices圖9 自動(dòng)化過程實(shí)踐比例

圖10 展示了 2018 年受訪團(tuán)隊(duì)所進(jìn)行的具體的自動(dòng)化實(shí)踐的百分比,其中,基于主干開發(fā)占比最大(61%),“代碼和app/系統(tǒng)的配置都有版本控制”緊跟其后(48%).2016 年的結(jié)果與之接近,都顯示出受訪團(tuán)隊(duì)對(duì)于網(wǎng)絡(luò)(實(shí)現(xiàn)了網(wǎng)絡(luò)基礎(chǔ)設(shè)施自動(dòng)化)、安全性(在交付過程中有安全團(tuán)隊(duì))方面有所欠缺.這在某種程度上說(shuō)明,國(guó)內(nèi)團(tuán)隊(duì)目前主要關(guān)注開發(fā)、運(yùn)維與質(zhì)量保證三者之間的協(xié)作,暫時(shí)未將安全考慮在內(nèi).

Fig.10 The ratio of specific process automation practices in 2018圖10 2018 年具體自動(dòng)化實(shí)踐比例

發(fā)現(xiàn)3.國(guó)內(nèi)團(tuán)隊(duì)自動(dòng)化實(shí)踐已基本普及,尤其是在構(gòu)建、部署、測(cè)試和監(jiān)控等階段.但在自動(dòng)恢復(fù)上還明顯重視不足.此外,國(guó)內(nèi)還鮮有充分將安全和網(wǎng)絡(luò)基礎(chǔ)設(shè)施自動(dòng)化考慮進(jìn)來(lái)的團(tuán)隊(duì).

標(biāo)準(zhǔn)化是為了協(xié)調(diào)開發(fā)項(xiàng)目的各個(gè)階段和各個(gè)部分聯(lián)系和銜接而做出的約束和規(guī)定.良好的標(biāo)準(zhǔn)化實(shí)踐可以提高軟件可靠性、可維護(hù)性和可移植性,縮短軟件的開發(fā)周期和降低運(yùn)行維護(hù)成本[23].然而,由于軟件開發(fā)的特性,標(biāo)準(zhǔn)化往往難以得到嚴(yán)格的實(shí)施.僅有約6%的團(tuán)隊(duì)沒有任何的標(biāo)準(zhǔn)化實(shí)踐.采用最多的標(biāo)準(zhǔn)化實(shí)踐是“對(duì)DevOps 的預(yù)測(cè)都是基于實(shí)證角度,除非極具專業(yè)性,否則避免使用數(shù)學(xué)模型”,占比45%.而“應(yīng)用CMM 或CMMI 以及ITIL 標(biāo)準(zhǔn)到產(chǎn)品上”的占比最少,僅29%.有32%的團(tuán)隊(duì)表示會(huì)“從企業(yè)過程中汲取靈感”.

發(fā)現(xiàn)4.受訪團(tuán)隊(duì)已普遍實(shí)現(xiàn)了標(biāo)準(zhǔn)化,但更多的是基于實(shí)證的角度,缺少量化的數(shù)學(xué)模型的構(gòu)建.

質(zhì)量保證是質(zhì)量管理的一部分,致力于使得所提供的產(chǎn)品質(zhì)量得到客戶的信任.質(zhì)量保證是指為使人們確信產(chǎn)品或服務(wù)能夠滿足質(zhì)量要求而在質(zhì)量管理體系中實(shí)施并根據(jù)需要進(jìn)行證實(shí)的全部有計(jì)劃和有系統(tǒng)的活動(dòng)[24].我們主要從3 個(gè)方面考量質(zhì)量保證實(shí)踐的程度,如圖11 所示.其中,最為引人注目的就是“使用實(shí)時(shí)的用戶監(jiān)控在早期發(fā)現(xiàn)問題”這一比例從2016 年到2018 年有了極大增長(zhǎng).同時(shí),2016 年有超過三分之一的團(tuán)隊(duì)沒有任何質(zhì)量保證實(shí)踐,而在2018 年的調(diào)查數(shù)據(jù)中,僅有約3%的團(tuán)隊(duì)沒有任何質(zhì)量保證實(shí)踐.

Fig.11 The ratio of different quality assurance practices圖11 質(zhì)量保證實(shí)踐比例

發(fā)現(xiàn)5.國(guó)內(nèi)團(tuán)隊(duì)在質(zhì)量保證實(shí)踐上有著明顯的進(jìn)步,且目前幾乎所有團(tuán)隊(duì)均有質(zhì)量保證實(shí)踐.

敏捷方法對(duì)于DevOps 并不是必須的,雖然DevOps 是敏捷的一種延伸,且敏捷與DevOps 在自動(dòng)構(gòu)建、自動(dòng)測(cè)試、持續(xù)集成與持續(xù)交付等方面都具有一致性.許多業(yè)界專家認(rèn)為將敏捷與DevOps 結(jié)合起來(lái)將獲得更好的企業(yè)效益[25].從2016 年到2018 年,沒有使用任何敏捷方法的團(tuán)隊(duì)比例從27.4%下降到了19.7%.在具體方法的使用上,兩年差別不大,超過40%的團(tuán)隊(duì)使用Scrum,12%的團(tuán)隊(duì)使用Kanban,使用其他方法的團(tuán)隊(duì)占比均少于5%.

發(fā)現(xiàn)6.國(guó)內(nèi)團(tuán)隊(duì)對(duì)于敏捷方法的采用呈現(xiàn)增長(zhǎng)趨勢(shì),雖然各種敏捷方法均有團(tuán)隊(duì)使用,但Scrum 始終表現(xiàn)出一枝獨(dú)秀的態(tài)勢(shì).

3.4 工具支持

在2016 年,基于Ebert 等人推薦的DevOps 自動(dòng)化工具列表[19],我們調(diào)查了15 種支持DevOps 實(shí)踐的工具在受訪團(tuán)隊(duì)中的使用情況.我們使用相同的工具列表作為選項(xiàng),分別問了“使用過以下哪些工具?”和“推薦以下哪些工具?”兩個(gè)問題.圖12 列出了這15 種工具推薦和使用(推薦+未推薦)情況.將近六成的團(tuán)隊(duì)會(huì)使用JenKins(58%),且?guī)缀蹙扑]該工具.Maven 也被超過一半的團(tuán)隊(duì)使用(55%),且其中超過三分之二的受訪者推薦該工具.Ant 也有較高的使用率(39%),然而,僅不到一半的使用過的團(tuán)隊(duì)推薦該工具.相反地,ReamCityChef、Chef、Bamboo 和New Relic 雖然使用率不高,但使用者幾乎均推薦這些工具.Graylog 未發(fā)現(xiàn)有團(tuán)隊(duì)使用.

在2018 年的調(diào)查問卷中,基于我們對(duì)于DevOps 自動(dòng)化支持工具的研究成果[20],選取了Stack Overflow(https://stackoverflow.com/)和現(xiàn)有文獻(xiàn)中討論最多的工具,調(diào)整了“使用過以下哪些工具?”問題中的選項(xiàng).考慮到無(wú)法窮盡所有的DevOps 工具(僅從Stack Overflow 中,我們就識(shí)別到了178 個(gè)不同的工具[20]),且當(dāng)用戶需要以文字輸入時(shí)會(huì)更加慎重,我們將“推薦以下哪些工具?”改為了填空式的開放性問題.

Fig.12 The tools used and recommended by the teams in 2016圖12 2016 年團(tuán)隊(duì)DevOps 的工具使用與推薦

如圖13 所示,左圖統(tǒng)計(jì)了準(zhǔn)高性能團(tuán)隊(duì)工具的使用比例,超過半數(shù)的團(tuán)隊(duì)使用了Docker、JenKins 和Git.比較2016 年和2018 年的結(jié)果我們可以發(fā)現(xiàn),由于兩次問卷所列工具列表存在差異,所以結(jié)果存在明顯差異,但兩次調(diào)查都存在一些被普遍使用的工具,這充分說(shuō)明了DevOps 工具的多樣性以及國(guó)內(nèi)團(tuán)隊(duì)工具使用的普遍性.JenKins 和Ansible 在兩次調(diào)查中使用率都非常高,同時(shí)還有著極高的推薦率,在2018 年的調(diào)查中加入了Docker,立刻超越JenKins 成為了使用率最高的工具.圖13 中右圖展示了受訪者推薦的工具的頻次,與2016 年結(jié)果一樣,JenKins 排在榜首.

Fig.13 The tools used and recommended by the teams in 2018圖13 2018 年團(tuán)隊(duì)DevOps 的工具使用與推薦

發(fā)現(xiàn)7.國(guó)內(nèi)DevOps 團(tuán)隊(duì)對(duì)工具的使用較為普遍,且在工具選擇上呈現(xiàn)了多樣性.在多樣性中也突顯出了一些被廣泛使用和值得推薦的工具,如JenKins、Ansible 和Docker 等.

3.5 領(lǐng)導(dǎo)力

團(tuán)隊(duì)負(fù)責(zé)人是組織提升性能、獲得經(jīng)濟(jì)增長(zhǎng)的至關(guān)重要的一環(huán).負(fù)責(zé)人的工作表現(xiàn)直接影響到組織的文化氛圍、團(tuán)隊(duì)的IT 表現(xiàn)以及團(tuán)隊(duì)對(duì)DevOps 的投資比例等.在2018 年的調(diào)查中,我們使用了Rafferty 和Griffin[22]于2004 年提出的變革型領(lǐng)導(dǎo)力模型來(lái)衡量團(tuán)隊(duì)負(fù)責(zé)人的工作表現(xiàn).該模型由5 個(gè)方面構(gòu)成.

? 愿景:(1)理解組織方向;(2)理解團(tuán)隊(duì)方向;(3)理解團(tuán)隊(duì)5 年內(nèi)方向.

? 支持型領(lǐng)導(dǎo):(1)在行動(dòng)之前考慮他人的感受;(2)思考他人的個(gè)體需求;(3)關(guān)心個(gè)人興趣.

? 鼓舞人心:(1)激發(fā)團(tuán)隊(duì)成員的自豪感;(2)宣傳團(tuán)隊(duì)內(nèi)部的正能量;(3)激發(fā)熱情和積極性;(4)鼓勵(lì)人們看到這種變化帶來(lái)的機(jī)會(huì).

? 智力激發(fā):(1)挑戰(zhàn)團(tuán)隊(duì)現(xiàn)狀;(2)挑戰(zhàn)團(tuán)隊(duì)不斷提出新問題;(3)挑戰(zhàn)團(tuán)隊(duì)對(duì)工作的基本設(shè)想.

? 個(gè)人認(rèn)可:(1)贊揚(yáng)高出平均水平的工作;(2)認(rèn)可工作質(zhì)量的提高;(3)親自贊美個(gè)人的出色表現(xiàn).

調(diào)查結(jié)果顯示,87.1%的準(zhǔn)高性能團(tuán)隊(duì)負(fù)責(zé)人可以有效地幫助團(tuán)隊(duì),而準(zhǔn)低性能團(tuán)隊(duì)中這一比例為71.4%.具體來(lái)說(shuō),準(zhǔn)高性能團(tuán)隊(duì)在愿景這一項(xiàng)比準(zhǔn)低性能團(tuán)隊(duì)多出了13%;鼓舞人心多出了69%;智力激發(fā)多出了37%;個(gè)人認(rèn)可多出了39%;在支持型領(lǐng)導(dǎo)上差異不明顯.這一結(jié)果說(shuō)明,準(zhǔn)高性能團(tuán)隊(duì)負(fù)責(zé)人的領(lǐng)導(dǎo)力更強(qiáng),而更強(qiáng)的領(lǐng)導(dǎo)力被認(rèn)為可以有效地幫助團(tuán)隊(duì),幫助直接體現(xiàn)在了團(tuán)隊(duì)IT 性能更高這一點(diǎn)上.反過來(lái)說(shuō),這種領(lǐng)導(dǎo)力上的顯著差距也說(shuō)明準(zhǔn)高性能團(tuán)隊(duì)對(duì)負(fù)責(zé)人的領(lǐng)導(dǎo)力更加重視,甚至是有更高的要求.

發(fā)現(xiàn)8.準(zhǔn)高性能團(tuán)隊(duì)更重視負(fù)責(zé)人的領(lǐng)導(dǎo)力,且團(tuán)隊(duì)負(fù)責(zé)人的領(lǐng)導(dǎo)力的提升對(duì)于團(tuán)隊(duì)IT 性能表現(xiàn)的提升有著切實(shí)的好處.

3.6 工作比例

對(duì)于開發(fā)人員而言,計(jì)劃外的工作,比如代碼調(diào)試、修復(fù)Bug 等都被認(rèn)為是沒有建設(shè)性的工作任務(wù),這樣的工作對(duì)于開發(fā)人員而言沒有任何成就感.計(jì)劃外的工作時(shí)間在開發(fā)人員中的全部工作時(shí)間中所占比例越低,就意味著開發(fā)人員在自己的主要工作上的時(shí)間和精力投入越多,越少地被外界干擾.

在2018 年調(diào)查的數(shù)據(jù)中,準(zhǔn)高性能團(tuán)隊(duì)中,83.33%的受訪者表示其用于計(jì)劃外工作的時(shí)間小于30%,而這一數(shù)字在非高性能團(tuán)隊(duì)中則為64.71%.此外,在準(zhǔn)高性能團(tuán)隊(duì)中,計(jì)劃外工作時(shí)間占比超過50%的僅占6.67%,而對(duì)準(zhǔn)低性能團(tuán)隊(duì)而言,這一比例就達(dá)到了17.64%.

發(fā)現(xiàn)9.DevOps 化越成熟,即IT 性能表現(xiàn)較高的團(tuán)隊(duì),其成員的計(jì)劃外工作時(shí)間相對(duì)占比也越少.

3.7 員工敬業(yè)度及滿意度

員工敬業(yè)度及滿意度是衡量員工愿意留在公司并努力為公司服務(wù)的程度.至今,全球領(lǐng)先的人力資源咨詢管理公司Aon Hewitt 進(jìn)行的全球員工敬業(yè)度及滿意度調(diào)查已覆蓋超過7 000 家公司,其2017 年的調(diào)查結(jié)果顯示,員工敬業(yè)度與公司績(jī)效之間存在密切關(guān)系(http://www.aon.com/engagement17/).在調(diào)查中,我們采用了Employee Net Promoter Scores(eNPS)來(lái)衡量員工的敬業(yè)度,其主要體現(xiàn)在以下3 個(gè)問題上.

? 您愿意向您的朋友或同事推薦您團(tuán)隊(duì)的產(chǎn)品或服務(wù)嗎?

? 您愿意向您的朋友或過去的同事推薦您的組織嗎?

? 您愿意向您的朋友或同事推薦您的團(tuán)隊(duì)嗎?

eNPS 采用10 分制的打分機(jī)制,其中,0～6 分為貶損者,7～8 分為被動(dòng)者,9～10 分為推薦者.2016 年與2018 年的結(jié)果相近,其中,2018 年的結(jié)果顯示,準(zhǔn)高性能團(tuán)隊(duì)的成員,相比準(zhǔn)低性能團(tuán)隊(duì)的成員,在這3 個(gè)問題中推薦者的占比分別高出1.34、1.35 和1.21 倍.

發(fā)現(xiàn)10.DevOps 化越成熟,即IT 性能表現(xiàn)較高的團(tuán)隊(duì),其員工敬業(yè)度及滿意度更高.

3.8 障 礙

盡管DevOps 能夠帶來(lái)更頻繁的部署頻率,構(gòu)建更有創(chuàng)造性的開發(fā)團(tuán)隊(duì),創(chuàng)造更多的商業(yè)價(jià)值,但企業(yè)在實(shí)際的轉(zhuǎn)型和自上而下的推行中,會(huì)面臨各種各樣的障礙,我們?cè)趩柧碇辛谐隽? 個(gè)可能的障礙供受訪者多選,在問題選項(xiàng)的設(shè)置上,我們參考了Bass 等人權(quán)威著作中的“Barriers”章節(jié)[6].綜合2016 年和2018 年的調(diào)查結(jié)果,有5 個(gè)最普遍的障礙(被超過四分之一的受訪者認(rèn)為是障礙).

? 組織行業(yè)的限制(46%);

? 不同部門的目標(biāo)不一致(46%);

? 員工還不理解DevOps 的概念(38%);

? 組織缺少具備DevOps 經(jīng)驗(yàn)的專家(33%);

? 缺乏配置使用相關(guān)工具的專業(yè)知識(shí)和人才(25%).

發(fā)現(xiàn)11.阻礙DevOps 推行的五大因素中與“人”相關(guān)的因素高達(dá)80%,僅組織行業(yè)一條與“人”無(wú)關(guān).

4 國(guó)內(nèi)外現(xiàn)狀對(duì)比

本節(jié)將對(duì)我們發(fā)布的兩份國(guó)內(nèi)調(diào)查結(jié)果與Puppet Labs 從2013 年～2017 年(截至2018 年7 月,Puppet Labs還沒有發(fā)布本年度的調(diào)查報(bào)告)發(fā)布的5 份DevOps 全球現(xiàn)狀調(diào)查報(bào)告結(jié)果,針對(duì)可以量化且具有對(duì)比意義的部分進(jìn)行對(duì)比,并對(duì)呈現(xiàn)較明顯差距的部分進(jìn)行討論分析,以期對(duì)國(guó)內(nèi)當(dāng)前發(fā)展?fàn)顩r進(jìn)行定位.

4.1 組織結(jié)構(gòu)

在第2.2 節(jié)有關(guān)部門這一部分,我們提到目前國(guó)內(nèi)已有部分企業(yè)專門設(shè)立了DevOps 部門,但通過與國(guó)外的受訪者所屬部門分布對(duì)比可以發(fā)現(xiàn),在《2017 State of DevOps Report》中,DevOps 部門占比高達(dá)27%,而在國(guó)內(nèi)2018 年的調(diào)查中,僅有12%的受訪者是來(lái)自DevOps 部門的工程師,且相比2016 年的14%還略有下降.這說(shuō)明了國(guó)內(nèi)企業(yè)對(duì)于DevOps 的重視程度,甚至是轉(zhuǎn)型DevOps 企業(yè)比例還存在不小的差距.Puppet Labs 從2014 年開始統(tǒng)計(jì)DevOps 部門占比,其經(jīng)歷了從2014 年的16%,到2015 的19%,2016 年的22%,再到2017 年的27%的穩(wěn)定增長(zhǎng).結(jié)合DevOps 部門和DevOps 工程師崗位兩項(xiàng)結(jié)果作進(jìn)一步的對(duì)比,可以發(fā)現(xiàn),Puppet 的2014 年的受訪者中DevOps 工程師的比例已經(jīng)高達(dá)31%,說(shuō)明除了改變組織結(jié)構(gòu),增設(shè)DevOps 部門的企業(yè)外,還有相當(dāng)一部分企業(yè)選擇變動(dòng)更小的方式,即增加新的崗位.

發(fā)現(xiàn)12.國(guó)內(nèi)在組織結(jié)構(gòu)上針對(duì)DevOps 的改進(jìn),還處于全球2014 年甚至之前的水平,且兩極分化嚴(yán)重,鮮有選擇折中方案,即不增加部門只增加新崗位的企業(yè).在DevOps 工程師這一新崗位的資源投入上,即使與2014年的國(guó)際水平相比,也還普遍存在明顯差距.

4.2 IT性能表現(xiàn)

目前國(guó)際上對(duì)于高性能團(tuán)隊(duì)的定義為部署頻率為一天多次,交付周期和平均修復(fù)時(shí)長(zhǎng)在1 小時(shí)以內(nèi),團(tuán)隊(duì)變更失敗比例在0～15%[15].如果按照此標(biāo)準(zhǔn)衡量國(guó)內(nèi)受訪團(tuán)隊(duì),我們發(fā)現(xiàn),2016 年的受訪團(tuán)隊(duì)無(wú)一能達(dá)到該標(biāo)準(zhǔn),2018 年僅有6%的團(tuán)隊(duì)可以達(dá)到這一標(biāo)準(zhǔn),這雖然在一定程度上說(shuō)明了部分國(guó)內(nèi)團(tuán)隊(duì)在IT 性能上有了明顯的進(jìn)步,但總體來(lái)看,國(guó)內(nèi)與國(guó)際水平還存在明顯的差距.針對(duì)這4 個(gè)度量對(duì)2018 年數(shù)據(jù)進(jìn)行更細(xì)化的分析:35%的團(tuán)隊(duì)可以在部署頻率上達(dá)標(biāo),甚至有14%的團(tuán)隊(duì)可以將部署頻率進(jìn)一步提高到1 小時(shí)1 次甚至多次;僅15%的團(tuán)隊(duì)可以在交付周期上達(dá)標(biāo),如果將這一標(biāo)準(zhǔn)放寬到中等性能團(tuán)隊(duì)標(biāo)準(zhǔn)(1 月以內(nèi)),有94%的團(tuán)隊(duì)可以達(dá)標(biāo).事實(shí)上,68%的團(tuán)隊(duì)可以實(shí)現(xiàn)1 天以內(nèi)完成交付;30%的團(tuán)隊(duì)可以在平均修復(fù)時(shí)長(zhǎng)上達(dá)標(biāo);在變更失敗比例上達(dá)標(biāo)的團(tuán)隊(duì)高達(dá)82%.由此可以發(fā)現(xiàn),交付周期的控制是當(dāng)前制約國(guó)內(nèi)團(tuán)隊(duì)符合高性能團(tuán)隊(duì)標(biāo)準(zhǔn)的最主要因素,而這一指標(biāo)恰恰反映了國(guó)內(nèi)團(tuán)隊(duì)在開發(fā)和運(yùn)維的銜接上還存在明顯不足,這正是DevOps 不成熟的充分表現(xiàn).

發(fā)現(xiàn)13.國(guó)內(nèi)團(tuán)隊(duì)在變更失敗比例的控制上表現(xiàn)出色,但在交付周期上與國(guó)際高水平存在明顯差距,綜合4 項(xiàng)IT 性能指標(biāo),國(guó)內(nèi)僅有6%的受訪團(tuán)隊(duì)能夠達(dá)到國(guó)際上的高IT 性能標(biāo)準(zhǔn).

4.3 開發(fā)與運(yùn)維實(shí)踐

比較遺憾的一點(diǎn)是,在組織文化及相關(guān)實(shí)踐、開發(fā)與運(yùn)維實(shí)踐和工具支持這3 個(gè)對(duì)于DevOps 極其重要的方面,由于Puppet Labs 缺少對(duì)于原始可量化的數(shù)據(jù)的報(bào)告,難以進(jìn)行對(duì)比,但我們還是從中獲得了一個(gè)較大的發(fā)現(xiàn).

發(fā)現(xiàn)14.國(guó)內(nèi)外對(duì)于基于主干開發(fā)這一實(shí)踐備受推崇,這似乎已經(jīng)成為了一種必備的實(shí)踐.

4.4 工作比例

在工作比例上,國(guó)際上同樣也呈現(xiàn)了高性能團(tuán)隊(duì)比低性能團(tuán)隊(duì)的計(jì)劃外工作比例少的現(xiàn)象.此外,國(guó)內(nèi)準(zhǔn)高性能團(tuán)隊(duì)的計(jì)劃外工作比例,與國(guó)際上高性能團(tuán)隊(duì)的比例接近.

發(fā)現(xiàn)15.在工作比例上,國(guó)內(nèi)的分布情況與國(guó)際水平接近,呈現(xiàn)出良性的結(jié)果.

4.5 部署痛苦程度

關(guān)于是否對(duì)部署感到痛苦這一問題,我們提供了從“一點(diǎn)也不痛苦”到“害怕部署”4 個(gè)不同痛苦程度的選項(xiàng),結(jié)果出乎我們的預(yù)料.從Puppet Labs 在2017 年的報(bào)告結(jié)果來(lái)看,高性能的團(tuán)隊(duì)得益于自動(dòng)化實(shí)踐的充分開展,面對(duì)部署,比低性能團(tuán)隊(duì)感到更輕松.而我們?cè)?018 年的調(diào)查中卻得到了一個(gè)完全相反的結(jié)果,23.3%的準(zhǔn)高性能團(tuán)隊(duì)受訪者表示其和團(tuán)隊(duì)都害怕代碼部署,而準(zhǔn)低性能團(tuán)隊(duì)表示害怕的僅為8.8%.

對(duì)于這一現(xiàn)象的一個(gè)可能的解釋是,準(zhǔn)高性能團(tuán)隊(duì)內(nèi)部對(duì)于部署有著更高的要求和目標(biāo),這一方面促成了他們實(shí)現(xiàn)更快更穩(wěn)的部署,另一方面對(duì)他們可能是更大的挑戰(zhàn)和考驗(yàn).由第4.2 節(jié)我們可以發(fā)現(xiàn),對(duì)比國(guó)際上高性能團(tuán)隊(duì)的標(biāo)準(zhǔn),國(guó)內(nèi)團(tuán)隊(duì)的IT 性能從2016 年到2018 年有明顯提升,但還存在巨大的差距,一方面說(shuō)明了國(guó)內(nèi)生產(chǎn)力的滯后,另一方面也說(shuō)明了國(guó)內(nèi)水平在逐漸提高,在發(fā)展中階段感受到痛苦是正常現(xiàn)象.國(guó)內(nèi)準(zhǔn)高性能團(tuán)隊(duì)和準(zhǔn)低性能團(tuán)隊(duì)的差距可能是源于兩方面的,一方面是準(zhǔn)高性能團(tuán)隊(duì)進(jìn)步更快,另一方面是準(zhǔn)高性能團(tuán)隊(duì)在商業(yè)目標(biāo)上對(duì)于IT 性能相對(duì)要求更高,這兩方面最終體現(xiàn)在組織對(duì)準(zhǔn)高性能團(tuán)隊(duì)在IT 性能上不斷提出更高的要求.

發(fā)現(xiàn)16.國(guó)內(nèi)性能高的團(tuán)隊(duì)反而更害怕部署,與國(guó)際上報(bào)告出來(lái)的結(jié)果相反.這實(shí)際上是,標(biāo)準(zhǔn)逐漸與國(guó)際接軌,而生產(chǎn)力卻發(fā)展滯后的體現(xiàn).

4.6 障 礙

在Puppet 的2013 年的報(bào)告中,識(shí)別出了采用DevOps 所面臨的6 個(gè)最大的障礙.

? 團(tuán)隊(duì)不理解DevOps 的價(jià)值(48%);

? 開發(fā)和運(yùn)維團(tuán)隊(duì)沒有相同的管理結(jié)構(gòu)(43%);

? 沒有工具支持(33%);

? 沒有時(shí)間嘗試DevOps(31%);

? 缺乏成功轉(zhuǎn)型的支持和保障(19%);

? 嘗試轉(zhuǎn)型DevOps 的成本過高(5%).

這6 條障礙與我們所收集到的制約國(guó)內(nèi)企業(yè)實(shí)踐DevOps 面臨的障礙非常相似.主要體現(xiàn)在固有的組織文化和結(jié)構(gòu)與DevOps 的要求差異較大,為了實(shí)現(xiàn)變革所需的工具、人力等的資源配置不足以扭轉(zhuǎn)差異.企業(yè)的最終目標(biāo)是實(shí)現(xiàn)商業(yè)價(jià)值的最大化,所以DevOps 的轉(zhuǎn)型與否,投入多少進(jìn)行轉(zhuǎn)型的根本問題在于,轉(zhuǎn)型所帶來(lái)的回報(bào)是否大于轉(zhuǎn)型所需的開銷.這一問題很難給出一致的標(biāo)準(zhǔn)答案,DevOps 所能帶來(lái)的比如交付周期上的變化并不對(duì)于所有業(yè)務(wù)都是必須的,對(duì)于電商而言,一分鐘的宕機(jī)意味著數(shù)以萬(wàn)計(jì)的財(cái)富的銷售額的流失,而對(duì)于一個(gè)有著充分技術(shù)壁壘的非在線的軟件產(chǎn)品開發(fā)的企業(yè)而言,交付周期、部署頻率等指標(biāo)可能并不需要追求極致.

發(fā)現(xiàn)17.國(guó)內(nèi)企業(yè)當(dāng)前在實(shí)踐DevOps 所面臨的障礙與國(guó)際上2013 年所面臨的障礙相似,其根本問題在企業(yè)對(duì)于DevOps 的態(tài)度和需要的程度.此外,還有一個(gè)突出的問題在于,國(guó)內(nèi)面臨著獨(dú)有的DevOps 人才緊缺的問題.

5 討 論

通過對(duì)兩次調(diào)查研究結(jié)果的分析與對(duì)比,以及與Puppet Labs 的報(bào)告的對(duì)比,我們共總結(jié)出了17 條發(fā)現(xiàn).綜合分析這17 條發(fā)現(xiàn),梳理出了3 條綜合發(fā)現(xiàn),進(jìn)一步地,基于3 條綜合發(fā)現(xiàn),我們?cè)趯?shí)踐和研究這兩個(gè)方面提出了多項(xiàng)建議,以思維導(dǎo)圖的形式展現(xiàn)出來(lái),如圖14 所示.

Fig.14 Recommendations for practice and research based on survey findings圖14 基于調(diào)查發(fā)現(xiàn)的實(shí)踐與研究方向建議

5.1 綜合分析

綜合發(fā)現(xiàn)1.基于發(fā)現(xiàn)3、5、7、16,我們發(fā)現(xiàn)雖然國(guó)內(nèi)的工具和DevOps 實(shí)踐在各個(gè)團(tuán)隊(duì)中已逐漸普及,且普及程度較高,但與國(guó)際水平相比,IT 性能表現(xiàn)依然不夠理想,發(fā)展不夠均衡(發(fā)現(xiàn)13,15),變更失敗比例雖有良好表現(xiàn),但交付周期還有明顯不足.基于發(fā)現(xiàn)8、11 和17,可以發(fā)現(xiàn)人的因素是DevOps 發(fā)展的最大障礙,體現(xiàn)在領(lǐng)導(dǎo)力不足、人才緊缺、缺乏DevOps 知識(shí)和技能3 個(gè)方面,這與組織對(duì)人員培訓(xùn)的投資不足有著密切的關(guān)系(發(fā)現(xiàn)2、12).大部分國(guó)內(nèi)組織DevOps 起步較晚,經(jīng)驗(yàn)不足也是原因之一,DevOps 的成熟需要以經(jīng)驗(yàn)為基礎(chǔ),循序漸進(jìn)(發(fā)現(xiàn)1).此外,我們還發(fā)現(xiàn),大量組織的過程成熟度還不夠高,例如,雖然組織普遍實(shí)現(xiàn)了標(biāo)準(zhǔn)化,但鮮有能夠進(jìn)一步構(gòu)建數(shù)學(xué)模型定量管理和改進(jìn)的過程(發(fā)現(xiàn)4),以CMMI[26]成熟度模型來(lái)評(píng)價(jià),這些組織的過程成熟度是難以達(dá)到4 級(jí)的,這可能也是制約組織推行DevOps 的一個(gè)較大障礙.

綜合發(fā)現(xiàn)2.我們可以看到DevOps 給組織及員工帶來(lái)的好處,隨著DevOps 的逐漸成熟,員工的計(jì)劃外工作將減少(發(fā)現(xiàn)9),這有利于軟件過程的可管理性和易預(yù)測(cè)性.這樣的組織,員工將有更高的敬業(yè)度和滿意度(發(fā)現(xiàn)10),這有利于組織的可持續(xù)性發(fā)展.

綜合發(fā)現(xiàn)3.發(fā)現(xiàn)6、14 說(shuō)明Scrum 是目前主流過程方法,而在開發(fā)方式上,基于主干開發(fā)在產(chǎn)業(yè)界是主流.

5.2 實(shí)踐建議

以17 項(xiàng)發(fā)現(xiàn)作為證據(jù),3 項(xiàng)綜合分析作為過程結(jié)果,我們從弱項(xiàng)、人、工具及實(shí)踐這3 方面給出實(shí)踐建議.

? 從調(diào)查結(jié)果來(lái)看,國(guó)內(nèi)組織IT 性能的主要弱項(xiàng)是交付周期;自動(dòng)化實(shí)踐中的自動(dòng)更改審批流程和自動(dòng)恢復(fù)相較于其他自動(dòng)化實(shí)踐應(yīng)用較少.這些弱項(xiàng)可以作為組織未來(lái)改進(jìn)的著眼點(diǎn).

? 在工具和培訓(xùn)上加大投資,強(qiáng)化員工的知識(shí)和技能以及相關(guān)的工具支持.同時(shí),關(guān)注和提高團(tuán)隊(duì)負(fù)責(zé)人的領(lǐng)導(dǎo)力,從而提高組織的軟件過程成熟度,這些是DevOps 化的基礎(chǔ).項(xiàng)目及工作計(jì)劃會(huì)因此更加準(zhǔn)確,團(tuán)隊(duì)生產(chǎn)力會(huì)有所提高,員工計(jì)劃外工作會(huì)減少,從而,員工的敬業(yè)度和滿意度會(huì)提高,形成良性循環(huán).

? 工具和實(shí)踐的推薦基于受訪者采用的比例.開發(fā)過程推薦Scrum 方法,開發(fā)方式推薦基于主干開發(fā),工具推薦JenKins、Ansible 和Docker.雖然通過對(duì)過程構(gòu)建數(shù)學(xué)模型進(jìn)行定量管理的組織較少,但這是組織尋求突破的必要手段.

5.3 研究方向

基于調(diào)查中發(fā)現(xiàn)的問題,對(duì)于研究方向從教育、組織轉(zhuǎn)型、評(píng)價(jià)3 方面,我們提出了多個(gè)研究問題.

DevOps 教育問題.

? DevOps 工程師需要具備哪些技能?前文我們解釋了人的重要性,國(guó)內(nèi)DevOps 人才緊缺.一名DevOps 工程師具體需要哪些技能,如何培養(yǎng)一名DevOps 工程師,目前仍然沒有標(biāo)準(zhǔn)答案.

? DevOps 團(tuán)隊(duì)負(fù)責(zé)人需要具備哪些領(lǐng)導(dǎo)力?除了培養(yǎng)DevOps 工程師以外,提升團(tuán)隊(duì)負(fù)責(zé)人的領(lǐng)導(dǎo)力也是必要的,雖然對(duì)于領(lǐng)導(dǎo)力等已有大量相關(guān)研究,但在DevOps 背景下,對(duì)團(tuán)隊(duì)負(fù)責(zé)人有哪些新的要求仍是未知的.

DevOps 組織轉(zhuǎn)型問題.

? DevOps 轉(zhuǎn)型期如何配置資源?組織如何轉(zhuǎn)型,在轉(zhuǎn)型中如何配置資源是一個(gè)龐大的且眾說(shuō)紛紜的命題,采用經(jīng)驗(yàn)研究方法,可能可以為該問題尋求到一個(gè)合理的答案,為更多組織科學(xué)地實(shí)現(xiàn)DevOps 化提供基礎(chǔ).

? DevOps 轉(zhuǎn)型需要投入多少資源?轉(zhuǎn)型必然意味著資源的投入,我們觀察到有大量組織對(duì)DevOps 還持觀望態(tài)度,一方面不知道組織當(dāng)前是否需要DevOps 化,另一方面對(duì)需要多少投入心里沒底.

? DevOps 的最佳工具和實(shí)踐是什么?工具和實(shí)踐是DevOps 化落地的基礎(chǔ),為組織從紛雜的工具集和實(shí)踐集中選擇最合適的集合,可以讓組織少走彎路.

DevOps 評(píng)價(jià)問題.

? 如何評(píng)價(jià)DevOps 工具的效果?根據(jù)我們的不完全統(tǒng)計(jì)[20],目前有超過百種支持DevOps 的工具,建立工具評(píng)價(jià)的統(tǒng)一標(biāo)準(zhǔn)可以為工具選擇提供支持.

? 如何評(píng)價(jià)DevOps 實(shí)踐的效果?相比于評(píng)價(jià)工具,對(duì)DevOps 實(shí)踐的評(píng)價(jià)難得多,但卻是必要的.

? 如何量化評(píng)價(jià)和界定DevOps 團(tuán)隊(duì)?IT 性能是否已經(jīng)足夠?目前,無(wú)論是產(chǎn)業(yè)界還是學(xué)術(shù)界,對(duì)于DevOps都還沒有明晰的界定,對(duì)于DevOps 化的程度也還沒有類似CMMI 的科學(xué)的、公認(rèn)的評(píng)價(jià)模型.借鑒Puppet Labs的工作,本研究采用IT 性能來(lái)量化度量組織的能力,這些是與DevOps 最相關(guān)的性能,但其與組織的DevOps 程度沒有直接的量化的因果關(guān)系,且其不可直接用于對(duì)軟件過程的評(píng)價(jià).

? 如何量化定位團(tuán)隊(duì)DevOps 的成熟度?如果能夠量化地評(píng)價(jià)組織的DevOps 化程度,下一步可以對(duì)組織的成熟度進(jìn)行科學(xué)的分級(jí),這應(yīng)該是基于證據(jù)和最佳實(shí)踐的,而不是單純地基于一些數(shù)值.

6 有效性威脅

本研究采用了問卷調(diào)查的經(jīng)驗(yàn)研究方法,結(jié)合2016 年和2018 年兩次問卷調(diào)查結(jié)果分析DevOps 在中國(guó)的發(fā)展現(xiàn)狀與趨勢(shì).本節(jié)將從反饋數(shù)量、數(shù)據(jù)質(zhì)量和統(tǒng)計(jì)分析3 個(gè)方面分析有效性威脅以及我們采取的削弱威脅的措施.

反饋數(shù)量.為了盡可能地收集到更多的反饋,我們兩次問卷都是采用在線問卷的形式,問卷通過技術(shù)社區(qū)、產(chǎn)業(yè)界及學(xué)術(shù)界會(huì)議等渠道分發(fā),例如在會(huì)議上展出含問卷二維碼的海報(bào),所以實(shí)際分發(fā)了多少問卷是無(wú)法統(tǒng)計(jì)的,這導(dǎo)致了度量問卷調(diào)查效度的重要指標(biāo)——反饋率的值是未知的.為了提高反饋數(shù)量,我們還將報(bào)告結(jié)果作為激勵(lì)吸引更多人參與,目前已經(jīng)有DevOps 經(jīng)驗(yàn)的從業(yè)人員,往往收入水平較高,獎(jiǎng)品和金錢對(duì)于他們?nèi)狈ξ?在DevOps 剛剛興起時(shí)即有經(jīng)驗(yàn)的從業(yè)人員往往對(duì)于技術(shù)有較高的求知欲,一份能夠讓他們了解到自己和其他從業(yè)者所處的水平以及遇到的瓶頸的調(diào)查報(bào)告,將更具吸引力,所以我們沒有采用獎(jiǎng)品或金錢的激勵(lì)方式.

數(shù)據(jù)質(zhì)量.為了確保反饋數(shù)據(jù)的質(zhì)量,我們采取了一系列措施.首先,在卷首注明了回答問卷需要的時(shí)間,使受訪者有心理準(zhǔn)備.此外,我們還在卷首聲明“問卷是匿名的,調(diào)查結(jié)果只用于統(tǒng)計(jì)、分析和生成最終的報(bào)告,我們將確保不會(huì)泄漏每一位受訪者的相關(guān)信息”,在問卷設(shè)計(jì)上也避免了問及姓名、公司名等私密信息,以此減少受訪者的顧慮.在問卷問題的設(shè)計(jì)上,我們主要采用的是封閉式問題,且提供“其他”“不知道”或“以上都沒有”等選項(xiàng),避免受訪者在不理解的情況下胡亂填寫.我們的問卷分發(fā)渠道面向?qū)I(yè)人士,激勵(lì)方式與調(diào)查本身相關(guān),這也為數(shù)據(jù)質(zhì)量提供了一定保障.從結(jié)果來(lái)看,確實(shí)沒有收到無(wú)效反饋.

統(tǒng)計(jì)分析.雖然我們采取了多項(xiàng)提高反饋數(shù)量的策略,然而,2016 年和2018 年的反饋數(shù)量分別僅為74 和66,這使得結(jié)果在統(tǒng)計(jì)上顯著性不足,所以在分析上我們盡可能地比較兩年的結(jié)果,以此減少統(tǒng)計(jì)結(jié)果對(duì)于樣本差異的敏感性,從最終的分析結(jié)果來(lái)看,例如質(zhì)量保證實(shí)踐等,雖然在占比量上兩年存在差異,但在實(shí)踐占比的排序上,兩年差異較小,支撐了結(jié)果的統(tǒng)計(jì)意義.在問題選項(xiàng)的設(shè)置上,我們盡可能地細(xì)粒度,例如對(duì)于“團(tuán)隊(duì)平均多長(zhǎng)時(shí)間部署一次代碼?”,我們從“<15 分鐘”到“>6 個(gè)月”共設(shè)置了9 個(gè)選項(xiàng),但在統(tǒng)計(jì)分析上,我們基于數(shù)據(jù)的分布,對(duì)選項(xiàng)進(jìn)行了合并,通過小于/大于1 周作為準(zhǔn)低性能和準(zhǔn)高性能團(tuán)隊(duì)的分水嶺,由于受訪企業(yè)的能力在調(diào)查前是未知的,設(shè)置細(xì)粒度的選項(xiàng)可以減少用于分析的數(shù)據(jù)在分布上受問卷設(shè)計(jì)者的主觀偏見,在具體分析時(shí)合并選項(xiàng)可以確保各個(gè)類別的數(shù)量,使我們分析時(shí)具備統(tǒng)計(jì)意義.

7 結(jié)束語(yǔ)

本研究基于兩次中國(guó)DevOps 現(xiàn)狀調(diào)查,結(jié)果顯示,DevOps 經(jīng)驗(yàn)豐富的團(tuán)隊(duì)在IT 性能表現(xiàn)上明顯更佳,高低性能的團(tuán)隊(duì)在IT 性能上會(huì)存在數(shù)十倍的差距.這反映出DevOps 在支持和提升中國(guó)軟件行業(yè)效率和質(zhì)量上有著明顯效果,為DevOps 運(yùn)動(dòng)在中國(guó)的進(jìn)一步推廣提供了充足的極具參考價(jià)值的證據(jù).從另一角度來(lái)看,調(diào)查報(bào)告反映的內(nèi)容能夠幫助學(xué)術(shù)/科研領(lǐng)域真實(shí)、全面地了解DevOps 在國(guó)內(nèi)軟件產(chǎn)業(yè)的發(fā)展的整體狀態(tài),進(jìn)一步發(fā)現(xiàn)和解決這其中有實(shí)踐意義和價(jià)值的問題,使軟件工程研究落地服務(wù)于軟件產(chǎn)業(yè)的最新發(fā)展.

具體而言,我們從受訪團(tuán)隊(duì)的IT 性能表現(xiàn)、組織文化及相關(guān)實(shí)踐、開發(fā)與運(yùn)維實(shí)踐、工具支持、領(lǐng)導(dǎo)力、工作比例、員工敬業(yè)度及滿意度、障礙這8 個(gè)方面,對(duì)DevOps 在中國(guó)近兩年的現(xiàn)狀與發(fā)展進(jìn)行了分析,并將部分結(jié)果與Puppet Labs 發(fā)布的全球DevOps 現(xiàn)狀報(bào)告進(jìn)行了對(duì)比.目前,國(guó)內(nèi)團(tuán)隊(duì)的IT 性能表現(xiàn)在交付周期上還存在明顯不足,從趨勢(shì)上看,隨著DevOps 經(jīng)驗(yàn)的提高,IT 性能表現(xiàn)也會(huì)隨之提高.IT 性能表現(xiàn)高的團(tuán)隊(duì),在文化、自動(dòng)化等實(shí)踐上明顯優(yōu)于較低性能的團(tuán)隊(duì).這體現(xiàn)了IT 性能、實(shí)踐、經(jīng)驗(yàn)三者之間相輔相成、循序漸進(jìn)的過程.值得警惕的一點(diǎn)是,當(dāng)前國(guó)內(nèi)組織在轉(zhuǎn)型DevOps 上正面臨著國(guó)際上5 年前識(shí)別出來(lái)的障礙,且在人才資源上面臨著更嚴(yán)峻的挑戰(zhàn).相應(yīng)地,國(guó)內(nèi)組織在DevOps 上的投入和力度雖然平均已到達(dá)國(guó)際上5 年前的水準(zhǔn),卻存在明顯的兩極分化現(xiàn)象,整體上發(fā)展不夠良性,這將制約DevOps 在中國(guó)的進(jìn)一步發(fā)展和推廣.此外,國(guó)內(nèi)DevOps 實(shí)踐更佳的團(tuán)隊(duì),其成員反而更覺得部署是一件痛苦的事,這反映了國(guó)內(nèi)一部分高標(biāo)準(zhǔn)的企業(yè)正處于DevOps 轉(zhuǎn)型的陣痛期,而另一部分企業(yè)發(fā)展較緩.本文結(jié)合兩年的問卷調(diào)查研究和Puppet Labs 的調(diào)查報(bào)告,分析獲得了17 條發(fā)現(xiàn),綜合分析這些發(fā)現(xiàn),我們?cè)趯?shí)踐和研究?jī)煞矫娣謩e給出了建議.本研究最大的局限在于,雖然竭力推廣,但收到的問卷反饋數(shù)量相對(duì)有限,這也從側(cè)面反映了國(guó)內(nèi)企業(yè)或個(gè)人對(duì)于DevOps 的態(tài)度還不足夠積極.此外,參與到調(diào)查中的受訪者更多的是對(duì)DevOps 有著濃厚興趣的從業(yè)人員,從他們的反饋數(shù)據(jù)分析出來(lái)的結(jié)果,雖已然體現(xiàn)出了中國(guó)DevOps 發(fā)展的滯后,但真實(shí)情況,可能更不容樂觀.