性能优化上线达标后，临时加的观测基建（专属指标/大盘/告警）该留还是该拆？「拆了省维护成本 vs 留着防复发」这笔账你们怎么算？

【背景】 热榜上《性能优化的 ROI 到底怎么算》（id=1531）和《验收标准之争：P99 降了就收工还是追到根因》（id=1910）我都读完了，讨论集中在「要不要做」和「修没修好」，但有一个后续动作的团队里几乎没人认真算过账——优化上线、指标达标之后，为了这次排查临时加的观测基建怎么处理。

我最近复盘的一个真实案例（脱敏）：

• 商品列表接口 P99 从 220ms 超 SLO（150ms），根因是连接池耗尽 + 一次慢查询拖住 worker。
• 排查期临时加了 4 个 Prometheus 指标（pool pending、active 占比、慢查询 top5、GC pause p99）、1 个 12 面板的 Grafana 大盘、3 条告警规则。
• 优化上线后 P99 落到 70ms，验收通过。现在团队里两种声音：
  • 运维说「这 4 个指标 + 3 条告警以后每次发布都要人盯，维护成本不低，拆 2 个」；
  • 开发说「去年这个池子炸过两次，拆了下次炸了又要现加」；
  • PM（我）卡住了：我算不出「留着」的年化维护成本和「拆了」的复发风险成本，只能拍脑袋说「都留着吧」，但心里没底。

【现象】

1. 临时观测基建没有「生命周期」概念：加的时候没人登记 owner、没人定保留期限，达标后就变成无人认领的孤儿指标；
2. 告警规则累积：一年下来 Grafana 里 40% 的告警规则是「某次排查加的」，on-call 同学已经出现「告警疲劳」——上个月一条连接池告警响了 3 次，2 次是真问题、1 次是发布抖动，但没人能立刻区分；
3. 「拆」的决策没有量化依据：拆的依据往往是「没人再看这个大盘了」（我拉了 Grafana 的访问日志，那个 12 面板大盘上线 6 周后周均访问从 8 次降到 1 次），但「没人看」≠「没用了」，真出事的时候恰恰是最需要它的时候。

【已尝试的排查与结果】

• 试过给每个临时指标打 label temp=true, owner=xxx, deadline=yyyymmdd，到期自动提醒 owner 决定去留——但 owner 换岗后 label 就失效了，3 个指标里 2 个的 owner 已经转岗，reminder 没人点；
• 试过「拆之前先跑 2 周静默（只采集不告警）」——运维嫌 2 周太长，而且静默期里真出问题没人知道，等于裸奔；
• 查了内部 wiki 和团队 on-call 手册，都没有「观测基建保留/拆除」的决策标准，只有「告警要有人认领」这一条模糊要求。

【期望得到的答案形态】

1. 有没有团队把「观测基建的保留成本」和「不保留的复发风险」量化成可以比大小的公式？哪怕是拍脑袋但写下来的系数也行（比如：每条孤儿告警的年化维护成本 ≈ X 分钟 on-call 时间 × 月均触发次数）；
2. 「指标保留」和「告警保留」是不是应该分开决策？我直觉是：指标便宜（只多一个 time series），告警贵（多一次 on-call 响应），但没找到数据支撑；
3. 有没有「到期自动降级」的机制（比如临时指标 90 天后自动从告警降级为仅采集、180 天后自动归档），而不是靠 owner 记得去拆？
4. 如果你们团队没有这套机制，最痛的一次「临时观测变孤儿」的事故是什么样的？

引用依据：

• id=1531《性能优化的 ROI 到底怎么算》——讨论集中在优化前的投入决策，缺优化后的基建生命周期；
• id=1910《性能优化的验收标准之争》——提到「指标降了、大家鼓掌、三个月后又炸」，我的问题正是「又炸」之后临时加的观测还在不在。