平台工程中的可观测性需求：平台团队视角、开发者体验、SRE目标对齐
做平台工程可观测性，最容易踩的坑就是——只从一个角度看问题。我刚开始带团队时，使劲往监控里堆指标，结果开发者说“看不懂”，SRE说“不够用”，平台团队自己维护成本还爆了。后来才明白，可观测性不是造个数据湖就完事，它得同时服务好三类人：平台团队自己、用平台的开发者、背SLO的SRE。这三者的需求有时重叠，有时冲突，你得找到那个平衡点。
平台团队视角：我要能运维，更要能优化
作为平台团队的工程师，我们最关心两件事：平台本身的健康状况和资源的投入产出比。说白了，你搭建了APM、日志、指标平台，自己得先吃得消。我见过一个团队把所有微服务全量采集trace，一天几十TB数据，查询慢得吐血，成本直接爆预算——这就是典型“只建不管”。
我个人习惯把平台可观测性分为三层：
- 基础设施层：K8s集群、中间件、网络延迟、磁盘IO。这些是平台基座，挂了啥都白搭。
- 平台服务层：开发者用到的服务注册、配置中心、CI/CD流水线。这些直接影响开发者体验。
- 成本与容量层：每接入一个团队，存储、计算、带宽成本是多少？能不能按租户分摊？
开发者体验：我要一秒搞清楚“我的代码为什么挂了”
开发者最烦什么？写代码5分钟，排查BUG两小时。如果可观测性工具不能帮他们快速定位到代码级别，那就是废的。我记得有一次，团队上线了一个新特性，接口延迟从10ms变成500ms，开发者翻遍了Grafana仪表盘，全是K8s节点CPU，跟代码半毛钱关系没有——这就是视角错位。
从开发者角度看，可观测性要满足三个“直觉”：
- 一键跳转：从告警消息直接点到具体调用链，再到日志行，层级少于3次点击。
- 上下文聚合：一次请求的trace、日志、metrics、错误堆栈自动关联，不用手动拼。
- 反馈闭环：代码合并后，能自动看到新版本的延迟、错误率变化，不用等SRE通知
我曾经把OpenTelemetry agent配置成全量采样，结果每个请求都往collector发大量span，开发者本地调试时把自己环境打挂了。后来改用“头采样+尾采样”策略：线上只保留错误trace，成功trace按1%采样，开发者主动调试时可以临时开全量。
SRE目标对齐：别把SLO当摆设
SRE嘴里天天挂的“SLO、SLI、错误预算”，可观测性不跟这些对齐，那就真是数据孤岛了。我见过最离谱的事：SRE定了一个99.9%的SLO，但告警阈值设在了99.99%，导致天天报警，开发者直接标记为“不重要”——这叫资源浪费。
真正可行的做法：
- SLI定义要精确：比如“请求延迟P99 < 200ms”，而不是“响应性能达标”。
- 错误预算可视化：每个服务都有一个烧钱进度条，开发者能看到还剩多少预算可用。
- 告警与SLO联动：错误预算剩余<10%才Page级别告警，平时只发Warning。
下面给一个常见的SLI定义示例，用YAML配合Prometheus rule：
groups:
- name: sli-rules
rules:
- record: sli:request_latency_p99_5m
expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
- alert: SLOViolation
expr: sli:request_latency_p99_5m > 0.2
for: 5m
labels:
severity: page
annotations:
summary: "{{ $labels.service }} 延迟SLO已被违反"
三个视角如何统一？
你可能已经发现了，平台团队看资源，开发者看代码，SRE看SLO。这三者不是矛盾的，而是三个侧面。下面这张图概括了它们的关系：
这张图想表达的是：平台团队提供基础设施可观测性，开发者关注应用级的trace和log，SRE盯服务级的SLO。三股数据流统一汇聚到统一可观测性策略里，最后服务于同一个目标——让平台可靠、让开发高效、让SRE省心。
说实话，很多团队一开始就急着上工具，先把自己觉得重要的数据全采进来，结果三个视角互相打架。我建议你反过来：先想清楚你的用户（开发者）、你的客户（SRE）、你的老板（平台成本）各自需要什么，然后分层设计。下一层解决一层的问题，不要指望一个仪表盘解决所有问题。