Jev通信告警分诊（演示）

通信网络的一次故障，为什么会冒出一屏告警？ 主干光纤中断后，下游设备可能同时报错；机房停电后，多座基站又会接连进入电池供电。Jev 通信告警分诊演示展示一种处理方式：程序先整理拓扑、读数、历史和变更记录，决策层再对告警作有限判断，最后由明确的规则决定操作员看到的队列。 视频为英文界面的无声演示。开场明确说明：Jev 的回答是预先编排的，优先级底线、规则和计时器在演示中实际运行。它适合用来理解工作流程，不代表已经接通真实通信网络或完成模型效果测试。 五种场景 - 主干光纤中断： 根据拓扑归并同一原因引发的下游告警，同时保留医院、银行等关键业务的最低优先级。关联告警仍可追溯，附近但无关的告警不会仅因位置接近就合并。 - 九座基站掉电： 结合电池剩余时间安排处理顺序；电量不足或未及时确认时，由程序提高优先级。视频使用加速的模拟时钟展示升级过程。 - 夜间变更窗口： 计划内的重启和链路变化进入摘要，范围外的异常和窗口结束后仍未恢复的站点单独提醒。 - 紧急呼叫异常： 在模拟的紧急呼叫成功率为 91% 时，故意注入“routine，0.72”的错误回答，展示代码如何通过降级条件与优先级底线阻止不当降级；未确认的事件随后由计时器升级。 - Jev 不可用： 回退到设备厂商给出的原始严重级别，继续保留告警，展示没有模型回答时的处理路径。 决策模型负责哪一步？ 界面将判断拆成六个问题：严重程度、处理团队、是否符合历史模式、是否与已有事件同因、能否等待，以及影响范围。程序负责事实整理、阈值计算、允许降级的条件、关键业务底线、定时升级和审计记录。 这段视频中的模型回答、延迟和 token 数都是演示数据，不能用于评价真实 Jev 的准确率、响应时间或成本。它也没有证明告警减少后仍能达到真实网络的漏报、误报和响应要求；这些需要用实际事件、人工标签和现网流程另行验证。