基於 Jenkins Log 秒級數據的研發效能改進

最新 04-20

作者簡介：

這是我自己的介紹，我之前在諾基亞和華為都工作過17年的時間，目前我是負責無線雲平台公共服務部門，做研發團隊的服務，跟Jenkins的定位非常接近。

前言：

在過去的17年裡邊我們碰到一個問題，就是如何不斷地做效率改進。我一直在問是不是有一些普世的方法，或者一種通用的方法能夠幫助我們的研發團隊不斷地改進效率。這是非常難的問題。在華為、諾基亞公司裡邊會有不同的方法去做效能改進，我相信各位在做的工作也有自己的方法。但是如何找區別找一個普世的？對我來說是一個非常挑戰的事情。

一、數據是第一生產力

今天我希望帶來一個目前的想法，就是可能的一種解決方案。我今天想介紹的解決方案數據是第一生產力，下面有一句話是沃德說的「使我們陷入麻煩的通常並不是我們不知道的事情，而是那些我們知道的不確切的事情」。

沃德是美國的文學家，在想想我們每個人的成長過程還是蠻符合我個人的經驗，比如說我在讀書的時候考試做不出的題一般來說是練得比較少的題目。在工作的時候寫代碼容易出錯的一般是我對需求理解不太清楚的，管理崗位上工作上出的問題可能是老闆不清楚。

大家開一下腦洞，假設有足夠多的數據會變成什麼樣子，如果有足夠多的數據每天的學習中就知道每種題型熟練程度是多少。我會知道哪一類的題會經常出錯，哪個韻母發音相對來說並不熟練。我只要做簡單的聯繫很容易提高學習成績，因為我平時成績比較忙，數據可以幫助我們很高效的工作和學習。

老闆這兒問題也一樣，假設你有足夠多的數據，你可以對老闆做一些客戶畫像、用戶畫像，你可以知道你的老闆性格是什麼類型的，如果你的老闆比較強調控制力，如果有一天跟你說這個事情交給你去辦，不用找我審批，其實你應該找我繼續審批，不應該自己做決定。

如果是一個授權性的老闆，你自己的事情了解清楚以後就可以自己做決定了。如果這個領導是自己家裡的領導，不管什麼事情都應該請示一下，要不然就不是智商的問題，而是情商的問題了。

接下來看一個具體的案例。這張圖是現在所在產品線模塊依賴關係圖，這張圖每個點表示我們一個軟體模塊，如果兩個軟體模塊之間有依賴關係就畫一條聯線。

可以看到這張圖複雜度是非常高的，我剛畫完這張圖的時候我自己也比較詫異，因為這是軟體模塊2.0的版本，1.0還沒有這麼複雜。之前我們整個產品線認知知道2.0迭代版本裡邊複雜度上升了，但是沒有人知道到底複雜度上升到什麼情況。我有這張圖之後我把圖發給工作人員，如果沒有這個數據其實針對性就會相對比較弱。

這只是我們整個諾基亞產品線裡邊很小的一部分，也只是研發過程中的很小的一部分。如果把這些圖，整個研發的流水線所有的數據都堆在一塊，可以看到是一個海量的數據，這僅僅只是大海里的一滴水而已，即使是一滴水，每個後面都對應著一個研發團隊，全球有600多個工程師。

整個研發過程數量量非常龐大，大數據技術在研發的過程上面的應用有非常多可以挖的點。今天的內容包含一些企業在日常工作裡邊具體的應用，我後面可以再具體的介紹一下。

有了這樣複雜的系統之後接下去在諾基亞內部整個研發改進的過程，可以看到水平線表現的是我們在整個數據採集過程裡邊數據的力。Y軸是定量的程度，剛開始做的時候可能跟每個公司一樣，基本上是靠專家的經驗，逐漸到第二階段，可能這些專家升級了，這些專家的經驗也比較一個KPI考核大家。

可能有些專家變成項目經理，可能變成項目的考核，或者項目計劃。我相信很多人比較熟悉的是周報或者日報，一般項目經理都會要求發一些報告，在極限情況下一般來說項目報告一天發一個已經是極限了。我碰到更多的有的項目經理要求比較高，一天發兩個，我估計項目自己也看不出來。

所以人的極限基本上就是在第三階段，到第三階段的時候，敏捷轉型過程中伴隨著整個工作的CI化，我們基本上所有的工作全部上自動化系統。這樣的話上大量的數據，數據多到沒有辦法人工的分析數據了。

所以在第四階段的初期數據是堆放在那兒，沒有做太多的應用，直到最近幾年大數據技術興起，我們有能力分析具體的數據，那個時候才開始一些新的應用。

這裡插一個段子，可以看到S軸定義時間序列的切片粒度。2015年的時候有一個伊斯頓（音）公司，當時2015年中國股災的時候惡意做空中國股市。當時伊斯頓這家公司的做法用多個帳號去做交易，買和賣同時進行，分析出一百毫秒之內的分析。

這個事件帶來一個提示，我們在數據上面有這個特性，如果你能夠看到數據的切片粒度越小，你能挖出的信息量會越大。但是它帶來數據會呈幾何數的增加，不要說從天到秒，就是分鐘到秒就差60倍，資料庫是不是支撐數據量，後台的分析會帶來非常多的技術和演算法上的要求。

二、數據採集和分析方法

所以在AI人工智慧上有三個比較關鍵的點，數據、硬體、演算法。這三個必須同時滿足，演算法和硬體早期是沒辦法解決的，直到最近幾年人工智慧的演算法才能做下一步的改進。這是比較傳統情況下的項目，這是五年前帶的團隊做的，當時我們的團隊是全球分布的，橙色部分參與了國家項目，上面的點表示在那個城市有我們的研發中心。

這兒一共有8個國家，15個研發中心，參與到一個項目裡邊，做一個產品。當時在日本上班的同事上班的時間是最少的，日本同事下班了，美國同事還沒上班。全球化的公司裡邊整個研發全球分布非常廣泛，中間產生的數據有非常大量的數據不斷地產生。而且是持續性的，因為全球時差的原因存在，第一個上班、下班，第二個還沒開始，基本上24全球滾動的研發模式，任何一刻做的數據統計都是無效的。

還有一個比較大的問題就是人為的干擾因素，相信很多公司可能也會碰到這樣的問題，我以前在華為的時候每個部門都會設一個CMO，專門做統計分析的，收集數據的人。我自己也兼任過一段時間，每天收集產品線的數據，報告給上一級，很容易出錯，因為是全手動的。手動的誤差一定存在。

還有一個比較麻煩，來自於央企或者政府部門的同學，因為有KPI的存在，大家在上報數據的時候有時候會有一些保留，不會把真實的情況完全報到上一級。雖然KPI導向稍微弱一點，但是或多或少存在，我們可能三四級。這樣帶來一個問題項目好不容易收集一個報告，但是數據跟實際情況不一定完全符合，在項目的管理上風險度是非常高的。

這個怎麼破呢？這是很現實的問題，如果沒有辦法收集到準確的數據，什麼都是白談的。這個時候我們就想到了Jenkins，剛才我提到06—08年的時候杭州的部門，所有的CI的服務都在伺服器上，我們的測試已經百分之百自動化了，基本上做到全流程都由Jenkins調度的。

這樣的話就自然而然想到Jenkins Log的採集，這個Log記錄了整個研發流程的所有數據。優點我這兒也列了，實時性非常好，Jenkins Log只要產生了就保存在Jenkins的伺服器上。Jenkins Log想去作假對人來說已經沒有能力做了，因為產生的數據太大了，滾動的速度太快了，而且廣泛的在流程裡邊嵌入。

還有一個好處很容易收集，如果你想要相關的研發數據，只要找到像我這樣的服務部門就可以了，扔個數據給我，馬上可以扔給你。今天下班前收集一份，發個報告給我，那不好意思今天負責收集數據的工作人員請假了，下周給你，你也只能哈哈一笑。Log是比較稀疏的數據，裡邊分析的難度是比較高的，因為很多時候是人工的，有很多自然語言在裡邊，要做統一分析還是有技術難度的。

價值密度相對來說比較低，真正需要的Log就在一萬行裡邊的一行，而不是說一萬行裡邊全都是有效的。你要找到那一行的Log是最難的。過去幾年我們在數據分析裡邊很難做更多的事情。右邊這張圖是目前存儲在伺服器的資料庫裡邊，可以看到最近兩個月的研發過程數據大概是3個TB，差不多就是每天5000萬條記錄。這還不是全部，只是杭州伺服器上的數據，我只是截了一個片斷。可以看到傳統技術方案裡邊伺服器能支撐的都已經很難了，對硬體資源消耗是非常大的。

我們來看看我們怎麼去解決具體問題？剛才說到我們是用Jenkins來做整個CI體系，正好接上雪峰剛才說的方案，我們頂層的調度用的是Gearman，是做一級分發的工作，我們這兒目前使用的是Docker解決方案。左側是Jenkins Master的截屏，一旦用完的話就直接刪除，就釋放回了。可以看到每一行對應到一個動態的節點，最下面表示即將被釋放出去的Step，因為任務正好完成了。

使用權動態的模式之後會帶來一些問題，大家看到各個模塊全部已經Docker化了。帶來的問題是實時性的要求比較高，因為我們要抓取整個研發過程所有的Log，Log還沒採集Step已經被釋放掉了。

最後我們參考了OpenStack的解決方案，它是一個高實時性的隊列管理的插件，做的主要工作一旦有Log產生髮一條觸發的消息出來。我們後台有一個是Log Puller模塊，一旦受到了觸發就會去抓Log。其實做的事情很簡單，抓了Log之後要做幾件事情，一個是要做所有Log數據的規劃處理，因為在後台的分析來說對數據源的格式有一定要求，後台做事情很麻煩的，要做數據清理，要做規劃，做完之後通過ERK平台存儲到資料庫裡邊。

同時大家要做一個備份，因為我們現在放到研發過程資料庫里的數據不是全量數據，部分數據暫時用不起來，但是數據量很大，我們會存儲到存儲盤上，保證將來一旦需要用的時候這些數據還是可以被查詢到的。大概從06、08年開始，之前的數據基本上還在，對研發來說這個數據是一個非常寶貴的資產，就看你怎麼用起來了。

可以看到後面應用就是十年以來大量的存儲上面，如果數據量少的話有些應用是很難做到的。可以看到我們這裡還有一個AI系統，AI系統沒具體化，AI系統用的各種框架也比較多。現在目前用的比較多的就是GOOGLE的解決方案。

最右邊這一塊就是運維繫統，我們選了比較多的解決方案，對應道不同的需求上面，我列了一些開源，開源這一塊參考的是Kibana，是目前研發體系裡邊做分析比較容易的解決方案，大家可以回去搜索一下。下面還用了Grafana，這個平台主要是伺服器資源，我們公共服務架構在IT維護的基礎架構上面，網路的問題和伺服器的穩定性對我們整個研發體系的影響還是蠻大的。

所以我們在監控整個研發團隊的開發過程之外我們還監控整個IT平台的穩定性，比如說杭州如果宕掉了，我們馬上切到芬蘭和美國，盡量對研發人員要做到透明，不用管自己設備在哪，全球任何一個機房裡邊都有可能是它的資源。

還有一個是Piwik工具，我們的客戶都是研發的內部對象，我們還是用一些互聯網公司技術，我們對研發人員做一些用戶畫像，我會知道不同類型的研發用戶使用習慣什麼樣，可以對不同類型的用戶提供更好的服務。中國的用戶和芬蘭的用戶行為習慣就是不太一樣，德國和美國的用戶又不一樣。

我們在資源的分配和整個研發生產系統設計的時候需要考慮這些因素，包括網站的使用都需要一個實時的監控。當然我們還有一些資源系統。這個平台帶來的好處是什麼？我們碰到管理上的痛點，很多的老大們會經常提我想要一個什麼數據你幫我抓一下，現在還有比較大的好處，數據和可視化是分離的。

大家如果去看一下你去配的時候是非常容易的事情，現在有很多非常資深的管理團隊的人員自己跑到我們的平台上，監控他希望看到的數據，而不是像原來傳統做法，我要找到我的團隊，你給我生成一個報告讓我看到一個數據，這樣效率很低。老大們的時間也是可以優化的，通過這個平台可以解決掉。因為在數據層這個層次已經把問題全解決了，剩下的只是排列組合，挑哪些感興趣的數據而已。通過這個平台基本上這個問題就解決掉了。

我們再看一下最後搭建網的效果。最左邊就在我座位後面搭的運維牆，上面把整個研發過程的數據都展示在那兒了。也帶來一些負作用，夏天比較熱，因為顯示器會發熱，夏天的時候把空調打得很足，因為我們是大廳，扔在一個角落裡，但是也有一個同事開玩笑這就是一個烤箱，坐在邊上的運維同事頭髮都掉光了。其實不是因為這個，已經掉光了才有了這個牆，因為研發比較辛苦。最下面是監控伺服器，可以看到伺服器響應的情況。

再往上一層，這一層我們監控的是整個研發過程中的吞吐量，整個Pipelines裡邊基於時間序列看產量的變化情況。如果做研發效能改進的比較清楚，你知道這個情況之後你會可以玩很多平衡生產線，或者做一些效率改進的事情，因為你知道整個研發流程中瓶頸到底在哪，因為哪個模塊的開發讓你的交付變慢了。你可以做這個分析。

這一塊是我們集成測試的情況，顯示的是最近三此集成測試，所有技術領域測試通過的情況。其實我們的力度可以細到每個測試，我目前可以跟蹤到所有的工作，如果我想做一些測試改進，這些數據非常容易指導我們的具體工作，我可以找出10個經常失敗的案例，找工程師談一下有沒有辦法提高穩定性。

我找軟體工程師，為什麼你的代碼在歷史上的排名出錯概率是前十名，我可以做非常有針對性的改進。最頂上這個是監控網站使用情況的數據。

三、案例分享

這張圖是傳統基於周報的分析，因為信息安全的原因，這兒所有的數據都做了一個透明的處理，最左邊寫了ABCD，其實每一行代表我們一個技術領域，每一列代表一次集成測試。裡邊的數字代表這次集成測試在對應的領域我們發現了幾個錯誤，一般寫報告的人分析到這兒就可以了，項目經理看一下這個地方紅了。

但是他可能會忽略一些東西，因為項目經理也有資深和非資深，到現在可以玩很多東西出來了，比如說中間這個圖可以做異常式分析，我可以得出兩個結論，第一個技術領域比較有高風險的，紅色和黃色這一行你可以加一塊，我知道哪幾個領域是高風險，經常出問題。這個時候可以找軟體或者測試團隊聊一聊是不是應該改進你的代碼質量了，是不是應該改進你的測試穩定性。

還有容易被忽視的全是綠色的那一行，如果你做異常式分析的話也會識別出來。原因我們看到有些行永遠是綠的，實際上去了解的話，業務上背景這幾個領域案例測試覆蓋率非常低，這也是一個異常情況，如果你的案例永遠在跑，永遠發現不了問題，永遠帶來不了價值，體現價值點就在於你發現了問題。

最右側這張圖，這張圖是我們把每次測試的通過率，如果對單次的集成來說放在一行，最左邊表示這個領域的測試是0%，最右邊表示百分之百，就可以得到散點圖。有了這張圖之後，或者有了這些數據之後可以做一個相關性分析。大家應該聽過一個故事，很多超市在賣尿布的時候發現買尿布的人經常買啤酒。最後分析出來是因為買尿布的人經常是爸爸，順便買啤酒回家。A領域的案例失敗的時候有高相關性領域的案例也可能失敗。

可以看到這張圖相關性非常複雜，如果人要做這個分析基本上不可能，除非你有非常深的業務領域的經驗。研發團隊首先分布在全球，人數也非常多，這個時候你要找資深的人在案例相關性分析上可能性非常低，因為這樣的人在公司一定像寶貴一樣，到處要救火。通過數據分析你就可以知道所有的技術領域之間相關性是什麼情況，這樣帶來什麼好處呢？

我們現在研發的工作模式是基於單創的開發，在分支開發的模式上面對質量的要求非常高。有了這個分析之後分支就可以給開發人員建議，如果沒有足夠的時間跑全量，可以跑高相關的案例。這樣的話可以把整個測試的周期，這樣的話集成的效率非常高。相關案例的概率是多少，這個時候有多少資源，有多少時間，一算就知道了，你能跑多少case。

從時間維度上可以看到下面，從分鐘級下降到秒，從小事級下降到秒。如果完成的話，至少從天降到秒。第一個是編譯的失敗，我是用隨機梯隊的演算法做錯誤分類。大家做集成這一塊經常碰到一個困難，編譯經常會掛掉，這時候我要去分析為什麼掛掉。有很多原因，很有可能是因為代碼原因，也有可能是因為環境原因，或者某一個腳本哪出問題了。

這個時候如果人工分析是很痛苦的事情，回到前面那一張，很多紅點的圖，你會發現600多個模塊都跑的話，就算能做到99%的穩定度，每天假設跑一百次編譯的話會有多少模塊失敗。

如果維護這個工作的人就會非常的煩，雖然每次已經做到很熟了，打開去看一下歷史上編譯失敗是什麼原因。而且做到最熟一分鐘的時間還是需要的。我們當時大概就選了十幾種演算法對比了一下，最後選出來是SAD的方法，目前可以做到接近百分之百的正確率，只要這個編譯失敗了我就知道這次編譯失敗的原因是什麼，如果是代碼的原因就發給軟體開發人員修復，如果不是代碼原因就發給相關的人修復。

中間這個是另一個應用，如果有測試背景經常碰到一個問題，如果一旦測試失敗我需要定位這次測試失敗的原因是什麼。一方面是個技術的問題，因為在集成測試階段要了解整個產品，培養期是非常長的，特別是剛才看到有幾百個模塊的時候，每個模塊都很熟悉幾乎是不可能的。

所以你需要花大量的時間調查失敗的原因到底是什麼。假設發現這個問題就是A和B兩個模塊有一個可能出問題了，但是在企業裡邊經常碰到A和B兩個不同的部門，兩個互相踢皮球。作為集成測試團隊來說經常碰到這個問題，最後扔到誰就是誰，先改了再說。

如果有一個方法能夠自動的找出或者大概找出測試失敗的原因，至少測試團隊裡邊是非常有效的事情。目前做了11分類的演算法，我們現在用的演算法是隨機的，這張圖我們做了一個IOC曲線評估，在這個案例歷史的數據會少一點，所以它的有效性不是太高。另外幾種分類基本上可以做到97%以上的準確率，只要失敗了我就可以知道是屬於哪個錯誤分類，只要找對應錯誤分類負責人解決就可以了。

最後這是比較有意思的項目，但是這個項目現在還在進行過程中，這個項目是我和貝爾實驗室的幾位同事在做的，因為貝爾實驗室已經被諾基亞收購回來了，去年我們把阿朗合併進來了，貝爾實驗室也加入了諾基亞。

這個同事是我和他們在搞的，現在還只是在啟動期，我們的目標是這樣，測試人員有大量的時間在日常工作裡邊寫自動化腳本，我們最終目標是只要市場或者前端把你的需求用文字描述出來，我可以自動生成所有的自動化測試腳本，這個時候我可以把大量測試人員從手動寫測試用力這個事情上解放出來。效率的提升應該是幾個數量級的提升，一半以上的測試人員都可以做其他的工作了。

當然基於幾個秒級數據更多的數據，首先是所有測試都抓進來，這個數量非常大，繼續學習演算法裡邊是非常少的。代碼的數據我們也要抓取，因為在我們內部有一個工具，所有的編譯做了一些工作之後可以讓做功能測試這一級，跑完之後我知道運行了哪些分支和哪些具體的代碼。

每個案例在各種測試場景下面覆蓋到了哪些代碼，反過來我就可以知道哪個需求在代碼上的關係。一旦有大量海量數據的時候我就知道背後有哪些代碼，當然指的是測試代碼，還不能做到把程序員替換掉。基本上做到秒級就可以做到自動化配置了。

分享的主要內容和應用就這些，回到開頭的主題，大家可以看到一旦擁有了Jenkins Log之後，在上面帶來了大量新的信息，在這上面可以做非常多的新工作。這些應用只是在日常中應用的一小部分，數據在目前或者在可見的將來可以看到對研發效率改進變得非常重要，如果各位數據還沒有開始積累，我個人建議你開始積累自己公司內部的數據，和一切想到對公司將來發展有意義的數據。