作者 | 杜沁園 等

　　責(zé)編 | 郭芮

　　出品 | CSDN（ID：CSDNnews）

　　曾在 Hacker News 上看到過(guò)一個(gè) Oracle 工程師處理 bug 的 日常：

　　先花兩周左右時(shí)間來(lái)理解 20 個(gè)參數(shù)如何通過(guò)神奇的組合引發(fā) bug,。

　　改了幾行代碼,，嘗試對(duì) bug 進(jìn)行修復(fù),，提交測(cè)試集群開(kāi)始跑近百萬(wàn)個(gè)測(cè)試 case,，通常要 20~30 小時(shí)。

　　運(yùn)氣好的話(huà)會(huì)有 100 多個(gè) case 沒(méi)過(guò),，有時(shí)候上千個(gè)也有可能,，只好挑選幾個(gè)來(lái)看，發(fā)現(xiàn)還有 10 個(gè)參數(shù)之前沒(méi)有注意到。

　　又過(guò)了兩周,，終于找到了引起 bug 的真正參數(shù)組合,，并跑通了所有測(cè)試。并增加 100 多個(gè)測(cè)試 case 確保覆蓋他的修改,。

　　經(jīng)過(guò)一個(gè)多月的代碼 review,，他的修改終于合并了，開(kāi)始處理下一個(gè) bug……

　　后來(lái)這個(gè)工程師感慨說(shuō)：“I don't work for Oracle anymore. Will never work for Oracle again!”

　　Oracle 12.2 有將近 2500 萬(wàn)行 C 代碼,，復(fù)雜系統(tǒng)的測(cè)試是一件艱難,、艱苦和艱巨的事情，而測(cè)試一個(gè)分布式數(shù)據(jù)庫(kù)的情況就更復(fù)雜了,。我們永遠(yuǎn)不知道用戶(hù)可能寫(xiě)出什么樣的 SQL,，表結(jié)構(gòu)和索引有多少種組合，此外還要考慮集群在什么時(shí)候節(jié)點(diǎn)發(fā)生宕機(jī),，以及受到網(wǎng)絡(luò)抖動(dòng),、磁盤(pán)性能退化等因素的影響——可能性幾乎是無(wú)限的。

　　那么有沒(méi)有一種方法能讓程序自動(dòng)幫我們查 bug,？

　　如何做到「睡覺(jué)的時(shí)候讓程序自動(dòng)查 bug」,？

　　項(xiàng)目的思路其實(shí)很簡(jiǎn)單，如果在每次跑 case 的時(shí)候能用統(tǒng)計(jì)學(xué)的方法對(duì)足夠多次實(shí)驗(yàn)的代碼路徑進(jìn)行分析,，就可以找出疑似 bug 的代碼,，最終結(jié)果以代碼染色的方式由前端可視化呈現(xiàn)，就得到了如下圖展示的效果：

　　「顏色越深,，亮度越高」表示包含錯(cuò)誤邏輯的可能性越大,。該方法不僅適用于數(shù)據(jù)庫(kù)系統(tǒng)的測(cè)試,，同樣適用于其他任何復(fù)雜的系統(tǒng),。

　　背后的原理

　　項(xiàng)目最初是受到 VLDB 的一篇論文的啟發(fā) APOLLO: Automatic Detection and Diagnosis of Performance Regressions in Database Systems，該論文主要圍繞如何診斷引發(fā)數(shù)據(jù)庫(kù)性能回退的代碼,，其核心思想也同樣適用于排查 bug,。論文中提到的自動(dòng)診斷系統(tǒng)由 SQLFuzz，SQLMin 和 SQLDebug 三個(gè)模塊組成,。

　　SQLFuzz：負(fù)責(zé)隨機(jī)生成 SQL,，并利用二分查找定位到性能回退的前后兩個(gè)版本，傳遞給 SQLMin 模塊,。

　　SQLMin：通過(guò)剪枝算法將 SQLFuzz 生成的 SQL 進(jìn)行化簡(jiǎn),，得出能夠復(fù)現(xiàn)該問(wèn)題的最小 SQL ，傳遞給 SQLDebug 模塊,。目的是減少無(wú)關(guān)的代碼路徑,，降低噪音。

　　SQLDebug：對(duì)源碼進(jìn)行插樁，使其在執(zhí)行 SQL 時(shí)能夠輸出代碼的執(zhí)行路徑,。然后對(duì)兩個(gè)版本的代碼路徑進(jìn)行分析,，建立一個(gè)統(tǒng)計(jì)模型來(lái)定位問(wèn)題的位置。

　　最終系統(tǒng)自動(dòng)生成測(cè)試報(bào)告,，內(nèi)容包含：

　　哪一次的代碼 commit 引入了性能回退,。

　　存在問(wèn)題的代碼源文件。

　　具體的函數(shù)位置,。

　　而實(shí)際上,，考慮到并發(fā)、循環(huán),、遞歸等帶來(lái)的影響,，代碼執(zhí)行路徑分析會(huì)非常復(fù)雜。為了保證能夠在 Hackathon 那么短的時(shí)間內(nèi)展示出效果,，我們又參考了另一篇論文 Visualization of Test Information to Assist Fault Localization,，其核心思想是通過(guò)統(tǒng)計(jì)代碼塊被正確和錯(cuò)誤測(cè)試用例經(jīng)過(guò)次數(shù)，再基于分析算法來(lái)涂上不同的顏色,，簡(jiǎn)單而實(shí)用,。

　　其實(shí)借助這個(gè)思路也可以應(yīng)用到其他領(lǐng)域，后面我們將展開(kāi)來(lái)介紹,。接下來(lái)我們先來(lái)看看 SQLDebug 是如何實(shí)現(xiàn)的,。

　　聊聊細(xì) (gān) 節(jié) (huò)

　　如何自動(dòng)產(chǎn)生測(cè)試 case？

　　由于是基于統(tǒng)計(jì)的診斷,，我們需要先構(gòu)建足夠多的測(cè)試用例,，這個(gè)過(guò)程當(dāng)然最好也由程序自動(dòng)完成。事實(shí)上,，grammar-based 的測(cè)試在檢驗(yàn)編譯器正確性方面有相當(dāng)長(zhǎng)的歷史,，DBMS 社區(qū)也采用類(lèi)似的方法來(lái)驗(yàn)證數(shù)據(jù)庫(kù)的功能性。比如：微軟的 SQL Server 團(tuán)隊(duì)開(kāi)發(fā)的 RAGS 系統(tǒng)對(duì)數(shù)據(jù)庫(kù)進(jìn)行持續(xù)的自動(dòng)化測(cè)試,，還有社區(qū)比較出名的 SQLSmith 項(xiàng)目等等,。今年 TiDB Hackathon 的另一個(gè)獲獎(jiǎng)項(xiàng)目 sql-spider 也是實(shí)現(xiàn)類(lèi)似的目的。

　　這里我們暫時(shí)采用 PingCAP 開(kāi)源的隨機(jī)測(cè)試框架 go-randgen 實(shí)現(xiàn) SQL fuzzing,，它需要用戶(hù)寫(xiě)一些規(guī)則文件來(lái)幫助生成隨機(jī)的 SQL 測(cè)試用例,。規(guī)則文件由一些產(chǎn)生式組成。randgen 每次從 query 開(kāi)始隨機(jī)游走一遍產(chǎn)生式,，生成一條 SQL,，產(chǎn)生一條像下圖紅線(xiàn)這樣的路徑。

　　我們將每個(gè)產(chǎn)生式生成正確與錯(cuò)誤用例的比例作為該產(chǎn)生式的顏色值,，繪制成一個(gè)頁(yè)面,，作為 SQLFuzz 的展示頁(yè)面,。通過(guò)該頁(yè)面，可以比較容易地看出哪條產(chǎn)生式更容易產(chǎn)生錯(cuò)誤的 SQL,。

　　代碼跟蹤

　　為了跟蹤每一條 SQL 在運(yùn)行時(shí)的代碼執(zhí)行路徑,，一個(gè)關(guān)鍵操作是對(duì)被測(cè)程序進(jìn)行插樁 (Dynamic Instrumentation)。VLDB 論文中提到一個(gè)二進(jìn)制插樁工具 DynamoRIO,，但是我們不確定用它來(lái)搞 Go 編譯的二進(jìn)制能否正常工作,。換一個(gè)思路，如果能在編譯之前直接對(duì)源碼進(jìn)行插樁呢,？

　　參考 go cover tool 的實(shí)現(xiàn),，我們寫(xiě)了一個(gè)專(zhuān)門(mén)的代碼插樁工具 tidb-wrapper。它能夠?qū)θ我獍姹镜?TiDB 源碼進(jìn)行處理,，生成 wrapped 代碼,。并且在程序中注入一個(gè) HTTP Server，假設(shè)某條 SQL 的摘要是 df6bfbff（這里的摘要指的是 SQL 語(yǔ)句的 32 位 MurmurHash 計(jì)算結(jié)果的十六進(jìn)制,，主要目的是簡(jiǎn)化傳輸?shù)臄?shù)據(jù)）,，那么只要訪(fǎng)問(wèn) http://<tidb-server-

ip>::43222/trace/df6bfbff 就能獲得該 SQL 所經(jīng)過(guò)的源碼文件和代碼塊信息。

　　因?yàn)橹饕繕?biāo)是正確性診斷,，所以我們限定系統(tǒng)不對(duì) TiDB 并發(fā)執(zhí)行 SQL,，這樣就可以認(rèn)為從 server/conn.go:handleQuery 方法被調(diào)用開(kāi)始，到 SQLDebug 模塊訪(fǎng)問(wèn) trace 接口的這段時(shí)間所有被執(zhí)行的基本塊都是這條 SQL 的執(zhí)行路徑,。當(dāng) SQLDebug 模塊訪(fǎng)問(wèn) HTTP 接口,，將會(huì)同時(shí)刪除該 SQL 相關(guān)的 trace 信息，避免內(nèi)存被撐爆,。

　　基本塊統(tǒng)計(jì)

　　SQLDebug 模塊在獲取到每條 SQL 經(jīng)過(guò)的基本塊信息后,，會(huì)對(duì)每個(gè)基本塊建立如下的可視化模型。

　　首先是顏色,，經(jīng)過(guò)基本塊的失敗用例比例越高,，基本塊的顏色就越深。

　　然后是亮度,，經(jīng)過(guò)基本塊的失敗用例在總的失敗用例中占的比例越高,，基本塊的亮度越高。

　　已經(jīng)有了顏色指標(biāo),，為什么還要一個(gè)亮度指標(biāo)呢？其實(shí)亮度指標(biāo)是為了彌補(bǔ)“顏色指標(biāo) Score”的一些偏見(jiàn),。比如某個(gè)代碼路徑只被一個(gè)錯(cuò)誤用例經(jīng)過(guò)了,，那么它顯然會(huì)獲得 Score 的最高分 1，事實(shí)上這條路徑不那么有代表性,，因?yàn)檫@么多錯(cuò)誤用例中只有一個(gè)經(jīng)過(guò)了這條路徑,，大概率不是錯(cuò)誤的真正原因,。所以需要額外的一個(gè)亮度指標(biāo)來(lái)避免這種路徑的干擾， 只有顏色深,，亮度高的代碼塊,，才是真正值得懷疑的代碼塊。

　　上面的兩個(gè)模型主要是依據(jù)之前提到的 Visualization 的論文,，我們還自創(chuàng)了一個(gè)文件排序的指標(biāo),，失敗用例在該文件中的密度越大（按照基本塊），文件排名越靠前：

　　前端拿到這些指標(biāo)后,，按照上面計(jì)算出的文件排名順序進(jìn)行展示,，越靠前的文件存在問(wèn)題的風(fēng)險(xiǎn)就越高。

　　當(dāng)點(diǎn)擊展開(kāi)后可以看到染色后的代碼塊：

　　我們經(jīng)過(guò)一些簡(jiǎn)單的實(shí)驗(yàn),，文件級(jí)別的診斷相對(duì)比較準(zhǔn)確,，對(duì)于基本塊的診斷相對(duì)還有些粗糙，這跟沒(méi)有實(shí)現(xiàn) SQLMin 有很大關(guān)系,，畢竟 SQLMin 能去除不少統(tǒng)計(jì)時(shí)的噪聲,。

　　還能不能做點(diǎn)別的？

　　看到這里,，你可能覺(jué)得這個(gè)項(xiàng)目不過(guò)是針對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的自動(dòng)化測(cè)試,。而實(shí)際上借助代碼自動(dòng)調(diào)試的思路，可以給我們更多的啟發(fā),。

　　源碼教學(xué)

　　閱讀和分析復(fù)雜系統(tǒng)的源碼是個(gè)頭疼的事情,，基于源碼的運(yùn)行時(shí)可視化跟蹤能否做成一個(gè)通用工具呢？這樣在程序執(zhí)行的同時(shí)就可以直觀(guān)地看到代碼的運(yùn)行過(guò)程,，對(duì)快速理解源碼一定會(huì)大有幫助,。更進(jìn)一步，配合源碼在線(xiàn)執(zhí)行有沒(méi)有可能做成一個(gè)在線(xiàn) web 應(yīng)用呢,？

　　全鏈路測(cè)試覆蓋統(tǒng)計(jì)

　　語(yǔ)言本身提供的單測(cè)覆蓋統(tǒng)計(jì)工具已經(jīng)比較完備了,，但一般測(cè)試流程中還要通過(guò) e2e 測(cè)試、集成測(cè)試,、穩(wěn)定性測(cè)試等等,。能否用本文的方法綜合計(jì)算出各種測(cè)試的覆蓋度，并且與 CI 系統(tǒng)和自動(dòng)化測(cè)試平臺(tái)整合起來(lái),。利用代碼染色技術(shù),，還可以輸出代碼執(zhí)行的熱力圖分析。結(jié)合 profiler 工具,，是不是還可以輔助來(lái)定位代碼的性能問(wèn)題,？

　　Chaos Engineering

　　在 PingCAP 內(nèi)部有諸多的 Chaos 測(cè)試平臺(tái)，用來(lái)驗(yàn)證分布式系統(tǒng)的魯棒性,，譬如像 Schrodinger,，Jepsen 等等,。混沌測(cè)試有個(gè)弊端就是,，當(dāng)跑出問(wèn)題之后想再次復(fù)現(xiàn)就很難,，所以只能通過(guò)當(dāng)時(shí)的情形去猜代碼可能哪里有問(wèn)題。如果能在程序運(yùn)行時(shí)記錄代碼的執(zhí)行路徑,，根據(jù)問(wèn)題發(fā)生時(shí)間點(diǎn)附近的日志和監(jiān)控進(jìn)一步縮小范圍,，再結(jié)合代碼路徑進(jìn)行分析就能精確快速的定位到問(wèn)題的原因。

　　與分布式 Tracing 系統(tǒng)集成

　　Google 有一篇論文是介紹其內(nèi)部的 分布式追蹤系統(tǒng) Dapper ,，同時(shí)社區(qū)也有比較出名的項(xiàng)目 Open Tracing 作為其開(kāi)源實(shí)現(xiàn),，Apache 下面也有類(lèi)似的項(xiàng)目 Skywalking。一般的 Tracing 系統(tǒng)主要是跟蹤用戶(hù)請(qǐng)求在多個(gè)服務(wù)之間的調(diào)用關(guān)系,，并通過(guò)可視化來(lái)輔助排查問(wèn)題,。但是 Tracing 系統(tǒng)的跟蹤粒度一般是服務(wù)層面，如果我們把 trace_id 和 span_id 也當(dāng)作標(biāo)注傳遞給代碼塊進(jìn)行打樁,，那是不是可以在 Tracing 系統(tǒng)的界面上直接下鉆到源碼,，聽(tīng)起來(lái)是不是特別酷？

　　接下來(lái)的工作

　　以上我們只完成了一個(gè)非常簡(jiǎn)單的原型,，距離真正實(shí)現(xiàn)睡覺(jué)時(shí)程序自動(dòng)查 bug 還有一段路要走,，我們計(jì)劃對(duì)項(xiàng)目持續(xù)的進(jìn)行完善。

　　接下來(lái),，首先要支持并行執(zhí)行多個(gè)測(cè)試用例,，這樣才能在短時(shí)間得到足夠多的實(shí)驗(yàn)樣本，分析結(jié)果才能更加準(zhǔn)確,。另外,，要將注入的代碼對(duì)程序性能的影響降低到最小，從而應(yīng)用于更加廣泛的領(lǐng)域,，比如性能壓測(cè)場(chǎng)景,，甚至在生產(chǎn)環(huán)境中也能夠開(kāi)啟。

　　看到這里可能你已經(jīng)按耐不住了,，附上項(xiàng)目的完整源碼：

　　https://github.com/fuzzdebugplatform/fuzz_debug_platform

　　Welcome to hack!

　　作者簡(jiǎn)介：

　　黃寶靈,，PingCAP 前端開(kāi)發(fā)工程師，喜歡 React 和 Type,。

　　滿(mǎn)俊朋, 效率工具工程師, 目前在 PingCAP 從事 Benchmark, Stability 相關(guān)工具的研發(fā),。

　　杜沁園，中科大研究生,，曾在 PingCAP 實(shí)習(xí),，從事數(shù)據(jù)庫(kù)測(cè)試工具的研發(fā)。

　　韓玉博,，中科大研究生,，在 Tradeshift 實(shí)習(xí)，從事前端開(kāi)發(fā),。