2016 年 3 月 29 日晚间,LeanCloud 平台上的多个应用进行了推广活动,激增的访问量给我们的数据存储和实时通信服务带来了较大压力。从 20:50 至 22:15 有多次流量高峰出现,我们多台 Web 服务器的网络吞吐包超过虚拟机的能力极限,内外网通信中断,从而导致 HTTP 服务多次出现间歇性故障(数据存储 API 以及依赖于它的服务也都间歇性不可用)。具体情况汇报如下: 故障时间20:53 - 21:03 (持续约 10 分钟)数据存储 API 服务约 50% 的请求超时。21:17 - 21:40 (持续约 23 分钟)数据存储 API 服务约 50% 的请求超时。22:00 - 22:15 (持续约 15 分钟)数据存储 API 服务约 12.5% 的请求超时。
故障总共持续约 48 分钟。 影响范围本次故障只影响中国节点,美国节点的所有服务均工作正常。在故障期间凡是向 LeanCloud 平台发送过请求,并使用了数据存储服务的活跃应用都受到了影响;我们的统计服务也在短时间内无法正常接收来自应用的事件上报。
事故过程20:52 :内部监控系统报警,显示多个 Web 服务器节点出现故障。我们立刻上线进行紧急处理,在排除后端服务问题之后,开始追查前端资源和带宽配额。21:03 :由于部分应用流量回落,同时也由于我们临时大幅增加了出口带宽,服务暂时恢复正常。21:05 :我们开始扩容前端机集群,以应对接下来可能再次出现的流量高峰。21:17 :前端机扩容时碰到了虚拟机 OS 故障以及网络环境问题,未能及时完成。此时恰好部分应用又迎来一次流量高峰,前端机再次吃紧。21:30 :修复过程将近半小时,于是我们启动了公告和通知流程,在微博和用户群里发出通告。21:40 :流量自然回落,前端机再次恢复正常,我们的平台开始正常处理 API 请求。22:00 :线上部分前端机出现物理故障,我们又开始对它们进行紧急处理,期间有大约 1/8 的 API 请求丢失。22:15 :新的前端机节点经过手动处理后终于达到可用状态,并加入集群,完成了扩容,至此全部服务彻底被恢复。
后续改进措施- 增加新的监控措施,对前端机网络入包量进行监控,防止网络转发量超过 VM 能力限制。
- 调整前端机 VM 配置,使用高包量机型,增大前端机的处理能力。
- 改进前端机扩容方式,使用 docker 镜像来加快新节点部署上线的进度。
- 公告流程中增加短信通知渠道,确保信息及时通知到开发者。
|