初八、初九，窗外轰轰隆隆的鞭炮声一直在提醒我，春节假期已经结束，大家都已开始工作啦。虽然作为一名无业游民，无所谓假期不假期的，但是觉得不能天天颓废，新年总要有新气象，于是关闭抖音，放下手机，打开电脑，开始干活。
(图源 ：pixabay)
我首先做的事情就是把N多台乱七八糟的服务器、VPS都更新、重启一下，用uptime看了一下，一些VPS已经运行了上百天，有些更是夸张，运行了一年多啦。
虽然即便不去管他们，也不会有任何影响，但是强迫症O哥就想着去弄一下，或者弄一下不是目的，O哥只是想刷一下存在感，更新、重启一整套流程下来，O哥觉得自己是个有工作的人一样。
其实重启也不是那么简单的一件事，有些没跑啥重要程序的机器直接更新系统并重启即可，有些重启后要重新运行程序，有些更麻烦的要先关闭程序再重启再重新打开。
比如自己运行的一个HIVE备份节点，要先关闭程序，还要把内存中的shared_memory.bin复制到硬盘下，这之后升级重启服务器，再把shared_memory.bin复制到内存目录中，然后再重启HIVE节点，大概是我要处理的最麻烦的一台机器呢。
除了重启VPS等，我还要整理并检查一下各个机器上运行的程序、脚本等，其实有些程序和脚本已经没啥意义了，回头把它们统统关掉，然后把VPS也停了，这样还可以节省一笔开销。
不过O哥在检查一个脚本时，竟然有了惊人的发现，这脚本运行竟然报了一堆错误信息，而O哥在脚本中把各种输出信息以及出错信息都重定向到一个日志文件中，但是除了部署的时候检查过几次输出，之后就再也没有检查过啦。
从出错信息来看，这个脚本已经有好几年没有正确工作过啦，而这个脚本对我而言又非常重要，怎么可能几年没工作都没发现呢？
仔细想想才想明白，原来因为这个脚本非常非常重要，为了避免出错，O哥在家里的一台常年运行的机器上部署了一个备份脚本，两个脚本同时工作，一旦一个出错，另外一个也能顶上，不会导致什么不良影响。
也就是说，其实主脚本已经死掉了好多年，都是备份脚本在工作，虽然一直没出问题，但是这本身就是个大问题呀，相当于我只运行了一个脚本，一旦家里的机器出一点故障（电源、网络等），岂不就死翘翘了？
想到每次出行，我都觉得非常安心——因为重要的脚本我都有主备两套方案，现在想想非常后怕，损失几个亿倒是不可能，但是一旦出故障，足以让我手忙脚乱肉疼不已。
那么又是为啥导致这个故障呢？毕竟我部署的时候做过全面的测试，之后每次更新我也进行过测试啊。于是决定下决心找一下原因。
这个脚本运行思路是这样，根据链上数据，计算出执行某操作的时间，进而计算出需要等待的时间，等待，执行操作并将结果写入日志。
除了部署那会，之前每次测试时只是简单执行一下脚本，发现读数据以及计算时间等都正常，就觉得OK了。以往确实主要BUG都在这个过程，而执行从未出错过，所以想当然的认为部署好了，就不会出错了。
那么又是什么原因导致出错呢？原本我打算用错误信息作为关键字搜索一下，确实搜索到很多结果，排名最前的确实是这个项目的github仓库的问题列表(issues)，然而我想去查看一下，发现我又打不开github啦，唉，总是在关键的时候抽风（谁抽风？）
不过这也难不住我，为啥主脚本不可用，而备份脚本正常工作呢？我分析一下，大致有两种可能，一是客户端的问题，二是服务器的问题（脚本使用客户端去读取服务器节点上的一些信息）。
虽然我可以通过进一步测试，组合出能协同工作的脚本与客户端，但是懒病发作的我决定还是直接把主脚本用的客户端工具升级到最新版本，升级后又进行了一次彻底的测试，发现总算一切正常了。
(图源 ：pixabay)
一开工就揪出并解决这个隐藏如此之深的陈年老BUG，还是很有成就感的，真是一个好兆头。
希望龙年里各个服务器、VPS从不DOWN机；各个脚本都能一直正常工作，BUG从不被触发！当然了，我还要继续“干活”刷存在感，装成有工作的人，顺便希望每次“干活”时都有新发现、新进展，成就感满满。
