蹲在服务器机柜旁啃凉包子时，我搞懂了真正的技术风险识别

凌晨三点的机房没有空调风声。

只有服务器风扇的嗡鸣往骨头缝里钻。

那天我蹲在机柜边啃早上剩下的半盒凉包子，盯着屏幕上跳出来的“支付回调重复触发”的红色报错，突然反应过来：我们之前耗了整整三个月、拉了八次跨部门会做的技术风险识别，全是白忙活。

之前我们做风险识别的流程，说出来真的太有代表性了：拉上产品、运营、安全的同事开两次会，每个人对着PPT想几个听起来很吓人的问题，什么“机房整体断电”“数据库被黑客拖走”“DDoS攻击打瘫入口”，每个问题配个看起来很完善的应对方案，导出成PDF存在知识库最显眼的位置，全公司上下都觉得，我们已经把所有风险都兜住了。

别信那些贴在墙上的风险 checklist

没人真的把这些checklist当回事。

就说那次出问题的支付系统，我们当时在风险清单里明明白白写着“回调接口异常时启动自动重试机制”，看起来考虑得特别周全。但从头到尾，没有一个人坐下来，把第三方支付的回调逻辑顺着捋一遍——如果第三方的服务端抽风，因为自身的网络问题，10分钟内给我们发了17次完全一样的“支付成功”通知，我们的系统会怎么做？

答案是：每收到一次通知，就给用户的账户充一次值。

那天凌晨的故障，就是因为第三方支付的接口出了点小问题，重复推送了几百笔支付成功的回调，我们的系统没做任何拦截，硬生生给两百多个用户充了17倍的话费，等运维同事监控到异常流量的时候，财务已经在大老板的群里@所有人，说账户里少了小两万块。

说出来真的臊得慌。

我们当时列风险的时候，满脑子都是那种能上新闻的大故障，根本没人愿意花两个小时，把代码里的每一个执行分支都顺着摸一遍。大家都觉得，那种小问题、小疏漏，根本算不上“风险”——不就是个没做幂等的接口嘛，第三方怎么可能发重复请求呢？

真正的风险识别，是顺着“最懒的选择”往下挖

那次故障之后，我们组连着熬了两个通宵，才把之前漏掉的风险点一个个补回来。也是那段时间我才想明白，真正能造成损失的技术风险，从来不是那些听起来吓人的极端情况。

是你写代码的时候图省事儿，留的那些“应该不会出事”的口子。

比如写回调接口的时候，为了快，没做幂等校验——这里简单解释下，幂等就是同一个操作不管重复执行多少次，结果都和执行一次一模一样，就像你按电梯的上行按钮，按十次，电梯还是只会来一次，不会为你跑十趟。当时我们觉得“第三方支付怎么可能发重复请求”，就把这步省了。

比如做数据库备份的时候，图方便，每周只做一次全量备份，从来没测试过备份文件能不能真的恢复——你以为备份做了就万事大吉，真要硬盘坏了，可能丢整整一周的用户数据。

比如上线新功能的时候，为了赶版本，把权限校验的代码注释掉，想着“等上线稳定了再加回来”，然后转头就忘了这茬。

这些都不是什么需要高深技术才能发现的风险。就是你在敲代码的过程中，每一次抱着侥幸心理省掉的步骤，每一次觉得“没人会那么闲钻这个空子”的判断，最后都会变成某个凌晨弹出来的红色报错，变成财务群里的损失明细，变成你要熬大夜填的坑。

我现在排查风险的时候，根本不用什么高大上的扫描工具，就坐在工位上，把整个业务流程在脑子里像放电影一样过一遍：如果这个接口的下游服务突然延迟10秒会怎么样？如果同一个请求被恶意重复发送100次会怎么样？如果用户在支付的最后一步直接把浏览器关了，过半小时再回来，系统的状态会不会乱？

就这么简单。

真的没那么玄乎。

别把风险识别做成“一劳永逸”的档案

很多公司对技术风险识别的误解，真的太深了。

总觉得花一两个月时间，拉团队做一次全面排查，出一份厚厚的报告，把所有能想到的风险都列出来，配好应对方案，这事就算做完了。把文档往共享盘里一存，再也没人翻，直到下一次故障爆发，才想起来之前的报告里好像提过这个问题。

但技术环境是天天变的啊。

我们去年做用户系统风险排查的时候，当时花了整整一周，梳理出来的最严重风险是“用户密码数据库泄露”，为此我们还专门把所有用户的密码都换成了加盐哈希存储，花了快十万块做安全加固。结果今年我们接入了第三方微信登录、支付宝快捷登录，新的风险点马上就来了——如果第三方的登录接口权限校验出问题，别人能不能伪造登录态，冒充任意用户拿到账号里的所有信息？这个风险，是我们去年做排查的时候，根本不可能提前想到的。

上个月我们组的年轻同事，为了赶版本上线，把一个内部用的用户信息查询接口的权限校验给临时注释了，想着“等上线了就加回来”，结果上线之后转头就忘了，整整三天时间，这个接口在公网暴露着，谁拿到链接都能查到所有用户的手机号、收货地址和订单记录。还好是我们日常做接口巡检的时候扫到了，不然被爬虫把数据爬走，那造成的损失，可比之前重复充话费的事大多了。

说白了，技术风险识别根本不是什么需要一次性做完的项目。它更像你每天出门前摸一遍口袋，确认钥匙、手机、门禁卡带没带，不是你摸一次，就能管一辈子的。

我现在特别反感市面上那些卖“风险识别解决方案”的厂商，吹得天花乱坠，说一套工具就能把所有技术风险都扫出来，能帮企业省掉多少事。真要是那么有用，为什么之前我们花大价钱买的安全工具，连那个暴露了三天的无权限接口都没扫出来？

说穿了，那些工具能扫出来的问题，都是已经被写进规则里的老问题。那些藏在代码缝隙里的、因为赶需求临时加的、因为图省事儿省掉的、因为业务迭代新出现的风险，永远需要写代码的人自己上心。

上次故障之后，我们组每个人工位上都放了个巴掌大的小本子，每次写代码的时候，只要觉得这里留了个“可能出事”的口子，就随手记下来，每周开15分钟的短会，把这些点拿出来过一遍，能补的马上补，补不了的就列成待办跟进。现在那个小本子已经攒了快半本了，之前那些看起来“根本不会出事”的小疏漏，一个个都补上了。

哦对，那天凌晨在机房啃的凉包子，我后来扔的时候，油渗了一整个塑料袋。现在每次路过机房门口，我都能想起那个嗡鸣的夜晚。

毕竟所有的风险识别，最后都不是为了写在报告上给领导看的。是为了下次再在机房蹲到凌晨的时候，手里拿的不是凉包子，是刚买的热咖啡。