一次不该出现的bug

简介:   部门好久没有出过事件了,ps:事件可以简单的理解为bug,事件分为5个类别,其中严重的是1级,灾难性的。但是这次是天灾,避免不了。      首先说说我们发布程序的过程,首先程序员发布到测试环境,测试人员测试通过,然后发布到uat,业务人员接着测,这个地方其实是很薄弱的,uat环境缺失很...

 

  部门好久没有出过事件了,ps:事件可以简单的理解为bug,事件分为5个类别,其中严重的是1级,灾难性的。但是这次是天灾,避免不了。

     首先说说我们发布程序的过程,首先程序员发布到测试环境,测试人员测试通过,然后发布到uat,业务人员接着测,这个地方其实是很薄弱的,uat环境缺失很多数据,有的地方根本没有办法测,最后测试人员点通过,项目经理上生产,这个时候也不是直接上生产的,项目经理会告诉发布人员这个站点可以发布了,发布人员会从集群里面拉出一台机器做堡垒,把最新开发的代码发布到堡垒机上测试,堡垒测试还是测试人员来测的,只不过这个时候访问的是真实生产环境的数据,用的账号也是真实生产环境的账号。当然这个地方只是冒烟测试,不会测的很细致,因为在测试环境会测很长时间,虽然是黑盒但是会测的很细致,所以在生产环境上只是走一走常规流程。

  整个过程是没有什么问题的,但是在某些情况下就不行了。offline预定站点访问量相对较少,注意只是相对。只有两台机器,如果拉一台出来做堡垒机,那客户所有的访问都会瞬间涌入到另外一台机器上,这个时候会暴漏出一个问题,504 gateway time-out,不用我解释你们可能已经清楚什么问题。

  拉出来的这台堡垒机只有那几个测试人员在上面访问,绝对不会报这个错误,但是剩下的那台生产机就不一样了啊,相当于两个人的担子现在一个人来挑,于是它就罢工了,一直报504,堡垒测试的时间超过1小时,意味着这1个小时它完全趴下了,客户报修一个接着一个,完了,一个一级事件出现了。

  你可能会疑问,测试人员如何在堡垒机上测试,如何保证自己测到的是最新的代码,答案是host,测试人员在自己host上指定堡垒机的IP地址,这样访问到的站点会映射到堡垒机上。

  开发的技术很重要,测试很重要,流程也同等重要,一个大的站点不可能发布了,直接拷贝到生产环境就了事了,测试工具,发布工具,日志都是缺一不可的。但是不管怎么说问题还是会不断地出现。

作者:Tyler Ning
出处:http://www.cnblogs.com/tylerdonet/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,如有问题,可以通过以下邮箱地址williamningdong@gmail.com  联系我,非常感谢。

目录
相关文章
|
SQL JSON 前端开发
【改BUG】项目遇到的奇葩bug
【改BUG】项目遇到的奇葩bug
|
16天前
|
SQL 运维 Java
记一个折磨了我一天半的 Bug
一杯茶,一根烟,一个 Bug 一天根本改不完。
28 1
|
5月前
|
供应链 测试技术
修复糟糕的代码气味
修复糟糕的代码气味
58 11
|
6月前
|
人工智能 网络安全 Python
一篇普通的bug日志——bug的尽头是next吗?
[bug 1] TypeError: ‘method’ object is not subscriptable 问题代码:
128 0
一篇普通的bug日志——bug的尽头是next吗?
写了个全局变量的bug,被同事们啪啪打脸
前阵子写了一个功能,测试 0 bug 就上线了,上线后也运行好好的,好多天都没有人反馈bug,超爽。。 不出问题还好,出问题就是大问题。。
|
缓存 JavaScript 小程序
接手前同事代码,特别烂,各种BUG,看麻了。。。
接手前同事代码,特别烂,各种BUG,看麻了。。。
|
Python
遇到bug不要慌,先发个文章看看
遇到bug不要慌,先发个文章看看
128 0
|
Java 中间件 程序员
最网最全bug定位套路,遇见bug再也不慌了
最网最全bug定位套路,遇见bug再也不慌了
315 0