排查了一圈发现Redis没启动，导致服务各种异常问题爆发

（来源：某运维工程师的故障复盘报告）

那天下午三点左右,客服那边的电话突然就响个不停，像炸了锅一样，一开始我们还在各自忙着手头的事，没太在意，以为又是哪个地区的网络波动，但很快，内部的工作群里也开始被刷屏了，来自不同业务线的同事都在@我们技术部，说的都是同一类问题：“用户登录一直转圈圈，提示超时”、“后台管理系统点啥都没反应，报500错误”、“购物车里的商品一会儿有一会儿没的”。

（来源：监控系统告警日志）

我们的监控大屏上,原本平稳的曲线开始像过山车一样往上猛蹿，不过不是好现象，全是代表错误的红色警报，应用服务器的CPU和内存使用率看着都还挺正常，但HTTP响应码“500”的数量在短短十分钟内从个位数飙升到了上万，这明显不对劲，肯定不是某个单一功能出bug了，更像是整个系统的基础出了问题，像是踩中了什么“地雷”。

（来源：开发团队内部沟通记录）

我们团队几个人立刻放下手里的活儿,凑到一起开始排查，第一步，当然是先看日志，打开应用服务的错误日志文件，密密麻麻的新增记录看得人头皮发麻，翻了几屏，重复出现最多的错误信息大概是“Could not get a resource from the pool”和“Connection refused”，看到“pool”和“connection”这两个词，我们心里都“咯噔”一下，不约而同地想到了同一个东西——Redis。

（来源：系统部署架构图）

在我们的系统里,Redis这个组件太重要了，它就像是我们整个网站的一个高速临时记忆中心，用户登录后的会话信息、一些频繁访问但又不太变化的基础数据、还有为了防止重复提交的临时令牌，全都放在它里面，如果它挂了，就等于这个记忆中心突然失忆了，所有需要从这里读写的服务都会卡壳，进而引发连锁反应。

（来源：故障排查过程记录）

带着这个怀疑,我立刻远程连接到那台专门部署Redis的服务器上，首先用命令 ps -ef | grep redis 想看看Redis的进程在不在，结果，终端里只返回了一行grep自己进程的信息，压根没有Redis的影子，心里一沉，但还是不死心，又用 systemctl status redis 命令检查这个服务的状态，屏幕上赫然显示着一行醒目的红色文字：“inactive (dead)”，果然！Redis服务不知道什么原因，已经停止了运行。

（来源：服务器系统日志）

为了搞清楚它是什么时候、为什么挂的，我赶紧去查看了系统的日志（用的是 journalctl 命令，围绕这个时间点往前翻），翻了半天，终于在中午大概一点钟左右的日志里，发现了一条关键信息：服务器上有一个例行安全更新，自动重启了系统，系统重启之后，Redis服务没有被配置成自动启动，可能是因为上次部署的时候，执行自动启动的命令（systemctl enable redis）被漏掉了，或者执行了但没成功，当时谁也没注意到这个小细节。

（来源：故障处理动作清单）

找到根因就好办了,我们立刻执行了启动命令：systemctl start redis，随着一声令下，终端提示启动成功，紧接着，我们再检查状态，看到了令人安心的绿色“active (running)”字样，几乎就在Redis服务恢复的同时，监控大屏上那些刺眼的红色错误曲线，就像被一只无形的手猛地按了下去，开始快速回落，工作群里抱怨的消息也逐渐少了，取而代之的是“好像恢复了”、“页面能打开了”的反馈，大家这才松了一口气，擦了擦手心里的汗。

（来源：事后复盘会议纪要）

这次故障前后折腾了差不多四十多分钟,对公司业务的影响不小，用户体验更是直接跌到谷底，回想起来，问题本身其实特别简单，甚至有点低级，就是因为一个核心服务没有设置开机自启，导致服务器重启后它一直处于“躺平”状态，但正是这个小小的疏忽，却像推倒了第一张多米诺骨牌，引发了一连串的服务异常大爆发，它给我们狠狠地上了一课：越是觉得基础、觉得简单的环节，越不能想当然，运维工作真的需要像绣花一样细心，每一个配置、每一个步骤都得检查再检查，容不得半点马虎，以后对于所有核心服务的自启动配置，必须纳入部署清单，并且要有自动化的检查机制，确保类似的事情绝不能再发生。