軟件系統配置研究綜述①

陳 艷,葉宏杰,陳 偉

1(中國電子科技集團公司第十五研究所,北京 100083)

2(中國科學院大學,北京 100049)

3(中國科學院 軟件研究所,北京 100190)

當前軟件系統更加趨于具有高可配置性(high configurability)的特點,目標在于提升系統的靈活性和可變性,使開發人員和系統管理人員能夠在不修改程序代碼的前提下通過改變配置來控制系統的行為以及改變系統的特性.軟件配置是指以用戶需求和軟件的功能、結構及主要特性等為依據,選擇和確定相關硬件、軟件和固件的型號、版本及數量,規劃軟件放置位置和關聯關系,設置軟件系統相關參數值等;狹義上的軟件配置主要指對軟件系統配置參數取值的設置[1].

隨著信息技術與互聯網技術的發展,軟件系統(尤其是網絡分布式系統)的規模和復雜度不斷提升,其在功能和非功能方面特性的設置和定制化往往是通過對配置項的不同取值來實現的,由此也使得復雜系統的配置項數量越來越多、復雜程度越來越高.

但是,大量配置參數在提高系統靈活性的同時也為應用的配置正確性帶來困難[1],為系統后續運行的可靠性、可用性、易用性以及系統性能等服務質量帶來極大挑戰,具體包括:

(1)大量配置項給用戶的使用和操作帶來困難和干擾.不恰當的、數量過多的配置項設計,以及缺少系統的、詳細的配置參數使用說明,會使用戶難以理解配置項與系統特性之間的關聯性,因此也很難通過正確調節配置來使系統達到預期效果.Xu 等人實證研究發現,大部分用戶只會修改系統6.1%～16.7%的配置項[2].Yin 等人也指出,有63.6%以上的配置錯誤是在用戶初次修改配置項時發生的[3].

(2)配置錯誤已經成為導致軟件系統錯誤和運行故障的重要因素之一[4].配置錯誤是指由于配置項取值設置不當而導致的軟件系統錯誤和運行故障,包括參數錯誤、兼容性錯誤和組件錯誤等[3].軟件配置錯誤往往帶來災難性后果.Barroso 等人發現配置錯誤是Google一個主要服務運行錯誤的主要原因之一[5].更嚴重地,在2009年,配置錯誤導致整個“.se”域癱瘓了一個多小時,影響了近百萬臺主機的正常工作.

(3)軟件配置與系統性能緊密相關,設置不當將嚴重影響系統的服務質量.軟件系統的資源需求往往以配置參數的形式進行設置,以提高系統的靈活性和可配置性,如緩沖區大小、最長響應時間、最大連接數等.此類配置參數如果取值不恰當,將會嚴重影響系統的性能,例如將數據庫最大連接數設置過小會顯著降低系統的并發能力,而如何合理設置此類配置參數,使得系統性能達到最優也是一個十分困難的問題.

綜上,軟件配置已經成為了一個備受關注的話題,并且已存在諸多的軟件配置相關研究工作.本文旨在對已有的研究工作進行梳理,系統化地分析相關工作,為今后的軟件配置研究提供線索依據和發展方向.

本文的組織安排如下:第1 節首先提出了一個面向軟件配置的分析框架,該框架從軟件生命周期和軟件配置技術手段兩個維度對軟件配置相關工作進行劃分和分析評價.第2 節簡要介紹了本文對軟件配置相關文獻的檢索和篩選方法與過程.第3 節分別從軟件生命周期中的設計階段、開發階段和后開發階段(即測試階段、部署階段和生產階段)中所面對的軟件配置問題以及當前代表性的相關工作進行介紹和分析,以及其他對典型軟件系統進行分析的研究工作.第4 節對軟件系統配置研究現狀進行總結,分析各類型研究工作的特點,并對軟件配置的未來研究方向作出展望.第5 節總結全文.

1 軟件配置分析框架

軟件配置活動存在于軟件生命周期的各個階段,本文從軟件開發的生命周期,即設計階段、開發階段、測試階段、部署階段和生產階段著手,對現有改善軟件配置設計、減輕不良配置影響以及應對配置錯誤的相關工作進行分析和綜述.除此之外,軟件配置分析的技術手段包括程序分析和統計分析等,本文也根據采用的技術手段對現有軟件配置分析方法進行分類.

本文首先建立基于軟件生命周期的分類方法.軟件配置是軟件系統中的重要組成部分,軟件配置的設計、開發、測試和維護包含于軟件系統的設計、開發、測試和維護過程中.因此,從軟件生命周期著手,在各個階段中尋求軟件配置面臨的問題以及相應的解決方法,可以有效提升軟件配置質量.軟件生命周期可以劃分為設計階段、開發階段和后開發階段,其中后開發階段即測試階段、部署階段和生產階段.在上述各個階段中,軟件配置面臨的主要問題如下:

(1)設計階段中的軟件配置問題主要是如何進行配置項的選擇和設計,即如何在提高軟件的配置性以及減少配置參數數量上進行權衡,從而通過清晰、有限的配置參數來實現軟件的高可配置.配置項的選定即明確系統的可配置點,指出哪些功能需要以可配置的形式展現給軟件系統的使用者.配置項的設計即確定配置項在系統中的表示形式,包括配置項的名稱、類型、存儲形式甚至使用的語言等[6].

(2)開發階段中的軟件配置問題主要是如何進行配置項的實現和管理.配置項實現需要關注配置項的約束和用戶配置手冊的編寫.配置項的管理即維護已經實現的配置項,并有效應對其變更.

(3)后開發階段中的軟件配置問題主要是配置錯誤處理和配置性能分析.配置錯誤處理即應對軟件配置帶來的系統錯誤,包括配置錯誤的檢測、診斷和修復等.配置性能分析即分析軟件配置與系統性能間的關系,包括配置性能間關系分析以及性能優化等.

其次,本文以軟件配置研究工作中所采取的主要技術手段為依據,對現有的研究工作進行分類分析,主要包括白盒方法(white-box)和黑盒方法(black-box)兩種,以及兩種方法的綜合使用:

(1)白盒方法的適用前提是軟件系統的源代碼(或字節碼)可獲取,從而能夠將目標系統作為白盒處理.采用靜態程序分析或動態程序分析技術,分析代碼中配置項的讀入點、控制流和數據流等,找到軟件配置與軟件系統本身的關系,進而解決具體問題.

(2)黑盒方法適用于無法獲得軟件系統源碼的應用場景,該方法主要基于統計方法、對比方法、機器學習等技術,通過運行一定數量的測試用例,觀察目標系統在不同條件下的執行結果,總結和發現軟件配置與軟件系統的內在關系,進而解決具體問題.

基于上述觀點和視角,本文以軟件生命周期作為文獻分類的主方法,簡述各項軟件配置相關的研究工作;當工作涉及到軟件配置與軟件系統關系時,本文將指出其基于的主要技術手段.

2 文獻檢索與篩選

為了保證綜述的全面性和時效性,本文采用的檢索策略如下:

(1)將研究工作的檢索范圍設定在近7年,即2014年～2020年.

(2)以軟件配置(software configuration)為第一關鍵詞,軟件配置相關的活動,如:設計(design)、管理(management)、性能(performance),為第二關鍵詞,組合成若干關鍵詞詞組.

(3)使用(2)中的詞組,分別使用谷歌學術和中國知網搜索引擎進行搜索,并按照相關性排序、選取相關性最高的前20 條結果.再以人工的方式進行去重、篩去不符合需求的文章.

(4)使用(2)中的詞組,在多個文獻數據庫中,以與軟件配置相關的期刊和會議為范圍進行檢索,再以人工的方式進行去重,篩去不符合需求的文章.

(5)分析(2)、(3)步獲得文章的參考文獻,選取在時間范圍內且與主題密切相關的文章,并重復該步驟.

(6)綜合以上(3)～(5)步結果,構成本文檢索范圍.

最終,本文選取了32 篇文章作為本綜述的范圍.文章的發表時間分布如圖1所示.從圖中可以看出,文章的發表時間分布較為均勻,表明軟件配置問題是軟件工程領域一個持續得到關注和研究的主題.文章的類型分布如圖2所示.大量研究工作集中在配置錯誤的處理上,關注配置項選定和設計的工作較少.本文認為,這是因為與此相關的工作被包含于軟件系統設計的工作當中,而軟件系統設計相關的研究已經較為成熟.

圖1 文章發表時間分布

圖2 文章類別分布

3 軟件配置研究概述

3.1 軟件設計階段的相關工作

軟件配置項的選擇和設計是軟件設計階段需要解決的問題.需要把需求中的部分可變點抽象出來作為配置項,以提高系統靈活性.配置項的選定應該準確且適量,這是因為:(1)不準確的配置項難以表達系統的可變點,增加用戶的理解難度和系統的維護成本;(2)過少的配置項不能滿足系統靈活性的需求,降低用戶滿意度并可能在特定場景下給開發人員帶來困難;(3)過多的配置項不利于維護,也可能使用戶很難確定需要改動的配置.在完成基于可變點的配置項選定后,需要對配置項進行設計,完善其語法和語義信息,使其易于理解和使用.配置項的設計包括配置項的名稱、類型、存儲形式、與變動點的映射關系等.

在可變點分析與配置項選擇方面,Mu?ante 等人參考基于眾包的需求獲取方法,提出基于眾包的配置項選擇方法[7].方法將眾包分為領域專家和潛在用戶兩類,其中領域專家負責確定系統的可變點,并根據可變點初步選定配置項,之后專家對潛在用戶的用戶畫像進行分析,并綜合用戶畫像和系統配置問題設計問卷.潛在用戶負責填寫問卷,展現自己的用戶畫像并表達對系統的反饋.最后,專家和開發人員對問卷進行統計和分析,確定配置項.該方法的優勢在于:(1)使用戶盡早接觸到系統配置,提高配置的可用性和易用性;(2)不僅在配置項的選定過程中有所幫助,在系統版本更迭、配置項變更時,也可以采用類似的方法進行系統配置的更新.其不足之處在于:(1)難以對方法的代價和收益進行定量評估,導致方法代價過大;(2)潛在用戶選擇困難:一方面,在項目開發初期,難以明確哪些群體是潛在用戶;另一方面,調研的潛在用戶數量不好確定,太少可能導致調研結果出現偏差,太多則會帶來額外時間和金錢的開銷.

在配置項設計原則方面,Xu 等人通過調研指出現有的系統配置項存在以下問題[2]:(1)大部分用戶只會修改小部分的配置項;(2)相比數值型配置項,枚舉型配置項更容易被用戶所使用.同時,配置項的值域越小,越不容易出現配置錯誤.由此,作者給出了2個配置項設計原則:(1)減少或者隱藏不必要和使用頻率低的配置項,對使用頻率不高但確實需要的配置項,可以通過“高級配置”的方式與普通配置項分隔開;(2)縮小無意義的配置項值域,多使用枚舉型的配置項,而枚舉數量以2～3個為佳.這些原則能夠降低配置項設計的冗余、提高配置項的質量,使用戶更易于配置系統.但是這些設計原則覆蓋面有限,不夠全面和完備,沒有考慮到配置項的命名等問題.例如,有研究顯示,配置項語義含糊是導致配置錯誤的重要原因之一[8].

3.2 軟件開發階段的相關工作

開發階段中的軟件配置相關工作主要包括配置項實現和配置項管理.

3.2.1 配置項實現

配置項實現以設計為依據,主要任務包括:完善配置項的約束,將配置項寫入配置文件或配置庫,編碼實現配置項訪問接口,以及形成配置說明文檔.當前已有工作主要關注于配置項約束的完善和配置文檔的編寫兩方面.

在配置項的約束方面,Li 等人研究了MySQL、Redis、ApacheHttpd 等常見大型開源系統的軟件配置項,對配置項按照類型進行了分類,并指出了每類配置項的約束[9].作者首先將配置項劃分為字符串型和數值型兩大類,再將每個大類劃分若干小類,繼續細分直到語義明確為止.對于每類配置項,作者根據其類型和運行時需求定義了語法約束和語義約束.如端口號應是0–65535中的一個整數(語法約束)且不能使用已經被占用的端口號(語義約束).該文章使用樹狀結構對配置項進行分類,對研究對象系統配置項的覆蓋率達到95%以上,并且具有很好的可擴展性.但基于類型的配置項約束完善方法主要考慮的是單個配置項的約束.現實中的配置項約束不局限于單個配置項內,還存在于多個配置項之間.對于配置項之間的約束,需要通過其他方法進行完善.

在配置項文檔方面,Zhang 等人實現了配置文件自動注釋工具ConfigFile++[10].作者認為,當前許多系統存配置文件注釋不充分、不規范的問題,導致了許多的用戶配置錯誤.ConfigFile++從配置項的類型、約束、作用等方面對配置項進行概括,生成統一格式的配置項注釋,插入配置文件中.ConfigFile++沿用Xu 等人的工作[2]和Li 等人的工作[9],分析配置項的類型和約束;對于配置項的作用,ConfigFile++對用戶手冊進行搜索,找到與配置項最相關的段落,使用TextRank模型[11]提取關鍵詞,概括配置項作用.最后,ConfigFile++生成統一格式的配置項注釋,插入配置文件中.該方法相當于生成了一份精簡版的用戶手冊,用戶在修改ConfigFile++注釋后的配置文件時,能夠對配置項有全面的了解,減少配置錯誤的發生.但是,ConfigFile++生成的配置項注釋段落長、信息量大,用戶很難快速找到關鍵信息,也會成倍地增加配置文件的大小.同時,ConfigFile++生成優質配置注釋依賴于成熟的用戶手冊.極端情況下,如果系統用戶手冊沒有對配置進行說明,ConfigFile++只能對配置項本身進行分析,能夠提取的信息比較有限.

此外,Nadi 對配置項約束進行了分類[12].作者認為約束按照作用劃分,主要包括以下4 類:(1)底層配置項依賴關系,配置項間的取值關聯隱含在程序代碼中,配置項設置時必須滿足此類依賴;(2)根據運行環境配置系統,保證系統在不同環境下的正確運行;(3)指導用戶進行配置,減少無效配置、提高用戶配置體驗;(4)避免極端情況,防止系統在配置項取某些值時不能正確運行.王燾等人關注配置項間的關聯,定義了一致性關聯和類型性關聯[13].一致性關聯指兩個配置項具有相同的值,或一個值是另一個值的子串;類型性關聯指兩個配置項之間存在類型上的語義關聯,若一個配置項的值發生變化,另一個配置項取值需相應進行改變.這兩類關聯是配置項之間的約束,要求修改存在關聯的配置項時,考慮其他配置項的變化.

文獻[10,12,13]的工作都對配置項約束進行研究,但分類方法和覆蓋面有所不同,總結如表1所示.

表1 配置項約束研究工作對比總結

3.2.2 配置項管理

軟件開發過程中,由于需求的變化或者新功能的增加,配置項可能發生變化.面對變化,如果缺乏配置項的管理手段,可能會出現配置項更新困難、配置不一致和配置項丟失等問題.因此,配置項的管理是軟件開發過程中配置項有效性、一致性的重要保證.

Tang 等人介紹了Facebook 配置管理套件[14].套件由Configerator、Gatekeeper、PackageVessel、Sitevars以及MobileConfig 組成.Configerator 提供最底層功能,提出配置即代碼(configuration as code)的思想.配置通過平臺無關語言Thrift 編寫,輸出JSON 格式的配置文件.Sitevars 提供編寫和修改配置的圖形化接口.Package-Vessel 解決大型配置文件頻繁更新的問題,將配置文件和其元數據分開更新.元數據上傳時立即更新;對于配置文件本身,PackageVessel 從元數據中找到文件位置,使用混合訂閱P2P 模型傳輸.Gatekeeper 負責新特性發布,控制特性的部分開放、對部分用戶開放或禁用等,控制產品逐步推出.MobileConfig 負責解決移動端APP的配置問題,包括平臺多樣性、移動網絡速度和新舊版本兼容性等問題.Facebook的配置管理工具套件的優點在于:(1)提出“配置即代碼”的概念,可以通過類似管理代碼的方法管理配置項,提高配置的可維護性;(2)從多角度考慮配置管理過程中可能遇到的困難,并設計了相應的解決方案.該套件對于大型項目的配置管理具有很高的參考價值.但另一方面,該套件并不適用于中小型規模的軟件系統,此類軟件系統的配置相對簡單,使用上述工具反而可能帶來不必要的開銷和效率的降低.

配置的管理可以依賴第三方工具完成,許多研究人員著手于開發配置項收集分析工具,輔助進行配置項管理.Tuncer 等人開發的云平臺上的配置項自動發現和提取工具ConfEx[15]是該類工作的代表之一.對待檢測系統,ConfEx 首先根據詞匯表和文件名劃分出各個配置文件所屬的軟件;其次ConfEx 對配置文件進行文本分析,以鍵值對的形式提取出文件中的配置項及其取值;然后消除歧義,保證每個鍵只對應唯一的值;最后將解析得到的配置文件和配置項列表展現給用戶.對于httpd、MySQL和Ngnix 等大型應用,該工具可以找到99.7%的配置文件及包含的配置項,而之前的方法Augeas[16]只能找到35.8%.但ConfEx的核心工作在于配置文件的發現上,對于配置項的提取,ConfEx僅是沿用了Augeas的方法.ConfEx 僅提供了配置項提取方法,并不涉及配置項的語義和約束等信息.

此外,Bartusevics 等人設計了一套模型驅動的軟件配置管理方式[17].該方式定義了配置管理過程中的3 種模型:環境模型、行為模型和分支模型,以及2 條規則:環境轉換規則和分支合并規則.應用該方法,在配置變化時,首先明確變化在模型變更中的體現,然后基于規則進行模型的轉化,完成配置項的管理.Perera提出了一種自動化配置管理方法[18].該方法通過程序分析,自動發現系統中的配置項及其約束,存入數據庫中進行統一管理.相比參照程序規格說明書進行管理,該方法更具有可靠性、且能夠發現說明書與實際程序不符之處.Jin 等人開發了配置項查找工具PreFinder[19].PreFinder 工作流程分為4 步:(1)通過程序分析和API調用提取配置項;(2)根據分隔符和貪心算法對配置項名稱分詞;(3)對自然語言查詢輸入進行縮略語轉化、停止詞消除等預處理;(4)使用TF-IDF 算法計算查詢與各個配置項的關聯性,推薦配置項.PreFinder是最早將自然語言處理技術應用于配置領域的工作之一.曾廣福等人提出了枚舉類型配置項配置空間的提取方法[20].該方法使用程序分析技術,找到枚舉類型配置項集中定義的代碼段,提取配置項的枚舉值,確定配置空間.作者使用Redis、MySQL 等6 款常用C/C++開源軟件進行測試,結果顯示該方法的提取準確率高于80%.復雜軟件系統通常使用配置框架,如Java Properties、Spring 等,統一管理配置.Sayagh 等人研究了配置框架對系統開發的影響[21].通過對2000 余個Java 項目和11 種Java 配置框架的分析,作者指出基礎、成熟、文檔完備的框架經常在開發中被使用且穩定性較好.

本文認為已有工作主要從以下兩方面提高軟件開發過程中配置項管理的能力:(1)配置演化變更管理,建立和完善配置項變更應對機制,以成熟的理論和工具變更配置項(包括參考文獻[14,17]);(2)配置理解發現,發現和理解系統配置項,對配置項進行集中管理(包括參考文獻[15,18–20]).兩類工作相輔相成.在實際配置管理過程中,可以首先通過(2)中工作的方法整理配置項,建立配置管理中心,然后通過(1)中工作的方法變更配置.

3.3 軟件后開發階段的相關工作

軟件后開發階段主要包括測試、部署和生產.在這3個階段中,軟件配置所面臨的主要問題既有相似性,側重點又有所不同.3個階段都以配置錯誤處理和優化為主.測試階段側重于配置錯誤的處理;部署階段側重于配置項調優;運維階段則同時關注配置錯誤處理和性能優化兩方面.

3.3.1 配置錯誤處理

軟件配置錯誤常見且負面影響極大,因此,盡早地發現軟件配置錯誤并進行修復極為重要.軟件配置錯誤處理主要分為檢測、診斷和修復3個階段[1].錯誤檢測主要判斷系統是否存在配置錯誤,或者當前系統錯誤是否是軟件配置導致的;錯誤診斷主要分析配置錯誤具體是由哪一個或者哪一組配置項導致的,以及為什么會導致配置錯誤;錯誤修復為錯誤的配置項重新設置正確的值,使系統可以正確運行.此外,還有一些工作研究配置項在程序中的表現形式(如程序中的配置項讀入點、配置項在程序中的類型等),輔助進行配置錯誤的處理.

Xu 等為盡早發現配置錯誤,將軟件測試的思想引入軟件配置中,提出了軟件配置測試方法[22].配置測試分為3 步:(1)將硬編碼在源代碼中的配置項參數化;(2)給配置項賦予實際運行環境中使用的值;(3)運行測試用例.作者還提出了以下幾點看法:(1)配置測試應該保證測試的充分性和路徑覆蓋率;(2)可以沿用軟件測試中的測試用例,因為這些測試用例已經包含了大多數配置項的執行路徑;(3)當軟件測試的測試用例不足以覆蓋執行路徑時,需要配置測試專用的測試用例;(4)當配置出現變更時,需要對變更的配置項本身和依賴該配置項的所有配置項進行配置測試.該方法指出可以像測試代碼一樣充分測試配置,避免配置錯誤的發生.但是,大型軟件系統配置項數量多、結構復雜,如何設計測試用例,通過少量用例覆蓋大部分配置,作者在文中并沒有進一步討論.

Wang 等人對比異常日志與正常日志的差異,開發了基于日志的配置錯誤診斷工具MisconfigDoctor[23].MisconfigDoctor 分為學習和診斷兩個階段.在學習階段,MisconfigDoctor 首先違背配置項約束,產生若干錯誤的配置,再分別在正確和錯誤的配置上運行測試用例,得到日志輸出,并對日志文件進行移除時間戳、統一單詞形式等預處理.MisconfigDoctor 比較正常日志和異常日志,記錄每個配置錯誤對應的“+語句”(正常日志不出現而異常日志出現的句子)、“–語句”(正常日志出現而異常日志不出現的句子),以此作為配置錯誤的特征存入庫.在診斷階段,對于新的異常日志,MisconfigDoctor對異常日志進行預處理,與特征庫中的各個配置錯誤進行比對,得到最有可能的數個配置錯誤.實驗顯示,該方法檢測出了31個真實存在的配置錯誤.該方法充分利用了程序日志,以白盒的方法進行配置錯誤的診斷.但是,該方法也存在一些不足:(1)依賴于軟件系統的日志信息.如果系統日志區分度不足,MisconfigDoctor很難進行正確的診斷;(2)該方法只能診斷出學習階段中預定義的配置錯誤,難以發現新類型的配置錯誤.

Zhang 等人研究軟件更新過程中產生的配置錯誤,開發了工具ConfSuggester,推斷導致配置錯誤的配置項[24].ConfSuggester 運行過程分為3個階段:運行程序、比較結果和推斷配置項.運行程序階段,ConfSuggester 使用相同配置文件和輸入運行更新前后兩個版本的程序,檢測每個程序斷言執行的次數和判斷為真的頻率.比較結果階段,ConfSuggester 首先將新舊兩個版本對應的程序斷言進行匹配,然后計算每個斷言的執行次數和判斷為真頻率的調和平均數,當平均數偏差大于閾值時,該斷言存在問題.推斷配置項階段,ConfSuggester 進行程序切片,找到引起問題斷言表現不同的配置項并計算權重,輸出結果.ConfSuggester可以在1.8的平均推薦順位上找到配置錯誤,而之前的工具[25]需要在15.3的平均推薦順位才能找到.Conf-Suggester 在發現更新引起的配置錯誤上表現較好,但擴展性有限.對于長期存在的配置錯誤和無法提供歷史版本的系統,ConfSuggester 作用有限.另一方面,當程序規模較大時,簡單的輸入很難覆蓋到所有程序斷言,需要高質量或者多數量的輸入為ConfSuggester 提供支持.

配置項取值不同會影響程序的控制流.發現異常控制流是解決配置錯誤的重要方法之一.Nguyen 等人開發了程序交互發現工具iGen[26].程序交互,指配置項值與程序代碼覆蓋間的關聯,即配置項值對程序控制流的影響.iGen 生成多份被測程序的配置文件并運行程序,劃分出每份配置文件覆蓋和未覆蓋的代碼.當覆蓋條件由多個配置項取值的合取組成時,若多份配置文件覆蓋到同一段代碼,iGen 對這些配置文件的配置項進行交運算并繼續生成多組配置文件,重新運行和計算直到結果不再變化.結果集合表示對應代碼被覆蓋到時各個配置項的取值范圍.類似地,當覆蓋條件由多個配置項取值的析取組成,或由多個配置項的析取和合取共同構成時,iGen 也設計了相應檢測算法.在29個程序片段上的實驗顯示,iGen 計算出各個程序交互的平均F1-score 達到了99.7%.該方法的局限性在于:(1)檢測的配置項類型以離散的數值型為主,當配置項是字符串型時,該方法不適用.當配置項是連續的數值型時,該方法很難得到準確的結果;(2)當配置項數量多、值域大時,檢測的準確性會有所降低.

除了上述工作之外,Sayagh 等人將研究重點放在跨軟件棧的配置錯誤上,指出跨棧配置錯誤由于配置項數量多、層間配置項關系復雜等因素,處理較為困難.在此之上,作者提出了基于程序分析的模塊化方法,診斷出可能出錯的配置項[27].該方法已經應用到實踐中,發現并修復了1082個配置錯誤.Santolucito 等人使用機器學習的關聯規則挖掘算法研究配置項是否有誤[28].作者從配置文件中提取配置項并進行訓練,使用基于關聯規則的學習算法得到一系列配置項的規則,以此判斷一個配置項是否存在問題.經過實驗,該方法可以檢測出多種類型的配置項錯誤,并保持著11%～18%的低誤報率.Xu 等人開發了工具PCHECK 用于檢測延遲性配置錯誤[29].延遲性配置錯誤是指在系統啟動時不會觸發,但隨著系統運行、執行到特定語句時觸發的配置錯誤.這類配置錯誤通常難以發現.PCHECK通過程序分析的手段,生成能夠檢測配置項是否存在錯誤的代碼并插入程序中.實驗表明該方法可以有效檢測出延遲性配置錯誤,并對其他類型的配置錯誤也具有一定的檢測能力.Potharaju 等人開發了工具Conf-Seer,用于檢測配置錯誤,并給出修復方案[30].ConfSeer結合了自然語言處理、信息檢索和交互式學習等多種技術,建立解決配置錯誤的知識庫,檢測和修復配置錯誤.該工具的準確率達到了80%～97.5%,并且有運行開銷低的優點.Xu 等人開發了自動推測配置項類型的工具ConfTypeInfer[31].ConfTypeInfer 使用基于配置項名稱的方法和抽象語法樹分析方法推測配置項的類型.基于配置項名稱的方法通過配置項詞典分析配置項名稱的語義信息,確定其類型;抽象語法樹分析方法通過分析程序的抽象語法樹,確定配置項是否為枚舉類型,是基于配置項名稱方法的補足.兩種方法綜合使用,ConfTypeInfer的準確率達到了90%以上.Dong 等人開發了識別程序中配置項讀入點的工具ORPLocator[32].ORPLocator 工作流程如下:(1)以程序代碼和配置父類作為輸入;(2)根據配置父類識別出配置子類;(3)提取子類中從配置文件中讀取配置項值的方法;(4)找到調用這些方法的代碼,得到配置項對應變量.實驗表明,該方法可以在大型程序中找到95%的配置項讀入點.

本文對上述工作關注點和配置分析采用的技術手段的總結如表2所示.

表2 配置錯誤處理研究工作總結和對比

由表2可看出:

(1)配置錯誤處理方面的工作采用的技術手段以白盒分析方法為主(7 項工作使用了白盒分析方法,4 項工作使用了黑盒分析方法).本文認為,其原因在于:1)配置錯誤的處理通常由軟件開發方進行,其有能力獲取軟件代碼,可以實行白盒分析;2)白盒分析方法可以覆蓋到更多的配置錯誤,相比黑盒方法更容易找到和處理不常出現的錯誤,且具有更高的準確率.

(2)配置錯誤修復方面的研究工作較少(僅文獻[26,30]的工作可以輔助進行配置錯誤修復).本文認為,其原因在于:許多配置錯誤的修復需要運用領域知識進行人工修復,自動化程度較低,難以形成系統化的工作.

3.3.2 配置參數調優

軟件配置與系統性能密切相關.通過調整配置以改善系統性能,首先要建立模型,表示配置項與系統性能的關系;然后根據實際需求和約束,為配置項設定恰當的值,通過配置參數調優達到優化系統性能的最終目標.

Sarka 等人研究了建立配置項與系統性能關系模型時對配置項進行抽樣的方法[33].方法在模型準確率與樣本采樣代價之間進行權衡,提出了基于頻率的投影抽樣來實現模型準確率和獲取樣本代價間的平衡.投影抽樣是在選定初始樣本后,每次迭代中新增一定數量的樣本產生(樣本容量,準確率)點對,并使用常見的曲線進行擬合,找到一條能夠較好表達當前模型樣本容量和準確率曲線的方法.方法基于頻率選取初始樣本,使初始樣本中每個配置項都至少需要被啟用和禁用若干次,這樣生成的樣本才具有代表性,能夠快速找到擬合度高的曲線.實驗顯示,投影抽樣方法優于漸進抽樣,而基于頻率的初始樣本選取方法也在大多數情況下比傳統的隨機選取和多路選取方法好.

Wang 等人開發了用于系統性能調優的配置框架SmartConf[34].該框架根據用戶期望的系統性能,由系統自動調整系統配置以滿足需求.使用SmartConf 框架時,開發者說明哪些配置項與什么性能相關,并設定配置項的初始值;用戶說明期望的系統性能,系統通過SmartConf 控制器,自動調整配置項的值.SmartConf 控制器通過控制理論實現,系統下一時刻的性能由當前時刻配置項的值所決定,而當前時刻配置項的值又由上一時刻配置項的值、以及當前時刻系統性能與用戶期望的誤差所共同決定.實驗結果顯示,相比靜態取值,SmartConf 動態修改配置項的值可以提高系統1.2～1.5倍的性能.SmartConf的不足在于需要開發人員指出配置項和性能指標之間的關聯,需要豐富的領域知識和前提條件.如果能夠實現配置項-性能指標關聯自動發現功能,SmartConf的動態調整效果可以進一步提升.另一方面,由于SmartConf 在系統運行時動態修改配置項,因此不適用于運行時可以動態更新配置并使之生效的系統和場景.

除了上述工作之外,Zhang 等人提出基于傅里葉變換的系統性能配置模型以及模型學習方法[35].將該方法在多個系統上的準確率達到92.5%以上,而模型的構建僅使用2.2%的樣本.系統性能不佳經常是由于系統資源不足、程序競爭資源產生的,為此Feng 等人開發了檢測系統資源競爭并通過調整配置項解決競爭的工具Relax[36].Relax 通過靜態程序分析的方法找到和資源相關的軟件配置項,調整競爭軟件對資源的占有率以解決沖突.引入Relax 后,程序的運行時間能夠縮短15%以上.關于選取模型的學習樣本,Nair 等人認為建立精確的配置性能模型是代價巨大且不必要的,無需精確的性能值即可對配置方案進行排名[37].作者提出了基于排名的方法,顯著地降低了建立模型的成本,并在多個系統中取得了明顯的成果.Kaltenecker 等人提出了基于距離的采樣方法[38].該采樣策略基于距離度量和概率分布,以給定的概率分布在配置項空間中采集配置項樣本.經過實驗,該方法在配置項空間較大時仍然可以建立更準確的性能模型.Han 等人使用神經網絡估計系統性能,分析輸入程序、服務器配置配置、云服務器間干擾程度與程序執行時間之間的關系[39].在用戶選擇購買時,使用該模型評估當前服務器配置的性能,購買到恰當配置的服務器資源.

本文對上述工作關注點和配置分析采用的技術手段的總結如表3所示.

表3 配置參數調優工作總結和對比

由表3可看出:在配置參數調優領域,許多工作的焦點集中在快速建立高質量的配置數據集上.本文認為,這是因為:1)軟件系統配置項多、配置空間巨大,采集典型的配置樣本集合比較困難.2)對每一個配置樣本,系統都需要以該配置運行系統才能采集評估指標,獲取評估指標代價較大.3)數據集建立后,構建配置性能模型的方法有一定的數學理論作為支撐,相對容易.

3.4 其他工作

除了上述工作之外,還有一些工作的重點在于對已有系統配置的分析和實證研究方面.

Jha 等人以908個Android 應用程序的配置文件(即manifest.xml 文件)為研究對象,對這些文件的版本變更過程進行分析和總結,找到了一系列Android 應用程序配置變更的規律[40].實證研究發現:(1)配置變更的主要原因是新增組件(占全部變更的44.0%)和申請新的權限(占全部變更的14.6%).進一步地,作者總結認為Android 應用程序發生配置變更的首要原因是應用程序新增功能.(2)Android 應用程序配置變更的頻繁程度和其功能點數量并沒有明顯的關系.(3)除了新增功能之外,很大一部分配置變更是由于改進用戶界面.改進用戶界面的手段包括更新主題、圖表、導航欄等(占全部變更的21.6%).(4)Android 應用程序常在新增功能點方面做無用功,即新增了一個功能點、但過一段時間后又由于某些原因刪除了這個功能點.這些發現能夠對Android 應用程序的更新提供指導,并對軟件配置變更的研究有一定的意義.

Sayagh 等人以WordProcess (WP)為例,研究了跨軟件棧系統中低層軟件配置對高層應用的影響[41].WP 按調用關系從上至下可以分為3 層:WP 插件、WP本身和PHP.研究分析發現:(1)WP 插件為提高可用性,通常將配置項存儲在數據庫中;而WP 本身也是如此.因此,數據庫中的配置項可能屬于軟件中的任意一層.(2)WP 插件跨層使用配置項的情況較為常見,平均每個插件使用1.4個PHP 層配置項、并修改0.4個PHP 層配置項的值.(3)單個配置項被多個插件同時使用的情況十分常見,78.88%的可配置常量和85.16%的數據庫配置項會同時被至少2個插件使用,而單個配置項同時被最多458個插件使用.(4)配置項間接使用的情況比直接使用的情況更多.這些發現說明了跨軟件棧系統中可能潛藏著許多配置問題.進一步地,這些發現能夠為跨軟件棧配置錯誤處理提供理論依據.

4 分析和展望

通過對綜述范圍內(除參考文獻[1,3–6,8,11,16,25,42–44]外，均為綜述范圍內的文獻)的研究成果分類和分析,本文對當前軟件配置領域的相關研究成果所具有的特點總結如下:

(1)在軟件生命周期中,軟件配置的研究成果主要集中于開發階段和后開發階段,統計結果如圖3所示.其中,配置錯誤處理、配置項管理和配置參數調優是研究的熱點.本文認為,這是因為:1)配置項數量和復雜度的增加,簡單維護配置文件或數據庫已經很難滿足需求、難以應對復雜的情況,因此需要新的技術和工具輔助進行配置項管理,提高效率;2)配置錯誤和系統性能不佳是軟件配置缺陷的直接表現,配置錯誤處理和配置參數調優是解決問題的直接手段.由于軟件系統的配置項的增加,配置缺陷逐漸暴露,首先要解決的就是直接體現的配置錯誤和系統性能問題.

圖3 不同階段軟件配置領域文章數量統計

(2)黑盒方法和白盒方法都廣泛應用于軟件配置相關的研究中,統計結果如圖4所示.總體而言,兩種方法的使用頻率相近,但在具體領域,黑盒方法和白盒方法各有優劣,故使用率存在較大差異.

圖4 各領域工作采用的技術手段分布

(3)對于配置錯誤處理領域的工作,本文已在3.3.1節末尾作出分析.在其他方面的工作,采用的技術手段以黑盒分析方法為主.本文認為,其原因在于:1)其他方面的工作通常有軟件的使用者參與,不宜將代碼實現暴露給用戶;2)配置參數調優關注軟件配置與系統性能間的關系,其中涉及到語言優化問題和操作系統層面問題等,基于白盒方法進行分析并不適用.

(4)使用白盒方法對軟件系統配置進行分析的一般流程如下:1)獲取系統配置項;2)找到配置項在程序中的讀入點;3)切片分析,找到配置項影響的控制流和數據流;4)定位所分析問題對應的程序片段;5)分析配置項控制流、數據流和對應程序片段的關系;6)評價各個配置項與所分析問題的關聯度,排序并給出結論.

(5)使用黑盒方法對軟件系統配置進行分析,一般從以下幾方面考慮:1)分析配置項名稱和值中的語義信息;2)收集多份配置文件,通過數據挖掘和機器學習等方法發現配置項取不同值時和所分析問題的關聯;3)收集系統用戶手冊和論壇相關問答,通過自然語言處理等方法提取有用知識;4)收集日志信息,挖掘日志輸出和配置的關聯.

綜合上述幾點,本文認為,在選擇使用黑盒方法還是白盒方法進行軟件系統配置分析時,可以從以下幾方面進行考慮:

(1)問題領域.當進行配置錯誤處理時,白盒方法更為常用;當進行配置性能調優,尤其涉及到多軟件系統、操作系統層面的問題時,通常考慮黑盒方法.

(2)程序源碼是否可獲得.如果可獲得,可以考慮使用白盒方法進行分析,否則只能使用黑盒方法.

(3)是否存在額外資源(如用戶手冊、日志輸出等).如果存在,有助于提升黑盒方法分析的準確度;如果只有單一配置文件,使用白盒方法分析準確度更高.

通過對當前軟件配置錯誤檢測、診斷與修復相關的研究熱點和主要工作進行分析,本文認為該領域的未來研究趨勢包括以下方面:

(1)跨軟件棧配置錯誤的處理.對于單個軟件堆棧上的配置錯誤處理的研究,目前發展較為充分,但對于跨軟件棧的配置錯誤處理,研究成果仍然較少.而在實際應用中,跨軟件棧的大型復雜分布式系統已成為常態.調查顯示,相比單軟件配置錯誤,跨軟件棧的配置錯誤更容易導致系統崩潰,且修復難度不低于單軟件配置錯誤[27].因此,對于跨軟件棧配置錯誤問題的研究將是未來的研究發展趨勢之一.

(2)基于深度學習的配置優化.隨著配置項數量的增長和軟件性能指標的增加,傳統的機器學習模型面臨著建模難度大和需求訓練集樣本容量大的問題.在其他領域(如聲紋識別領域[42,43])的成果表明,面對復雜的建模問題,深度學習方法和傳統機器學習方法相比模型表示更簡單、準確率更高.因此,本文認為,在未來幾年的研究中,深度學習方法會逐步應用于以提高系統性能為目標的配置優化中.

(3)軟件配置演化維護.持續演化已成為軟件系統發展演進的重要特征,其中的軟件配置也隨之一同演化和發展,并貫穿于軟件生命周期的各個階段.因此,對于軟件配置問題的理解和認識更加需要站在全生命周期的視角去理解和看待,將各個階段融會貫通,通過持續軟件工程的方法提高軟件配置在系統持續演進過程中的維護和管理能力.例如,通過不斷的迭代演進將后開發階段發現的配置問題反饋到新一輪迭代中的配置設計和實現中,不斷提升軟件配置的質量、合理性和可理解性等.

(4)軟件配置領域知識的匯聚與運用.開源軟件和技術社區的發展積累了大量的軟件數據,其中也包括與軟件配置相關的數據與知識,散落和隱藏在多源異構的軟件倉庫與社區中.例如,從Docker Hub、GitHub和StackOverflow中都能夠獲取與軟件系統配置相關的數據和知識[44].因此,從上述數據來源中分析抽取軟件配置知識,并進行有效的組織和管理(如知識圖譜),也是后續研究中提高配置領域知識應用的一個有效方法和途徑.

(5)新軟件形態和技術中的配置問題.隨著云計算、人工智能和大數據等技術的成熟運用,基于這些技術的軟件系統和平臺不斷涌現.新場景下是否衍生出新的軟件配置需求和問題,已有軟件配置方法和成果是否能夠應對,還有待進一步研究.

5 結束語

隨著軟件系統規模的不斷擴大,以及用戶對系統靈活可定制性要求的逐漸提高,軟件配置已經成為軟件工程領域的一個重要話題.國內外眾多學者和研究人員從不同視角出發,對軟件配置的諸多問題展開研究,取得了眾多成果.本文對軟件配置領域的研究現狀和主要成果進行分析綜述,首先分析了軟件配置面臨的問題,然后提出了基于軟件生命周期和技術手段的軟件配置相關研究工作的分析框架,然后基于該框架對當前主流的研究成果和研究現狀進行分類總結和分析評價,最后總結當前軟件配置領域研究工作的特點,并對未來研究方向提出了展望和建議,對于今后該領域的繼續和深入研究具有一定的借鑒意義.