【摘要】
一个厂的报警系统上线三个月后，操作员把它关了。原因很朴素：一天 1,800 条报警，其中 1,600 条是同一个真空报警的重复上报，剩下 200 条里有一半是"设了又清、清了又设"的抖动。
报警系统的失败模式高度一致：把三类语义完全不同的报警塞进一个池子，用一个优先级字段，配一条只有"红黄蓝"的规则。技术从来不是瓶颈，建模才是。
这篇给三样东西：ALID 字典的必备字段、按影响面与紧迫性的四级分级、超时自动升级的路径设计，以及治理报警洪水的三招。
【核心要点】
- 三类报警必须分池：设备报警（ALID）、统计报警（SPC/OOC）、业务规则报警（Q-time/滞留/WIP 异常）
- ALID 字典七字段必备，缺一个就会出现"Unknown Alarm"占满屏幕
- 分级不用设备自带的严重度，用「影响面 × 紧迫性」两维打分
- 升级路径的核心不是"通知谁"，是超时未处置自动升级，且升级不解除原责任
- 报警洪水三招：去重（时间窗合并）、抑制（父子关系）、掩码（必须带时限和审批）
- 闭环看三个时长：Set→Ack、Ack→Clear、Set→Clear（MTTA / MTTR），不看条数
---
一、三类报警，别塞一个池子
这是最容易犯、后果最重的错误。三类报警的语义、责任人、处置动作完全不同：
| 类型 | 来源 | 例子 | 责任人 | 处置动作 |
|---|---|---|---|---|
| 设备报警 | 设备 ALID（S5F1/S5F2） | 真空压力超限、 heater 断线、门未关 | 设备工程师 | 到机台、复归、消警 |
| 统计报警 | SPC / FDC / 量测 | 控制图连续 9 点同侧、膜厚偏移 | 工艺工程师 | 查数据、判定、调整 recipe |
| 业务规则报警 | MES 规则引擎 | Q-time 剩 25%、批滞留 8 小时、Hold 超 24 小时未处置 | 生产/计划 | 改派、协调、放行 |
塞一个池子的后果：操作员看到一个列表，混着"设备要停机"和"这批该催了"，他无法判断哪个该先动；统计报警被设备报警淹没，工艺工程师干脆不看系统、直接去翻自己的 SPC 报表；三个月后所有人退回微信群通报。
落地要求：三张表、三个处理队列、三个责任人路由。界面上可以做统一入口，但数据结构必须分开。合并显示是 UI 的事，合并存储是设计的罪。
二、ALID 字典：七个字段缺一不可
设备报警落地时最常踩的坑是：ALID 只有编号，没有语义。屏幕上显示"报警 4021"，操作员去问设备工程师，设备工程师去翻设备手册——一次处置 20 分钟，其中 15 分钟在查这是什么。
ALID 字典必须有七个字段：
| 字段 | 说明 | 缺失后果 |
|---|---|---|
| ALID | 设备侧报警码 | — |
| 设备型号 | 同一 ALID 在不同机型含义不同，必须按机型分别建 | 误报处置 |
| 中英文描述 | 一句话说清"哪里出了什么问题" | 查手册 |
| 严重度 | 设备厂给的等级（Stop / Warning / Info） | 无分级依据 |
| 分类 | 真空/温控/传动/气体/安全/通信 | 无法统计与抑制 |
| 建议动作 | 三条以内的处置步骤 | 处置靠人经验 |
| 关联 Hold 策略 | 是否自动 Hold 批、Hold 哪一类 | 批带病流转 |
第二条最关键：ALID 不是全局唯一的，是「机型 + ALID」唯一。同一个 4021 在刻蚀机上是"腔体压力异常"，在炉管上可能是"传送带卡料"。用一张全局字典，一定错。
字典建设期要做一次实测对账：让设备工程师从设备面板导出全部 ALID，和 EAP 侧实际收到的 ALID 做差集。差集里通常有两类：设备配了但没上报的（通信配置漏项）、上报了但字典里没有的（显示 Unknown）。这两类的数量，直接反映对接质量。
三、分级：影响面 × 紧迫性
别用设备自带的严重度做分级。设备厂的 Stop 级，可能只是这一个腔体停了，另一腔体照跑；而某个 Warning 级的温度偏移，可能正在毁掉整批片。设备只知道自己，不知道产线。
用两维打分：
| 紧迫性高（分钟级） | 紧迫性中（小时级） | 紧迫性低（班次级） | |
|---|---|---|---|
| 影响面大（整机/整批/安全） | P1 | P2 | P3 |
| 影响面中（单腔体/单片） | P2 | P3 | P4 |
| 影响面小（辅助系统/提示） | P3 | P4 | P4 |
四级对应动作要写死：
- P1：5 分钟内响应，自动 Hold 相关批，同时通知设备 + 工艺 + 值班经理；不进"待办列表"，直接弹出并要求 Ack。
- P2：30 分钟内响应，通知设备工程师，超时升级到组长。
- P3：当班内处置，进队列，班末未处理进交接单。
- P4：只记录，进日报，不打扰任何人。
一个厂 P1 报警的数量应该是个位数每天。如果 P1 一天几十条，说明分级没做，只是把设备严重度换了个名字——这时候所有人都会开始忽略 P1，分级体系就废了。
四、升级路径：超时才升级，升级不转移责任
升级路径设计有三条铁律：
1. 按时间升级，不按人升级。"P1 报警 10 分钟未 Ack → 通知值班经理"，这个规则写在配置表里，不写在流程文件里。流程文件没人执行，配置表会真的发消息。
2. 升级不解除原责任人。这条最容易被设计错。报警升级到经理后，原设备工程师的任务不能消失——升级是"加一双眼睛"，不是"换一个人"。否则所有人学会的策略就是拖，拖到升级，责任自然转移。
3. 升级链要有终点，也要有兜底。典型三级：值班工程师 → 设备/工艺组长 → 值班经理。再往上呢？到值班经理就该有一个明确动作：接受风险继续生产（留痕）、停线、或者升级到厂级。不允许"挂着不管"——挂着不管的报警是下一次事故的伏笔。
配套两个机制：
- Ack 不等于处置。Ack 只是"我看到了"。真正的闭环是 Clear + 处置记录。只统计 Ack 率的厂，Ack 率能到 99%，实际处置率可能只有 60%。
- 交接班检查。每个班次结束，未 Clear 的 P1/P2 报警自动进交接单，接班人要签字确认。这是防"报警过夜"最有效的一招。
五、报警洪水：去重、抑制、掩码
1,800 条/天的报警，实际独立事件可能只有 120 个。三个手段按顺序上：
去重（时间窗合并）：同一设备、同一 ALID，在 N 分钟窗口内重复 Set，合并为一条，计数 +1。窗口长度按报警类型配：抖动型（传感器噪声）30 分钟，状态型（门未关）5 分钟。阈值要可调，不写死。
抑制（父子关系）：一串报警往往有因果。真空泵故障 → 压力异常 → 传送超时 → 批滞留，四条报警一个根因。做法是建抑制表：父报警激活期间，子报警不推送（仍记录，标 suppressed）。抑制关系不要靠猜，让设备工程师在调试期标注——他们对因果链最清楚，一周能标完主要机型。
掩码（Mask）：已知问题、等备件、待改造的报警，允许临时屏蔽。但掩码必须带三样：时限（默认 7 天，到期自动解除并提醒）、审批人、原因。没有时限的掩码就是永久静音，我见过一个厂屏蔽了 47 个 ALID，改造完没人解，两年后查出来时已经不记得为什么屏的。
三个手段的效果要量化跟踪：去重率、抑制率、掩码数量。掩码数量持续上升是危险信号——说明问题在积累而不是在解决。
六、闭环看时长，不看条数
报警系统的 KPI 不要用"处理了多少条"。条数可以通过拆分报警刷上去，毫无意义。看三个时长：
| 指标 | 定义 | 健康区间（参考） |
|---|---|---|
| MTTA | Set → Ack 平均时长 | P1 < 5 min，P2 < 30 min |
| MTTR | Ack → Clear 平均时长 | 按报警分类分别看，均值会被长尾污染，看 P90 |
| 有效率 | 需要实际处置的报警 / 总报警 | > 60%，低于 40% 说明噪声太多 |
再加一个容易被忽略的：重复报警率。同一设备同一 ALID，7 天内 Set 超过 5 次，就是"治不好"的信号，应该生成一条工程改进项，而不是继续让操作员 Ack。报警系统的终极目标不是"报警被处理"，是"报警变少"。
七、可复用点
- 三类报警分池存储：设备 ALID / 统计 OOC / 业务规则，三个队列三个责任人。
- ALID 字典按「机型 + ALID」唯一，七字段必备；建设期做设备面板与 EAP 实收的差集对账。
- 分级用「影响面 × 紧迫性」，P1 每天个位数；P1 泛滥等于没有分级。
- 升级按超时触发，配置化；升级不解除原责任人；升级链终点必须有明确动作。
- 洪水治理三招顺序：去重 → 抑制 → 掩码；掩码必须带时限与审批。
- KPI 看 MTTA / MTTR(P90) / 有效率 / 重复报警率，不看条数。
下一篇讲 SPC 子系统落地：控制图选型与数据前置条件——SPC 项目做不起来，八成不是统计方法选错，是数据根本不具备做控制图的条件。
判断口诀：报警不是通知，是工单的前置；一条没人处置的报警，比没有报警更危险。