隨著互聯(lián)網(wǎng)的快速發(fā)展，大數(shù)據(jù)與軟件質(zhì)量的關(guān)系越來越密切，從源碼撰寫、持續(xù)集成、測試調(diào)試、發(fā)布運(yùn)營，整個(gè)流程中大數(shù)據(jù)無所不在。每個(gè)數(shù)據(jù)關(guān)聯(lián)起來對軟件質(zhì)量中的發(fā)現(xiàn)、度量、定位都有著重要的價(jià)值。如何從 0 到 1 建立基于大數(shù)據(jù)的質(zhì)量平臺，利用大數(shù)據(jù)來改善軟件質(zhì)量？

來自阿里巴巴優(yōu)酷事業(yè)部技術(shù)專家萬傳奇老師將在 4 月 20 - 22 日召開的 QCon 全球軟件開發(fā)大會上分享優(yōu)酷大數(shù)據(jù)質(zhì)量平臺建設(shè)及線上質(zhì)量閉環(huán)解決方案實(shí)踐。在大會開始前，我們有幸采訪了萬傳奇老師，提前了解一下優(yōu)酷大數(shù)據(jù)質(zhì)量平臺建設(shè)背后的技術(shù)故事。

萬傳奇（花名“萬眾”），阿里巴巴優(yōu)酷事業(yè)部技術(shù)專家。2014 年進(jìn)入阿里，負(fù)責(zé)阿里集團(tuán)持續(xù)集成平臺 CISE 、AONE 實(shí)驗(yàn)室等開發(fā)工作，支撐集團(tuán)所有事業(yè)部的測試任務(wù)。并通過整合集團(tuán)測試工具插件化，中間件 Docker 化等核心工作，積累了豐富的測試經(jīng)驗(yàn)。

2017 年開始，全面負(fù)責(zé)優(yōu)酷質(zhì)量部平臺建設(shè)工作，建立起以大數(shù)據(jù)為基礎(chǔ)的視頻質(zhì)量保障體系，高效結(jié)合了實(shí)時(shí)度量、監(jiān)控、灰度、告警、定位、分析等多項(xiàng)功能，形成一套完整質(zhì)量保障解決方案，成為優(yōu)酷業(yè)務(wù)線以及阿里相關(guān)多媒體質(zhì)量唯一標(biāo)準(zhǔn)。

隨著優(yōu)酷技術(shù)棧和阿里不斷整合，各客戶端埋點(diǎn)數(shù)據(jù)參照集團(tuán)的方式全部上報(bào)，但對于數(shù)據(jù)的使用，大家多是寫個(gè)離線 SQL ，或者部分?jǐn)?shù)據(jù)對接集團(tuán)各個(gè)橫向服務(wù)平臺來使用。從優(yōu)酷業(yè)務(wù)線角度看，沒有一個(gè)垂直的大數(shù)據(jù)平臺來支撐各業(yè)務(wù)線，嚴(yán)重影響開發(fā)的效率以及數(shù)據(jù)對業(yè)務(wù)本應(yīng)有的強(qiáng)力支持?；谶@個(gè)背景，團(tuán)隊(duì)臨危受命，開始了大數(shù)據(jù)平臺的開發(fā)工作。

從技術(shù)角度來說，優(yōu)酷大數(shù)據(jù)質(zhì)量平臺搭建分為三大部分：實(shí)時(shí)、離線、檢索。

• 實(shí)時(shí)框架我們選擇了 Blink（ Flink ）和 Spark Streaming ，兩個(gè)框架都能很好處理實(shí)時(shí)需求，我們在 ETL 層面選用了 Blink ，數(shù)據(jù)計(jì)算部分選用了 Spark；

• 離線部分依托 ODPS 平臺，這個(gè)平臺相對功能強(qiáng)大，適合新人上手，簡單的 SQL 就能滿足業(yè)務(wù)需求；

• 檢索部分我們主要依賴 ELK 技術(shù)，并將數(shù)據(jù)存儲在 OTS （ HBase ）和 ElasticSearch 中用來進(jìn)行實(shí)時(shí)離線度量數(shù)據(jù)查詢，也包括了上面說的聚合查詢、全文檢索等。

在平臺搭建過程中遇到不少“坑”，我們也總結(jié)了一些經(jīng)驗(yàn)，主要分為以下兩點(diǎn)：

1. 成本

在開發(fā)之前，需要考慮兩個(gè)成本問題：費(fèi)用成本和人力成本。

大數(shù)據(jù)是特別耗費(fèi)資源的，如果這方面不加以控制，產(chǎn)品的性價(jià)比就大打折扣，結(jié)合優(yōu)酷大數(shù)據(jù)平臺的經(jīng)驗(yàn)，這塊一定要強(qiáng)關(guān)聯(lián)業(yè)務(wù)，比如說在數(shù)據(jù)預(yù)計(jì)算處理的時(shí)候，需要考慮可選維度或必選維度，亦或是哪些維護(hù)可以合并處理，這樣在存儲上能夠極大節(jié)省空間。在離線計(jì)算過程中，如何抽象出中間表，降低計(jì)算復(fù)雜程度，節(jié)省計(jì)算資源。

再說人力成本，這個(gè)在中后期表現(xiàn)特別明顯，隨著平臺發(fā)展，業(yè)務(wù)方的需求源源不斷涌入，從鏈路上要對接數(shù)據(jù)、數(shù)據(jù)計(jì)算、存儲、后端接口封裝、前端展現(xiàn)等一系列開發(fā)工作，這就需要我們明確數(shù)據(jù)格式規(guī)范、對各環(huán)節(jié)的計(jì)算邏輯抽象，支持靈活的配置化工作等，有了通用化作為前提，大數(shù)據(jù)平臺同學(xué)就可以專注鏈路架構(gòu)上的優(yōu)化，業(yè)務(wù)同學(xué)深度參與進(jìn)來，這樣非常有利于平臺的迭代。

2. 盲目調(diào)參

常規(guī)的參數(shù)調(diào)優(yōu)，這是大數(shù)據(jù)工程師必須經(jīng)歷的。對于初次進(jìn)行大數(shù)據(jù)平臺開發(fā)的同學(xué)，建議大家不要盲目調(diào)參，要看是哪個(gè)環(huán)節(jié)出現(xiàn)了瓶頸，是網(wǎng)絡(luò)問題，計(jì)算資源問題，還是數(shù)據(jù)傾斜問題等，針對性的進(jìn)行參數(shù)調(diào)整，效率會更快。

測試領(lǐng)域有過幾個(gè)明顯階段，手工測試、自動化測試、再到持續(xù)集成，其實(shí)不外乎在追求更高的質(zhì)量，更快的研發(fā)效率。但隨著移動互聯(lián)網(wǎng)高速發(fā)展，對于質(zhì)量的要求要遠(yuǎn)遠(yuǎn)高于 PC 時(shí)代，測試人員的能力也需要隨之提升，不僅要對接常規(guī)的開發(fā)測試需求，還要關(guān)注產(chǎn)品效果、線上運(yùn)維情況等，也就是說測試領(lǐng)域未來需要復(fù)合型人才。

我們都知道現(xiàn)在的移動互聯(lián)網(wǎng)產(chǎn)品迭代速度很快，各類設(shè)備的測試都要涵蓋到，單從通用的測試角度來說，就要考慮 APP 啟動時(shí)間、頁面響應(yīng)時(shí)間、頁面滑動流暢度、崩潰、卡頓、功耗 等等，測試成本非常高，甚至大多數(shù)時(shí)候又回到了手工測試去驗(yàn)證。那么大數(shù)據(jù)能為測試帶來哪些幫助？

首先，我們將業(yè)務(wù)關(guān)注的數(shù)據(jù)進(jìn)行埋點(diǎn)，可以是功能、性能、用戶體驗(yàn)、用戶行為等等，這樣就保證了我們測試的結(jié)果和用戶感受基本一致，釋放了大部分的常規(guī)測試手段，如 UI  、性能、接口等。

其次，我們將數(shù)據(jù)流程分成：線下、灰度、線上三個(gè)階段進(jìn)行保障，逐級利用真實(shí)設(shè)備的數(shù)據(jù)來保證質(zhì)量，間接釋放了多機(jī)型測試不充分的問題。拿優(yōu)酷播放卡頓指標(biāo)問題來說，用戶觀看視頻出現(xiàn)一個(gè)等待圓圈開始到結(jié)束，就是一次卡頓，此時(shí)數(shù)據(jù)埋點(diǎn)紀(jì)錄這個(gè)卡頓時(shí)長并上報(bào)到大數(shù)據(jù)平臺。這樣大數(shù)據(jù)平臺就可以對這一指標(biāo)做出各類質(zhì)量方面的工作，比如：

• 一次播放中出現(xiàn)了多少次卡頓、卡頓平均時(shí)長是多少

• 卡頓超過多少的時(shí)候會導(dǎo)致用戶退出 App

• 卡頓分布在哪個(gè)網(wǎng)絡(luò)是否有故障

• 新上線的版本卡頓是否有增加

對應(yīng)大數(shù)據(jù)質(zhì)量平臺的功能，就大致分為實(shí)時(shí)度量、監(jiān)控告警、數(shù)據(jù)分析、定位排查、灰度驗(yàn)證等幾大部分。

傳統(tǒng)的監(jiān)控手段，對于服務(wù)器性能指標(biāo)、調(diào)用鏈路等已經(jīng)相對成熟，一般發(fā)現(xiàn)異常就能夠確定原因。在移動互聯(lián)網(wǎng)時(shí)代，質(zhì)量這個(gè)詞涵蓋的不單單是線上的故障，更多的是體驗(yàn)。如果讓用戶感知的問題發(fā)現(xiàn)不及時(shí)或者沒有發(fā)現(xiàn)，所有的努力都會付之東流。

所以我們的重頭放在了客戶端埋點(diǎn)數(shù)據(jù)上，把播放體驗(yàn)相關(guān)的埋點(diǎn)數(shù)據(jù)（卡頓、播放成功率）、性能指標(biāo)數(shù)據(jù)（啟動時(shí)間、 Crash ）、關(guān)鍵服務(wù)返回?cái)?shù)據(jù)（ CDN 節(jié)點(diǎn)數(shù)據(jù)）、用戶行為數(shù)據(jù)（點(diǎn)擊行為、停留行為）等進(jìn)行分類計(jì)算抽象形成 CUBE ，把能夠反應(yīng)在現(xiàn)象上的問題做成監(jiān)控，來衡量我們的質(zhì)量到底好還是壞。

在大數(shù)據(jù)質(zhì)量平臺，涉及到多維度計(jì)算，比如一次播放成功率下跌，具體是發(fā)生在安卓還是 iOS ？是全國范圍還是具體某一個(gè)?。渴撬幸苿佑脩暨€是聯(lián)通用戶出的問題？這就涉及到了我們?nèi)绾螌S度切片、鉆取，維度大了發(fā)現(xiàn)了問題也不好定位出原因，粒度小了對于存儲計(jì)算都是極大浪費(fèi)。

這就需要結(jié)合業(yè)務(wù)來看，定義必選監(jiān)控維度，然后將錯誤數(shù)據(jù)流通過 ETL 單獨(dú)切分，落盤到有聚合功能 ElasticSearch 、Druid 中，做到維度進(jìn)一步細(xì)化，把告警從“大面”縮減到“小面”。比如說北京市聯(lián)通出現(xiàn)了播放成功率下跌，通過聚合發(fā)現(xiàn)，出錯 CDN  IP 高度集中，告警層面就可以直接交給網(wǎng)絡(luò)服務(wù)定位系統(tǒng)去處理了。此外，監(jiān)控從實(shí)時(shí)性、準(zhǔn)確性、告警條件模型都有一些探索，我們將在 QCon 的分享中和大家做進(jìn)一步交流。

現(xiàn)在各大公司都在做 Trace 相關(guān)工作，阿里優(yōu)酷大數(shù)據(jù)平臺也不例外。在原有的服務(wù)端日志收集的基礎(chǔ)上，融合了客戶端埋點(diǎn)日志、客戶端遠(yuǎn)程 Debug 日志、服務(wù)變更操作、以及規(guī)范了第三方服務(wù)日志（ CDN 等）。這樣操作有利于統(tǒng)一收集已發(fā)現(xiàn)問題的數(shù)據(jù)；當(dāng)數(shù)據(jù)在手，被明確告知是有問題的，我們該如何分析？

首先，如果是錯誤碼，我們一層一層看下去也能解決，但是有一些問題，不是錯誤導(dǎo)致的。舉個(gè)例子，某天，我們這收到一個(gè)客訴反饋說看視頻特別卡，突然出現(xiàn)的，我們查了日志沒有任何報(bào)錯，最后是一位細(xì)心的同學(xué)發(fā)現(xiàn)，用戶網(wǎng)絡(luò) IP 在北京，CDN IP 被打到了廣州。對于這類問題，就是兩個(gè) IP 字符串提取并作地域解析匹配即可。

其次，我們結(jié)合數(shù)據(jù)，要建立起一個(gè)定位知識庫，把歷史故障、線上 Bug 、badcase 抽象成我們的定位診斷庫。

第三，也是我們現(xiàn)在正在做的一些事情，知識庫是人建立起來的，其實(shí)這就好比監(jiān)督學(xué)習(xí)，但我們想能不能用無監(jiān)督學(xué)習(xí)的方式把問題定位出來呢？再舉個(gè)例子，我們會做一些大型活動，但是有時(shí)發(fā)現(xiàn)從第一個(gè)頁面跳轉(zhuǎn)到第二個(gè)頁面的用戶轉(zhuǎn)化率發(fā)出警報(bào)（只有 10% ），我們會把這一類的用戶進(jìn)行全鏈路數(shù)據(jù)檢索（不只是服務(wù)端日志），然后將各類特征做聚類分析，就會驚奇的發(fā)現(xiàn)，絕大部份用戶會有共同的特征被聚類出來，問題可能是可能關(guān)聯(lián)一個(gè)服務(wù)來自于同一臺服務(wù)器超時(shí)引起，也有可能是來自于同樣的客戶端設(shè)備因?yàn)轫撁婕虞d適配問題等。所以說，未來的方向重點(diǎn)在于數(shù)據(jù)和算法結(jié)合起來，挖掘更大的價(jià)值。