4、四大黄金信号之错误：错误率计算、错误类型分类、错误码与业务错误区分
错误（Error）是黄金信号中直接反映服务健康状态的核心指标。与延迟或流量不同，错误信号具有明确的“好坏”分界线：任何非预期的错误都意味着服务能力降级或功能失效。本节将深入解析错误率的精确计算方法、错误类型的分类体系，以及如何区分技术错误码与业务错误，从而构建可指导服务画像动态更新的错误信号模型。
4.1 错误率计算：从原始计数到有效信号
错误率并非简单的“错误请求数/总请求数”，在微服务架构中，需要根据不同的观测粒度选择计算口径。以下是三种最常用的错误率计算方式：
| 计算口径 | 公式 | 适用场景 | 注意事项 |
|---|---|---|---|
| 请求级错误率 | HTTP 5xx 响应数 / 总请求数 | 网关、入口代理、对外API | 忽略4xx客户端错误，仅关注服务端故障 |
| 调用链错误率 | 包含错误Span的Trace数 / 总Trace数 | 内部服务间调用、异步消息 | 需定义“错误Span”标准（如状态码≥400或异常标记） |
| 业务错误率 | 业务逻辑失败数 / 总业务操作数 | 订单、支付、风控等核心业务 | 需与HTTP状态码解耦，单独定义业务错误码 |
实践建议：在SLO定义中，推荐同时监控“请求级错误率”和“业务错误率”。前者用于基础设施告警，后者用于业务健康度评估。两者结合才能完整反映服务的真实错误状态。
4.2 错误类型分类：结构化错误分层模型
为了驱动服务画像的动态更新，错误必须被分类并赋予优先级。下图展示了一个四层错误分类模型，从最底层的系统错误到最上层的业务错误，每一层对应不同的响应策略和画像更新权重。
4.3 错误码与业务错误：关键区分
在微服务可观测性实践中，最常见的误区是将HTTP状态码直接等同于业务错误。实际上，两者在语义、粒度和处理方式上存在本质差异。下表清晰展示了它们的区别：
| 对比维度 | HTTP错误码（技术错误） | 业务错误码（业务错误） |
|---|---|---|
| 语义范围 | 传输协议层，表示请求/响应的传输状态 | 应用层，表示业务逻辑的执行结果 |
| 典型值 | 200, 400, 401, 403, 404, 500, 502, 503 | ORDER_OUT_OF_STOCK, PAYMENT_INSUFFICIENT_BALANCE |
| 粒度 | 粗粒度，一个状态码对应一类传输问题 | 细粒度，每个业务场景可定义独立错误码 |
| 是否影响SLO | 是，5xx直接计入错误预算 | 视情况而定，需单独定义业务SLO |
| 处理策略 | 触发重试、熔断、降级 | 触发补偿事务、人工审核、业务告警 |
| 示例场景 | 请求超时返回504，网关直接熔断 | 下单时库存不足，返回BUSINESS_STOCK_LACK，前端提示用户 |
常见陷阱：不要将业务错误包装为HTTP 200返回。这种做法会污染错误率计算，导致监控系统认为服务健康，而实际业务已经大面积失败。正确的做法是：HTTP状态码反映传输状态，业务错误码在响应体中携带，两者独立记录。
4.4 错误信号驱动服务画像更新流程
当错误信号被采集并分类后，需要将其映射到服务画像的更新动作中。下图展示了从错误发生到画像更新的完整闭环流程：
4.5 错误信号在服务画像中的动态更新规则
基于上述分类和流程，我们可以定义具体的画像更新规则。以下是一个示例规则表，展示了不同错误类型如何影响服务画像的各个维度：
| 错误类型 | 影响画像维度 | 更新动作 | 恢复条件 |
|---|---|---|---|
| 系统错误（如OOM） | 健康状态、弹性策略 | 标记为“不健康”，触发自动扩缩容 | 连续5分钟错误率为0 |
| 服务错误（如5xx激增） | 负载保护、熔断阈值 | 降低熔断阈值，启动限流 | 错误率低于1%持续10分钟 |
| 应用错误（如参数校验失败） | 版本质量、发布策略 | 标记版本为“有风险”，暂停灰度 | 新版本修复后重新评估 |
| 业务错误（如库存不足） | 业务容量、依赖健康 | 更新依赖服务容量画像，触发预警 | 依赖服务恢复后自动清除 |
核心结论：错误信号是服务画像中最敏感的输入之一。通过精确的错误率计算、结构化的错误分类、以及错误码与业务错误的清晰区分，我们可以构建一个既能快速响应故障、又能避免噪声干扰的动态画像更新机制。这是实现服务自治和弹性伸缩的基础能力。