性能监控

持续在生产测性能在用户注意前抓回退。

为什么

性能非一次性优化；是随时间退化属性。每个新依赖、新查询、新功能加延迟，无监控回退不可见直到用户抱怨或跳。生产 RUM（真实用户监控）显实际体验——非快 CI 机器的合成 Lighthouse 分，而是中端手机 3G 真实用户实际见的 4 秒 LCP。APM（应用性能监控）追踪后端显哪个端点和数据库查询慢。合给完整图：用户体验什么（RUM）和为何慢（APM），并对回退告警使团队在成用户可见问题前修。

何时使用

从生产第一天设 RUM 和 APM。每周审查仪表盘。实时对回退告警（p95 延迟 > SLO、LCP > 2.5s）。

如何做

1. 为前端性能设 RUM
   - web-vitals 库 → 发 LCP、INP、CLS、FCP、TTFB 到分析
   - Google Analytics 4、Vercel Analytics 或 Datadog RUM
   - 按页、设备类型、地理和连接速度分解
   - 看 p75 非平均——尾是用户受苦处

2. 为后端性能设 APM
   - Datadog、New Relic 或 OpenTelemetry + Jaeger/Grafana
   - 追每请求: 入口 → 服务调用 → DB 查询 → 外部 API
   - 记每步 span 时长找瓶颈
   - 设服务图和依赖图可视化架构

3. 定义 SLO（服务级目标）违规告警
   - "p95 API 延迟 < 200ms、99.9% 请求、28 天测"
   - "75% 页面加载 LCP < 2.5s"
   - SLO 违规告警（非单请求慢）
   - 用错误预算: 烧穿预算停发功能修性能

4. 建显趋势非仅当前值的仪表盘
   - 延迟随时间（在变糟吗？）
   - 错误率随时间（趋向中断吗？）
   - 比本周上周、此部署上一部署
   - 时间线标注部署看哪个部署致回退

5. 据监控行动
   - 告警触发时追踪慢请求找根因
   - 部署回退性能时立即回滚或前修
   - 每季审查最慢端点优化前 3

示例

// RUM: 发 web vitals 到分析
import { onLCP, onINP, onCLS } from "web-vitals";

const sendVital = ({ name, value, rating, id }) =>
  navigator.sendBeacon("/api/vitals", JSON.stringify({
    name, value, rating, id,
    page: location.pathname,
    device: navigator.userAgent,
    connection: navigator.connection?.effectiveType,
  }));

onLCP(sendVital); onINP(sendVital); onCLS(sendVital);

// APM: OpenTelemetry 追踪
import { trace } from "@opentelemetry/api";

const tracer = trace.getTracer("my-app");
async function handleOrder(req, res) {
  return tracer.startActiveSpan("handleOrder", async (span) => {
    try {
      const order = await tracer.startActiveSpan("db.insert", () =>
        db.query("INSERT INTO orders ...", [req.body]),
      );
      span.setAttribute("order.id", order.id);
      res.json(order);
    } catch (err) {
      span.recordException(err);
      span.setStatus({ code: 2, message: err.message });
      throw err;
    } finally {
      span.end();
    }
  });
}

// SLO 告警（Datadog monitor JSON）
{
  "name": "API p95 延迟 SLO 违规",
  "query": "p95:trace.http.request.duration{service:api} > 200",
  "thresholds": { "critical": 200, "warning": 180 },
  "timeframe": "5m",
  "message": "API p95 延迟超 200ms SLO。调查慢端点。"
}

常见问题

⚠仅 CI 合成测试（Lighthouse）监控非生产 RUM——CI 分在快机器绿，但慢手机真实用户见 5 秒加载监控永不显。
⚠对平均延迟告警非 p95/p99——平均 100ms 告警永不触发，但 5% 用户见 3 秒请求且跳走。
⚠仪表盘显当前值非趋势——延迟今天 150ms 看好，但上月 80ms 趋向 SLO 违规。
⚠监控告警但无人查——3am 告警触发值班工程师静音，回退留数周因无跟进流程。

最佳实践

✓用 RUM（web-vitals → 分析）看真实用户体验和 APM（OpenTelemetry → Jaeger）看后端追踪——合显用户见什么和为何慢。
✓基于用户影响定义 SLO（p95 延迟、99.9% 可用）对 SLO 违规告警非个别慢请求——SLO 是与用户的契约，违规是行动信号。
✓仪表盘显趋势（本周上周、带部署标注）使回退作时间线上阶变可见，非仅今天略高的数字。
✓每个性能告警当带负责人和截止的工单——静音遗忘的告警比无监控更糟，因它造覆盖错觉。