我的亲历:一行代码,百万人民币打水漂!

点击上方“芋道源码”,选择“设为星标

管她前浪,还是后浪?

能浪的浪,才是好浪!

每天 8:55 更新文章,每天掉亿点点头发...

源码精品专栏

 
  • 01 一次寻常的发布

  • 02 故障发现和止血

  • 03 事件缘起和善后

  • 04 我的感受和思考


大家好,我是艿艿~~~一个每天肝到 2 点钟的小胖子

最近在和朋友一起肝一个 SpringBoot2.4.2 + Vue 的开源项目:

https://github.com/YunaiV/ruoyi-vue-pro

记得 Star 关注下噢,胖友们的支持,真的很重要!

几年前,刚进入职场,作为程序员走上了技术这条路,不久便亲身经历了一件特别震撼的事情。那是一行代码引发的线上故障,故障造成了百万级的资金损失。时至今日,我依然印象深刻,也正是这件事,让我在职业生涯初期就形成了敬畏代码,严谨做事的态度。时间过去的比较久,我脑海里的细节也存在失真。我将尽量还原事件的重点信息,分享我的感受和思考,希望能带给你启发。

01 一次寻常的发布

如往常一样,又来到了一个发布窗口,这次发生变更的迭代很简单,是支持全链路压测的一个功能上线。

我们团队负责的是一个底层核心系统,链路上会有上百个应用依赖,为了应对大促这种超高流量的场景,大促前有一轮又一轮的压测。在首轮压测时,便发现我们的系统上有个数据库表不支持压测,导致压测计划无法进行。因此团队有位同事 A 就起了紧急迭代,针对业务依赖的这个数据库表做压测改造,代码变更也就几行。

与此同时,同事 B 在这个系统上也想改下代码,就搭了压测改造的车,两块变更一起发布。

同事 A 负责走发布流程,我们的系统有几百台服务器,部署会分为好几组,通常会搞到很晚。那天晚上,我也和大家一样,回去的比较晚,而且还忘带了手机充电器。

回去没多久,我的手机就自动关机了,想着第二天到公司再充电。

02 故障发现和止血

到了公司,给手机充上电后,就知道出事了。有大量客诉,并且出现排队现象,同时上游系统反馈有个错误码上午开始增加的特别多,一切迹象表明:对业务产生的一系列影响和昨晚的发布有关,同事 A 果断进行了代码回滚,避免了午高峰来临时将影响扩大。

代码回滚后,上游系统之前异常的错误码逐步恢复到基线水平,客满的同事也反馈不再有新的投诉进来。至此,止血工作完成。

03 事件缘起和善后

接下来就是定位原因和善后工作。团队内部仔细看了下本次发布提交的代码,再结合上游系统感知到的错误码,就定位到有一行代码的变更,影响了整个逻辑。

这行代码被同事 B 改成了 「return null」,而老逻辑是有具体数据的时候会返回实体信息,没有才返回 null。 这个结果信息的变化,直接影响了上游的交易,从而商户收款紊乱,引起大量客诉,也造成了资金不平。

善后工作主要就是调账,安抚商户,差额的部分平台补足以及故障定级和整体复盘。调账的前提是,能知道哪些订单有问题,故障期间每个订单错误的收款户是哪个,实际上应该是哪个。产出这样一份数据是很复杂的,涉及很多业务和很多团队,光拉本次故障受影响数据就花费了一周以上。

受影响数据拿到之后基本就能知道资损的量级,也可以基于此给受影响的用户赔偿,同时给故障定级。最终资损百万级,故障级别也相当高,高到故障不能往一线员工身上挂,只能往管理层上挂。

事后就有一大帮人参与复盘,拷问本次发布的各个环节是否符合规范。有没有代码 CR,有没有测试,有没有灰度,有没有监控,有没有核对。我发现好像该有的我们都有,但事情还是这么诡异的发生了,并且是被迫发现。

诡异之处就在于同事 B 也不知道有提交过那行「return null」的代码,能找到 CR 截图但并未覆盖到那一行代码,测试只关注了压测改造的变更并没有关注到搭车的内容,灰度发布又在晚上,感知不到业务异常,监控核对有报警,但平常比较关注的我在当天刚好手机关机。

由此看来,故障的直接原因是同事 B 的代码误提交,但事实上在提交后的各个环节里都有疏漏的地方。不久之后,同事 B 和负责测试的同事就离职了。他们不需要为公司承担资金的损失,但会因此事得到不好的绩效,这可能是他们离开的原因。

04 我的感受和思考

亲历了这么一次大故障,让我感受到代码的强大,强大的影响力和破坏力

「敬畏代码」不再是耳边的循循教导,而是要落实到工程实践中。对待代码的盲目自信,也渐渐转变成只相信测试结果。代码是人敲出来的,人会犯错,但机器不会。 编写的代码不仅要经得起理论的推敲,也要挺得住实践的检验。不能想当然,每当心存侥幸的时候,你觉得不会发生的事情它还真的就会发生。严谨做事,应当成为职业工程师的基本素养。

另外就是规范的重要性。什么是规范?规范是明文规定或约定俗成的标准。人总会有疏忽,大脑会有停转的时刻,实际执行也有遗漏的时候。遵循规范,人的不可靠带来的影响可以限制在一定范围内,大大减少出错率。 规范的制定,执行,调整,能够提升效率,降低风险,避免类似这次故障的低级错误。



欢迎加入我的知识星球,一起探讨架构,交流源码。加入方式,长按下方二维码噢

已在知识星球更新源码解析如下:

最近更新《芋道 SpringBoot 2.X 入门》系列,已经 20 余篇,覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例,以及超 4W 行代码的电商微服务项目。

获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。

文章有帮助的话,在看,转发吧。
谢谢支持哟 (*^__^*)
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值