可观测性方案从演示到验证的落差
用模拟告警演示聚类、降噪或根因建议，只能说明最小链路可运行。生产环境的时间序列会有扩缩容、发布、缺失数据、乱序事件和多种故障叠加；模型在演示样本上给出的结论，不能直接视为可上线的告警策略。
验证应从明确的问题开始：系统要减少哪些重复通知，不能遗漏哪些关键事件，建议允许多大延迟，人工如何复核。将规则告警和模型建议分别记录，才能看清是模型改进了噪声，还是碰巧遇到更平稳的流量窗口。
用受控实验建立数据集
Kind 或隔离测试集群适合重复运行部分故障场景，但它不等同于生产。故障注入需有范围、持续时间、恢复步骤和观察指标，并避免对共享环境产生影响。网络延迟、依赖超时、应用错误、资源饱和和数据缺失等场景应分别记录；同时保留没有故障的正常窗口，防止算法把正常变化当作异常。
评估标签不能只靠一次人工判断。对于“根因”，应允许未知或多个候选原因；对告警，至少计算事件是否被发现、通知是否重复、首个通知延迟和误报的人工处理成本。Precision、recall 等指标需要说明样本集、类别定义和阈值，单个固定门槛不适合作为所有服务的发布条件。
def compare_alerts(expected: set[str], emitted: set[str]) -> dict[str, int]: return { "true_positive": len(expected & emitted), "false_positive": len(emitted - expected), "false_negative": len(expected - emitted), }这个比较只适合标签已经明确且同一时间窗口内可对齐的场景。真实告警还要处理分组、抑制、重复、延迟和严重级别，不能用字符串包含关系判断“找到了根因”。
为关键告警保留独立路径
节点不可达、存储接近耗尽、证书过期等高影响信号，应由经验证的确定性规则直接通知，不依赖模型是否返回结论。模型可以帮助聚合相关告警、补充可能的排查路径，但不应拦截关键通知或自动执行修复。
每次修改模型、检索语料、聚类窗口或标签映射后，在固定回归集上重新评估，并在小范围真实流量中观察。记录版本、输入来源、模型输出和人工修订，发现退化时可以回到已知稳定版本。对模型无法判断的情况，界面应明确显示不确定性，而不是输出看似肯定的根因。
从演示到生产，最重要的变化是把“模型回答得像不像”改成“它是否在限定边界内帮助人更早发现问题，并且不会压制原有的可靠告警”。
发布记录还应保留回退条件和人工联系人。出现异常时先关闭模型建议或切回稳定配置，而不是同时修改规则、数据源和基础设施；恢复后再对照实验数据确认是否由新方案引起。这样的运行边界能让验证结果真正服务于下一次发布。
所有结论都应能追溯到原始样本与明确的评审记录。
并保留失败案例。
