作者 | 杜沁園 等

　　責(zé)編 | 郭芮

　　出品 | CSDN（ID：CSDNnews）

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

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

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

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

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

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

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

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

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

　　如何做到「睡覺的時(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ù)庫系統(tǒng)的測(cè)試，同樣適用于其他任何復(fù)雜的系統(tǒng)。

　　背后的原理

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

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

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

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

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

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

　　存在問題的代碼源文件。

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

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

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

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

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

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

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

　　我們將每個(gè)產(chǎn)生式生成正確與錯(cuò)誤用例的比例作為該產(chǎn)生式的顏色值，繪制成一個(gè)頁面，作為 SQLFuzz 的展示頁面。通過該頁面，可以比較容易地看出哪條產(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，但是我們不確定用它來搞 Go 編譯的二進(jìn)制能否正常工作。換一個(gè)思路，如果能在編譯之前直接對(duì)源碼進(jìn)行插樁呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　源碼教學(xué)

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

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

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

　　Chaos Engineering

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

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

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

　　接下來的工作

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

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

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

　　https://github.com/fuzzdebugplatform/fuzz_debug_platform

　　Welcome to hack!

　　作者簡(jiǎn)介：

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

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

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

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