想說件最近實打?qū)嵅鹊目?，也順便聊聊這些年做開發(fā)、跟團隊協(xié)作下來，越來越深的一個感受——有些Bug，不是技術不夠硬，是我們太容易困在自己的崗位視角里，忽略了上下游的關聯(lián)。
問題復盤：
事情發(fā)生在一周前。我們組維護的用戶中心系統(tǒng)，上線了一個“批量查詢用戶權(quán)限”的接口。上線前，單元測試、集成測試全過，壓測也沒發(fā)現(xiàn)異常。上線后第三天，監(jiān)控開始報警：接口偶發(fā)響應超時，短則200ms，長則十幾秒，毫無規(guī)律，高峰時段更頻繁。
排查一開始就陷入了僵局：
前端同事查了請求參數(shù)和緩存策略，確認請求格式?jīng)]問題，本地調(diào)用測試環(huán)境接口也正常；
我們后端查了接口日志，入?yún)⒑蜆I(yè)務邏輯都沒異常。用Postman單獨調(diào)用接口也次次正常，初步排除了代碼死循環(huán)或內(nèi)存泄漏；
網(wǎng)關同事幫忙抓了包，發(fā)現(xiàn)一個關鍵線索：請求到達后端的時間，與后端返回的時間，差值偶爾會突然拉大。這說明，后端在處理請求時，內(nèi)部確實有某個環(huán)節(jié)變慢了；
于是找DBA查慢查詢?nèi)罩?，但所有關聯(lián)SQL的執(zhí)行時間都在50ms以內(nèi)，索引也正常。
排查到這里，每個人都覺得自己負責的環(huán)節(jié)沒問題，問題像憑空消失了一樣。
直到凌晨，測試組的同事主動介入。他沒有止步于“復現(xiàn)Bug”，而是用SkyWalking拉取了完整調(diào)用鏈路，并在壓測環(huán)境模擬了上線后的真實數(shù)據(jù)量（比測試環(huán)境膨脹了3倍，且大量批量查詢場景），終于復現(xiàn)了偶發(fā)超時。
順著鏈路一層層追下去，最終定位到了根因：不是單個SQL慢，而是ORM代碼里隱藏的N+1查詢。一段MyBatis-Plus的lambda鏈式調(diào)用，在查詢用戶列表后，又在循環(huán)里調(diào)用了getUserPermission()方法，而方法內(nèi)部再次查詢了數(shù)據(jù)庫。測試環(huán)境數(shù)據(jù)量小，循環(huán)次數(shù)少，問題被完美掩蓋；上線后批量查詢的循環(huán)次數(shù)暴漲，單次50ms，循環(huán)100次就是5秒，接口響應時間瞬間飆到十秒級。
修復很簡單，把循環(huán)查詢改為批量查詢，用IN條件一次性拉取所有用戶權(quán)限，接口響應時間穩(wěn)定在了100ms以內(nèi)。
問題本身不復雜，但修復后復盤時，測試同事的一句話讓我琢磨了很久：“這種循環(huán)依賴的場景我之前其實想過要測，但測試環(huán)境數(shù)據(jù)量太小，沒顯出問題來?！?/p>
讓我真正想聊的，不是這個Bug本身
這場故障讓我徹底想明白一件事：在復雜系統(tǒng)里，絕大多數(shù)能躲過層層檢查的疑難Bug，都長在不同角色的“交界處”。
前端和后端的交界處：后端覺得返回完整嵌套對象方便，前端卻可能因解析冗余數(shù)據(jù)導致列表卡頓；前端在循環(huán)里不假思索地調(diào)用批量接口，后端的數(shù)據(jù)庫就可能被突如其來的IN查詢打爆。前端不懂后端的查詢成本，后端不懂前端的渲染痛點，矛盾就出在這兒。
業(yè)務代碼和數(shù)據(jù)層的交界處：我寫代碼時只想著功能實現(xiàn)，覺得鏈式調(diào)用簡潔，卻忽略了數(shù)據(jù)量增長對ORM查詢的致命影響；DBA只關注到單條SQL的執(zhí)行計劃，卻不知道業(yè)務代碼在循環(huán)里調(diào)用它。
開發(fā)和測試的交界處：我們都容易默認“對方會覆蓋所有場景”，于是這種“看似沒問題，實際有隱患”的Bug，就溜過了單元測試和集成測試，直到上線才暴露。
我見過最高效的排查，從來不是一個人在專業(yè)領域里死磕，而是能跳出崗位，站在對方視角想問題：前端能懂一點后端查詢邏輯，后端能預判一點數(shù)據(jù)增長的性能風險，測試能讀懂關鍵代碼邏輯。反過來，我也見過太多低效的拉鋸——前端后端互相截日志證明自己沒問題，開發(fā)和DBA各執(zhí)一詞，時間都在猜疑中耗盡了。
順帶提一句
最近有個合作挺久的團隊在招人，前端、后端、測試崗都有，全國不少城市都有HC。我和他們技術負責人挺熟，團隊技術氛圍不錯，待遇和穩(wěn)定性都算靠譜。感興趣的朋友可以看一眼：https://jsj.top/f/o38ijj。
最后回到凌晨三點的那個Bug，其實誰都沒有錯——代碼通過了評審，測試完成了驗證，DBA也盡了職責。問題在于，我們都困在自己的崗位視角里，忽略了那個“似乎不屬于自己”的交界地帶。
現(xiàn)在我判斷一個技術人，不只看本專業(yè)的深度，更看他對自己邊界之外的東西有沒有好奇心。
你的舒適區(qū)邊界在哪兒，排查問題的邊界，大概就在哪兒。
