Linux新手避坑指南：12年数据分析师的极简部署手册

　　去年五月那场部署，现在想起来手还抖——三台机器的磁盘空间报警同时炸开，开发在群里喊“数据写不进去了”，我盯着屏幕上的df -h，发现/var/log直接吃了八十多个G。当时第一反应是“这帮开发又乱写日志”，结果冲过去一看，好家伙，是某个数据分析脚本把标准输出和错误输出全重定向到了/var/log/messages，日志文件每小时轮转一次，每次轮转完还tm用gzip压缩，压缩完反而更占空间——我原以为gzip能省地方，结果压缩后的文件比原文件还大两倍，因为全是文本数据。

文章配图，仅供参考

　　后来复盘的时候，开发说“我们以为logrotate会自动清理旧文件”，我说“你们以为？你们以为的事多了！”其实这事儿最坑的不是日志没清理，是那帮人根本没给/var/log分区留足够的空间——总空间才一百G，系统日志占二十G，数据分析脚本的日志占八十G，剩下的空间连个临时文件都放不下。我原以为分区大小这种基础配置不会出错，结果发现好几台机器的/var/log都是按默认值分的，开发说“我们以为默认值够用”，我差点把键盘砸了。

　　其实最该骂的是我自己——部署前没查磁盘空间，没查日志轮转配置，没查脚本的重定向路径。我总以为“数据分析师的部署手册”里会写这些，结果那本手册里全是“如何安装Python包”“如何配置Spark参数”，连“检查磁盘空间”这种基础操作都没提。后来我翻了自己十二年的部署记录，发现踩过的坑里，八成都是这种“我以为”的事——我以为开发会处理好日志，我以为系统分区足够大，我以为备份脚本能正常工作，结果每次都是宕机了才想起来查。

　　跟开发吵完架的第二天，我拉着他们开了个会，把那本“极简部署手册”撕了重写。新手册第一页就写：“别tm以为，先查日志、查磁盘、查备份。”第二页写：“/var/log分区至少留20%空间，数据分析脚本的日志别重定向到系统日志。”第三页写：“备份脚本必须每天跑，跑完要发邮件确认。”开发看了说“这手册太啰嗦了”，我说“啰嗦总比宕机强”。其实新手册里很多条都是去年五月那场事故的补救措施，比如“日志轮转脚本必须包含--remove-older-than参数”，比如“数据分析脚本启动前先检查磁盘空间”，比如“所有部署操作必须先在测试环境跑一遍”。

　　但说实话，有些坑还是躲不过。比如上周又出事了——一台机器的磁盘报警，我查发现是某个数据分析任务把中间结果全写到了/tmp下，/tmp分区才十G，任务跑了半天就把空间占满了。开发说“我们以为/tmp是临时目录，系统会自动清理”，我说“系统清理的是/tmp下的旧文件，不是你们这种每小时生成几个G的新文件！”后来查了发现，那台机器的/tmp分区是按最小值分的，因为“数据分析任务一般不用/tmp”，结果这次的任务偏要用。我原以为“极简手册”能覆盖所有场景，结果发现“优胜劣汰”才是真理——手册里没写的坑，迟早会踩到，踩到了才能补进去。

　　现在我的部署流程里多了条“反常识检查”：比如“别以为/var/log分区够大”“别以为/tmp会被自动清理”“别以为开发会处理好日志”。其实这些“别以为”都是血泪教训，去年五月那场事故要是早点总结，上周的坑本来能避免。但话说回来，运维这行，谁没踩过几个坑呢？我干了十二年，现在看到“极简部署手册”这种词还是犯怵——真正的极简，是把所有坑都踩一遍，然后把“别踩”写在手册里。

　　下一步我打算把“反常识检查”做成自动化脚本，部署前跑一遍，报错就停。开发说“这太麻烦了”，我说“麻烦总比宕机强”。其实我也知道，脚本再全，也防不住所有坑——比如上周那个/tmp的问题，脚本里根本没查/tmp分区大小，因为“没人会把中间结果写到/tmp”。但至少，能防住八成。剩下的两成，等踩了再补吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!