解密螞蟻研發效能
本文整理自螞蟻金服解決方案架構師添棋在「中國DevOps社群杭州第3屆Meetup」上的分享《研發洞察：如何用資料驅動效能提升》，将圍繞決策輔助和研發輔助兩個方向，詳細講解在螞蟻金服内部如何基于AI、資料技術，洞察研發效率，提供面向一線研發和團隊TL的提效解決方案。
作者簡介
添棋
螞蟻金服 解決方案架構師
添棋，軟體研發、工程技術、系統工程專家，聚焦 ICT、金融等領域，擅長大規模、高可靠性、分布式軟體的架構、研發模式與工程技術、軟體項目管理。現負責螞蟻金服研發效能解決方案，結合 CI/CD、DevOps、大資料、AI 等相關技術，落地雲端研發體系及螞蟻研發洞察平台。
01
背景：螞蟻金服研發效能體系
1.業務特點：“快”和“穩”的平衡
螞蟻的業務兼備金融行業和網際網路行業屬性。金融的核心訴求是“穩”，因為一旦出現資金問題就會失去使用者信任，是以每次的釋出必須是高品質。而網際網路的核心訴求又是“快”，1個新特性可能需要1周甚至更早要上線，1 個嚴重問題甚至要在幾小時内完成修複。按照常識來判斷，我們知道，“快”和“穩”這兩個名額的同時達到最大化幾乎是不可能的，就像開車一樣，你想快，猛踩油門，風險就會提升。是以，要解決這個問題就需要系統性的設計，尤其是在軟體架構和研發體系上。
2.架構以及研發體系演進
随着螞蟻架構的演進，研發體系也随之逐漸更新，目前，我們的最小傳遞單元叫做“應用”，類似業界的“微服務”，一個應用的每一次傳遞都具有“小、獨、輕、松”的特點，即：
- 小：每次釋出的需求顆粒度足夠小。
- 獨：應用可獨立開發、測試、釋出。
- 輕：應用能輕量級部署、更新。
- 松：應用之間松耦合，互相影響小。
3.我們做什麼
作為螞蟻研發效能部，我們目前聚集3個領域，分别是：
- DevOps：提供一站式開放內建持續傳遞工具鍊，助力螞蟻DevOps落地。
- DevMind：研發洞察分析，依托資料和算法，驅動團隊和一線研發提效。
- DevServices：研發服務支撐，幫助一線研發快速解決日常問題。
本次分享的重點是 DevMind，即“研發洞察”的落地實踐。
02
What：問題和解決思路
列舉一些一線研發和各級 Leader 在日常工作中的常見痛點：
- 一線研發：經常把時間花在解決編譯不過、鍊路排查這類問題定位上，碰到一個沒見過的問題，經常半天的時間就搭進去了。
- 一線TL（Team Leader）：團隊同學每天都很忙，但似乎這周沒什麼産出，都遇到什麼問題了？
- 部門負責人：業務方回報我們團隊傳遞慢，到底是什麼原因？其他部門的水準又怎麼樣？
顯而易見，這些痛點并不是單純提升工具鍊效率就可以解決的，但如果放任不管，就會造成很多時間上的浪費，甚至很多 Leader 會使用各種“管理手段”嘗試解決這些問題。歸根結底，這類問題的本質是由于資訊不足，研發的資訊沒有在一線研發和 Leader 之間有效的流動，研發經驗沒有在一線研發之間很好的繼承、複用，而這類問題正是我們研發洞察需要嘗試解決的，目前的思路是這樣的：
- Step1：收集日常研發活動中所有的過程和結果資料，加工後，依托模型和算法識别問題。
- Step2：對于團隊Leader，提供效能的可視化，并把發現的問題和解決方案推薦給Leader，驅動團隊進行改進。
- Step3：通過資料挖掘和分析，找到一線研發在各個活動中的問題點，并通過用資料賦能現有的 DevOps 工具鍊，幫助一線研發提效。
下面，按照這3個步驟，依次分享一下我們的思考、方案及落地實踐。
03
How：螞蟻研發效能模型
既然要提效，那麼我們首先要回答三個問題：什麼是研發效能、螞蟻研發效能如何評估、如何先找到問題并持續調優。
1、什麼是研發效能？
“效能”這個概念本身有很多解釋，比如字面了解就是“效率*能力”或者“做正确的事+正确的做事”。比如《精益軟體度量》中總結的“價值、品質、效率、能力”。但是映射到螞蟻的實際情況，從業務對軟體研發團隊的“效能”的感覺的角度看，我們認為比較契合的還是 Capital one 的這句口号——“Deliver High Quality Working Software Faster”。
試想一下，如果把研發團隊整體看做是一個“生産工廠”，業務方最關心的就是你的這家工廠，能否持續的滿足業務需求，能否持續的做到“有品質的快”，如果能做到，那麼在此基礎上，可以再看下你的投入，自然是越低越好。
2、螞蟻研發效能如何評估？
（1）流動效率
結合螞蟻的業務架構、軟體架構和研發組織架構，把螞蟻的研發過程抽象并“具象化”，我們會得到一個類似管道一樣的模型，輸入就是原始的“業務需求”，它經過設計&拆解變為“應用需求”（也可叫微服務需求），再經過開發人員編碼實作、建構成可運作的軟體包，最後釋出到線上。
按照精益的定義，我們首先要關心“流動效率”，圍繞它定義關鍵名額。當然，這裡隐含着一個難點就是“需求粒度”，不同的需求量，傳遞的周期肯定是有差别的，而在軟體工程領域目前并沒有一個精确的方式可以衡量一個需求的“粒度”，人天、點數、代碼行無論是哪一種方法都有它的問題和局限性。至于螞蟻的解法，此處篇幅有限就不進行展開了。
（2）資源效率
資源效率指的是各環節的資源使用率和産出情況，它影響了整個“管道”的流速。具體我們又拆分為了2個關鍵的要素：
- 團隊能力：團隊中參與開發的人員的産能主要決定了開發、測試階段的效率。但是在軟體工程領域，人的産能也同樣沒有通用、科學的度量衡，是以我們就再進一步拆解為人員投入、人員能力、以及工作效率，其中比較容易觀察和衡量的就是工作效率，工作效率指研發人員使用每一個研發工具完成必要活動的效率。
- 工程能力：工程工具也是一個綜合性、複雜性的系統工程，持續傳遞流水線以及測試能力決定了在代碼在內建、驗證、釋出階段的流動效率（全自動化的前提下），研發各類輔助工具會影響研發人員的産出，而基礎設施則決定了整個工具鍊的底層效率和穩定性。但是好在，這些都是機器的事情，隻要持續的拆解，每個過程都是客觀的、可以度量的。
按照以上的了解，我們就獲得了一個分層的評估方式：
（1）價值：業務目标的達成情況，它和研發效能有一定的相關性，但是不一定存在必然因果關系。
（2）研發效率：業務直接感覺到的研發團隊的傳遞水準，業務方和研發團隊的Leader都需要關注的核心點。
（3）研發能力：決定了研發效率的關鍵因素，是團隊Leader提升效率的關鍵抓手。
3、如何先找到問題并持續調優？
基于上述的評估方式，我們可以建構一套用來評估和診斷的模型體系，幫助螞蟻的研發效能持續的提升。
此需要強調的是我們的一個基本觀點：“模型的本質是對規律的洞察，而上帝不會告訴我們規律，隻會展示給我們資料”，是以，我們雖然基于觀察和經驗建構了邏輯模型，但是會帶入大量的團隊資料并結合實際進行驗證，最終把它轉換成“基于資料建構的可驗證模型”，隻有這樣才能確定它是貼近事實的。
How：決策輔助
下面分享我們幫助團隊提效的實踐：
首先，上文中已經明确表明，在理論上并沒有統一的、有效的、科學的效能度量方法，但是不代表我們解決不了問題。理論是抽象的、基于邏輯的，它和現實的實體世界之間多少會存在差距，是以，隻要我們從實踐出發，聚焦到具體的問題上，總會有各種各樣的解決方法。
具體到效能度量這件事情上，我們可以回歸最初的目的和價值來思考，“度量”的本質其實是幫助團隊達成目标的一整套政策，如果團隊對目标有共識，那麼自然會嘗試把現實情況抽象成“度量名額”，用來牽引和評估目标的達成。基于這個思路，我們制定了三個層面的落地政策：
1、自上而下，建共識、定名額：依托“螞蟻研發效能模型”産出系統性的名額，在公司高層Leader之間達成一緻，確定各級主管對效能了解一緻，同時基于螞蟻的曆史資料和各位專家的經驗，用統計學的方式建立基線作為參考。
2、自下而上，貼場景、保落地：一個好的名額一定是能夠反映出團隊的真實情況，并且能幫助團隊解決實際問題。為了做到這一點，我們持續和螞蟻不同業務線的一線團隊開展提效試點，一方面幫助團隊解決具體問題，另一方面把積累的資料、規則和方案沉降到了研發洞察平台中。
3、平台支撐，産品化、模型化：我們研發了一款“研發洞察”産品，依托資料和模型能力，實作了名額異動的自動檢測、問題自動發現以及解決方案的自動推薦，用來服務螞蟻所有的團隊Leader，下面是我們的産品能力上的邏輯圖：
我們目前主要落地了四個場景：
（說明：下文中圖示均為示意圖，不涉及真實資料）
場景一：日常體檢
我們把效能名額的規則沉降到了産品中，讓産品能夠自動對現狀進行報告，并對異常名額進行監控和告警。基于這些規則，團隊 Leader 不僅能看到自己團隊的現狀和标準之間的對比，也可以看到和公司平均水準或其他團隊的對比。
場景二：研發效率診斷
洞察平台會以巡檢的方式持續監測團隊研發周期的短闆，推送給部門負責人，部門負責人收到通知後可直接分解到一線 TL。一線 TL 則會使用深入診斷能力，确認異常的應用、時間、問題原因和具體證據，并能夠獲得解決的方案以及其他團隊的實踐案例。（細節可以下載下傳材料，其中有相關的示範）
場景三：品質風險診斷
一般來說，研發過程中每個階段都有相應名額可以衡量品質，隻要通過簡單的多元分析和可視化就可以幫助到團隊 Leader。但是對于研發洞察來說，還需要更近一步，我們會通過關聯分析的算法，嘗試找到線上故障和研發過程各個階段品質活動之間的關系，把影響線上品質的關鍵因子提示給對應的 Leader，幫助 Leader 把問題消滅在前端。
場景四：能力診斷（工程、團隊）
工程能力的評估在 DevOps 領域已經很常見，此處不詳細說明了。但是關于團隊的能力，目前業界并沒有真正能衡量人能力的方法或實踐，我們目前的政策是通過人的産出反向關聯開發着的研發活動、行為，找到可能的改進點，把資料推送給團隊Leader，讓團隊 Leader 可以結合客觀資料主觀的判斷是否需進行改進。
比如我們可以通過研發在 IDE 上的鍵盤敲擊序列判斷編碼的時間和習慣，洞察出一個團隊的核心編碼時間，那麼這個團隊Leader就會刻意的再這段時間内保護組内的開發同學不被其他雜事打斷。
再比如我們通過研發的日常咨詢資料，洞察出一個團隊最常問的問題是哪一類，某種工具的使用還是 SDK 的使用，幫助團隊的 Leader 判斷是否要進行教育訓練或者建立内部知識庫來針對性的解決問題。
小結
在決策輔助層面，我們的核心觀點是：“不僅僅實作研發資料的可視化，而是要能通過效能領域專家的知識沉澱，直接提供效能洞察結果給非專家型的使用者”。
上圖中引用的這篇文章來自于 Evangelos Simoudis 的部落格，它完整的展示了我們建構的這個系統的本質——“專家系統”。專家系統的建構思路源于20世紀60年代，它是一個計算機程式系統，其内部含有大量的某個領域專家水準的知識與經驗，能夠利用人類專家的知識和解決問題的方法來處理該領域問題。
你可能會覺得，它似乎和當下流行的基于機器學習解決問題的思路格格不入，但是它的優勢就在于“規則的可解釋性”，簡而言之，我們的系統不僅要告訴團隊Leader問題在哪裡，更要有邏輯的闡述為什麼有問題以及問題的原因，這是目前機器學習技術不擅長做的事情。
04
How：研發輔助
接下來，繼續分享我們使用資料幫助一線研發提效的實踐，你會發現，它和上面介紹的“決策輔助”是完全不同的思路，我們的落地政策有兩個層面：
1、分析研發大資料，識别低效點：我們投入了效能領域專家和資料專家，結合基于資料思維的“資料挖掘方法”和基于邏輯思維的“工作流分析法”對螞蟻一線研發過程進行系統性的分析，找到工具鍊之外一些由于資訊問題造成的低效點。
如圖所示，螞蟻的工具鍊體系多年演進過來，不論是自動化程度、運作效率還是穩定性基本都已經達到了很高的水準，但是我們發現随着工具效率的逐漸提升，依賴人經驗和能力的環節正在逐漸成為瓶頸，比如失敗日志的定位、鍊路的排查、研發問題的咨詢等等，那麼如何能降低這部分的時間，讓一線研發更多聚焦在編碼這樣的高價值工作上，就是研發洞察中“研發輔助”要解決的問題。
2、資料賦能研發工具：針對低效點，我們會思考如何使用資料來更新對應的工具，讓工具鍊更“懂”研發，更好更精準的提供服務，具體有三個步驟：
(1) 建構研發畫像：分析人、應用的特點、活動、行為，生成标簽。
(2) 使用者需求預測：根據目前行為預測，可能遇到了什麼問題、需要什麼幫助。
(3) 智能推薦/修複：将風險&資訊提示給使用者，甚至直接幫助使用者解決。
下面簡單分享四個我們的實踐
場景一：失敗日志定位
我們通過研發資料分析發現，同樣一個失敗日志，有人 1 分鐘定位，有人要花 30 分鐘，這裡面的差異就是人和人經驗上的差距。
我們通過聚類發現，所有流水線上的失敗日志，大概可以分為 14 個大類 96 個小類，而 90% 以上的失敗日志都是有解決方案的，是以我們建構了日志的知識庫賦能給了日志平台，實作了精準診斷和解法推薦。
這樣一來，當一線研發點選失敗日志後，會直接看到失敗日志的行号以及如何解決這個錯誤（如圖所示）。落地至今，平均每天可以命中數以萬計的失敗日志，并可為其中 94% 的失敗推薦方案，為每一個遇到流水線失敗的使用者每天每人節約 28.5 分鐘的時間。
場景二：鍊路排查
衆所周知，在分布式、微服務架構下，系統的鍊路調用關系錯綜複雜。對于線上運維來講，由于業務規則比較确定，通常可以用 AIOps 的思路來解決，但是在研發過程中，一線研發在自測試、聯調過程中的問題定位，由于面臨很大的不确定性，仍然需要在複雜的調用關系中進行人肉排查。
對此，我們建構了一個研發鍊路的規則庫和知識庫，賦能給鍊路排查工具，規則庫可以繼承上線診斷規則以及線下研發的曆史排查規則，知識庫則是記錄每一個命中問題對應的團隊解決經驗。這樣一來，當開發同學輸入一個問題鍊路 ID 時，工具會直接鎖定問題節點，并将團隊已經處理過的經驗連結推送過去，大大降低了問題排查時間。
場景三：代碼送出風險提示
很多時候，一線研發會因為擔心風險不敢輕易的頻繁送出代碼，這也是問題常常遺留到後期的原因之一，如果能在每一次送出的時候，把影響性知會到他，那麼他會很願意把問題提前消除掉。
在這個實踐中，我們通過分析送出的代碼變更判斷對線上業務的影響，并根據業務的使用量、調用量、關鍵程度等資料，判斷風險，推送給一線研發，并監控這些風險在釋出前的閉環情況。在實際落地中，我們發現有超過 50% 的風險在代碼入主幹之前被消除掉，一線研發通過自動化或者手工驗證的方式盡可能的對未覆寫過的代碼進行了充分的驗證。
場景四：研發咨詢
如圖所示，這是一個智能答疑機器人，在每個研發工具的右下角都會有一個入口，當研發過程中遇到問題時，點開，可以看到“猜你想問”，這是我們對他目前可能遇到問題進行預測，如果未命中，我們的答疑機器人就會根據開發的提問，進行對應的方案推送。
在這個領域，如果用一個詞來描述我們的願景，那麼就是“AI Dev”，我們希望依托資料和算法把傳統的 ”被動輔助工具“轉換為“主動智能工具”，讓研發工具鍊更”懂“研發，為一線研發實時的提供更高效的優質服務。
總結：智能化之路
最後，大家心中可能還有疑惑，講了這麼多場景，“研發洞察”似乎無處不在，它做了這麼多事情，那麼它的“實體”到底是什麼，又由哪些關鍵技術組成呢？
研發洞察其實是一個“以提效為中心，融合研發全領域知識和模型的智能洞察平台”。
把它展開來，簡單看一下它的内部結構：
在系統建設上，平台底層有兩項關鍵技術：
(1) 研發效能統一資料中心：從螞蟻研發工具的源資料中提取資料，一方面使用“阿裡大資料”體系的方法論進行模組化形成了分析型資料倉庫，另一方面使用資料挖掘技術建立了特征工程，形成了人和應用的研發畫像。
(2) 研發領域算法模型：基于人工抽象或機器學習算法建構的“學件”，主要包括一些可解釋性規則庫、基于機器學習的識别/比對模型、基于NLP的研發語料模型等等。
在核心能力上，我們對上層提供 3 個中台服務，分别對應了問題的發現、定位和解決。
在使用者場景上，面向團隊 Leader，我們提供了一款資料産品“研發洞察”，面向一線研發，我們将中台能力賦能到現有工具鍊上，期望在不改變工具使用習慣的情況下，默默的幫助研發同學提升效率，達到潤物細無聲的效果。
最後，無論是研發洞察平台本身還是我們要解決的問題域，都是一個複雜的系統工程，是AI、大資料、軟體工程、組織行為學、研發工具鍊等多個領域的綜合應用，在理論、技術還是落地實踐上都需要持續的探索，我們也希望更多的領域專家和技術專家能加入我們，一起迎接挑戰，打造業界領先的研發體系和實踐。