当运维工程师开始玄学修仙：论重启大法的终极奥义

当运维工程师开始玄学修仙：论重启大法的终极奥义

作为一名在上海辛苦搬砖的运维工程师，我今天终于悟出了一个真理：这世界上90%的问题都可以用”重启”来解决，剩下10%的问题则需要”再重启一次”。

早上：又是被钉钉告警叫醒的一天

早上刚到工位，手机就开始震动。打开一看，某台VM的监控又报警了——磁盘使用率超过90%。

这种情况我已经遇到不止一次了。点开详情一看，好家伙，又是日志文件堆积的锅。你说这服务器吧，平时运行得好好的，但一旦开始写日志，那叫一个疯狂。什么debug日志、access日志、error日志，层出不穷。

作为一个专业的打工人，我第一反应不是去查具体是哪些文件占用了空间，而是直接祭出我们的传家宝——重启大法。

先SSH连上去，看了一眼进程，发现某服务的日志正在疯狂输出。那输出速度，简直比我看剧时的弹幕还快。

二话不说，先把日志清一清，然后调整了一下日志级别，重启服务。得亏处理得及时，再晚一会儿可能就要触发更大规模的告警了。

这波啊，属于是虽然我不知道为什么会产生这么多日志，但我知道怎么让它不产生。

中午：来自领导的”惊喜”

正吃着午饭，领导发来一条消息：”那个某某平台最近不稳定，你去看看到底是什么问题。”

我嘴里还嚼着饭，含含糊糊地答应着”好的好的”。

打开监控面板一看，好家伙，某某平台的错误率确实比平时高了不少。错误类型也是五花八门：有连接超时的，有认证失败的，还有直接返回500的。

先从最简单的开始排查：网络连通性。ping了一下某平台的API地址，延迟正常，没有丢包。

再检查一下认证信息。access_token还在有效期内，refresh_token也没问题。

最后看了一下代码逻辑。发现某段重试逻辑写得有问题——失败后只重试1次就放弃了，而平台本身偶尔会有抖动，1次重试根本不够。

改完代码，部署上线，观察了一下午，总算是稳定下来了。

下午：玄学事件二三则

下午发生了几件很有意思的事，让我深深体会到了运维工作的”玄学”本质。

事件一：某Mac的谜之卡顿

某位同事的Mac突然变得超级卡顿，打开任何应用都要等半天。我上去检查了一下，CPU使用率正常，内存使用率也正常，磁盘也没满。

重启了一下，好了。

你说这是什么问题？我到现在都没搞明白。

事件二：某VM的谜之断连

某台VM突然和某平台的连接断开了。查看日志，显示的是”连接被重置”。这种错误一般要么是网络问题，要么是对方服务器问题。

先排查网络。ping了一下，正常，没丢包。

再检查防火墙规则，也没问题。

正当我准备联系平台方的时候，它自己又好了。

你说气人不气人？

事件三：某数据库的谜之慢查询

某台数据库突然开始慢查询，查询时间从平时的几毫秒变成了几秒。查看执行计划，发现某张表的索引突然失效了。

我寻思这也没人改过配置啊。

又看了一下数据量，发现数据量增长了不少，可能是统计信息过时了。

执行了一下ANALYZE TABLE，好了。

你说这找谁说理去？

晚上：总结今日感悟

终于把所有问题都处理完了。泡了杯茶，坐在工位上发了会儿呆，回想起今天一天的经历，有几点感悟想和大家分享：

第一，重启大法真的是yyds。 虽然听起来不专业，但80%的问题都能通过重启解决。如果你遇到问题解决不了，那就重启一次。如果一次不行，那就两次。

第二，有些问题真的就是玄学。 你永远不知道代码会在什么时候、什么地点、出什么问题。与其纠结于找出根本原因，不如先想办法让它不复发。

第三，监控告警很重要。 今天的磁盘告警就起到了很好的预警作用，不然等磁盘满了再处理，可能就来不及了。

第四，打工要有好心态。 今天是修完了，但明天还有新的问题在等着。这是定律，改不了的。那怎么办？要么接受，要么转行。我选择前者。

写在最后

今天一共处理了：

• 1次磁盘告警（日志清理）
• 1次平台连接问题（代码修复）
• 1次Mac卡顿（重启大法）
• 1次VM断连（玄学自愈）
• 1次数据库慢查询（统计信息更新）

好像也没少干活。但总觉得哪里怪怪的——有种忙了一天，但又好像没干什么的感觉。

可能这就是运维工作的本质吧：处理问题，然后等待下一个问题。

毕竟，在上海这座城市上班已经这么辛苦了，下班后就别为难自己啦。

明天又是新的一天，新的问题在等着我。但那又怎样呢？兵来将挡，水来土掩，重启大法保平安！

作者：小六，一个在上海努力生存的普通打工人