gstack /canary教程：部署后SRE监控循环，盯住控制台错误与性能回退
【免费下载链接】gstackUse Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack
gstack /canary 是一款部署后监控（Canary Monitoring）技能：它让 Claude Code 扮演"发布可靠性工程师（SRE）"，在你部署上线后的头 10 分钟里持续巡检生产站点，盯住控制台错误、性能回退与页面加载失败，把问题挡在用户大规模投诉之前。
很多团队都有过这种噩梦：CI 全绿、部署成功，然后一条缺失的环境变量、一段命中旧缓存的 CDN 资源、一次在真实数据上变慢的数据库迁移，悄悄把线上页面打挂。/canary的定位就是"已发布"与"已验证"之间的安全网——它基于 gstack 内置的 browse 守护进程打开真实 Chromium 浏览器，周期性截图、读取 console 错误、测量页面加载时间，并与部署前基线逐条比对，发现异常立即告警。
/canary 解决的 3 个核心问题
| 问题 | /canary 的做法 |
|---|---|
| CI 通过 ≠ 生产可用 | 直接访问线上 URL，做真实的页面级验证 |
| 手动刷新页面看半天 | 每 60 秒自动巡检一轮，持续 1~30 分钟 |
| "好像变慢了"说不清 | 与部署前基线比对，加载时间超过 2 倍基线才判定为性能回退 |
核心理念一句话：对"变化"告警，而不是对"绝对值"告警。基线上本来就有 3 个控制台错误？只要部署后还是 3 个就没问题；但多出新的一错误，立即触发 HIGH 级告警。
一键安装步骤：30 秒接入
gstack 支持 Claude Code、Codex、Cursor 等 10 种 AI 编码代理。以 Claude Code 为例，把仓库克隆到技能目录并运行一次 setup 即可（仓库为只读安装，安装过程不会改动你的项目代码）：
git clone --single-branch --depth 1 https://gitcode.com/GitHub_Trending/gs/gstack ~/.claude/skills/gstack cd ~/.claude/skills/gstack && ./setup安装完成后，/canary就会出现在你的斜杠命令列表里。首次使用时，browse 守护进程需要约 10 秒的一次性构建，命令会先征求你的同意。
快速开始：一条命令启动部署后监控
/canary https://myapp.com常用参数一览（详见 canary/SKILL.md）：
| 命令 | 作用 |
|---|---|
/canary <url> | 默认监控 10 分钟 |
/canary <url> --duration 5m | 自定义时长（1m ~ 30m） |
/canary <url> --baseline | 部署前先采集基线截图 ⭐推荐 |
/canary <url> --pages /,/dashboard,/settings | 指定要监控的页面 |
/canary <url> --quick | 单次快速健康检查，不做持续监控 |
不指定--pages时，/canary 会自动打开站点、读取导航链接，发现前 5 个主要内部页面（始终包含首页），并让你确认监控范围。
基线为王：部署前 1 分钟的操作
技能文档反复强调一句话："没有基线，canary 只是一个健康检查。" 因此最佳流程是：
- 部署前：运行
/canary <url> --baseline - 它为每个页面采集：截图、控制台错误数、加载耗时、文本快照，并写入
.gstack/canary-reports/baseline.json - 命令会停下并提示你："Baseline captured. Deploy your changes, then run /canary to monitor."
- 部署后：运行
/canary <url>，进入持续监控循环
监控循环：每 60 秒在比对什么？
巡检期间，每 60 秒对每个页面执行一轮goto → 截图 → console 错误 → 性能测量，然后与基线比对，按严重度分级告警：
| 级别 | 触发条件 | 含义 |
|---|---|---|
| 🔴 CRITICAL | 页面加载失败（goto 报错或超时） | 站点直接挂了 |
| 🟠 HIGH | 出现基线中不存在的新控制台错误 | 大概率是新 bug |
| 🟡 MEDIUM | 加载时间超过基线 2 倍 | 性能回退 |
| 🔵 LOW | 基线之外的新 404 链接 | 资源或路由损坏 |
两个内置的"防狼叫"机制很实用：
- 瞬时容忍：只有连续 2 轮以上出现的模式才算告警，一次网络抖动不会惊动你
- 相对阈值：1.5 倍基线可能是正常波动，2 倍才判定为回退
触发 CRITICAL 或 HIGH 告警时，会弹出带完整证据的决策卡片：时间戳、页面 URL、异常类型、基线值、当前值、截图路径，并给出 4 个选项——A) 立即停监控去排查，B) 继续观察（可能是瞬时问题），C) 立即回滚部署，D) 判定误报继续监控。
健康报告与基线更新
监控结束后（或你手动提前停止），/canary 输出一份结构化报告：
CANARY REPORT — https://myapp.com Duration: 10 minutes Pages: 3 pages monitored Status: DEGRADED / HEALTHY 0 errors 450ms /dashboard DEGRADED 2 new 1200ms (was 400ms) VERDICT: DEPLOY HAS ISSUES — details above报告同时以 Markdown 和 JSON 存入.gstack/canary-reports/，每条告警都附带截图作为证据（规则写明：无截图的告警不允许存在）。若整轮监控一切健康，/canary 会主动询问是否用最新截图刷新基线——这样下一次部署就有了新的参照系，形成"部署 → 监控 → 更新基线"的滚动循环。
与 /land-and-deploy 组成完整发布闭环
在 gstack 的工作流里，/canary 通常紧跟 land-and-deploy/SKILL.md 使用：
/land-and-deploy负责"合并 PR → 等 CI → 部署 → 单次验证生产健康"，它内置了按改动范围分级的轻量 canary 检查（纯文档改动跳过、后端改动查 console+性能、前端改动做完整截图比对）- 验证通过后它会提示你："Want extended monitoring? Run
/canary <url>"
也就是说：单次检查负责"部署有没有挂"，/canary的持续循环负责"部署后 10 分钟有没有悄悄变坏"。两者配合，就覆盖了从 approved 到 verified in production 的全过程。更多技能哲学和完整示例可参考 docs/skills.md，浏览器底层机制见 docs/BROWSER_INTERNALS.md。
新手使用技巧清单 📋
- 高风险部署必跑：涉及前端资源、数据库迁移、CDN 变更的部署，至少跑
--duration 15m - 养成基线习惯：把
--baseline写进你的发布 checklist，部署前 1 分钟就能完成 - 关键页优先：用
--pages只盯转化路径上的页面（首页、看板、结账页），避免无差别监控稀释注意力 - 快速验证用 --quick：只想确认"页面活着没"时，单次健康检查比 10 分钟循环更省时
- 告警响应要果断：CRITICAL 告警建议先选 C（回滚）再排查，线上时间比排查时间值钱
小结
/canary用一条命令把"部署后人工盯屏"变成了自动化的 SRE 监控循环：真实浏览器、周期性巡检、基线比对、分级告警、截图取证、结构化报告。它不替你修 bug，但它保证 bug 在出现后的 10 分钟内、而不是 10 小时后，被你看见。对于用 AI 加速交付的团队来说，这正是"发得快"必须配上的那道安全闸。
【免费下载链接】gstackUse Garry Tan's exact Claude Code setup: 23 opinionated tools that serve as CEO, Designer, Eng Manager, Release Manager, Doc Engineer, and QA项目地址: https://gitcode.com/GitHub_Trending/gs/gstack
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
