发布后持续验证线上可用性：用合成监控探针按计划探测关键用户旅…

当需要在发布后 7×24 持续检测生产环境的关键用户旅程、可用性与性能退化，并在真实用户报障前发现故障时，用合成监控探针 + 告警路由 + SLA/错误预算验证。

适用场景

解决思路

1. 先检查 `.agents/qa-project-context.md`，若存在则以其为上下文，跳过已回答的问题；否则依次澄清：关键流程（5-10 个最重要用户旅程、哪些中断直接损失收入、哪些会静默失败、是否有 SLA/SLO）、当前监控（已有 uptime/APM/错误追踪/仪表盘、监控覆盖与用户体验的差距、当前如何得知线上问题、上次故障及检测耗时）、基础设施（单/多区域、是否有 CDN/缓存/边缘层、第三方依赖是否有监控、现有告警系统）、测试账号（是否有专用合成账号、能否排除出分析/计费/邮件、是否有 API 做程序化建号与清理）。
2. 围绕关键用户旅程而非基础设施组件设计探针，按探针类型设定频率与超时：首页加载 1 分钟/10s、登录流程 5 分钟/15s、核心工作流 5 分钟/20s、API 健康 1 分钟/5s、搜索 5 分钟/15s、结账（沙箱模式）10 分钟/25s、第三方集成 10 分钟/15s。
3. 每个探针只覆盖一条关键路径，墙钟预算控制在 30 秒以内，断言数不超过 5 个，并设置 `retries: 0`（零容忍抖动）。
4. 用三种探针形态覆盖多数需求：登录流程（Playwright 浏览器）、API 健康检查（状态 + 鉴权 + 延迟预算）、搜索探针（填查询 → 提交 → 断言结果而非仅状态码）；参考 `references/probe-implementations.md` 的可运行示例与环境感知配置。
5. 采用非破坏性探针模式：只读操作（GET、页面加载、搜索）、沙箱交易（测试模式支付、发往内部地址的邮件）、创建后立即删除（建草稿→验证→删除）、打上 synthetic 标记并在处理链路中排除；避免创建真实订单/工单/用户可见记录、触发真实通知（邮件/短信/推送）、修改共享资源（配置/权限/设置）、无法自动清理的操作。
6. 为探针建立专用测试账号：邮箱含 "synthetic" 或 "monitor" 便于识别、数据库打 `is_synthetic = true` 标记、排除出分析/计费/邮件营销/支持队列、排除出 RUM 与 SLO/错误预算管道、预置稳定测试数据、凭据放密钥管理器（`process.env`）并每季度轮换、每个并发探针使用独立账号以避免状态冲突。
7. 选择平台：Checkly（Playwright 原生、代码优先、Git 集成，Rocky AI 代理做根因分析，支持 CLI 与 MCP）、Datadog Synthetic（深度 APM 集成）、Grafana Synthetic Monitoring（开源、配 k6 2.x、固定版本通道）、AWS CloudWatch Synthetics（heartbeat/API/broken-link/visual diff 蓝图，Python 或 Node Puppeteer canary）、New Relic Synthetics、Better Stack、Uptime Kuma、或自建（Playwright/k6/Puppeteer + cron）；探针可用 Playwright(TS/JS)、Puppeteer、k6(JS)、Python 编写，选团队已维护的技术栈；新项目避免用 Pingdom。
8. 自建方案：用 GitHub Actions 的 `schedule` cron（每 5 分钟）调度 Playwright 探针，通过 secrets 注入生产凭据，结果上报到监控 webhook；托管方案用 Checkly 从多位置按固定频率运行；无论哪种都让探针环境感知，使同一份代码能以不同 base URL 与阈值跑 staging 与生产；参考 `references/platforms-and-ci.md` 的 workflow、Checkly 配置、告警路由规则与 runbook 模板。
9. 配置告警规则以削减噪音：单次失败只记录不告警；同区域连续 2 次失败 → warning；2 个以上区域连续 2 次失败 → 呼叫 on-call；延迟超过基线 2 倍持续 10 分钟 → warning；超过基线 3 倍持续 5 分钟 → 呼叫 on-call；任何探针超时连续 3 次 → 告警。
10. 按严重度路由：收入路径（登录、结账、api-health）的关键失败用 PagerDuty + Slack incidents 呼叫 on-call 并设较短重复间隔；次要探针的 warning 发到 Slack 监控频道；info 级用较长重复间隔；探针结果必须打上 `severity` 与 `probe` 标签，路由规则才能匹配（完整 `alerting-rules.yaml` 与打标签步骤见 `references/platforms-and-ci.md`）。
11. 计划维护期间抑制合成告警（探针会按设计失败），并把该窗口从错误预算计算中排除，避免计划内工作烧预算并误呼 on-call。
12. 告警消息包含足够上下文：标题 `[SYNTHETIC] {probe_name} failing from {region}`、Severity、连续失败次数、最后成功时间、错误信息、耗时与阈值、仪表盘链接、runbook 链接、受影响区域列表；`{link_to_runbook}` 指向每个探针的六行 runbook（测什么、首先检查什么、手动复现、升级路径、仪表盘、负责人）。
13. 按可用性公式计算 SLA：`Availability = (total_minutes - downtime_minutes) / total_minutes × 100`，其中 total_minutes 为当月分钟数（30 天为 43,200），downtime_minutes 为合成探针检测到故障的分钟数；常见目标：99.0% = 432 分钟、99.9% = 43.2 分钟、99.95% = 21.6 分钟、99.99% = 4.32 分钟；但目标应来自用户影响分析而非档位名称，现代实践（Google SRE Workbook、OpenSLO）偏好显式 SLO + 错误预算策略。
14. 跟踪响应时间百分位而非平均值：首页加载 P50 < 1s / P95 < 3s / P99 < 5s；API 响应 P50 < 200ms / P95 < 500ms / P99 < 1s；搜索结果 P50 < 500ms / P95 < 2s / P99 < 4s；登录流程 P50 < 2s / P95 < 5s / P99 < 8s。
15. 跟踪错误预算：如 SLO 99.9%、月 43,200 分钟则预算 43.2 分钟；按剩余比例行动——>50% 正常发布功能、25-50% 谨慎并审查近期变更、<25% 冻结非关键部署专注可靠性、耗尽则进入事故模式每次部署都需额外审查；把自身维护窗口导致的合成停机从计算中排除。
16. 多区域监控：全球服务至少 3 个区域，始终包含最接近主基础设施、用户量最大、离主基础设施最远的区域（如美国为主：us-east-1、eu-west-1、ap-southeast-1；欧洲为主：eu-west-1、us-east-1、ap-northeast-1）；按区域分别跟踪延迟，任一区域 P95 超阈值、区域间延迟差超过 5 倍、或原本健康区域持续退化时告警。
17. 做 CDN 校验：检查响应头 `x-cache`、`cf-cache-status` 是否为 `HIT`，并确认 `server` 头与预期提供商一致，以在用户遇到慢的未缓存响应前发现 CDN 配置错误和被陈旧缓存掩盖的源站故障。
18. 避免反模式：探针不要复杂（一个关键路径、30 秒内、5 个断言以内）；不要对每次失败都告警（要求连续 2-3 次且 2 个以上区域）；不要共用测试账号（每个并发探针一个专用账号）；不要只监控 happy path（断言有意义的内容：数据加载、鉴权成功、核心动作完成、搜索有结果）；不要没有 runbook（每个探针链接六行 runbook）。
19. 按失败模式排查：探针绿但用户报障 → 补内容/状态断言；告警反复触发/恢复 → 加连续失败与多区域规则；本地过 CI/区域失败 → 对比各区域结果并检查延迟差与 `x-cache`；无真实故障却失败 → 合成账号状态漂移，改为每并发探针独立账号并重置稳定数据；源站宕机但探针绿 → 断言 `cf-cache-status`/源站 `server` 头；无事故却烧错误预算 → 维护窗口被计入停机；被呼但无法行动 → 补全六行 runbook 并验证链接；可靠性数字过好 → 把 `is_synthetic` 流量从 RUM、计费与错误预算管道排除。
20. 按顺序验证监控有效：1) 对 staging 运行 `npx playwright test probes/ --reporter=list`，确认每个探针在声明超时内通过且不超过 30 秒上限；2) 把一个探针指向已知坏 URL（503 或错误路径），等其达到配置的连续失败次数，确认告警在 SLA 检测时间内路由到 on-call，并在恢复后解除；3) 临时破坏被断言的内容（在 staging 改仪表盘标题），确认探针失败——仍绿说明断言错了对象；4) 查询分析/RUM/计费管道中的 `is_synthetic` 流量，确认已被过滤。
21. 完成标准：每个关键用户旅程都有探针且断言目标而非仅 2xx；每个探针墙钟预算 < 30s 且 `retries: 0`；告警配置含 ≥2 次连续失败规则与多区域确认规则，且结果打上 `severity` + `probe` 标签；SLA 仪表盘显示当前可用性与错误预算消耗，合成流量已排除出 RUM/计费/错误预算管道；一次测试告警在 SLA 检测时间内到达 on-call（实测一次而非假设）；每个探针链接非空 runbook（含首先检查、手动复现、升级路径）；存在监控健康度的定期审查任务或日历项。

适用边界 · 注意事项

• 不适用于发布/灰度期间的安全发布技术（功能开关、金丝雀、护栏指标）——那属于 testing-in-production。
• 不适用于从生产遥测设计测试——那属于 observability-driven-testing。
• 不适用于与某次发布绑定的、一次性的部署后冒烟门禁——那属于 release-readiness。