合ABOS at Work

ConversationSpec · 议事厅

定时跟踪 RMS 线上环境发版

平台：feishu群组：定时任务管理Topic：定时跟踪 RMS 线上环境发版Thread ID：omt_1923d18dc50f1cbb标题来源：fallback
更新：2026-08-21T19:33:38
状态：active距今：21 天任务：4/7未决问题：3
议事厅首页brief.mdtasks.mddecisions.mdmeta.json
brief.md

简述

本线程用于设计并维护「RMS 线上发版长期回查机制」：不是只看 RMS 发版成功，而是围绕发版后线上是否符合预期，形成可持续的采集口径、检查分层、风险判断和报告 checklist。

decisions.md

决策

  • 长期机制不能只以 RMS DeployRet code=0 作为“符合预期”的结论；这只能证明部署动作基本完成。
  • 发版后回查采用分层判断：部署结果 → KGOSS 运行态 → 告警/事件 → 指标/接口 → 日志 → 业务结果；证据不足时输出“待观察/待补证”，不能硬判正常。
  • 检查范围需要区分：全量 RMS 发版适合轻量筛查；重点 RMS/重点项目才做深度回查，避免定时任务过重和误报过多。
  • 当前发版跟踪任务默认只按 aboszheng 操作人匹配；后续若要覆盖会员项目/指定项目，应改为显式 RMS ID/项目白名单。
  • 长期机制必须是 AI Agent 驱动，不能做成纯脚本判定。脚本只负责采集原始证据和结构化快照；每一步判断、关联、归因、风险分级、报告措辞和下一步建议都必须由 Agent 读取证据后完成。
  • 发版回查证据面必须覆盖：CLS 日志、QA 反馈、APM、监控告警、需求变更涉及的数据、接口返回、用户体验；缺哪一项要明确标为“证据缺失/待补证”。
tasks.md

任务

  • [x] 明确 RMS 发版长期回查大方向。
  • [x] 沉淀发版后回查 checklist。
  • [x] 明确机制原则：每一步都要由 AI Agent 评估，不能纯脚本硬判。
  • [x] 将 CLS、QA 反馈、APM、监控告警、需求变更数据、接口返回、用户体验纳入回查证据面。
  • [ ] 将现有 rms-release-watch.py 从“发现发版”升级为“证据采集脚本 + Agent 分层后验 + 摘要报告”。
  • [ ] 确认长期监控范围：全量轻量、重点项目深度，或指定 RMS ID 白名单。
  • [ ] 为重点项目补充项目级业务验收项，例如 VIP 订单、支付、权益、概念版链路等。
open_questions.md

待澄清

  • 长期机制的重点项目白名单：是否先从 4333/kugouvip_kugou_com 开始？
  • 重点项目是否要配置项目级业务验收项，例如支付、订单、权益、活动任务、回调等？
  • 报告频率采用“异常即时 + 每日汇总”，还是每次发版都输出？
context.md

上下文

RMS 发版长期回查机制草案

一、大方向

长期目标不是“看到发版”，而是回答：

发版后，线上是否真的处于符合预期的状态？如果不能确认，缺哪类证据？风险等级是什么？下一步谁处理？

因此检查要分三层：

1. 全量轻量巡检：覆盖所有 RMS 线上发版，低成本判断是否有明显异常。

2. 重点项目深度回查：对明确关心的 RMS ID/项目做更完整的线上后验。

3. 异常闭环追踪：对失败重发、灰度未全量、资源水位异常、告警/日志异常持续跟踪到恢复或人工确认。

二、推荐检查分层

L0：发版事件识别

  • 是否为线上环境：source=rms_deploy 且 Env=0 / message 包含“环境：线上”。
  • 发版主体：RMS ID、项目名、版本、操作人、Handler、发版说明、时间。
  • 是否重复发版：同 RMS/同版本/同说明多次出现。
  • 是否后续覆盖：同项目后续又发了新版本。

结论口径：只能说明“发生了什么发版”。

L1：部署动作结果

  • DeployRet 是否可解析。
  • 每个集群 code 是否为 0。
  • 是否存在先失败后重发成功。
  • 灰度/全量状态：gray、replicas、grayReplicas。

结论口径：只能说明“部署动作是否完成”，不能直接等同业务正常。

L2：KGOSS 当前运行态

  • 当前线上版本是否等于本次发版版本。
  • 是否存在新旧版本分批共存，且是否符合预期灰度。
  • Pod 运行数/期望数是否一致。
  • 重启次数是否增加或非 0。
  • HPA 状态是否异常。
  • CPU/Mem 水位是否明显高于平时或接近危险值。
  • 服务事件是否为 0。

结论口径：可判断“服务运行态是否有明显异常”。

L3：告警/监控事件

  • 发版后 5/10/30 分钟内是否有 AMC/OPD/KGMonitor/Saturn 告警。
  • 是否有 P0/P1 或 fatal/error-rate/status-ratio 类告警。
  • 告警是否与该 RMS、集群、IP、接口、业务链路相关。
  • 如果告警平台不可用，必须标记“告警证据缺失”，不能当作无告警。

结论口径：可判断“发版后是否触发可见运维风险”。

L4：接口与服务指标

  • 核心 API 成功率、状态码 5xx/4xx、P95/P99 延迟。
  • QPS 是否异常下跌或突增。
  • 错误率是否较发版前基线升高。
  • 对网关/入口服务，关注下游错误、超时、熔断、限流。
  • 对 cron/异步任务，关注执行失败数、堆积、延迟。

结论口径：可判断“技术指标是否符合预期”。

L5：日志与异常样本

  • 发版后窗口内 error/exception/panic/fatal/timeout/oom 等关键词。
  • 新版本特征日志是否出现。
  • 是否有持续重复异常，还是一次性噪声。
  • 对代码变更相关关键词做定向检索。

结论口径：可解释风险原因或确认无明显异常样本。

L6：业务结果 / 项目级验收

只对重点项目做，避免全量慢查。

  • 关键业务指标是否正常：订单、支付、权益、转化、任务领取、回调等。
  • 与本次发版说明对应的功能是否有最小可验证信号。
  • 是否需要人工/产品验收。
  • 不用当前状态替代历史状态；需要按发版时间窗口锚定。

结论口径：可判断“业务是否符合预期”。

三、长期 checklist

1. 发现发版

  • [ ] 拉取 ALC/GTools source=rms_deploy 最近窗口。
  • [ ] 过滤线上环境。
  • [ ] 记录 RMS ID、项目、版本、说明、操作人、时间。
  • [ ] 去重并识别重复发版/后续覆盖。

2. 部署结果

  • [ ] 解析 DeployRet。
  • [ ] 检查所有集群 code=0。
  • [ ] 标记失败重发、部分集群失败、未知结果。
  • [ ] 判断灰度/全量字段是否与预期一致。

3. 当前运行态

  • [ ] 打开 KGOSS 应用详情。
  • [ ] 核对线上版本是否已切到目标版本。
  • [ ] 检查 Pod 运行数/期望数。
  • [ ] 检查重启次数。
  • [ ] 检查 HPA 状态。
  • [ ] 检查服务事件/安全事件。
  • [ ] 标记资源水位异常，如 CPU/Mem 高水位。

4. 告警与指标

  • [ ] 查询发版后 5/10/30 分钟告警。
  • [ ] 标记 P0/P1、错误率、超时、状态码、资源类告警。
  • [ ] 对重点项目查询接口成功率、错误率、延迟、QPS。
  • [ ] 对任务类服务查询调度成功率/堆积情况。

5. 日志与业务验收

  • [ ] 对重点项目查错误日志关键词。
  • [ ] 查新版本/功能特征日志是否出现。
  • [ ] 查本次发版说明对应的业务最小验收指标。
  • [ ] 标记需要人工确认的功能验收项。

6. 输出报告

每项发版输出统一状态：

  • 正常：部署成功 + 运行态正常 + 无相关告警/指标异常。
  • 待观察：部署/运行态基本正常，但存在高水位、灰度中、样本不足等。
  • 需关注：失败重发、Pod 异常、重启、告警、错误率升高等。
  • 证据不足：登录态/接口/权限/数据源不可用，不能判断。

报告必须包含：

  • 结论先说。
  • 异常/待观察项优先。
  • 每项判断说明证据来源。
  • 明确缺失证据和下一步。
  • 不把“查不到告警”写成“无告警”。

四、执行策略建议

  • 每 30 分钟：全量轻量检查 L0-L2，只对异常/待观察输出。
  • 发版后延迟 10 分钟：对重点项目追加 L3-L4。
  • 重点项目白名单：例如 4333/kugouvip_kugou_com 可做 L5-L6。
  • 每日汇总：输出当天所有发版、异常项、未闭环项。
  • 人工确认点：灰度是否符合预期、业务功能是否需要产品/研发验收。

五、AI Agent 驱动原则（新增硬要求）

这个长期机制不能做成纯脚本规则引擎。正确形态是：

脚本/工具 = 采集证据、拉取快照、做基础结构化
AI Agent = 逐步评估、关联证据、判断风险、指出缺口、生成报告和下一步

每一步都需要 Agent 参与判断，尤其是以下环节：

1. 发版事件理解：Agent 读取 RMS ID、版本、发版说明、Handler、需求描述，判断这次变更可能影响哪些接口、数据、业务链路和用户体验。

2. 部署结果评估：Agent 不能只看 code=0；要结合是否失败重发、灰度比例、后续覆盖、线上版本分布判断。

3. CLS 日志研判：脚本拉取日志样本和错误聚合，Agent 判断异常是否与本次发版、接口、需求关键词相关。

4. QA 反馈汇总：脚本可收集 QA 群/反馈记录/工单，Agent 判断是否是新版本问题、历史问题、环境问题或无关反馈。

5. APM 指标解读：脚本拉取成功率、耗时、QPS、错误率等，Agent 对比发版前后基线，判断是否异常波动。

6. 监控告警归因：脚本拉告警，Agent 判断告警是否关联 RMS、集群、IP、接口、业务链路，避免把无关告警误判为发版问题。

7. 需求变更数据核验：Agent 根据发版说明识别涉及的数据表、配置、缓存、AB、任务、回调、埋点，并要求对应证据。

8. 接口返回验证：脚本或工具请求接口/读取样本，Agent 判断返回是否符合预期、是否有兼容性/灰度/边界问题。

9. 用户体验判断：Agent 从 QA 反馈、接口返回、日志、APM、业务指标综合判断用户是否可感知异常，而不是只看服务没挂。

10. 报告与闭环：Agent 输出 正常 / 待观察 / 需关注 / 证据不足，并给出 owner、下一步和复查时间。

六、扩展证据面 checklist

CLS 日志

  • [ ] 发版后窗口内 error/exception/panic/fatal/timeout 走势。
  • [ ] 与版本号、RMS ID、需求关键词、接口路径相关的日志。
  • [ ] Top 错误样本、首次出现时间、持续时间、影响 IP/集群。
  • [ ] Agent 判断：是否与本次发版相关，还是历史噪声/无关异常。

QA 反馈

  • [ ] 发版后 QA 群、工单、反馈记录是否出现新问题。
  • [ ] 反馈是否能映射到本次需求、接口、页面、用户路径。
  • [ ] 是否有复现步骤、截图、用户样本、环境信息。
  • [ ] Agent 判断：新版本问题 / 历史问题 / 环境问题 / 证据不足。

APM

  • [ ] 核心接口成功率、错误率、P95/P99、QPS。
  • [ ] 发版前 30 分钟 vs 发版后 30 分钟基线对比。
  • [ ] 下游依赖超时、熔断、限流、连接池异常。
  • [ ] Agent 判断：波动是否超阈值、是否与发版时间对齐。

监控告警

  • [ ] AMC/OPD/KGMonitor/Saturn 告警。
  • [ ] P0/P1、状态码、错误率、资源、任务失败、DB/Redis/MQ 异常。
  • [ ] 告警关联 RMS、IP、集群、接口、业务链路。
  • [ ] Agent 判断：相关告警 / 无关告警 / 告警证据缺失。

需求变更涉及的数据

  • [ ] 发版说明中涉及的数据表、配置 key、缓存 key、AB、埋点、回调、任务。
  • [ ] 关键数据写入/读取是否符合预期。
  • [ ] 数据量、状态流转、回调成功率是否异常。
  • [ ] Agent 判断：数据链路是否验证充分，不能用当前 latest 状态替代历史窗口。

接口返回

  • [ ] 核心接口样本请求或线上真实样本返回。
  • [ ] 状态码、错误码、字段结构、兼容性、灰度命中。
  • [ ] 与需求预期返回对比。
  • [ ] Agent 判断：是否符合预期；是否存在边界用户/灰度用户异常。

用户体验

  • [ ] 用户路径是否可完成：打开、请求、下单、支付、领取、回调、权益生效等。
  • [ ] 页面/客户端是否有白屏、报错、延迟、状态不一致。
  • [ ] QA/客服/用户反馈是否有新增体感问题。
  • [ ] Agent 判断：用户是否可感知，影响范围和优先级。

七、Agent 输出模板

每个发版项必须由 Agent 输出：

RMS/项目/版本：
需求/变更理解：
影响面推断：接口 / 数据 / 用户路径 / 依赖
证据检查：
  - 部署：正常/异常/证据不足
  - KGOSS：正常/待观察/异常/证据不足
  - CLS：正常/待观察/异常/证据不足
  - QA反馈：无新增/有反馈/未接入
  - APM：正常/波动/异常/证据不足
  - 监控告警：无相关/有关联/证据不足
  - 数据核验：通过/待补/异常
  - 接口返回：符合/待补/异常
  - 用户体验：无感知异常/有影响/待确认
综合判断：正常 / 待观察 / 需关注 / 证据不足
原因：
下一步：
复查时间：
archive.md

Archive

  • 暂无。