运维工程师日常最频繁的操作是什么？查日志、清缓存、部署上线、操作数据库——这些重复性高、步骤固定的任务，正是 WorkBuddy 最擅长的领域。本文通过四个真实场景，展示如何用 WorkBuddy 的动手执行能力完成从问题定位到修复上线的完整闭环。

🔍场景一：查日志定位线上异常

问题背景

凌晨 2 点收到告警：用户反馈支付接口超时。需要从海量日志中快速定位异常原因。

传统方式 vs WorkBuddy

传统方式：SSH 登录服务器 → 切换目录 → 用 grep 搜索关键字 → 逐条分析 → 再搜索关联日志……耗时 15-30 分钟。

WorkBuddy 方式：一句话描述需求，自动完成多步操作。

# WorkBuddy 对话
> 查一下生产环境支付服务的错误日志，最近1小时的，
  关键字 "timeout" 或 "error"，服务器 10.0.1.12

# WorkBuddy 自动执行：
# 1. SSH 连接 10.0.1.12
# 2. 搜索 /var/log/payment/ 下最近1小时的日志
# 3. 过滤 timeout 和 error 关键字
# 4. 按时间排序，提取上下文
# 5. 汇总异常原因

实际输出

WorkBuddy 执行结果：

📋 日志分析报告 - 支付服务 (10.0.1.12)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
时间范围：2026-07-27 01:15 ~ 02:15
异常总数：47 条

🔴 关键异常：
  01:23:15 [ERROR] PaymentService.connect()
    → Redis connection timeout: 10.0.1.50:6379
    → 原因：Redis 主节点宕机，哨兵未完成切换

  01:23:16 ~ 01:45:30 [WARN] 连续 134 次 timeout
    → 所有支付请求受影响

💡 建议操作：
  1. 检查 Redis 哨兵状态：redis-cli -h 10.0.1.51 info sentinel
  2. 手动触发故障转移：redis-cli -h 10.0.1.51 sentinel failover mymaster
  3. 确认新主节点就绪后观察日志

🧹场景二：清理缓存释放磁盘空间

问题背景

监控告警：服务器磁盘使用率 92%，需要紧急清理。涉及 Nginx 缓存、Docker 镜像、临时文件等多类文件。

# WorkBuddy 对话
> 服务器 10.0.1.15 磁盘快满了，帮我清理一下，
  先看看哪些目录占用大，再安全清理

# WorkBuddy 自动执行步骤：

Step 1: 分析磁盘占用
  $ ssh 10.0.1.15 "df -h"
  Filesystem      Size  Used  Avail  Use%
  /dev/sda1       100G   92G   8G    92%

Step 2: 定位大目录
  $ du -sh /var/cache/* /tmp/* /var/log/* 2>/dev/null | sort -rh | head -20
  /var/cache/nginx    28G   ← Nginx 代理缓存
  /var/lib/docker     25G   ← Docker 镜像和容器
  /tmp/build_*        12G   ← 构建临时文件
  /var/log/app       8G    ← 应用日志（可轮转）

Step 3: 安全清理（逐项确认）
  ✅ 清理 Nginx 缓存：rm -rf /var/cache/nginx/*
     → 释放 28G

  ✅ 清理过期 Docker 镜像：docker image prune -a --filter "until=168h"
     → 释放 18G（保留7天内镜像）

  ✅ 清理构建临时文件：rm -rf /tmp/build_*
     → 释放 12G

  ⚠️ 跳过日志目录（建议配置 logrotate 自动轮转）

Step 4: 验证结果
  $ df -h /dev/sda1
  Use%: 34%   ✅ 磁盘使用率恢复正常

🚀场景三：部署更新上线

问题背景

修复了支付服务的 Redis 连接问题后，需要将新版本部署到生产环境。涉及构建、推送镜像、滚动更新等步骤。

# WorkBuddy 对话
> 部署支付服务 v2.3.5 到生产环境，
  先构建镜像，再滚动更新，全程观察健康检查

# WorkBuddy 执行部署流水线：

Step 1: 拉取最新代码并构建
  $ cd /opt/payment-service && git pull origin main
  $ docker build -t registry.internal/payment:v2.3.5 .
  → 构建成功，镜像大小 245MB

Step 2: 推送到私有仓库
  $ docker push registry.internal/payment:v2.3.5
  → 推送完成

Step 3: 滚动更新 Kubernetes 部署
  $ kubectl set image deployment/payment \
      payment=registry.internal/payment:v2.3.5 \
      -n production
  deployment.apps/payment image updated

Step 4: 监控滚动更新状态
  $ kubectl rollout status deployment/payment -n production
  Waiting for deployment "payment" rollout to finish: 1 of 3 updated...
  Waiting for deployment "payment" rollout to finish: 2 of 3 updated...
  deployment "payment" successfully rolled out ✅

Step 5: 健康检查验证
  $ curl -s http://payment.prod/health | jq .
  { "status": "UP", "redis": "connected" } ✅

  $ kubectl get pods -n production -l app=payment
  NAME                       READY   STATUS
  payment-7d4f8b-x2k9        1/1     Running
  payment-7d4f8b-m5p3        1/1     Running
  payment-7d4f8b-q8w1        1/1     Running

🗄️场景四：数据库操作

问题背景

运营需要批量修正一批用户的会员等级数据，涉及条件查询和数据更新，需要格外谨慎。

# WorkBuddy 对话
> 连接生产数据库，查一下 users 表里 vip_level=2 但
  consumption>10000 的用户有多少，这些应该升级到 vip_level=3

# Step 1: 先查询，不修改
  $ mysql -h db-master -u admin -p*** production

  mysql> SELECT COUNT(*) FROM users
         WHERE vip_level = 2 AND consumption > 10000;
  +----------+
  | COUNT(*) |
  +----------+
  |      237 |
  +----------+
  → 共 237 条记录需要升级

# Step 2: 生成备份
  mysql> CREATE TABLE users_vip_backup_20260727
         AS SELECT * FROM users
         WHERE vip_level = 2 AND consumption > 10000;
  Query OK, 237 rows affected ✅ 备份完成

# Step 3: 执行更新（需确认）
  mysql> UPDATE users SET vip_level = 3,
         updated_at = NOW()
         WHERE vip_level = 2 AND consumption > 10000;
  Query OK, 237 rows affected ✅

# Step 4: 验证结果
  mysql> SELECT vip_level, COUNT(*) FROM users
         WHERE consumption > 10000
         GROUP BY vip_level;
  +-----------+----------+
  | vip_level | COUNT(*) |
  +-----------+----------+
  |         3 |      237 |  ← 全部升级成功
  +-----------+----------+

⚡四场景对比总结