用 k6 对公开网站做端到端性能/负载/压力测试时…

当你想用 k6 对某个公开网站做性能、负载或压力测试，并需要可执行的测试套件、SLO 阈值和最终报告时使用。

适用场景

解决思路

1. 先向用户明确征询工作流（workflow）：至少 2-4 个命名工作流、凭据、读/写操作、soak 期间要避免的破坏性操作、担忧清单、已有 SLO、后端归属与 Grafana 访问权限，以及每种测试类型在本地还是 Grafana Cloud k6 运行；记录到 runbook.md。若用户说不出至少一个工作流，停下来澄清，不要继续。
2. 把技能的 assets/ 目录树复制到目标目录：cp -R "<SKILL_DIR>/assets/." "<target-dir>/"；若 cp -R 被沙箱阻止，用文件写入工具逐个复制。为每个工作流复制 recorder.template.js → recordings/scripts/wN-<short-name>.js，复制 tests/workflow.template/ → tests/wN-<short-name>/，并替换 <WORKFLOW_PLACEHOLDER> 标记。然后执行 cd <target-dir> && npm install && npx playwright install chromium。
3. 逐个录制工作流：填写 recordings/scripts/wN-<short-name>.js 的用户动作序列、recordHar.urlFilter 正则（白名单目标主机，屏蔽第三方 RUM/广告）、使用真实 Chrome 的 userAgent（默认 HeadlessChrome UA 会触发反爬）；运行 node recordings/scripts/wN-<short-name>.js 生成 recordings/har/wN-<short-name>.har；用 npx har-to-k6 recordings/har/wN-<short-name>.har -o tests/wN-<short-name>/from-har.js 转换；把 HAR 和 from-har.js 都提交（作为 bundle 路径变化的审计线索）。若录制失败或 HAR 不可用，参考 references/gotchas.md 和 references/recording-with-playwright.md。优先使用 mcp-k6 的录制与迁移工具。
4. 构建功能测试：把 from-har.js 手工清理成 protocol.js——删除逐请求 UA 头、重命名 group、参数化 BASE_URL、替换会话 token、删除 sleep(1)、对每个关键响应加 expect()；按 references/functional-tests.md 的 5 步流程从 Playwright 录制手写 browser.js；运行 ./tests/run-all.sh，在退出码为 0 之前不要进入 SLO 设计步骤。优先用 mcp-k6 迁移工具做 Playwright→k6/browser 转换。
5. 设计 SLO 与阈值，调整 assets/tests/workflow.template/ 中的默认值以匹配用户 SLO，分四层：全局 SLO（整体错误率+聚合延迟）、逐端点阈值（给每个协议请求打 tag，按 tag 设阈值）、逐迭代阈值（工作流耗时+迭代完成率）、Web Vitals（仅 LCP/INP/CLS，不含 FCP）。默认全局：http_req_failed: ['rate<0.01']、http_req_duration: ['p(95)<500']、checks: ['rate>0.99']。逐端点打 tag 示例：http.get(`${BASE_URL}/api/things`, { tags: { name: 'GetThings' } }); 'http_req_duration{name:GetThings}': ['p(95)<400', 'p(99)<800']。Web Vitals 示例：browser_web_vital_lcp: ['p(95)<2500']、browser_web_vital_inp: ['p(95)<200']、browser_web_vital_cls: ['p(95)<0.1']。详见 references/slo-design.md。
6. 构建混合负载测试：每个工作流每种测试类型一个文件，每个文件包含一个协议场景（驱动负载）加单个浏览器 VU（测量负载下的 Web Vitals）；breakpoint 仅用协议（浏览器 VU 会给信号加噪声）。默认参数：smoke 用 constant-vus 3 VUs × 1m；average 用 ramping-vus 0→20→0 over 14m；stress 用 ramping-vus 0→50→0 over 20m；spike 用 ramping-vus 0→100→0 over 2m；soak 用 ramping-vus 0→10→0 over 70m；breakpoint 用 ramping-arrival-rate 5/s→500/s over 20m 并启用 abortOnFail。看到 smoke 结果后再按工作流调参。
7. 本地运行并启用负载生成器 sidecar：./tools/run-with-monitor.sh tests/wN-<short-name>/smoke.js。该脚本后台启动 lg-monitor.sh、运行 k6，然后打印判定：OK（≥30% 空闲）、NOTE（10–30%）、WARNING（<10%）。若为 WARNING，说明笔记本是瓶颈——降低 VUs、改用云端或拆分到多个 LG。详见 references/lg-monitoring.md。
8. 推送到 Grafana Cloud k6：对 runbook 中分配给云端的每种测试类型，先确认 k6 cloud login 可用（技能不负责认证配置），先在本地跑 smoke 验证脚本，再执行 k6 cloud run tests/wN-<short-name>/<type>.js，并记录运行 URL 供最终报告使用。注意成本：浏览器 VU-hours 按协议 VU-hours 的 10 倍计费，soak 和 breakpoint 最贵，长跑前先检查配额。详见 references/local-vs-cloud.md。
9. 若用户拥有后端且有 Grafana 访问权限，做后端调查：通过 mcp-grafana 或 gcx datasources list 发现数据源；向用户询问 service label keys，不要猜测；把 k6 运行时间窗与 RED 指标、错误日志、traces、profiles（Pyroscope，使用显式 from/to 限定运行窗口）关联；交回具体证据：时间戳、查询语句、面板链接。详见 references/grafana-investigation.md。
10. 按 references/reporting.md 的模板填写最终报告：Summary（工作流、测试类型、日期）、SLOs（每个阈值通过/失败）、Findings（每条发现一段，按严重程度排序，附具体证据）、Evidence（k6 输出路径、LG monitor CSV、云端运行 URL、Grafana 链接）、Suggested next steps。必须具体，例如“GetPizza p(95) 在第 ~200 次迭代达到 1.4s；与 recommender 服务持续 100% CPU 相关，见 Grafana 面板链接”，而不是“延迟很高”。

适用边界 · 注意事项

• 仅做协议测试的套件（本技能范围外）。
• 仅 API / 非浏览器应用，以及移动原生测试。
• 超出“找到并标记 breakpoint”范围的容量规划。