这个灾难，就发生在前2天前的一次项目上线过程中。
灾难的现象：
应用端调用我们的开发的应用对外提供的接口服务，有时候能得到数据，有时候超时报404.
我们这个应用的基本技术形式：
一个促销活动的接口功能上线，java web应用，对外REST ful API，采用POST对外提供服务。
我们的应用部署架构：
我们的Host对应的域名是abcd.cn，F5下面挂载的4个nginx服务器，用nginx服务器作为反向代理服务器，后面挂载Tomcat，nginx的反向代理调度机制采用的是默认的round robin，即轮询。
我们的这个促销接口，是基于之前的一个既有的应用search，也就是我们的官网abcd.cn的站内搜索服务，奇怪的现象，就是搜索服务工作很正常，但是新的推荐接口，在httprequester模拟器上，就会出现绝大多数情况下失败，返回404，偶尔能正常返回数据。经过多次测试，发现有规律，基本上是3此失败后就会有1次成功。
这个现象很有意思，就是这个现象，让我们找到了问题的根源。
1》搜索服务一直都不存在问题，说明这个反向代理配置没有问题。搜索在应用程序中的功能没有问题。
2》促销接口，这个功能也是没有问题的，因为有成功的返回，而且是周期性的成功。说明促销接口功能程序也是OK的。
这就引起我们的注意，是不是反向代理服务器上有问题呢？于是登上服务器，查看nginx的配置文件，发现反向代理配置中，server21，server22都有4个端口对应的tomcat应用，这里让我们瞬间崩溃，部署应用的人员，疏忽大意，只更新了两个服务器上8080端口的应用，也就是说，其他端口8081-8083这3个端口没有更新对应的tomcat的应用war包。。。
当时，我作为项目负责人，差点没有直接批评那个开发和部署这个项目的工程师，因为这个，导致合作的其他团队质疑我们团队的产品质量。。。也因为这个问题，耽搁了差不多半个小时。。。
总结，
1. 出现问题，要细心分析现象，规律的错误比较好查。
2. 项目管理中，负责人要反思沟通效率。
3. 团队伙伴技术水平差距太大，或者不够细心，会严重拖累团队整体的效率和产品质量
我作为项目负责人，有过失， 那个开发人员，疏忽大意，给团队埋雷，应该受到处罚，这种事情发生在上线阶段，上线是件严肃的事情，团队成员都要重视。