关于发布事故,总结为三点:

      

   (1)人的因素

       避开态度问题。凡是人为操控的事务,必会有遗漏,在所难免,但要切忌同一个地方跌倒两次。

    (2) 测试环境

        很多特殊场景无法在黑盒下发现,好在开发人员一般会预知到大部分可能出问题的坑(毕竟都是我们码出来的)。我们可以想办法

      搭建环境,并告知测试关注这些风险/敏感点,进行模型化的验证。

         我的观点,产品质量是需要研发打造,测试并不能提高代码质量,相反,有了测试这关,若管理机制不完善,开发可能更加放松警惕。

 (3)发布机制

        大部分初创企业的情况:

       a、各个开发人员均可以进行正式环境发布,不好控制版本节奏,导致频繁发布,发布越多,故障几率也相应增多。

       b、测试环境只存在一个版本保留,测试人员的环境和开发的环境几乎一致,虽然“加快”了发布进程,但实际情况可能是:

           。测试人员没有自己干净环境,数据存在开发调试数据的污染,这对场景化验证非常不利。

           。测试趋于形式化,开发提交给测试的版本即在开发看来是可上线的版本,并且要做好版本保留,目的是避免测试人员测试的版本和开发分支版本污染,道理同上。

       c、流程

             这边有如下场景分享:

            在原团队初期,

           开发人员开发完成功能后,经过测试觉得完全没问题,为了保险起见,通知了测试人员,XX功能我开发好了,验证一下是否有问题,

          测试人员拿到开发“精心准备”的版本,经过测试,发现问题不大,于是告知相关人员可以发布。开发人员很开心的将程序发布到了正式环境,

          同时通知了相关人员,版本发布成功,目前运行稳定。

            然而系统经过一定时间的运行,比如刚好是开发人员回家洗漱好,正在庆幸终于可睡觉的时候,收到系统已经快崩了,开发人员一听现象,哎哟,

        完了,有个地方判断写错了,于是又赶紧起来修改代码重新发布,再观察,直到问题解决...

         

         研发团队吸取了上次的教训,将流程进行了重新设计,将开发、测试、发布职责分离,期望各角色的相互监督来规避一些问题,将问题发现在前期。

        

         开发人员按计划完成版本开发工作,经过验证并提交了测试, 然后就可以投入到下个版本的开发中。

         测试人员在收到开发人员提交过来的版本包后,他们根据实际的时间规划,将包发布到了测试环境, 整体测试下来, 并无重大影响流程的情况,于是通知XX版本具备发布条件。

         发布人员收到测试人员的测试报告和产品经理、研发经理的确认信息后,通过工具一键部署到了正式环境。

         产品发布后,测试人员,产品经理 在线上环境进行了一些基本的case验证,发现并没什么大问题,于是宣布本次版本升级成功。

           效果确实很奏效,低级问题少了很多,然而,线上还是经常出现各种bug,最终导致各种补丁版本齐飞的现状,更致命的是,重大事故下没有很好的回滚机制。

         

           研发团队再次吸取经验教训,在各环节都设置了回滚机制,出现重大问题,实在无法快速解决,我们可以先回滚,变相解决了很多突发问题,

         然而,有一天,某一个功能修改了数模结构,当出现了突发故障,开发团队如法炮制,进行了回滚,然而悲剧的是,数据无法回滚了,并且数据混乱了....

           研发团队再次坐下来商量,有没有一个合理的机制来彻底避免类似问题。 经过商量,研发团队决定走 预发布机制...

         以上场景虽然比较粗糙,但生动反映了一个研发团队的采坑/改进过程,即机制带来的改变。




总之,出现事故不可怕,我们吸取经验教训,是人的问题处理人,是机制的问题,改变机制,效率的问题多采用工具!


本文版权归作者,欢迎转载,但未经作者同意必须在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。