分类： Shell 脚本

线上服务起不来，最常见的报错之一是 bind: Address already in use。这时运维第一反应是 lsof -i:8080，但你是否遇到过：ss 明明显示端口被占用，lsof 却空空如也；或者反过来，lsof 列出一堆进程，ss 只给一个 LISTEN。两个工具走的是完全不同的内核数据源，理解差异才能写出靠谱的排查与清理脚本。本文给出一套可直

集群里最容易被忽略、又最容易引发"玄学故障"的基础项，就是时间。NTP 漂移几百毫秒，可能让 JWT 校验随机失败、让 Kafka 消费者位点错乱、让分布式锁提前释放、让 ELK 里的日志时间线对不上。而这类问题往往不具备可复现性，排查成本极高。 手工逐台 ssh 上去看 chronyc tracking 的运维方式，在几十台机器规模下就完全不可接受了。本文

用 curl 做服务健康检查几乎是所有运维脚本的标配，但大多数实现只写了一行 curl -s -o /dev/null -w "%{http_code}"，然后判断是否等于 200。这种写法在真实生产环境里会暴露三个问题：没有设置超时导致脚本被挂死、把「服务不可达」和「服务返回业务错误」混为一谈、无法区分 HTTP 状态码中哪些属于自身异常、哪些属于上游依赖

一、Shell 脚本的基础骨架 #!/bin/bash se…

服务器磁盘被打满的原因，九成是日志没人管。写一个能定时跑、超阈值会叫人的脚本，比事后救火体面得多。 需求拆解 按时间清理 N 天前的日志 磁盘使用率超过阈值时告警 找到并处理异常大的单个文件 全程记日志，方便事后追溯 脚本 #!/bin/b