结论先行：可观测平台上线后最常见的尴尬是"大屏做得很漂亮，但没人天天看"。原因通常不是数据不够，而是所有指标堆在一张图上，值班运维、开发、业务运营、管理层看到的是同一份数据，却没有谁能直接得到自己要的答案。可行做法是按角色分层：值班层看故障与影响面，开发层看自己服务的接口与依赖，业务层看体验与转化，管理层看可用性与趋势；每层指标控制在 8 个以内，并且每个指标都要绑定一个明确的响应动作。
一张大屏给所有人看，为什么行不通
- 噪音盖过信号。几十个指标同屏展示，真正异常的那一两个被淹没，值班人员只能靠经验翻找。
- 责任边界模糊。看到错误率上升，不知道该叫谁；看到资源告警，不知道该不该上报。
- 指标没有动作绑定。指标变化了没有对应的处置流程，看板最终退化为"出事后截图给领导"的材料。
- 视角单一。只有技术指标，没有业务结果，业务方不认这份数据，管理层也读不出投入产出。
四类角色的看板设计
| 角色 | 核心问题 | 建议指标 | 刷新频率 | 触发动作 |
|---|---|---|---|---|
| 值班运维 | 现在有没有事、影响多大 | 活跃告警数、接口错误率、分位耗时、依赖异常、影响服务数 | 分钟级 | 分级派单，必要时启动应急预案 |
| 开发 | 我负责的服务健不健康 | 接口耗时分位、错误率、慢 SQL 条数、下游依赖耗时、版本发布对比 | 十分钟级 | 提优化工单，纳入迭代 |
| 业务运营 | 用户有没有受影响 | 崩溃率、页面加载耗时、关键转化环节流失率、区域与渠道对比 | 小时级 | 调整运营动作、客服口径 |
| 管理层与合规 | 整体可用性与趋势 | 核心交易可用性、故障次数与平均修复时长、趋势对比、审计留存完备性 | 日或周 | 复盘立项、追加投入 |
四层之间有两条硬性要求：底层指标必须能从上层下钻，看到异常能一键跳到对应调用链；上层的口径要与下层的采集口径一致，避免出现"两个看板两个数字"的信任危机。
分层落地的五个步骤
- 定义角色与责任人。先确认组织里有哪几类用数角色，每类指定一名看板负责人，负责指标取舍与季度回顾。
- 每类角色不超过 8 个指标。指标数量与使用率通常成反比，超过 8 个之后，被真正使用的往往只剩前三个。
- 指标绑定动作。每个指标都要写清"异常时谁处置、多久响应、响应方式是什么"，没有动作的指标应当被删掉。
- 设定权限与分享范围。业务层看板可以按业务域授权，管理层看板按经营口径开放，避免跨部门看到不该看的明细。
- 建立季度清理机制。每季度回顾一次：哪些指标没人看、哪些指标已经失真、哪些新指标要加进来。
容易踩的四个坑
- 指标越多越好。堆到几十个指标后，看板变成仪表盘展览，反而没人能快速判断。
- 只有技术视角。没有转化、体验、可用性这类业务语言，业务方不会参与，项目价值也难以向上表达。
- 看板不能下钻。看到曲线异常却点不进调用链，值班人员还是要切到别的平台，一体化价值就没了。
- 看板与告警脱节。看板好看但没有对应告警规则，异常只能靠人盯着，等于把监测退回人工值守。
一个可复用的检查项
看板上线后可以用三句话自测：值班人员能不能在两分钟内判断"有没有事、影响多大、该叫谁"；开发人员能不能在看板上直接跳到自己服务的慢调用；管理层能不能从一张图读出本季度比上季度好在哪里。三句话里有一句答不上来，说明分层还没做到位。奇摩在为金融与政企客户搭建可观测体系时，通常把看板分层与告警分级一起设计——先定谁看什么，再定什么情况下叫醒谁。
如果您正在规划可观测看板或想重构现有大屏，欢迎 预约咨询，我们可以基于您的组织结构给出分层模板与指标口径建议。