例行维护后引起的故障

类似的事情听过不是一次两次了，今天看到 robbin 在推上的留言。觉得很有意义，特别记录一下，时刻提醒自己。在日后架构设计和维护规范上应当通过合理的手段避免类似的事故发生。

robbin 原推如下：

@robbinfan: 昨晚JE所在机房切换电源关机导致网站无法访问。早上恢复后因为数据库和缓存服务器都被清空，巨大流量(QPS将近400，并发连接到1000)直接冲击导致web服务被阻塞，现在正在逐步恢复中。

显然，这是一次运维事故。事故的原因是分流作用的数据库和缓存出现“故障”，导致数据层响应延迟，web 服务器阻塞。这里我没有用“清空”而是用了“故障”来描述分流数据库和缓存，是因为实质上 javaeye 的这次事故虽然是正常维护（电源切换）后发生的，但是其表象跟分流数据库和缓存宕机是一样的。

这个故事给我的两个启示：

在架构设计上，对于分流数据库或者缓存或许应有一定的持久化能力。比如，在维护时，按照从“外”到“内”的顺序逐步关闭服务。在这个例子里，“外”就是 web服务，“内”就是数据层。在关闭了“外”服务后，手工或自动将缓存持久化。维护完成，开启顺序从“内”到“外”，并在回复完底层存储后，将持久化数据恢复到缓存。

在运维规范上，在维护后应让系统进入一个的磨合期，在合理的时间内通过分流（比如跳转到一个“系统忙”的页面）或者防火墙封锁的方式。让系统保持在比正常负载低一些的水平。持续一段时间（或者维护后累计访问量达到某个值）后再让系统开足马力去运行。

这样，应该可以避免空缓存大并发导致的宕机事故。

再次感谢 robbin 和 javaeye 为我们带来的启示。