U7.04.5Alerts must point to the executable next step, not just report the value设计
告警需指向可执行的下一步而非只报告数值
别名: 可行动告警 · 告警动作
概念解释
"错误率 2.1%，超过阈值 0.5%"这样的告警只完成了一半：它报告了事实，没回答"然后呢"。可行动的告警要同时携带三个要素：发生了什么（指标与越界幅度）、影响多大（波及范围或业务换算）、下一步去哪（深链到相关面板、值班文档或处置手册）。缺了第三要素，每条告警都逼接收者从零开始诊断——这是告警疲劳的另一半来源。
机制
下一步指向之所以重要，是因为告警的处理成本大头不在"知道"而在"定位"：接收者从收到告警到开始处置之间的间隔，几乎全部花在"打开哪个系统、看哪个面板、按哪本手册"的寻路上。深链把这些寻路动作前置到告警生成时——告警规则的定义者知道该指标异常时该看哪里，这个知识应该被固化进规则，而不是要求每个接收者重新学习。行动指向还天然充当告警的质检器：写不出下一步的告警规则，多半意味着"这个异常没人知道该怎么处理"，它要么缺处置文档（运营缺口），要么不该作为告警存在（观测缺口），两者都应反馈回规则治理。
边界
下一步指向要避免过度自动化：自动执行处置动作（自动重启、自动回滚）属于另一个决策层级，告警携带的应是"查看与处置的入口"而非"已代为处置"——除非处置动作本身经过充分的自动化审计。指向的目标也会腐化：面板改名、手册迁移后深链失效，深链目标需要纳入链接巡检。指向的粒度按接收者分层：值班工程师要的是仪表盘深链，管理者要的是影响摘要与升级路径，同一告警的两个视图都应预置。
怎么落地
- 告警消息固定三段：现象（指标、当前值、阈值）、影响（波及面或业务换算）、入口（面板深链、手册链接、认领按钮）。
- 新建告警规则时"下一步入口"为必填项，填不出即回到"是否该告警"的评审。
- 验证：抽十条近期告警，跟踪接收者从收到到开始处置的路径；若普遍需要自行寻路，补深链后复测处理时长。