博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
一个sql脚本引发的灾难后的思索
阅读量:6693 次
发布时间:2019-06-25

本文共 844 字,大约阅读时间需要 2 分钟。

今天下午同事在PRD数据库服务器上更新了一个脚本,没有想到的是,本来很平常的一个操作,却导致了灾难性的后果,由于我们系统前不久改变了同SAP交互的方式,以前通过另外的中间接口访问SAP,最近进行了迁移,换了个接口程序。可是我同事的脚本更新后不久,用户就发现订单中有些产品被莫名的更改了,订单上开始选择的是芝麻油500箱,结果后来生成订单后发现变成了橄榄油500箱,虽然后来我们发现后马上进行了进一步的验证,而且没有发现大量的错误数据,只有一家用户,下了一个订单出现了问题。风险范围比较小,大家总算松了口气,马上进行了修复,并进一步进行了再三的Check,但是也暴露出了一个问题。事关这种全局性的修改,我们没有严格的进行测试,并且审查,所以出现了这种紧急情况。所幸的是最终造成的损失并不大。

但是通过这次的事件,也暴露了我们开发中的一些薄弱环节,比如测试不过,对于这种事关系统全局的更改,没有进行严格的代码审查,在PRD环境执行时,也没有仿真环境测试,开发人员完成后,进行了一次确认后,特别是这种数据库脚本的执行,就简单的做了些测试就直接执行了。有时候简单的看看是看不出问题的,而且测试时如果没有考虑全面的话也测试部出来,因为这次并没有导致所有的数据出错,仅仅只是特殊的情况下有问题。所以流程的管理在某些 方面还是有漏洞。关于系统全局,关键性的修改,在开发人员完成开发后,自己先做完单元测试,相关同事一定要仔细的做验证,并Review代码,然后由同事再次测试,测试通过OK后交给测试组进行全面的测试。对于这种事关全局的更改,即使是一个小小的脚本,也要有测试用例,而且要全面的测试,同事在PRD环境执行前,一定要在一个和PRD环境最接近的仿真环境再次进行测试,并确认OK后方可在PRD环境执行。古人云:失之毫厘,差之千里。绝对的真理啊。下次一定要谨记了。

转载于:https://www.cnblogs.com/kevinGao/archive/2012/08/30/2671007.html

你可能感兴趣的文章
一个resin启动bug的解决
查看>>
571B. Minimization(Codeforces Round #317)
查看>>
Ubuntu查看端口占用情况
查看>>
『科学计算』最小二乘法
查看>>
Bootstrap缩略图
查看>>
Android之实现ViewPager+Fragment左右滑动
查看>>
android开发艺术探索学习 之 结合Activity的生命周期了解Activity的LaunchMode
查看>>
linux系统下用到的小知识点积累
查看>>
工作中的感悟 (三)三个月碎碎念篇
查看>>
第三百一十节,Django框架,模板语言
查看>>
关于游戏行业目前的形势
查看>>
Struts2+Spring+Hibernate+Jbpm技术实现Oa(Office Automation)办公系统第一天框架搭建
查看>>
POJ 1655 Balancing Act(树的重心)
查看>>
Loadrunner IP欺骗
查看>>
大型站点架构体系的演变(上)
查看>>
Linux-中断的本质
查看>>
Spring定时器注解配置
查看>>
springboot跨域请求设置
查看>>
TeamViewer远程唤醒主机实战教程(多图)
查看>>
pat(B) 1037. 在霍格沃茨找零钱(水题)
查看>>