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

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

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

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

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

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

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

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

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

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

1. 成本

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

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

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

2. 盲目調(diào)參

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

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

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

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

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

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

• 卡頓超過多少的時候會導致用戶退出 App

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

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

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

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

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

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

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

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

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

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

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