Linux运维老手也常踩的5个Unix环境搭建坑
|
半年前那波Unix环境搭建,我原以为能顺顺利利——毕竟都是十年以上的老运维了,结果还是踩了五个坑,现在想起来都后怕。那天在会议室,空调滴水滴在需求单上,老张的手机震了三次,最后他直接关机了。投影仪对焦不准,我站在白板前写代码片段,结果白板笔没水了,只能用马克笔,擦都擦不掉,现在墙上还留着半行“export PATH=...”。
文章配图,仅供参考 第一个坑是环境变量优先级。老李说他在.bashrc里设了JAVA_HOME,结果启动脚本里又硬编码了另一个路径,导致服务起不来。我原以为这种低级错误十年前就该绝迹了,结果他翻出历史提交记录,发现三年前就有人这么干过,后来改了,但新服务器没同步配置。最绝的是,他居然用“source ~/.bashrc”在脚本里刷新环境变量——我说你这不是自己挖坑吗?他挠挠头:“当时急着上线,没想那么多。”第二个坑是依赖版本冲突。我们用Python写了个监控脚本,结果生产环境装的是2.7,测试环境是3.6,某些库的API都不一样。小王说他在PRD里写了“Python 3.x”,结果运维默认装了2.7,说“稳定”。更搞笑的是,有个库在3.6里叫“urllib.request”,在2.7里叫“urllib2”,脚本里混着用,报错信息全是“No module named...”。最后我们不得不把脚本拆成两版,用if判断系统版本——我原以为这种兼容性问题早该解决了,结果还是得手动处理。 第三个坑是文件权限管理。老张在/opt下建了个目录,chmod 777,说“方便大家访问”。结果第二天发现里面多了个.ssh目录,里面放着不知道谁的私钥。我问他:“你就不怕被人植入后门?”他耸耸肩:“反正是内网,没事。”我说:“内网就能乱来?上次谁把测试环境的MySQL root密码设成123456的?”他愣了一下:“那不是我...”这时候空调突然滴水,正好滴在他键盘上,他手忙脚乱地擦,手机又震了——这次是钉钉通知,他看了一眼,直接把手机扣在桌上。 第四个坑是服务启动顺序。我们有个服务依赖Redis和MySQL,结果启动脚本里先起了Redis,再起MySQL,最后起主服务。但MySQL启动慢,有时候Redis都ready了,MySQL还在初始化,主服务就报“Connection refused”。小李说他在脚本里加了sleep 5,我说:“你这不是硬编码吗?万一MySQL启动变慢了怎么办?”他翻出监控数据:“最近半年都没超过3秒。”我说:“那半年前呢?”他沉默了——我们根本没监控启动时间,只有错误日志。最后我们改成了“while ! nc -z localhost 3306; do sleep 1; done”,虽然丑,但至少不会假死。 第五个坑是日志轮转配置。老周说他在logrotate里设了“daily”,结果服务每天写10G日志,磁盘很快满了。我问他:“你没设maxsize?”他说:“设了,500M。”我说:“那为什么还爆?”他翻出配置文件,发现“daily”和“maxsize 500M”同时存在——而logrotate的规则是“满足任一条件就轮转”。结果服务每500M就切一次,但每天最多切一次,导致日志堆积。我说:“你这不是自己矛盾吗?”他挠挠头:“当时看文档没仔细...”这时候白板上的马克笔痕迹已经干了,我试着擦,结果越擦越花,最后只能用湿布擦,留下一大片水渍。 这些坑为什么老运维还会踩?我觉得是优胜劣汰——不是技术不行,而是环境变了。十年前,服务器是宝贝,配置得小心翼翼;现在云服务器一开一大片,坏了就重建,谁还仔细看文档?十年前,依赖少,版本冲突容易解决;现在一个服务可能依赖几十个库,每个库还有多个版本,谁记得清?十年前,日志是手动查看的,轮转错了能及时发现;现在日志是集中管理的,轮转错了可能几天后才爆——等发现时,磁盘早满了,服务早挂了。 那天散会后,老张说:“下次得写个checklist,把这些坑都列出来。”我说:“写也没用,没人会看。”他说:“那怎么办?”我说:“把坑写成自动化测试,启动服务前先跑一遍,报错就卡住。”他说:“那得花多少时间?”我说:“总比线上出问题强。”他沉默了——他知道我说的是对的,但排期已经排满了,谁有空写测试? 现在回头看,这些坑其实都不难解决,但为什么没人解决?因为优先级低——运维的KPI是“服务可用率”,只要服务没挂,这些小问题没人关心。而等服务挂了,大家又忙着救火,没时间复盘。就像白板上的马克笔痕迹,擦不掉就擦不掉吧,反正下次开会换块白板——但环境搭建的坑,不填的话,下次还会踩。 我后来跟老板提过,能不能给运维留点时间优化环境,而不是只救火。他说:“ROI不高,先保证业务上线。”我说:“但长期看,优化能减少故障。”他说:“长期的事,等业务稳定了再说。”我笑了笑——业务什么时候算“稳定”?等没人踩坑了,才算稳定?可坑是踩不完的,因为环境一直在变,技术一直在更新,新的坑会不断冒出来。所以,这些老运维的坑,大概会一直存在吧——除非哪天,我们不再用手动搭建环境,而是全自动化,一键生成,连checklist都不用写。 但那天在会议室,我们谁都没想到这些。我们只想着赶紧把坑填上,让服务跑起来。老张的手机又震了,这次是微信,他看了一眼,没回。小李在改启动脚本,键盘敲得啪啪响。老周在查日志轮转的文档,嘴里嘟囔着“这规则怎么这么复杂”。我站在白板前,看着那半行擦不掉的“export PATH=...”,突然觉得,这些坑,大概就是运维的宿命吧——踩过,填过,然后忘记,再踩,再填,循环往复,直到退休。 (编辑:草根网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |


Linux安全环境搭建:13年工程师实战指南
网站合规运维的7大缓存致命盲区
网站总卡壳?20年前端老兵的多媒体运维避坑指南
后端架构师亲历:12个高可用运维真相
运维老手血泪总结:5大服务器部署深坑


浙公网安备 33038102330471号