A06 可观测性与稳定性工程：让系统可见、可控、可恢复

目标：建立系统化的可观测性思维，掌握前端监控、错误处理、性能度量、稳定性设计和故障响应能力。

---

核心要点（TL;DR）

• 可观测性不是“监控图表”，而是通过外部输出理解系统内部状态的能力。
• 可观测性三大支柱：日志（Logs）、指标（Metrics）、追踪（Traces）。
• 前端监控包括：错误监控、性能监控、业务埋点、用户行为分析。
• 稳定性工程的目标是减少故障发生、缩短故障恢复时间、降低故障影响范围。
• SLO/SLA/Error Budget 是量化稳定性的核心概念。
• 告警不是越多越好，好的告警要少而精，能驱动行动。

---

学习时长与前置知识

• 建议学习时长：2-3 周（每周投入 6-8 小时）
• 前置知识：Node.js、网络协议、监控基础

一、为什么可观测性与稳定性是架构问题？

1.1 没有监控的系统是“黑盒”

一个系统上线后，如果你不知道：

• 用户有没有报错？
• 页面加载用了多久？
• 核心功能转化率如何？
• 新版本有没有引入问题？

那你就无法判断系统是否健康，也无法持续改进。

1.2 稳定性是用户体验的底线

用户可以接受功能不完善，但很难接受：

• 页面打不开。
• 白屏。
• 点击按钮没反应。
• 数据丢失。

稳定性问题会直接影响用户信任和业务收益。

1.3 前端架构师的责任

前端架构师不仅要写代码，还要确保：

• 问题能被及时发现。
• 问题定位足够快。
• 问题影响能被控制。
• 故障后能快速恢复。

1.4 生活化比喻

可观测性像汽车的仪表盘：

• 速度表告诉你现在跑多快（实时指标）。
• 油量表告诉你还能跑多久（容量指标）。
• 故障灯告诉你哪里出问题（错误告警）。
• 行车记录仪记录发生的事（日志和追踪）。

稳定性工程则是：

• 定期保养（预防）。
• 备胎和急救包（降级和恢复）。
• 保险（故障兜底）。

---

二、可观测性三大支柱

2.1 Logs（日志）

日志是系统运行过程中记录的事件。

特点：

• 最详细。
• 适合定位具体问题。
• 数据量大，成本高。

前端日志示例：

logger.info('User clicked checkout', { userId, productId });
logger.error('Failed to load product', { error, productId });

最佳实践：

• 结构化日志（JSON 格式）。
• 包含上下文信息（用户 ID、页面、时间、版本号）。
• 分级：debug / info / warn / error / fatal。

2.2 Metrics（指标）

指标是对系统状态的量化度量，通常是时序数据。

前端常用指标：

指标	说明
PV / UV	页面访问量 / 独立访客
错误率	发生错误的请求/会话占比
页面加载时间	从请求到可交互的时间
FCP / LCP / CLS	Core Web Vitals
接口成功率	API 请求成功占比
转化率	核心业务目标完成率

2.3 Traces（追踪）

追踪记录一个请求在系统中经过的完整路径。

用户点击 → 前端路由 → API 请求 → BFF → 订单服务 → 数据库
   │          │          │         │        │         │
   └──────────┴──────────┴─────────┴────────┴─────────┘
                        一个 Trace

前端追踪：

• 页面加载链路。
• 用户操作链路。
• 错误发生链路。

2.4 三者的关系

Metrics 告诉你“有没有问题”
Logs 告诉你“问题是什么”
Traces 告诉你“问题在哪里”

---

三、前端监控体系

3.1 错误监控

错误监控的目标是及时发现并定位线上错误。

常见错误类型：

类型	说明	示例
JS 运行时错误	代码执行异常	TypeError: Cannot read property
资源加载错误	图片/脚本/CSS 加载失败	404、CDN 故障
Promise 未捕获错误	async 代码异常	unhandledrejection
接口错误	API 返回非 2xx	500、超时
白屏	页面完全没有内容	关键 JS 加载失败

常用工具：Sentry、Fundebug、Rollbar、阿里云 ARMS、腾讯云前端监控。

3.2 性能监控

性能监控关注页面加载和运行时的性能表现。

核心指标（Core Web Vitals）：

指标	名称	说明	目标值
LCP	Largest Contentful Paint	最大内容渲染时间	≤ 2.5s
FID / INP	First Input Delay / Interaction to Next Paint	首次输入延迟 / 下一次绘制交互时间	≤ 100ms / ≤ 200ms
CLS	Cumulative Layout Shift	累积布局偏移	≤ 0.1

其他重要指标：

• FCP（First Contentful Paint）
• TTFB（Time to First Byte）
• TTI（Time to Interactive）

3.3 业务埋点

业务埋点用于追踪用户行为和业务转化。

常见埋点：

• 页面浏览（PV）
• 按钮点击
• 表单提交
• 商品曝光
• 支付成功
• 功能使用频次

埋点设计原则：

• 事件命名规范统一。
• 包含 Who（用户）、When（时间）、Where（页面）、What（行为）、How（方式）。
• 避免过度埋点，关注核心指标。

3.4 用户行为分析

• 热力图：用户点击分布。
• 录屏回放：复现用户操作路径（注意隐私合规）。
• 漏斗分析：分析转化路径中的流失点。

---

四、稳定性工程

4.1 稳定性目标

稳定性工程的目标不是“零故障”，而是：

1. 降低故障发生概率。
2. 缩短故障发现时间（MTTD）。
3. 缩短故障恢复时间（MTTR）。
4. 降低故障影响范围。

4.2 SLO / SLA / Error Budget

概念	全称	说明
SLA	Service Level Agreement	服务等级协议，对用户的承诺
SLO	Service Level Objective	服务等级目标，内部目标
SLI	Service Level Indicator	服务等级指标，可量化的指标
Error Budget	错误预算	允许的不达标时间/次数

示例：

SLI：页面加载成功率
SLO：页面加载成功率 ≥ 99.9%
Error Budget：每月允许 0.1% 的失败率

4.3 稳定性设计模式

模式	说明
降级	核心服务不可用时，返回简化版本或缓存数据
熔断	下游服务异常时，快速失败，避免拖垮自身
限流	控制请求速率，防止过载
超时	设置请求超时，避免无限等待
重试	失败时按策略重试，注意幂等性
隔离	不同业务或用户隔离，避免互相影响
兜底	准备默认数据或静态页面

4.4 前端稳定性实践

• 错误边界（Error Boundary）：React/Vue 中捕获组件错误，防止白屏。
• 全局错误处理：监听 error 和 unhandledrejection。
• 资源加载失败兜底：图片加载失败显示占位图，JS 加载失败显示提示。
• 接口超时和重试：统一封装请求库。
• 灰度发布：先让少量用户试用新版本。
• 回滚机制：发现问题快速回滚到上一个版本。

---

五、告警与响应

5.1 告警设计原则

好的告警应该：

• 可操作：收到告警后知道该做什么。
• 少而精：避免告警疲劳。
• 分层：P0（立即处理）、P1（尽快处理）、P2（可以延后）。
• 带上下文：包含错误详情、影响范围、相关链接。

差的告警：

• “页面错误率上升”——没有范围、没有原因。
• 大量重复告警——导致麻木。

5.2 告警分级示例

级别	条件	响应时间	处理方式
P0	核心页面白屏率 > 1%	5 分钟	立即介入，考虑回滚
P1	接口错误率 > 5% 持续 5 分钟	30 分钟	排查并修复
P2	某非核心功能错误率上升	2 小时	安排修复
P3	性能指标轻微退化	1 天	纳入迭代优化

5.3 On-Call 与事故响应

事故响应流程：

发现 → 定位 → 止损 → 修复 → 复盘

• 发现：监控告警或用户反馈。
• 定位：通过日志、追踪、指标快速找到根因。
• 止损：回滚、降级、限流、扩容，先恢复服务。
• 修复：彻底解决问题。
• 复盘：记录原因、改进措施，防止再次发生。

5.4 事故复盘模板

# Incident Report: 2026-06-18 页面白屏

## 影响范围
- 时间：10:00 - 10:30
- 用户：约 5000 人
- 功能：首页无法访问

## 根因
- 新版本打包时 polyfill 缺失，导致低版本浏览器白屏。

## 止损措施
- 10:05 触发回滚，10:30 服务恢复。

## 改进措施
1. CI 中增加低版本浏览器兼容性测试。
2. 灰度发布覆盖更多浏览器版本。
3. 增加白屏监控告警。

## 教训
- 不要只在最新版 Chrome 测试。

---

六、最佳实践

1. 监控要覆盖全链路：从用户点击到服务端响应。
2. 先监控核心指标：不要一开始就追求大而全。
3. 错误监控要包含上下文：用户、页面、版本、设备、网络环境。
4. 性能指标要结合业务：加载快不一定转化好。
5. 告警要少而精：每条告警都要能驱动行动。
6. 建立 Error Budget：允许一定的错误率，避免过度追求 100%。
7. 稳定性设计要前置：在架构设计阶段就考虑降级、熔断、超时。
8. 定期演练故障：通过混沌工程验证系统韧性。
9. 重视复盘：每次事故都是改进的机会。
10. 保护用户隐私：埋点和日志不要收集敏感信息。

---

七、总结

可观测性与稳定性工程是前端架构师的高级能力：

• 初级：能在代码中接入错误监控和性能上报。
• 中级：能搭建完整的前端监控体系，设计告警规则。
• 高级：能制定 SLO，设计降级、熔断、限流等稳定性方案。
• 架构师：能推动组织级可观测性体系建设，建立故障响应文化。

一个好的系统，不仅要“能跑”，还要“跑得稳、看得见、恢复快”。

---

八、延伸阅读与资源

必读文章

• 🟢 Google Core Web Vitals — 前端性能指标权威指南。
• 🟢 Sentry 前端监控最佳实践
• 🟡 可观测性三大支柱 — Cindy Sridharan。

书籍

• 🟡 《Site Reliability Engineering》— Google
• 🟡 《混沌工程》
• 🔴 《Designing Data-Intensive Applications》— Martin Kleppmann

实践项目

• 在项目中接入 Sentry，配置错误监控和 Source Map。
• 使用 Web Vitals API 收集 LCP、FID/INP、CLS 指标。
• 设计一个前端灰度发布和回滚方案。
• 建立一次事故复盘会议，并输出复盘报告。

---

领域编号：A06 可观测性与稳定性工程
最后更新：2026-06-18

---

本领域学习进度

学习进度0 / 43 （0%）