一次查找分子級Bug的經歷，過程太酸爽了
Debugging is like trying to find a needle in a haystack, except the needle is also made of hay.
Debug調試就像是在大片的干草堆中找針一樣，只不過針也是由干草制成的。
為了達成秒級啟動環境的性能要求，我們設計了一套精巧的分布式文件系統架構，其核心是一個可以瞬間復制大量小文件的寫時復制 (COW) 技術。IO 吞吐能達到幾萬人同時在線，性能絕對是它的一大優勢。
我們對此信心滿滿，然而沒想到，很快就翻車了。
02 探險啟程
2023 年 1 月，北方已經白雪皚皚，而深圳卻仍難以感受到冬天的寒意。
我和我的團隊在幾次打開文件樹的某個文件時，會顯得有點慢——當時沒有人在意，按照常規思路，“網速”背了這個鍋。事后我們復盤才發現，這個看似微不足道的小問題，其實正是我們開始這次探險之旅的起點。
1 月底，南方的寒意緩緩侵入。這時候我們的輕協同 IDE 引擎已經開始陸續支持了 Vue2、Vue3、React、Django、Rails 等框架環境，一開始表現都很棒，加載和啟動速度都很快。但是，跑了一段時間，我們開始察覺，線上環境就出現個別環境（Rails 環境）啟動要 20-30s 才能完成。
雖然其他環境仍然保持了極快的加載和啟動速度，但敏銳的第六感告訴我，不行，這一定有什么貓膩，如果不立即行動，勢必會對用戶體驗帶來很不好的影響。于是，我開始安排團隊排查眼前這個不起眼的問題，我們的探險之旅正式開始。
03 初露希望
濕冷的冬季，夜已深，我和我們的團隊依舊坐在電腦前苦苦探索，瑟瑟發抖。
探險之旅的第一站，就是老大難的問題：定位Bug。目前只有某一個環境啟動很慢，其他的環境都表現不錯。大家想了很多辦法都沒有想明白為什么，甚至懷疑這個環境的模板是不是有問題——但把代碼放在本地啟動，最多就2秒。
哎，太詭異了。我們在這里卡了至少一周時間，不斷追蹤代碼，分析日志文件，嘗試各種方案，都沒有弄清楚一個正常的程序啟動為什么會慢。我們一度陷入了疲憊和焦慮的情緒中。
| Debug 是種信仰，只有堅信自己能找到 Bug，才有可能找到 Bug。
軟件開發界一直有一個低級 Bug 定律：所有詭異的問題都來自一個低級原因。在這“山重水復疑無路”之際，我們決定重新審視我們的探險路徑：為什么只有 Rails 更慢，其他并不慢？會不會只是一個非常微小的原因而導致？
這時候，恰好有一個架構師朋友來訪，向我們建議，可以用 perf 火焰圖分析看看 Rails 的啟動過程。
當我們用 perf 來分析時，驚訝地發現：原來 Rails 的啟動要加載更多的文件！緊接著，我們又重新用了一個文件讀寫監控的工具：fatrace，通過它，我們看到 Rails 每次啟動需要讀寫至少 5000 個文件，但其他框架并不需要。
這才讓我們突然意識到，會不會是文件系統讀寫速度不及預期，導致了啟動變慢。
04 Bug現身
為了搞清楚是不是文件系統讀寫速度的問題，我急需一個測試 IO 抖動的腳本。我們初步估算一下，寫好這個腳本需要好幾個小時的時間。
夜已深，研發同學都陸續下班了。時間緊迫！我想起了火爆全球的 ChatGPT，心想，不如讓它寫一個試試。
Cool，幾乎不需要改動就能用，把代碼扔在服務器開跑，一測，果然發現問題：每一次文件讀寫都需要 10-20ms 才能完成 。實際上，一個優秀的磁盤 IO 讀寫時延應該在亞毫級，但這里至少慢了 50 倍。
Bingo，如同“幽靈寶藏”一般的分子級 Bug 逐漸顯現，問題的根因已經確認：過慢的磁盤 IO 讀寫引發了一系列操作變慢，進而導致啟動時間變得非常慢。
更慶幸的是，它還讓我們發現了偶爾打開文件樹變慢的根本原因，這也是整個系統并發能力下降的罪魁禍首。
05 迷霧追因
看到這里，大家可能會問，這套分布式文件系統莫非一直這么慢，你們為什么在之前沒有發現？
非也，早在項目開始的時候，這里的時延是比較良好的，大家沒有特別注意這個 IOPS 性能指標，直到我們后面才留意到，系統運行超過一個月時，IO 讀寫時延很容易就進入到卡頓的狀態，表現就是文件系統所在主機 CPU 忽高忽低，重啟就會臨時恢復。
此時，探險之旅還沒結束。畢竟，這個“幽靈寶藏”周圍依舊籠罩著一層迷霧。
我們繼續用 fatrace（監控誰在讀寫哪個 IO）監控線上各個候選人答題目錄的 IO讀寫情況，好家伙，我們發現了一個意外的情況：幾乎每一秒都有一次全量的文件 stats 操作 (這是一個檢測文件是否有屬性變化的 IO 操作）！
也就是說，比如有 1000 個候選人正在各自的 IDE 中編碼，每個候選人平均有 300 個文件，就會出現每秒 30 萬的 IO 操作數！
我們趕緊去查資料，根據研究數據顯示，一個普通的 SSD 盤的 IOPS 最高也就到 2-3 萬 。于是，我們重新測試了自己分布式文件系統的 IOPS 能力，結果發現也是 2-3 萬 。
那這肯定遠遠達不到我們理想中的能力級別。
這時，問題更加明確：某種未知的原因導致了大量的 IOPS 的需求，引發了 IO 讀寫時延變長，慢了大約幾十倍。
06 接近尾聲
我和我的團隊繼續深究下去，問題已經變得非常明確了：
原來，早在去年 12 月，我們上線一個監聽文件增刪的變化來通知各端刷新的功能。
最開始我們采用事件監聽 (fswatch event)，因為跨了主機，所以存在 1-2s 的延遲。研發同學將其改為輪詢實現的方案，進而引發了每秒掃描目錄的 stats 行為。
當在百人以下訪問時，IOPS 沒有破萬，還足夠應對。但一旦訪問量上千，便會引發 IO 變慢，進而導致系統出現各種異常：間歇導致某些關鍵接口 QPS 變低，進而引發系統抖動。
隨著“幽靈寶藏”顯露真身，這次分子級 Bug 的探險之旅也已經接近尾聲。團隊大呼：這過程實在太酸爽了！
07 技術無止境
每一個程序員在成長路上，都需要與 Bug 作充足的對抗，要么你勇于探索，深入代碼的叢林，快速定位，挖到越來越豐富的“寶藏”，然后盡情汲取到頂級的知識，最終成為高手；或者被它打趴下, 花費大量時間都找不到問題的根源，成為蕓蕓眾生中的一人。
當然，程序員的世界中，不單單是 Debug。
當我畢業 5 年之后，開始意識到技術的真正價值是解決真正的社會問題。前文中我提到，由于我發現技術招聘真是一個極其痛苦的事：特別花面試官的時間，卻又無法有效分析出候選人的技術能力，所以創立 ShowMeBug 來解決這個問題：用模擬實戰的編程環境，解決科學評估人才的難度。
這個輕協同 IDE 技術從零開發，支持協同文件樹、完全自定義的文件編輯器、協同的控制臺 (Console) 與終端 (Shell)，甚至直接支持 Ctrl+P 的文件樹搜索，不僅易于使用，又強大有力。
但是這還不夠。要知道，追求技術精進是我們技術人的畢生追求。對于這個輕協同IDE，我們追求三個零：零配置、零啟動、零延遲。其中，零啟動就是本文所追求的極限：以最快的速度啟動環境和切換環境。
因此，探險之旅結束后，我們進一步改進了此文件系統，設定 raid 的多磁盤冗余，采用高性能 SSD，同時重新制定了新磁盤架構參數，優化相關代碼，最終大幅提升了分布式文件系統的穩定性與并發能力。
截止本文結尾，我們啟動環境的平均速度為 1.3 秒，切換環境速度進入到亞秒級，僅需要 780ms。目前在全球范圍的技術能力評估賽道 (TSA) 中，具備 1-2 年的領先性。
08 后記
正當我打算結束本文時，我們內部的產品吐槽群信息閃爍，點開一看：嚯，我們又發現了新 Bug。
立夏已至，我們的探險之旅又即將開始。
