由于部门没有测试团队，只有开发和运维，开发自己写程序，然后自己进行测试，OK了，就交给运维发版本变更。
本次是同一个模块，开发完成测试后，灰度了几台机器，我与开发同事一起进行观察，起初就觉得内存使用不太正常，内存占用一直在增加，让开发同事查看是否有问题，他看了后，很自信的说正常。当时没多想，虽然心中还有些疑虑，不过开发自己都说正常了，我还担心什么？没多想，就一次给全网变了。
没过几天，问题来了，每台机器内存使用直线上涨，赶紧拉开发问影响。给出的答案是，当时他没发现代码里有一处内存泄露的bug，内存耗尽会导致服务进程重启。他很快改了代码，但我没让立刻发布版本，这次必须很谨慎，多观察观察，结果观察的时间有点长了，缺乏全局观，本来观察了一个星期，准备全网变更的时候，脑子一想，这次绝对不能再出问题，还是再观察观察，就在全网机器中变更了20%的机器，准备再观察几天。结果人品大爆发，到周六的时候，几台机器进程异常，大概看了下，我怀疑是内存问题导致的，开发也不知道怎么看的，非说是其他问题引起的。真是不想把同事关系搞僵。没再追究，后来又有几台机器出现同样问题，找另一个开发同事定位原因，确认是内存问题导致。于是赶紧对未变更的机器换新版本。当时就在后悔，干嘛周五的时候不变完，这些可好，没观察出问题，却等到了bug的爆发。这次版本发的太被动。
从这次事件中也要吸取点教训，避免以后大半夜被迫发版本！
1、发现问题时，不要只和当事人私自讨论解决。这样会很片面，很多人也不知道事实的真相。最好在你发现是比较严重的问题的时候，拉上对方和自己的上司。
就像这次发现内存使用异常，只是跟开发同事在讨论，可能开发同事对自己写的程序信心满满，不把你提出的问题当回事，我没有把问题摆出来给大家，后面leader问到当初灰度怎么没发现bug的时候，那叫一个委屈。处世方式欠妥。
2、下次再遇到类似第一个版本完成变更后发现bug,也要观察适当时期就好了，要记住，不能因为等待观察新版本的bug，而忘记了还有一个已知的随时可能爆发的bug在那里蠢蠢欲动。
一个模块短时间内多次发布版本是需要谨慎，但有时候要分清楚状况，有的bug确实不能等，这个要在发现bug后，和相关同事评估影响bug爆发后的应对措施。不能因为担心新版本又有bug，就提出能观察就多观察一段时间的想法。有时候会误了大事，新bug什么时候能等到？还是先把已知的bug解决掉再说，当然也不能解决bug的新版本一出来，就立马想变更，要评估适当的观察时间，配合开发进行有效测试。尽快确认是否无问题，好尽快解决已有的bug。
阅读(915) | 评论(1) | 转发(0) |
