摘要
- Delos Cloud 不再仅仅是一份备忘录或政策概念。其自身发布的信息称，位于居特斯洛大区的首个运营中心已于 2025 年 9 月上线，位于莱比锡大区的第二个运营中心于 2026 年 1 月上线，安全运营中心已准备就绪，数据中心正在进行生产服务的最终准备。
- 其商业产品是基于 Microsoft Azure 技术构建、由 Delos Cloud 运营并由 Arvato Systems 人员支持的德国公共部门云。Delos 表示，它拥有基础设施、运营平台并许可产品，而 Microsoft 提供技术，Arvato 支持德国境内的运营。
- 公开路由证据是真实的。AS198678 的 RIPE RDAP 记录显示为 Delos Cloud GmbH，RIPEstat 已宣告前缀数据显示四个 IPv4 前缀和一个 IPv6 聚合，RIPEstat 路由状态显示广泛的采集器可见性。可见的依赖性也很明确：RIPEstat 邻居数据将 AS212185（另一个 Delos Cloud 系统）视为 AS198678 的唯一公开邻居。
- 因此，韧性测试不在于 Delos Cloud 是否有可信的公开足迹。它确实有。测试在于，在关键公共部门工作负载依赖于托管服务之前，客户能否验证其设施电力、制冷、运营商多样性、维护实践、备件库存和支持升级机制。
公开证据现在支持严肃的运营探究
Delos Cloud GmbH 通过官方公司页面、SAP 发布、合作伙伴页面、客户试点材料和互联网注册数据可见。其关于页面将公司定位为德国数字公共服务的主权平台，符合德国安全要求，并旨在支持联邦、州和市级 IT 提供商。其产品页面称，其产品以 Delos Cloud 主权提供的 Microsoft 服务为中心，包括基于消费和基于用户的服务，同时也为第三方软件、开源软件和客户开发的应用程序留出了空间。
这比“薄弱足迹”假设所暗示的（如果仅将其解读为对公司存在性的质疑）更具公开说服力。更恰当的降级评估有所不同。Delos Cloud 有足够的证据被视作一个真实、进展显著的建设项目。但它尚未公布足够的物理和运营细节，以便外界能够将每个数据中心、传输、维护和迁移依赖项都评定为经生产验证的。在公共部门云中，这种区别比品牌熟悉度更重要。一个主权产品仍然是一个托管容量产品。它仍然需要将建筑、机架、路由器、人员和合同转化为在设备故障时依然可用的服务。
时间线很重要。一份2025 年 9 月的 SAP 发布称，Delos Cloud 在居特斯洛大区将其首个运营中心投入了使用。该发布称，那里将有超过六十名人员，由 Arvato Systems 运营人员运行 Delos Cloud 服务，并且该中心在平台运营、安全和认证中扮演重要角色。它还提到，位于莱比锡大区的第二个运营中心即将完工，位于法兰克福大区的第三个运营中心将很快开工建设，而位于法兰克福大区的安全运营中心已经准备就绪。
一份2026 年 1 月的 SAP 发布则推进了事件进展。该发布称，位于莱比锡大区的第二个运营中心已投入运营，生产运营所需的运营中心基础设施已经完备，两个投入使用的运营中心为平台提供了应对故障和危机场景的地理冗余运营保护。同一份发布还提到，相关的安全运营中心已准备就绪，Delos Cloud 数据中心正在进行生产运营的最后准备。它还提到，莱比锡中心将提供 80 个工位，并在严格的安全措施下实行全天候运营。
公开客户证据也已超越了一般性兴趣。Delos Cloud 的客户页面列出了试点客户以及联邦和州级公共用例的具体案例，包括一家联邦就业机构、一个北莱茵-威斯特法伦州金融与技术项目以及巴登-符腾堡州的文化机构。一份2026 年 5 月的 SAP 发布称，斯图加特国家剧院已启动针对 Microsoft Office 365 和选定 Azure 服务在 Delos Cloud 平台上的试点，巴登国家剧院卡尔斯鲁厄也参与其中，并由 SVA 作为咨询和实施合作伙伴。一份2026 年 6 月的 SAP 发布称，Delos Cloud 在合作伙伴计划启动时已与 15 家企业签署了战略合作伙伴关系。
综合来看，这些来源足以支撑严肃的基础设施分析，而非持怀疑态度的否定。问题不再是 Delos Cloud 是否出现在公开记录中，而是已推出基础设施与客户仍需查验的部分之间的界限在哪里：物理数据机房、运营商路由、支持升级、恢复路径、安全认证以及对 Microsoft 技术基础的商业依赖性。
服务区域是德国，但站点地图依然有限
Delos Cloud 的服务区域承诺异常明确。其材料反复强调该平台服务于德国公共部门，且数据处理和运营将留在德国境内。2025 年 2 月的定价发布指出，该平台面向德国公共客户，敏感行政数据将在德国境内的数据中心和运营站点处理，且 Delos Cloud GmbH 及该平台受德国司法管辖。D-Trust 证书发布在描述用于加密和认证通信的德国 TLS 证书时，也强调了相同的地点属性。
这一地点属性具有商业价值，但它并非完整的站点地图。公开信息中提到了居特斯洛大区和莱比锡大区的运营中心以及法兰克福大区的安全运营中心，但并未公布数据机房的地址、供电设计、机架数量、电力密度、建筑所有者、配线架、燃料安排或运营商入口。它们声称在 2026 年 1 月时数据中心已进入最后准备阶段，但在本报告所查阅的公开信息中并未指明这些数据中心的具体名称。
这一界限应被清晰划分。运营中心是人员进行监控、操作、安全和响应的地方，而数据中心是计算、存储和网络设备消耗电力、排出热量并连接运营商的地方。两者相关，但不可互换。双站点运营布局可以提升人员和指挥的韧性，即使计算平台拥有独立的物理依赖。反之，如果运营桌面、访问控制、运营商升级或变更批准不可用，两个数据机房也可能无法为客户提供服务。Delos Cloud 的公开材料在运营中心层面最有力，而在数据机房层面则较弱。
对地理冗余的谨慎态度同样适用。2026 年 1 月的发布称，两个投入使用的运营中心通过地理冗余保障运营，以应对故障和危机场景。这是关于运营层的重要声明，但本身并不能证明每个客户工作负载都在两个独立的数据机房之间同步复制、每个管理系统都具有主动-主动控制、每个客户服务都经过区域故障转移测试，或者每个存储服务能够满足特定的恢复点目标。这些细节或许存在于客户文档中，但并非全部公开。
因此，在采购时，正确的站点问题是具体的：所订购的服务由哪个区域、可用性设计和哪对数据中心支持？哪些功能由居特斯洛、莱比锡或法兰克福控制，哪些功能在数据机房内运行？运营中心能够吸收哪些故障，哪些故障则需要数据中心人员、运营商工程师、备用硬件或 Microsoft 技术支持？公开材料开启了这条尽职调查之路，而非终结。
运营边界是核心主权主张
Delos Cloud 的主权论证依赖于角色分离。2024 年 10 月 SAP 合同发布及贝塔斯曼关于相同合同的报道描述了 Delos Cloud、Microsoft 与 Arvato Systems 之间的最终合同，并称 Arvato Systems 将支持在德国的平台运营。2025 年 2 月的定价发布指出，Delos Cloud 使用 Microsoft Azure 超大规模技术，但以主权方式将这些服务带给德国行政机构。它表示，作为基础设施所有者的 Delos Cloud GmbH 承担平台运营和产品许可，Microsoft 则作为技术供应商贡献力量。
这一架构至关重要，因为公共部门采购方购买的不仅是虚拟机或 Office 协作。它购买的是法律和运营控制权的分配。Delos Cloud 声称，它在由德国公司运营、受德国司法管辖、配备德国安全审查人员且数据在德国处理的环境中提供 Microsoft 技术。这与在某个全球区域购买普通公共云服务并加上德国计费包装是截然不同的主张。
这一边界也创造了依赖性。如果 Microsoft 是技术提供方，Delos Cloud 仍然依赖 Microsoft 的软件开发、安全更新、产品演进和许可权。如果 Arvato Systems 人员在运营中心运行服务，Delos Cloud 则依赖 Arvato 的招聘、培训、审查、轮班覆盖和设施流程。如果 SAP 是母公司和投资方，Delos Cloud 虽受益于 SAP 的规模，但也置身于一个需要持续协调资金、合同和公众信任的战略计划中。主权降低了某些风险，但将另一些风险集中在一个精心设计的链条上。
2025 年 11 月与 Bleu 和 Microsoft 的韧性公告展示了这一链条。SAP 发布称，Delos Cloud 与 Bleu 同意针对广泛的危机和紧急场景开展跨境技术与运营合作，同时 Delos Cloud 与 Microsoft 签署了单独协议，旨在当外部限制影响 Microsoft 为某些客户提供云服务时，维持欧洲的业务连续性。这很有用，因为这表明 Delos Cloud 已考虑地缘政治下的服务连续性风险。这也表明为何运营边界不能被视作一堵单墙。某些紧急补救措施需要同时获得法律权利、软件访问、Delos 容量、运营人员及客户迁移能力。
可支持的结论是平衡的。Delos Cloud 拥有一个公开的主权设计，并明确了角色分离。该设计是有意义的。但它并不能替代对物理设施、更新路径、人员流程及紧急转移安排在实际负载下运行的证明。客户无需拒绝该设计，但确实需要针对故障对其进行检验。
Delos Cloud 销售的不是单一简单的云产品
Delos Cloud 的产品目录涵盖基础设施、平台和协作服务。产品组合页面列出了 Azure 基础服务、Azure 主流服务、Office 365、SAP 服务、第三方解决方案、开源软件和客户开发的应用程序，包括计算、存储、网络、数据库、容器服务、监控及安全相关项目。其路线图页面将服务集框定为一个通往主权公共部门云的分阶段路径。
这一广度对容量至关重要。一台虚拟机消耗 CPU、内存、存储、网络端口、主机调度能力、管理面容量和支持时间。一个托管数据库消耗存储、内存、备份容量和运维关怀。一个协作租户消耗身份、邮件、存储、策略和支持容量。备份或站点恢复服务消耗辅助存储、网络吞吐量、恢复流程和测试时间。Kubernetes 服务消耗控制面容量、工作节点、镜像、日志和安全维护。采购方看到的是一个云目录，而运营方则必须管理多个容量池。
2025 年 2 月的定价发布补充了经济框架。它表示，Delos Cloud 面向德国公共客户的主权 Microsoft 服务定价将比当前 Microsoft 德国目录价格高出 15%，该定价适用于 Delos Cloud 提供的 Microsoft 基础设施和平台服务，包括 Azure 基础服务、Azure 主流服务和 Microsoft Office 365。溢价是主权的可见代价，但并非容量保证。15% 的上浮仅在平台达到足够需求且底层设施规划有可用储备时，才能覆盖德国运营、安全要求、独立基础设施和控制安排的成本。
可用储备是隐形的分母。Delos Cloud 可以宣布运营中心和产品组合，但评估生产迁移的客户需要更难公布的容量数据：已投产 IT 负载、已售负载、闲置负载、按服务划分的主机集群、存储储备、网络超配比、备份容量、支持人员配备、补丁窗口及恢复性能。安装的服务器不等于可用的云容量。一个有机架和硬件但没有测试自动化、没有冗余存储、没有经批准的维护路径或没有运营商多样性的区域，无法安全承载关键工作负载。一个能启动试点租户的区域，并不自动准备好进行大规模部门迁移。
这就是平台开放和厂商中立主张的重要性所在。合作伙伴计划和产品页面表示，第三方可将解决方案带到 Delos Cloud 上。这可以增强生态系统深度，但也增加了差异性。一个建立在 Delos 基础设施上的合作伙伴应用，其支持、许可、补丁和恢复条款可能与 Office 365 服务不同。开源组件与 Microsoft 提供的组件在维护责任上可能不同。客户开发的应用程序可能需要 Landing Zone、监控、备份、秘密管理和网络分段，而 Delos 仅提供其中一部分。云目录是容量规划的起点，而非终点。
路由证据证明可达性，而非整个物理路径
Delos Cloud 的网络证据比许多早期阶段的主权云项目更强。AS198678 的 RIPE RDAP 记录将该自治系统标识为deloscloud，注册于 2023 年 5 月 1 日，注册人为 Delos Cloud GmbH。RIPEstat 的 AS 概览报告该 AS 于 2026 年 7 月 12 日宣告。其已宣告前缀视图在 2026 年 6 月 28 日至 7 月 12 日的窗口中显示五个可见前缀：123.2.0.0/15、142.221.0.0/16、161.37.0.0/16、168.86.0.0/17和2a07:3040::/32。
这些前缀的规模不小。RIPEstat 路由状态报告了四个 IPv4 前缀，共 294,912 个 IPv4 地址，以及一个相当于 65,536 个 /48 的 IPv6 聚合。它同时报告，在查询时，326 个采样的 IPv4 对等体中有 326 个看到了路由，322 个采样的 IPv6 对等体中有 322 个看到了路由。Delos IPv4 地址段的RIPE RDAP IP 记录将 Delos Cloud GmbH 识别为可见分配地址的持有者。对 AS198678 和123.2.0.0/15的RIPEstat RPKI 验证返回了有效的起源状态，对 AS198678 和2a07:3040::/32的相应IPv6 验证也返回了有效状态。
这些事实支持一项重要声明：Delos Cloud 拥有以自己名义运行的实时公共互联网路由。但它们不能支持云采购方关心的每项声明。RIPEstat 邻居视图看到 AS198678 有一个公开邻居：AS212185。AS212185 的 RIPE RDAP将其标识为deloscloudconnect，注册于 2025 年 6 月 26 日，注册人为 Delos Cloud GmbH。AS212185 的 RIPEstat 已宣告前缀数据显示两个 IPv4 /23 和两个 IPv6 /48，而其RIPEstat 邻居数据看到 AS2914、AS3356 和 AS198678。
这种模式看起来像是一个内部的源 AS，背后是一个 Delos 连接 AS，然后通过大型上游接入全球传输。这可能是完全有意且具有韧性的。但也可能隐藏了公开 BGP 视图无法看到的物理依赖。AS212185 是否接收独进入光纤入口？AS2914 和 AS3356 是否通过独立的配线间、管道和光系统进入？若其中一个故障，另一个能否承载全部生产负载？管理和客户面是否隔离？是否有 PeeringDB 上不可见的互联网交换对等互联？公开路由无法回答这些问题，只能显示采集器看到的路径形态。
缺少公开的 PeeringDB 条目也是有限的证据。对PeeringDB 查询 AS198678返回无网络记录。PeeringDB 是自愿的；缺失并不意味着 Delos Cloud 缺少设施、私有互联或上游合同。但这意味着公众无法使用 PeeringDB 验证设施存在、交换端口、流量策略或对等互联联系方式。对于一个依赖安全连接到公共部门网络的主权云而言，缺少公开互联信息增加了客户获取直接证据的必要性。
因此，网络评级为中等而非较弱。路由是实时的、经过 RPKI 验证且广泛可见的。公开路由图不足以揭示足够的物理多样性，从而认定网络边缘已经过韧性证明。客户在依赖 Delos Cloud 处理高影响工作负载之前，应当询问路由起源设计、上游运营商列表、物理入口多样性、DDoS 处理、私有公共部门连接、路由泄漏保护、故障转移测试结果及维护通知规则。
电力和制冷仍然是未被关注的证明点
一个主权云仍然是一个建在软件之上的发电厂和制冷厂。Delos 公开资料称数据在德国数据中心处理，并且这些数据中心在 2026 年 1 月已进行生产运营的最后准备。但它们没有披露公用容量、变压器拓扑、UPS 设计、发电机额定功率、燃油运行时间、制冷拓扑、水暴露情况、防火分区或机架密度限制。出于安全和商业原因，这些遗漏可以理解，但留给采购方一些无法跳过的问题。
BSI C5 目录页面和C5:2026 目录 PDF显示了为何这一证据级别对云保证是正常的。云安全包括物理安全、运营、事件处理、业务连续性、可移植性、服务级别和供应链控制。Delos Cloud 自身的材料称其符合 BSI 要求，并旨在支持处理敏感的公共部门数据。这一声明最终应由认证和测试证据支持，而不仅仅是启动声明。
关于电力，客户需要了解服务边界。客户工作负载是否放置在两个物理独立的数据机房中？从变电站到机架的公用供电是否独立？投用的 IT 负载与仅安装的比例是多少？发电机系统能否同时承载 IT 负载和制冷？在长时间断电期间的加油情况如何？哪些系统可并行维护，哪些维护状态会降低冗余？如果它们在单个开关柜或单条 UPS 母线上游汇聚，A/B 路机架供电意义不大。
关于制冷，客户需要一张散热图。一个平台在保持供电时仍可能因入口温度升高、组件降频和主机减载而出问题。制冷系统在已售负载下是否有足够储备？冷却器、泵、控制器、供水和热交换器是否有独立电源？制冷维护能否在不迁移工作负载的情况下进行？如果制冷单元、控制器或传感器网络发生故障，事件路径是怎样的？这些不是学术问题，它们决定一次短暂的设备故障是否会演变为服务事件。
关于火灾和水险，客户需要针对特定建筑的缓解措施。德国境内位置有利于司法管辖和人员配备，但无法揭示地面高程、漏液检测、气体灭火、烟雾分区、燃料存储、邻近租户风险或紧急通道。官方安全评估可能涵盖这些事实，但公开资料未予公布。在这些事实未以适当保密方式对采购方可见之前，审慎的公开陈述是：数据中心位于德国，但数据机房的韧性无法公开评分。
修复窗口是客户发现谁真正运营服务的地方
维护窗口将设计变为现实。一个服务可以拥有两个站点、两个运营商和冗余组件，但如果修复程序需要不安全的手动步骤、缺少备件、人员无法到达站点，或者变更没有回滚路径，它仍然可能失败。Delos Cloud 在这方面的最强公开证据是其运营中心建设：两个已投入使用的运营站点、来自 Arvato Systems 且经过安全审查的德国人员、一个安全运营中心以及不断增长的合作伙伴生态系统。
这是积极的。但这也引出了下一组问题。哪个团队可以打开数据机房的机柜？哪个团队可以更换故障存储架？哪个团队可以批准路由器变更？哪个团队可以推迟或拒绝 Microsoft 技术更新？哪个团队通知客户维护窗口？哪个团队宣布事件？在三方设计中，客户体验取决于合同和权限映射，与设备数量同样重要。
Arvato Systems 的 Delos Cloud 页面将 Arvato 定位为行政主权云的合作伙伴，而 2025 年 9 月和 2026 年 1 月的 Delos 发布均确认运营中心内 Arvato Systems 的操作人员。贝塔斯曼报告补充称，Arvato Systems 将运营该平台，且多个德国地点参与长期运营。这使 Arvato 在修复链中扮演重要角色，但并未披露具体的升级梯队、远程操作响应时间、备件政策或工单目标。
修复窗口还与公共部门的变更控制互动。普通超大规模云可能在全球区域持续推出变更。一个主权公共部门云可能需要更严格的通知、批准、文档和职责分离。这可以改善控制，但如果设计不当，也可能减缓修复。客户应询问标准的维护提前期、紧急变更规则、客户批准点、回滚程序，以及有代表性规模下计划维护已完成且无服务损失的证据。
支持覆盖同样重要。运营中心发布承诺了全天候运营。全天候运营并不自动意味着每项服务都有 24/7 专家支持、每个合作伙伴应用都能在夜间修复，或每个客户拥有相同的严重性路径。Delos Cloud 的合作伙伴计划将合作伙伴分为服务、销售和构建角色。这意味着客户在一次事件路径中可能面对 Delos Cloud、服务合作伙伴、软件供应商和内部公共部门 IT 提供商。一个修复窗口必须明确谁呼叫谁、谁拥有计时器以及谁能执行修复。
客户迁移是一项依赖，而非一次性上线任务
Delos Cloud 存在的原因是公共部门客户希望在不放弃本地性、司法管辖和运营控制的情况下使用现代云服务。这一迁移承诺是核心。它也是最容易夸大韧性的地方之一。将工作负载迁入主权云并不自动使其可移植、可恢复或独立于底层技术基础。
Delos 客户页面将试点描述为在大规模采用之前验证技术、合同和组织安排的方式。斯图加特国家剧院的发布称，试点将在真实条件下测试 Office 365 功能和选定 Azure 服务，并关注安全性、效率及与公共文化运营的整合。这是对试点的良好运用，它将迁移视为需要验证的，而非假设成立的。
对客户而言，实际的迁移问题是具体的。身份如何集成？租户策略如何设置？哪些 Office 365 数据可以导出和恢复？在启动时包含哪些 Azure 服务，哪些随后推出？虚拟机能否作为镜像迁出，还是只能重建？数据库、备份、日志、加密密钥和监控数据如何导出？如果一个公共部门机构从普通 Microsoft 服务开始，后来迁移到 Delos Cloud，或者从 Delos Cloud 开始并需要紧急迁移到其他地方，会发生什么情况？工作负载使用的托管服务越多，迁移就越依赖于产品特定的导出路径。
德国行政云战略材料和FITKO DVC 指引指向一个更广泛的联邦云生态系统，而非一个孤立的平台。这一背景很重要。Delos Cloud 可能是一个大型组件，但公共机构还需要互操作性、采购清晰度以及避免用一种依赖替换另一种依赖（仅仅是国家层面的）。数据本地化解决一个问题，而数据可移植性解决另一个不同的问题。
2025 年 11 月的 Microsoft 连续性协议使迁移更为明确。它指出，如果外部限制阻止 Microsoft 为某些客户提供服务，这些客户可以选择将工作负载迁移到 Delos Cloud。这是一项战略应急安排。其实用价值取决于容量、法律权利、软件访问、兼容的服务版本、客户准备情况、带宽和测试演练。从未演练过的紧急迁移只是一种希望，而非恢复能力。
因此，采购方应将迁移产物视为实时运营证据。所需证据包括 Landing Zone 模式、身份集成指南、导出说明、按服务划分的局限性、备份和恢复测试、回滚标准、成本影响及客户验收测试。目标不是让每个工作负载完全云中立，而是确切知道哪里有意的依赖、哪里是暂时的以及哪里可能变得危险。
主要故障路径是常见的，而非奇特的
Delos Cloud 的战略环境可能使风险感觉起来是地缘政治的，但大多数服务故障仍将始于普通基础设施。
第一条路径是机架或主机故障。服务器、存储架、机柜顶交换机或配电单元发生故障。如果备用硬件在本地且自动化工作正常，客户可能感觉不到影响。如果故障影响了一个小型服务集群、一个不成熟的区域或一个储备有限的管理系统，客户可能遇到配置错误、性能下降或恢复失败。Delos Cloud 的公开材料未公布集群大小、备件比率或恢复时间。
第二条路径是上游或运营商故障。公开 BGP 显示 AS198678 在 AS212185 之后，AS212185 毗邻大型传输提供商。该设计可能具有良好的私有多样性，但公开路由图无法证明。一次运营商维护事件、光纤切断、光平台故障或路由泄漏可能隔离客户工作负载或管理路径，即使计算部分仍然正常。客户需要了解物理路径多样性，而不仅仅是 AS 号码。
第三条路径是软件更新和提供商合同故障。Delos Cloud 依赖 Microsoft 技术，同时保留德国运营和控制。安全更新、功能变更、许可和紧急权利都必须安全地跨越这一边界。更新流程太少会产生安全和兼容性风险，而不加中介的过多更新流程则会削弱主权论证。公开信息显示合同存在，但客户需要运营规则和证据。
第四条路径是支持与人员饱和。两个运营中心降低了人员站点风险，但一起大事件仍可能使服务台、合作伙伴团队和升级队列过载。公共部门客户需要事件分类、严重性目标、沟通模板、非工作时间授权以及演练证据。一次重大身份认证、邮件、网络或存储事件比单台虚拟机停机影响的人要多得多。
第五条路径是计费、采购和授权不匹配。Delos Cloud 的公开产品仅限于德国符合条件的公共客户，并通过合作伙伴和公共部门 IT 提供商进行。服务可能在技术上已准备就绪，但受限于合同、授权、预算、采购目录、合作伙伴可用性或安全审批。只有当客户能够在适用的公共部门规则内订购、配置、连接和支持时，托管容量才实际可用。
第六条路径是数据可移植性故障。如果客户无法足够快地导出身份、邮件、存储、数据库、快照或日志，一次服务中断就变成了锁定事件。Delos Cloud 的 DVC 对齐和合作伙伴生态系统可能减少这种风险，但证明需要经过测试的出口，而不仅仅是标准文本。
这些路径中没有一条是抛弃 Delos Cloud 的理由。它们是任何严肃云平台都必须变得“无聊”的路径。“无聊”意味着文档化、测试过、演练过、测量过且在合同上有人负责。
托管经济学决定了能保留多少韧性储备
2025 年 2 月的定价声明很有用，因为它同时暴露了经济问题和采购方建议。Delos Cloud 表示，主权 Microsoft 服务针对符合条件的公共客户，定价将比当前 Microsoft 德国目录价格高出 15%。对于一个通常仅用战略语言描述的产品类别而言，这是一个相对清晰的数字。这使客户能够问出一个尖锐的问题：该溢价必须覆盖什么？
答案远不止软件许可。溢价必须支撑德国数据中心基础设施、德国运营中心人员配备、经过安全审查的人员、合规工作、独立的证书安排、合作伙伴协调、客户导入、事件响应、支持覆盖，以及足够的未使用容量来吸收增长和故障。其中一些成本在首个大客户到来之前就已固定。另一些随用量扩展。还有一些只在故障期间才显现，那时备用主机、备用存储、备用网络路径及高级工程师必须可用，尽管在平常日子里它们可能闲置。
这就是安装容量与可用容量脱节的地方。一个平台可能在德国数据机房安装了硬件，但扣除了储备、维护裕量、灾难恢复分配、管理面需求、备份空间和增长缓冲后，可销售部分会降低。如果平台销售过于接近其安装上限，维护将变得更危险。如果保留大量储备，经济模型就需要足够的客户需求来为其提供资金。客户看到的是云价格，而运营商管理的则是在安全和本地化约束下的库存问题。
公共部门采购可能放大这一挑战。客户可能在框架协议、试点审批或预算周期结束后批量到来。缓慢的增长可能使昂贵的基础设施利用不足，而突然的增长则可能对服务团队、配额规划和合作伙伴容量造成压力。一些客户在完成安全检查前可能需要保守的限制，而另一些客户可能在试点成功后希望进行大规模迁移。Delos Cloud 的合作伙伴生态系统可以帮助吸收这项工作，但前提是合作伙伴就绪程度、Delos 配额和客户治理能同时匹配。
对于采购方而言，经济尽职调查是务实的。询问哪些服务已普遍可用，哪些容量受限，哪些需要预约，哪些存在区域或租户配额，以及哪些支持条款随服务等级变化。询问 Delos 如何处理售罄的区域、稀缺的存储层级、大规模的 Office 迁移、突然的备份扩展或从其他环境进行的紧急迁移。只有当价格不仅购买本地性和法律控制，还能保留足够储备以承受普通基础设施压力时，主权云才具有良好的价值。
系统故障时谁会受到影响
直接客户是德国公共机构及其 IT 提供商。实际用户可能是公务员、剧院员工、财务团队、就业中心工作人员、市政管理员、案件处理人员、安全团队以及依赖公共数字服务的公民。受影响的具体人群取决于哪些服务发生故障。Office 协作中断可能影响员工沟通，虚拟网络中断可能隔离应用程序，数据库或存储事件可能停止案件处理，身份认证事件可能同时阻断跨多种服务的访问。
责任链是分层的。根据其发布信息，Delos Cloud 是公开的平台运营商和基础设施所有者，Microsoft 提供技术基础，Arvato Systems 支持德国运营，服务合作伙伴可能设计、实施和迁移客户环境，构建合作伙伴可能在平台上运行应用逻辑，公共部门 IT 提供商可能签约、集成并支持最终服务。经历不可用服务的公民看不到这些层次，但事件响应将贯穿其中。
这就是文章标题重要的原因。Delos Cloud 销售托管容量。即使法律包装是主权的，软件基础是熟悉的，托管容量仍然依赖机架、传输和修复窗口。一个故障的存储架不会因司法管辖而修复，一次运营商切断不会因政策声明而解决，一个迁移瓶颈不会因价格清单而消除。主权是一种控制主张，而可靠性则是一份运营记录。
Delos Cloud 最强的公开案例是，它已一步步从合同走向设施、试点、合作伙伴和路由。最强的审慎提示是，最终的生产证据必然比公开公告更为具体。数据机房需要当前的认证，传输设计需要多样性证明，修复链需要权限证明，客户退出路径需要演练。一旦采购方能够获得这些，Delos Cloud 就可以作为一个生产平台而非战略承诺来接受评估。
什么能解决剩余的问题
Delos Cloud 所需提供的证据，并非要求敏感的平面图或客户名称，而是关键托管容量的正常保证包。
首先，公布或在适当保密条件下提供数据中心的运营边界：设施运营商、德国位置区域、数据机房范围、公用与发电机等级、制冷韧性、物理安全控制、防火与水险保护，以及当前的认证或认证范围。目标不是透露具体的机架排，而是展示已评估的系统边界。
其次，提供按服务划分的容量证据。客户需要知道现在技术上什么可用、什么在试点中、什么已计划、什么依赖于 Microsoft 的发布节奏，以及什么有足够的备用容量来应对迁移潮。Delos 的路线图和产品组合很有用，但生产工作负载需要当前的可用性、配额、限制、维护状态和支持承诺。
第三，以适当的级别披露网络设计。公开 BGP 已显示 AS198678 和 AS212185。客户仍需要上游多样性、物理入口多样性、私有公共部门连接、路由安全、DDoS 响应、路由故障转移测试和维护程序。缺少 PeeringDB 本身不是缺陷，但缺失的公开互联视图应为客户提供直接的证据来代替。
第四，证明修复能力。这意味着提供近期关于倒电测试、制冷故障转移、运营商故障转移、安全事件处理、备份恢复、身份恢复、存储恢复、补丁回滚和客户沟通的证据。维护窗口不仅应说明工作何时发生，还应说明工作期间保留了哪些冗余。
第五，证明可移植性。客户需要经过测试的租户数据、虚拟机、数据库、日志、密钥、备份和应用程序依赖的导出路径。DVC 背景使互操作性成为战略目标；Delos Cloud 仍需展示特定客户如何进入、扩展、暂停、恢复或退出。
有了这些证据，对 Delos Cloud 的评估就能够超越“进展显著但仍需在物理和运营层面证明”的结论。没有这些，负责任的结论是经衡量的。Delos Cloud GmbH 拥有公开的运营里程碑、客户试点、合作伙伴规模、清晰的主权设计和实时的网络资源。尚待验证的不是该公司的存在性，而是当云服务的普通机械发生故障时，以其名义出售的容量的可靠性。