redis服务突然被删，数据全没了，真是太糟心了啊

（来源：知乎专栏《运维血泪史》）

那天下午三点多,我正端着杯子准备接水，钉钉突然像炸了锅一样狂响，心里咯噔一下，这种密集的消息提示音准没好事，放下杯子点开一看，运维小组的群里已经刷了上百条消息，最刺眼的是几条加粗的警报：“生产环境Redis连接全部失败！”“所有业务线的缓存服务报错！”“紧急！疑似数据库故障！”

我冲到工位打开电脑,手有点抖，登录服务器管理平台，找到那台核心的Redis服务器，输入查询状态的命令，屏幕上冷冰冰地返回了一行“Connection refused”，冷汗瞬间就下来了——这可不是普通的服务重启，这是连端口都关闭了，赶紧用最高权限尝试强制连接，结果提示更吓人：“No such file or directory”（来源：当时执行的错误日志截图），连Redis的进程文件和数据目录都找不到了，这意味着什么？我的心沉到了谷底。

团队里负责基础架构的小王脸都白了,他颤着声音在语音会议里说：“老大，我……我好像闯祸了。”原来，半小时前他接到一个任务，要清理一批测试服务器释放资源，公司服务器命名有点混乱，有一台线上Redis服务器的主机名和一台废弃的测试机特别像，他在长长的列表里勾选要删除的机器时，眼花看错了一行，把生产环境的Redis服务器给选上了，更致命的是，公司的云平台删除操作为了“用户体验”，省去了二次密码验证的步骤，只有一个不太起眼的确认对话框，他当时急着处理下一个工单，鼠标一点，确认删除。

（来源：事后复盘会议记录中当事人的陈述）

就那么一下点击,一台承载着公司核心业务的Redis服务器，连同里面所有的数据，就在云端被瞬间抹掉了，没有备份，没有延迟删除，就像从来没存在过一样。

接下来的场景,简直是一场灾难片现场，首先是用户中心登录不了，因为用户会话数据全在Redis里躺着，几分钟内，客服电话就被打爆了，紧接着，首页和商品详情页开始大面积报错，这些页面依赖Redis缓存数据库查询结果来抗住高并发，缓存一崩，底层数据库根本撑不住汹涌的流量，很快也接近崩溃边缘，我们的主站几乎瘫痪了，运营同事跑过来，带着哭腔说正在进行的促销活动全乱了套，优惠券无法核销，库存数量显示异常，订单系统卡死，整个技术部鸦雀无声，只能听到键盘声和沉重的呼吸声。

（来源：当天系统监控平台的流量和错误率图表，显示在15:10左右出现断崖式下跌和飙升）

我们试图从其他地方恢复数据,但现实很残酷，这台Redis服务器因为性能要求很高，为了极致速度关闭了持久化功能（来源：该服务器的配置档案），也就是说，数据只存在于内存里，我们也曾有过搭建主从集群的计划，但因为最近业务迭代太忙，一直“明天再说”，结果偏偏就在这个空窗期出了事，数据恢复公司也联系了，对方一听是云服务器被直接删除且没开持久化，直接表示无能为力。

那种感觉,不仅仅是焦急，更是一种深深的无力感和懊悔，好几GB的热点数据，包括百万用户的购物车信息、近千万的临时会话、几十种关键的业务队列……全没了，这不是硬盘损坏还有可能修复，这是被“主动”且“干净”地消灭了，你能想象那种感觉吗？就像你辛辛苦苦写了好几个月的文档，没保存，然后不小心按了删除键还清空了回收站，小王躲在楼梯间抽烟，眼睛红红的，我们谁也没法去责怪他，因为这种脆弱的架构和缺失的流程，我们每个人都有责任。

从下午三点到第二天凌晨,我们技术部全员加班，做的事情只有一件：想尽一切办法，让系统在没有缓存的情况下“苟”下去，限流、降级、紧急扩容数据库、一遍遍安抚业务方……网站勉强能打开了，但速度慢得像回到了十年前，这次事故，直接损失了几百万的订单流水，间接的品牌信誉损失更是无法估量。

这真是我职业生涯中最糟心的一天,它用最惨痛的方式给我们上了一课：在技术世界里，任何为了方便而牺牲安全性的设计，任何抱着“应该不会出事”的侥幸心理，最终都会以你最不愿看到的方式，给你一记响亮的耳光。 数据无价，备份重于泰山，流程规范不是摆设，这些老生常谈的道理，在真正的灾难发生前，总是容易被忽视，而教训，往往只有在失去之后才显得刻骨铭心。