当前位置:首页 > 科研成果库

踩过三次生产事故坑才懂:技术风险识别不是找bug

2026-10-09 04:50:04小研科研成果库8

去年9月23号,我在南京江北的产业园运维室,啃着凉掉的鸭血粉丝汤。突然,办公群里弹出一串红色警报。整个生产区用户登录服务挂了。那滋味,真疼。

最后查下来,不是我们写的代码有bug,是我们上线新功能的时候,漏算了一个不起眼的技术风险:新上的用户标签同步,峰值流量是预估的17倍,直接把消息队列撑爆,把整个用户中心的线程池拖垮了。那次赔了合作方十几万,整个团队连着熬了三个通宵改方案。从那时候我才明白,很多人对技术风险识别的理解,从根上就错了。

互联网生产事故技术风险排查现场图互联网生产事故技术风险排查现场图

别把技术风险识别等同于找bug

我见过太多团队,上线前走风险评审,翻一遍测试报告,所有bug都改完了,就拍板说没问题。真的没问题吗?

bug是代码写错了,功能不符合预期,这个测试能测出来。但技术风险,是你整个架构、链路、依赖里藏的“不定时炸弹”,它不在你的功能逻辑里,甚至不在你负责的这块代码里。你测试环境流量只有几千,测不出生产环境几十万流量来的时候扛不扛得住。你测试环境只有几个测试用户,测不出真有万级标签的头部用户进来的时候,你的循环会不会卡死。

m

我之前听同行说过一件事,某电商平台改商品详情页的按钮颜色,改完测试全过,上线之后半天没拿到点击数据。为啥?改颜色的时候,前端顺手改了按钮的class名,第三方统计的埋点是靠class定位的,全瞎了。你说这是bug吗?代码写的没错,颜色也改对了,就是没人想到改个class会把统计埋点搞挂。这就是典型的没识别到技术风险。

很多事故出了之后,大家复盘都会说“怎么会这么巧”,哪有那么多巧合,都是风险埋在那,你没看见而已。

真正要识别的,是你看不见的关联

现在哪还有什么单体应用,全是分布式,你一个小功能,上下游可能关联十几个服务,有的是别的部门维护的,有的是好几年前的老代码,连文档都找不到。你只看自己这块,当然看不见风险。

分布式系统依赖链路技术风险识别图分布式系统依赖链路技术风险识别图

我之前总结过,九成以上的重大技术风险,都出在依赖关联上。要么是你依赖别人,别人出问题把你带崩,要么是别人依赖你,你出问题把全链路带崩。我见过最离谱的一个案例,某个公司的内部配置中心改了一个超时参数,把所有依赖它的业务线全搞挂了,整整两个小时恢复不了。改参数的人说,我以为这个参数只影响我自己用的那个服务啊。

怎么把看不见的关联挖出来?说穿了也简单,你上线改任何东西,先画个简单的链路图:你调谁,谁调你,你把数据传给谁,你从哪拿数据,每一个节点都列出来。就像你装修改电线,你得先搞清楚这根线接了哪些电器,不能上来就剪。对吧?

很多人嫌麻烦,说都是老业务了,能有什么问题。老业务才容易出问题,半年前加的依赖,谁还记得啊。我上次帮新人做评审,他改一个支付回调的逻辑,翻了半天文档,才发现有三个下游业务在吃这个回调数据,其中一个还是一年前和第三方合作留的,对接的人都离职了。要是直接上线,支付数据不同步,亏的钱找谁补去?

普通开发也能直接用的两个笨办法

普通开发也能直接用的两个笨办法普通开发也能直接用的两个笨办法

别觉得技术风险识别是架构师或者运维的事,你写的代码你上线,你自己不上心,谁能帮你盯?我从几次坑里爬出来之后,攒了两个方法,不用复杂工具,花不了半小时,次次都能挖出点东西。

第一个,反向提问法。别顺着想“我的功能怎么才能成”,反过来想“我的功能在哪里会炸”。每次上线前,问自己三个问题:

第一,如果我依赖的服务挂了,我能不能正常运行?会不会把错误扩散出去?第二,如果流量是我预估的十倍,我扛不扛得住?第三,如果我输出的数据错了,最远会影响到哪里?

就这三个问题,我最少有三次提前挖出了风险。有一次做营销活动,我问完第一个问题才发现,我们依赖的第三方短信接口,给我们的限额是每秒一百条,活动预估每秒要发五百条,提前找人家扩容,直接躲过一次事故。

第二个,找个外行人问一句。什么意思?就是找个别的组,不碰你这块业务的开发,让他看看你的方案,问他觉得哪里可能出问题。别觉得人家不懂,就是因为不懂,才会问出你根本想不到的问题。你天天盯着这块,思维早就固化了,所有默认的前提你都觉得理所当然,外人一开口就能给你戳破。

我上次做那个用户标签同步,就是一个新来的测试小姑娘,什么都不懂,问了一句“要是一个用户有一万个标签,你这个循环不会卡死吗?”我那时候默认一个用户最多一百个标签,查了一下库,真的有三个头部大V有接近一万个标签,提前加了分页截断,不然那次事故说不定更严重。说实话,这个方法真的百试百灵。

不过话说回来,技术风险识别也不是要把所有风险都消灭。你要是为了找风险,三个月不上线,那也没必要。任何事情都有边界,内部工具就不用按照面向亿级用户的标准来,小功能的风险也不用兴师动众开一下午评审。

核心逻辑就一条:会影响用户正常用、出了要赔钱的风险,挖地三尺也要找出来。无关痛痒的小问题,留着迭代也没关系。你多花半个小时找风险,省下来的是熬夜抢修、给老板道歉、赔违约金的一堆破事。

那次南京的事故之后,我们团队把上线前15分钟风险排查改成了强制要求,到现在快两年了,没出过一次影响核心业务的大事故。我现在周末能安心在家睡觉,不用盯着手机怕群里弹红警报,想想真的赚了。做技术,冲指标做新功能是本事,把藏在暗处的风险找出来,更是本事啊。