阿里云Redis宕机事件 (2019年) 复盘
事件
2019年4月12日,阿里云Redis服务在华东1区主availability zone发生故障,导致50%以上的Redis节点不可用,大量基于Redis的应用程序和网站不可访问。
造成此次故障的主要原因是自动化系统错误地将宕机的Redis节点标记为删除,这些节点上的子节点也被错误删除,最终演变成失控状态。
事件详情如下
1.事件起因
阿里云Redis服务一个自动化系统疏忽地将一些宕机节点标记为”要删除”状态。这些节点上的子节点也被错误地标记为删除。
2.事件蔓延
受影响节点上的客户端服务开始报连接超时和连接拒绝错误。 DELETE操作开始在主AZ的节点上递归执行,导致大量正常运行的Redis节点被错误删除。
3.事件检测
阿里云监控系统检测到主AZ的Redis节点数量突然大幅下降,用户报错率显著上升。判断这属于一次不正常事件,且有蔓延迹象。
4.事件响应
阿里云Redis团队立即关闭相关automated系统,制止DELETE操作的进一步执行。并手工恢复部分已删除但数据尚未覆盖的Redis节点。同时增加其他AZ的Redis节点数量,租户流量开始分流至其他可用区。
5.事件根因分析
经分析,造成此次事件的主要根因是:
(1) Automated系统的DELETE操作规则过于宽松,导致出现误删除正常节点的情况。
(2) 自动化运维流程缺乏人工确认机制,完全依赖算法判断,增加了误判率。
(3) 节点之间的CASCADE删除规则,使得个别节点的错误删除可以连锁反应,最终导致大面积节点Down。
后续整改
阿里云Redis团队修改automated系统的DELETE判断规则,增加人工确认机制。
优化节点删除流程,避免CASCADE效应。
增加业务监控,提高故障检测速度。持续推进机器人与人工协作,提高automated运维的准确性。
总结
这个事件反映出,作为一款基础服务,Redis的高可用性至关重要。阿里云Redis团队从事件中汲取教训,进行了很好的整改与优化。作为用户,我们也应考虑Redis这类基础服务的容灾能力,避免产生单点故障,影响业务连锁反应。