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

導(dǎo)讀

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

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

從一個(gè)小故事開始講起

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

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

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

在那個(gè)晚上，我們開始冷靜地思考一個(gè)問題：一款優(yōu)秀的商用級 SDK 應(yīng)該怎么做？

一年的努力功虧一簣

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

在最開始對接的時(shí)候，我們的產(chǎn)品質(zhì)量還不是很優(yōu)秀，幾個(gè)關(guān)鍵指標(biāo)跟競品都有差距。這倒不是問題，優(yōu)化總要有一個(gè)過程，于是我們一個(gè)迭代一個(gè)迭代地去跟進(jìn)。因?yàn)榭蛻舻陌姹景l(fā)布速度非常慢，所以我們需要在兩個(gè)版本之間都做好問題分析和優(yōu)化落地，穩(wěn)抓穩(wěn)打地慢慢降低工單率。就這樣，經(jīng)過了將近一年的時(shí)間，產(chǎn)品各項(xiàng)指標(biāo)都已經(jīng)很不錯(cuò)了，我們非常有信心在下一個(gè)版本超過友商獲得質(zhì)量上的領(lǐng)先地位。

但就在我們信心滿滿地等待客戶上線的灰度反饋時(shí)，客戶突然拋出一個(gè)問題：“你們的 SDK 有一個(gè)對音頻模塊的自動重啟邏輯，這個(gè)邏輯會在切換線路時(shí)影響到其他供應(yīng)商的音頻模塊， 這是絕對不能容忍的”。因?yàn)橐攵嗉夜?yīng)商賽馬的意義就在于保證可以有災(zāi)備，如果一家供應(yīng)商影響了其他供應(yīng)商的穩(wěn)定性，這個(gè)災(zāi)備便沒有了意義，因此客戶對我們異常失望，放量計(jì)劃無限期擱置。

面對一年的努力功虧一簣，我們開始接受一個(gè)現(xiàn)實(shí)：每位同事都可能會因?yàn)槭只肴毕?#xff0c;但對團(tuán)隊(duì)而言代價(jià)卻是難以承受的，怎么辦？

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

我們是做什么的？

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

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

面對這么多行業(yè)領(lǐng)域的客戶，有喜有憂，喜的是這是一樁很好的生意，憂的是這里有著車載斗量的壓力：因?yàn)?SDK 這種形態(tài)的技術(shù)產(chǎn)品，如果要面向企業(yè)客戶去服務(wù)，那真是打從娘胎里一出來就注定了坎坷的一生。

首先是客戶群體：

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

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

然后是產(chǎn)品形態(tài)：

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

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

最后是交付成本：

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

• SDK 版本多，平臺多，這也就意味著測試工作是海量的。就說一個(gè)細(xì)節(jié)，這么多平臺和版本，全量編譯都需要兩個(gè)小時(shí)，轉(zhuǎn)測和發(fā)版就更不用說了。

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

當(dāng)然，我們不能這么簡單粗暴，畢竟粗放型經(jīng)濟(jì)是走不遠(yuǎn)的，我們還是得從研發(fā)體系上用集約的思想去解決問題，這就是接下來要說的重點(diǎn)：從研發(fā)、產(chǎn)品、數(shù)據(jù)和排障等四個(gè)方向去認(rèn)認(rèn)真真做好一款面向企業(yè)服務(wù)的 SDK 產(chǎn)品。

研發(fā)體系的優(yōu)化

在研發(fā)體系方面，我們依然遵循騰訊倡導(dǎo)的需求評審=>技術(shù)評審=>開發(fā)=>測試的流程。但每個(gè)環(huán)節(jié)，我們都結(jié)合自身的特點(diǎn)進(jìn)行了改進(jìn)。

1. 怎么做需求評審？

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

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

2. 怎么做技術(shù)評審？

這個(gè)部分，我們一般會鼓勵(lì)大家提供兩個(gè)以上的方案，然后進(jìn)入“左右互搏”的模式。因?yàn)楹芏嗫蓯鄣耐卤旧硪彩强蓯鄣募毙宰?#xff0c;只要能早點(diǎn)寫代碼，什么都是不重要的。畢竟咱們做研發(fā)的成就感，不就來自于把功能做出來看到自己的成果嗎。

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

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

3. 怎么做代碼合入？

在代碼合入方面，我們團(tuán)隊(duì)在很早的時(shí)候就引入了一套非常嚴(yán)格的代碼評審流程，即三級評審：

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

• CR 二級：自己的 leader 來 review，這是我們整個(gè) CR 的核心基石。很幸運(yùn)團(tuán)隊(duì)有像 taopu 一樣負(fù)責(zé)和認(rèn)真的 leader，會非常細(xì)致的 review 大家的每一行代碼，并積極提出意見和建議，在 CR 中提升大家的技術(shù)水平。

• CR 三級：總監(jiān)負(fù)責(zé) review 和 代碼合入，這一步更多是抽檢，看看哪些同事是真正地愛這款產(chǎn)品，哪些同事則是不那么負(fù)責(zé)的架構(gòu)破壞者。

4. 怎么做功能測試？

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

• 怎么確認(rèn)畫面出來了？

• 怎么確認(rèn)聲音是正常的?

• 怎么構(gòu)造復(fù)雜的測試流程和測試序列?

• 怎么保證測試環(huán)境的穩(wěn)定和不被干擾?

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

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

產(chǎn)品體系的優(yōu)化

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

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

方法一：通過場景落地來驗(yàn)證產(chǎn)品質(zhì)量

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

當(dāng)然不行，所以我們自己也實(shí)打?qū)嵉亻_發(fā)了一些面向行業(yè)場景的 App（也可說是 Demo），比如合唱、語聊、教育、直播等等。并在這些場景的開發(fā)過程中，不停地尋找產(chǎn)品的問題和不足，并持續(xù)打磨，以確保在產(chǎn)品交付客戶之前，在產(chǎn)品體驗(yàn)上就已經(jīng)達(dá)到了一個(gè)很好的水平。

比如我們在開發(fā)在線合唱的場景時(shí)，就經(jīng)常有人找我問：“rex，我跟你確認(rèn)一下哈，咱們團(tuán)隊(duì)里的同學(xué)，究竟都是寫代碼的程序員，還是想要通過《我是歌手》來改變?nèi)松柠湴?#xff1f;”

方法二：通過數(shù)據(jù)體系來評估產(chǎn)品質(zhì)量

構(gòu)建一套靠譜的數(shù)據(jù)體系很重要，這就是把“文無第一”的事情變成“武無第二”。通過數(shù)據(jù)體系，讓所有的指標(biāo)都變成可以比較的數(shù)字，并且依托數(shù)據(jù)分析系統(tǒng)，不斷地提升產(chǎn)品質(zhì)量。

雖然這個(gè)思路大家都很清楚，也都在各自的產(chǎn)品中有所落地，畢竟咱們騰訊的產(chǎn)品團(tuán)隊(duì)，誰家還沒有一個(gè)負(fù)責(zé)數(shù)據(jù)運(yùn)營的同事呢？當(dāng)然有些比較大的業(yè)務(wù)，都是有自己的數(shù)據(jù)運(yùn)營團(tuán)隊(duì)的。

但還是得說，這個(gè)事情在 toB 的方向上不好做，難在兩點(diǎn)：

• 不同的客戶關(guān)注的點(diǎn)是不一樣：比如教育客戶關(guān)注的是穩(wěn)定性，電商直播關(guān)注的是清晰度，秀場直播關(guān)注的則是音質(zhì)。如果我們給一個(gè)在線教育客戶去過度地優(yōu)化畫質(zhì)，客戶不僅可能不買賬，還可能因?yàn)槲覀兊膬?yōu)化影響了其他指標(biāo)而棄用我們的產(chǎn)品。

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

數(shù)據(jù)體系建設(shè)

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

慶幸的是這方面我們還是做得不錯(cuò)的，尤其是我們團(tuán)隊(duì)一向比較在意數(shù)據(jù)，團(tuán)隊(duì)里還有一等一的聰明腦袋負(fù)責(zé)數(shù)據(jù)體系的建構(gòu)。比如我們在自己的引擎內(nèi)部的各個(gè)關(guān)鍵模塊都做了數(shù)據(jù)“掛節(jié)點(diǎn)”。這些模塊會每時(shí)每刻將近百個(gè)技術(shù)指標(biāo)以一秒一次的頻率反饋給統(tǒng)計(jì)模塊，在統(tǒng)計(jì)模塊進(jìn)行匯總之后，再實(shí)時(shí)上傳到服務(wù)器上。

基于這些海量的數(shù)據(jù)信息，僅僅靠 group by 和 count 、where 等 SQL 語句做簡單的統(tǒng)計(jì)分析是肯定沒用的，因?yàn)檫@樣的分析得不出任何有價(jià)值的信息。

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

針對這個(gè)問題，團(tuán)隊(duì)中的 xuanyi 和 yuting 兩位同事，基于對以往 badcase 的經(jīng)驗(yàn)綜合分析，構(gòu)建了一套“根因分析系統(tǒng)”，并用了將近半年的時(shí)間，不斷地打磨其準(zhǔn)確性。到目前為止，這套系統(tǒng)對于 badcase 的分析已經(jīng)接近人工挨個(gè) case 分析的準(zhǔn)確性，為團(tuán)隊(duì)節(jié)省了不知道多少人力。

排障體系

回到最初的小故事，客戶之所以懷疑我們的產(chǎn)品不是一款商用級的產(chǎn)品，最大的問題就在排障體系上。因?yàn)榭蛻粢膊皇亲罱K用戶，客戶在面對自己用戶的反饋和投訴時(shí)，往往也是很難拿到第一手信息的。如果我們將排障過程演化成了：我們 <=> 客戶<=>客戶的用戶，之間的復(fù)雜關(guān)系，這個(gè)事情就很容易引發(fā)矛盾和沖突。

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

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

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

總結(jié)

從 2016 年加入騰訊云，團(tuán)隊(duì)到今天已經(jīng)走過了五年，我們用了五年時(shí)間去學(xué)習(xí)如何做一款商用級的 SDK。雖然現(xiàn)在來說，我們做得還不夠好，但至少可以回答幾年前客戶的質(zhì)問，我們現(xiàn)在還是有信心并且有能力做好一款商用級的 SDK 產(chǎn)品的，而且不止一個(gè)。

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。