2. 台账数据模型设计:事故台账核心字段定义、状态机设计、数据生命周期管理
事故台账的数据模型是跨系统同步的基石。一个设计不良的模型会导致字段歧义、状态丢失、同步冲突,最终使台账沦为“数据孤岛”。本节从核心字段、状态机、生命周期三个维度,构建一套可跨系统复用的标准化数据模型。
2.1 事故台账核心字段定义
核心字段分为标识字段、时间字段、分类字段、责任字段、内容字段和同步字段六大类。下表列出每个字段的跨系统同步要求:
| 字段类别 | 字段名称 | 数据类型 | 同步要求 | 示例值 |
|---|---|---|---|---|
| 标识字段 | incident_id | UUID v4 | 全局唯一,源系统生成后不可变 | a1b2c3d4-e5f6-7890-abcd-ef1234567890 |
| 标识字段 | source_system | VARCHAR(32) | 记录首次创建的系统名称 | ServiceNow |
| 时间字段 | detected_at | TIMESTAMP | 统一使用 UTC,精度到毫秒 | 2025-03-21T14:30:00.123Z |
| 时间字段 | resolved_at | TIMESTAMP | 可为 NULL,仅当状态为 Resolved 时填充 | 2025-03-21T16:45:00.000Z |
| 分类字段 | severity | ENUM | P1/P2/P3/P4,跨系统枚举值一致 | P1 |
| 分类字段 | category | VARCHAR(64) | 使用统一分类树,避免自由文本 | 网络-核心交换机 |
| 责任字段 | assignee | VARCHAR(64) | 同步用户唯一标识(邮箱或工号) | zhang.san@company.com |
| 责任字段 | team | VARCHAR(64) | 使用团队编码,避免中文别名 | SRE-Network |
| 内容字段 | title | VARCHAR(256) | 纯文本,禁止 HTML 标签 | 核心交换机 BGP 会话中断 |
| 内容字段 | description | TEXT | 支持 Markdown 格式,同步时保留原始 | **影响范围**:所有办公网络... |
| 同步字段 | sync_version | INT | 乐观锁,每次更新递增 | 3 |
| 同步字段 | last_synced_at | TIMESTAMP | 记录最后同步时间,用于冲突检测 | 2025-03-21T17:00:00.000Z |
设计要点:标识字段使用 UUID v4 而非自增 ID,避免跨系统主键冲突。同步字段
sync_version 是解决“后写入覆盖”问题的关键,每次更新前必须校验版本号。
2.2 状态机设计
事故台账的状态机必须覆盖从发现到关闭的完整路径,同时支持回退和挂起。下图展示标准五态状态机及其合法转换:
状态转换规则:
- New → Investigating:确认事故真实,开始排查。
- Investigating → Mitigating:找到根因,进入缓解措施阶段。
- Mitigating → Resolved:业务恢复,监控确认无异常。
- Resolved → Closed:完成事后复盘,生成报告。
- 回退规则:Investigating 和 Mitigating 可回退到上一状态,但 Resolved 不可回退。
2.3 数据生命周期管理
事故台账数据从创建到归档,经历活跃期、观察期、归档期三个阶段。每个阶段对应不同的存储策略和同步频率。
2.4 数据生命周期策略表
下表汇总三个阶段的关键参数,用于指导跨系统同步的调度配置:
| 生命周期阶段 | 触发条件 | 存储介质 | 同步频率 | 数据保留 | 清理策略 |
|---|---|---|---|---|---|
| 活跃期 | 事故创建 | SSD 热存储 | 实时(≤5s) | 状态变为 Resolved 为止 | 无 |
| 观察期 | Resolved 状态 | SSD 热存储 | 准实时(≤60s) | 7 天 | 到期自动进入归档 |
| 归档期 | Closed 状态 | 冷存储 / S3 | 每日批量(T+1) | ≥1 年 | 超过保留期后自动删除 |
常见陷阱:
- 状态机缺少回退路径:很多系统只设计正向流转,导致 Investigating 阶段发现误判时无法回退到 New,只能新建事故,造成数据冗余。
- 生命周期与状态机脱节:归档任务仅依赖时间而非状态,导致 Resolved 但未 Closed 的事故被提前归档,影响事后复盘。
- 同步字段缺失:没有
sync_version和last_synced_at,跨系统更新时无法检测冲突,容易发生数据覆盖。
2.5 数据模型 JSON Schema 示例
以下是一个符合上述设计的事故台账 JSON Schema 片段,可直接用于 API 契约或消息队列的 payload 定义:
{
"$schema": "http://json-schema.org/draft-07/schema#",
"title": "IncidentRecord",
"type": "object",
"required": ["incident_id", "source_system", "detected_at", "severity", "status"],
"properties": {
"incident_id": {
"type": "string",
"pattern": "^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"
},
"source_system": {
"type": "string",
"enum": ["ServiceNow", "PagerDuty", "Opsgenie", "Zabbix", "CustomPortal"]
},
"detected_at": {
"type": "string",
"format": "date-time"
},
"resolved_at": {
"type": ["string", "null"],
"format": "date-time"
},
"severity": {
"type": "string",
"enum": ["P1", "P2", "P3", "P4"]
},
"status": {
"type": "string",
"enum": ["New", "Investigating", "Mitigating", "Resolved", "Closed", "On Hold"]
},
"sync_version": {
"type": "integer",
"minimum": 1
},
"last_synced_at": {
"type": "string",
"format": "date-time"
}
}
}
实践建议:在跨系统同步时,将
sync_version 作为乐观锁字段。每次更新请求必须携带当前版本号,目标系统校验版本一致后才允许写入,否则返回 409 Conflict 错误,由上游处理冲突。