告警的恢复、确认、删除操作的分别分别是什么？

# U‑Center /iMC 告警：恢复、确认、删除操作说明

>
> 适用于 H3C U‑Center5.0、iMC 平台，区分三个操作的定义、行为、后续影响。

## 1、告警恢复（手动恢复 / 清除）

**含义：标记故障已经实际消除。优先是系统自动恢复；设备上报清除事件，告警自动变为【已恢复】；收不到清除报文时，人工点手动恢复。**H3C

- 触发条件：**真实故障已经处理完毕，故障源消失**
- 行为：告警从【活动 / 未恢复】→【已恢复】；从**当前活动告警列表移到历史告警库**。
- 后续影响：
1. 不再参与首页活动告警计数，不会继续产生短信 / 邮件重复推送；
2. **完整保留这条告警全部记录：发生时间、恢复时间、告警详情，可用于故障复盘、报表统计**；
3. ⚠️**只是修改平台侧告警状态，不会下发命令修改设备配置**；
4. 如果故障实际还存在，设备再次上报告警，**会重新生成一条全新活动告警**。

>
> 注意：不要故障还存在就手动恢复，故障未解决会再次弹出告警。

## 2、告警确认

**含义：运维标记 “这条告警我已知晓，正在处理 / 已经接手”，属于协作标记，**不改变故障本身状态**。**H3C

- 触发条件：刚刚收到告警，故障还没修好，先标记有人接手处理。
- 行为：告警状态由【未确认】→【已确认】；**告警仍然留在活动告警列表，故障没消除就不会进历史库**。
- 后续影响：
1. 抑制同一条告警的重复消息推送，避免多人同时处理同一故障；
2. 记录确认人、确认时间、备注信息，多人运维分清责任人；
3. **故障没有真正修复，设备再次上报告警，仍然会更新这条告警，不会消失；可以执行反确认，退回未确认状态。**

>
> 通俗理解：确认 =“我看到这个故障了，我来处理”，不等于 “故障修好了”。

## 3、告警删除

**含义：直接把这条告警记录从数据库删掉，物理移除这条告警数据。**H3C

- 触发条件：清理无效、测试、过期告警记录。
- 行为：告警直接从页面消失，分为删除活动告警、删除历史告警。
- 后续影响：
1. 删除**未恢复的活动告警**：界面看不见告警，但**实际故障依然存在**，设备再次上报告警，平台会生成一条全新告警；
2. 删除**已恢复历史告警**：记录永久清除，**无法查询这条告警的历史，报表、故障复盘再也找不到这条记录，不可找回**；
3. ⚠️删除只是平台本地数据库操作，**不影响被监控设备，不会消除设备上真实故障**。

## 简明对比表格

表格

| 操作 | 核心含义 | 故障是否修好 | 告警记录保留 | 故障再次出现表现 |
| --- | --- | --- | --- | --- |
| **恢复（清除）** | 标记故障已消除 | ✅建议故障实际修复后执行 | ✅存入历史告警，完整保留记录 | 重新上报会生成新告警 |
| **确认** | 标记告警已被运维接手处理 | ❌故障可还未修复 | ✅保留，仍然留在活动告警列表 | 故障存在会持续更新本条告警，不会消失 |
| **删除** | 直接删掉告警这条数据记录 | 不关心故障状态 | ❌删除后记录丢失，不可找回 | 故障还存在，会生成全新告警 |

## 运维最佳实践

1. 故障排查完成，设备故障真实消除：优先等待**系统自动恢复告警**；收不到清除报文再手动【恢复】；
2. 收到告警，暂时还没修好：做【确认】，标记责任人，防止重复推送；
3. **尽量少使用【删除】**；只清理测试告警、无效垃圾告警；业务故障告警不建议删除，保留历史用于复盘；
4. ❌禁止故障还没解决，直接删除活动告警，会掩盖真实故障。

### 容易踩坑点

>
> 很多人混淆【确认】和【恢复】：
> 确认≠故障修复，只是告诉其他人 “我知道这个告警了”；
> 恢复才代表故障问题已经处理完毕。