Contents

最近看的几部悬疑片,主角都淡淡地说过:“要转换角度来思考问题”。

在「嫌疑犯X的献身」里面,为什么女主可以很淡定的说她没有杀死前夫,为什么她可以有“确凿的”不在场证据?后来发现是因为警察发现的尸体,和作案时间,并不是她的前夫和杀死他的那一天。

在「看不见的客人」里面,协助男主分析案件的“律师”,告诉他一个小故事:“在一个空荡的谷仓里面,正中间的房梁下有一个人悬梁自尽。可是那个人脚下却没有任何可以让他垫脚站上去的东西。后来发现这个”看似“不存在”的东西,其实是一个大冰块,它是曾经存在的,只是“消失”了。

悬疑片里面,有大量的这种类型的桥段。

其实,当一个程序员,我们也经常需要用这种“转换角度来思考问题”的思路,来发现导致看似不可能出现的问题的原因。

拿我最近两次排查系统问题来举例吧。

第一个问题是,在我们平台的直播里,偶然一些原因会导致主讲人的语音缺少了长度信息。我反复看获取语音长度,和控制消息推送到直播间的相关代码。可是在语音缺失的情况下,怎么都不应该导致消息推送出去。那为什么直播间会出现那样的消息呢?后来发现,原因是在另一个统计消息点赞数,刷新缓存的任务。它会把语音长度缺失的数据也刷到缓存,所以直播间就能看到那个数据了。

另一个问题是,最近我的手机会收到服务号推送直播开始的通知。可是那些直播命名都是已经结束了的。我怎么看代码都百思不得其解。我观察到两个奇怪的现象:1)误推送的消息,显示的直播时间都是差了 8 个小时,显示的是 ISO 时间。2)线上服务器的日志,根本没有这些异常通知的发送日志记录。原来,压测团队在模拟的线上环境里跑系统和后台任务的时候,用了线上环境的一些参数,导致通过线上的微信服务号,根据压测环境数据库的直播,推送了消息。

我们程序员,经常被调侃说,当测试或产品告诉我们发现 Bug 的时候,我们经常会回复:“没可能,在我的机器都是好好的。” 其实,有些问题是以我们从来没有想到的角度,而被触发的。下次说没可能前,先停一停,想一想。

Contents