萬無一失卻實際上是形同虛設的代碼邏輯漏洞

這是一則發生在某大廠的真實案例，出于脫敏名字這且不說。

?

這個系統因為第一次上線，流量非常的大。

所以需要灰度上線，所謂灰度方案很短，比如按照地理位置，先選擇某個訪問量小的地區比如西部青海。

然后逐步放量，幾天以后增加幾個省再看看，然后如果沒問題擴大到全國。

灰度是沒有問題的，也是必要的。

?

APP--->B系統--->新系統

這個系統提供了一個接口給B調用

由于B系統是全國開放，所以B的流量很大，B上面沒有做地區限制，他的流量會都打到新系統上。

所以一開始不是青海的用戶就不走這個系統的邏輯。

由于這個系統有自己的后臺，運營人員在后臺會設置不同地區的業務邏輯。

但是開發你也不知道運營是什么時候設置其他地區，這個灰度實際上是由運營來控制的。

所以開發人員就先從數據庫進行查詢已經設置的地區，把設計的地區直接緩存在JVM內存李，不在這個地區的都直接跳過，這樣就不會走后面的業務邏輯也就是查庫等等。

看起來一切沒有問題，但是實際上出現了一個缺陷，就是上線之初運營人員自己測試的時候先設置了“全國”，然后又刪除了這個配置，但是數據庫是軟刪除，地區是存在一個關聯表里。

開發人員沒有對查詢出來設置的地區進一步的限制，該地區必須是有效的，而不是已經刪除的也就是地區信息要去配置表進行關聯。

所以系統一上線，這個看似萬無一失卻形同虛設的優化點一點作用也沒有。

?

問題本身不復雜，無非是代碼邏輯不嚴謹，只測試了業務邏輯，沒有測試這個灰度邏輯。

開發+測試 都有需要改進之處，實際上現實中千千萬萬的bug都是諸如此類的。

總結

以上是生活随笔為你收集整理的大厂线上案例复盘--代码漏洞的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。