在8月9号公司在浙江横店借助蓝普开发商大会推广我们的app，本来是一个很好的推广我们app的机会。在7月27日老大给我们说明了这样的一个契机，向我们表明老板希望我们在8月4号之前做好群聊功能和群聊发红包众人抢红包的功能。我们也为了这次机会不分昼夜，周末连续加班。首先我们的工作进度是准备要把单聊的消息从服务器获取改到从云信服务器获取，然后就被叫停，先开发群聊模块，而群聊的消息要从云信服务器获取。然后在消息展示页面就有一个很尴尬的情况，就是单聊的消息是从我们服务器取的，群聊是从云信服务器取的，然后还要穿插排序，同时消息未读数还要统一各自显示。然后就和安卓讨论，每次取群聊消息或者单聊消息的时候都把2个接口调用一下，然后统一按时间排序显示，本来想着就为了这次宣传大会，老板在上面展示一下，即便频繁调用接口也不会对服务器造成太大的影响。而且回来马上就要把单聊消息也改为云信统一获取，即便后来用户量多了也能及时改回来。也可能模块功能的原因，测试进行测压的时候也只是对群聊和红包功能的接口进行了测试，测试结果也没出什么问题。
但是。。。偏偏大的事故却在8月9号那天等着我们，500个人同时在群里说话，发红包，抢红包。每次每个人说一句话，都会调用会话列表的接口，进行数据排序。一个人说话，会话列表接口马上被调用499次，服务器马上超负荷运行，卡到爆，造成线程阻塞。我们老板在群里发了几万的红包，却没法领取，有的人领取了页面加载不出来。无数工程商在群里中伤老板，说我们app做的垃圾，要拿程序员祭天之类的话，我们看了也是心里很是愧疚，本来我们是要做成每次有会话的时候判断一下本次会话在会话列表是不是第一个的，如果是第一行，就不再去调用会话接口重新排序了，直接调用云信sdk加载。因为时间问题，苹果要提前审核，上线。做好的这个功能就没来及上线，抱着侥幸的心里也想着几百人访问接口不会有太大影响。。。回来以后老板真是生气，毕竟让他在这么好的一个机会面前以很尴尬的结局收尾，我们也清楚在这个事件里我们每个人都有很大的责任，虽然服务器压力这个是运维要考虑的，我们却想当然，没有把隐患上报，回来以后老周哥还安慰我们，那么短的时间把项目完成已经很厉害了。但是心里的自责却没法说出来。
然后我们就开了这次事故的评估会议吧，老大就觉得目前我们开发的项目架构没有一个很好的文档展示，app端的接口调用逻辑，页面加载交互也需要一份文档展示。方便以后配合产品对于项目的维护和修改，也能让运维对于用户人数和app之间的峰值风险控制。于是回来就赶紧放下手头工作，做一下对app进行解剖式的图文展示。但是自己心里很清楚知道每一步的流程，却不清楚要怎么展示出来。
