> ## Documentation Index
> Fetch the complete documentation index at: https://docs.molesignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 守护关键用户旅程

> 从三个侧面覆盖登录、结账这类旅程：从外部发起的拨测、真实用户的用户体验数据，以及带 SLO 的后端，并把它们接到状态页。

客户并不关心是哪个服务出了故障，只关心结账能不能用。挑出最重要的几条旅程，从三个侧面盯住每一条：从外部尝试它的拨测、真正走过它的用户，以及支撑它的后端。

| 侧面 | 工具 | 能发现 | 会漏掉 |
| - | - | - | - |
| 外部 | [拨测](https://docs.molesignal.com/zh-Hans/synthetics.md) | 任何时候的中断（即使没有流量）、过期证书、DNS 故障。 | 只有部分用户、设备或数据才会遇到的问题。 |
| 真实用户 | [用户体验](https://docs.molesignal.com/zh-Hans/rum) | 慢页面、前端错误、受挫行为，以及用户的真实操作。 | 没人使用这条旅程时什么也发现不了。 |
| 后端 | [应用性能 SLO](https://docs.molesignal.com/zh-Hans/apm#服务等级目标) | 旅程背后端点的错误和延迟，以及错误预算。 | 请求到达后端之前发生的故障。 |

## 定义旅程以及成功的标准

把旅程写成步骤，例如：打开商品页、加入购物车、支付、看到确认页。为每一步写明对应的页面或端点，以及什么算成功：状态码、页面内容，以及时间上限，例如“3 秒内确认支付”。

在所有工具中保持名称稳定：用户体验中使用相同的视图名称，应用性能中使用相同的路由模板，拨测中使用旅程名称。

## 从外部探测

1. 为每个关键 API 步骤创建 **HTTP / API** 检查，为整条旅程创建 **浏览器** 检查。参见[创建并发布检查](https://docs.molesignal.com/zh-Hans/synthetics.md#创建并发布检查)。
2. 断言成功的标准：状态码和确认文本用 **严重** 断言，时间上限用 **警告** 断言。
3. 至少从两个地点运行，避免一条网络路径故障被当作整体中断；并设置失败和恢复阈值，避免反复抖动。
4. 先 **测试修订**，再 **发布修订**。编辑会生成新草稿，已发布的检查会继续运行，直到新版本经过验证。

浏览器检查最多每分钟运行一次，API 检查可以更频繁。使用测试账号和测试支付方式，永远不要使用真实客户数据。

## 关注真实用户

在应用中接入 [Browser RUM SDK](https://docs.molesignal.com/zh-Hans/rum/browser-sdk.md) 后：

* 在[性能](https://docs.molesignal.com/zh-Hans/rum/performance.md)中，关注旅程各页面第 75 百分位的 LCP、INP 和 CLS。
* 在[受挫信号](https://docs.molesignal.com/zh-Hans/rum/frustration.md)中，查看旅程各步骤上的狂点、死点和错误点击。
* 在[错误](https://docs.molesignal.com/zh-Hans/rum/errors.md)中，把旅程的 issue 分配给负责团队。
* 打开失败旅程的[会话回放](https://docs.molesignal.com/zh-Hans/rum/session-replay.md)，查看用户看到的画面，并用[隐私设置](https://docs.molesignal.com/zh-Hans/rum/privacy.md)遮掩个人数据。

为意味着旅程对很多人失效的指标创建 [RUM 告警](https://docs.molesignal.com/zh-Hans/rum/alerts.md)，例如错误率或关键页面的某项 Vital。

## 用 SLO 跟踪后端

在关键步骤背后的端点（例如支付端点）上创建 [SLO](https://docs.molesignal.com/zh-Hans/apm#服务等级目标)，选择 **成功且不超过阈值**，并把延迟阈值设为与旅程时间上限一致。再添加[燃烧率告警](https://docs.molesignal.com/zh-Hans/apm#燃烧率告警)：快速燃烧发出紧急通知，慢速燃烧给出警告。

## 告知客户

为这条旅程在[状态页](https://docs.molesignal.com/zh-Hans/status-pages)上创建一个组件，例如“结账”。用[发布自动化](https://docs.molesignal.com/zh-Hans/status-pages#发布自动化)把它与旅程的拨测和告警规则连起来，开始时选择 **人工批准**：确认的故障会变成一条草稿更新，由响应人员批准后发布。

## 每周回顾

在应用的内置用户体验仪表盘上点击 **创建副本**，加入拨测结果和 SLO，并每周向团队发送一份[报告](https://docs.molesignal.com/zh-Hans/reports.md)。关注趋势，而不只是事件：每周变差一点的 Vital，离旅程中断只差一次发布。

## 验收标准

* 每条关键旅程至少有一个从两个地点运行、已发布且通过的拨测。
* 用户体验覆盖了旅程的各个页面，其中的错误都有负责人。
* 后端关键步骤有 SLO 和燃烧率告警。
* 状态页上有这条旅程的组件，并接到了它的拨测或规则。
* 在测试环境中让检查失败，通知会送达值班人，并生成一条草稿更新。

## 相关指南

* [拨测](https://docs.molesignal.com/zh-Hans/synthetics.md)
* [用户体验](https://docs.molesignal.com/zh-Hans/rum)
* [状态页](https://docs.molesignal.com/zh-Hans/status-pages)
* [验证一次发布](https://docs.molesignal.com/zh-Hans/best-practices/release-verification.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.