技能介绍

要解决什么问题

Redis 与 RabbitMQ 在生产里往往同时存在：缓存顶到 maxmemory、慢查询和 fork/AOF 卡顿、队列积压却分不清是「没消费者」还是 unacked 堆积，连接数异常抖动却被当成「延迟问题」去杀连接。手工在 RESP 与管理 API 之间切换，写操作又缺少可追溯的前后状态，一旦改错策略或误 purge，很难还原。

技能如何工作

本技能通过 28 个 MCP 工具覆盖两类 broker：Redis 走 RESP 客户端，RabbitMQ 走管理 HTTP API；platform 字段按目标选型，一套配置可管混合环境。每个工具都挂在内置的 @governed_tool harness 上：操作写入 ~/.queue-aiops/ 下的统一审计库，带策略引擎、token/失控循环熔断，以及可撤销写操作的 undo 描述符；密码经 Fernet + scrypt 加密存于 secrets.enc，不落明文。

读侧包括概览、INFO/慢日志/大 key 采样（SCAN 预算，报告覆盖率）、队列与连接清单等。四条旗舰分析是透明启发式，会给出数字而非黑盒结论：redis_memory_pressure_rca、redis_latency_rca（按命令模式消化 SLOWLOG）、rabbitmq_queue_backlog_rca、connection_churn_analysis。

写侧分风险档：中等风险的 redis_config_set、declare_queue、set_policy 等可捕获变更前状态并支持 undo；purge_queue、delete_queue 为高风险，需 dry-run 与二次确认，且消息不可恢复。CLI 与 MCP 走同一套治理与审计路径。

适用边界与注意

只适用于 Redis / RabbitMQ broker 运维；虚拟机、存储、数据库、监控栈等应路由到同系列的其它 AIops-tools 技能。
技能记录并审计写操作，不代替你判断是否允许执行；只读仍取决于所连账号的 ACL/管理标签。
redis_kill_client、purge_queue 不可逆且无 undo；delete_queue 的 undo 仅恢复队列定义，不恢复消息与外部 binding。
将 noeviction 改为淘汰策略会导致 Redis 主动删键——若实例当存储而非缓存，应加内存而非改策略，必要时用 undo_apply 回滚运行期配置（重启后仍需在配置文件中持久化）。

截图预览

使用场景

Redis 已接近 maxmemory 并开始淘汰或写失败，需要对照 used/maxmemory、淘汰策略与大 key 采样做 memory 压力根因分析并决定是否改 policy。
RabbitMQ 某 vhost 单条或多条队列深度持续上涨，要先查节点 watermark 告警，再用 backlog 分析区分无消费者、unacked 堆积与投递速率不足。
Redis P99 延迟升高，需结合 SLOWLOG、按命令模式的 latency RCA 以及 clients/blocked 数，判断是 O(N) 查询还是持久化 fork 卡顿。
在事故或变更窗口需要安全改 broker 状态：如 `config-set`、队列策略或声明队列用 dry-run；高风险 purge/delete 前必须预览，并依赖 undo 恢复可逆变更。

适合人员

对 Redis/RabbitMQ 承担 on-call 的 SRE，希望在告警窗口内用概览与四条旗舰分析拿到带数字的结论，而不是临时拼 RESP 与管理 API。
维护多套 broker 目标清单的平台工程师，需要 MCP 与 CLI 共用 `~/.queue-aiops/` 审计、策略熔断与加密凭据，满足 mixed estate 同一配置。
负责消息消费链路的后端技术负责人，队列积压时需要按连接/通道确认消费者是否存在、prefetch 是否饿死吞吐，再决定扩容消费者还是加 max-length 策略。
在变更评审中执行 broker 写操作的运维工程师，要求中等风险操作可 undo、误 purge 前有 dry-run 与二次确认，且所有调用落同一 audit 库备查。