记一次惨痛的线上bug

  讲述背景,刚入职新公司2个月的时候,接手一个红包系统。资历尚浅,对业务也不是很熟悉。公司开发新的平台,需要使用红包功能来进行推广,按照产品的需求,进行开发。。。然而,问题就出在这里,红包接口比较陈旧,许多代码并有过多注释(甚至多出注释不全,注释出错),接口参数参差不齐,看的很累。

  起先,将系统中所有调用红包的地方,都改成调用我的红包系统。和某端联调时,出现各种bug,参数无规约,返回参数不明确,(不知道要返回些啥,无明确需求文档),最后还是某端哥们,将原来的sql提供给我才得以解决此问题。

  接着为某端提供接口,内部对接时,新增许多需求,旧接口不支持。于是新增了新的接口,啪啪啪撸完代码,接口提供出去。先是被次端开发吐槽代码参数大小写时大时小(泪奔,我不能因为你们一个端去乱动历史代码啊,这接口我们也不清楚多少人在使用,历史参数问题请吐槽以前的前辈吧),其次接口提供完,大概半个月之后,开始联调,出现几个不知名的bug,经过定位,发现代码中处理逻辑太多,好多都过不去,于是为此端另辟新接口方法。刷刷刷,测试通过了,没有问题了。准备上线了,Duang!!!重点来了,产品零时提出需求,要求用户第一次登陆时,提示用户领取红包,每台设备每用户只能领取一次。需求很合理,我看了下代码,代码中原来就用这种逻辑判断,内心狂喜,直接拿来使用,BOOM!!!BOOM!!!BOOM!!!问题来了,原来的代码逻辑上有问题,有漏洞,当用户使用玩次红包之后,是可以再次领取的。天哪,当时自己也没注意到这个细节,自测的时候完全没问题。而测试去测试的时候,并没有考虑这种场景,结果测试通过,程序没问题~~~上线。。。

  平稳度过一个星期,接着瞬间爆炸,700多个10元红包,被同一个人刷走了,炸了,真炸了,我整个人都蒙逼了,wtf!!!,赶紧查代码,一查果然,这个旧的逻辑里面状态漏了一种,玩完。按理说,红包还有各种使用限制,好家伙,这家伙利用我们另外一个平台,未校验红包的bug,刷了个精光。我的天,欲哭无泪啊。。

  然后呢,通过这件事情呢,我想说的是,对旧代码,一定要仔细看!!!要仔细看!!!仔细看!!!关于钱的项目一定要仔细,认真。任何代码不论它已经上线多久了,也不论多稳定,都不要相信它,你一定要好好扒开它的,仔细看每一个细节,思考每一个逻辑。不是不出问题,只是时候未到。拿我这件事来说,此代码发布于2015年3月,以稳定运行1年多,然后他依旧出了问题,而代价就是7000多元的损失,这简直就是致命的。

  最后,愿每个程序员都能处理好代码,协调好工作,大家多抽出点时间,来讨论方案,而不是让一个人,两眼摸瞎,改个代码,怕这受影响,哪里受影响,简直了~

时间: 2024-10-13 20:53:22

记一次惨痛的线上bug的相关文章

快速定位iOS线上BUG在哪个控制器崩溃

快速定位iOS线上BUG在哪个控制器崩溃 快速定位iOS线上App崩溃在哪个控制器里面,需要和后台配合使用 下载本项目并添加手动添加到项目里 新建所有的页面都继承于YZViewController 在AppDelegate的didFinishLaunchingWithOptions方法里面写下如下代码: if ([[[NSUserDefaults standardUserDefaults] valueForKey:@"BUG"] isKindOfClass:[NSDictionary

Android线上bug热修复分析

针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现.重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的 关于Hot Fix技术 Hot Fix技术,简单来说就是针对线上已发布app出现了bug,在不推送新版本的情况下通过发布修复补丁进行修复.通常是刚上线的app,需要快速线上修复bug,类似的技术就叫做热修复或热补丁. 热修复技术能带来什么 让app具有了上线后被修复的可能性,增加事故风险可控性: 避免为修复bug而快速增发新版本,让

听说”双11”是这么解决线上bug的

--Android线上热修复的使用与原理 预备知识和开发环境 Android NDK编程 AndFix浅析 Android线上热修复的原理大同小异.这里仅仅针对眼下最火的框架AndFix进行解说.主要从AndFix的使用.原理以及优缺点三个方面进行阐述. 使用方式 介绍 AndFix是一个AndroidApp的在线热补丁框架. 使用此框架,我们可以在不反复发版的情况下,在线改动App中的Bug.AndFix就是 "AndroidHot-Fix"的缩写. 就眼下来说,AndFix支持An

【MySQL 线上 BUG 分析】之 多表同字段异常:Column ‘xxx’ in field list is ambiguous

一.生产出错! 今天早上11点左右,我在工作休息之余,撸了一下猫.突然,工作群响了,老大在里面说:APP出错了! 妈啊,这太吓人了,因为只是说了出错,但是没说错误的信息.所以我赶紧到APP上看看. 这果然是出错了,而且还是简单而粗暴的500,太吓人了. 二.本地赶紧调试起来! 既然线上出错了,我们又不能直接进行调试,那当然得马上在本地搞起来了! 1.代码是否有错? 立马启动本地的项目,访问对应的接口,看看是不是代码哪里出错了. 好了,本地的代码和 SQL 都是没错的! 2.SQL 是否有错? 那

对线上系统维护工作的总结与思考

背景描述:目前在一家网站公司工作,2015年初研发中心部门改革,小组重组,被分配到了网站平台的维护组.下面内容是对近期维护工作的一个总结: 个人感受:以前也在老东家的团队也做线上系统的维护和新产品的研发,由于大家的认真负责,Leader的管理也很到位,线上的系统很少有bug反馈,不管是UI上迭代,还是系统逻辑的升级都很顺畅. 目前负责的平台运行了3年多,可能由于当时逻辑设计问题,也可能是执行问题,发现近期反馈的问题多是逻辑问题,在此对这些问题的原因不做探讨和深究,只是想讲讲面对线上问题的维护工作

chrome浏览器调试线上文件映射本地文件

通过ReRes让chrome拥有路径映射的autoResponse功能. 前端开发过程中,经常会有需要对远程环境调试的需求.比如,修改线上bug,开发环境不在本地等等.我们需要把远程css文件或者js映射到本地的文件上,通过修改本地文件进行调试和开发.通常我们可以通过以下方法来实现映射: 1.修改host文件——只能把域名映射到IP 2.使用Apache或者nginx搭建反向代理——需要装环境,配置相对繁琐 3.使用Fiddler中的AutoRespnose功能——不支持目录映射,mac.lin

关于线上故障的思考

周末早上,一个哥们突然@我,问是否有线上故障处理和定级的规范或者模板,虽然手头有既有文档,但内容显的太具象了,跟我们的业务有很强的关联性,并不是那么好直接复制到他的团队中.因此,个人对过去的线上故障处理进行了回顾和思考,并进行了简要的归纳,望帮助到需要的同学.文本将按事中处理.事后总结和事前预防的顺序进行介绍,不足之处望大家不吝赐教. 换个角度来说,其实故障处理的过程,和小朋友发高烧的处理过程类似.首先mama会带孩子上医院,如果温度高医生会要求打退烧针,类似发布回滚,之后再通常吃对症的药物慢慢

一次惨痛的搬砖总结--线上管理服务器迁移

为什么有这次迁移,主要是因为年前针对nagios的扩展做了很多研究测试,希望应用到生产环境中去,但是生产环境的nagios所在服务器是个集中的管理服务器,上面运行了很多开源软件,而且大部分都是前人安装部署,结构已经固化,坑太多已经无法扩展;其次管理服务器操作系统版本为Centos5.4,老实说现在很多软件在6x的系统上安装起来比较方便,默认环境基本都能满足各种开源软件的运行,而且线下测试都是在6.5的系统上测试的.最后是因为管理服务器太老了,害怕哪一天Down了,虽然配置文件每天都有备份,但是软

线上应用bug跟踪查找-友盟统计

线上的应用只要用心点点都能发现些bug,连微信,QQ也不列外.但是bug中最严重的算是闪退了,这导致了用户直接不能使用我们的app. 我们公司是特别注重用户反馈和体验的,我们会定期打电话咨询用户的使用情况.我们也有自己的天使用户群,这些用户会跟我们及时的反馈应用的使用情况,bug情况,还有他们的需求. 用户不是技术人员他无法跟你清楚的描述怎么产生闪退的,于是我们需要一个bug统计的功能,我们公司采用友盟统计实现bug的记录.我们在iOS应用中植入友盟统计的功能,我也经常在查看友盟的错误统计和错误