AI 告警解释模板解释要贴近值班动作一、解释不是把指标翻译成中文AI 告警解释常见问题是把 Prometheus 表达式翻译成人话比如“CPU 使用率超过阈值”。这当然没错但对值班来说帮助有限。值班更需要知道影响范围、可能原因、立即检查项和临时缓解动作。告警解释要贴近值班动作而不是只做语言美化。二、模板要包含五件事flowchart TD A[告警] -- B[发生了什么] A -- C[影响谁] A -- D[可能原因] A -- E[先查什么] A -- F[怎么缓解]每条告警解释都应该围绕这五件事组织。尤其是影响范围决定是否升级。alert_explanation: symptom: api latency p99 high impact: checkout users first_checks: - downstream_error_rate - recent_deploy - database_pool解释结构稳定值班人员才能快速扫读。三、上下文要自动补齐同一个告警在不同服务和时间段含义不同。解释模板要拉取最近变更、拓扑下游、历史相似事故、当前流量和 SLO 状态。context_sources: recent_changes: 2h service_topology: required slo_burn_rate: required past_incidents: optional没有上下文的解释容易变成通用运维百科。四、动作要安全分层AI 可以建议动作但要区分只读检查、低风险缓解和高风险变更。比如查日志、看指标是只读扩容是低风险重启核心数据库就是高风险。action_levels: readonly: - check_dashboard - query_logs mitigation: - scale_replica risky: - restart_stateful_service高风险动作必须要求人工确认甚至需要升级到负责人。最后解释模板要持续优化。每次事故复盘后把“当时真正有用的检查项”写回模板告警解释才会越来越贴近现场。解释还要匹配告警阶段。同一个延迟告警刚触发时适合提示首查项持续 30 分钟后就应该提示升级策略、影响评估和临时缓解恢复后则适合提示复盘材料。alert_stage_templates: firing_initial: first_checks firing_long: escalation_and_mitigation resolved: postmortem_summary还要把“不要做什么”写清楚。比如数据库连接数高时不要先重启数据库磁盘 IO 抖动时不要立刻清理未知文件。禁止动作能避免事故扩大。最后解释模板应该支持服务定制。支付链路、推荐链路、离线任务的首查项不同不能用一套模板打天下。解释还要引用具体数据。比如“错误率升高”后面应带当前值、基线值、开始时间和影响实例数。没有数据的解释容易像模板话术值班人员还得重新验证一遍。alert_context_values: current_error_rate: 3.2% baseline_error_rate: 0.2% started_at: 10:42 affected_instances: 12如果告警来自 SLO 燃烧率还要说明按当前速度多久会耗尽错误预算。这个信息能直接决定是否升级。五、总结AI 告警解释模板要说明症状、影响、可能原因、首查项和安全动作并自动补齐变更、拓扑和 SLO 上下文。解释要贴近值班动作。好解释不是更会说而是更能带人排障。
AI 告警解释模板：解释要贴近值班动作
AI 告警解释模板解释要贴近值班动作一、解释不是把指标翻译成中文AI 告警解释常见问题是把 Prometheus 表达式翻译成人话比如“CPU 使用率超过阈值”。这当然没错但对值班来说帮助有限。值班更需要知道影响范围、可能原因、立即检查项和临时缓解动作。告警解释要贴近值班动作而不是只做语言美化。二、模板要包含五件事flowchart TD A[告警] -- B[发生了什么] A -- C[影响谁] A -- D[可能原因] A -- E[先查什么] A -- F[怎么缓解]每条告警解释都应该围绕这五件事组织。尤其是影响范围决定是否升级。alert_explanation: symptom: api latency p99 high impact: checkout users first_checks: - downstream_error_rate - recent_deploy - database_pool解释结构稳定值班人员才能快速扫读。三、上下文要自动补齐同一个告警在不同服务和时间段含义不同。解释模板要拉取最近变更、拓扑下游、历史相似事故、当前流量和 SLO 状态。context_sources: recent_changes: 2h service_topology: required slo_burn_rate: required past_incidents: optional没有上下文的解释容易变成通用运维百科。四、动作要安全分层AI 可以建议动作但要区分只读检查、低风险缓解和高风险变更。比如查日志、看指标是只读扩容是低风险重启核心数据库就是高风险。action_levels: readonly: - check_dashboard - query_logs mitigation: - scale_replica risky: - restart_stateful_service高风险动作必须要求人工确认甚至需要升级到负责人。最后解释模板要持续优化。每次事故复盘后把“当时真正有用的检查项”写回模板告警解释才会越来越贴近现场。解释还要匹配告警阶段。同一个延迟告警刚触发时适合提示首查项持续 30 分钟后就应该提示升级策略、影响评估和临时缓解恢复后则适合提示复盘材料。alert_stage_templates: firing_initial: first_checks firing_long: escalation_and_mitigation resolved: postmortem_summary还要把“不要做什么”写清楚。比如数据库连接数高时不要先重启数据库磁盘 IO 抖动时不要立刻清理未知文件。禁止动作能避免事故扩大。最后解释模板应该支持服务定制。支付链路、推荐链路、离线任务的首查项不同不能用一套模板打天下。解释还要引用具体数据。比如“错误率升高”后面应带当前值、基线值、开始时间和影响实例数。没有数据的解释容易像模板话术值班人员还得重新验证一遍。alert_context_values: current_error_rate: 3.2% baseline_error_rate: 0.2% started_at: 10:42 affected_instances: 12如果告警来自 SLO 燃烧率还要说明按当前速度多久会耗尽错误预算。这个信息能直接决定是否升级。五、总结AI 告警解释模板要说明症状、影响、可能原因、首查项和安全动作并自动补齐变更、拓扑和 SLO 上下文。解释要贴近值班动作。好解释不是更会说而是更能带人排障。
