小公司的后端有时候就不得不兼任多职，既是后端又是运维。现在又差不多是全栈了，这样下去说不定会怎么样呢！说回正题，这回我负责的客服系统出了故障，虽然对用户影响不大，但对客服影响很大（亲爱的客服小姐姐，对不起），客服无法正常工作了。全靠 CTO 调试数据库发现问题所在。虽然在公司的 wiki 上小记一笔，但公司上写得还是严肃许多的。这里我就说话随意多了。

故障发生在 12 月 12 日晚上 6:00 ，从昨天开始就已经有预兆了，但我那时候忙于其他事情，没有时间查看服务器，加之服务器加了配置之后，承载能力大为提升，我也就放松下来，不再管服务器了。所以，当服务器出现故障时，我脑子里是嗡的一下，整个人都快要炸了。 mongodb 反复崩溃，当时慌乱的我并没有去查看日志，然后雯雯直接找了锦钿，锦钿问的时候我才想起来要看日志。

这个时候，调用日志时发现了一个慢查询，现在的问题是，这个慢查询是那里的？

我印象中想不起来这个查询是那里的，追查了好久代码，才终于发现原来是创建房间的时候出现的这个查询。这个接口原本不是频繁访问的接口，查询也不应该是慢的。但为什么会导致服务器崩溃呢？原来新的 app 上线之后，增加了创建房间的访问，导致这个接口被频繁访问。锦钿说，这个的逻辑不应该交给客户端来控制，如果没有房间返回 0 就行了，如果交给客户端，服务器面对这种写的同时还得读的情况是会巨大的问题的。但问题是，这个查询在 explain 时并不慢，但运行起来会很慢，这是有问题的。

锦钿继续排查，发现是由于 mongodb 使用了错误索引导致的，删除索引后，服务器恢复正常。

锦钿说，问题不在于 mongodb 使用了错误索引，而是前期压测没有做， API 设计又不合理导致的。个人第一次遭遇这种事情，感觉自己还有很多的不足。测试一定做好（好了，多了测试一职），又由于我们现在是单机架构，其实会出很多问题，但因为我们现在负责的内容少，所以也就没有大碍，但等到项目大了之后，事情就变化很多了。到时候事情到时候再考虑了。

唉，好像体验主服务那种规范的设计模式啊！