徹言 (@iamcheyan) “我的工作叫服务器保守，对应国内应该就是运维。 面试的时候岗位要求写 Linux、Shell、” — TopicDigg

我的工作叫服务器保守，对应国内应该就是运维。 面试的时候岗位要求写 Linux、Shell、AWS，我想着日语虽然差点，但哥们技术没问题啊。 结果工作后才发现，这活跟技术就没关系。 国内很多互联网服务都是云原生、24 小时在线服务，而日本很多传统企业，尤其是金融行业，核心系统至今仍然依赖夜间批处理（夜間バッチ処理）。 白天业务运行，傍晚数据冻结，服务器里的JP1、A-AUTO 调度器开始启动，上千个 BAT、KSH、Shell、COBOL 等脚本按照依赖关系一个接一个执行。 有的负责传文件，有的负责清洗数据，有的负责计算，有的负责生成报表，再把结果传给下一台服务器。就是这些只有几 KB 的小脚本，几十年来支撑着整个系统每天运转。 很多人抱怨日本有些网站一下班就维护、暂停服务，就是因为后台开始跑批处理了。 这些祖传脚本很多已经运行了四五十年了，从来没有重构过。没人敢改，也没人敢删，甚至很多脚本的作者可能早就退休了。 反正小车不倒只管跑，能用就行。 那按理说，这么重要的系统应该有设计文档吧。 但脚本的大部分知识都写在 Excel 里。 输入什么文件、输出到哪里、参数是什么、依赖哪个脚本、日志在哪，全靠一个个表格来维护。 而这些表格写得极其复杂，能有几十个列，维护起来特别麻烦。 经常出现的问题是，状态不同步： 代码改了，Excel 没改；路径变了，Excel 没改；文件名改了，Excel 还是旧的……直接照着 Excel 去配置反而会出错，因为记录的信息本身就是错的。 我甚至怀疑这东西像样的版本管理都没有。 最近我们在做服务器迁移。 先根据 Excel 找文件（输入的输出的日志的），复制到新环境，运行脚本，看哪里报错；再顺着代码和日志去找真正需要的输入文件；跑通以后，再把正确的信息反过来补回 Excel。 就靠这样蚂蚁搬家的方法，去一个一个测试那数千个脚本。 代码肯定是不能改的，毕竟祖传代码，改个注释都得开会讨论好几天，能做的就是把它跑起来。 跑起来之后，把成功运行的截图，产生的文件散落，在各个地方的日志复制出来，能存到表格里的就存在表格里，不能存到表格里的，就放在一个共享磁盘里面存档。 等待下一次服务器迁移时，另外一个人一边抱怨着写的什么玩意儿，一边继续在表格里屎上雕花。