用一回真切实在的「6个租户×三场景内存压测」来表明, 能为你去安排编排些什么, 不能代办包办哪些事项, 另外, 省下的那些时间究竟都用到什么地方去了, 写在最开始之前。

做基建或中间件的人大概都干过这种活：

若是人一旦走神的状况出现, 那么窗口那怕是歪了；要是人始终目不转睛地盯着, 那半天时间也就没了。讲真, 这般的值守较之于写代码而言可是更耗费人的哟。

就在前些日子里, 我开展了一回缓存迁移三场景的内存压测工作。整个过程大概花费了70分钟 , 涉及6个现网租户 , 每个租户有三个场景情况 , 对于每个场景都要观察180秒时长。最后我并非自己坐在屏幕跟前进行计时抄写操作 , 而是在将任务编排清晰之后交给Agent去跑完 , 在关键节点它会把进度推送回来 , 这一点着实挺解压的 , 起码不用一直盯着秒表发呆。

这篇文章想讲三件事：

这一回究竟是在对什么进行测试、步骤究竟是如何安排的、在其中实际所做的事情是什么、边界在何处、效率又体现在哪些节省之处呢?

不是来吹 AI 多能干，就是一次能复盘的协作记录。

一、任务长什么样：简单，但很长业务目标

缓存需要从先前的集群迁移至新的集群, 对于互联网上每个实际租户, 可以在三种特定切换流量状态下重新播放获取流量, 从而查看接入层面（缓存代理地方）所处运营内部的存储情况和使用内存:

场景切流意图流量走向

策略在，但不命中该租户

只打旧缓存

双写双读，且命中该租户

旧缓存 + 新缓存

切流完成

只打新缓存

指标很明确，就是进程常驻内存：

process_resident_memory_bytes{job="<接入服务>"}

采集用的口径是, 三个接入实例各自进行相关操作, 之后求和, 接着在做后处理时进行除以三的运算从而得到单实例均值, 以此来方便进行横向对比, 别问为什么要除以三, 理由是汇报的人想要看单机大概是多少, 要是呈现求和的数据表, 他们会觉得数据量太大。

手工跑一个租户的标准动作

对齐过的流程大概是这样：

重启3台接入实例, sleep, 将切流策略变更为双写, 而为租户填写一个故意不命中的（比如'1'）, 秒, 启动流量回放, 朝着接入入口发送该租户的现网180秒, 记录内存SQL, 把策略里的租户改成真实ID（回放不要断开）, 再经过180秒, 记录, 然后再次重启接入（清除内存基线）, 将SQL改成「已完成/仅新缓存」, 再过180秒, 记录, 最后停止回放。

一个租户大约 10 分钟；6 个就是 一小时出头。

难的点从来并不是在于「会不会去写那两句 SQL」, 而是在于: 不要遗漏步骤, 不要看错窗口, 不要在中途刷手机从而把窗口错过。

二、如何进行编排呢: 首先要将「可重复」这一内容写进脚本之中, 之后再使得 Agent 去执行 1. 把人工制定的标准作业程序固化成为自动化脚本。

我们没有让模型, 通过「临场发挥点点鼠标」这种方式, 因为那样实在是太悬了。即便嫌麻烦, 也必须先把流程写成可重复入口, 举例如下:

python3 bench_gray_memory.py --uids-file bench_uids.txt

（这里的 uid 就是租户 / 客户标识，习惯叫法没改。）

脚本里写死这些约定：

倘若不按照这种方式去做, 那么 Agent 极易自行创立出一套针对压测语义的内容, 而后你面对最终结果时候无法进行账目的核对。将其与 SOP进行对齐是极为麻烦的事情, 不过相比于返工而言倒是省力一些。

2. 长任务丢后台，用「输出匹配」叫醒 Agent

确确实实能够使体验呈现出仿佛是存在其他人正在一同与其推行同步进展这样子情形的, 乃是其后台所具备的命令方面的能力:

后台运行着压测进程, 另外开启且持续写入.log文件, 同时启动一个tail -F去盯着日志, 并给其挂上匹配规则, 比如:

日志当中命中了关键字, 进而系统唤醒了Agent, 然后Agent去读取状态, 最后用两三句话推送给你。

并非模型于聊天之中随意揣测进度这般, 而是任务自身吐出能够被观测到的信号, 随后系统将 Agent 唤醒进行汇报。将其与传统的「人力 tail -f 加上自己抄录至群聊里」相比较, 其中的差别在于唤醒以及摘要被纳入了对话流程, 如此你能够去从事其他的事情, 只是偶尔瞅一眼推送便可以。

同类机制, 还能够运用在, /loop定时检查当中, 亦可用于CI结束通知, 在PR里, 冲突以及红灯需要一同盯着, 这些思路, 大致是相同的。

3. 结果尽量落成文件，别只剩聊天记录

跑完后我们落了几层：

最好是有可能再三运用于工程方面资产事项的源自Agent的产出成果。聊天记录进行翻页的过程实在是饱含折磨令人痛苦不已。

三、实现机制：第一次就挂了，反而把边界讲清楚了

自动化第一次跑，改库那一步直接爆了。

缘由显得比较“工程化”: SQL当中的表名反引号 ``, 当被放入bash -lc"..." 之际被视作命令替换, bash出现报错 : not found, MySQL语句也遭到截断。那时我凝视着日志大约沉默了三秒——此类坑与人们是否运用AI并无关联, 纯粹是shell转义在作祟。

修法同样很土：

修好重跑，6 个租户全流程才跑通。

所以我真正所想着重指出的是, 不会使得 shell 转义朝着正确的方向改变, 它能够在身处的切实环境中将出现的难题彻底展现出来, 随后辅助你迅速除去那些问题, 紧接着继续执行。效率源自封闭的循环内所具备的条件, 这些具备的条件是「缩短检查出问题—修复问题—再次尝试执行」所成之序列, 并非是源自「始终不会遭遇失败状况 」中的条件所致。在首次实施便能顺利通过的情况? 那绝对是不符合常理的。

另一个边界也很典型：

目标由「长得像 」转变为「数据与口径为一套」, 如此这般才称得上是提效, 截图党的那些小心思, 凉了便凉了。

四、能力边界：一张表就够了

擅长不擅长 / 做不到

把已对齐的 SOP 写成脚本并执行

替你拍板「该怎么切流、算不算达标」

长任务后台跑 + 关键字进度推送

没信号时猜进度

查 / 落盘 / 画

直接截你本机浏览器当前页

修 bash/SQL/容器类具体故障

保证第一次编排就零缺陷

并行查日志、改代码、写文档

绕过权限、审批和变更规范

说白了，它适合高强度执行和值守，不适合替你拍架构板子。

什么该测、怎样去判、窗口时长几何, 你得对齐清晰, 如此它方可吃掉那些重复劳动。

五、效率提升到底花在哪里

以这次压测粗算人的时间：

环节纯人工有 编排后

对齐场景与口径

仍需要（省不掉）

仍需要

写/改自动化脚本

1～数小时

对话式迭代，通常更快

6 租户 × 三场景执行

~70 分钟全程值守

可去做别的事，节点被推送叫醒

抄 / 整理表

易错、重复、眼神疲劳

落盘 + ÷3 出最终表

中途失败重跑

心态先崩一半，再重来

修一点，从断点语义重跑

真正省下的，通常不是「思考业务」的时间，而是：

那种最无聊的值守时间, 也就是盯着秒表、盯着面板的时间, 进行誊写, 并且要对齐时间, 这里的时间包括表、窗口、租户ID, 还要完成小故障的修复闭环, 此中有反引号、容器、权限。

倘若你一年之中所具备的价值在于「设计压测」以及「解读结果」这二者, 那么将值守交付给 Agent 的话, 性价比便会相当之高。人应当去思索数字呈现那般模样的缘由, 而并非面对着 180 秒的倒计时处于发呆状态。

六、给想试的人的最小操作建议

有类似长流程的话，可以按这个顺序来：

先将 SOP（场景、SQL、窗口、指标口径）进行对齐, 而后写进文档或者注释当中, 要是懒得写的话, 也至少自己念上一遍之后再进行脚本化（通过一个入口命令跑完整个流程）, 接着交给 Agent 后台去执行, 并且要明确表述: 「在后台运行；当日志呈现 END uid= 或者 ERROR 的时候主动告知我」, 其结果要求进行落盘（CSV 或者 JSON 格式）, 要是需要展示的话就重新查找, 绘制图表时要保留人工门禁, 还有更改切流策略、重启集群以及对现网存在副作用的动作, 那些动作的指标口径需要你先做出决定。

对关键字进行检索的话: 后台的Shell, 加上输出匹配的通知, 以及“/loop”, 还有“Hooks /”。这样就够用了, 不要一开始就堆砌一堆概念。

七、结尾

这次压测对我最大的启发，不是某个模型答对了题，而是：

当任务能够被描绘成可进行观测的状态机, 其流程为重启后续接改配置，改配置后续承接打流, 打流后续跟着等窗, 等窗后续伴随采指标进而进入下一状态, 那样便能够以执行者、值守者以及记录者的身份, 将一小时的机械流程压缩成先对齐, 对齐过后启动, 启动之后偶尔去看一眼推送相关内容, 看过推送之后收取所产生的结果。

它省下的是重复劳动；

它逼你做的是把流程讲清楚（烦，但有用）；

它暴露的是环境里真实的坑。

要是你同样在进行缓存迁移、正在做灰度验证、还在搞长稳回放, 不妨选取一个「步骤清晰然而非常耗时间」的任务尝试一回——关键之处不在于让 AI 为你承担责任, 而是使它为你留意那些原本不应当由人一直盯着的时钟。

（完）