2. 报警数据模型设计：报警事件的数据结构
好，咱们接着聊报警数据模型。说白了，这就是给报警事件画个「身份证」。你想想看，风场里几百台风机，每天产生成千上万条报警，如果没有统一的数据结构，那排查问题就像大海捞针。
我个人习惯，在设计报警数据结构时，会把它拆成七个核心字段。这七个字段，缺一个都不行。我在项目中遇到过，有同事为了省事，把「部件ID」和「风电机组ID」合并成一个字段，结果后来查问题，根本分不清是哪个风机、哪个部件出的问题，那叫一个乱。
2.1 核心字段详解
咱们一个一个来看。每个字段都有它的设计初衷，也有它的坑。
| 字段名 | 类型 | 说明 | 示例 |
|---|---|---|---|
| 事件ID | 字符串/UUID | 全局唯一标识 | ALM-20240515-001234 |
| 时间戳 | datetime | 事件发生时间 | 2024-05-15 14:23:18.456 |
| 风电机组ID | 字符串 | 风机唯一编号 | WTG-012 |
| 部件ID | 字符串 | 具体部件编码 | GB-01 (齿轮箱一级) |
| 严重级别 | 枚举 | 1-5级 | 3 (警告) |
| 状态 | 枚举 | 当前处理状态 | 已确认 |
| 描述 | 文本 | 详细说明 | 齿轮箱油温超过85°C |
2.2 事件ID的设计哲学
事件ID，我建议用「前缀+日期+序列号」的格式。为什么？因为可读性强。你看到 ALM-20240515-001234，一眼就知道这是2024年5月15日发生的第1234条报警。
我曾经见过有人直接用自增整数做主键，结果系统迁移时ID全乱了。嗯，这里要注意：事件ID必须全局唯一，不能依赖数据库自增。我推荐用雪花算法或者UUID，但UUID太长了，查询效率低。我个人习惯用雪花算法，生成的是64位整数，存成字符串也就19位，够用。
核心原则：事件ID一旦生成，终身不变。哪怕这条报警后来被撤销、被合并，它的ID也不能变。这是审计追溯的基础。
2.3 时间戳的精度之争
时间戳，这个坑最多。你想想看，风机的PLC采集周期是100毫秒，但SCADA系统上报可能有延迟。如果时间戳精度只到秒，那同一秒内发生的多条报警，你根本分不清先后顺序。
我建议用毫秒级时间戳，最好带时区信息。为什么？因为风场可能跨时区，你总不想半夜被叫起来，结果发现是时区换算错了。
小技巧：时间戳统一用UTC存储，展示时再转本地时间。这样不管风机在新疆还是海南，数据都是对齐的。
2.4 严重级别的分级标准
严重级别，我把它分成5级。这个分级标准，是我在多个项目里打磨出来的。
- 信息：日常状态变化，比如风机启动、停机。不需要处理，但需要记录。
- 提示：参数轻微越限，比如温度比正常值高了5度。可以观察，但不用立刻处理。
- 警告：参数明显异常，比如振动值达到报警阈值。需要关注，安排巡检。
- 严重：设备可能损坏，比如齿轮箱油压骤降。需要立即处理，远程停机。
- 紧急：人身安全或重大设备损坏风险，比如火灾报警。必须立刻响应，全员通知。
说白了，1级和2级是「看看就行」，3级是「该干活了」，4级和5级是「别睡了，快起来」。我在项目中遇到过，有人把3级和4级混在一起，结果运维人员对报警麻木了，真正出大事时反而没人重视。所以分级一定要清晰，不能模糊。
2.5 状态机的流转设计
状态字段，我设计了一个简单的状态机。报警事件不是一成不变的，它会经历「产生→确认→处理→恢复→关闭」这几个阶段。
注意：状态流转必须是单向的，不能回退。比如「已恢复」的报警不能再次变成「已确认」。我曾经见过一个系统，状态可以随意跳转，结果运维人员把「已关闭」的报警又改成「处理中」，审计时根本说不清楚。
我建议的状态枚举：
- 0-未确认：报警刚产生，还没人看过
- 1-已确认：运维人员已查看，但还没处理
- 2-处理中：正在排查或维修
- 3-已恢复：报警条件消失，设备恢复正常
- 4-已关闭：确认问题已解决，归档
2.6 知识体系结构图
下面这张图，是我梳理的报警数据模型核心逻辑。你看一眼，就能明白这七个字段是怎么配合的。
2.7 代码示例：报警事件的数据结构定义
光说不练假把式。我给出一个Python的数据结构定义，你拿去就能用。这个结构我在三个风场项目里验证过，稳定运行了两年多。
from dataclasses import dataclass
from datetime import datetime
from enum import IntEnum
from typing import Optional
class SeverityLevel(IntEnum):
"""严重级别枚举"""
INFO = 1 # 信息
HINT = 2 # 提示
WARNING = 3 # 警告
CRITICAL = 4 # 严重
EMERGENCY = 5 # 紧急
class AlarmStatus(IntEnum):
"""报警状态枚举"""
UNCONFIRMED = 0 # 未确认
CONFIRMED = 1 # 已确认
PROCESSING = 2 # 处理中
RECOVERED = 3 # 已恢复
CLOSED = 4 # 已关闭
@dataclass
class AlarmEvent:
"""报警事件数据结构"""
event_id: str # 事件ID，格式：ALM-YYYYMMDD-序列号
timestamp: datetime # 时间戳，UTC时间，毫秒精度
turbine_id: str # 风电机组ID
component_id: str # 部件ID
severity: SeverityLevel # 严重级别
status: AlarmStatus # 当前状态
description: str # 描述信息
source: Optional[str] = None # 数据来源（可选）
def __post_init__(self):
"""初始化后的校验"""
if not self.event_id.startswith("ALM-"):
raise ValueError("事件ID格式不正确，必须以ALM-开头")
if self.severity not in SeverityLevel.__members__.values():
raise ValueError(f"无效的严重级别: {self.severity}")
if self.status not in AlarmStatus.__members__.values():
raise ValueError(f"无效的状态值: {self.status}")
# 使用示例
alarm = AlarmEvent(
event_id="ALM-20240515-001234",
timestamp=datetime.utcnow(),
turbine_id="WTG-012",
component_id="GB-01",
severity=SeverityLevel.WARNING,
status=AlarmStatus.UNCONFIRMED,
description="齿轮箱油温超过85°C，当前值87.3°C"
)
print(f"报警已创建: {alarm.event_id}")经验之谈：代码里的 __post_init__ 方法，是我后来加的。为什么？因为有一次数据导入时，有人把严重级别填成了6，系统没报错，结果报警一直没触发。从那以后，我所有数据模型都加校验，宁可慢一点，也不能错。
2.8 避坑指南
最后，我总结几个常见的坑，你遇到了可以少走弯路。
- 字段冗余不是坏事：有人觉得「风电机组ID」和「部件ID」可以合并，千万别。查询时按风机过滤和按部件过滤，是两个完全不同的场景。
- 时间戳别用字符串：我见过有人用字符串存时间，结果排序时按字典序排，2024-01-01 排在了 2023-12-31 前面。用datetime类型，数据库层面就支持排序。
- 描述字段别太短：描述至少要能容纳200个汉字。为什么？因为报警原因可能很复杂，比如「齿轮箱高速轴轴承温度异常，同时伴有振动值升高，建议检查润滑油路」。你写个「温度高」，运维人员根本不知道从哪查起。
嗯，报警数据模型这块，说白了就是「把话说清楚」。每个字段都有它的使命，设计时多想一步，后面能省十步。我当年第一次做报警系统时，就是吃了字段设计不全的亏，后来重构了三次才稳定下来。你按我上面说的来，至少能少踩一半的坑。