七牛李倩：⼯程效率如何為研發賦能
- 工程效率是什麼？
- 工程效率如何為研發賦能
工程效率對大家來說並不是一個陳舊的概念，許多公司也成立了專門的工程效率部門，但如何更好地利用工程效率，提升研發效能呢？看七牛工程效率部負責人 & TGO 鯤鵬會上海分會會員李倩從“What、Why、How”三個角度為大家帶來工程效率方面的經驗及建議。
工程效率的 What , Why , How
對於大部分工程師而言，沒辦法把大量時間投入到寫程式碼上。除了寫程式碼，他們還要負責找 bug、上線等工作，尤其是事務性工作（比如除錯環境，和各部門溝通等雜項）。這是一個很普遍的現象，尤其是在一些達到一定體量的公司裡，這種情況很容易出現效率問題，我今天主要講組織發展篇。
第一個“What”
什麼是工程效率？
工程效率主要關注業務交付鏈條中研發交付環節的品控和效率，最核心的是縮短優質程式碼到客戶 (使用者) 交付間的距離。用一句話說就是：整個研發交付的事都要管。
工作效率到底要做什麼？
我的理念是，工程效率不只是改善一個人力的投入，更重要的是為企業建立軟體工程資訊高速公路，讓更多工程師可以專注於研發。
首先，要關注一些重要不緊急的事情。因為重要不緊急的事情，在公司發展到一定階段的時候會暴露，而且很難解決，積重難返。這裡涉及流程、工具、協作等一系列問題，它是為一個企業發展做長遠的支撐。如果一個企業認為“咱們就是為了融一筆錢把這個產品做出來，過個半年就放棄掉，那根本不用做工程效率，堆人以最快的速度做出來就好。”工程效率是到一定規模或者為一定規模的增長做基礎建設，比如發展多條產品線或者多個專案或者上百人。
第二，就是量化工程開發團隊對業務的交付能力，並且識別薄弱環節。如果不量化我們就不知道到底哪裡有問題。工程效率其實是很泛的東西，首先你的效率要可衡量，如果不可衡量哪都抓不住。我認為量化是非常重要的，量化以後你才知道哪裡是薄弱環節，然後再針對薄弱環節做提升，這裡建立業務反饋是必須的，可以幫助我們瞭解業務的缺陷、事故等健康狀態。
第三，就是向工程建設卓越的企業學習，比如 Google、Facebook 以及 Netflix。通常我們建立非常多的流程，非常多的人、組織去做很多事情。有了這些人以後就要有流程，有流程就要去協作，有協作就是人的江湖，就會出很多短板。在協作上如果出現了一個薄弱環節，就會產生木桶效應，所以我認為流程要足夠精簡。不需要的部門都應該被統籌到另外一個部門，而不是出了問題就增加一個實體。很多公司有一個監管部門不行就再建設一個監管，使得組織非常龐大，向外包專案制發展，這樣就會出現很多三權分立或者集權，牽扯到人非常複雜。所以我認為流程要足夠精簡，戰略應該足夠專注，職能部門不要太多，以業務交付為目標建立成長性的矩陣式管理組織。
第二個“Why”
舉個例子，To C 的企業像 B 站這樣成長非常快的公司，人員增長逐年成倍。七牛也是一樣的，一年增長一倍之多，這個如果體系化建設不牢是很可怕的。加人以後業務複雜度提升了，產能並不一定可以成倍提升。要更穩定的業務增長務必要把工程這一層做厚，比如多套測試環境，提升自動化程度，CI / CD 建設等。
另外一個比較大趨勢就是業務驅動的 IT，這其實是說，我們一直在做業務，以 IT 技術為中心，但是僅僅以技術為中心是不行的，要轉化為業務驅動的 IT。而對於軟體工程而言，如何以業務維度來量化各個職能的產出，也就是做企業內部的數字化轉型？舉個例子，QA 的產能怎麼樣評價？兩條業務線到底哪個產能更高？對於工程師而言，他們的技術實力代表的是他們的真實實力，而不是企業賣了多少錢代表他的實力。所以，工程師這塊需要告訴他們更多的反饋，比如覆蓋率指標，返工率情況等等，資料驅動我們不斷的提升和成長。
上圖是七牛研發場景，我們這塊已經發展七年，我們有海量的產品和程式碼。比如，我們產品線從前些年的儲存 CDN、直播到近兩年的 AI、大資料、容器雲，涉及到不止 600 個元件和微服務，還有一些行業解決方案，整個產品平臺實施的專案非常大。
面對這樣的問題，我們怎麼支撐是一個很大的問題，包括複雜的編譯環境，我們會用 Linux 、Mac、Windows。前後端、移動以及涉及語言的版本也不一樣，比如，不同語言版本在不同產品線上用的也不一樣，升級主版本也需要對比驗證，謹慎升級。
另外就是協作難度大，我們有 400 多個研發人員同時寫程式碼，分支也比較多，合併頻度以及狀態的跟蹤等等都是挑戰。對我們雲端計算公司而言，質量是我們的生命線，我們有 70 萬客戶，這 70 萬客戶都是 to B 的。比如，范冰冰正在做直播，如果我們直播服務掛掉，這是很可怕的一件事情，將影響上萬的使用者。這塊怎麼樣快速迭代？怎麼做才能又能保證質量保證效率？包括自動化 case 或者多場景的測試，都是要面對的一些實際場景。
第三個“How”
面對這些挑戰我們是怎麼做的，今天我分享兩塊務虛的東西，一個是組織發展，一個是文化建設。
組織發展這塊中，三大塊組成了我們整個工程效率的體系，這三大塊對應我們的三個子 team。
質量管理是我們的測試開發 team，分很多線，效能運營是我們效能運營中心，是一個虛擬組織，但是包含多種服務。工程賦能是我們的平臺工具組，來做整個的研發支撐。我們到底在做什麼？質量管理這塊我們 QA 的同學基本上是測試開發，還有技術專家這樣一些職能。大部分情況下，他們做全流程質量的把控，核心工作在熟悉業務，寫自動化，構建不同的場景。例如 chaos 工程來破壞雲服務，驗證其健壯性，然後也會去做客戶驗收的一些工作。
質量運營主要是關注 PMO 以及流程的產品化，還有我們整個內部系統的運維支援，還會做競品分析等。以前做直播 SDK 我們會把競品的幾家 SDK 的自動化實現了以後去觀察他們的一些效能指標。比如 ，CPU、Memory 以及丟幀或者一些實際的推流、播放的效果，會去做一些監控，這樣就可以給內部提供更多的技術改進方向，或者是看得到其他人的技術成長。
然後現在他們的 scope 擴大了，就會去做一些質量分析。比如某團隊，我們通過質效資料看到它是否有一些特性；比如通過事故統一分析下來，發現某個元件的效能非常容易出問題，技術專家會參與出專項改進方案，最終落地以及提供環境支撐等。
另外就是研發最佳實踐的傳播，比如單測或者是整合測試等做得比較好的，還有 codereview 做得比較好，都有這個組織來進行發起。近期準備組織內部的類似於效能運營活動。宗旨是主要來源於工程師，服務於工程師，讓工程師自己把好的實踐講出來，我們只是一個組織者，配合一些運營。
然後是工程師，大概都包含哪些工程師？質量管理制度我們會分幾條線，有技術線和管理線。比如，業務質量負責人類似於質量 owner，測試開發有兩個方向，一個是技術專家方面，一個業務專家方向。質效運營中心包含三部分，一個是針對測試服務的 service，一個是 PMO 負責流程設計和產品化，另外是 sre 內部平臺的運維支援
文化建設之“工匠精神、質量意識和工程文化”
文化建設篇其實寫的務虛了一點，但七牛日常也確實是這麼實踐的。
第一、工匠精神
工程師對於質量應該有極致地追求，eat your own dog food。我們的理念是：程式碼是工程師寫出來的，bug 也是他寫出來的。舉個例子，如果一段程式碼寫的不好，給他多少個 QA 都解決不了問題，所以根上仍然是工程本身的質量怎麼樣。所以我們不會把質量往下游放，而是不斷地向上游去思考，以及不會對 QA 追責，而是關注這個問題到底誰去解決成本更低。比如，一個問題如果是在 codereview 階段就應該發現，那麼就不應該到 QA 階段。
第二、質量意識
我們這塊會做大量的質量服務化工作，比如單測或者靜態掃描等，我們會做成服務化。很多時候開發同學不是不願意把程式碼寫得好，而是自己不知道寫出來到底能不能 work，我們就需要給他提供更多地支撐。比如，他不 work 的時候反饋給他原因。比如，一旦單測不過，或者說單測覆蓋達不到要求，我們會讓他看到，他會針對這個去做修改，而且是基於 Pr 級別的，秉承著“持續整合，小步快跑，快速反饋”的理念。
第三、工程文化
凡是超過兩次都要考慮自動化或者服務化實現，Everything is Code。我們 CEO 許式偉先生曾經在群裡說了一句話叫“系統性地解決一下”，這句話挺有意思也是我們日常的工程文化體現。
質效度量能力的建立與實踐成果
體系化實踐主要包括：自動化體系建立、量化驅動開發、平臺賦能交付，這裡主要看下我們的一些實踐成果。
上圖是我們實踐的一些結果，左邊是不同的產品線，右邊是我們量化出來的指標，總共有 20 多個，上圖顯示了 8 個。我們會在不同階段用不同的指標，每一個指標至少都涉及兩方，而不是特定哪個角色。比如缺陷遺失率，其實開發和 QA 都會影響，還有返工率也是兩個角色協作。
每條產品線差異很大，比如服務端和 web 應用，量化出來只是告訴你當前處於什麼水平，自己與自己以往進行比較，看得到的自我成長。當然也有的同學看到數字就很敏感，不甘低於別的產品線，就會自發找原因提升或者去請教做的好的小組，這也是比對帶來的側面效果。
上圖是一個系統測試覆蓋趨勢示意。系統測試覆蓋非常重要，它聲明瞭自動化程度和迴歸驗證的具體效果，以及進一步決策需不需要把 QA 同學更合理地安排或調整工作重心。我們曾經有一條產品線，最初有三個 QA，自動化測試達到一定程度的時候遷移了兩個同學到新產品線，隨著不斷積累，自動化程度進一步提高，剩下的一個同學還能空出一半時間做小工具開發或者效率提升的事情。通過這樣持續的自動化能力打造和充分驗證，我們更有信心釋出甚至自助驗證上線。
返工率，一定程度反應溝通成本，其實人與人協作成本很高，一段程式碼連驗證都不驗證就交到下游，下游如果發現有問題，再打回重寫再驗證，效能是很低下的，七牛在這方面控制在 15% 以下。
缺陷遺失率，即外部遺失缺陷佔整體缺陷的比率。這是傳統方法論裡一個指標，我認為也比較有價值，能證明整體的缺陷遺失情況，與返工率聯合分析可以看出 QA 的壓力和能力。
上圖是我們的質量和效率成果。在質量方面，我們現在核心服務的單測覆蓋在 60% 以上，程式碼合規率 80%，pipeline 通過率 80%。其中 pipeline 通過率就是 CI/CD 中 CD 的通過率，即從編譯部署到釋出的通過率。這裡面大部分不通過的原因，一方面是環境因素，另外一方面是自動化測試用例不穩定，還有就是本身框架支撐上的一些問題。這就相當於一個資訊高速公路，如果不通暢，就沒有信心用 pipeline。整合測試覆蓋就是 E2E+API 的整合測試，現在我們已經達到 35% 以上。
在效率方面，構建效率為 2 到 10 分鐘，這是我們 pipeline 的整個構建效率。構建效率高也一定程度因為我們採用高效的測試框架基於 golang 語言的 TDD 框架，它能實現嚴格意義的併發執行效率極高。除此之外，我們的環境可以提供多元化的平臺支撐和全套的 CD Pipeline 實現。缺陷解決率其實是一種反饋機制，就是對客戶的快速響應客戶的服務能力評估。釋出頻度每週現在已經有 60+ 了。平均故障恢復時間現在小於 1.5 個小時，重點服務小於 20 分鐘，事故率逐個季度呈現下降趨勢，已經基本上屬於高效能組織的標準中的中高階水平。Dev：QA 我們現在是 15 左右仍然在減少，當然前期會多加一些 QA 人員，目的是讓他充分了解業務轉化為可驗證的質量環節，如果 QA 不懂業務，就失去了核心競爭力。
我們知道有一門課程叫軟體工程，現在研發其實都是在做軟體工程，Devops、CI / CD 本質上還是在做軟體工程，是整體資訊化的過程。我對未來軟體工程趨勢大膽的做三個方向預測：
1、軟體工程資訊化一定會被全面完整實現，現在有很多人在做的 CI/CD 或者 devops 只是其中一部分。
2、事務型的職位將會被技術取代或者優化。比如 Ops 和 QA 會越來越少，因為技術上可以更優雅地解決和優化職能效率。
3、未來組織極有可能變成研發團隊 + 工程團隊，沒有專案經理，也沒有特別多的產品經理，很少工程師加極少量的 QA，還有一部分 SRE，包括 SRE、QA 等只要跟業務交付無關的都屬於工程團隊，做強大的技術支撐。
每個團隊都應該把自己當微服務、產品來運營。你著重需要關注彼此之間的介面 和產品介面，以及介面的質量和效率。我們把它們量化出來以後，就可以知道自己當前的水準。關於個人成長也是一種量化思維，考慮自己的評估體系，建立量化的能力，瞭解自己的優劣，去借鑑別人的成功做法和優秀經驗。
TGO 鯤鵬會是極客邦科技旗下高階技術人聚集和交流組織，目前已在北京、上海、杭州、廣州、深圳、成都、矽谷、臺灣、南京全球九個城市設立分會。現在全球累計 700 多名會員，60% 為 CTO、技術 VP、技術合夥人。
如果你想和這些優秀的科技領導者們一起前行，歡迎點選 ofollow,noindex">「報名表單，申請加入」 。