作者 | 周俊鵬
出品 | CSDN（ID：CSDNnews）
產品質量是吸引和積攢用戶的重要因素，業內不乏由微小Bug引起的災難事故，對用戶或公司造成巨大的損失。從業務角度，質量是產品口碑、市場、收益背後的助力；從技術角度，高可用性是衡量系統架構的核心指標之一。對質量的高要求並不區分產品類型，但是從研發團隊的角度上，toB產品的研發團隊更加需要強化品控的意識，尤其是平臺級toB產品。
騰訊云云開發是一個一雲多端的應用開發平臺，日調用量達7億多次。作為一個平臺級toB產品，雲開發的研發團隊又是如何做好研發品控管理，以確保交付的產品高可用呢？本文將從職能分工、研發規範、研發流程三個維度，與大家分享雲開發研發團隊的品控管理。
平臺級toB產品的質量危機和信任危機
平臺級toB產品提供的功能大多是細粒度、可組合的原子能力，B端開發者通過組合不同的能力完成業務邏輯，屬於C端應用背後的間接支撐。
toB平臺不直接接觸C端一線用戶，發生問題後需要經過二次傳導才會影響C端邏輯。這種性質決定了toB平臺在產生質量問題時與toC產品的兩個差異點：
影響面大
反饋鏈長
影響面大
以雲開發為例，B端開發者針對不同的業務模塊編寫對應的雲函數，某些雲函數也可能被多個業務模塊之間共用。一旦支撐雲函數運行的底層系統出現問題，其影響範圍可能會覆蓋多個函數，進而擴散至業務邏輯層造成無法預估的破壞。
反饋鏈長
C端用戶在使用應用程序遇到問題時可以通過客服、社區等方式反饋，很多研發團隊還會提供直接聯繫研發人員的渠道，目的是儘快收集問題並且第一時間解決。而使用toB平臺開發的應用程序如果問題的癥結在平臺本身，B端開發者則需要經過一輪排查之後進一步反饋至toB平臺的研發團隊，反饋鏈遠比toC產品更長。這從側面表明toB平臺品控的敏感和重要程度。
toB平臺的質量危機極易引發信任危機。 toB平臺作為生產工具為客戶提供價值，一旦出現質量問題，客戶對產品信任度將直線下降，產品需要恢復原有的信譽、口碑極其困難。需要時間、數據、市場等組合拳去挽留。事實上有一些toB公司就是“千里之堤潰於蟻穴”。
產品質量的把控並不僅僅是技術問題，高可用的系統架構背後同樣有流程、分工等人的因素。研發過程嚴格的品控管理是保證產品質量的必要因素。雲開發作為一款平臺級toB產品，支撐小程序、Web、移動應用等多端平臺，下面將簡單介紹這款支撐60w開發者、日均調用量7億次的toB平臺背後的研發流程管理經驗。
研發流程管理
首先介紹一下雲開發研發團隊的職能結構，一次完整的迭代流程中存在以下職能：
- 項目經理PM：負責發起需求宣講和評審，把控迭代節奏，保證在預排期時間內順利完成迭代；
- 產品FO：一次迭代需求很可能涉及多個子需求，每個子需求由指定的產品經理負責，產品FO把控主需求。產品FO往往由負責某個子需求的產品經理兼顧；
- 技術FO：同產品FO的角色類似，技術FO把控主需求，每個子需求由指定的研發人員負責。技術FO也同樣由負責某個子需求的研發人員兼顧；
- 產品經理：負責子需求的產品把控；
- 研發人員：負責子需求的技術把控 ；
- 測試人員：負責集成測試、多重回歸併且在研發人員配合下完整測試case清單的制定和審核；
- 運維人員：負責與產品和技術人員評估可能存在的風險並提前預案並實施。
金字塔形的職能結構能夠覆蓋迭代需求中的所有細節，並且由於產品FO和技術FO的總籌調度，當子需求發生未提前預估到的風險時也能夠從全局的角度及時協調各個子需求的優先級和人員分配以保證整體進度的正常推進。
研發規範：堅持“三隔離”法則
通用的研發規範分為技術和流程管理兩部分。
技術方面，為保障研發環境的安全性，相關人員需嚴格遵守“三隔離”法則，即：環境隔離、權限隔離和網絡隔離。
一、環境隔離
完整的迭代週期需要經過研發、聯調、測試、發佈流程，每個環節都分別對應不同的環境，各個環境之間的數據不能共用和混淆。
- 開發環境：即研發人員獨立的環境空間；
- 聯調環境：前後端聯調所用的環境；
- 測試環境：開發完成後集成測試的環境；
- 體驗環境：測試完成之後供產品經理體驗完整流程的環境；
- 預發環境：灰度發佈之前有一個完全仿真現網的預發環境，此環境的數據與現網共用，用來做發佈前的最後驗證和緩衝；
- 現網環境：即線上環境，發佈現網需漸進灰度。
二、權限隔離
對於涉及服務變更的需求，研發人員不能直接登錄服務所在的服務器進行變更，必須經過跳板機授權。權限的嚴格隔離是為了維護服務器的穩定性以及權限的集中管理和收歸操作。
三、網絡隔離
辦公網絡、開發網絡、公共網絡之間的可訪問權限分離，這對於IT研發來說是普遍的規範。
在流程管理方面實施以下原則：
提前預案：對迭代需求可能存在的風險進行提前預估和預案；
研發測試排期1:1：一次完整的迭代週期一般是4周，研發和測試的排期分別佔據2周。
研發流程：品控意識貫穿全流程
在整體流程上，雲開發與其他大多數研發團隊並沒有太大區別，一次迭代流程依次經過評審、研發、測試和發佈。品控意識體現在細節把控上。
需求宣講
需求宣講是發起迭代後的第一個步驟，PM發起宣講會議，有需求的產品經理們在會議中描述需求的背景、優先級、重要程度、成本以及預期等細節，所有參會者們共同對所宣講的需求進行評估，確定是否加入到本次迭代中。最終宣講結束後確定本次迭代的需求清單，進入技術評審環節。
技術評審
技術評審由項目經理發起，所有職能人員均需到場。產品經理提前建立需求單，在發起評審時進行逐行逐字描述，然後由研發人員和測試人員進行技術可行性評估，對需求描述中不清晰的地方進行討論和糾正，以及預估可能存在的風險和對應的預案。需求明確後給出研發和測試方案以及各自的排期。研發和測試的排期比例為1:1。
研發
在進入研發階段之前，測試人員需要根據本次需求產出測試案例清單，並且由研發人員和產品經理共同審閱、補充和糾正。
前後端研發人員在各自的開發環境中編寫代碼，如果涉及服務變更則需嚴格遵守環境隔離規範藉助跳板機登錄服務器。
測試
在將需求提交測試之前有兩項預備工作，缺一不可：
研發人員需要根據測試案例清單產出進行自測併產出自測報告；
產品經理需在聯調環境下體驗完整的功能和操作流程。
測試人員首先在測試環境下進行功能驗證，在此過程中研發人員和產品經理共同協助。測試完成後由研發人員將代碼部署至體驗環境，然後測試人員進行完整的案例迴歸，通過後再部署至預發環境，再次完整迴歸之後才可達到發佈標準。也就是說在測試環境需經過一次完整測試和兩次迴歸。
發佈
服務發佈需嚴格遵循漸進灰度的策略進行，SDK的發佈需要依次按照“alpha->beta->正式版”的流程推進。除此之外，功能的變更不僅僅是代碼本身，不同的產品類型往往還會涉及文檔、多渠道等周邊工作，比如服務的發佈會影響多端SDK，每個SDK的API及其對應的文檔都需要同步進行更新。所以根據服務模塊或SDK渠道進行專人專項劃分也是很有必要的。保證發佈出口的唯一性，並且在發佈之前進行嚴格的涉及工作清單遍歷。
迴歸
灰度發佈過程中和全量發佈之後，測試人員需要同步跟進對已發佈的功能進行迴歸測試，完全通過後即本次迭代結束。
雖然從整體流程上與絕大多數技術研發團隊並無二致，雲開發團隊對品控的管理意識體現在：藉助完善和嚴格的規範制度將每個環節中可能出錯的細節均通過技術和人的雙重角度進行覆蓋，很大程度上減少了質量問題的產生。
總結
計算機技術經過幾十年發展到今天，人的很多工作可以由機器協助完成甚至被完全取代。技術力量的偉大無可置疑，但人的因素同樣不可或缺。產品質量的把控容不得一絲大意，不論是技術缺失還是人為失誤。
雲開發作為一款平臺級toB產品，其高可用性背後是技術與人的雙重加持。雲開發研發團隊在提高技術能力的同時，並未忽略人在其中的偉大性，未來我們也將繼續秉承這項原則，將技術和人的雙重因素滲透至研發品控管理的每個細節之中。
作者介紹：周俊鵬，騰訊高級前端工程師，就職於騰訊云云開發CloudBase團隊，負責雲開發Cloudbase相關技術研發工作。Qcon2017講師，GMTC 2018/2019出品人，主要研究方向是前端圖形編程、工程化和web應用層架構。著有《前端工程化：體系設計與實踐》和《前端技術架構與工程》。
☞AI 時代，為什麼程序員很貴？
☞前百度主任架構師創業，兩年融資千萬美元，他說AI&新藥研發將迎來黃金十年
☞天吶，你竟然還在用 try–catch-finally
☞北京四環堵車引發的智能交通大構想
☞從Ngin到Pandownload，程序員如何避免面向監獄編程？
☞從Web1.0到Web3.0：詳析這些年互聯網的發展及未來方向
閱讀更多 CSDN 的文章
