摘要
- 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 提供商。其产品页面称，产品以 Microsoft 服务为中心，由 Delos Cloud 主权提供，包括按用量和按用户的服务，同时也为第三方软件、开源软件和客户开发的应用留出空间。
这比“薄足迹”假设所暗示的公司存在性问题更强大。更好的调整是不同的：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 及平台受德国法律管辖。2025 年 5 月的D-Trust 证书发布在描述用于加密和认证通信的德国 TLS 证书时也强调了相同的地域性。
这种地域性具有商业价值。但它并非完整的站点地图。公开发布确定了居特斯洛和莱比锡大区的运营中心，以及法兰克福大区的安全运营中心。它们未公布数据大厅地址、供电设计、机架数量、功率密度、建筑所有者、会面室、燃料安排或运营商入口。它们称 Delos Cloud 数据中心在 2026 年 1 月处于最后准备阶段。它们未在此处审查的公开发布中命名这些数据中心。
应明确区分这一点。运营中心是人员监控、运营、安全和响应的地方。数据中心是计算、存储和网络设备消耗电力、散热并连接运营商的地方。两者相关，但不可互换。双站点运营安排即使在计算平台具有不同物理依赖时，也能提高人员和指挥韧性。相反，如果操作台、访问控制、运营商升级或变更审批不可用，两个数据大厅仍可能导致客户失败。Delos Cloud 的公开材料在运营中心层面最强，在数据大厅层面较弱。
同样的谨慎适用于地理冗余。2026 年 1 月的发布称两个已完成的运营中心通过地理冗余确保运营免受中断和危机场景影响。这是关于运营层的重要声明。它本身并不能证明每个客户工作负载都在两个独立数据大厅间同步复制、每个管理系统都具备主动-主动控制、每个客户服务都经过测试的区域故障转移，或每个存储服务都能满足特定的恢复点。这些细节可能存在于客户文档中，但并非全部公开。
因此，采购方面的正确站点问题更具针对性：所订购服务支持哪个区域、可用性设计和数据中心对？哪些功能由居特斯洛、莱比锡或法兰克福控制，哪些在数据大厅内运行？运营中心能吸收何种故障，哪些故障需要数据中心人员、运营商工程师、备件或 Microsoft 技术支持？公开材料开启了这一尽职调查线，但并未结束。
运营商边界是核心主权主张
Delos Cloud 的主权论证基于角色分离。2025 年 2 月的定价发布称 Delos Cloud 使用 Microsoft Azure 超大规模技术，但将这些服务主权地提供给德国行政机构。它称 Delos Cloud GmbH 作为基础设施所有者，承担平台运营和产品许可。Microsoft 作为技术供应商贡献。2024 年 10 月的SAP 合同发布和贝塔斯曼关于相同合同的报告描述了 Delos Cloud、Microsoft 和 Arvato Systems 之间的最终合同，并称 Arvato Systems 将支持在德国的平台运营。
这种结构很重要，因为公共部门买家购买的不是虚拟机或 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 将为德国公共客户提供的 Sovereign Microsoft 服务定价为当前 Microsoft 德国标价之上 15%，该价格适用于 Delos Cloud 提供的 Microsoft 基础设施和平台服务，包括 Azure 基础服务、Azure 主流服务和 Microsoft Office 365。附加费是主权可见的价格，但不是容量保证。15% 的上调只有在平台达到足够需求且底层设施计划有可用储备时，才能支付德国运营、安全要求、独立基础设施和控制安排的费用。
可用储备是隐藏的分母。Delos Cloud 可以宣布运营中心和产品目录，但评估生产环境的客户需要更难以发布的容量数据：已投运的 IT 负载、已售负载、备用负载、按服务的集群、存储储备、网络超订、备份容量、支持人员、补丁窗口和恢复性能。已安装的服务器不等同于可用的云容量。装有硬件但未经过测试的自动化、备用存储、批准维护路径或运营商多样性的机架无法安全承载关键工作负载。能够启动试点租户的区域并不自动准备好用于大规模部门迁移。
这就是平台开放和供应商中立声明重要的原因。合作伙伴计划和产品页面称第三方可以将解决方案带到 Delos Cloud。这可以增强生态系统深度，但也增加了变数。基于 Delos 基础设施的合作伙伴构建的应用可能具有与 Office 365 服务不同的支持、许可、补丁和恢复条款。开源组件可能具有与 Microsoft 提供组件不同的维护责任。客户开发的应用可能需要着陆区、监控、备份、密钥处理和网络分段，而 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 标识为可见分配的地址持有者。RIPEstat RPKI 验证对 AS198678 和123.2.0.0/15返回有效来源状态，相应的IPv6 验证对 AS198678 和2a07:3040::/32返回有效。
这些事实支持一个重要主张：Delos Cloud 在自己名下拥有活动的公共互联网路由。它们不支持云买家关心的所有主张。RIPEstat 邻居视图看到 AS198678 有一个公共邻居：AS212185。AS212185 的 RIPE RDAP将该 AS 标识为deloscloudconnect，注册于 2025 年 6 月 26 日，注册人为 Delos Cloud GmbH。AS212185 的 RIPEstat 公布前缀数据显示两个 IPv4 /23 和两个 IPv6 /48，而AS212185 的 RIPEstat 邻居数据看到了 AS2914、AS3356 和 AS198678。
这种模式看起来像是 Delos 连接 AS 背后的内部来源 AS，然后通过大型上游连接到达全球传输。这可能是完全有意且具有韧性的。它也可能隐藏公共 BGP 视图无法看到的物理依赖。AS212185 是否接收多样化的光纤入口？AS2914 和 AS3356 是否通过单独的会面室、管道和光学系统进入？如果其中一个故障，另一个能否承担全部生产负载？管理和客户平面是否分离？是否有不在 PeeringDB 中可见的互联网交换对等？公共路由无法回答这些问题。它只能显示采集者看到的路径形状。
缺少公共 PeeringDB 条目也是有限的证据。对PeeringDB 针对 AS198678的查询返回无网络记录。PeeringDB 是自愿的；缺失并不意味着 Delos Cloud 缺乏设施、私有互联或上游合同。但它的确意味着公众无法使用 PeeringDB 验证设施存在、交换端口、流量策略或对等联系详情。对于依赖与公共网络安全连接的主权云，缺失公共互联概况增加了对直接客户证据的需求。
因此，网络等级是中等而非弱。路由是活动的、RPKI 有效且广泛可见。公共路由图不足以揭示足够的物理多样性，无法将网络边缘视为经证明具有韧性。客户应要求路由来源设计、上游运营商列表、物理入口多样性、DDoS 处理、私有公共部门连接、路由泄漏防护、故障转移测试结果和维护通知规则，然后再依赖 Delos Cloud 承载高影响工作负载。
电力和冷却仍是不引人注目的证据点
主权云本质上仍是一个电厂和冷却厂，上面叠加了软件。公开的 Delos 发布称数据在德国数据中心处理，这些数据中心在 2026 年 1 月处于生产运营最后准备阶段。它们未披露公用电力容量、变压器拓扑、UPS 设计、发电机额定值、燃料运行时间、冷却拓扑、水暴露、防火分区或机架密度限制。出于安全和商业原因，这种省略可以理解，但它给买家留下了无法跳过的问题。
BSI C5 目录页面和C5:2026 目录 PDF显示了为什么这种证据级别对于云保证是正常的。云安全包括物理安全、运营、事件处理、业务连续性、可移植性、服务级别和供应链控制。Delos Cloud 自己的材料称其符合 BSI 要求，旨在支持敏感公共部门数据的处理。该主张最终应由证明和测试证据支持，而不仅仅是启动声明。
对于电力，客户需要了解服务边界。客户工作负载是否放置在两个物理独立的数据大厅？从变电站到机架的供电馈线是否独立？已投运的 IT 负载与仅安装的负载相比是多少？发电机设备能否同时承载 IT 负载和冷却？长时间停电期间加油时会发生什么？哪些系统可同时维护，哪些维护状态会降低冗余？A/B 机架供电在汇聚于一个配电板或 UPS 列的上游时意义不大。
对于冷却，客户需要有散热图。平台可能保持电力供应，而入口温度升高、组件节流、主机卸载负载。冷却设备在已售负载下是否有足够的储备？冷水机组、泵、控制器、供水和热交换器是否由独立电源支持？冷却维护能否在不移动客户工作负载的情况下进行？如果冷却单元、控制器或传感器网络故障，事件路径是什么？这些并非学术问题。它们决定是短暂的设施故障还是服务事件。
对于火灾和水暴露，客户需要建筑特定的缓解措施。德国所在地在管辖权和人员配置方面有所帮助，但无法揭示楼层高度、泄漏检测、气体灭火、烟雾分区、燃料储存、相邻租户风险或紧急通道。正式安全评估可能涵盖这些事实。公开发布未公布它们。直到在适当保密下对买家可见，安全的公开声明是：数据中心位于德国，数据大厅韧性无法公开评分。
维修窗口是客户发现谁真正运营服务的地方
维护窗口将设计变为现实。一个服务可能拥有两个站点、两个运营商和重复组件，但如果维修程序需要不安全的手动步骤、缺少备件、人员无法到达站点，或者变更应用时没有回滚路径，它仍然可能失败。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 连续性协议使迁移更加明确。它称某些客户可以选择将工作负载迁移到 Delos Cloud，如果外部限制阻止 Microsoft 为其提供服务。这是一种战略应急措施。其实际价值取决于容量、法律权利、软件访问权限、兼容的服务版本、客户准备度、带宽和测试演练。从未演练过的紧急迁移是一种希望，而非恢复能力。
因此，买家应将迁移产物视为现场运营证据。所需证据包括着陆区模式、身份集成指南、导出说明、按服务的限制、备份和恢复测试、回滚标准、成本影响和客户验收测试。目标不是让每个工作负载都与云无关。目标是精确知道依赖是有意的、暂时的还是危险的。
主要故障路径是普通的，而非异常的
Delos Cloud 的战略背景可能使风险感觉像地缘政治，但大多数服务故障仍将从普通基础设施开始。
第一个路径是机架或主机故障。服务器、存储架、柜顶交换机或电源分配单元故障。如果备件在本地且自动化工作，客户可能几乎看不出影响。如果故障影响到小型服务集群、不成熟的区域或储备有限的管理系统，客户可能会看到配置错误、性能下降或恢复失败。Delos Cloud 的公开材料未公布集群大小、备件比率或恢复时间。
第二个路径是上游或运营商故障。公共 BGP 显示 AS198678 位于 AS212185 之后，AS212185 与大型传输提供商相邻。设计可能具有良好的私有多样性，但公共路由图未能证明。运营商维护事件、光纤中断、光平台故障或路由泄漏可能隔离客户工作负载或管理路径，即使计算保持健康。客户需要了解物理路径多样性，而不仅仅是 AS 号码。
第三个路径是软件更新和提供商合同故障。Delos Cloud 依赖 Microsoft 技术，同时保留德国运营和控制。安全更新、功能变更、许可和紧急权利都必须安全地跨越该边界。更新流太少会带来安全性和兼容性风险。未经中介的更新流过多会削弱主权主张。公开发布显示合同存在；客户需要运营规则和证据。
第四个路径是支持和人员饱和。两个运营中心降低了人员站点风险，但广泛的事件仍可能使服务台、合作伙伴团队和升级队列过载。公共部门客户会希望事件分类、严重性目标、通信模板、非工作时间权限以及来自演练的证据。大规模的身份验证、邮件、网络或存储事件影响的人远远超过单个虚拟机停机。
第五个路径是计费、采购和权利不匹配。Delos Cloud 的公开产品仅限于德国符合条件的公共客户，通过合作伙伴和公共部门 IT 提供商提供。服务可能在技术上准备就绪，但受合同、权利、预算、采购目录、合作伙伴可用性或安全批准阻碍。托管容量只有在客户能够根据适用的公共部门规则订购、配置、连接和支持时才能使用。
第六个路径是数据可移植性故障。如果客户无法足够快速地导出身份、邮件、存储、数据库、快照或日志，服务中断就会变成锁定事件。Delos Cloud 与 DVC 的对齐和合作伙伴生态系统可能降低这一风险，但证明需要经过测试的出口路径，而不仅仅是标准语言。
这些路径都不是否定 Delos Cloud 的理由。它们是任何严肃云平台必须让其变得平淡无奇的路径。平淡意味着已记录、已测试、已演练、已测量且合同约定。
托管经济学决定了可保留多少储备韧性
2025 年 2 月的价格声明很有用，因为它同时暴露了经济问题和买家主张。Delos Cloud 称，符合条件的公共客户的 Sovereign 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 拥有公开的运营里程碑、客户试点、合作伙伴规模、清晰的主权设计和活的网络资源。尚需验证的不是公司的存在。而是以其名义销售的容量在云服务的普通机械故障时的可靠性。