写好一个运维脚本，核心不是让它“能跑”，而是让别人（或三个月后的你）能快速看懂、安全修改、稳定复用。可维护性不是锦上添花，而是避免线上事故的第一道防线。
命名与结构：一眼看懂脚本是干什么的
脚本名应体现用途和范围，避免 generic 名称如 deploy.sh 或 fix.sh。推荐格式：动词+模块+环境（可选）.sh，例如：backup-mysql-prod.sh、rotate-nginx-logs.sh。
- 脚本开头必须包含标准 shebang 和简明注释块：说明用途、作者、最后更新时间、预期执行用户（如 root）、依赖项（如 jq、curl）
- 所有功能逻辑封装为函数，主流程仅保留清晰的调用顺序，避免裸露的命令堆砌
- 配置项统一放在脚本顶部的 CONFIGURATION SECTION 区域，用大写变量 + 注释说明用途和可选值
参数与输入：拒绝硬编码，拥抱可控入口
脚本不应假设路径、端口、数据库名等固定值。一切可能变化的输入，都应支持外部传入。
- 使用 getopts 或更健壮的 getopt 解析短/长选项（如 -h、--host、--dry-run），禁用位置参数隐式传递
- 关键参数设为必填，缺失时打印 usage 并退出；非关键参数提供合理默认值，并在注释中明确标注
- 敏感信息（密码、token）不接受明文参数，优先从环境变量或专用配置文件读取，且配置文件权限设为 600
错误处理与日志：让失败有迹可循
运维脚本一旦出错，往往发生在深夜或无人值守时。静默失败比报错更危险。
- 全局启用 set -euo pipefail：遇到命令失败、未定义变量、管道任一环节失败即终止
- 对关键操作（如 rm、mv、systemctl restart）添加显式判断，失败时打印上下文并 exit 1，不靠上层兜底
- 统一日志输出：用 log_info、log_warn、log_error 函数封装，自动带时间戳和脚本名；调试模式（-v）下输出详细执行命令
- 重定向 stdout/stderr 到日志文件时，使用追加模式（>>）并确保目录存在，避免因路径不存在导致脚本中断
测试与交付：上线前多走一步，省去半夜救火
脚本不是写完就扔进生产 crontab 的。可维护性始于交付前的验证闭环。
- 本地模拟最小环境测试：用 bash -n 检查语法；用 shellcheck 扫描常见陷阱（如未引号变量、危险通配符）
- 在测试机上执行 dry-run 模式（如有），确认输出符合预期，不真实变更系统状态
- 脚本交付时附带简短 README.md：说明适用系统版本、依赖包安装命令、典型执行示例、已知限制
- 纳入版本管理（Git），每次修改提交清晰 commit message，关联变更原因（如 “修复 backup-mysql.sh 在 MariaDB 10.6 下超时问题”）
