可观测性与埋点

问题：看不见的系统没法运维

线上出故障时，如果你只能靠用户反馈和猜测还原现场，那不叫排障，叫考古。没有随功能一起写进代码的遥测数据，事后永远补不回来——用户上报的第一个 bug 就变成了挖掘工作，而不是一次查询。可观测性指的是从外部、基于代码产生的遥测数据（指标、日志、追踪）回答“系统正在做什么、为什么这么做”。埋点不是上线前的补丁，它应当像测试一样，与功能同步编写。

这个技能如何工作

核心原则是：没有疑问的遥测就是噪声。技能要求你先澄清问题，再动手埋点：

1. 先定义“正常工作”：在添加任何 instrumentation 之前，写下 2–4 个值班工程师一定会问的问题。如果说不出问题，就还没准备好埋点——否则你会记录一切，却什么也学不到。
2. 为每个问题挑对信号：把问题映射到指标、日志或追踪上，权衡每种信号能回答什么、采集与存储成本有多高。
3. 覆盖典型场景：任何要进生产的功能、新的服务、端点、后台任务或外部集成；告警规则的设置与评审；涉及 I/O、重试、队列或跨服务调用的 PR 审查。

适用边界

• 不用于诊断正在发生的故障，那交给 debugging-and-error-recovery；可观测性的作用是让下一次诊断更快。
• 不用于性能剖析和已测出的慢点优化，请用 performance-optimization。
• 不用于上线当天的监控清单与回滚触发条件，那是 shipping-and-launch 的范畴；本技能只提供喂给这些清单的埋点。