黃 璜,張 賀,2,邵 棟,2

1(南京大學(xué) 軟件學(xué)院,江蘇 南京 210093)

2(計算機軟件新技術(shù)國家重點實驗室(南京大學(xué)),江蘇 南京 210023)

1 研究背景

社會經(jīng)濟的不斷發(fā)展使得用戶需求的多樣性以及市場競爭的激烈性不斷增強,如何快速完成軟件的開發(fā)運營從而縮短實現(xiàn)軟件的商業(yè)價值的時間成為所有軟件企業(yè)組織在應(yīng)對軟件行業(yè)發(fā)展的挑戰(zhàn)時所需要考慮的重要問題.為了應(yīng)對這個問題,從21 世紀初開始,敏捷原則和精益方法在軟件開發(fā)實踐中不斷得到普及,Scrum和極限編程(extreme programming,簡稱XP)是其中最典型的兩種方法.而隨著敏捷原則在開發(fā)中的迅速應(yīng)用,面向經(jīng)驗性的傳統(tǒng)運維與它的矛盾逐漸加深,如何解決這一矛盾成為了一個新的研究話題.John 和Paul 在“10+Deploys Per Day:Dev and Ops Cooperation at Flickr”的演講中總結(jié)了Dev 和Ops 的不同觀點和思維方式,提出以自動化基礎(chǔ)設(shè)施與共享版本控制為核心的解決方案,并闡述了以信任與尊重為核心的早期DevOps 文化[1].

然而,DevOps 發(fā)展了近10 年,至今仍缺乏對其清晰和統(tǒng)一的認知.Andrej 等人認為,DevOps 是一種組織方法,強調(diào)在軟件開發(fā)組織中的團隊,特別是開發(fā)與運維團隊內(nèi)部或者之間的情感共鳴和跨職能協(xié)作,以此來達到快速交付和響應(yīng)變化[2].Matej 等人認為,DevOps 包含了一系列能夠縮短軟件設(shè)計變化的、可控的、可操作的軟件工程策略[3].Ramtin 等人也對學(xué)術(shù)界和業(yè)界出現(xiàn)的DevOps 相關(guān)的概念進行了研究[4,5].因為沒有官方定義,所以每個人都可以根據(jù)自己的想法賦予DevOps 一個定義,也就不斷地為DevOps 增加了新概念、新實踐和新工具.

從發(fā)展程度上看,Puppet Labs 在“2017 年DevOps 報告”[6]中指出,高性能的DevOps 團隊在代碼生成量與穩(wěn)定性方面優(yōu)于其他團隊.由于社會環(huán)境對人有巨大的影響[7,8],DevOps 實踐在中國環(huán)境下會與國際范圍內(nèi)有一定的差異,南京大學(xué)在2018 中國DevOps 年度報告[9]中提出了準高性能團隊的概念,認為中國在DevOps 團隊建設(shè)方面,大部分的團隊還達不到Puppet Labs 所定義的高性能團隊的標準,而且國內(nèi)的準高性能團隊主要進行的是主干開發(fā)、版本控制、測試方面的實踐,更多的是使用工具幫助構(gòu)建開發(fā)環(huán)境、實現(xiàn)自動化部署和監(jiān)控軟件系統(tǒng)的健康狀況,對于計劃、持續(xù)集成和持續(xù)反饋階段的工具關(guān)注較少.

DevOps 是對傳統(tǒng)軟件開發(fā)實踐的一場變革,其中,自動化處于關(guān)鍵位置.因為短周期的高質(zhì)量交付需要高度的自動化,而且快速獲取反饋的關(guān)鍵也是自動化;工具是實現(xiàn)自動化的基礎(chǔ),在DevOps 知識體系的5 個層面中(如圖1 所示),工具處于最底層,是DevOps 的基石[10-12],所以,對于DevOps 實踐中的自動化支持工具的研究也在不斷地增多.而對于DevOps 自動化支持工具的分類已經(jīng)有了很多成熟的模型,Xebialabs 公司提供了DevOps工具周期表,StackOverdrive 公司則提供了DevOps 工具全景圖.在學(xué)術(shù)界中,Vaasanthi 等人提出了基于數(shù)據(jù)挖掘技術(shù)的對DevOps 工具進行分類的新方法[13],Kersten 則對DevOps 自動化支持工具的爆炸性增長問題提出了自己的見解[14],Farcic 則對DevOps 工具集中的持續(xù)集成與持續(xù)部署部分保持了關(guān)注[15,16].

Fig.1 Knowledge system of DevOps圖1 DevOps 知識體系

隨著DevOps 的不斷發(fā)展,DevOps 觀念不斷獲得認同,支持DevOps 的自動化工具不斷增多.雖然DevOps不僅僅只會停留在工具層面,但是工具之于整個 DevOps 是不可或缺甚至具有決定性作用的一部分.研究DevOps 中的自動化工具,也會進一步推動DevOps 的全面發(fā)展.

本文第1 節(jié)介紹研究背景,闡述DevOps 文化以及DevOps 在中國的發(fā)展和DevOps 與自動化支持工具的關(guān)系.第2 節(jié)介紹研究方法,闡明3 個研究問題以及針對這3 個研究問題使用的不同的研究方法和研究過程.第3 節(jié)對獲取到的數(shù)據(jù)進行定性分析,通過系統(tǒng)化文獻評價獲得學(xué)術(shù)界最關(guān)注的一些DevOps 自動化支持工具,通過灰色文獻評價獲得這些自動化支持工具在實踐中存在的3 個層次的問題,最后通過訪談得出企業(yè)進行DevOps 轉(zhuǎn)型的一個范例以及對DevOps 自動化工具的一些建議.第4 節(jié)對研究的成果和不足進行討論.第5 節(jié)對研究進行總結(jié)和回顧.

2 研究方法

2.1 研究問題

DevOps 倡導(dǎo)的理念需要自動化給予支持,尤其是在開發(fā)和運維方面.認識DevOps 自動化支持工具的現(xiàn)狀,理解現(xiàn)有自動化工具在中國環(huán)境下DevOps 實踐中的問題,能夠更好地促進DevOps 在中國的發(fā)展,本文提出以下研究問題.

研究問題1:目前DevOps 實踐中有哪些自動化工具?

該問題旨在收集目前DevOps 實踐中的自動化工具,形成一個工具集合,并為后續(xù)研究提供參考.為了回答這個問題,本文從學(xué)術(shù)文獻中收集證據(jù),從學(xué)術(shù)文獻中搜索、篩選并統(tǒng)計DevOps 實踐中的自動化工具.

研究問題2:目前的自動化工具在中國的DevOps 實踐中存在哪些問題?

該問題旨在找出中國的DevOps 實踐中自動化工具存在的問題.為了回答這個問題,本文在學(xué)術(shù)文獻證據(jù)的基礎(chǔ)上,從部分中文博客論壇中收集灰色文獻,進而從這些證據(jù)中抽取數(shù)據(jù)進行定性分析.

研究問題3:自動化工具在中國的DevOps 實踐中存在的問題有哪些解決辦法?

該問題旨在給研究問題2 中的問題提出解決方案.為了回答這個問題,本文邀請國內(nèi)部分DevOps 研究者、DevOps 企業(yè)從業(yè)人員和DevOps 咨詢師進行訪談,對訪談內(nèi)容抽取數(shù)據(jù)后進行定性分析.

2.2 研究方法

DevOps 文化誕生于技術(shù)社區(qū),隨即廣泛地應(yīng)用到軟件企業(yè)組織中,近些年來,學(xué)術(shù)界對它的關(guān)注也逐漸增強,但是,相關(guān)的研究并不豐富,所以,我們除了需要學(xué)術(shù)文獻,還需要使用博客等材料輔助分析.本文提出的各研究方法間的關(guān)系如圖2 所示,首先,采用系統(tǒng)化文獻評價(systematic literature review,簡稱SLR)對目前學(xué)術(shù)界和工業(yè)界都認可的DevOps 實踐中的自動化工具加以集合,然后,通過灰色文獻評價(gray literature review,簡稱GLR)對上述工具集合進行問題的總結(jié),歸納出多個自動化工具在DevOps 實踐中存在的問題,最后針對這些問題,采取訪談的形式從企業(yè)人員、咨詢師、研究者這3 個角度獲取評價,從而得出對每個問題的建議.

2.2.1 系統(tǒng)化文獻評價

自2004 年Kitchenham 等人首次將系統(tǒng)化文獻評價(SLR)引入軟件工程以來[17],SLR 已成為軟件工程中一種重要的研究方法[18],在《DevOps 自動化支持工具調(diào)研》[19]中,李杉杉等人對DevOps 實踐中的自動化支持工具做出了系統(tǒng)化文獻評價,對DevOps 自動化支持工具的相關(guān)文獻進行了檢索,本文按照報告中的字符串((DevOps)in title or keyword or abstract AND (tool*)in full-text)進行了初步的檢索,有168 篇文獻被確定為相關(guān)文獻,其中包括IEEE Xplore 的71 篇,ACM Digital Library 的53 篇,SpringerLink 的19 篇以及ScienceDirect 的25 篇.由于本文更多關(guān)注自動化工具在DevOps 實踐中的影響,只需要獲取學(xué)術(shù)界常見的工具集合,因此,我們對于文獻的選擇做出了更加嚴格的限制,在標題、摘要和關(guān)鍵字中出現(xiàn)DevOps 和Tool 相關(guān)詞匯的文獻被篩選出來進行數(shù)據(jù)抽取.最終,本文得到了50 篇DevOps 自動化支持工具的相關(guān)文獻,對這50 篇文獻中提到的工具進行抽取,得到一個DevOps 自動化支持工具的集合.

Fig.2 Research method圖2 本文研究方法

2.2.2 灰色文獻評價

灰色文獻是由傳統(tǒng)商業(yè)或?qū)W術(shù)出版和分銷渠道以外的組織制作的材料和研究.通常情況下,學(xué)術(shù)文獻中的信息會落后于灰色文獻[20],DevOps 文化起源于技術(shù)社區(qū),發(fā)展于軟件開發(fā)組織,學(xué)術(shù)界在對DevOps 的理解上相對來說落后于社區(qū)和軟件組織,而且研究者使用工具的頻率遠低于工業(yè)界,在使用中遇到的問題或困擾必然少于工業(yè)界,因此,針對DevOps 實踐中自動化存在的問題,單純地從學(xué)術(shù)文獻中獲取是不夠客觀和完整的.本文從文獻中識別了69 個自動化工具,而XebiaLabs 公司根據(jù)工具類型的不同,把120 種DevOps 工具分成了15 個大類,由此可見,灰色文獻對研究文獻具有極大的補充作用.

因此,針對研究問題2,本文采用灰色文獻評價的方法,在選取灰色文獻來源時,我們對比了簡書、知乎和Gitbook 這3 個數(shù)據(jù)源.其中,Gitbook 中的數(shù)據(jù)均為書籍章節(jié),不能夠體現(xiàn)DevOps 實踐在中國環(huán)境下產(chǎn)生的問題;知乎作為一個網(wǎng)絡(luò)問答社區(qū),存在各種問題與解決問題的方法,但經(jīng)過檢索我們發(fā)現(xiàn),知乎中問題和回答的數(shù)量級較小,選其作數(shù)據(jù)源可能會造成較大的偏差;簡書作為一個原創(chuàng)社區(qū),其作者涵蓋了研究者、咨詢師和企業(yè)從業(yè)人員這3 類與DevOps 實踐中自動化工具密切相關(guān)的人群,簡書上超過50 萬個專題中有像Docker 等專門收錄相關(guān)工具文章的專題,并且每個專題都有比知乎更多的文獻.我們通過簡書獲取博客,在保證博客的原創(chuàng)性與質(zhì)量的同時,能夠更好地獲取DevOps 在中國實踐中產(chǎn)生的問題,對結(jié)果的準確性有著更好的支持.本文對于DevOps 實踐的幾個環(huán)節(jié):容器、持續(xù)集成、版本管理、編譯、配置管理,從簡書中選擇其中最熱門的專題對其中的博客進行爬取.一共爬取到1 942 篇博客.由于簡書中的博客沒有標簽選項,而且對于關(guān)鍵詞的搜索策略為包含其中一個關(guān)鍵詞即列入結(jié)果列表,因此,本文檢索了關(guān)鍵詞“DevoOps”和“工具”,并對搜索結(jié)果以相關(guān)性排序的前50 篇博客進行分析,對博客中提出的問題進行歸納,結(jié)合第1 次Web 挖掘時產(chǎn)生的統(tǒng)計數(shù)據(jù)整理問題,形成DevOps 文化中自動化工具所存在的問題列表.

2.2.3 民族志:訪談

民族志是用來揭示在某種文化中支撐社會行為的過程和意義的方法[21-24].在民族志方法中,訪談是獲取數(shù)據(jù)的重要手段[25-28].相較研究文獻和灰色文獻而言,訪談可以通過引導(dǎo)訪談對象進行深度交談來獲取更為可靠、有效并且接近實際的信息[29],對于DevOps 自動化支持工具在使用中的問題,通過訪談的形式可以更為準確地了解它們在實際情境下的真實情況,此時獲取的有關(guān)這些問題的建議或者解決方案,往往在真實情況下能夠更加容易地實現(xiàn).本文的訪談對象都是對DevOps 有一定了解的專家,在了解他們對DevOps 中事物的看法時,結(jié)構(gòu)的或半結(jié)構(gòu)的訪談是最有價值的.而半結(jié)構(gòu)的訪談比結(jié)構(gòu)的訪談能夠獲取更多被訪談人員自己的想法,從而可以形成更加客觀的結(jié)論,因此,本文選取半結(jié)構(gòu)的訪談作為訪談方法.

三角測量是民族志研究的基礎(chǔ),是民族志研究正確性的關(guān)鍵所在,可以提高資料質(zhì)量和成果的精確度[25],因此,本文在選取被采訪人員時,從DevOps 研究者、DevOps 企業(yè)從業(yè)人員和DevOps 咨詢師這3 個維度進行,從而保證最終結(jié)論的準確性.其中,DevOps 研究者來自高校,有多年的DevOps 研究經(jīng)驗;DevOps 咨詢師來自軟件咨詢公司,長期從事DevOps 方面的軟件咨詢工作;DevOps 從業(yè)人員為各公司的架構(gòu)師,對于公司開發(fā)運維的方式有一定的認識,并且也參與過一些DevOps 項目的開發(fā).

最終,本文邀請到7 位相關(guān)的專家參與訪談,名單見表1.

Table 1 List of interviewed experts表1 接受訪談的專家

針對3 個維度的被訪談人員,訪談時需要采用不同的訪談問題,由于希望獲得更多的信息,因此,問題中需要包含更多普泛的問題,但是對某些具體的情形,則需要專門的問題.另外,封閉式的問題在嘗試量化行為模式時是比較有用的,而開放式的問題允許參與者本人來解析它,從而可以獲得更多信息,有助于闡釋不同人員自己的世界觀,因此,本文對被訪人員采用開放式的問題來進行訪談.

Table 2 Outline of interview questions表2 訪談問題大綱

自動化支持工具作為研究的對象在訪談問題中并不需要提及太多,這樣可以獲得更多的被訪人員在無意識下對自動化支持工具的看法,從而提升結(jié)論的客觀性.訪談中的問題不拘泥于表2 所列內(nèi)容,因為不同的公司所處的行業(yè)不同、環(huán)境不同,不同的咨詢師所服務(wù)的公司也各有不同,所以,對于每一位被訪人員,都需要在了解背景以后,根據(jù)具體的訪談情境做出針對性的修改,具體的修改內(nèi)容在結(jié)果分析中會列出.DevOps 咨詢師分布在全國各地,由于地域和時間的限制,我們對于這部分專家(E3、E4 和E5)采取線上訪談的模式.線上訪談是線上民族志的主要部分,是這個領(lǐng)域開創(chuàng)性作品采用的方法之一.雖然Bruckman 認為“線上訪談價值有限”,但是他評價的是基于文字的線上訪談,本文采取電話訪談作為線上訪談的形式,能夠獲取更多的細節(jié),而這種方法在Robert V.Kozinets 看來也是可取和可信的[30,31].

2.2.4 數(shù)據(jù)整合和分析

為了回答研究問題,我們采用了定量和定性的數(shù)據(jù)分析方法.對于研究問題1,采用統(tǒng)計性的描述去整合我們的數(shù)據(jù),為了方便理解,使用圖表來展示我們的數(shù)據(jù).扎根理論[32]被用于對研究問題2 的回答,這樣的應(yīng)用能夠逐步發(fā)現(xiàn)工具在DevOps 實踐中產(chǎn)生的問題,并能據(jù)此建立一個問題的集合.而在回答研究問題3 時,我們結(jié)合了主題分析[33]和民族志方法中常見的摘要敘述[25]方式,包含了一些逐字引用,以說明專家對某幾個問題的真實看法.

3 結(jié)果分析

3.1 針對研究問題1

圖3 所示的柱狀圖展示了初步檢索后的168 篇文獻(2011 年～2018 年)的分布情況,由圖3 可以看出,有關(guān)DevOps 工具相關(guān)的論文從2014 年開始激增,在2014 年～2017 年間,每年增長的幅度保持了一個較高水平,而在2018 年有一個急劇下降,這是因為,本研究的文獻檢索工作是在2018 年第1 季度展開的.

Fig.3 Study distribution of DevOps tools圖3 DevOps 工具相關(guān)文獻分布

由此可見,研究者對DevOps 自動化工具相關(guān)研究的興趣是逐年遞增的.鑒于研究者對DevOps 的相關(guān)研究的興趣也是越來越強,本文又以DevOps 為關(guān)鍵詞對4 個電子文獻庫進行了一次檢索,記錄下每一年相關(guān)研究的數(shù)量,并計算每年與DevOps 工具相關(guān)的文獻所占比例,從圖3 所示的折線圖我們可以看出,從2014 年開始,與自動化工具相關(guān)的研究在DevOps 相關(guān)研究中所占的比例穩(wěn)定在35%～40%.這顯示了在DevOps 持續(xù)發(fā)展的階段,研究者始終保持了對自動化工具的熱情,同時這也彰顯了自動化工具作為DevOps 文化的基石的重要性.

針對DevOps 實踐中常用的自動化工具,本文對篩選出的50 篇文獻進行了數(shù)據(jù)抽取,共識別出69 個自動化工具,其中提及率超過10%的工具排名如下文的圖4 所示.從圖中可以看出,Docker、Chef、Jenkins 是DevOps自動化支持工具中最常見、最為研究者所青睞的3 個工具,尤其是Docker 和Chef,幾乎每兩篇文獻就有一篇會提及它們.

3.2 針對研究問題2

對于爬取到的博客文章,本文首先對發(fā)表的時間進行了一些分析,從圖5 中我們可以看出,有關(guān)DevOps 實踐的5 個關(guān)鍵過程——容器、持續(xù)集成、版本管理、編譯和配置管理中有關(guān)工具的博客數(shù)量從2013 年至今總體上呈現(xiàn)上升的趨勢,并在2017 年達到了頂峰,而從2017 年第4 季度開始有小幅回落,出現(xiàn)這個狀況的原因可能是DevOps 經(jīng)過多年發(fā)展,在2017 年已經(jīng)接近成熟,尤其是在工具使用方面,面臨的問題已經(jīng)趨于穩(wěn)定.

Fig.4 Frequency of automation tools in support of DevOps in studies圖4 DevOps 自動化支持工具文獻提及頻率

Fig.5 Time distribution of blogs in 5 topics on DevOps in Jianshu圖5 簡書DevOps 5 個專題中博客數(shù)量的時間分布

對于自動化工具在DevOps 實踐中存在的問題,根據(jù)對簡書博客的分析,可以將其分為多樣性、聯(lián)系、文化這3 個不同維度的問題.

3.2.1 DevOps 實踐中自動化工具的多樣性問題

在研究問題1 中,本文根據(jù)文獻識別出了69 個DevOps 自動化支持工具,而在第2 節(jié)也提到了XebiaLabs公司根據(jù)120 個DevOps 自動化支持工具制作的DevOps 工具周期表,由此可見,DevOps 自動化工具數(shù)量龐大.而從第2 次Web 挖掘的博客中,本文共識別出162 個DevOps 自動化支持工具,包括配置管理、構(gòu)建、測試、集成、部署等不同類型.眾多的工具帶來了選擇上的問題,在簡書的博客中,每一篇博客都選取了至少一個不相同的工具來搭建自己的工具鏈,同一篇博客也會在某個階段推薦兩個不一樣的工具,比如OneAPM 就比較了DevOps 配置管理階段的兩個工具Fabric 和Ansible 在使用時給用戶帶來的不同的體驗.

數(shù)量眾多的自動化支持工具不僅帶來了選擇的問題,有時也會帶來對工具的理解問題,在工具日益增多的情況下,對于DevOps 的后來者需要學(xué)習(xí)和理解的DevOps 知識的廣度和深度也越來越大.同樣,對于一個工具來說,功能也是隨著時間而增多的,Nagios 的官網(wǎng)顯示,它的各種插件已經(jīng)達到了4 347 種.從表3 我們可以看到,大部分的DevOps 自動化支持工具都有很多的插件,而復(fù)雜的工具會在工作時帶來更多復(fù)雜的情況,也會帶來更多的問題.另一方面,隨著自動化工具功能的完善,更多的軟件組織會采用更加復(fù)雜的方式進行開發(fā),例如,Docker 的興起鼓勵許多組織進行基于微服務(wù)架構(gòu)的開發(fā),這也增加了DevOps 自動化的復(fù)雜性.

Table 3 The number of languages and plug-ins used by some automation tools in support of DevOps表3 部分DevOps 自動化支持工具使用的語言和插件數(shù)量

3.2.2 DevOps 實踐中自動化工具間的聯(lián)系問題

DevOps 眾多的自動化工具讓人在選擇上產(chǎn)生困惑,但是更重要的一個問題是各個階段的工具之間的聯(lián)系問題.在第1 節(jié)中提到,相比國外DevOps 實踐的發(fā)展,中國DevOps 文化更加關(guān)注于工具的使用,因此,打造一個易用的DevOps 工具鏈是每一個軟件組織都希望完成的事情.但是,現(xiàn)階段多數(shù)DevOps 工具鏈其實都不夠完善,目前大部分可用的DevOps 工具都是基于碎片點的孤立解決方案,只能在DevOps 工作流的特定階段完成特定任務(wù).以華為軟件開發(fā)云為例,它的自定義流水線是解決不同階段工具聯(lián)系的一種方法,但是與其他工具鏈一樣,它重點關(guān)注于Dev 階段,對于Ops,雖有布局,但是關(guān)注并不像Dev 那樣多,這也導(dǎo)致在Dev 和Ops 銜接的時候會出現(xiàn)聯(lián)系不密切的問題.此外,對于大部分的軟件組織來說,如何將傳統(tǒng)工具和新應(yīng)用聯(lián)系起來,會是另一個棘手的問題.

3.2.3 DevOps 實踐中有關(guān)自動化工具的文化問題

無論是DevOps 自動化支持工具的數(shù)量問題,還是各個階段工具間的聯(lián)系問題,歸根結(jié)底它是DevOps 的文化問題.沒有合適的文化和適應(yīng)這種文化的人,即使擁有再好的工具,也不會成功地實施DevOps 實踐.這一點在中國尤為重要,簡書中幾乎每一篇有關(guān)DevOps 工具使用問題的博客都會或多或少地提及其中的文化問題,他們認為單純地使用工具沒有辦法打破團隊間的壁壘,因為每一個團隊都希望使用最符合自己需求的工具鏈,甚至在同一個團隊中,每個技術(shù)人員都有自己偏好使用的工具,而很多時候他們(技術(shù)人員)都自視甚高.

敏捷宣言中提到,最好的架構(gòu)、需求和設(shè)計出自自組織團隊,Hackman 給我們提供了一個可以區(qū)分團隊自組織4 個層次的權(quán)力矩陣[34](如后文的圖6 所示).在中國的環(huán)境下,軟件組織中的團隊大多是管理者領(lǐng)導(dǎo)型團隊和自管理型團隊.而在軟件組織中,為了保證各個部門間的協(xié)作,必須使用兼容工具,不匹配的工具集會產(chǎn)生瓶頸、誤解和誤導(dǎo),進而導(dǎo)致大量的時間被浪費,而在多個部門需要使用一個DevOps 工具鏈時,如果存在工具選用上的分歧,在中國的文化環(huán)境下,從權(quán)力矩陣中我們可以發(fā)現(xiàn),在環(huán)境這一部分的選擇大多由管理者或者企業(yè)組織的領(lǐng)導(dǎo)者決定,而這樣的決定形式很大程度上會導(dǎo)致團隊間的信任危機,從而影響業(yè)務(wù)效率,進一步地,這也違背了我們在第1 節(jié)中提到的以信任和尊重為核心的DevOps 文化的精神.這一點尤其表現(xiàn)在開發(fā)人員與運維人員可能產(chǎn)生的沖突上,開發(fā)人員關(guān)注的重點是新的功能的實現(xiàn),而運維人員關(guān)注的重點是已有功能的成功運行,不同的關(guān)注重點在工具鏈中想要獲得的內(nèi)容是不同的,想要工具鏈實現(xiàn)的細節(jié)也會是不同的,在開發(fā)人員強勢、運維人員弱勢的情況下,軟件組織必然會選用開發(fā)人員所偏好的工具,這時候,開發(fā)人員可能會因此擔(dān)負部分運維任務(wù),這會更加惡化開發(fā)、運維二者的關(guān)系,從而讓DevOps 名存實亡,變成一種通過自動化工具和手段構(gòu)建的標準流程.

3.3 針對研究問題3

在訪談中提及工具的多樣性時,專家們總是會談起工具的選擇、聯(lián)系等問題,相較于工具本身,專家們更關(guān)注工具在整個實踐中的地位、發(fā)揮的作用以及它所帶來的影響.專家E5 就表示,“每個工具有不同的功能,我們做的事情就是把工具串起來”.專家E4 并不關(guān)注DevOps 自動化支持工具的問題,他認為有了優(yōu)秀的工程師文化,自然而然地可以解決工具方面帶來的任何問題(如圖7 所示).

這一點是可以被理解的,在整個DevOps 實踐中,不存在完全獨立于其他自動化工具的工具,所以,對于訪談中的這一部分內(nèi)容我們也作了進一步的識別:我們認為,在單獨討論某一個工具時,如果專家對這個工具進行了延展,提及了與之有交互的其他工具,那么這一部分的訪談也會被認為是涉及了工具間的聯(lián)系問題;而在單獨討論某一工具時,如果專家也提及了文化問題,我們也認為這一部分的訪談可以作為專家對文化問題的回答.

在涉及DevOps 實踐中自動化工具的多樣性問題時,眾多的插件使得工具變得更加復(fù)雜這個問題在專家看來是不可避免的,因為“插件的產(chǎn)生肯定是為了滿足某一個需求”.面對這個問題,專家E7 認為,在選擇工具時需要固定一個版本,不要冒然地改動,當(dāng)遇到問題時再根據(jù)實際情況選擇合適的更新版本.

Fig.6 Power matrix圖6 權(quán)力矩陣

Fig.7 Part of interview with expert E4 on DevOps tools圖7 對專家E4 有關(guān)DevOps 工具的訪談片段

在面對如何選擇自動化工具的問題時,專家們表示,適合公司的、團隊成員更加熟悉的工具更應(yīng)該被使用.專家E1 就把選擇工具類比為選擇程序設(shè)計語言,認為在選擇工具的時候需要考慮到團隊的技術(shù)積累.若是某個環(huán)節(jié)上引入的工具對于團隊人員來說不是那么熟悉,那么專家給出的建議應(yīng)是從其中選擇開源的、參考資料多的以及被使用程度高的工具,在專家E2 看來,“在每個環(huán)節(jié)都有兩三款處于領(lǐng)先地位的工具,其他的工具其實差很多,而這些處于領(lǐng)先地位的工具的參考資料都是極大豐富的,比如說版本控制階段的Git”(如圖8 所示).

Fig.8 Part of interview with expert E2 on tools selection criteria圖8 對專家E2 關(guān)于工具選擇標準的訪談片段

專家們表示流水線是解決工具之間聯(lián)系問題的一個好的選擇.而在構(gòu)建流水線時,專家E4 表示要從持續(xù)集成開始,慢慢地擴展到持續(xù)交付,從而形成一個規(guī)范的自動化的流水線.對于流水線的應(yīng)用,專家E3 則表示應(yīng)該從平臺開始,技術(shù)先行,然后采用試點的方式,先對和企業(yè)核心資產(chǎn)關(guān)系不是太親密的部分進行改革,逐漸改善流水線,最后達到引入DevOps 的目的.專家們對于流水線的建議十分契合唯物辯證法中的兩點論與重點論,在構(gòu)建這樣一條DevOps 流水線時全面統(tǒng)籌企業(yè)的所有部門,厘清重要功能與在短時間內(nèi)可深入改革的部分,從持續(xù)集成這個重點開始進行DevOps 轉(zhuǎn)型,最終實現(xiàn)快速響應(yīng)交付.

在DevOps 實踐中運維與開發(fā)的聯(lián)系的問題是最重要的部分之一,大部分專家也表示這是一個很關(guān)鍵但卻是比較困難的問題.專家E7 認為,他們公司就沒有完全打通開發(fā)和運維之間的壁壘,需要在以后的實踐中對持續(xù)部署這部分做更多的工作;專家E4 則認為,目前開發(fā)和運維之間聯(lián)系不密切的原因是技術(shù)能力的不足,他相信,在基礎(chǔ)設(shè)施達到某一水平之后,二者之間的壁壘自然而然就會打通,而在達到這個水平之前,開發(fā)和運維的工具鏈仍然是封閉的.本文認為,二位專家的意見是一致的,專家E4 作為咨詢師,在企業(yè)DevOps 轉(zhuǎn)型中提供咨詢的服務(wù),但是在基礎(chǔ)設(shè)施不能夠達到要求時,也會束手無策;專家E7 作為DevOps 企業(yè)從業(yè)人員,則從實際的工作環(huán)境角度對基礎(chǔ)設(shè)施的問題做出了自己的回答,并希望可以在某些環(huán)節(jié)能夠有技術(shù)上的提升.

在談到傳統(tǒng)工具與新工具的聯(lián)系問題時,專家們的分歧較為明顯,專家E1 表示,“要盡可能地降低整個學(xué)習(xí)的成本,盡可能地遷就項目團隊成員原有的一些工具,然后需要去找新的工具,那么新的工具要與原有工具的匹配度盡可能地好一些”;而專家E2 則表示,應(yīng)該在軟件層面上對原有的工具進行全部替換,他指出,現(xiàn)有的企業(yè)大多數(shù)是這樣進行的.本文認為,這是二位DevOps 研究人員在思考這樣的問題時把自己代入的環(huán)境不同所造成的.專家E1 長期從事敏捷開發(fā)的研究,思考這類問題時更多考慮的是有著長期敏捷開發(fā)經(jīng)驗的組織,訪談中他也經(jīng)常提及敏捷在DevOps 中的作用與不同,敏捷團隊比起其他傳統(tǒng)的團隊對于DevOps 有更好的適應(yīng)性,DevOps 實踐中很多自動化工具我們也可以在敏捷開發(fā)中看到;而專家E2 長期從事的是軟件開發(fā)過程的研究,更多思考的是傳統(tǒng)的軟件開發(fā)流程,在短周期交付的情況下,很多傳統(tǒng)的工具已經(jīng)不能滿足需求的快速變更,與其花費時間匹配工具,不如直接更換全新的工具鏈.

在文化層面上,每一位專家都提到了組織結(jié)構(gòu)和制度問題,他們提到的康威法則(Conway’s low)認為,“一個組織最終產(chǎn)生的設(shè)計等同于組織之內(nèi)、之間的結(jié)構(gòu)”.而對于具體的企業(yè)文化,專家E1 表示要提升團隊的自組織性,對于環(huán)境工具的選擇要聽取更多團隊的意見,探索自組織型團隊在中國環(huán)境中的優(yōu)秀實踐;專家E2 提出要明確團隊目標,采用能夠?qū)崿F(xiàn)目標的工具與流程,獎懲應(yīng)該以實現(xiàn)多少目標為依據(jù),同時,程序員要增加自信心;專家E4 則表示,應(yīng)該更加相信程序員,對于工具問題要給予他們更多的選擇權(quán)力;專家E7 在同意給程序員更多選擇空間的同時也認為要通過更多的制度來保證擁有更多權(quán)力的程序員不會成為公司的隱患;專家E3 也對這方面做出了自己的總結(jié),“從組織結(jié)構(gòu)上打破部門墻,從工具的角度使信息透明,從而做到在工具上可以一次性做到協(xié)作,然后從流程上界定好開發(fā)與運維之間的責(zé)任關(guān)系,并且能力上要進行多元化的發(fā)展”(如圖9 所示).

Fig.9 Part of interview with expert E3 on the relationship between development and operation teams圖9 對專家E3 關(guān)于開發(fā)運維的關(guān)系的訪談片段

綜合整個訪談,我們對各個專家的意見進行了總結(jié),見表4.

Table 4 Recommendations for three dimensions of automation tools in support of DevOps表4 對DevOps 自動化支持工具3 個層次問題的建議

對這些建議,我們可以總結(jié)為3 點:(1)選擇適合組織的、團隊成員熟悉的自動化工具,在此基礎(chǔ)上選擇開源的、參考資料豐富、被廣泛認可的自動化工具,在適當(dāng)?shù)臅r候通過自己開發(fā)工具適配組織結(jié)構(gòu),自己開發(fā)插件滿足組織流程對自動化工具的要求.(2)各個階段選擇相互匹配的自動化工具,加強基礎(chǔ)設(shè)施的建設(shè)來加強工具間的聯(lián)系,并以此構(gòu)建一個標準化的自動化的流水線.(3)構(gòu)建符合DevOps 價值觀的企業(yè)文化,變革組織結(jié)構(gòu),制定和完善相應(yīng)的制度,鼓勵程序員,使之保持信心和熱情.

在形成建議的同時我們對訪談中專家對于3 個層次問題的關(guān)注程度,從在談及各個層次問題時的態(tài)度、語速、語氣以及內(nèi)容的多少,形成了表5.

Table 5 Level of concern with three dimensions of automated tools in support of DevOps表5 對DevOps 自動化支持工具3 個層次問題的關(guān)注程度

專家E4 在談到具體工具時語速加快,而且迅速從具體工具談到每個工具之間的聯(lián)系,再上升為文化,我們就可以認為,專家E4 對于DevOps 自動化支持工具的第1 層次問題的關(guān)注很少,甚至不關(guān)注,所以我們把他對多樣性問題的關(guān)注程度標注為1;專家E1 在談?wù)揇evOps 自動化支持工具的時候就專注于工具本身,語氣平緩,語速適中,并沒有表現(xiàn)出對每一種類型的工具有強烈的興趣,所以我們認為他對工具多樣性的關(guān)注程度為3;而專家E6 在訪談中大量地介紹他們公司所構(gòu)建的工具“布加迪”,語氣中充滿自豪與自信,并且堅持認為未來會繼續(xù)開發(fā)這一工具,則本文認為,他對于工具本身的關(guān)注是很多的,也很重視工具,所以我們認為,他對工具多樣性的關(guān)注度為5.

從表5 中我們可以看出,DevOps 的研究者和咨詢師對文化問題的關(guān)注明顯高于企業(yè)從業(yè)人員,這在一定程度上也顯示了兩種不同的思想,研究者和咨詢師更注重企業(yè)文化的培育,認為企業(yè)文化決定了更多的東西,而企業(yè)從業(yè)人員不會對文化給予過多關(guān)注,他們在乎的是工作是否快捷,一個工具或者一種實踐能否帶來效率的提升,這也符合企業(yè)的定位,任何企業(yè)都需要以市場為導(dǎo)向,而目前的環(huán)境中,能夠快速地進行開發(fā)和運維則是企業(yè)應(yīng)對市場變化的基礎(chǔ).訪談中,DevOps 的研究者也都提到了如今DevOps 的研究與工業(yè)界存在的差距,通過表3 我們也可以看到,這種差距是由于所處的不同的環(huán)境造成的,在某種程度上是不可避免的.研究者對DevOps 的研究想要更加深入,應(yīng)該要有更細致的規(guī)劃,進入企業(yè)內(nèi)部參與企業(yè)的每一次轉(zhuǎn)變.而企業(yè)也應(yīng)當(dāng)重視研究者所給出的意見,在追求快速、簡潔流程的同時,注重企業(yè)文化的培育.

根據(jù)各個專家在訪談中的建議、提出的看法以及企業(yè)中合適的做法,對于軟件組織引入DevOps,構(gòu)建合適的工具鏈,本文給出了如圖10 所示的自上而下的引入DevOps 的范例.軟件組織的高層受到DevOps 顧問的影響,學(xué)習(xí)DevOps 的理念,從而轉(zhuǎn)變自己的思想,使之適應(yīng)DevOps 的價值觀,然后從制度入手,把DevOps 團隊的權(quán)力與義務(wù)以制度化的形式確定下來,保證在后續(xù)過程中每個環(huán)節(jié)的責(zé)任都能夠找到承擔(dān)的人員或團隊,DevOps 顧問在制度的起草階段起到一個建議人的作用.在確定了新的制度以后,軟件組織高層應(yīng)該對DevOps 團隊充分地信任,DevOps 團隊?wèi)?yīng)該在DevOps 顧問的指導(dǎo)下,由原來的Dev 團隊和Ops 團隊消除部門墻之后合并而成,消除部門墻需要有清晰的組織目標,由DevOps 協(xié)調(diào)各個部門,向著這個目標協(xié)同努力,與此同時,改善工作環(huán)境,使每個部門能夠更加認同組織.在形成新的DevOps 團隊之后,無論是Dev 團隊成員還是Ops團隊成員,在使用新的流水線和學(xué)習(xí)使用新的工具時都需要保持自信.而整個DevOps 流水線由新合并而成的DevOps 團隊決定,原Dev 團隊和原Ops 團隊的成員都需要在這一過程中參與或者投票選出DevOps 團隊使用的工具,軟件組織高層在整個流水線制定中和完成后起到一個監(jiān)控的作用,使整個流水線符合軟件組織的利益.在制定流水線時應(yīng)該有先后順序,最重要的3 個部分是構(gòu)建、發(fā)布和部署,DevOps 團隊?wèi)?yīng)該從這3 個環(huán)節(jié)入手,一步步完善整個流水線.

Fig.10 DevOps paradigm for software organization圖10 軟件組織DevOps 轉(zhuǎn)型范例

4 討 論

自動化工具是軟件組織中必不可少的部分,DevOps 也會是未來軟件組織響應(yīng)快速變化的主要手段,在引入DevOps 的初級階段,自動化工具會是最重要的一個環(huán)節(jié),此時可以認為使用自動化工具即為DevOps,而隨著DevOps 的發(fā)展,當(dāng)工具不再成為阻礙時,軟件組織的結(jié)構(gòu)與文化就會超越工具,成為DevOps 發(fā)展的新的核心點.可以說,自動化工具是DevOps 發(fā)展的基石,DevOps 的發(fā)展也為自動化工具的發(fā)展提供新動力.

在訪談中專家們也對未來DevOps 的發(fā)展提出了自己的期望,DevOps 的研究者們認為,在技術(shù)層面上,產(chǎn)品的設(shè)計、開發(fā)和運維會越來越成為一個整體,且DevOps 會成為以后教學(xué)中的重點,越來越多的工具也會出現(xiàn),從而推動DevOps 的發(fā)展;DevOps 咨詢師們認為,更多的企業(yè)會加入DevOps 轉(zhuǎn)型,不同團隊之間的界限會越來越透明;DevOps 企業(yè)從業(yè)者則希望DevOps 有一個更細致的切入點,可讓企業(yè)更方便、更快捷地提高軟件的交付速度.

本文復(fù)現(xiàn)了李杉杉等人在《DevOps 自動化支持工具調(diào)研(技術(shù)報告)》中的輕量級的系統(tǒng)化文獻評價,篩選出50 篇與DevOps 自動化支持工具相關(guān)的文獻作為數(shù)據(jù)抽取的原始材料,但是,由于DevOps 是近10 年中才出現(xiàn)和發(fā)展的一個概念,很多DevOps 的支持工具也是持續(xù)交付所需要的工具,部分論文可能并不會使用DevOps 的概念,這對我們得出的在學(xué)術(shù)界關(guān)注的DevOps自動化支持工具的排名有一定的影響.我們需要對持續(xù)交付的相關(guān)文獻進行一次檢索,對于其中可能涉及DevOps 自動化支持工具的文獻,我們也應(yīng)該將其歸入數(shù)據(jù)抽取的材料中.

在灰色文獻評價部分,本文從簡書上進行了數(shù)據(jù)的摘取,在博客數(shù)量的統(tǒng)計上,本文選取簡書中最熱門的5個DevOps 自動化支持工具的專題對其中的博客進行了統(tǒng)計,這雖然有可能遺漏某些未收錄入專題中的博客,但在橫向?qū)Ρ戎?這一點帶來的誤差是可以忽略的,收集到的數(shù)據(jù)仍然可以反映技術(shù)論壇對于DevOps 自動化支持工具的關(guān)注程度.另外,本文試圖探討DevOps 實踐在中國的狀況,因此選取了簡書作為數(shù)據(jù)來源,簡書是一個任何人均可在其上進行創(chuàng)作的社區(qū),用戶在簡書上面可以方便地創(chuàng)作自己的作品,互相交流,它是國內(nèi)優(yōu)質(zhì)原創(chuàng)內(nèi)容的輸出平臺,選取簡書可以保證原創(chuàng)性以及專業(yè)性,但是單純分析一個數(shù)據(jù)來源可能會帶來一些誤差,我們需要其他類似的中文數(shù)據(jù)來源對通過簡書得到的結(jié)論加以驗證.

由于地理位置的緣故,本文對部分訪談人員采用電話訪談的方式代替面對面的訪談,這會帶來一定的限制,在理解被訪談?wù)叩恼鎸嵰鈭D上會存在一些誤差.本文的訪談對象中,兩位DevOps 研究者來自同一所院校,兩位DevOps 咨詢師也來自同一家咨詢公司,相同的環(huán)境帶來的限制會使本文對DevOps 理解的廣度上有所縮小.解決這一問題的一種方法是在中國環(huán)境下尋找典型的DevOps 實踐,進入現(xiàn)場觀察研究這個實踐產(chǎn)生的原因、方式等.在對專家E6 進行訪談時,我們在專家的帶領(lǐng)下了解其公司的工作流程,圖11 所示為其公司會議室墻壁上的標語.觀察與訪談的結(jié)合讓我們對他在訪談中提及的一些問題有了更為深入的了解.而這兩種方法也是民族志方法中最為重要的方法[25,28],二者配合,就可以實現(xiàn)對一個DevOps 實踐的更為深入的理解.

Fig.11 Meeting room of the company expert E6 works for圖11 專家E6 公司的會議室

此外,對于文中給出的軟件組織DevOps 轉(zhuǎn)型范例(如圖10 所示),我們需要對其中涉及到的DevOps 顧問(咨詢師)、軟件組織的高層(管理者)、開發(fā)團隊(Dev)和運維團隊(Ops)這4 個角色進行回訪.因為在不同環(huán)境下,人的行為以及人與人之間的關(guān)系是不同的[8],所以回訪有助于了解不同環(huán)境中范例的適用性,以此來進一步完善我們的范例.

5 總結(jié)

本文從文獻中識別出DevOps 自動化支持工具的集合,根據(jù)一些中文博客對DevOps 自動化支持工具在實踐中出現(xiàn)的實際問題進行了總結(jié),形成了3 個層次的問題,并對這些問題進行具體的闡述.最后針對3 個層次的問題,采用民族志研究中的訪談作為調(diào)研方法,對7 位專家和從業(yè)人員進行了半結(jié)構(gòu)式的訪談,從中歸納出對DevOps 自動化支持工具使用的建議.

本文的主要貢獻如下.

首先,我們通過系統(tǒng)化文獻評價獲得了DevOps 實踐中常見的自動化工具集合.

然后,我們通過中文博客總結(jié)出在實際的DevOps 實踐中這些自動化工具產(chǎn)生的問題.多樣化問題、聯(lián)系問題和文化問題這3 個方面的問題能夠很好地覆蓋問題的每一個方面.

第三,我們通過對DevOps 實踐中3 個維度的專家進行半結(jié)構(gòu)式的訪談來獲取他們對于3 個方面問題的看法和建議,這些建議能夠從不同的角度為軟件組織的DevOps 轉(zhuǎn)型提供幫助.我們也從專家們的看法中歸納出自動化工具在實際的DevOps 實踐中的地位,我們從組織引入DevOps 的時間角度,把其分為前期和后期,前期我們認為DevOps 實踐就是對自動化工具的使用與理解,而在后期,軟件組織需要通過建立符合DevOps 價值觀的組織文化來減少對自動化工具的依賴.

最后,我們建立了一個企業(yè)DevOps 轉(zhuǎn)型范例,試圖在專家建議的基礎(chǔ)上,為軟件組織提供更為明晰的轉(zhuǎn)型方向.