2015-10-06 08:11 EST
早上我被CTO的Slack信息吵醒，CTO说AWS给我们发了一封邮件说我们的一台服务器由于硬件故障down掉了。CTO查了一下那是我们的数据仓库，用于几乎无用数据存储。由于这个数据仓库数据多，增长速度也快，基于成本的考虑这是一个集群的单点。尽管有服务往那个数据仓库写入，但是也都catch掉异常。所以当时CTO测试了一下认为没有问题，所以也就说了暂时不需要处理。我继续睡觉。
2015-10-06 09:15 EST
我回到办公室，我们的报警系统开始发报警。第一个报警是流入数据库速度达不到最低值，同时我们也收到了facebook api服务故障的邮件，这个很正常，facebook api经常故障可用性，据我目测达不到80%。所以，我暂时不管继续调昨天的Bug。
2015-10-06 09:25 EST
又一个报警邮件，数据流入数据库与数据流入系统的比例达不到阈值，这个时候我开始警觉了，检查了几个服务的处理速度，最后定位到两个和数据仓库有连接的服务处理速度异常了，基本就是30秒处理若干条消息。这是我醒悟了，我在消息写数据仓库的时候只做了异常处理没有做数据仓库连接异常次数过多时移除数据仓库。赶紧改了下代码，测试环境跑一下。正准备上生产环境的时候，数据仓库复活了，一切都正常了。当然这样就不需要马上去修复生产环境了。
检讨
系统恢复后，我们开始检讨之前的设计。
- 最大的失误在于，同步写入数据仓库。这是当时觉得同步写入效率可以接受，没有考虑这个会是一个集群单点。其实无论如何这种冷数据的处理都应该异步。
- 没有做节点异常后的降级处理。
- 幸运的是故障发生在东部时间早上，大家都还没有上班的时间，而且我们的报警做得不错。
好吧，坑过才会进步嘛。
»订阅本站：
https://chaopeng.me/blog
