可观测性
你无法修复看不见的问题。可观测性是设计内置的，而不是事后在事故发生后临时添加的。如果回答生产环境的问题需要更改代码，那么说明检测手段是错误的。
规则
- 三条支柱：日志、指标、追踪。 每一条回答不同的问题——发生了什么（日志）、多少以及多频繁（指标）、为什么慢（追踪）。你需要全部三条。
- 仅使用结构化日志。 JSON（或类似格式）优先。在大规模下，
grep不是一个可行的策略。 - 每条日志行中包含关联 ID / 追踪 ID。 在服务边界之间通过请求头传播它。一个 ID 即可缝合整个请求旅程。
- 每个端点启用 RED 指标。 速率（Rate）、错误（Errors）、持续时间（Duration，包含 P50/P95/P99）。这是发现性能回归的最小需求。
- 每个资源启用 USE 指标。 利用率（Utilization）、饱和度（Saturation）、错误（Errors）——针对 CPU、内存、连接池、队列、磁盘、网络。
- 追踪每次跨服务调用。 使用 OpenTelemetry。数据库查询和缓存命中也应作为 span 捕获。
- 基于 SLO 进行告警，而不是原始指标。 “CPU > 80%” 在凌晨三点把人叫醒毫无意义。“P99 延迟打破 SLO 持续 5 分钟” 才能抓到真正的用户痛点。
- 健康检查和就绪检查是不同端点。
/health= “我还活着，不要重启我。”/ready= “我现在可以接收流量。” 请按此对待。 - 在正确的级别记录，每个事件只记录一次。
INFO用于请求生命周期，WARN用于可恢复的问题，ERROR用于需要人为介入的事情。重复的日志会让仪表盘失真。 - 绝不记录 PII 或秘密。 在日志输出器层面进行掩码处理；不要依赖调用者记住这件事。
- 每条告警指向一个 Runbook。 没有记录操作的告警只是一个假装在呼叫值班人员的 Slack 通知。
危险信号
- 通过 SSH 进入 Pod 来调试生产环境。
- 频繁触发却被忽略的告警。（告警疲劳本身就是一个可靠性问题。）
- 日志内容为
"error occurred"，却没有任何上下文、ID 或堆栈信息。 - 仅显示平均值、没有百分位的指标。
- 按服务划分仪表盘，却没有按用户旅程划分的仪表盘。