AIDevOps離我們有多遠？

本文轉自微信號EAWorld。掃描下方二維碼，關注成功后，回復「普元方法+」，將會獲得熱門課堂免費學習機會！

本文目錄：

一、寫在前面

二、AIDevOps，未來已來

三、AIDevOps的方法

四、學術界的研究啟示

五、距離AIDevOps還有多遠？

六、參考文獻

一、寫在前面

如果有一天機器人可以代替我們做代碼Review，會自動分析出當前代碼變更集對相關功能的影響，對迭代完成的影響，甚至對軟體成本的影響。並且指導程序員如何修改代碼，降低缺陷幾率；或者招聘時，候選人的簡歷不再是簡單的文字描述，而是切實的度量指標，並且個體指標可以和組織現有的集體指標進行彌合，來預測他的加入對團隊所產生的影響，從而決定一個面試者是否合適。這一切會到來嗎？

為什麼軟體工程始終無法像建築工程那樣可以工業化，說到底就是軟體工程中的靜態數據（代碼本身的特性）、動態數據（軟體過程）、差異性大、維度複雜、隨機性大，所以軟體工程預測學已經研究了十幾年，仍舊沒有商用。然而AlphaGo已經打敗了傲視群雄的柯潔，蘋果也在WWDC2017上公布了若干支持機器學習的應用。這一切對軟體工程的發展產生什麼樣的積極影響？AIDevOps(智能化DevOps)離我們還有多遠？

二、AIDevOps，未來已來

曾經在推特上看見一個網友這樣定義DevOps：「DevOps is software eats infrastructure」，也就是說DevOps是用軟體來定義基礎設施，這個定義比所謂的Infrastructure as Code更準確一些。不僅僅止於代碼本身，目前DevOps比較流行的趨勢是用相對成熟的開發體系整合運維體系，將部分運維的工作前移到開發階段，用流程改進的方法讓開發和運維統一，這樣運維就可以享受較為成熟的開發工具，規範的設計方法，規範的開發流程。我常在想，為什麼不是用運維的模式，指導思想整合開發工作呢？

除了部署以外，運維的大量工作都在監控基礎設施，對異常問題進行事件告警，並且採取干預行動保證生產環境穩定、健康、可靠。運維工作的數據來源是機器，而開發工作毋庸置疑是由人主導，但是由人產生的數據就隨性，複雜很多。所以數據的角度看，運維工作更加剛性，開發工作比較柔性。目前階段用開發的方法統一運維就顯得簡單，並且可操作了。但是！DevOps統一的過程中不知不覺形成了一個微妙的變化。具體是什麼呢？

從上面軟體工程發展來看，我們可以得出兩個趨勢：由零散到整合，由自動化到智能化。這背後的動因就是：DevOps的本質是軟體生命周期數據鏈的形成。而利用數據做事一直是運維擅長的。

目前已經有不少組織開始在運維方面運用人工智慧的方法使傳統運維變的智能化。目前DevOps將部分運維工作整合到開發，而剩下的工作將以智能化運維的方式代替，這也就是為什麼我認為今後運維的規模要縮減很多的原因。

而當我們有了數據鏈之後，就為傳統運維意識：「監控事件告警行動」向整個軟體生命周期進軍鋪平了道路。也就是說這種度量意識是從運維反饋給開發的。在度量意識驅動下的智能化運維AIDevOps將具有以下模式：

度量：針對軟體生命周期內的不同行為進行度量點定義，並且定義度量點的度量指標，對軟體生命周期數據進行度量。

分析：對現有數據進行收集匯總，針對不同業務目標確定預測模型，或者對原有模型進行調整。

學習：用數據進行建模，通過對不同模型效能的評估，確定可用模型。

預測：通過數據對業務目標進行預測。

指導：針對預測結果和度量目標的對比，對實踐者進行最佳實踐指導。

行動：按照指導行動，並為下一次的度量積累數據。

在理想情況下，人們只需要參與度量和行動環節，而其他環節都可以由機器自動的完成。並且度量環節只在系統初始化的時期設定，除非業務目標調整，一般是不會進行持續改變的。指導環節是很有必要的，即便在度量目標已經達到的情況下。我在以往的文章中講過，度量有三中類型：過猶不及型，越多越好型，以及越少越好型。所以當目標達到時，並不是繼續沖高更好。舉個例子，當任務目標達標時，並不是給予研發人員更多的壓力更好，更多的壓力會帶來代碼質量低下，以及潛在的問題數增多。所以，AIDevOps會更加全面的利用軟體工程的數據，挖掘潛在的影響因素，幫助我們更好的完成軟體開發。

說到軟體預測研究其實並不是一個新的話題，這些年來有大量的研究論文圍繞如何預測軟體缺陷，或者軟體維護成本等問題展開。如果搜索軟體預測方面的論文，你會發現發表日期可以追溯到2000年左右，可見軟體預測的發展歷史已經很久了，可是為什麼沒有一家商用的預測軟體呢？究其原因有以下幾點：

軟體工程能力成熟度不同，預測的價值有時屬於錦上添花。

預測研究所用的數據比較單一，數據可用性不強。

不同項目，不同產品的管理過程不同，因此同一種數據會有不同的數據上下文。

但隨著數據鏈的完善，雲設施的廣泛部署，以及微服務帶來的軟體開發複雜度，管理複雜度攀升。AIDevOps在技術設施，商業需求上已經逐漸成熟。說了這麼多，讓我們來看看如何將人工智慧運用到軟體工程領域。

三、AIDevOps的方法

如何開展一個軟體預測性研究，目前的關注點主要是以下幾個方面：

研究採用什麼樣的預測模型。

所採用什麼樣的度量指標進行預測。

如何進行數據預處理。

如何評價模型的預測結果。

模型

預測分析主要採用兩大類演算法體系：統計方法、機器學習的方法。

統計的方法就是以若干屬性為維度找出數據集在另一維度上數據分佈情況。其實統計的方法已經很成熟了，比如以時間的角度去看缺陷如何變化的燃盡圖。短時間內變化不如長時間段看趨勢有指導意義。不過，計的數據只在某些維度下比較有意義。如果維度過多，並且度量的範圍過大就沒有意義了，因為整體趨勢總是類似的。

目前研究的大熱門，機器學習大部分文章圍繞在如何基於經典的分類器（樸素貝葉斯，邏輯回歸，決策樹等）設計出自己的預測演算法。一般來說採用機器學習的方法進行預測的套路是這樣的：

選定度量指標（特徵）。

從例如代碼庫，項目管理工具，測試工具等系統中抽取度量值。

對度量值進行預處理。

使用數據對若干個模型進行訓練，並且選定一個最優的模型。

進行正式預測。

AlphaGo讓深度學習家喻戶曉，其實深度學習也是機器學習的一個領域。那麼深度學習較之之前的邏輯回歸，或者部分樸素貝葉斯演算法有什麼優點呢？以邏輯回歸為例，它無法將不同的特徵量合併產生新的特徵量，例如貝葉斯也有條件無關性假設，即如果用X Y Z作為建模的度量指標，它們必須無關才行；但是這點有時很難做到。比如人員規模和進度有關聯嗎？當然有關聯。另外大多數度量點和預測結果遠非線性關係，這對於邏輯回歸和非連續的樸素貝葉斯來講就很難產生好的預測結果，使用者必須非常小心的挑選度量點。而深度學習就可以解決上面這些棘手的問題。

度量點怎麼選？

度量點的選擇是一個技巧性的問題。研究證明並沒有一套最佳度量點可以放之四海，也就是說對於不同的預測上下文（預測目標），需要選擇不同的度量點，比如說缺陷預測的度量點和軟體維護成本預測的度量點就不一樣。可以用以下分類方式對目前流行的度量點進行分類。

另外一個需要關心的問題就是，度量點數到底多少為好呢？一般情況下相關的度量點越詳細，那麼對於問題捕捉的準確度越高。但經常遇見的問題就是，如果數據質量不高，還想做預測該怎麼辦？有一篇「How Many Software Metrics Should be Selected for Defect Prediction?」，答案是最少需要三個度量點。

數據如何預處理

一般而言，獲得的數據一般會分為兩塊：

第一塊，訓練數據集，用來訓練和建立模型；

第二塊，驗證數據集，在已經建立的模型上對不同模型（分類器）在不同場景下進行測試，選擇適合的模型。

在開始進行建模之前，必須對數據集進行一定的數據清洗。很多演算法的輸入條件都比較苛刻。比較理想的數據研究對象是，有問題的和沒有問題的各佔一半，這樣模型才有充分樣本可以學習。如果說一個模塊的缺陷率有0.3%，這樣就會造成一個數據不平衡的問題（Data imbalance）；以及如果數據特徵不夠明顯，最終的模型也會產生過擬合的問題，這也會造成模型的不準確。因此一般會採用一些方法點對數據進行清洗：特徵選擇（Feature Selection）、規則化（Normalization）、噪音處理（Noise Handling）。

如何評價演算法有效性？

如果有若干個備選模型，或者備選度量點，如何評價該採用那一個（套）呢？在演算法的評價方法上，學界還是有共識的。我們先普及一下這幾個指標：

由上面的幾個基本指標再派生出例如，精密度（Precision, TP/(TP+FP)）、查全率（Recall, TP/(TP+FN)）、以及兩者的綜合F度量，分值越高證明演算法既能預測到更多的研究對象又比較穩定。詳細的概念就在這裡不再贅述了。

四、學術界的研究啟示

有一篇比較有意義的論文「Researcher Bias: The Use of Machine Learning Software Defect Prediction」，他對2012年以前出現的機器學習法軟體預測學論文進行了研究，並以「分類器、數據集、度量點、研究團體」四個維度進行了匯總分析「Meta-analysis」。文章的結論還是比較震撼的，作者用了「Striking」這個詞對論文進行了總結：

很多分類器並沒有很好的鑒別作用，並且他們之前的差別也並不明顯；因為還有一些未知的因素對模型效果產生了比較大的影響。

較之分類器模型，不同研究團體之間的研究成果差距明顯。也就是說演算法並不重要，誰做的研究更重要。

因為預測套路大多都是在已經存在的數據集之上建模，並且用已知的數據進行測試，用已知結果來反推演算法讓模型變得可用，這樣以來研究小組總是發明自己的演算法，造成演算法的複雜度越來越高，換一個數據集可能模型就沒有移植性。

研究成果有沒有隨著時間的推移更加成熟了呢？並沒有！因為以上的原因，研究的持續性比較差，也就是說很少有論文在之前論文的基礎上開展更加深入的工作。

難道AIDevOps無法實現了嗎？，近些年研究者在可獲取的數據量，數據廣度，或者研究方向上都有了明顯的變化，如「Deep Learning for Just-In-Time Defect Prediction」，「Automatically Learning Semantic Features for Defect Prediction」這兩篇已經開始用深度學習的方法，進行更有時效性的缺陷預測。之前也講了深度學習模型的特點，在這兩篇論文中都是用了深度置信網路DBN為模型進行預測，DBN由多層玻爾茲曼機RBN組成。相對之前直接用度量點的數據為輸入進行建模的方式，DBN在用分類器進行結果判定之前，用若干層RBN對數據進行處理，從而得出特徵值，再用該值進行判定，輸入值和結果值不被限定在線性關係，因此DBN比簡單的分類器方法更加可信。比如論文「Automatically Learning Semantic Features for Defect Prediction」不再以傳統的度量值為輸入，而是對代碼的語義進行解析，形成特徵向量，再輸入到DBN中進行模型訓練。

此外，近些年的論文在數據量大小以及項目多樣性方面已經具有所謂「大數據」的特徵。研究者們有更多並且高質量的數據可以使用研究。正如李飛飛教授所說，數據集將在高級人工智慧研究方面扮演至關重要的角色。這也為軟體預測的發展奠定了良好的基礎。

在商用軟體架構領域，這些年也在發生著悄然生息的變化：容器和微服務解決了基礎設施和軟體結構的問題。API經濟學，語義網路解決了數據共享以及數據關係的問題。GitHub等軟體工程相關的公有雲解決了工程數據可用性的問題。那接下來就是用一個標準的語義格式去連接這些數據，並且做分析的問題了。雖然已經有類似OSLC的標準進行了先期探索，但是受限於數據存儲、查詢效率等各種問題的制約止步不前。從數據應用的角度看，自服務的數據使用方式也漸漸融入更多的機器學習演算法。

所以其實我們與AIDevOps的距離並不那麼遙遠了，待軟體工程管理的複雜度越來越大，智能化管理的需求越來越高，AIDevOps也許就是臨門一腳的事情。因此，我們應該有充分的信心期待軟體工程領域會出現類似AlphaGo一般的研究成果。

六、參考文獻

• Sarah Beecham，Tracy Hall, David Bowes. A Systematic Review of Fault Prediction approaches used in Software Engineering (2010).
• Huanjing Wang, Taghi M. Khoshgoftaar, Naeem Seliya. How Many Software Metrics Should be Selected for Defect Prediction? (2010).
• Javier Alonso, Llu´ıs Belanche, Dimiter R. Avresky. Predicting Software Anomalies using Machine Learning Techniques (2011).
• Martin Shepperd, David Bowes and Tracy Hall, Researcher Bias: The Use of Machine Learning
  
  in Software Defect Prediction (2012).
• Jaechang Nam , Survey on Software Defect Prediction (2014).
• Xinli Yang, David Lo, Xin Xia. Deep Learning for Just-In-Time Defect Prediction (2015).
• Song Wang,Taiyue Liu and Lin Tan. Automatically Learning Semantic Features for Defect
  
  Prediction (2016).

胡帥

普元信息高級軟體架構師，計算機軟體與理論碩士。曾供職於IBM開發實驗室，參與Rational Team Concert, Rational Insight等產品研發，曾經擔任著名開源BI產品BIRT社區顧問。為工行，招行，建行，美國通用等大型企業提供DevOps以及BI產品諮詢實施服務。在DevOps以及BI方面積累了豐富的研發與實施經驗。

關於EAWorld