网站可观测性：定义、价值与核心概念

本文为企业技术决策者解析网站可观测性的定义、与监控的区别、业务价值，以及SLO、SLI、错误预算和三大支柱等核心概念，并提供实践指导。

什么是网站可观测性？

网站可观测性（Observability）是一种通过分析系统外部输出（如日志、指标和追踪）来推断其内部状态的能力。它不仅仅是收集数据，更是让团队能够回答“为什么系统会处于当前状态”这一问题的工程实践。对于企业网站而言，可观测性覆盖了从用户浏览器到后端基础设施的完整链路，包括前端性能、API 响应、数据库查询、CDN 分发以及第三方服务调用等环节。

### 可观测性与监控的区别

可调整示例假设：监控（Monitoring）和可观测性经常被混用，但两者有本质区别。监控侧重于对已知故障的告警，例如当服务器 CPU 使用率超过 90% 时触发警报。它依赖于预先定义的规则和阈值，适合处理已知的、可预期的问题。而可观测性则着眼于发现未知问题——那些你尚未意识到可能发生的故障。

它通过保留丰富的上下文数据，让团队在问题发生时能够灵活地探索和定位根因，而不是仅仅依赖预设的告警。

一个形象的比喻是：监控告诉你“系统出错了”，而可观测性告诉你“为什么出错”。例如，监控可能检测到网站错误率上升，但可观测性能够通过追踪数据发现是某个微服务的数据库连接池耗尽导致的，并进一步定位到具体的代码变更。

### 企业网站的可观测性范围

企业网站通常不是一个单体应用，而是由多个组件构成的复杂系统。因此，网站可观测性需要覆盖以下三个层面：

– **前端性能**：包括页面加载时间、交互响应时间、JavaScript 错误率等。这些指标直接影响用户体验，也是用户最先感知问题的环节。
– **后端 API 与基础设施**：涉及服务器响应时间、API 错误率、数据库查询性能、网络延迟等。这些是支撑网站功能的核心。
– **用户体验**：不仅仅是技术指标，还包括用户是否能够成功完成任务，例如注册、下单或搜索。这通常通过真实用户监控（RUM）来采集。

只有将这三个层面的数据关联起来，才能形成对网站状态的完整视图。例如，当用户报告页面加载缓慢时，可观测性工具可以帮助你判断是前端资源过大、CDN 节点故障，还是后端 API 响应延迟。

为什么企业网站需要可观测性？

企业网站往往是业务的关键入口，承载着品牌展示、产品销售、客户服务等重要功能。一旦网站出现性能下降或宕机，不仅会造成直接的经济损失，还可能损害品牌信誉。因此，可观测性对于企业网站而言，不是可选项，而是保障业务连续性的必要手段。

### 业务影响与故障复杂性

现代企业网站依赖多个服务，例如 CDN、API 网关、微服务、数据库和第三方支付接口。任何一个环节出现问题，都可能导致网站整体不可用。然而，故障的定位却异常复杂。例如，一个用户报告“无法登录”，可能的原因包括：前端代码错误、认证服务超时、数据库连接失败，甚至是网络防火墙配置错误。如果没有可观测性，团队只能依靠猜测和手动排查，平均修复时间（MTTR）会大大延长。

可观测性通过提供端到端的追踪和关联数据，帮助团队快速缩小故障范围，找到根因。例如，通过追踪一个登录请求的完整路径，可以清晰地看到它在哪个服务上耗时最长或返回错误，从而迅速定位问题。

### 减少 MTTR 与提升稳定性

可观测性的核心价值之一是减少平均修复时间（MTTR）。当故障发生时，团队能够快速获取所需信息，而不是在多个工具之间切换、手动拼凑线索。例如，当告警触发时，可观测性平台可以自动关联相关的日志、指标和追踪，展示一个“故障现场”视图，让工程师立即开始分析。

此外，可观测性还能帮助团队在故障发生前发现潜在风险。例如，通过分析错误预算的消耗趋势，团队可以预测是否即将违反 SLO，从而提前采取措施，如扩容或优化代码。这种主动的稳定性管理，远比被动响应故障更有效。

核心概念：SLO、SLI与错误预算

在实施可观测性时，SLO、SLI 和错误预算是三个必须理解的核心概念。它们为团队提供了量化服务质量和指导决策的框架。

### SLI：服务级别指标

SLI（Service Level Indicator）是衡量服务质量的具体量化指标。它必须是可以测量的，并且与用户体验直接相关。常见的 SLI 包括：

– **可用性**：例如，请求成功返回的百分比。
可调整示例假设：- **延迟**：例如，95% 的请求在 200 毫秒内完成。
– **错误率**：例如，请求返回 5xx 错误的百分比。

选择 SLI 时，应聚焦于用户可感知的维度。例如，对于电商网站，支付成功率可能比页面加载时间更重要。

### SLO：服务级别目标

可调整示例假设：SLO（Service Level Objective）是 SLI 的目标值，它定义了团队承诺的服务水平。例如，“可用性为 99.9%”或“95% 的请求延迟低于 300 毫秒”。SLO 必须是明确的、可衡量的，并且与业务目标对齐。

设定 SLO 时，需要平衡用户体验和成本。过于严苛的 SLO 可能导致高昂的运维成本，而过于宽松的 SLO 则可能损害用户信任。通常，SLO 会设定为一个略低于理想值的数字，以留出一定的容错空间。

### 错误预算：平衡创新与稳定

可调整示例假设：错误预算（Error Budget）是 SLO 的衍生概念，它表示在 SLO 允许的范围内，系统可以失败的时间或次数。例如，如果 SLO 是 99.9% 可用性，那么错误预算就是每月 0.1% 的不可用时间，约 43 分钟。

错误预算的核心价值在于，它为团队提供了一个决策框架：只要错误预算充足，团队就可以放心地部署新功能；当错误预算耗尽时，团队应暂停创新，优先修复稳定性问题。这避免了“为了创新而牺牲稳定性”或“为了稳定而停滞不前”的极端情况。

### 实际应用示例

假设一个企业网站的用户登录服务，团队设定了以下目标：

– **SLI**：登录请求的成功率。
可调整示例假设：- **SLO**：月度可用性 99.9%。
– **错误预算**：每月允许的失败请求数（基于总请求量计算）。

可调整示例假设：当错误预算消耗超过 50% 时，团队会收到预警；当消耗达到 100% 时，团队会冻结新功能发布，集中精力修复问题。

可观测性的三大支柱：日志、指标与追踪

日志、指标和追踪被称为可观测性的三大支柱。它们各自提供不同维度的数据，只有结合使用，才能构建完整的可观测性体系。

### 日志：记录离散事件

日志（Logs）是系统在运行过程中产生的、带有时间戳的文本记录。它们记录了离散的事件，例如用户请求、错误堆栈、系统警告等。日志是故障排查的基础，能够提供详细的上下文信息。

在企业网站中，日志通常包括：

– **访问日志**：记录每个 HTTP 请求的详细信息，如 IP、URL、状态码、响应时间。
– **应用日志**：记录业务逻辑中的关键事件，如用户登录、订单创建。
– **错误日志**：记录异常和错误堆栈，用于定位代码问题。

日志管理的关键在于结构化。使用 JSON 等格式记录日志，可以方便地搜索和过滤。同时，应避免记录敏感信息，如密码或身份证号。

### 指标：聚合数据视图

指标（Metrics）是系统状态的数值表示，通常以时间序列的形式存储。它们提供聚合数据，例如请求量、错误率、CPU 使用率等。指标的优势在于存储成本低、查询速度快，适合用于告警和趋势分析。

常见的网站指标包括：

– **RED 方法**：Rate（请求速率）、Errors（错误数）、Duration（持续时间）。
– **USE 方法**：Utilization（利用率）、Saturation（饱和度）、Errors（错误数），用于基础设施监控。

指标通常通过拉取或推送的方式采集，并使用 Prometheus、Graphite 等工具存储和可视化。

### 追踪：分布式请求路径

追踪（Traces）记录了请求在分布式系统中的完整路径。它通过为每个请求分配一个唯一的追踪 ID，并跨服务传递，从而将不同服务产生的跨度（Span）关联起来。追踪能够展示请求在每个服务上的耗时、调用顺序和错误信息。

对于企业网站，追踪尤其重要，因为一个用户请求可能涉及多个微服务。例如，一个“查看商品详情”的请求可能需要调用商品服务、库存服务和推荐服务。追踪可以帮助你看到哪个服务是瓶颈，或者哪个服务返回了错误。

### 三大支柱的协同工作

三大支柱并非孤立存在，而是相互补充。例如：

– 当指标显示错误率上升时，你可以通过日志查看具体的错误信息。
– 当日志显示某个请求超时时，你可以通过追踪查看它在哪个服务上耗时最长。
– 当追踪发现某个服务响应缓慢时，你可以通过该服务的指标（如 CPU 使用率）进一步分析原因。

现代可观测性平台通常会将三者集成，提供从指标到日志、再到追踪的“一键跳转”能力，从而加速故障排查。

### 实践建议

在实施三大支柱时，建议从以下步骤开始：

1. **统一日志格式**：确保所有服务使用相同的日志格式，并包含请求 ID 等关联字段。
2. **定义关键指标**：根据业务目标，确定需要监控的核心指标，并设置合理的告警阈值。
3. **引入分布式追踪**：在服务间传递追踪上下文，并逐步增加对关键链路的追踪覆盖。

通过三大支柱的协同，团队能够快速定位问题，缩短 MTTR，并持续优化系统性能。

建立用户旅程SLO

以下是一个可用的 SLO 模板，您可以根据自己的业务场景填写：

**使用说明**：
– **用户旅程名称**：描述用户完成的一个关键任务，如“用户登录”。
– **SLI 指标**：选择可量化的指标，如成功率、延迟。
可调整示例假设：- **SLO 目标值**：设定一个可接受的目标值，通常为 99% 以上。
– **错误预算**：根据 SLO 计算允许的失败时间或次数。
– **告警阈值**：设定一个提前预警的阈值，避免直接违反 SLO。
– **责任人**：指定负责该 SLO 的团队或个人。

您可以根据此模板，为您的网站定义首个 SLO，并逐步完善可观测性体系。

告警阈值与责任人设置

在实施网站可观测性时，第一步不是选择工具，而是明确业务目标。对于企业网站而言，用户旅程（User Journey）是连接技术与业务的桥梁。一个用户旅程是指用户为完成特定业务目标而执行的一系列操作，例如登录、搜索、结账或内容浏览。每个旅程都对应着关键业务价值，因此需要为其定义服务级别目标（SLO）。

### 识别关键用户旅程

首先，列出网站的核心业务功能。通常，这些功能与收入、用户留存或品牌体验直接相关。例如，电商网站的“结账”旅程、SaaS平台的“登录”旅程、内容网站的“搜索”旅程。识别过程应邀请业务、产品和技术团队共同参与，确保覆盖高价值和高频场景。避免将每个页面或API都视为独立旅程，而应聚焦于端到端的用户操作序列。

### 定义服务级别指标（SLI）

每个用户旅程需要可量化的SLI。SLI是衡量用户体验的具体指标，例如：
– 页面加载时间：从用户发起请求到页面完全渲染的时间。
– API成功率：旅程中关键API调用成功的百分比。
– 错误率：旅程中发生错误（如HTTP 5xx）的比例。
– 响应时间：后端服务对关键请求的响应时长。

选择SLI时，应确保其能真实反映用户感知。例如，对于“结账”旅程，支付API的成功率比首页加载时间更重要。同时，SLI应可测量且与业务结果相关。

### 设定SLO目标

可调整示例假设：SLO是团队期望达到的服务水平，通常以百分比表示，例如“结账旅程的API成功率在30天内达到99.9%”。设定SLO时，需考虑业务优先级和技术可行性。高优先级旅程（如支付）可设定更严格的目标，而低优先级旅程（如帮助中心）可适当放宽。SLO应基于历史数据和用户期望，避免过于激进导致频繁告警，或过于宽松失去意义。

### 错误预算的引入

可调整示例假设：错误预算 = 100% – SLO。它表示在特定周期内允许的服务不可用时间。例如，99.9%的SLO意味着每月最多43分钟的不可用时间。错误预算将技术指标转化为业务语言，帮助团队在创新与稳定性之间做出权衡。当错误预算耗尽时，应暂停新功能发布，优先修复稳定性问题。

为每个用户旅程创建SLO文档，记录SLI、目标值、错误预算和负责人。定期审查SLO，确保其与业务变化同步。例如，当网站推出新功能时，可能需要调整现有旅程的SLO或新增旅程。

事故时间线与复盘

告警是可观测性体系中的关键环节，但设计不当会导致告警疲劳或漏报。有效的告警策略应基于SLO和错误预算，而非简单的静态阈值。

### 基于SLO的告警阈值

告警阈值应与SLO和错误预算挂钩。例如，当错误预算消耗速度超过预期时触发告警。常见方法包括：
可调整示例假设：- 基于消耗率：设置错误预算消耗率的阈值，如“在1小时内消耗超过10%的错误预算”。
– 基于剩余量：当错误预算剩余低于20%时告警。
可调整示例假设：- 基于趋势：使用预测算法，预测错误预算将在未来24小时内耗尽时告警。

可调整示例假设：避免为每个指标设置固定阈值（如CPU使用率超过80%），因为这类告警往往与用户体验无关，且容易产生噪音。

### 避免告警疲劳

告警疲劳是指团队因收到过多无效告警而忽视重要告警。为减少疲劳，应：
– 合并相关告警：将同一用户旅程的多个指标合并为一个综合告警。
– 设置告警级别：区分紧急（立即处理）和警告（工作时间处理）。
– 定期审查告警规则：删除无效规则，调整阈值。

### 明确责任人与升级路径

可调整示例假设：每个告警必须指定一个明确的责任人（on-call）。责任人负责响应告警并启动处理流程。同时，定义升级路径：当责任人无法在限定时间内解决时，应升级至更高级别的团队或经理。例如，一线支持在15分钟内未响应，则升级至二线工程师。

### 可调阈值变量

告警阈值不应一成不变。考虑不同时段和流量模式，例如：
– 高峰时段（如促销活动）可临时放宽阈值，避免误报。
– 低峰时段可收紧阈值，以便及时发现潜在问题。
– 使用动态阈值，基于历史数据自动调整。

为每个告警规则记录其对应的SLO、责任人和升级路径。定期进行告警演练，确保团队熟悉响应流程。同时，将告警与工单系统集成，确保问题可追踪。

实施可观测性的最佳实践

即使有完善的SLO和告警，事故仍可能发生。事故时间线和复盘是改进系统韧性的关键。

### 事故时间线记录

事故时间线是从检测到解决的完整事件记录。它应包括：
– 检测时间：告警触发或用户报告的时间。
– 响应时间：责任人开始处理的时间。
– 缓解时间：采取临时措施恢复服务的时间。
– 解决时间：根本原因被修复并确认的时间。

记录每个关键操作及其时间戳，例如“10:00 告警触发，10:05 责任人确认，10:15 回滚版本，10:30 服务恢复”。时间线有助于分析响应效率。

### 复盘（Postmortem）的目的

复盘旨在改进流程而非追责。它应回答：
– 发生了什么？
– 为什么发生？
– 我们如何防止再次发生？

复盘会议应邀请所有相关方，包括开发、运维、业务。会议中应避免指责，而是关注系统缺陷和流程漏洞。产出物是行动项，例如“增加自动化测试覆盖支付流程”或“优化告警阈值”。

### 关联发布版本

将事故数据与发布版本关联，可以识别变更影响。例如，如果事故发生在版本v2.3发布后，应检查该版本的变更是否引入了问题。使用版本控制工具和部署记录，建立时间线关联。

建立事故复盘模板，记录时间线、影响范围、根本原因和行动项。定期审查事故趋势，识别重复问题。将复盘结果纳入知识库，供团队参考。

实施可观测性并非一蹴而就，需要系统化方法。以下最佳实践可帮助企业避免常见陷阱。

### 从业务目标出发

首先定义SLO，再选择工具。许多企业先购买监控工具，再试图定义指标，导致工具与业务脱节。正确顺序是：明确关键用户旅程和SLO，然后选择能测量这些SLI的工具。

### 统一日志格式和指标命名

日志和指标是三大支柱中的两个。统一格式和命名规范，便于关联分析。例如，所有日志使用JSON格式，包含时间戳、服务名、用户ID等字段。指标命名遵循一致模式，如`http.request.duration`。这有助于在事故期间快速关联不同数据源。

### 定期审查SLO和告警

SLO和告警不是静态的。随着业务发展，用户旅程可能变化，SLO需要调整。定期（如每季度）审查SLO和告警规则，确保其与业务同步。同时，根据事故复盘结果优化告警阈值。

### 工具选择与集成

选择可观测性工具时，考虑其与现有技术栈的兼容性、数据采集能力、可视化效果和成本。优先选择支持日志、指标、追踪一体化的平台，以减少集成复杂度。确保工具支持自定义仪表盘和告警。

### 团队协作与文化

可观测性不仅是技术问题，更是文化问题。培养团队的可观测性思维，鼓励主动监控和快速响应。建立跨职能团队，包括开发、运维、SRE和业务，共同负责SLO。

### 持续改进

可观测性体系需要持续改进。定期评估SLO达成率，分析错误预算消耗，调整告警策略。将事故复盘行动项纳入迭代计划，确保改进落地。

### 所需工件：SLO模板

为帮助您开始，我们提供以下SLO模板。请为每个关键用户旅程填写此模板，以建立可观测性基线。

请根据您的业务场景调整字段。此模板可作为团队讨论的基础，确保每个旅程都有明确的目标和负责人。

下一步

下载SLO模板并开始为您的网站定义首个SLO。