Quality Architecture / Tutorial 21

日志、监控与可观测性测试教程

系统能够恢复还不够。你还需要验证团队能否及时发现、准确定位，并用同一条证据链解释用户的订单发生了什么。

9 个章节Logs + Metrics + Trace告警 + SLO + 证据链

把可观测性也当成产品来测试

看见不等于看懂

从现象到结论的观察路径

用户反馈支付后订单未更新

指标发现支付成功率下降

Trace定位回调消费超时

日志确认幂等更新失败

业务对账扣款一次、订单待补偿

测试目标

异常发生后能在目标时间内被发现。
能从告警定位到服务、接口、版本和业务对象。
日志、指标与 Trace 表达同一事实，不相互矛盾。
敏感数据不进入日志，采样不会漏掉关键失败。
恢复后告警关闭，业务数据完成对账。

用四类信号回答不同问题

技术信号连接业务

可观测信号分工

信号	回答的问题	商城关键字段
日志 Logs	这一次请求发生了什么	orderNo、traceId、错误码、重试次数
指标 Metrics	问题影响有多大、持续多久	成功率、P99、消息积压、资源饱和度
链路 Trace	时间花在哪个服务、哪次调用失败	订单→库存→支付→消息的 Span
业务事件	技术异常是否改变业务结果	重复扣款、超卖、退款超时

只有 CPU 和错误日志，无法证明用户有没有被重复扣款。技术指标必须与订单成功率、支付金额、库存差异等业务指标共同使用。

验证日志可搜索、可关联且不泄密

结构化日志

推荐的结构化错误日志

{
  "level": "error",
  "event": "payment_callback_failed",
  "trace_id": "tr-82a1",
  "order_no": "TEST-20260809-001",
  "payment_no": "PAY-001",
  "error_code": "DB_TIMEOUT",
  "retry_count": 2,
  "duration_ms": 812
}

用例：当支付回调写库超时时，日志应支持直接定位

用测试支付单触发一次可控写库超时。
按 orderNo 搜索，确认能找到失败事件和 traceId。
检查错误码、依赖、耗时、重试次数和版本字段。
确认没有密码、Token、完整卡号或个人敏感信息。
恢复后确认成功或补偿事件也被记录。

日志反例

问题	后果	改进
只写“处理失败”	无法定位对象与原因	结构化错误码 + 业务 ID
打印完整请求体	泄露隐私或密钥	字段白名单与脱敏
每次重试都打印大堆栈	噪声和成本失控	首次详情 + 聚合计数
各服务时间不一致	时间线无法拼接	统一时区与时钟同步

验证 Metrics 的定义与计算

数字必须可信

商城核心指标

指标	计算口径	测试方法
下单成功率	成功订单 / 有效下单请求	构造成功、业务拒绝、系统失败，核对分母
支付回调错误率	失败回调 / 全部回调	注入已知数量失败并核对标签
P99 延迟	99% 请求不超过的耗时	固定样本分布校验聚合结果
消息积压	生产位点 - 消费位点	暂停消费后应增长，恢复后应下降
库存差异数	缓存或订单占用与 DB 事实差异	制造测试差异并验证指标出现

Metrics 测试步骤

先写指标名称、单位、标签、分子和分母。
用最小可计算样本产生确定结果。
核对采集、聚合、看板展示与时间窗口。
测试重启、跨实例和标签缺失场景。
限制高基数标签：orderNo 应留在日志或 Trace，不应直接成为 Metrics 标签。

沿 Trace 找到慢点与断点

跨服务还原请求

从现象到结论的观察路径

POST /ordersroot span

库存预占inventory span

支付创建payment span

事件发布mq span

退款补偿async linked span

用例：当库存调用超时时，Trace 应显示完整因果关系

入口 Span 带 traceId、版本和测试环境。
父子关系、服务名、操作名和耗时正确。
超时 Span 标记错误且记录标准化错误码。
重试是独立 Span，次数和退避可见。
异步消息传递 trace context，退款补偿可关联原订单。

采样策略也要测试。P0 失败、慢请求和支付异常应强制保留；如果只做 1% 随机采样，最重要的低频事故可能恰好没有 Trace。

让告警准确、及时并可行动

从触发到恢复

告警测试矩阵

用例标题	期望
当下单错误率连续 5 分钟超过 2% 时，应触发高优先级告警	阈值、持续窗口、通知对象和看板链接正确
当一分钟出现单个瞬时错误时，不应反复告警	去抖、聚合和静默策略生效
当支付出现重复扣款信号时，应立即告警	业务红线不等待普通窗口
当指标恢复并持续稳定时，告警应自动恢复	恢复通知包含持续时间与峰值
当值班人未确认时，应按升级策略通知下一负责人	升级链路可验证

告警消息最少包含

发生了什么、从何时开始、影响什么业务。
当前值、阈值、趋势和受影响版本。
关联看板、日志查询、Trace 示例和 Runbook。
告警级别、负责人、升级与恢复条件。

用 SLI、SLO、SLA 统一质量语言

目标、承诺与误差预算

SLI

实际测量指标，例如有效下单成功率、支付确认延迟。

SLO

内部目标，例如 30 天内 99.9% 有效下单成功。

SLA

对外承诺及违约责任，通常不等同于内部 SLO。

可计算定义

good_events = valid_orders with result in {CREATED, BUSINESS_REJECTED}
valid_events = all orders - client_cancelled - load_test_traffic
availability_sli = good_events / valid_events
error_budget = 1 - 0.999

用例：当错误预算快速燃烧时，应触发多窗口告警

用受控流量制造短时高错误率和长时轻微错误率。
验证快窗口能发现事故，慢窗口能发现持续退化。
确认测试流量和用户主动取消不会污染 SLI。
检查预算耗尽时发布门禁是否按策略收紧。

构建线上问题证据链

从用户现象到业务结论

支付异常证据时间线

10:01

错误率告警

10:02

用户支付成功

10:02:01

订单写库超时

10:08

补偿完成

失败报告模板

incident evidence

用户现象: 10:02 支付成功但订单仍待支付
业务对象: order_no=... payment_no=...
指标: 10:01 起 callback_error_rate > 3%
Trace: payment callback -> order DB timeout 812ms
日志: DB_TIMEOUT, retry_count=3, compensation_id=...
数据结论: 渠道扣款 1 次；订单 10:08 补偿为 PAID
行动: 修复连接池配置；补充告警与回归用例

“服务抖了一下”不是证据。可复盘的结论必须说明时间、版本、影响、业务对象、技术原因、数据最终状态和采取的行动。

验证一次支付故障的可观测性

练习与检查清单

练习

为下单、支付和退款各定义一个业务 SLI。
注入一次支付回调超时，验证日志字段、Metrics 数值和 Trace 父子关系。
验证告警触发、通知、升级和恢复全流程。
按 orderNo 串联页面时间、指标、日志、Trace 和数据库状态。
输出证据链报告，并提出一项监控或可测性改进。

信号可信

口径可计算
日志已脱敏
Trace 可串联
业务指标齐全

告警可用

阈值已验证
噪声受控
Runbook 可达
恢复可确认

结论可追溯

版本环境明确
业务 ID 齐全
时间线一致
改进项有负责人