用AI写了3个月运维脚本，说说我的真实感受

阿文173
0 阅读11分钟

用AI写了3个月运维脚本，说说我的真实感受

——一个银行运维开发人员的AI协作实录

一、从"三小时脚本"到"十分钟可运行"

深夜值班，临时接到一个任务：

写一个脚本，同时从华为云和阿里云拉取所有ECS实例，比对标签，生成差异报告。

两个云的SDK认证方式不同、分页逻辑不同、异常处理要单独写、最后还要输出Markdown表格。手写的话，保守估计三小时。

我抱着试试看的心态，打开AI，把需求描述了一遍。

十分钟后，一个可运行的、带异常处理的、输出Markdown表格的脚本出现在屏幕上。

那一刻的心情很复杂：兴奋、怀疑，还有点"我是不是要失业了"的恐慌。

但这三个月用下来，我逐渐摸清了AI写脚本的甜点、雷区和正确姿势。

今天这篇文章，不吹不黑，全是真实体验。

二、三个月，我让AI写了哪些脚本？

不是随便玩玩，是真正投入到银行生产环境的日常运维中。以下是部分实战清单：

场景脚本功能行数AI贡献度
日常巡检收集Zabbix告警+云监控指标，生成日报~200行80%
资源盘点跨云（华为+阿里）ECS资产对账，标签合规检查~350行70%
故障自愈检测到特定告警后，自动重启服务+写告警日志~120行60%
数据迁移MySQL导出数据，格式化后写入Kafka~250行50%
日志分析解析Nginx日志，统计TOP10 IP和响应时间~80行90%

AI真正帮到我的：

  • SDK调用模板、分页框架写得飞快，不用翻文档
  • 异常处理、日志打印、argparse参数解析——这些样板代码全包了
  • 正则表达式生成速度惊人（以前写一个要查半天）

AI经常要我擦屁股的：

  • 复杂分页逻辑（各云厂商分页方式不同，AI经常搞混）
  • 幂等性设计（重复执行不产生副作用，AI容易忽略）
  • 敏感信息处理（AK/SK有时会被"自作聪明"硬编码进去）

三、三个拿来即用的脚本实例

光说不练假把式。下面分享三个我实际用过的脚本，每个都附上AI提示词，你可以稍作修改就用到自己的环境里。

实例一：批量检查磁盘使用率并写入告警日志

场景：每天早上巡检所有服务器磁盘，超过85%的写入告警日志，由运维平台或邮件网关统一处理通知。

AI提示词（直接复制）：

写一个Bash脚本，功能：
1. 从配置文件servers.txt读取服务器列表（格式：主机名,IP）
2. 通过SSH免密登录每台服务器，执行df -h获取磁盘使用率
3. 如果任一分区使用率超过85%，将告警信息追加写入/var/log/disk_alarm.log
4. 告警日志格式：[时间] WARN 主机名(IP) 分区名 使用率%
5. SSH连接超时设置为10秒，连接失败也要写ERROR日志
6. 脚本执行完后，统计本次巡检总数和告警数，写入日志末尾

生成的脚本：

#!/bin/bash
# 磁盘巡检脚本 - 适用于银行运维环境（免密SSH + 本地日志）
SERVERS_FILE="servers.txt"
LOG_FILE="/var/log/disk_alarm.log"
THRESHOLD=85
TOTAL=0; ALARM=0

log() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOG_FILE"; }

if [ ! -f "$SERVERS_FILE" ]; then
    log "ERROR servers.txt 不存在，退出"
    exit 1
fi

while IFS=',' read -r hostname ip; do
    [ -z "$hostname" ] && continue
    TOTAL=$((TOTAL + 1))

    # SSH免密登录，超时10秒
    result=$(ssh -o ConnectTimeout=10 -o BatchMode=yes \
        -o StrictHostKeyChecking=no "$ip" \
        "df -h | grep '^/dev'" 2>&1)

    if [ $? -ne 0 ]; then
        log "ERROR ${hostname}(${ip}) SSH连接失败: $result"
        continue
    fi

    # 逐行检查使用率
    while IFS= read -r line; do
        usage=$(echo "$line" | awk '{print $5}' | tr -d '%')
        partition=$(echo "$line" | awk '{print $1}')
        if [ -n "$usage" ] && [ "$usage" -gt "$THRESHOLD" ] 2>/dev/null; then
            log "WARN  ${hostname}(${ip}) ${partition} 使用率${usage}%"
            ALARM=$((ALARM + 1))
        fi
    done <<< "$result"

done < "$SERVERS_FILE"

log "INFO  巡检完成: 共${TOTAL}台，告警${ALARM}台"

使用方法：

  1. 提前配置好各服务器的SSH免密登录（ssh-copy-id）
  2. 创建 servers.txt，每行格式：主机名,IP
  3. chmod +x disk_check.sh && ./disk_check.sh
  4. 配合 crontab 定时执行：0 8 * * * /opt/scripts/disk_check.sh

实例二：Zabbix告警聚合 + 写本地日志（合规版）

场景：Zabbix同一台服务器的CPU告警每分钟触发一次，要聚合抑制，避免日志和邮件被淹没，告警信息统一写到标准日志文件，由运维平台统一采集处理。

AI提示词：

写一个Bash脚本，由Zabbix告警脚本触发。输入参数：主机名、告警项、当前值。
功能：
1. 检查过去10分钟内该主机的相同告警是否已记录（记录在/tmp/alarm_cache.txt）
2. 如果10分钟内已记录过，则静默退出，只写suppressed日志
3. 如果是首次或距上次超过10分钟，将告警写入/var/log/zabbix_alarm.log
4. 日志格式：[时间] ALARM 主机名 告警项 当前值
5. 同时调用aliyun CLI获取该主机最近5分钟的CPU均值，追加到日志行末尾
6. 使用jq解析返回的JSON

生成的脚本：

#!/bin/bash
# Zabbix告警聚合脚本（写本地日志版，适合银行合规环境）
HOST=$1; ITEM=$2; VALUE=$3
CACHE_FILE="/tmp/alarm_cache.txt"
ALARM_LOG="/var/log/zabbix_alarm.log"

log_alarm() { echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$ALARM_LOG"; }

# 告警抑制检查（10分钟内同一主机+告警项不重复写入）
now=$(date +%s)
last_time=$(grep "^${HOST}|${ITEM}|" "$CACHE_FILE" 2>/dev/null | tail -1 | cut -d'|' -f3)
if [ -n "$last_time" ] && [ $((now - last_time)) -lt 600 ]; then
    log_alarm "SUPPRESSED ${HOST} ${ITEM} (距上次告警 $((now - last_time))s，已抑制)"
    exit 0
fi

# 更新缓存（保留最近1000条，避免文件无限增长）
echo "${HOST}|${ITEM}|${now}" >> "$CACHE_FILE"
tail -1000 "$CACHE_FILE" > "${CACHE_FILE}.tmp" && mv "${CACHE_FILE}.tmp" "$CACHE_FILE"

# 获取云监控CPU均值（需提前配置好aliyun CLI，失败则跳过）
cpu_avg="N/A"
if command -v aliyun &>/dev/null; then
    cpu_avg=$(aliyun cms DescribeMetricList \
        --Namespace acs_ecs --MetricName cpu_total \
        --Dimensions "{\"instanceId\":\"${HOST}\"}" \
        --Period 60 --Length 5 2>/dev/null \
        | jq -r '[.Datapoints | fromjson | .[].Average] | add/length | . * 100 | round / 100' 2>/dev/null)
    cpu_avg="${cpu_avg:-N/A}"
fi

# 写入告警日志
log_alarm "ALARM  ${HOST} [${ITEM}] 当前值=${VALUE} 近5分钟CPU均值=${cpu_avg}%"

💡 使用说明：在Zabbix后台将此脚本设为告警脚本，传入参数 {HOST.NAME} {TRIGGER.KEY1} {TRIGGER.VALUE}。安装 jq，如需云监控联动则配置好 aliyun configure。/var/log/zabbix_alarm.log 可接入 ELK 或运维平台统一采集。

实例三：跨云ECS资产标签对账（Bash版）

场景：华为云和阿里云混用，每天检查所有ECS是否有 Env=prod 标签，缺失的输出到CSV，方便整改跟踪。

AI提示词：

写一个Bash脚本，同时查询阿里云和华为云的ECS实例列表。
- 阿里云：使用aliyun CLI调用DescribeInstances，分页获取所有实例
- 华为云：使用hcloud CLI调用ecs list-servers，分页获取所有实例
- 检查每个实例是否有标签 Key='Env', Value='prod'
- 缺失的实例追加写入missing_tags.csv（含实例ID、名称、云厂商、当前标签列表）
- AK/SK通过 aliyun configure 和 hcloud configure 提前配置，脚本中不出现密钥
- 添加分页循环，确保实例数量超过100时也能全量拉取
- 脚本开头检查依赖命令是否存在

生成的脚本（核心逻辑）：

#!/bin/bash
# 跨云ECS标签合规检查脚本
OUTPUT="missing_tags.csv"
echo "实例ID,实例名称,云厂商,当前标签" > "$OUTPUT"

# 检查依赖
for cmd in aliyun hcloud jq; do
    command -v "$cmd" &>/dev/null || { echo "ERROR: 缺少依赖 $cmd"; exit 1; }
done

# === 阿里云 ===
echo "[INFO] 开始检查阿里云ECS..."
page=1
while true; do
    result=$(aliyun ecs DescribeInstances \
        --RegionId cn-hangzhou --PageSize 100 --PageNumber "$page" 2>/dev/null)
    count=$(echo "$result" | jq '.Instances.Instance | length')
    [ "$count" -eq 0 ] && break

    echo "$result" | jq -c '.Instances.Instance[]' | while read -r inst; do
        id=$(echo "$inst" | jq -r '.InstanceId')
        name=$(echo "$inst" | jq -r '.InstanceName')
        tags=$(echo "$inst" | jq -c '[.Tags.Tag[]? | "\(.TagKey)=\(.TagValue)"]')
        has_prod=$(echo "$inst" | jq -r \
            '[.Tags.Tag[]? | select(.TagKey=="Env" and .TagValue=="prod")] | length')
        if [ "$has_prod" -eq 0 ]; then
            echo "${id},${name},阿里云,${tags}" >> "$OUTPUT"
        fi
    done
    page=$((page + 1))
done

# === 华为云（逻辑类似，略）===
echo "[INFO] 检查完成，结果写入 $OUTPUT"
wc -l "$OUTPUT"

完整版含华为云分页逻辑、错误重试和执行日志，约120行。后台回复 ai脚本实例 获取完整代码。

四、一次真实的"翻车"经历

拿最近一个需求举例，这个过程更能说明AI写脚本的正确用法。

需求：写一个Bash脚本，从阿里云云监控拉取所有RDS实例CPU使用率，持续5分钟超过80%就写入本地告警日志，由运维平台统一处理。

手写AI协作
耗时估计2小时实际40分钟
主要工作查CLI文档 + 写分页逻辑 + 调试审核脚本 + 修正问题

但过程并不顺滑——

第一轮：AI用了已废弃的 QueryMetricList 接口。我发现后直接告知：

你用的QueryMetricList接口已废弃，请改用DescribeMetricList（2023-01-01版本）

AI重新生成，这次对了。

第二轮：输出的CPU值带了很多位小数，影响日志可读性，我让它用 printf "%.2f" 格式化。

第三轮：发现它把AK/SK直接写成了变量赋值——银行环境绝对不允许，应该通过 aliyun configure 预先配置，脚本里不出现任何密钥字符。

总结这次翻车：AI帮我省掉了查文档和写框架的时间，但它不懂你的业务约束——接口版本对不对、AK/SK能不能硬编码、重复执行有没有副作用，这些要靠你自己把关。

五、我摸索出来的4条使用心法

心法一：提示词"五要素"，说清楚才能写得准

每次给AI的需求，至少包含这五样东西：

要素说明示例
目标脚本要解决什么"检查所有ECS是否有Env标签"
输入需要什么参数或数据"从config.yaml读取AK/SK"
输出产生什么结果"输出缺失实例到missing.csv"
约束必须遵守的规则"不能硬编码密钥；超时30秒"
环境运行环境信息"Python 3.8，用boto3 1.26版本"

五要素说清楚，和模糊一句话相比，代码质量差距非常明显。

心法二：复杂脚本拆三步，别让AI一口吃成胖子

不要一次性让AI生成几百行代码，我的习惯是：

  • 第一轮：只生成核心函数（不要异常处理，不要日志）
  • 第二轮：加上异常处理和日志打印
  • 第三轮：整合主流程，加参数解析

每轮跑通测试再进下一轮，比一次全生成省更多调试时间。

心法三：永远别信AI的"第一次回答"

AI写脚本有三类常见错误，已经被我踩遍了：

  • 🔴 API过时：它会用两年前的SDK版本（尤其是阿里云和华为云的接口）
  • 🟡 逻辑漏洞：循环中忘记重置变量、分页没有终止条件
  • 🔴 安全隐患：AK/SK被写进代码，运维环境绝不允许

我的铁律：AI代码进入测试前，必须经过 人工快速阅读 + 测试环境跑一遍 + shellcheck静态检查，缺一不可。

心法四：让AI顺手把测试和文档也写了

AI最擅长"重复性写作"，每次生成代码后，我还会顺手要它：

帮我生成这个脚本的测试用例（用临时文件模拟servers.txt，验证告警逻辑）
帮我生成脚本的usage说明（在-h参数下输出）
帮我写一个简单的README

这些东西手写很费时间，AI两分钟搞定。

六、银行场景三条铁律（重要）

普通运维和银行运维用AI写脚本，有几个本质区别，我吃过亏，单独说清楚：

铁律一：内网代码绝不上传云端AI

所有IP、域名、AK/SK、内网路径，发给AI前必须全部脱敏。

我的做法：用云端AI生成"框架"，回到内网环境手动补敏感信息。对安全要求更高的场景，用本地模型（Ollama + CodeQwen）完全离线运行。

铁律二：每版脚本必须进Git，提交信息写清楚AI参与度

git commit -m "feat: 磁盘巡检脚本 v1.0 [AI辅助生成，人工审核，pylint通过]"

出了问题能追溯，也能向上级说清楚这段代码的生产过程。

铁律三：指定Shell版本和系统环境，别让AI用新特性

银行环境可能还在用RHEL 6、bash 4.1，AI默认会用 mapfile、关联数组等bash 4.3+的特性。提示词里一定要加：

使用bash 4.1兼容语法，不要用mapfile、declare -A等新特性，系统为RHEL 7

七、我现在用的工具链

环节工具说明
对话生成DeepSeek / 通义灵码免费，国内可用
代码补全GitHub Copilot写注释自动补全代码
本地离线Ollama + CodeQwen敏感内网环境专用
代码审查shellcheck + 人工Bash脚本静态检查，发现隐患
版本管理GitLab（内网）提交信息记录AI提示词

💡 shellcheck 一行安装：yum install shellcheck 或 apt install shellcheck，把它加进CI流程，AI生成的bash脚本必须过这关再上线。

八、三个月后，我对"被取代"这件事的看法变了

三个月前我担心被AI取代。

现在我发现，担心这件事本身，说明你还在用"体力劳动"的视角看自己的工作。

AI确实取代了我80%的"查文档+写样板代码"时间。但它放大了另一件事的重要性：你对运维场景的理解有多深，决定了你的提示词写得有多准，决定了AI生成的代码有多可用。

用AI写脚本的能力，和你的领域知识正相关。你越懂运维，AI越有用。

所以——AI不会取代运维，但会用AI的运维会取代不用AI的。

这不是危言耸听，这是三个月真实体验后，最诚实的判断。

九、写在最后

如果你也是运维同行，还没开始用AI写脚本，建议今天就试一下。

从最简单的开始：让AI帮你写一个"每天凌晨清理超过30天的日志文件"的bash脚本。五分钟就能看到效果。

📌 下期预告：《运维脚本安全指南：怎样让AI帮你写代码，同时不泄露内网信息》

关注公众号 「云间豹变」，后台回复关键词获取资源：

  • ai脚本实例 —— 本文三个脚本的完整代码（含异常处理、日志、配置文件）
  • 提示词模板 —— 我整理的10个运维常用AI提示词模板

公众号.jpg

💬 你也用AI写过运维脚本吗？

翻车经历、独门技巧、或者觉得AI完全没用的理由——都欢迎评论区聊聊。

avatar
文章
阅读
粉丝