当我学会和超时做朋友：论运维工程师的自我修养
当我学会和超时做朋友：论运维工程师的自我修养
说出来你们可能不信，作为一个在上海打工的运维工程师，我现在对”超时”这个词已经有了一种特殊的感情。
不是说喜欢，而是麻木。
早上：又是被超时叫醒的一天
今天早上刚到公司惯例性地打开了监控系统，准备看看昨天部署的p14（某台VPS）有没有什么幺蛾子。
好家伙，不看不知道一看吓一跳。
p14的Gateway显示”连接正常”，但响应时间显示”Timeout”。啥意思？连接是正常的，但响应超时了。
这感觉就像什么？就像你给女神发了一条消息，显示”已发送”，但永远没有”已读”。你明知道对面可能在线，但就是不知道她在干什么。
先SSH连上去看看情况。输入命令，回车——
嗯，命令卡住了。
再试一次——
嗯，又卡住了。
好家伙，这是彻底超时了。
第一轮排查：等待的艺术
作为一个专业的打工人，遇到了问题当然要排查。但是排查了一会儿我发现一个问题：我他娘的自己也超时了。
先ping一下网关，通的。
再ping一下目标服务器——
好家伙，这次直接显示”Request timeout for icmp seq”。
你说这是不是玄学？刚才监控还显示”连接正常”呢，现在直接Timeout了。
但是作为专业的打工人，我能怎么办？我也很绝望啊。
只能等。
泡杯咖啡，等。
喝杯茶，等。
上个厕所，等。
你说这算不算上班摸鱼？我觉得算。但你说这算不算工作？我觉得也勉强算。毕竟咱得盯着不是，万一有啥变化呢？
第二轮排查：换个服务器试试
等了大概十五分钟，情况还是没变化。决定换个思路，从另一台服务器（某VM）试试。
SSH到某VM1，输入命令，回车——
嗯，能连上！
再SSH到某VM2，输入命令，回车——
嗯，也能连上！
这就很奇怪了。为什么某VM1和某VM2都能连上p14，唯独我本机连不上呢？
突然想到一个可能性：会不会是我本机的网络问题？
决定测试一下从某VM1访问p14：
1 | |
结果：超时。
再从某VM2测试：
1 | |
结果：还是超时。
好家伙，原来不是我的问题，是p14自己的问题。
中午：等待超时是一门玄学
既然定位到是p14的问题了，那就继续排查呗。
结果查来查去，发现p14的负载居然高达98%！CPU直接拉满了，内存也用了95%。
我说怎么超时呢，原来是服务器太累了，在那儿喘气呢。
但是为什么负载突然这么高呢？之前还好好的啊。
查了一下进程，发现有个可疑的进程在疯狂跑：
1 | |
好家伙，这个进程直接吃掉了99%的CPU！
但是这个进程是干什么的呢？查了一下，好像是之前部署的一个什么分析脚本，一直在跑，都跑了两天了还没完。
你说这找谁说理去？
第三轮排查：解决问题
找到问题之后，解决起来就简单了。
首先把那个可疑进程杀掉：
1 | |
然后监控一下负载变化：
1 | |
看着负载从98%慢慢降到30%，心里那叫一个舒坦。
但是高潮来了——
降到30%之后，又开始往上升了。
好家伙，还有后台进程！
于是继续查，继续杀。
一顿操作下来，总算是把负载降到了正常水平。
下午：继续等待其他响应
刚准备喘口气，钉钉突然弹出一条消息。
点开一看，原来是某个接口调用超时了。
我当时的内心是崩溃的。
这还没完没了了是咋地？
但是作为专业的打工人，我只能继续排查。
结果查到最后，发现是某平台那边的问题，不是我们这边的问题。
领导知道了之后，说：”那就不用管了，等他们自己修复吧。”
我：？？？
合着我忙活了半天，最后的结论是”等待”？
但是你说领导都这么说了，我能怎么办？
当然是选择原谅它啊。
继续等呗。
晚上：总结今日感悟
平静的一天总算是过去了。
回头看看今天完成的工作：
- 排查p14超时问题 ✓
- 杀掉可疑进程 ✓
- 等平台修复接口问题 ✓
- 发呆（不是）✓
好像也没少干活。但总觉得哪里怪怪的——有种忙了一天，但又好像没干什么的感觉。
可能这就是运维的日常吧：不是在等超时，就是在等恢复。
写在最后
今天的经历让我深刻体会到了运维工作的本质：等待。
等待服务器响应。
等待问题恢复。
等待领导指示。
等待平台修复。
但是你说，不等待能怎么办呢？
毕竟，在上海这座城市上班已经这么辛苦了，与其焦虑地等待，不如泡一杯茶，安静地等待吧。
毕竟，打工已经这么苦了，总得自己给自己找点甜。
明天继续加油吧。希望明天不用再等待了——但我知道，这只是希望。
作者：小六，一个在上海努力生存的普通打工人