Linux运维老手也常踩的5个Unix环境搭建坑

　　去年六月那回，机器挂了那刻我原以为只是常规的磁盘告警——结果盯着监控屏看了十分钟，发现是inode炸了。老张在旁边啃泡面，汤汁滴在值班表上，我让他别动，先帮我把跳板机密码重置了，那破玩意儿又过期了。后来查日志才发现，有个开发把日志文件拆成了三万个.tmp后缀的小文件，分布在/tmp下，每个就几KB，可架不住数量多啊，直接把inode池抽干了。你说这坑熟不熟？老手都容易栽——谁他妈天天盯着inode看啊？

　　第二个坑更绝，我原以为swap分区是给内存兜底的，结果有次扩容，把swap从8G调到了32G。当时还跟老板吹牛，说这下高并发稳了。结果第二天负载就飙到20+，监控屏上全是红色告警。老李蹲在机柜前，手里攥着螺丝刀，问我：“你是不是动了swap？”我点头，他冷笑：“这机器总共才16G内存，你搞32G swap，内核现在忙着在磁盘和内存之间玩跷跷板呢。”后来查了半天，发现是swapin/swapout的I/O把磁盘队列堵死了，直接卡死了所有进程。现在想起来还后怕——那可是生产环境啊，告警灯闪了一夜，我盯着屏上的三个终端，手都在抖。

　　第三个坑跟证书有关。之前有个域名到期了，我让开发去续，结果他续的是另一个子域名的证书。我原以为监控会报错，结果没——因为那个子域名根本没人用，解析都没配。直到有天老板突然说：“为什么XX服务的HTTPS访问变慢了？”我查了半天，发现客户端在跟一个过期的证书握手，重试了三次才回源到正确的地址。更离谱的是，那台机器的证书目录里，居然混着五个不同域名的.crt文件，文件名全是“backup_202305xx”这种格式，根本分不清哪个是有效的。后来我写了个脚本，每天凌晨扫描证书有效期，结果第二天就被开发投诉，说脚本把他们的测试证书删了——那玩意儿文件名叫“prod_cert_backup.crt”，脚本哪分得清啊？

　　说到备份，第四个坑简直能写进教科书。有次要迁移数据，我让DBA先做全量备份，结果他用了mysqldump的默认参数，没加--single-transaction。那台机器是InnoDB引擎，表又大，备份的时候锁了半小时表，直接把线上服务卡死了。用户端反馈“支付页面加载超时”，老板在群里@我：“怎么回事？”我查日志，发现备份进程占着MDL锁，所有写操作都在排队。更绝的是，备份文件还没生成完，磁盘空间就满了——因为没算好临时文件的大小，直接把/var给撑爆了。后来回滚的时候，发现快照也失效了，因为那天凌晨刚好有磁盘维护，快照服务被暂停了。那晚我蹲在机房，闻着冷风机的味道，听着硬盘“咔咔”响，心里直骂娘——优胜劣汰啊，这行真不是人干的。

　　第五个坑跟僵尸进程有关。有次服务突然无响应，我查top，发现CPU占用不高，但负载特别高。用ps一看，好家伙，满屏的“defunct”进程，全是某个C++服务崩溃后留下的。我原以为kill -9能解决，结果杀了父进程后，子进程全变成僵尸，挂在init进程下，怎么都清不掉。后来查了半天，发现是那个服务的信号处理函数没写好，崩溃时没正确释放资源，导致内核没法回收进程描述符。最后只能重启机器——那可是生产环境啊，重启前得跟老板、开发、测试三方确认，等他们回消息的半小时里，我盯着屏上的僵尸进程数量从200涨到500，后背全是汗。重启完，我改了信号处理函数，加了waitpid()，结果两周后，同样的坑又踩了一次——因为开发偷偷把代码回滚了，说“新版本不稳定”。

　　这些坑里，我最服的是inode那个。你说磁盘空间够，内存够，CPU也够，结果被三万个几KB的小文件干趴了。后来我写了个监控脚本，每小时检查/tmp下的文件数量，超过一万就发告警。结果第一周就触发了三次——全是开发在跑测试，生成了一堆临时文件没清理。我跟他们吵了几次，后来在跳板机上加了权限控制，非运维账号不能往/tmp写超过1000个文件。效果倒是立竿见影——第二天就有开发找我，说测试脚本跑不了了。我让他改代码，他跟我抱怨：“这多麻烦啊，以前都没事。”我冷笑：“以前没事是因为没踩到坑，现在踩到了，就得改。”

文章配图，仅供参考

　　现在我跟开发吵架都理直气壮了——他们说“以前都这样”，我就回“以前没炸，是因为还没踩到那个临界点”。老板问我“为什么又要扩容”，我就说“为了避免下次踩坑”。有时候半夜被叫起来，看着屏上的告警，反而踏实了——至少我知道，这次又躲过了一个坑。至于下一个坑在哪？谁知道呢，反正优胜劣汰，踩过的，活下来；没踩的，早晚得踩。

（编辑：站长网）

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