U7.10.5Dashboards no one views should be retired rather than kept设计

长期无人查看的仪表盘应被下线而非保留

别名: 仪表盘生命周期 · 下线策略

概念解释

组织里的仪表盘数量只增不减:每个项目创建自己的仪表盘,项目结束后仪表盘留在系统里继续消耗计算资源、出现在搜索结果里、偶尔被新同事打开然后困惑地关掉。这些"无人查看"的仪表盘不是中性的存量——它们是活跃的负债:查询仍在跑(花钱)、指标可能已经失效但仍被展示(误导)、搜索列表越来越长(新用户更难找到有效仪表盘)。下线策略是仪表盘生命周期的终点设计,就像产品有 sunset、代码有 deprecation,仪表盘也需要有退出的路径。

机制

保留不用的仪表盘的代价分布得很分散,以至于没有人感受到它:每个仪表盘的查询成本在整体账单里可以忽略,但在组织层面累积为显著的资源消耗。更隐蔽的是信息生态的代价——当搜索"用户留存"返回 12 个仪表盘时,新用户不知道哪个是权威版本,选择成本转移给了他们,而他们没有判断依据(哪个有 owner、哪个数据还在更新、哪个口径是对的)。这种"选择过载"的效应与指标失效叠加:最容易被找到的仪表盘可能不是最新的而是 SEO 最好的(标题里关键词最多),新用户据此做出的判断建立在过期数据上。下线的阻力来自沉没成本("创建时花了精力")和不确定性("万一以后有人要用呢"),但这两个理由都不能证明持续维护的合理性——保留一个无人查看的仪表盘相当于为一个没有人访问的页面继续支付服务器费用。

边界

"无人查看"的判定需要合理的时间窗口和例外清单:90 天零查看是常用的下线候选标准,但合规要求的报表、事故复盘后等待归档的仪表盘、低频但重要的季度业务回顾应该列入保留清单而非自动下线。下线不等于删除:归档(保留配置与历史数据但不继续计算)与硬删除是不同的处理方式,前者保留了"以后可能恢复"的可能性而成本远低于持续运行。下线的流程也很重要:提前通知 owner、给一个宽限期让利益相关者申诉、下线后提供恢复入口,这些降低了下线的组织摩擦。

怎么落地

  • 建立仪表盘清单并记录每个的最近查看时间、owner、数据源状态。
  • 设定下线规则:最近 90 天无查看且无合规保留理由的仪表盘进入下线候选,通知 owner 后 14 天无申诉即归档。
  • 下线的仪表盘在搜索结果中隐藏或标注"已归档",避免新用户误用。
  • 验证:统计过去 6 个月中下线的仪表盘数量与新增数量;如果新增一直大于下线,清单在持续膨胀,策略需要更积极地执行。

延伸

  • 同组U7.10.1 自定义提高个人贴合度但削弱团队的共同参照 · U7.10.2 个人配置需与官方版本区分并可一键重置 · U7.10.3 长期固化的仪表盘会继续沿用已失效的指标 · U7.10.4 指标定义变更需通知所有复用该仪表盘的人
  • 相邻U7.10.3 长期固化的仪表盘会继续沿用已失效的指标 · U7.04.4 告警过多会训练用户忽略告警
  • 站内检索dashboard lifecycle · sunset policy · archive vs delete

同组卡片

快捷操作

分享

分享当前页面

ios_share

https://hci.top/zh/handbook/U7.10.5