运维工程师常用脚本有哪些？

在日常运维工作中，真正高频使用的往往不是复杂的自动化平台，而是一批体量不大、却能精准解决具体问题的脚本。它们部署轻、改起来快、贴合现场需求，是运维工程师工具箱里的“常备武器”。下面从几个典型场景出发，聊聊这些脚本的设计思路与落地要点。

一、系统资源实时监控脚本

这是使用频率最高的一类脚本。相比动辄需要部署采集器、时序数据库和可视化面板的完整监控体系，一个几十行的脚本就能在终端里把 CPU、内存、磁盘、网络这些核心指标盯住，调参也只需改几个阈值。

设计要点：

• 采集周期与开销：CPU 使用率通常需要一个采样窗口（例如 1 秒）来得到有意义的数值，直接瞬时读取容易失真。采样间隔要与告警灵敏度权衡。
• 指标口径统一：内存和磁盘建议统一换算成 GB 并保留两位小数，百分比单独展示，便于快速判断。
• 告警逻辑内嵌：与其事后翻日志，不如在打印时就地对超阈值情况做标记，让值班人员一眼看到异常。
• 可扩展性：把采集、格式化、告警分成独立函数，后续接入通知渠道时只需替换告警部分。

下面是一段示意性实现（Python 生态中常用系统信息库，此处以通用接口描述）：

# 伪代码示意：周期性采集并打印系统关键指标
def collect_metrics():
    cpu = get_cpu_percent(interval=1)
    mem = get_memory_info()          # 返回已用/总量/百分比
    disk = get_disk_usage("/")       # 返回已用/总量/百分比
    net = get_net_io_counters()      # 返回发送/接收字节数
    return {
        "time": now_str(),
        "cpu": cpu,
        "mem_used_gb": to_gb(mem.used),
        "mem_total_gb": to_gb(mem.total),
        "mem_percent": mem.percent,
        "disk_percent": disk_percent,
        "net_sent_mb": to_mb(net.bytes_sent),
        "net_recv_mb": to_mb(net.bytes_recv),
    }
def monitor(interval=10):
    while True:
        m = collect_metrics()
        render(m)
        if m["cpu"] > 80 or m["mem_percent"] > 85:
            emit_alert(m)
        sleep(interval)

实践建议： 生产环境不要长期在前台运行这类脚本，建议交给进程守护工具托管，并把输出重定向到日志文件，配合日志轮转避免撑满磁盘。

二、日志清理与归档脚本

磁盘被日志写满是运维最常见的故障之一。一个可靠的日志清理脚本应具备三个特征：按时间而非仅按大小清理、支持归档后再删除、执行前可预演。

典型逻辑包括：

1. 扫描指定目录下匹配规则的日志文件；
2. 对超过保留天数的文件先压缩归档到冷目录；
3. 归档成功后再删除原文件；
4. 输出本次清理的文件数量与释放空间，便于审计。

关键细节在于归档与删除的原子性：先压缩、校验压缩包完整性、再删除源文件，避免中途失败导致数据丢失。同时应排除正在被写入的当前日志文件，防止句柄异常。

三、服务健康检查与自愈脚本

对于没有完善编排能力的场景，一个定时运行的健康检查脚本可以起到“兜底”作用。它周期性探测本地或远端服务的可用性（如端口连通性、HTTP 状态码、关键接口响应），在连续失败达到阈值后触发重启或上报。

设计时需要回答几个问题：

• 探测方式：端口探测最轻量，接口探测更贴近真实可用性，但要注意探测本身带来的负载。
• 失败判定：单次失败可能是抖动，通常采用“连续 N 次失败”或“失败率超过阈值”再动作，避免误重启。
• 动作幂等：重启操作要能安全重复执行，且需限制单位时间内的重启次数，防止服务陷入反复重启的死循环。
• 状态记录：把每次探测结果和时间写入状态文件，便于事后分析故障时间线。

四、批量巡检与信息采集脚本

当需要同时了解几十上百台机器的状态时，手动登录逐台查看显然不现实。批量巡检脚本通常借助远程执行通道，把一组检查命令分发到各节点，回收结果后汇总成表格。

核心考量：

• 并发控制：并发过高会打爆目标机或跳板机，一般设置合理的并发上限；
• 超时与重试：单台无响应不能拖垮整体任务，必须设置超时；
• 结果结构化：输出统一格式（如每行一台机器的关键字段），便于后续导入表格或做差异对比；
• 只读优先：巡检类脚本默认只采集不修改，降低误操作风险。

这类脚本采集的常见项包括：系统负载、磁盘剩余、关键进程存活、内核版本、时间同步状态等。

五、告警通知脚本

监控和巡检发现问题后，需要把信息送达人。告警脚本一般被其他脚本调用，负责格式化消息并通过既定渠道发送。设计上应做到：消息简洁、包含定位信息（主机、指标、当前值、阈值、时间）、支持去重与静默。

一个常被忽视的点是告警风暴抑制：同一问题在短时间内反复触发时，应合并为一条或按周期汇总，否则真正重要的告警会被淹没。

六、写好运维脚本的通用原则

无论哪类脚本，以下几点都值得遵守：

1. 幂等性：重复执行不产生副作用，这是定时任务可靠运行的前提。
2. 可观测：脚本自身要有清晰日志，出错时能定位到具体步骤。
3. 参数化：路径、阈值、周期等通过参数或配置文件传入，避免硬编码。
4. 失败可见：异常退出要返回非零状态码，方便被调度系统捕获。
5. 最小权限：只申请完成工作所需的权限，降低误操作与安全风险。

小结

运维脚本的价值不在于复杂，而在于贴场景、可维护、能兜底。资源监控脚本解决“看得见”，日志清理脚本解决“不爆盘”，健康检查脚本解决“自愈”，批量巡检脚本解决“效率”，告警脚本解决“触达”。把这些脚本按统一规范沉淀下来，再逐步与更完善的平台能力衔接，就能在轻量与体系化之间找到适合团队的平衡点。