人人都会AI编程

6.4 运维场景：部署脚本、配置文件生成

更新时间：2026-06-28

6.4.1 核心痛点

运维日常面临重复性高、易出错的文档工作：

  • 每次新环境部署需手写Shell/Python脚本，逻辑漏洞多（如未判断服务是否存活就重启）
  • 多环境（dev/test/prod）配置文件差异管理混乱，手动改配置常漏改端口或数据库连接串
  • K8s YAML、Nginx配置语法繁琐，缩进错误导致上线失败

6.4.2 典型应用场景

场景1：标准化部署脚本生成

需求描述：生成带完整生命周期管理的部署脚本，包含备份、灰度、回滚逻辑。

Prompt示例：

生成一个Shell脚本，用于部署Java应用jar包到Linux服务器。
要求：
1. 检查磁盘空间，低于1GB时退出
2. 自动备份旧版本jar包到/backup目录，保留最近5个版本
3. 使用supervisor管理进程，优雅重启
4. 健康检查：等待30秒后curl检查/actuator/health，失败则自动回滚
5. 发送钉钉通知（webhook地址作为参数传入）

生成脚本要点（需人工复核后使用）：

#!/bin/bash
# 自动生成的部署脚本 - 需根据实际环境调整
APP_NAME=$1
JAR_PATH=$2
WEBHOOK=$3

# 1. 前置检查
DISK_USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $DISK_USAGE -gt 90 ]; then
    echo "磁盘空间不足" && exit 1
fi

# 2. 备份逻辑（带时间戳）
BACKUP_DIR="/backup/$APP_NAME/$(date +%Y%m%d_%H%M%S)"
mkdir -p $BACKUP_DIR
cp $JAR_PATH $BACKUP_DIR/ 2>/dev/null || true
# 清理旧备份（保留5个）
ls -t /backup/$APP_NAME | tail -n +6 | xargs rm -rf

# 3. 部署与健康检查
supervisorctl stop $APP_NAME
cp $JAR_PATH /opt/apps/
supervisorctl start $APP_NAME

sleep 30
if ! curl -sf http://localhost:8080/actuator/health; then
    echo "健康检查失败，执行回滚..."
    # 回滚逻辑：恢复上一个备份
    supervisorctl stop $APP_NAME
    cp /backup/$APP_NAME/$(ls -t /backup/$APP_NAME | head -2 | tail -1)/*.jar /opt/apps/
    supervisorctl start $APP_NAME
fi

场景2：多环境配置差异化生成

需求描述：基于基础模板，自动生成不同环境的Nginx/Docker/K8s配置。

Prompt示例：

基于以下基础配置，生成3个环境的Nginx配置文件：
- 生产环境：域名api.prod.com，上游3台服务器(10.0.1.1-3)，开启Gzip和限流(100r/s)
- 测试环境：域名api.test.com，上游1台服务器(10.0.2.1)，关闭缓存
- 开发环境：本地localhost， upstream指向127.0.0.1:8080，开启CORS所有来源

基础配置包含：反向代理/api到upstream，静态资源缓存1天，日志格式为json。

关键输出差异点：

  • 生产：包含limit_req_zone限流配置，gzip_static on，SSL证书路径
  • 测试：error_log级别为debug，添加add_header X-Environment test
  • 开发：access_log off或输出到stdout，CORS头设置为*

场景3：基础设施即代码(IaC)模板

快速生成Terraform或Ansible Playbook：

Prompt：

生成Terraform代码，在阿里云创建：
1. ECS实例（2核4G，Ubuntu 22.04），绑定已有安全组sg-xxx
2. 40GB ESSD云盘，自动挂载到/data
3. 弹性IP并关联
4. 使用cloud-init安装Docker和Docker Compose
要求：变量化region、instance_name、vpc_id，输出实例公网IP

6.4.3 落地实施建议

1. 建立模板库
将高频使用的脚本模式整理为Prompt模板：

  • 数据库备份脚本（带加密和上传OSS）
  • 日志切割清理脚本
  • 蓝绿发布K8s Deployment配置

2. 关键检查清单
使用AI生成后，必须人工检查：

  • [ ] 危险操作：是否包含rm -rf /或drop database等无确认操作
  • [ ] 硬编码密码：检查是否生成明文密码，应替换为变量或密钥管理引用
  • [ ] 路径依赖：检查绝对路径是否适配当前服务器目录结构
  • [ ] 并发安全：多节点部署时是否加锁机制（如flock）

3. 混合工作流

# 最佳实践：AI生成草稿 → 本地测试 → 标准化
# 1. 生成基础脚本
ai-gen deploy.sh --template=springboot --env=prod

# 2. 本地dry-run验证
bash -n deploy.sh  # 语法检查
shellcheck deploy.sh  # 静态分析

# 3. 纳入Git版本控制，关联CI/CD
git add deploy.sh && git commit -m "feat: add auto-generated deploy script"

4. 敏感信息处理规范
严禁在Prompt中传入真实密码，应使用占位符：

# 错误做法
数据库密码是AbC123，生成连接配置...

# 正确做法
数据库密码使用变量${DB_PASSWORD}，生成配置模板...

6.4.4 避坑指南

  • 环境探测：生成的脚本常假设目标环境已安装特定工具（如jq、yq），需添加command -v jq >/dev/null 2>&1 || { echo "未安装jq"; exit 1; }
  • 时区问题：时间戳相关操作（如日志切割）需显式设置TZ='Asia/Shanghai'
  • 退出码规范：确保脚本在失败时返回非0退出码，便于CI/CD流水线捕获异常

实际效果：某中型互联网公司实践表明，使用AI辅助生成基础脚本后，部署脚本编写时间从平均45分钟/个缩短至10分钟（含人工审核），且因语法错误导致的部署失败减少约70%。