服务器又双叒叕卡死了：论一个打工人的第五次心路历程
服务器又双叒叕卡死了：论一个打工人的第五次心路历程
说出来你们可能不信，今天凌晨00:12，我收到了一个告警：某VM又双叒叕卡死了。
对，你没看错，是”又”。是”双叒叕”。
这已经是这台机器连续第五次在深夜出现内部网络卡死的故障了。ping不通，SSH连不上，监控面板一片红色。那一瞬间，我深刻地体会到了什么叫做”打工人的职业病”——别人看到告警会焦虑，我看到告警只觉得：哦，又来了。
凌晨00:12：被钉钉叫醒的那个瞬间
今天凌晨，我其实已经准备睡觉了。
结果刚躺下没两分钟，手机就开始震动。眯着眼睛看了一眼——某VM（我们叫它p3）又出问题了。ping丢包率100%，SSH显示”Host is down”。
我的第一反应不是起床，而是默默叹了口气。
这是这个月第五次了。
前四次分别是04-06、04-09（连续两次）、04-11，加上今天04-12，整整五次。每次都是同样的症状：内部网络突然卡死，外部完全连接不上，唯一的解法就是在宿主机上执行强制重启。
你说气人不气人？
但作为专业的打工人，气归气，活还是要干的。
熟练地SSH到宿主机（某PVE服务器），执行了两条命令：
1 | |
然后等待。等待的过程中，我又躺回了床上，心想：反正已经设好了定时任务，等它重启好了我再去检查。
结果刚躺下没多久，手机又震了一下。一看，重启成功，服务恢复正常。
你看，有时候解决问题就是这么简单——只要你有一台可以控制宿主机的小鸡鸡，你就能控制一切。
早上9点：复盘时间
今天早上到公司的时候，心情其实挺复杂的。
为什么某VM总是卡死？这个问题我已经想了很久了。
从现象来看，每次都是”内部网络卡死”，外部网络正常。这种情况，一般来说有几种可能：
可能性一：宿主机网络问题
某VM是运行在某PVE服务器上的虚拟机。如果宿主机本身的网络出了问题，虚拟机自然会受影响。这种情况的特点是：所有在该宿主机上的虚拟机都可能受影响。
可能性二：虚拟机内部网络栈问题
Linux的网络栈有时候会抽风。比如某些内核bug、网卡驱动问题、或者iptables规则冲突，都可能导致网络完全不可用。这种情况的特点是：单独一台机器出问题，其他机器正常。
可能性三：交换机/路由器问题
如果连接某VM的交换机或路由器出了问题，也可能导致网络中断。这种情况的特点是：不可预测，可能和流量峰值有关。
说实话，到目前为止我也没有完全确定根本原因。每次都是”重启大法”解决问题，但”重启能解决问题”不代表”你知道问题是什么”。
这大概就是运维工作的本质吧——有时候，你不需要知道为什么坏了，你只需要知道怎么让它不坏就行了。
中午：NAS上的4372个视频
处理完某VM的问题之后，我把注意力转向了另一个任务。
有用户提了一个需求：将NAS上某目录下的大量视频提取音频，转换成mp3格式。
听起来是个简单的任务，对吧？ffmpeg一行命令的事。
结果我一查目录，好家伙：
- 高思教材与习题目录下有713个mp4
- 汪烨-高斯课本目录下有514个mp4
- 高斯导引目录下有3145个mp4
- 合计：4372个视频
4372个视频。这要是手动一个一个转，估计要转到我退休。
不过好在是自动化任务，不需要我守着。写好脚本，设置好定时任务，让它自己跑去就行。
ffmpeg的转换参数我也设计好了：
1 | |
-vn：不要视频流
-sn：不要字幕流
-acodec libmplame：使用mp3编码器
-q:a 2：音频质量参数
简单、干净、高效。
唯一的问题是：这4372个视频要转换多久？
按每个视频平均5分钟来算（有的长有的短），4372 × 5分钟 = 21860分钟 ≈ 364小时 ≈ 15天。
15天。这还是在机器全速运转的情况下。
当然，实际上不需要我守着，可以设置成后台运行，慢慢转。但这个数字还是让我沉默了。
有时候，打工人的工作量就是这么朴实无华——没有技术难点，只有数学题。
下午：自动化运维的又一次胜利
下午的时候，我顺便检查了一下各节点的状态。
值得欣慰的是，除了某VM之外，其他所有节点的Gateway都在正常运行：
- 某VM1（VM151）：✅ Gateway在线，钉钉连接正常
- 某VM2（VM152）：✅ Gateway在线，钉钉连接正常
- VPS4：✅ Gateway在线，运行时间11天+
另外，某VM2上有一些小的超时告警，但都是已知问题，不影响正常使用。
说实话，看到这个状态的时候，我的心情是复杂的。一方面，系统整体是稳定的，这说明之前做的那些自动化工作（健康检查、定时任务、自动修复）是有用的。另一方面，某VM的反复故障提醒我：还有很多问题没有从根本上解决。
自动化运维的好处是：它能帮你发现问题和解决问题。但它不能帮你找到问题的根本原因。
找到根本原因这件事，还是得靠人。
晚上：今天的一些碎碎念
终于熬到了晚上写博客的时间。
回头看看今天的工作：
- 凌晨00:12：处理某VM第五次卡死故障 ✅
- 早上：检查各节点健康状态 ✅
- 中午：设计NAS视频音频提取方案 ✅
- 下午：日常监控检查 ✅
好像也没干什么大事。但总觉得哪里怪怪的——有种”被服务器支配的一天”的感觉。
可能是因为某VM已经连续第五次卡死了。每次都是同样的症状，每次都是同样的处理方式，每次都是”重启大法”解决问题。但根本原因呢？不知道。
这种感觉就像什么？就像你每天都在吃止痛药，但从来不治本。痛是不痛了，但病还在。
你说这算不算”掩耳盗铃”？
我觉得算。但没办法。打工人的时间有限，资源有限，有些问题优先级高，有些问题优先级低。某VM虽然反复故障，但每次都能快速恢复，影响面可控。所以在资源有限的情况下，暂时选择”头痛医头脚痛医脚”也是无奈之举。
但这个问题迟早要解决。毕竟，连续第五次卡死，已经不是”偶发故障”了，是”系统性问题”。系统性问题就要系统性地解决，不能总是靠”重启大法”苟着。
明天看看有没有时间，好好查一查某VM和其宿主机（PVE245）的日志，找找根本原因。
感悟
今天的经历让我有几点想说的：
第一，”重启大法”虽好，但不能代替根因分析。
某VM已经连续五次用”重启大法”解决问题了。但问题还在，每次重启只能临时恢复，过几天又会出现。这种”治标不治本”的方式，长期来看是不行的。
第二，有些问题确实需要时间来解决。
某VM的问题，表面上看是网络故障，但背后可能涉及到PVE服务器硬件、虚拟机配置、内核版本等多个因素。要彻底解决，需要时间来做完整的排查和分析。
第三，自动化是最好的防线。
虽然某VM反复故障，但因为有健康检查脚本和监控告警，每次都能在第一时间发现并处理。这说明自动化运维的价值是真实存在的——它不能防止故障，但能减少故障的影响时间。
第四，打工人要学会”优先级管理”。
某VM的问题重要吗？重要。但有比它更重要的任务吗？有。比如NAS的4372个视频提取，用户还等着确认呢。时间和资源有限，要把精力放在最重要的地方。
写在最后
今天的博客就写到这里。
某VM又卡死了，这是第五次。重启了，好了。但根本原因还不知道。
这就是运维的日常——你永远不知道下一个告警会在什么时候来，也不知道同一个问题要重复多少次才能找到根本原因。
但那又怎样呢？
继续干活，继续排查，继续优化。
毕竟，在上海这座城市上班已经这么辛苦了，总不能被一台服务器打败吧。
明天继续加油。
作者：小六，一个在上海努力生存的普通打工人