用WorkBuddy做运维助手的五个实战场景

WorkBuddy运维实战：五大场景（智能巡检/故障排查/证书续期等），IT运维效率提升新方案！

核心内容：
智能巡检：自动检查磁盘/内存/安全指标，生成分级报告
故障排查：快速定位服务异常，梳理关键指标与日志
复杂操作（如SSL证书续期）：自动化高危运维任务，节省时间

研究AIOps已有1年，目前手里有不少可落地的方案了，而且目前我们已经有了自研的AIOps平台，欢迎关注并与我链接。

其实，腾讯的WorkBuddy在今年3月份就出来了，它和Claude Code / Codex是一类东西。不过，它是商业软件，所以我一直没有去测它在运维场景里的表现。

近期在公众号里频频刷到它，而且据说月活用户都有两千万了，看来这玩意在国内用户中越来越被认可啦。于是，这两天我也安装上了WorkBuddy，打算深度用一下。今天这篇文章来跟大家介绍几个WorkBuddy在运维场景的用法。

注意：以下场景已经假设提供给WorkBuddy相关的服务器权限，这里可以通过Ansible MCP搞定。

场景一：智能巡检

以前怎么干的：

每周一早上，登录每台机器，敲df -h、free -m、uptime，翻输出，记到 Excel。20 台机器干一上午。

现在让 WorkBuddy 干：

帮我巡检一下生产环境的所有服务器，检查以下内容：基础设施：- 磁盘使用率，超过 80% 的列出来- 内存和 CPU 使用率，持续超过 80% 的列出来- 系统负载，超过 CPU 核数 2 倍的列出来安全：- 所有 SSL 证书，30 天内过期的标黄，7 天内过期的标红- 检查最近 7 天有没有新增的 cron 任务或系统服务- 检查 /tmp 和 /var/tmp 下有没有可疑文件应用：- 检查所有核心服务的 /health 接口- 检查数据库连接池使用率结果整理成报告，按严重程度分 CRITICAL / WARNING / INFO 三级，发到我邮箱。
WorkBuddy会这样做：它自己去连服务器、查磁盘、检查证书、调接口，最后把报告整理好发到你邮箱。你打开邮箱，只看标红的部分，绿的直接跳过。

场景二：故障排查

以前怎么干的：

线上告警来了，用户说接口慢了。打开监控大盘，翻日志，查调用链，问开发有没有变更——折腾二三十分钟，才找到根因。

现在让 WorkBuddy 干：

帮我查一下这个告警：订单服务接口响应时间飙到 5 秒了。做以下几件事：1. 查一下这个服务最近 15 分钟的 CPU、内存、GC 情况2. 查一下最近 15 分钟的错误日志，按错误类型归类3. 查一下这个服务最近 24 小时有没有发版或者改配置4. 查一下它依赖的数据库和中间件最近有没有异常把以上信息整理成一份排查报告，告诉我：- 什么时间开始出问题的- 变化最大的指标是哪些- 最可能的根因是什么- 下一步怎么验证
WorkBuddy 会这样做：它自己去调监控 API、查日志系统、拉变更记录、比对指标，几分钟后把排查报告拍在你面前。哪个指标先跳的、哪个日志开始报错的、谁改了什么东西——时间线清清楚楚。

场景三：复杂操作——SSL 证书续期

以前怎么干的：

SSL 证书快过期了。生成 CSR、提交 CA、下载证书、上传服务器、改 Nginx 配置、reload 服务、检查 OCSP。如果涉及多台服务器、多个域名，搞半天。

现在让 WorkBuddy 干：

帮我检查一下所有线上服务的 SSL 证书状态。看看哪些证书在 30 天内过期，列个清单给我。清单里要包含：- 域名- 颁发机构- 过期时间- 部署在哪台服务器的哪个 Nginx 配置里对 7 天内过期的证书，自动走续期流程：1. 调用 Let's Encrypt API 申请新证书2. 自动做 DNS 验证3. 下载证书并部署到对应服务器4. 更新 Nginx 配置并 reload5. 验证新证书是否生效6. 每一步都要记录日志，失败了马上通知我
WorkBuddy 会这样做：扫描所有证书 → 列出即将过期的 → 自动续期 → 部署到服务器 → reload 服务 → 验证生效。你只需要看最后的执行报告。

场景四：变更影响分析

场景描述：

上线前，开发说"我就改了一行配置"。但这一行改了会影响谁？会不会导致连锁故障？以前全靠经验猜。

现在让 WorkBuddy 干：

帮我分析一下这个变更的影响范围：order-service 的数据库连接池配置要改，从 100 改到 200。查一下：1. order-service 还被哪些服务调用了？2. 下游服务有没有降级机制？3. 这个配置以前改过没有？改完出过问题吗？4. 如果改完后 order-service 挂了，会影响哪些链路？给一份风险评估报告，包含：- 直接影响的服务- 间接影响的服务- 建议的灰度步骤- 回滚操作是什么- 上线后重点看哪些指标
WorkBuddy 会这样做：它自己去查配置中心的历史、调服务拓扑图、拉变更记录，生成一份风险评估报告。你拿着报告跟开发说："这个改动影响 3 个下游服务，建议先灰度 10% 的流量，观察 15 分钟，重点看这几个指标。"

场景五：日常琐事自动化

场景描述：

运维每天都有各种"小活"：查一下某个 IP 的流量、看某个端口通不通、查一下最近有没有报错、看看谁在线上做了操作。单独都不难，但架不住一天来几十次。

现在让 WorkBuddy 干：

把这些做成一个快捷指令集，以后我说人话就能查：网络类：- "查一下 10.0.0.1 的 8080 端口通不通"- "看看这个 IP 最近的流量趋势"- "解析一下这个域名"日志类：- "帮我看看最近 1 小时的 500 错误"- "查一下这个 traceId 的完整调用链"- "这个错误码最近出现过多少次"审计类：- "查一下张三今天在线上干了什么"- "看看这个配置谁改过"- "这台服务器最近谁登录过"报告类：- "今天系统状态怎么样"- "这周出了哪些故障"- "这个月的 SLA 是多少"每个指令执行完，直接把结果返回给我。
以后群里有人问"帮我查一下某某"，你直接让 WorkBuddy 跑一遍，结果甩过去。不用自己登机器、敲命令。

用好 WorkBuddy 做运维的核心要点
需求讲明白

你把它当成是一个经验丰富的工程师，它很厉害，也很聪明，但它不会猜你想要做什么。所以，你给它派任务时一定要说明白需求，约定好边界。
把异常情况说清楚

"失败了通知我"太模糊。"失败了把错误详情发我，如果连续失败 3 次就停掉，等我人工处理"——这才是生产可用的指令。
每次执行都要有记录

跑完就完了？不行。结果记在哪、日志格式是什么、失败了有没有痕迹——没有日志的操作等于没发生。

·············· END ··············

[登录查看剩余 70% 内容](javascript:void (0);)

ai数字员工数字员工助手数字员工应用场景

用WorkBuddy做运维助手的五个实战场景