至暗时刻——记某项目的悲惨经历

原文链接:
https://segmentfault.com/a/1190000015409500


最近做了个项目,上线之后依次发现了三个线上bug,简直是我入职以来前所未有之事。感觉真的要被开除了。在此还原下整个项目的历程,希望能记录项目管理中失误的点,从而不再次出现错误。

1. 项目背景

1.1 参与者

clipboard.png

1.2 项目时间线

  • 4月13日 项目需求预讨论,定下了插件合作方A开发UI渲染,我方提供数据支持和上报的逻辑。
  • 4月17日 决定与广告商C方的应用逻辑,定下了通过referer确定广告来源的方案。
  • 5月25日 A方人员变动,广告被无限期延期,A方同时提出改版广告渲染逻辑,由我方提供广告组件库,全面接盘广告渲染的方案。
  • 5月30日 我方开发完成。A方临时有更高优先级需求,没有时间排期,联调时间被一拖再拖
  • 6月1日 C方接入联调,发现C方服务器是http链接,referer方案被迫改为url参数方案。C方一直想跑通全链路联调,但是因为广告后台测试服务器不支持外网访问,测试链路一直不通,必须要用截单方式。双方交流困难。
  • 6月7日 AB方初步联调完成,广告初步展示,但是A方还要改造广告相关插入逻辑。另外C方继续沟通缓慢,BC方联调完成,但是BD双方还要联调
  • 6月11日 A方还是没有排期,计划6月15-20日联调
  • 6月15日 AB方联调完成,C方还是开发中
  • 6月20日 BD双方联调完成,约定6月21日上线
  • 6月21日 C方发现在某些机型上返回文案过长会被隐藏,临时修改,导致上线时间改为6月25日
  • 6月25日 A方拖到晚上才上线,而且同时上线了手Q 70%-90%灰度和微信应用直达两个终端两个需求,B方没有意识到这两个需求会产生冲突,上线后手Q流量暴降,线上回退
  • 6月26日 B方紧急修复了手Q逻辑,A方重新上线,上线后发现广告无法点击,经查是CGI跨域,再次回退。
  • 6月27日 发现线上有IOS低版本广告图片展示不出来,经查是css兼容问题,再次上线。

2 项目中出现的问题

产品侧:

  • 多方合作时间点没有把控好,持续时间太长,拖掉了所有buff时间

开发侧:

  • 没有进行全链路测试就匆忙上线了

项目的质量永远是第一位的,上线之后回退还是赶不上时间点。要尽量进行全链路测试,充分明确全链路测试的必要性。

  • 没有进行整体的谨慎的思考,未了解到多端冲突的问题

项目开发前就要仔细考虑会影响的情况,尽管这次手Q和微信的冲突更多的是需要A方的同学提醒。但是最好也能考虑到

  • 项目中的问题没有引起警醒

曾考虑到会有跨域问题,但是没有去确认,也没有及时提醒测试同学注意。而测试同学因为要截单的缘故,在fiddler里设置了跨域头,略过了这个问题。

H5前端的几个经典坑:跨域,缓存和兼容性

把fidder截单加上判断条件,防止其他跨域被忽略。

    static function OnBeforeResponse(oSession: Session) {
        if (m_Hide304s && oSession.responseCode == 304) {
            oSession["ui-hide"] = "true";
        }
        // 添加跨域条件
        if (oSession.host.Contains("news.ssp.qq.com")) {
         oSession.oResponse["Access-Control-Allow-Origin"] =  "http://test.view.inews.qq.com";
         oSession.oResponse["Access-Control-Allow-Credentials"] = true;
        }
    }
  • 测试同学提出过兼容问题,但是没有引起足够的重视

测试同学口头提过某个机型上广告图片没有展示的问题,确认过是否必现,但是错误的将必现听成了偶现(我勒个去,这也能听错?!)所以以为是网络慢的原因,没有引起重视。

结果是flex引起子节点height:100%失效,导致图片的高度永远是0,这个问题现在只会在IOS10及以下的机型上出现,PC和Android(4.3以上)都表现良好。

还是要测试同学严格提测试单,同时重视测试同学提出的任何一个疑点

3 总结

这件事情上,我总结了一下项目是否要出现问题的特征:

  1. bug单上一个bug也没有
  2. 项目严重延期
  3. 合作方众多且联调困难
  4. 所有人都对项目有盲目的乐观

只要有以上的情况,项目多半是有问题没有测试到的。这次的责任主要在我,没有提前做好预警。想我刚入职的时候,老leader反复和我说:做项目未虑胜先虑败,做之前先想想哪里最容易出错。怎么干了这么多年,反而忘记了这个告诫。还是太不小心了。

从业4年,没这么惨过,回退一次都算事故,他妹的回退了两次,上线了三次,实在是惨绝人寰……

然后我扔掉了我的小猪佩奇,换了个新玩偶,希望能带来好运吧

图片描述

4 后记

2018-06-29日 20:30分 我在开车去往杭州的高速上,微信群里又叫起来了,说是有一个线上bug,会导致广告商C方没有点击数据。我得到这个消息的时候,我就在想,要是真的是我的锅,不然辞职算了。本来欢度周末的心情瞬间变得异常的糟糕,但是我又转念一想,线上出事故总比出车祸强。然后在嘉兴服务区,我强势接管了刚开了一小半的bug排查沟通会,当时的想法也很简单,死就死的有尊严一点——确实因为出了太多的事,已经不敢随意的甩锅了。谢天谢地,最后是广告后台D的问题。

图片描述

没想到还有很多小伙伴关注了这篇文章并给了我安慰,谢谢。这些都是自由水啊,说明其实项目管理也是大家在日常工作中很关注的一个点。针对这个问题,正文中还少提了几个点:

4.1 技术影响力的塑造

其实项目出现了很多问题,我最难过的,是技术影响力的崩塌。建一座大厦可能需要几年,毁掉它只要一瞬间。我们用了大半年的时间,刚刚培养了一点技术影响力,就在这次被摧毁的一干二净,而且这个后遗症可能还要延续很久。这也是我为什么萌生辞职念头的原因。真的很难过。

4.2 分分这个项目的锅

事情也过去几天了,这时候再来分锅应该算是心平气和了吧。首先,所有人都有锅,这是肯定的。

开发作为技术方案的具体实现者,占大锅也没问题。测试同学也有锅,但是鉴于新入职,开发同学又强势,担锅比例应该适当减少。产品同学在时间点把控、项目统筹上要承担主要责任。

clipboard.png