连续4天亮起红灯
某家B2B童装卖家的订单门户网站,在部署前有一个自动检查闸门会扫描代码。这个闸门连续4天亮起红灯,每天都跳出「发现异常」的通知。
追查原因后有点意外。3周前的安全修复中,我们刻意删掉了原本一字不差写死在代码里的明文密码。因为密码直接写在代码里,任何人都能偷看。删掉是对的。
但检查闸门还拿着旧标准。它在检查「那3个密码常量必须存在于代码中才算正常」。安全性明明变好了,检查器却判定它「坏了」。
修复反而很简单。我们把检查标准反转过来。现在改成明文密码「不存在」才能通过。
换成大楼保安来比喻
换个更简单的比喻。某栋大楼把大门安保从钥匙升级成指纹识别,安全多了。
但保安室的点检表上还留着旧项目:「确认钥匙盒里有3把钥匙」。既然改成指纹识别,当然没有钥匙。于是保安每天都上报「发现异常」。
没有钥匙不是问题,反而是好事。老旧的是那张点检表。我们的闸门正是这位保安。
隔壁也亮起了红灯
同一天,另一个服务的检查器也连续4天红灯。这次是试验性加入的新功能代码里留了个小瑕疵。而每天自动执行的数据保存作业持续继承这个瑕疵,跟着一起倒下。
数据本身没有错,是搬运数据的通道生病了。这是红灯连续好几天时常见的样子。
两个案例表面上看完全不同,一个是修完安全性之后,一个是加完新功能之后。但根源一模一样:检查器所看的标准,跟不上实际代码走过的变化。
于是学到的四件事
一、检查器也会像代码一样变老。 当要守护的对象进化了,检查标准也得跟着进化。昨天的正解,可能变成今天的错误。
二、「构建通过」和「全部闸门通过」是两回事。 我在自己电脑上只看了构建,闸门却在那之前先跑了别的检查。不能只看一个绿灯就相信全都好了。
三、红灯亮了4天,凶手通常不是「今天的提交」。 若是连续好几天的失败,原因多半藏在很久以前埋下的地方。只盯着今天改的东西,只会一直找错方向。
四、闸门失败时,多问一个问题。 别只问「代码坏了吗?」,也一起问「闸门老了吗?」。自动化越多,这一个问题越能省下大量时间。
今日一句
当检查器亮起红灯,在怀疑代码之前,先问问检查器的年纪。