自動化工具對中國DevOps實踐的影響*

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

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

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

1 研究背景

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

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

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

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

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

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

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

2 研究方法

2.1 研究問題

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

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

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

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

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

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

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

2.2 研究方法

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

2.2.1 系統化文獻評價

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

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

2.2.2 灰色文獻評價

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

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

2.2.3 民族志:訪談

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

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

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

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

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

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

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

2.2.4 數據整合和分析

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

3 結果分析

3.1 針對研究問題1

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

Fig.3 Study distribution of DevOps tools圖3 DevOps 工具相關文獻分布

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

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

3.2 針對研究問題2

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

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 個專題中博客數量的時間分布

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

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

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

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

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

3.2.2 DevOps 實踐中自動化工具間的聯系問題

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

3.2.3 DevOps 實踐中有關自動化工具的文化問題

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

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

3.3 針對研究問題3

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

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

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

Fig.6 Power matrix圖6 權力矩陣

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fig.10 DevOps paradigm for software organization圖10 軟件組織DevOps 轉型范例

4 討 論

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

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

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

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

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

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

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

5 總結

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

本文的主要貢獻如下.

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

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

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

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