作者：rexchang，騰訊 CSIG 客戶端開發工程師

導讀

我在 2008 年進入公司后，做的一直是面向 C 端用戶的客戶端產品—QQ，產品的可測性是很強的，雖然功能很多，但我們測試團隊總是能成為產品質量的堅強后盾。2016 年我們團隊加入騰訊云之后，依然在客戶端方向，但所做的產品已經不再是一款軟件，而是一套音視頻通信領域的 PaaS SDK，即 TRTC SDK 和 IM SDK。

相比于 QQ 只需要做好一款 App，我們要面對的是服務好幾千個客戶的 App，而于此同時，測試資源又是有限的。在這種情況下，如何確保產品質量呢？

從一個小故事開始講起

在幾年前我們剛開始做 ToB 的 SDK 的時候，曾經對接過一家做社交 App 的公司，對方的技術負責人很年輕也很務實。在商務大哥給力的努力下，客戶成功完成了產品的接入，并進入線上灰度階段。

然而，在開始灰度的那天晚上，線上用戶出現了很多消息延遲大的投訴，用戶的一條消息需要很長時間才能發出去。客戶雖然對我們很失望，但依然很努力地在配合我們排查和修復問題。

在兩天的時間里，我們給客戶改進了多個版本，每次給版本的時候我們都說“已經找到問題了，這個版本肯定可以”，但每次效果都不理想。兩天之后，客戶的技術負責人很嚴肅地詢問了我們一個問題：“從這兩天的排障過程和修復過程來看，我想確認一下你們這是一款商用級的產品嗎？”

在那個晚上，我們開始冷靜地思考一個問題：一款優秀的商用級 SDK 應該怎么做？

一年的努力功虧一簣

最近教育行業被政策打壓地非常厲害，但在兩年前，這是個 PaaS 服務的兵家必爭之地。我們有一家做在線英語教學的客戶，一直在對接我們的 TRTC。這個客戶對質量要求非常苛刻，他們很早便引入了賽馬機制，將多家 PaaS 服務商拉入到自己的供應商集群，互為災備，并進行質量評估，看誰的質量好就用誰的產品。

在最開始對接的時候，我們的產品質量還不是很優秀，幾個關鍵指標跟競品都有差距。這倒不是問題，優化總要有一個過程，于是我們一個迭代一個迭代地去跟進。因為客戶的版本發布速度非常慢，所以我們需要在兩個版本之間都做好問題分析和優化落地，穩抓穩打地慢慢降低工單率。就這樣，經過了將近一年的時間，產品各項指標都已經很不錯了，我們非常有信心在下一個版本超過友商獲得質量上的領先地位。

但就在我們信心滿滿地等待客戶上線的灰度反饋時，客戶突然拋出一個問題：“你們的 SDK 有一個對音頻模塊的自動重啟邏輯，這個邏輯會在切換線路時影響到其他供應商的音頻模塊， 這是絕對不能容忍的”。因為引入多家供應商賽馬的意義就在于保證可以有災備，如果一家供應商影響了其他供應商的穩定性，這個災備便沒有了意義，因此客戶對我們異常失望，放量計劃無限期擱置。

面對一年的努力功虧一簣，我們開始接受一個現實：每位同事都可能會因為手滑引入缺陷，但對團隊而言代價卻是難以承受的，怎么辦？

回到正題，接下來我會介紹一下過去的這些日子里，我們怎么去應對這個問題。不過在此之前，我需要先介紹一下我們的產品：

我們是做什么的？

我們團隊所開發的是一套面向企業級客戶的 SDK，包括用于實時音視頻通訊的 TRTC SDK；用于消息通信的 IM SDK；用于直播推流和播放的 LIVE SDK ；以及用于短視頻錄制和編輯的 UGC SDK。

產品面向的客戶群很多：有做泛互聯網行業的，比如在社交領域長期霸榜蘋果應用商店的某知名 App；也有在線教育領域的很多知名機構，教學模式包括 1V1、小班課、大班課等等；也有金融和保險領域的巨無霸，他們會使用我們的產品將現有的業務盡快地跟互聯網融合；還有各行各業的中小型企業，他們雖然可能并不出名，但確實支撐我們國家互聯網經濟持續繁榮的基石；對了，還有做畢業設計的學生，雖然他們不會付費，但保不齊人家會在畢業后給自己的老板推薦我們的產品呢。

面對這么多行業領域的客戶，有喜有憂，喜的是這是一樁很好的生意，憂的是這里有著車載斗量的壓力：因為 SDK 這種形態的技術產品，如果要面向企業客戶去服務，那真是打從娘胎里一出來就注定了坎坷的一生。

首先是客戶群體：

• 客戶所屬行業分布廣，教育、泛互、金融，不同的客戶對產品的需求差異性大。

• 客戶接入周期長，大客戶在接入過程中會不斷追加新需求和新特性，與此同時，客戶對交付周期要求又很苛刻。

然后是產品形態：

• SDK 對專業性要求是比較高的，別人家的客戶都只需要理解 http 的 get 和 post 就行了，俺們家的客戶就得知道多線程安全、內存泄漏、前后臺切換，蘋果隱私合規要求，還有 android 的 gradle 配置方法和 windows 的 stl 兼容問題...

• 涉及平臺眾多，iOS、Android、Windows、Mac、Web，每個方向都需要很長時間的積累和沉淀。同時，在微信的強大的影響力面前，我們又增加了一個新的平臺——微信小程序。

最后是交付成本：

• SDK 完成接入后，成不成要依賴客戶的最終反饋，但往往客戶的反饋周期很長，迭代周期也很長。

• SDK 版本多，平臺多，這也就意味著測試工作是海量的。就說一個細節，這么多平臺和版本，全量編譯都需要兩個小時，轉測和發版就更不用說了。

面對這個問題，我們的友商做法是：加人。

當然，我們不能這么簡單粗暴，畢竟粗放型經濟是走不遠的，我們還是得從研發體系上用集約的思想去解決問題，這就是接下來要說的重點：從研發、產品、數據和排障等四個方向去認認真真做好一款面向企業服務的 SDK 產品。

研發體系的優化

在研發體系方面，我們依然遵循騰訊倡導的需求評審=>技術評審=>開發=>測試的流程。但每個環節，我們都結合自身的特點進行了改進。

1. 怎么做需求評審？

首先是需求評審，我們團隊經過這幾年的打拼，總結出來最關鍵的一個點，就是看需求一定要看客戶背后的意圖。有時候客戶會跟你說：“我想要你給我增加一個設置視頻分辨率和碼率的接口”。這個時候你要不要加呢？如果我們只是看客戶的需求，那是要加的。但如果我們再問問，“您為什么需要我們加這個接口呢？” 那客戶可能就會跟你說：“我覺得你們的畫質不行，不夠清楚，我要自己調，我要調清楚一點。” 這個時候我們就明白了，我們的需求不是“去增加一個可以設置視頻分辨率和碼率的接口”，而是去“提升我們的畫質以滿足客戶的需求”。

這兩者是不對等的，因為前者客戶可能認為只要分辨率調到 4K 就是清晰的，但客戶可能誤以為“清晰度”就等同于“分辨率”，所以往往會指定一個 4K 的分辨率，卻配置了一個 40Kbps 的視頻碼率。懂音視頻的朋友都知道，這樣的畫面是模糊地沒法看得。所以我們在簡單版的 API 接口中，都不開分辨率設置接口，而僅僅是提供一個畫質等級的接口，以避免客戶的錯誤配置。但我們在得知客戶的意圖之后，會去了解客戶為什么覺得我們畫質不行，是跟哪款產品比有差距。進而分析是提升顏色矩陣轉換的精度，還是在前處理的最后增加一道銳化，還是視頻分辨率不匹配顯示分辨率導致的問題，還是 OpenGL 的線性變換和就近變化的差異問題。

2. 怎么做技術評審？

這個部分，我們一般會鼓勵大家提供兩個以上的方案，然后進入“左右互搏”的模式。因為很多可愛的同事本身也是可愛的急性子，只要能早點寫代碼，什么都是不重要的。畢竟咱們做研發的成就感，不就來自于把功能做出來看到自己的成果嗎。

但我們也不斷地告誡自己，我們究竟是做“一票子買賣”還是是“百年老店的生意”。如果是前者，那大可以想到哪里代碼就寫到哪里；但如果是后者，則需要我們綜合考慮多個方案，選擇更能可持續發展的方案。

要知道在 ToB 這個領域，我們一不注意就會把自己陷入到做定制需求的套路里。面對業務壓力，一開始這樣是很解渴的，但隨后的維護成本就讓自己徹底吃不消了，每天除了救火什么都干不了的團隊，也就失去了創造新價值的能力。

3. 怎么做代碼合入？

在代碼合入方面，我們團隊在很早的時候就引入了一套非常嚴格的代碼評審流程，即三級評審：

• CR 一級：模塊的維護者來 review，這一級的目的是讓模塊的穩定性能夠得到保障。畢竟在別人家的田間地頭種自己的莊稼，你總不能背著這塊地的主人搞小動作不是。

• CR 二級：自己的 leader 來 review，這是我們整個 CR 的核心基石。很幸運團隊有像 taopu 一樣負責和認真的 leader，會非常細致的 review 大家的每一行代碼，并積極提出意見和建議，在 CR 中提升大家的技術水平。

• CR 三級：總監負責 review 和 代碼合入，這一步更多是抽檢，看看哪些同事是真正地愛這款產品，哪些同事則是不那么負責的架構破壞者。

4. 怎么做功能測試？

最近半年在測試團隊，尤其是 svein 和俊哥的大力支持下，我們的自動化測試進步極大。不管是 native sdk 還是 webrtc sdk，自動化測試都能覆蓋掉很多刁鉆和難以手工覆蓋的部分。比如一次通話過程中幾十次的“進進出出”，或者是頻繁的切換某個狀態，這些都是以往手工測試很容易把人逼瘋的部分。益于測試團隊的持續投入，目前我們的自動化測試系統已經小有成績。要知道，構建一個面向音視頻功能的自動化測試體系，那難度可是非常高的。仔細想想就知道這里面有多少破事兒要解決：

• 怎么確認畫面出來了？

• 怎么確認聲音是正常的?

• 怎么構造復雜的測試流程和測試序列?

• 怎么保證測試環境的穩定和不被干擾?

• 還有最艱苦的：怎么找到足夠多又耐操的手機，尤其是水果牌的。

通過需求評審、技術評審、代碼審查和自動化測試的多重保護，我們最近已經很久沒有再發生前面說的第二個故事里的事情了。即使有些同事一時手滑引入了一些問題，也大都能在 SDK 交付前得到暴露，只是目前我們并不能將這個概率降低到 0% 而已。

產品體系的優化

作為一款自身不帶界面的 SDK，要做到產品體系的優化，就只能去優化技術本身，但這是枯燥且不好度量的。俗話說得好，“文無第一，武無第二”，說的就是評判標準的問題。這就好比你畫一幅畫，如果沒有老師指點你怎么才算好，那就會很難度量自己這段時間是水平提高了還是退步了。不然人家丟勒一個德國人，干嘛兩次跑到意大利的威尼斯去學畫畫；又不然怎么會出現很多畫家都是在那啥之后才有人開始欣賞他們的作品的呢？

所以說，作為一款面向 ToB 客戶的 SDK 產品，要提升產品質量，就得有一些手段和方法，我們是這么做的：

方法一：通過場景落地來驗證產品質量

我們做 TRTC SDK，我們的客戶拿 TRTC SDK 的能力去做合唱，去做 K歌，去做語音聊天室，去做視頻直播。那我們就只是做好自己的一畝三分地嗎？

當然不行，所以我們自己也實打實地開發了一些面向行業場景的 App（也可說是 Demo），比如合唱、語聊、教育、直播等等。并在這些場景的開發過程中，不停地尋找產品的問題和不足，并持續打磨，以確保在產品交付客戶之前，在產品體驗上就已經達到了一個很好的水平。

比如我們在開發在線合唱的場景時，就經常有人找我問：“rex，我跟你確認一下哈，咱們團隊里的同學，究竟都是寫代碼的程序員，還是想要通過《我是歌手》來改變人生的麥霸？”

方法二：通過數據體系來評估產品質量

構建一套靠譜的數據體系很重要，這就是把“文無第一”的事情變成“武無第二”。通過數據體系，讓所有的指標都變成可以比較的數字，并且依托數據分析系統，不斷地提升產品質量。

雖然這個思路大家都很清楚，也都在各自的產品中有所落地，畢竟咱們騰訊的產品團隊，誰家還沒有一個負責數據運營的同事呢？當然有些比較大的業務，都是有自己的數據運營團隊的。

但還是得說，這個事情在 toB 的方向上不好做，難在兩點：

• 不同的客戶關注的點是不一樣：比如教育客戶關注的是穩定性，電商直播關注的是清晰度，秀場直播關注的則是音質。如果我們給一個在線教育客戶去過度地優化畫質，客戶不僅可能不買賬，還可能因為我們的優化影響了其他指標而棄用我們的產品。

• 音視頻的表現不是簡單地靠 DAU、成功率來衡量的。比如“切課率”這個指標，影響因素非常多，比如網絡波動呀，硬件發熱呀，麥克風阻抗大呀，顯卡驅動不匹配呀，還有可能是用戶心情不好砸鍵盤呀。就說我們有個客戶，發現上課的聲音效果不好，結果客戶很負責，親自到了學生家去確認，最后發現是 iPad 的保護套把麥克風給遮住了，你說這找誰說理去？

數據體系建設

面對上述挑戰，我們還是得從技術角度去解決問題，畢竟靠堆人是不行的，這生意得做出毛利率才能長久地堅持下去。

慶幸的是這方面我們還是做得不錯的，尤其是我們團隊一向比較在意數據，團隊里還有一等一的聰明腦袋負責數據體系的建構。比如我們在自己的引擎內部的各個關鍵模塊都做了數據“掛節點”。這些模塊會每時每刻將近百個技術指標以一秒一次的頻率反饋給統計模塊，在統計模塊進行匯總之后，再實時上傳到服務器上。

基于這些海量的數據信息，僅僅靠 group by 和 count 、where 等 SQL 語句做簡單的統計分析是肯定沒用的，因為這樣的分析得不出任何有價值的信息。

比如一次糟糕的通話體驗，可能出現過一次 2s 的卡頓，但是這些數值如果僅僅是用來做大盤平均分析，那這次 2s 的卡頓就“淹沒”在了海量的通話數據里，你拿到的最終的平均值甚至不會有小數點上的一個波動。

針對這個問題，團隊中的 xuanyi 和 yuting 兩位同事，基于對以往 badcase 的經驗綜合分析，構建了一套“根因分析系統”，并用了將近半年的時間，不斷地打磨其準確性。到目前為止，這套系統對于 badcase 的分析已經接近人工挨個 case 分析的準確性，為團隊節省了不知道多少人力。

排障體系

回到最初的小故事，客戶之所以懷疑我們的產品不是一款商用級的產品，最大的問題就在排障體系上。因為客戶也不是最終用戶，客戶在面對自己用戶的反饋和投訴時，往往也是很難拿到第一手信息的。如果我們將排障過程演化成了：我們 <=> 客戶<=>客戶的用戶，之間的復雜關系，這個事情就很容易引發矛盾和沖突。

所以我們在接受了早期的失敗教訓之后，就勵精圖治建設了一套商業級的排障系統。經過這幾年的努力，這套系統已經越來越強大了，也承載了越來越多的能力。目前已經能夠做到分析過去兩周內任何一個用戶的任何一次體驗問題，并能夠定位到技術層面的缺陷或者環境方面的問題。

于此同時，在線日志和離線日志系統的雙重保障，也讓排障的信息變得更加容易獲取。以往比較困難的線上死鎖問題和調用時序問題，也開始不再那么可怕和束手無措。

當然，面對這么多的客戶，靠一個團隊的人力是不可能搞定數千個客戶的技術支持和售后服務的，靠兩個也不行。不過作為一款騰訊云上的老產品，我們的 TRTC 和 IM 很早就接入了騰訊云的安燈系統。借助安燈的問題跟蹤和信息流轉能力，中小客戶的問題也得到及時的處理和沉淀。

總結

從 2016 年加入騰訊云，團隊到今天已經走過了五年，我們用了五年時間去學習如何做一款商用級的 SDK。雖然現在來說，我們做得還不夠好，但至少可以回答幾年前客戶的質問，我們現在還是有信心并且有能力做好一款商用級的 SDK 產品的，而且不止一個。

騰訊程序員視頻號最新視頻

總結

以上是生活随笔為你收集整理的如何做一款面向企业客户的商用级 SDK的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。