本文系统介绍DevOps自动化运维脚本的编写方法，涵盖批量主机管理、应用部署回滚、日志监控、数据备份、健康巡检等高频场景，提供Bash磁盘巡检示例与Python选型建议，并总结幂等性、错误处理、参数化配置、Git版本管理、日志可观测与灰度执行等工程化落地规范，帮助团队将脚本沉淀为可复用的运维资产，构建完整的自动化运维闭环。

DevOps自动化运维脚本编写指南：常用场景、示例与落地规范

在微服务与容器化架构普及的今天，服务器数量动辄成百上千，靠人工执行巡检、部署、备份已经不现实。自动化运维脚本是 DevOps 体系中最基础、也最容易产生即时收益的一环。一套编写规范、维护良好的脚本库，能显著降低人为失误率，缩短故障恢复时间。本文从典型场景出发，给出可复用的编写思路和落地规范。

一、常见的自动化运维场景

运维脚本的覆盖面很广，实践中高频出现的场景主要有以下几类：

• 批量主机管理：通过 Ansible、SaltStack 或 SSH 循环，对多台服务器统一执行命令、分发配置、收集信息。
• 应用部署与回滚：拉取代码、构建镜像、滚动更新，以及失败时的快速回退。
• 日志处理与监控：定期切割日志、清理过期文件、采集关键指标并触发告警。
• 数据备份与恢复：数据库定时导出、异地同步、备份完整性校验。
• 巡检与健康检查：检查磁盘水位、CPU 负载、服务端口存活状态，输出巡检报告。

将这些场景脚本化后，再配合 CI/CD 流水线（如 Jenkins、GitLab CI）调度执行，才能形成完整的自动化闭环。

二、脚本编写示例

以最常见的磁盘巡检为例，一个健壮的 Bash 脚本应当包含阈值判断、日志记录和告警通知：

#!/bin/bash
THRESHOLD=85
LOG_FILE="/var/log/disk_check.log"

for part in $(df -h | awk 'NR>1 {print $5" "$6}'); do
    usage=${part%%%*}
    mount_point=$(echo $part | awk '{print $2}')
    if [ "$usage" -ge "$THRESHOLD" ]; then
        msg="$(date '+%F %T') [WARN] $mount_point usage: ${usage}%"
        echo "$msg" >> "$LOG_FILE"
        curl -s -X POST "https://alert.example.com/webhook" -d "{\"text\":\"$msg\"}"
    fi
done

对于逻辑更复杂的任务（如多环境部署、API 联动），建议改用 Python：它拥有 requests、paramiko 等成熟库，异常处理和结构化输出也更友好，配合虚拟环境和依赖清单，能保证脚本在任何机器上行为一致。

三、落地规范与工程化实践

脚本写得快不难，难的是写得可靠、可持续。以下几条规范值得在团队内推行：

1. 幂等性：同一脚本重复执行不应破坏系统状态。例如安装软件前先检测是否已安装，创建目录使用 mkdir -p。
2. 严格模式与错误处理：Bash 脚本开头加上 set -euo pipefail，关键步骤捕获退出码并给出明确的错误提示，避免静默失败。
3. 参数化配置：环境差异通过参数或外部配置文件传入，禁止把 IP、密码等硬编码进脚本；敏感信息交由 Vault 或 CI 密钥变量管理。
4. 版本化管理：所有脚本纳入 Git 仓库，走 Code Review 流程，重大变更打 Tag 便于审计与回溯。
5. 日志与可观测性：统一日志格式，记录执行时间、操作人、关键结果，方便事后定位问题。
6. 灰度执行：批量操作先在小范围机器上试运行，确认无误后再全量推送，并保留一键回滚手段。

结语

自动化运维脚本的价值不在于某一段代码多精巧，而在于能否被团队长期信任地复用。从高频、低风险的场景入手，逐步沉淀模板与规范，再配合版本管理和流水线调度，脚本就能从"个人工具"升级为组织级的运维资产，为整个 DevOps 体系打下坚实基础。

• DevOps自动化运维脚本
• 自动化运维脚本编写规范
• Bash运维脚本示例
• Ansible批量主机管理
• CI/CD自动化部署