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

17
最近做了个项目,上线之后依次发现了三个线上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


如果觉得我的文章对你有用,请随意赞赏

你可能感兴趣的

11 条评论
changli · 6月27日

其实可能没有你想得那么严重,我记得我刚毕业的时候,就分配在一栋大楼里面装交换机,那个时候对交换机,光纤,发射器什么的都不懂,一个月断大楼十几次网,断网的原因也多种多样,第三方单位把光纤扯断,光纤闭环,什么乱七八糟的问题,每次断网客户找我谈,领导找我谈,最后才完成整个项目。最后不是照样上班,按领导的话,我就需要坑踩多了的人,不要让人觉得你是个坑就行了

+1 回复

0

谢谢兄弟,主要是没遇到这种事,最近实在是有点自以为是

这是你的玩具车吗 作者 · 6月28日
0

你不说,可能不觉得你是个坑,你一说,尼玛你就是坑啊

艾尼菲楠 · 6月29日
1

@艾尼菲楠 其实真正的大坑就是领导,一个错误决策,就是埋坑的开始,你只是去踩他埋的坑,你得还像孙子一样,对领导说,还是你埋坑技术好

changli · 6月29日
Xeira · 6月29日

但是错误的将必现听成了偶现 所以任何时候都要写成文字

+1 回复

0

这点非常重要,非IT公司,领导基本上都是口头布置工作,很要命

samsara0511 · 7月2日
一条大懒虫 · 7月20日

河马也算挺大一个公司,不知道怎么做项目管理的。以下是我的一些观点。
首先,在做一个版本的计划时,需要开发和测试的同学评估完成这些任务的时间。团队要有这样一个机制,确定需要的人天不能随意压缩,这样测试的同学也有足够的时间来测试。否则,很容易会出事情的。
第二,测试的同学发现问题,要有自己的判断力,确定是不是bug的依据不是开发的说辞,而是根据业务需求来判断。测试需要坚持自己,大不了由产品经理PO来决定到底是不是一个bug。没有记录在bug系统里面,口头跟开发交流,这个锅大部分算测试的。要不然,要测试干嘛?
第三,上线的时候,bug系统里面的bug都关掉了,才能上线。否则,不允许上线。实在关不完bug,也要排一下优先级。在上线的时候发个报告出来。

+1 回复

0

综上,这不是你个人的问题,是整个团队项目管理有问题!

一条大懒虫 · 7月20日
ChristLand · 6月28日

程序写多了,bug就多,没事儿的啊! 这就和新手开车感觉一样,突然出了点小磕碰或者背开个罚单那感觉都像世界末日,然而实际上世界末日也不会因为这点事情到来. 等你变成老司机,那基本遇到事情就可以很淡定的处理了. 把这次失败的经验教训总结出来很好,以后尽量别再犯就已经很厉害了. 剩下的也不必多想.

回复

心惟耽静 · 6月28日

是河马生鲜么

回复

梦溪笔谈 · 7月1日

相同遭遇

回复

载入中...