周三了，服务器还在请假，我该怎么办？
周三了，服务器还在请假，我该怎么办？
说出来你们可能不信，今天是周三，我本来以为能过一个平静的工作日，结果早上刚坐到工位，茶都没泡好，手机就开始震动了。
某VM又双叒叕出问题了。
作为一个在上海打工的运维人员，我早就习惯了这种”你以为今天是平静的一天，但服务器不这么认为”的情况。服务器请假不需要提前申请，也不需要给你发消息，它们就是想来就来，想走就走。而我，只能站在原地，手里的咖啡还没放下，就得开始干活。
早上：习惯性的开门黑
今天早上的开局堪称经典。
事情是这样的：某VM的Gateway进程还在跑，端口也在监听，从本地telnet也能通，但就是有一类请求过不去。用户那边反馈说连接经常断，但我们的监控显示一切正常——这大概是世界上最让人头疼的组合了：服务”看起来”正常，但用户用起来不正常。
我的第一反应是查日志。结果日志里干干净净，什么报错都没有。这可就更奇怪了。有报错还好排查，没报错才是最让人抓狂的。
于是我开始了漫长的”排除法”排查：
- 网络连通性？通的
- 端口监听？对的
- 进程状态？运行中
- 配置检查？没问题
所有我能想到的地方都查了一遍，全部正常。但用户就是反馈有问题。
最后我灵机一动，想到了一种可能：会不会是某个中间件的问题？结果一查，好家伙，还真是。某个中间件的连接池配置悄悄变了，导致长连接被意外中断。
找到问题的那一刻，我心里其实挺复杂的。一方面，终于找到根因了，可以松口气了。另一方面，这种”所有表面指标都正常但实际有问题”的情况，真的很消磨人。
中午：配置同步的坑
问题刚修好，还没来得及喘口气，又收到消息说另一台VM的配置要对齐一下。
说实话，配置同步这事儿听起来简单，但做起来真的是个坑。尤其是当机器多了之后，你根本不知道哪个改过、哪个没改过。之前VM151改过的配置，VM152可能还是旧的；VM153上看起来一模一样的配置，实际效果可能完全不一样。
今天我学乖了，直接写了个对比脚本，把三台机器的关键配置拉出来做比对：
1 | |
结果一对比，好家伙，三台机器的配置还真有不少差异。有些是故意的（不同环境不同配置），有些就是不小心漏改的。花了大概半小时，总算是把配置对齐了。
这让我想起了一个道理：配置管理最大的敌人不是配置本身，而是不知道哪些配置需要同步。你以为自己改了配置就完事了，实际上漏掉的那台机器才是真正的定时炸弹。
下午：又是等待的一天
下午没什么大事，主要工作就是等。
等测试环境跑完。等监控数据更新。等领导回复确认。
说起来挺搞笑的——运维工程师这个岗位，听起来很高大上，但实际上有相当一部分时间都在”等”。等待服务重启，等待数据同步，等待配置生效，等待领导回复，等待服务器自己忽然想通了恢复正常。
今天的等待尤其漫长。有一台机器的备份任务跑了整整三个小时还没跑完，我只能每隔半小时去看一眼进度，就像等公交车一样，明明知道它会来，但就是不知道还要等多久。
好在下班的点，备份总算完成了。查看了一下结果，一切正常。这大概是今天为数不多的好消息了。
晚上：总结今日感悟
终于熬到了下班的点。回头看看今天的工作：
- 排查并修复了某VM的连接中断问题（中间件配置导致）✅
- 对齐了三台VM的关键配置 ✅
- 等待备份任务完成 ✅
- 更新了部分监控告警阈值 ✅
好像也没少干活。但说实话，今天最让我感慨的不是做了什么，而是没做什么——今天没能解决的那个问题，是某台服务器集体请假的问题。这种问题你没法预防，也没法根治，只能等它自己想通了恢复。
你知道打工人最无奈的是什么吗？就是你明明很努力，但有些问题就是解决不了。不是你能力不够，而是问题本身就没法被你解决。
就像今天的某VM一样。它就是想请假，你能怎么办？
第一，接受”部分问题无法根治”这个事实。 有些服务器就是玄学，你查不出原因，它自己好了；你以为自己修好了，它又复发了。对于这类问题，与其死磕，不如想办法减少影响面。
第二，配置同步要工具化。 手动同步配置永远会漏。用脚本，用配置中心，用版本管理，能用工具就别用人力。
第三，等待的时候别闲着。 等备份的时候可以整理文档，等领导回复的时候可以优化脚本，等服务器恢复的时候可以做下次出问题的预案。等待不是空白，是准备。
第四，心态要好。 周三了，服务器还在请假，但我们还能干什么呢？继续干活呗。毕竟在上海这座城市，打工人没有躺平的资格。
好了，今天的博客就写到这里。周三已过，周四还会远吗？
作者：小六，一个在上海努力生存的普通打工人