TiDB 可觀測性方案落地探索 | “我們這麼菜評委不會生氣吧”團隊訪談

在 TiDB Hackathon 2021 賽事中，沒有錯過任何一屆賽事的元老級選手王鵬翰再次得獎，也是繼滑滑蛋之後，又一支男女朋友並肩參賽的隊伍。

王鵬翰目前工作于思科旗下做應用效能管理的公司 AppDynamics，主要從事日誌搜尋引擎的研發和可觀測性相關的一些工作。陳思雨是 PingCAP Chaos Mesh 團隊的研發。

這次的參賽專案 Collie Diagnosing Platform，是一個集故障場景資訊收集、UI 線上觀察分析、機器學習輔助診斷於一身的故障診斷分析解決平臺。結合了兩人在工作中的實際場景，探索了未來 3-5 年 DBA 和運維人員的工作方式，評委們給予了非常高的評價和期待，拿下了本屆 Hackathon 的三等獎。

專案意義重大，讓 DBA 在分析問題時，面對那麼多 Metrics，不再那麼頭大。

——多點 Dmall 資料庫團隊負責人馮光普點評

資料庫自治是領域的重要方向，參賽團隊在理論和工程實踐方面都做的比較好，後續可以進一步對標阿里雲的 DAS 產品進行改進完善，將彌補這一領域專案在開源方面的空白。

——美團資料庫研發中心負責人李凱點評

關於團隊

Q：這個隊名的由來有什麼故事？

陳思雨： 隊名來自於 Dota 的一個語音包，在遊戲裡如果隊友做什麼比較蠢的操作的時候，播放下這條語音就達到效果了。

可以通過這條視訊體會一下： 

Q：兩位都是 Hackathon 的老選手了，Hackathon 對你們的吸引力是什麼呢？

王鵬翰： 對我來說 Hackathon 就是進行一個 deadline 的設定，逼著你在很短時間內學大量的東西。本來我很早就想去學習一下如何用機器學習做一些根因性分析相關的東西。但是已經想了一年，實際上只看了一點點。在 Hackathon 中，就可以在很短的時間內瞭解它並且把它使用起來。有一個 deadline 就會逼迫你快速去學習，這個時候學習效率非常高，睡覺的時候滿腦子都在想著這個地方還能怎麼優化一下，那個地方還怎麼搞。當然，順便還能拿到一點獎金。

陳思雨： 跟他差不多。另外，在 Hackathon 裡還能看到很多不一樣的 idea。

專案靈感

Q：你們最初為什麼會想到要做這樣一個專案的？能分享下你們的靈感是什麼嗎？

王鵬翰： 我們前兩年參賽基本上都是在做 FDW，就是給 TiDB 接一個通用的外部資料來源，今年的一等獎專案從某種意義上來說也是外部資料來源的一種。感覺已經做得有點心神憔悴了，那些 Hard Code 的功能對於我們這種老年人來說，無論是腦力還是體力都已經跟不上了，今年就只能在搞花活的方向去另闢蹊徑。

我找專案靈感的一個核心點是去發掘身邊真實遇到的一些情況，試圖抽取出一個通用性的問題，然後去想如何通過工具或者方法論把它高效地解決掉。包括去年的 idea 如何寫出一份優雅的文件，今年的 idea 如何快速地發現故障和診斷故障，都跟工作是息息相關的。

我現在的工作是在可觀測性領域，這個領域目前跟機器學習相結合的東西大多都還在論文階段，但在實際環境中如何把它更好地落地，還是比較少有人去嘗試的，剛好 TiDB 已經把整個基礎做得非常好了，就想借 Hackathon 的機會來做一些嘗試。

Q：在這次比賽過程中，你們的隊伍成員之間是如何分工的？

王鵬翰： 思雨負責如何用 TiDB 去模擬故障的發生，剛好也用了他們團隊的產品 Chaos Mesh。然後我使用一些工具來代替人腦，觀察這個時間段是否發生了問題，用機器學習的方法代替人做一些簡單的判斷。就等於說運維人員有一個很大的螢幕，上面有幾十個圖，每個圖裡都有很多的折線。一般情況下，如果一個系統在平穩執行的話，這條線基本是平的，但出現故障的時候，會有很大的波動。

現在都是 DBA 用人眼去觀察，故障的判斷也是基於人的經驗和思考模式。但現在 TiDB 中像這樣的指標就已經有幾千個了，未來還會有更多。這就意味著靠人去觀察這些東西會變得越來越複雜，越來越慢。我們可以用機器去幫你快速地篩選出來，比如 1000 張圖中有 10 張圖有這種故障，然後你再去觀察這 10 張圖就可以，幫你節省了大量的時間。

在理想的環境下，準確率能達到 70-80%。但如果在現實環境中，你可能認為有些並不是故障，所以這個指標會有一些波動，噪聲會很大。

技術困難&應對

Q：在比賽過程中你們遇到過什麼比較大的技術困難？

王鵬翰： 主要是資料集質量問題。目前在 AI 領域，演算法可能不是最關鍵的，最關鍵的是資料集。如果你的資料集夠好，通過相應的演算法都能得到一個很好的答案。但如果你的資料集比較糟糕，那你得出來的答案永遠是錯誤的。所以我們花了很多時間在資料集模擬這一塊。

另一塊就是在思考如果換我來運維繫統，從 DBA 的角度來看問題的時候，我該如何合理設計用更高效合理的方式來做這個事情。其實不管是 TiDB 也好，還是一套系統也好，都有一套共用的方法論，可以通過觀察資源，比如 CPU 資源或記憶體資源，或者觀察事務（一個http請求，一個資料庫查詢請求）。從而知道系統是否按照預期在執行。如果沒有按照預期執行的時候，我們的應用能給一個告警，還能告訴你是什麼原因導致系統沒有按預期執行。

這就是所謂的根因分析（Root Cause Analysis），我們希望通過機器學習，告訴你發生故障的原因是 CPU 不夠，還是機器上有另外的任務搶了 CPU 資源，那你就應該去加更多的 CPU 資源。

陳思雨： 其實其這個問題不應該僅僅是 DBA 或者運維關心的，因為他們（王鵬翰所在的 APPDynamic）是全員 Oncall 的，所以他會思考遇到一個 Oncall 的問題應該怎麼去解決，應該怎麼去優化這個 Oncall 的流程。我們這次做的專案也是在優化這個 Oncall 的整體流程。

DBA 可能會更專業一點，我們這次做的產品是面向那些非 DBA 人員，因為 DBA 看 Grafana 這種比較專業的指標就會有很明確的一個判斷。但是如果是剛上手的人，比如說剛開始學習 TiDB，也可以通過我們的產品有個初步的方向判斷，這個故障原因是一個網路延遲還是怎樣。

王鵬翰： 遇到的另一個問題就是現有的機器學習也好，深度學習也好，離所謂的 AIOps 還有非常遠的路要走，而且有很大的難度。為了這次的專案能有一個成品出來，主要依賴了兩篇論文，一篇是 SIGMOD 2016 的《DBSherlock: A Performance Diagnostic Tool for Transactional Databases》，另外一篇是 VLDB 2020 的《Diagnosing Root Causes of Intermittent Slow Queries in Cloud Databases》。

這 2 篇論文做得非常好的一點就是把場景侷限起來了，針對一個小的領域、小的場景能做到高度的準確性，比如一個運維可能 10% 的工作是在處理這類問題，那這個專案能自動化地解決這 10% 的工作量。然後像拼積木一樣，今天把這個問題的積木拼裝好，下次把另外一個問題拼裝好，慢慢就把整個全自動化的事情給拼接出來了。

未完成的遺憾 & 期待

Q：這次 Hackathon 的時間有限，你們在比賽過程中有什麼遺憾？

王鵬翰： 體驗滿意，完成個人的既定目標，在短時間快速學習了機器學習，並做了個小產品。aiops 可以在一些特定的領域降低人的工作負載，但離最終廣泛的替代運維還有非常遠的路。

陳思雨： 8 分鐘的演示時間太短了，我們一直在縮減 PPT，調整我們要突出哪些重點，還要保證在這麼短的時間內讓這麼多位評委老師都 get 到。

Q：你們的專案這次獲得了三等獎，對這個專案未來有什麼展望與期待？

王鵬翰： 首先，這個專案的實現方法還非常雛形，有很多的細節還需要跟大家探討和交流才能摸索出來。而且我們也沒有希望把這個專案做成一個產品，更多的是方向上的探索，探索未來 3-5 年運維或 DBA 的工作方式。

隨著技術的突飛猛進，運維的難度也越來越大。運維的管理物件從原來的單臺機器變成了雲和 Kubernetes，節點越來越多，湧現出來的資訊也越來越多。從開發的角度來說，會把更多的資訊暴露出來，統一地進行管理和追蹤。但如何更好地利用這些資訊？這個領域在國內還是鮮有人去思考的，也就是所謂的可觀測性（Observability）。

國外很多公司，包括我們公司（AppDynamic）都是這個領域的主要參與者，在非常活躍地往這個方向進行一些探索。PingCAP 已經算是做得很不錯的了，把整個資料庫的可觀測性做得很好。希望國內有更多的公司和個人能去思考一下，如何運用現有的工具，讓你的系統有更好的可觀測性，從而降低運維壓力和成本。