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

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

1. 项目背景

1.1 参与者

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 分分这个项目的锅

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

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