结论先行：可观测平台上线后最常见的浪费，是所有人都打开同一个总览页。同一个故障，运维想知道哪一段异常、开发想知道改哪里、业务想知道影响了谁、管理层想判断要不要升级——四类人的问题不同，需要的粒度和时效也不同。按角色把视图分开，是让平台真正用起来的起点。
先看四类人各自最先要回答的问题
- 运维：哪一段出问题、还在不在扩散、要不要立刻处置。
- 开发：哪一次发布引入的、是哪条语句或哪一段逻辑慢、改完之后有没有变好。
- 业务：影响了哪些渠道和客户、大概多少笔、什么时候能恢复。
- 管理层：要不要升级处置、由谁负责、对外的说明怎么统一。
这四个问题指向同一组数据，但需要的呈现方式完全不同。把它们塞进一个页面，结果是每类人都要自己过滤一遍，过滤的过程就是时间成本。
同一条链路上的四种粒度
完整的链路数据可以按粒度分成四层，对应四种用法。
- 拓扑层：服务之间的依赖与流向，异常节点直接标出，用于回答「问题在哪一块」。
- 时序层：各段耗时分布与错误率随时间的变化，用于回答「什么时候开始变差、拐点在哪」。
- 代码层：具体的堆栈、慢语句、线程状态，用于回答「改哪里」。
- 业务层：受影响的服务、渠道、用户量、交易笔数，用于回答「影响多大、先处理哪个」。
实践中容易出现的偏差，是把四层混在一起用：拿平均耗时向业务解释影响，或者拿交易笔数去定位代码问题。分层之后，每一层只服务它该服务的问题。
时效不同，推送方式也不该一样
同样是告警，不同角色需要的到达方式不同。对值班与运维，需要在异常出现的当时就到达，并且带上足够的上下文，否则还要花时间去查；对业务负责人，需要的是影响面判断与处置建议，用来决定要不要通知客户；对管理层，往往是日报或周报里的趋势，以及需要决策的个别事项。
这里有一个可以事先约定的动作：故障发生后，把影响面自动评估出来的结论直接推送给对应的业务负责人，并按预设级别决定通知范围。这样一来，业务侧不必等运维查清根因才知道自己要不要介入，两边的动作可以并行而不是串行。
哪些视图要固定下来
平台上线一段时间后，视图数量会自然膨胀，最后没人知道该看哪一个。可行的做法是把视图分成两类：
- 固定视图：数量少、长期不变，包括核心业务的整体大盘、单笔链路的检索入口，以及「服务—团队—负责人」的对应关系。这三样是所有角色的公共入口。
- 按需视图：为具体场景临时搭建，用完归档，不进入日常菜单。
把服务与团队的对应关系固定下来，价值容易被低估：故障发生时，最耗时的往往不是定位技术问题，而是找到该找的人。这份对应关系平时不维护，事发时就要靠群里问。
落地前先定三件事
- 业务归属。每个服务属于哪条业务、由哪个团队负责，先对齐再接入，不要等接入完成再补。
- 指标口径。哪些指标用于对外说明、哪些只用于内部定位，口径要提前统一，避免同一件事出现两个数字。
- 通知对象与升级条件。哪一类异常通知到哪一级、什么情况下升级，写下来比口头约定可靠。
边界与前提
三点需要说明。其一，视图分层解决的是使用效率，不能替代数据质量；如果埋点缺失、链路断点较多，分出更多视图也没有意义。其二，不同角色的数据可见范围需要与企业内部的权限规则一致，涉及客户信息的字段应当按合规要求处理，不能因为「排查方便」而默认全开。其三，视图不是越多越好，超过一定数量之后维护成本会超过收益，建议按季度清理一次。深圳市奇摩计算机有限公司在企业可观测平台与运维体系建设中，通常先把业务归属与指标口径对齐，再按角色配置视图与通知规则，避免平台上线后只被少数人使用。
需要按角色梳理你的可观测视图与通知规则，欢迎 预约咨询。