連續4天亮起紅燈
某家B2B童裝賣家的訂單入口網站,在部署前有一個自動檢查閘門會掃描程式碼。這個閘門連續4天亮起紅燈,每天都跳出「發現異常」的通知。
追查原因後有點意外。3週前的安全修復中,我們刻意刪掉了原本一字不差寫死在程式碼裡的明文密碼。因為密碼直接寫在程式碼裡,任何人都能偷看。刪掉是對的。
但檢查閘門還拿著舊標準。它在檢查「那3個密碼常數必須存在於程式碼中才算正常」。安全性明明變好了,檢查器卻判定它「壞了」。
修復反而很簡單。我們把檢查標準反轉過來。現在改成明文密碼「不存在」才能通過。
換成大樓警衛來比喻
換個更簡單的比喻。某棟大樓把大門保全從鑰匙升級成指紋辨識,安全多了。
但警衛室的點檢表上還留著舊項目:「確認鑰匙盒裡有3把鑰匙」。既然改成指紋辨識,當然沒有鑰匙。於是警衛每天都回報「發現異常」。
沒有鑰匙不是問題,反而是好事。老舊的是那張點檢表。我們的閘門正是這位警衛。
隔壁也亮起了紅燈
同一天,另一個服務的檢查器也連續4天紅燈。這次是試驗性加入的新功能程式碼裡留了個小瑕疵。而每天自動執行的資料儲存作業持續繼承這個瑕疵,跟著一起倒下。
資料本身沒有錯,是搬運資料的通道生病了。這是紅燈連續好幾天時常見的樣貌。
兩個案例表面上看完全不同,一個是修完安全性之後,一個是加完新功能之後。但根源一模一樣:檢查器所看的標準,跟不上實際程式碼走過的變化。
於是學到的四件事
一、檢查器也會像程式碼一樣變老。 當要守護的對象進化了,檢查標準也得跟著進化。昨天的正解,可能變成今天的錯誤。
二、「建置通過」和「全部閘門通過」是兩回事。 我在自己電腦上只看了建置,閘門卻在那之前先跑了別的檢查。不能只看一個綠燈就相信全都好了。
三、紅燈亮了4天,兇手通常不是「今天的提交」。 若是連續好幾天的失敗,原因多半藏在很久以前埋下的地方。只盯著今天改的東西,只會一直找錯方向。
四、閘門失敗時,多問一個問題。 別只問「程式碼壞了嗎?」,也一起問「閘門老了嗎?」。自動化越多,這一個問題越能省下大量時間。
今日一句
當檢查器亮起紅燈,在懷疑程式碼之前,先問問檢查器的年紀。