为我们的主权打分：openEduSuite 对照欧盟云主权评估框架
"云主权"很容易宣称，却很难衡量。之前的文章中，我们梳理了欧盟云主权评估框架的八大目标，并将它们对照一个自托管平台来解读。用框架对照一个假设来阅读是一回事；对照真实的部署来打分则是另一回事，因为那会产生可以核查的数字。
我们用官方框架方法论为我们自己的 openEduSuite 参考集群打分：全部 48 个标准、加权主权得分、以及"最薄弱环节"SEAL 级别。本文报告结果：平台强在哪里、结果在哪里被封顶。
框架衡量什么
欧盟云主权评估框架（v1.2.1）通过八个目标（SOV-1 至 SOV-8）和 48 个标准来评判云服务。每个标准都有一级序数的答案阶梯；每个答案都携带一个分值和 SEAL 级别（0 至 4）。分值用于加权主权得分，归一化到 /1000；SEAL 级别用于总体的 SEAL。
决定性特性是最薄弱环节：总体的 SEAL 等于任何单个标准所取得的最低 SEAL 级别。一个供应商可能得分不错，却因单一薄弱标准而落到 SEAL-1，例如非欧盟当局可以强制访问的硬件。得分奖励的是平均水平上的实力；SEAL 不是。
flowchart LR
A["标准答案<br/>(48 个标准，SOV-1 至 SOV-8)"] --> B["分值"]
A --> C["SEAL 级别 (0 至 4)"]
B --> D["加权主权得分<br/>73.5% (735 / 1000)"]
C --> E["总体 SEAL = 最低 SEAL<br/>在所有标准中"]
E --> F["SEAL-1 · 司法主权"]
我们评估了什么
评估对象是 Sovereign Cloud Days 工作坊所用的 openEduSuite 参考集群：三台翻新的华为 RH2288E V2 服务器（约 2013 年），在裸金属上运行经过 SCS 认证的 K3s，配备 Ceph 存储、Flannel、MetalLB、HAProxy 和 ArgoCD。它部署在马尔堡菲利普斯大学 HRZ 的本地机房，承载 openEduSuite 的多租户工作负载以及基于 CPU 的 Ollama 推理路径。
| 指标 | 结果 |
|---|---|
| 主权得分（加权，/1000） | 73.5%（735/1000） |
| SEAL（全部标准中最薄弱环节） | SEAL-1（司法主权） |
得分与 SEAL 出现分歧：一个扎实的得分和一个较低的等级，二者来自同一组数据。
按目标分解
| 目标 | 权重 | 得分 | 目标 SEAL |
|---|---|---|---|
| SOV-1 战略主权 | 20% | 94% | SEAL-4 |
| SOV-4 运营主权 | 15% | 83% | SEAL-3 |
| SOV-6 技术主权 | 15% | 80% | SEAL-3 |
| SOV-3 数据与 AI 主权 | 10% | 75% | SEAL-1 |
| SOV-2 法律与司法 | 10% | 71% | SEAL-1 |
| SOV-7 安全与合规 | 15% | 64% | SEAL-1 |
| SOV-5 供应链主权 | 10% | 50% | SEAL-1 |
| SOV-8 环境可持续性 | 5% | 19% | SEAL-1 |
xychart-beta
title "各目标主权得分 (%)"
x-axis ["SOV-1","SOV-2","SOV-3","SOV-4","SOV-5","SOV-6","SOV-7","SOV-8"]
y-axis "得分 (%)" 0 --> 100
bar [94,71,75,83,50,80,64,19]
平台强在哪里
SOV-1 战略主权（94%，SEAL-4）。 机构自己就是自己的供应商。控制、所有权、资金和路线图都位于欧盟内部。这是每个自托管平台都应达到的基线；得分证实了这一点。
SOV-4 运营主权（83%，SEAL-3）。 集群由欧盟团队运营，没有任何非欧盟供应商的生命线。升级、打补丁和排障都在内部完成；开放标准和 GitOps 使工作负载保持可移植。剩余的差距是形式化问题，而非能力问题。
SOV-6 技术主权（80%，SEAL-3）。 一切均为开源，运行在开放标准（Kubernetes、Ceph、OIDC）之上，并且可以被我们检视、修改和重新部署。这正是 openEduSuite 的核心承诺。
结果在哪里被封顶
总体的 SEAL-1 由那些无法达到更高等级的标准所决定。
SOV-5 供应链（50%，SEAL-1）。 硬件（华为服务器、英特尔或华为组件、不透明的固件）来自欧盟以外，且仅部分披露。这是最大的单一拖累，也是我们为证明退役硬件仍可发挥作用而做出的采购决定。软件是主权的；翻新的硬件不是。
SOV-7 安全与合规（64%，SEAL-1）。 集群已通过 SCS 认证（6/6 项 KaaS 标准，444/444 项 CNCF 一致性），并被积极监控，但 SCS 合规并非正式的 EAL 认证，独立审计权也尚未被完全行使。差距是程序性的，而非技术性的。
SOV-3 数据与 AI（75%，SEAL-1）。 数据留在欧盟境内的本地机房，密钥归我们所有，AI 路径在 CPU 上是可审计的开源实现。封顶该目标的是可验证的擦除：删除在内部按规则验证，但缺乏独立、有证据支撑的证明。
SOV-8 环境（19%，SEAL-1）。 复用旧硬件是良好的做法，但我们既不公布 PUE，也不公布排放数字。
SEAL-1 意味着什么
SEAL-1 是司法主权：欧盟法律适用于运营，但关键依赖仍处于欧盟控制之外。对于该集群上的 openEduSuite，这是一个准确的描述。软件、数据和运营是我们的；底下的硅是别人的。
这是一次自评，而非认证。签约机构可以对框架采用不同的权重，而真正的采购会被审计。我们公布这些数字，是因为得分只有在可复现时才有用；48 个标准的答案集和评分脚本存放在评估仓库中。
从 SEAL-1 走向 SEAL ≥ 3
三步：
- 处理硬件问题（SOV-5）。 披露来源或选择欧盟制造的平台，可以纠正结构性的弱点。
- 取得正式认证（SOV-7）。 弥合 SCS 验证与 EAL 认可级别之间的差距。
- 公布环境数字（SOV-8）。 测量 PUE、与 CSRD 对齐的排放报告、以及欧盟可再生能源。
每一步都是真正的工程。这正是"最薄弱环节"设计的意义所在：它不允许一个强势目标去补偿一个弱势目标。主权不是一个平均数。
结论
我们开展这次评估，是为了回答每个工作坊都会提出的问题：这次部署到底有多主权？用数字来回答是 73.5%，带有 SEAL-1 最薄弱环节；在软件及其运营方面很强，而被翻新的非欧盟硬件、缺乏正式认证以及环境报告缺失所拖累。
对于决定是否采用这类平台的机构而言，这比一句口号更有用。一场明确指出薄弱环节的自评，是做出采购决策的基础。
