阶段演进的判断依据
可观测性建设通常经历起步、规范化、可定位、目标化、治理五个阶段，每个阶段解决不同层次的问题：先能看到，再能对齐口径，然后能定位，最后用目标与成本约束整个体系。阶段之间不是打怪升级，而是按当前最痛的环节补课，跳过前置规范直接上工具，往往得到数据齐全但没人会用的结果。
阶段与标志
| 阶段 | 标志 | 常见任务 |
|---|---|---|
| 起步 | 主机与服务存活有告警 | 部署 exporter、统一采集与告警通道 |
| 规范化 | 服务具备统一的 RED 指标 | 埋点规范、命名约定、看板模板 |
| 可定位 | 日志与链路可关联下钻 | 结构化日志、trace_id 贯穿、日志采集 |
| 目标化 | SLO 与错误预算在运转 | SLI 定义、燃尽率告警、定期评审 |
| 治理 | 成本与数据质量受控 | 降采样、高基数清理、覆盖度盘点 |
自查四问
自查四问
1 随机挑一次历史故障：能否在 5 分钟内还原时间线？
2 随机挑一个服务：它的 SLI 与 SLO 是否有人能立刻说出来？
3 随机挑一条告警：责任人是否知道收到后先做什么？
4 随机挑一个看板：它多久没被打开，口径由谁负责？推进建议
- 从影响排障效率的环节入手，而不是先把工具采购齐全
- 先立命名与标签规范再铺采集，避免后期大规模返工改名
- SLO 建设与技术工具同步推进，告警分级才有判断依据
- 每个阶段做一次覆盖盘点，确认新上线的服务真的纳入监控
- 把成本与数据质量放进例行评审，避免建设完成后逐渐失控
成熟度看的是能力覆盖而不是工具数量：装了链路追踪但排障时没人用 trace_id 下钻，实际还停在上一个阶段。
阶段推进不必逐级等待：如果故障定位能力是当前瓶颈，可以先把日志与链路打通，再回头补 SLO 与成本治理。