OSIRIS：供应商中立的 JSON 格式，用于基础设施快照（IT/OT）

Source: Dev.to

反复出现的问题

如果你曾经尝试围绕基础设施数据构建工具（绘图、清单、审计、漂移/差异、文档），你很可能已经看到相同的问题：

• 每个厂商导出数据的方式都不同（即使是 JSON）。
• 每个工具最终都要编写自己的解析器和映射，大多数是闭源的。
• 关系（什么连接到什么、它位于何处、如何依赖）是最先变得不一致或隐式的部分。
• 随着时间推移，你要么不断重建集成，要么依赖于人们脑中的未记录部落知识，导致对无限问题的答案模糊不清。

结果是碎片化、工具特定的流水线，维护成本高，且难以获得基础设施的统一视图。

OSIRIS 是什么

OSIRIS 是一种厂商中立的 JSON 格式，用于描述跨异构 IT 与 OT 环境的基础设施资源及其拓扑关系。它生成 静态快照交换格式。

快照描述：

• 存在的内容（资源）
• 它们之间的关系（连接/关联）
• 在特定时间点（时间点）

它的设计目标是：

• 厂商中立（模式即合约）
• 工具友好（消费者无需厂商特定的解析器）
• 可扩展（为厂商或领域特定字段（包括 OT）提供命名空间扩展）

OSIRIS 不是（在 v1.0.0 中）

OSIRIS 不是：

• 基础设施即代码（IaC）
• 配置管理
• 遥测 / 指标 / 流式事件

它是一种可以导出、验证、存储、对比并消费的格式。

生产者 / 消费者 分离（核心理念）

与其让每个工具实现所有厂商的格式，OSIRIS 将职责分离：

• 生产者 将源数据转换为 OSIRIS 文档（例如：超大规模云或公共云提供商的清单 API、网络设备输出、OT 网关、CMDB 导出）。
• 消费者 读取 OSIRIS 文档（例如：绘图生成器、清单平台、审计工具、差异工具、文档系统）。

这样可以把厂商特定的逻辑集中在一个地方，并让多个工具共享同一快照格式。

当前包含的内容

• 规范与文档：
• 规范核心 JSON Schema（v1.0）：
• 示例：
• 一种先进行模式级验证、后留出空间进行更丰富语义验证的验证方法。

我希望得到的反馈

如果你从事基础设施数据工作，期待你对以下方面提出批评：

1. 核心模型： “资源 + 关系” 是否足够且易用，能够覆盖真实的拓扑？
2. 可扩展性： 扩展/命名空间的做法是否实用且具备前瞻性？
3. 采纳路径： 哪个首个生产者对你最有价值（云清单、设备 CLI、Terraform 状态等）？

接下来的计划

• 为贡献者制定开发指南
• 初步核心/SDK 工作，使生产者和消费者更易构建

如果你想审阅规范/模式或建议首个生产者目标，欢迎留言。

OSIRIS: