定义旅程以及成功的标准
把旅程写成步骤，例如：打开商品页、加入购物车、支付、看到确认页。为每一步写明对应的页面或端点，以及什么算成功：状态码、页面内容，以及时间上限，例如“3 秒内确认支付”。 在所有工具中保持名称稳定：用户体验中使用相同的视图名称，应用性能中使用相同的路由模板，拨测中使用旅程名称。从外部探测
- 为每个关键 API 步骤创建 HTTP / API 检查，为整条旅程创建 浏览器 检查。参见创建并发布检查。
- 断言成功的标准：状态码和确认文本用 严重 断言，时间上限用 警告 断言。
- 至少从两个地点运行，避免一条网络路径故障被当作整体中断；并设置失败和恢复阈值，避免反复抖动。
- 先 测试修订，再 发布修订。编辑会生成新草稿，已发布的检查会继续运行，直到新版本经过验证。
关注真实用户
在应用中接入 Browser RUM SDK 后：- 在性能中，关注旅程各页面第 75 百分位的 LCP、INP 和 CLS。
- 在受挫信号中，查看旅程各步骤上的狂点、死点和错误点击。
- 在错误中，把旅程的 issue 分配给负责团队。
- 打开失败旅程的会话回放，查看用户看到的画面，并用隐私设置遮掩个人数据。
用 SLO 跟踪后端
在关键步骤背后的端点（例如支付端点）上创建 SLO，选择 成功且不超过阈值，并把延迟阈值设为与旅程时间上限一致。再添加燃烧率告警：快速燃烧发出紧急通知，慢速燃烧给出警告。告知客户
为这条旅程在状态页上创建一个组件，例如“结账”。用发布自动化把它与旅程的拨测和告警规则连起来，开始时选择 人工批准：确认的故障会变成一条草稿更新，由响应人员批准后发布。每周回顾
在应用的内置用户体验仪表盘上点击 创建副本，加入拨测结果和 SLO，并每周向团队发送一份报告。关注趋势，而不只是事件：每周变差一点的 Vital，离旅程中断只差一次发布。验收标准
- 每条关键旅程至少有一个从两个地点运行、已发布且通过的拨测。
- 用户体验覆盖了旅程的各个页面，其中的错误都有负责人。
- 后端关键步骤有 SLO 和燃烧率告警。
- 状态页上有这条旅程的组件，并接到了它的拨测或规则。
- 在测试环境中让检查失败，通知会送达值班人，并生成一条草稿更新。