Manioudakis 用 CLEAR 框架概括了有效反馈的五个特征。这套框架本来用于写 bug 报告，但结构完美适配运维场景。

Concise（精简）——最大化信号，最小化噪音

测试的反面例子："支付模块好像有点奇怪，我在结账页面点了好几次按钮，有时候就没反应，卡住了。"CLEAR 版本："结账：快速点击'购买'按钮触发竞态条件，UI 卡死。"

运维场景：告警信息尤其需要精简。一个真正有用的告警标题应该是"支付网关 /health 返回 503，持续 3 分钟"，而不是"系统出问题了"。差别在后者收到告警的人还得去查才知道发生了什么，前者直接就能判断要不要爬起来处理。

Logical（逻辑链）——复现步骤有因果顺序

测试侧用四段式结构：前置条件 → 复现步骤 → 预期结果 → 实际偏差。如果故障是间歇性的，不说"它有时候会坏"，说"只在缓存为空时（首次加载）出现"。

运维场景：故障报告最怕逻辑跳步。"中午用户反馈登录慢"跟"下午发现 Redis 连接数打满"之间缺了中间链条——是登录请求激增导致 Redis 连接数上升，还是 Redis 慢导致登录堆积？故障复盘没有完整时间线，根因分析就靠猜。

Empathetic（同理心）——把问题外化，不攻击人

测试的反面例子："这个定价逻辑完全错了，代码审查怎么过的？"CLEAR 版本："定价引擎里发现一个边界场景——老的折扣规则跟新的 VAT 规则冲突了。看起来是挺复杂的交互，我把日志附上了。"

运维场景：同样的原则。运维发现开发部署的应用吃光了连接池时，说"你的代码把连接池打满了"是钉人，说"这个版本的连接池配置可能跟当前并发量不匹配，峰值时到上限了"是钉问题。

Actionable（可行动）——拿到就能开工，不用回头问

如果对方收到你的反馈后还得再来问你"在哪看的？""什么时间发生的？""影响多大？"，那就是不够 actionable。

运维场景：告警信息里附上处理步骤是最直接的 actionable。一个好的告警模板可以包含：什么服务、什么指标异常、持续多久、建议检查什么、谁 on-call。值班的人不用翻 runbook 就知道第一步做什么。

标题: [CRITICAL] 支付网关 /health 返回 503，持续 3 分钟
服务: payment-gateway
异常指标: 健康检查连续 3 次失败
影响: 用户无法完成支付（预估 50 笔/分钟）
建议操作: 检查 Pod 状态及最近一次部署日志
值班: @on-call-payments

Relevant（相关性）——对不同人说不同话

Manioudakis 举了个例子：同一个 bug，对开发说"堆栈跟踪在这里，环境版本，变量状态"，对产品经理说"这个 bug 导致 10% 的英国用户今天无法完成购买，估计营收影响 £X"，对管理层说"这个 UI 问题让登录过程看起来不安全，可能导致流失率上升"。

运维场景：故障通告也一样。给技术团队技术细节，给业务方恢复时间，给领导影响和风险等级。一份通告发给所有人是不负责任的。