可观测性平台建设与组织落地：从工具堆砌到全员可用的自助观测体系

无平台的典型症状：
  - 每个团队自建 Prometheus/Loki/追踪，重复造轮子
  - 指标/日志/追踪各自为政，口径不一致
  - 数据孤岛：这个团队看不到那个团队的服务
  - 接入流程复杂：新服务要手配一大堆
  - 成本失控：N 套存储 N 套账单

本质：
  把"可观测性"当成了一次性工具采购
  而不是一项需要持续建设的平台能力

平台化 = 把可观测性沉淀为"组织级基础设施"：
  - 一套统一采集（Agent/Collector 全公司一致）
  - 一套统一存储（指标/日志/追踪集中或统一路由）
  - 一套统一入口（看板/查询/告警/权限）
  - 自助接入（团队自己接自己管，不用重复造）
  - 统一规范（埋点/命名/权限/保留）

收益：
  新服务几小时内可观测；跨团队排障无孤岛
  成本集中可见可治理；专家只建一次、全员复用

采集层目标：
  全公司一套采集方案，而不是每团队一套
   - 统一 Agent（OTel Collector）部署在每节点/每集群
   - 统一埋点（OTel SDK）与自动注入
   - 统一服务发现（新服务自动纳入采集）

落地要点：
  - 采集基础设施由平台统一管理（版本/配置/升级）
  - 边缘处理（采样/脱敏/降噪）平台统一配置
  - 各团队只需"接入标准埋点"

存储层设计：
  指标：集中式 TSDB（Thanos/Mimir/VictoriaMetrics）或联邦
  日志：集中式（Loki/ELK）
  追踪：集中式（Jaeger/Tempo）

两种模式：
  全集中：一套后端吃所有数据（简单、贵）
  统一路由：按类型/租户路由到不同后端（可扩展、省钱）

平台职责：
  - 提供统一写入入口（OTel Collector 网关）
  - 定义保留/降采样/成本策略
  - 团队不需要自己搭存储

消费层目标：
  一个入口看所有数据（Grafana 聚合多数据源）
  统一权限（谁能看什么）
  自助接入（新服务自动有看板模板）

落地：
  - Grafana 统一入口 + 多数据源插件
  - 看板模板/按服务自动生成（Golden Signals 基线）
  - 告警规则模板 + 统一告警路由
  - 文档/向导让新团队"开箱即用"

自助服务的意义：
  排障和接入不该等平台团队响应
  → 开发者自己完成"接入、查数据、配告警"

自助能力清单：
  - 新服务：打标准埋点 → 自动纳入采集 → 自动有看板
  - 查询：统一入口 + 文档 + 常用查询模板
  - 告警：模板告警 + 自助配置
  - 元数据：服务注册表自动带入 label

开发者体验（DevEx）设计：
  - 默认全自动：埋点 SDK 自动注入，零配置可观测
  - 文档即教程：快速开始 + 常用排障 SOP
  - 模板化：看板/告警/查询模板开箱即用
  - 反馈闭环：开发者提问 → 平台改进

衡量：开发者"从想观测到看到数据"的时间
  目标：分钟级，而非"提工单等两天"

平台定义统一的埋点规范：
  - 指标：统一基线（RED/黄金信号）由平台模板提供
  - 日志：结构化 + 语义约定（见日志专题）
  - 追踪：OTel 语义约定 + 自动注入
  - 命名：指标/标签/日志字段统一风格

团队自定义扩展：
  - 允许自定义业务指标，但遵循命名规范
  - 高基数/敏感字段纳入审查

治理机制：
  - 埋点评审/代码扫描（静态检查）
  - 数据质量报告（缺失必填字段/命名违规）

靠制度 vs 靠平台：
  靠平台内置：SDK 自动带规范字段（无需人记）
  靠自动化校验：CI 扫描埋点是否符合规范
  靠文档沉淀：新规范即文档即示例

目标是让"正确做法"成为默认路径，
  而非靠每个工程师自觉遵守一纸规范

可观测性平台自身也要被观测：
  - 数据丢失率：采集→存储的丢失是否可控
  - 查询延迟：看板/查询响应时间
  - 可用性：平台自身不可用影响排障
  - 告警及时性

建立平台 SLO：
  例：查询 P95 < 5s、数据完整性 > 99.5%
  让平台质量可度量、可改进

观测成本治理（Observability FinOps）：
  - 统一成本视图：各团队/各类型遥测的存储成本
  - 按价值分配：错误/慢请求高保留，随机样本短期
  - 持续优化：采样率、字段、保留期定期评估
  - 成本归属：成本回挂到团队，驱动自我节制

关键指标：
  每团队观测成本 / 每实例观测成本
  → 既防"观测不足"，也防"观测过度烧钱"

平台工程团队（可观测性平台组）：
  - 维护统一采集/存储/查询基础设施
  - 制定规范与模板，提供自助工具
  - 提供 SLO 与成本治理
  - 服务内部团队（内部客户）

各产品团队：
  - 使用平台能力，维护自己服务的埋点与看板
  - 通过自助工具接入，不重复造轮子

平台 vs 团队的分工：
  平台做"共性能力"，团队做"业务观测"
  避免平台过度包揽业务、也避免团队重复建设

阶段一：统一采集（第 1~2 月）
  部署统一 Agent/Collector，新服务强制标准接入
  统一结构化日志与 OTel 埋点

阶段二：统一入口（第 2~4 月）
  Grafana 统一数据源 + 统一权限
  看板/告警模板化，服务自动纳入

阶段三：治理与成本（第 4~6 月）
  命名/基数/保留规范落地 + 数据质量校验
  观测成本视图与优化

阶段四：自助化与扩展（持续）
  接入向导、开发者体验优化
  平台 SLO 化 + 治理闭环

注意：
  从"最有痛的场景"（如一次大事故复盘）切入
  用真实价值推动采纳，而非自上而下压指标

□ 统一采集（Agent/Collector）全公司一致
□ 统一存储与路由，统一查询/看板/告警入口
□ 标准埋点体系 + 命名规范，平台内置 + 自动校验
□ 自助接入：新服务分钟级可观测
□ 看板/告警模板化，Golden Signals 基线
□ 平台自身设 SLO（查询延迟/数据完整性）
□ 观测成本统一视图 + 按价值分配
□ 明确平台团队与业务团队分工
□ 从真实痛点切入，用价值推动采纳

可观测性平台 = 统一采集 + 统一存储 + 统一查询 + 自助接入，
一次建设、全员复用，让观测成为团队的基础设施而非负担。