如果你做过几年线上服务的故障值班应该对这种凌晨并不陌生告警蜂鸣、群里一片问号、临时拉起排查群一帮人边界不清地对着日志平台刷关键字。等真正定位完问题天也亮了然后还要再花两三个小时写一份复盘把时间线、影响面、根因和行动项填进模板。我手上有个和业务耦合非常重的系统之前一次 P0 复盘光是从钉钉群、监控平台、发布系统里把证据链对齐就耗了我接近三个小时。上个月我试着用 WorkBuddy 把整条路径重走了一遍从拿到告警到产出复盘文档并发进小组40 分钟收工。这篇文章就是这次实战的完整记录。包含 WorkBuddy 的部署、skill 配置、自定义指令写法、连接器接入这些可以直接照搬的部分也包含我在过程中踩过的坑——尤其是那些让结果看起来“很有道理但其实是错的”的场景。如果你也负责线上服务的稳定性或者正准备把日常复盘工作自动化下面这些内容应该能帮你省下不少试错时间。1. 为什么一次 P0 复盘要花 3 小时“查”和“写”的时间都去哪了1.1 P0 复盘的工作量到底来自哪里P0 是故障级别里最严重的一档意味着核心链路挂了、用户侧有明确感知、需要立即响应。复盘不是事后写个纪要那么简单而是要还原从故障发生到恢复的全过程并对每一个关键节点给出证据。我按自己的实际经历拆了一下一份完整的 P0 复盘通常包含这些工作量从告警里找触发条件大约 10 分钟。告警内容经常只有一句“接口超时率 5%”但你得搞清楚它到底在说哪个服务、哪台实例、什么时间段。从日志平台拉故障时间段的日志大约 20 到 40 分钟。下载、筛选、去噪高峰期一个服务一小时的 error 日志可能有几十万条人肉 grep 非常考验耐心。从监控平台看资源曲线大约 20 分钟。CPU、内存、慢 SQL、GC 时间每一项都要扣到分钟级才能定位异常拐点。从发布平台查变更记录大约 10 分钟。核心问题是故障发生前是不是刚上线了什么配置或代码。从 IM 群还原“人说了什么”大约 10 到 20 分钟。谁在什么时候说了“我重启了一下”谁在什么时候贴过一段报错这些碎片信息拼起来往往才是完整故事。梳理时间线并写文档大约 30 到 60 分钟。这是最后一步但往往最费时因为前面拿到的是散装信息要把它们拼成阅读体验顺畅的证据链。就算全程顺利三小时一点都不夸张。这还只是“顺利”的情况如果中间有人工误判、日志权限申请、监控图导不出来时间会更长。我第一次用 WorkBuddy 前对它的预期其实没那么高只觉得能把“写文档”压缩一下就不错了。结果真正跑完后发现大头根本不在写。1.2 “语境重建”才是真正的时间黑洞复盘过程里真正消耗时间的地方不是“想”而是“找”和“切换”。四个系统的信息分布在完全不同的时间线、归属和展示维度里你每切换一个系统脑子里就要重新建立起一套“现在在查什么问题、刚才看到了什么、接下来要看什么”的上下文。举一个很典型的例子你看到一条MySQL Lock wait timeout exceeded第一反应是查这个 SQL 是哪个服务发的。于是你要去日志平台搜 traceId从 traceId 跳到调用链从调用链跳到连接池监控再从连接池监控跳回代码仓库看最近提交。每一步都要打开新页面、输入新的查询条件、重新回忆刚才的关键词。这种跳转一旦超过三四次人脑的短期记忆就开始失效你必须把中间结果记录下来然后继续跳。WorkBuddy 的思路正好反过来它把散落在 IM、日志、监控、发布平台的数据通过连接器汇总成一个统一上下文再用自定义指令驱动它做针对性检索。配置完成以后原本“人肉梳理上下文”的过程变成了“让智能体把检索结果按时间线铺开”。它不替你下结论但替你完成 80% 的信息搬运和串联。这也是为什么同样是复盘它能从 3 小时压到 40 分钟的根本原因——不是它懂业务而是它把人从反复横跳的页面里解放出来了。2. WorkBuddy 环境准备与基础配置2.1 部署方式选择与启动时的那点糟心事我一开始选的是 Linux 本地版跑在 Ubuntu 22.04 上。选择本地版的原因很简单内部系统的日志平台、监控平台都跑在内网网页版在工作台场景下接入内网数据会比较绕。但本地版有一个非常常见的坑就是启动特别慢。我第一次装好后启动光转圈就转了快十分钟一度以为进程卡死了。后来排查发现首次启动要加载模型文件和索引数据所以格外慢第二次启动会明显快很多。如果你也遇到启动卡顿可以优先看日志输出确认是在加载模型而不是在无限重试。另外有一个容易忽略的细节启动后会在项目目录里生成一个以.开头的隐藏目录WorkBuddy 的记忆数据、历史对话记录、本地索引都放在这里面。第一次用的人经常会找不到自己的配置和对话记录在哪其实就在这个隐藏目录里。如果你不想碰本地部署直接用官方工作台或者网页版也完全可以。网页版对日常复盘来说更省心更新也及时。唯一的限制是连接器涉及内网日志平台、内部 IM、内部监控系统时本地版的可定制性更强。我的建议是先从工作台跑通整个复盘流程觉得值得再上本地版不要一上来就折腾环境。2.2 skill 与自定义指令的区别和使用思路很多刚开始用 WorkBuddy 的人会分不清 skill 和自定义指令我直接说人话。skill 是一个能力模块相当于预置好的技能包你告诉它“调用哪些功能、按什么顺序执行”它就会照做。自定义指令则是你给它的固定 Prompt 模板可以理解为“按下某个快捷键就触发的操作手册”。在故障复盘场景里我把三个能力拆成了三个 skill日志拉取、时间线还原、文档生成。每个 skill 只干一件事然后用自定义指令把它们串起来。比如我在工作台里固定了一个“开始复盘”指令只要输入这个指令它就会自动按顺序执行先拉日志摘要再搜索监控指标然后对比发布记录最后生成复盘文档初稿。这里有一个值得抄作业的自定义指令模板你是我的运维复盘助手。当我说“开始复盘”时按以下步骤执行 1. 收集指定时间段内涉及服务的 error 日志、慢查询、监控指标和发布记录。 2. 按时间先后整理成时间线每条时间线必须包含“时间、来源、事件、影响”四个字段。 3. 对可疑根因给出至少两个假设每个假设标注置信度并列出可验证的命令。 4. 输出复盘模板 markdown故障概述、时间线、初步根因、影响范围、行动项、遗留问题。 5. 严禁猜测所有结论必须挂接证据无法证实的写“待确认”。这个模板看起来简单但把最关键的约束都写进去了按时间排序、带来源、给置信度、禁止猜测。我第一次用的时候没加这些限制结果它生成了一段“看起来结构完整但完全没有依据”的根因推断差点让我直接发进值班群。所以自定义指令里的约束条件比指令本身更重要。2.3 连接器把钉钉、日志平台、监控平台和发布系统接进来连接器是 WorkBuddy 能干活的基础。没有连接器它就是个普通的对话机器接上连接器之后它才能读告警、查日志、看监控、翻发布记录。我接的是钉钉连接器、日志平台 OpenAPI 和监控平台的查询接口。连接器的配置原理不复杂本质上是把各平台提供的 OpenAPI 封装成 WorkBuddy 可以调用的工具。你需要做的是提前申请好各平台的 API 权限拿到 token 或密钥然后在连接器配置里填上请求地址、鉴权方式和参数模板。这里有一个很容易踩的坑日志平台的关键字查询通常默认只返回最新 N 条不指定时间范围时你会漏掉故障窗口里的关键日志。所以我在连接器配置里强制要求所有日志查询都带上start_time和end_time参数宁可慢一点也不能漏数据。另外顺便说一句 WorkBuddy 和 CodeBuddy 的区别总有人问。WorkBuddy 更偏工作流聚合和日常任务处理适合处理告警、复盘、文档、多系统协同这类“办事”场景CodeBuddy 更偏代码生成和工程辅助适合写代码、改 bug。两者不是替代关系而是不同层面的工具。这篇文章讲的是 WorkBuddy 在运维复盘里的用法。3. 实操过程40 分钟复盘是怎么一步步跑通的3.1 0-5 分钟告警接入与信息速记这次故障的背景是某个核心服务在高峰期的错误率瞬时飙升告警在钉钉群里被触发。按照以前的流程我第一步应该是打开告警详情页人工确认告警对应的服务、实例、时间窗然后复制粘贴到临时文档里。这次我直接让 WorkBuddy 通过钉钉连接器读取告警卡片再自动从日志平台拉取故障开始前后 30 分钟的 error 日志。关键的一点是告警速记不能只记录告警原文要把告警标题、触发时间、涉及实例数、相关服务名都结构化地提取出来。我让 WorkBuddy 输出成下面这种格式告警摘要 - 告警标题core-api 错误率 5% - 触发时间2025-06-12 14:32:00 - 涉及实例3/10 - 相关服务core-api、payment-svc、user-svc - 已自动拉取日志窗口14:00 - 14:35这一步大概 2 分钟就完成了。放在以前光是把告警里的信息点完整地抄下来就得 5 到 10 分钟还不包括我去日志平台配时间窗的时间。人不是不会做而是这些机械操作占用注意力会挤掉真正需要判断的精力。3.2 5-20 分钟时间线还原与根因假设这一步我用了一个技巧先做日志去噪再做时间线还原。高峰期一小时的 error 日志里真正有价值的信息可能不到 5%。其余大部分是心跳检查超时、客户端主动断开、上游重试等“看起来异常但其实是常规噪音”的条目。如果不过滤AI 也会被噪音带偏——它会把最频繁出现的错误当成根因哪怕那些错误和故障根本不相关。所以在 skill 里我写死了一套去噪规则过滤掉告警上报、健康检查、心跳检测、客户端主动断开、已知重试机制等噪音项。过滤之后真正的异常集中在数据库连接池超时以及随之而来的接口雪崩。时间线还原这一步我让 WorkBuddy 按分钟粒度输出事件序列每条事件都带来源。刚开始它输出的时间线比较乱会把一些同时发生的事件硬排成先后关系。后来我在自定义指令里加了一句“如果多条事件时间戳相同必须标注为并行事件不要强行排序”输出质量立刻好了很多。下面是一个简化的时间线输出示例14:32:10 error core-api 数据库连接池获取连接超时wait_time 3000ms 14:32:22 error payment-svc 调用 core-api /order/detail 超时 14:32:35 监控 core-api 活跃连接数从 80 突降至 20 14:33:01 error user-svc 批量查询用户信息失败触发重试风暴 14:34:40 发布 14:20 曾有一次配置变更连接池 max_connections 从 200 调整为 60看到连接池配置变更这条我基本就知道问题方向了。但注意这里 AI 只负责把“存在配置变更”这个事实摆出来它不能直接断定“配置变更就是根因”。我把验证步骤交给人工点开发布记录确认变更人、变更内容、变更时间是否和故障时间吻合。3.3 20-30 分钟影响面评估与复盘文档初稿影响面是复盘里最容易遗漏的一环。很多人写完根因就以为复盘完成了实际上影响面没评估清楚行动项就无从谈起。我让 WorkBuddy 从监控平台拉出受影响接口的调用量、错误率、以及下游依赖的波动数据同时粗略估算故障窗口内的受影响请求数。估算的逻辑非常简单取故障时段正常基线的 QPS乘以故障持续时间再乘以错误率上升的比例就能得到一个量级。WorkBuddy 会把这类计算过程写清楚不会直接甩一个数字。我觉得这是它做得比较好的一点过程可见结果可审计。然后我要求它按团队模板生成复盘文档初稿。模板字段包括故障概述、时间线、初步根因、影响范围、行动项、遗留问题。它生成的初稿有一个通病——太“机器味”全是技术参数和错误码大段大段地堆 SQL 和监控指标。我花了大概 10 分钟把它改成“人话”补充了值班人的操作记录最后在 40 分钟内把文档发到了小组群。3.4 复盘流程中“人”的核心职责整个流程跑下来我的体会是WorkBuddy 干的是搬运工和整理员的活人干的是判断和决策的活。它把日志拉好了、时间线排好了、监控指标汇总好了人要做的是确认 AI 选出的关键证据没有遗漏比如有没有更早的异常征兆。验证根因假设不能因为 AI 说“可能是”就直接信。补充 AI 无法获取的信息比如值班人当时做了什么操作、用户反馈了什么现象。把技术结论改写成团队能读懂的复盘文档。这四步是任何自动化工具都替代不了的。如果你期望完全放手让 AI 生成一份能直接发的复盘文档那大概率会翻车。正确用法是人机各干各擅长的部分AI 负责速度和广度人负责准确性和判断力。4. 实际效果对比与误区规避4.1 三小时 vs 40 分钟到底省在了哪里我把自己之前的操作耗时和这次用 WorkBuddy 的耗时做了个对比发在下面这张表里。每个人的环境和熟练度不同数字会有偏差但比例大致可以参考。阶段传统手动方式使用 WorkBuddy 后告警信息收集15-20 分钟自动拉取1-2 分钟日志下载与过滤20-40 分钟5-8 分钟监控与发布上下文串接15-30 分钟3-5 分钟时间线还原30-50 分钟10-15 分钟含人审 5 分钟文档撰写与格式调整20-40 分钟AI 初稿 5-8 分钟人改 10 分钟合计约 3 小时约 40 分钟最明显的变化不是“写文档快了”而是“找信息快了”。原来需要人工到日志平台反复搜关键字、切页面、导出结果现在让连接器直接读接口把结果结构化输出。省下来的时间实际上是把人从机械性的信息检索里释放出来了。4.2 别把 AI 结论直接当真三个典型翻车点第一个翻车点是时间线推断错误。AI 在整理事件时容易把同一时间戳的事件硬排成因果链比如“A 错误出现在 14:32:10B 错误出现在 14:32:12”它会顺理成章地写“A 导致 B”。但这两者可能只是同一个故障的并发表现。解决办法是在自定义指令里明确要求“仅凭时间先后不能推断因果”。第二个翻车点是上下文窗口不足时AI 会遗忘早期关键信息。故障日志往往很长超出上下文窗口后它可能只根据后半段信息做推断导致早期的重要征兆被忽略。我在实际使用中遇到过它完全没提到故障前 10 分钟已经有慢查询记录的情况。解决办法是把关键日志先做摘要再喂给 AI而不是把原始日志一股脑倒进去。第三个翻车点是噪音日志干扰判断。前面说了心跳检查、客户端断开、重试机制这些常规噪音如果不提前过滤AI 很可能把“出现频率最高的错误”当成根因。所以日志去噪规则必须在 skill 里写死而且要针对不同服务单独定制。4.3 复盘文档是给人看的不是给机器看的WorkBuddy 生成的内容很容易堆满 SQL、错误码和监控指标。但真正的复盘文档是要在早会上给人读的。一份好的复盘文档应该先讲结论再讲行动项最后才是详细证据。指标和日志应该作为附录存在而不是放在正文开头。我的做法是让 WorkBuddy 同时生成两份内容一份是内部证据链全文保留所有日志、时间线和指标另一份是对外摘要版只包含结论、行动项和关键证据长度控制在一页以内。对外摘要版的写作要求我在指令里写得很死禁止出现裸的错误码禁止大段引用日志原文每个结论都不超过两行。这样出来的文档第二天早会发出去大家不用逐字翻日志也能看懂。5. 常见问题速查与个人避坑心得5.1 连接失败 3002 和启动慢的排查思路我在本地版遇到过连接失败错误码是 3002表现为登录不上或者云端资源同步中断。很多人在群里问过这个问题我当时排查了一圈最后发现是网络出口不稳定导致认证请求超时。不过 3002 本身是一个比较泛的错误码不同环境下原因可能完全不同。我的建议是先看服务端日志里完整错误上下文再检查 DNS 解析和网络策略不要盲目重装。如果你用网页版遇到 3002优先确认网络出口是否稳定如果问题持续收集日志后问官方。至于启动慢除了首次加载模型还有一个容易被忽略的地方本地版启动时会扫描目录里的历史对话记录和索引文件当索引文件越来越大启动时间也会变长。按需清理历史对话、或者把索引目录放到性能更好的磁盘上能明显改善启动速度。另外如果你看到目录里有个.开头的隐藏文件夹那就是它的数据目录备份迁移时千万别漏了它。5.2 复盘提速的五个实用技巧很多人在配置完 WorkBuddy 后依然跑不出理想效果不是工具不行而是使用姿势不对。我整理了几个亲测有效的技巧预置好“常用信息采集清单”。把服务名、默认时间范围、日志关键词做成参数复盘时只要填时间窗口不用每次都描述一遍背景。把监控查询固化到 skill 里。临时用自然语言描述“帮我查一下 CPU”和写一个固定的“查 CPU、内存、慢 SQL、GC”skill速度不是一个量级。日志去噪规则提前写死。不同服务有不同噪音花一点时间整理一次后面每次复盘都受益。让 AI 只做搬运人只做判断。职责分离避免“AI 给什么就信什么”。复盘模板及时迭代。每次 P0 或大故障后在模板里增加一个“本期新增教训”字段模板会越来越好用。5.3 什么场景下不适合用智能体做复盘WorkBuddy 的价值建立在“能连、能读、能写”之上这决定了它并不适用于所有环境。如果你的服务运行在严格离线内网、各平台没有开放 API或者故障数据本身涉及敏感信息、不允许第三方模型处理那就要谨慎使用。起码要把数据脱敏和访问权限问题先解决。还有一点容易被忽略如果团队没有形成“用自动化替代人工搬运”的共识工具再好也推不动。因为连接器配置、skill 维护、模板迭代都需要有人持续投入。没有人维护的自动化很快就会因为接口变动而失效。所以最适合 WorkBuddy 的场景是系统组件可控、接口完备、团队愿意花前期时间做配置并且对这种效率工具有一定容忍度和耐心。我个人在实际操作中的体会是WorkBuddy 这类效率智能体真正值钱的地方不是“会写文档”而是把故障复盘中大量信息搬运和串联的工作接管了。省出来的时间是让人去干更接近“判断”的事。踩过几次坑之后我的建议是平时就把复盘模板固化成团队 skill并把“每次故障必须采集的信息清单”提前写清楚不要等故障发生了才临时让它去数据库里翻。只要打通了日志、监控、发布、IM 这几个连接器P0 从 3 小时压缩到 40 分钟并不玄学而是一个稳定可复现的流程。下一次故障来的时候你也会发现真正的瓶颈已经不是“查不到”而是“有没有提前把该接的都接好”。