摘要
- IBM Cloud 发布了云市场中最有用的公开位置地图之一：完整多可用区区域、单园区多可用区区域、经典数据中心代码、通用可用区名称和 PoP 代码。该地图让客户能够将区域选择与物理数据中心组关联起来，而不是将区域名称视为纯粹的软件概念。
- 同样的证据并未涵盖决定硬恢复案例的具体事实。公开文档未披露确切的设施所有权、站点级兆瓦数、当前机架负载、公用设施拓扑、暗光纤路由、实时骨干利用率、Direct Link 运营商多样性或免费更换容量。
- IBM 自己的文档缩小了一些营销宣称的范围。硬件相关配置文件并非在所有地方都可用，经典虚拟服务器请求可能遇到容量不足，裸机库存因数据中心而异，Direct Link 并非自动冗余，且 VPC 区域资源在完整区域故障时不会自动迁移到另一个区域。
- IBM 的事件、迁移和关闭材料使基础设施观点具体化。电网中断、冷却电源故障、火灾、设施网络中断以及计划的 CHE01 关闭表明，云地理不仅仅是一种合规选择；它依赖于真实的建筑、运营商、运营商、维护窗口和数据移动能力。
区域标签是一种物理选择
IBM Cloud 的位置文档最有用的地方在于它没有给客户一个纯粹抽象的区域列表。它解释了 IBM Cloud 使用完整多可用区区域、单园区多可用区区域和经典数据中心。因此在工具和控制台工作流中出现的区域名称映射到物理数据中心分组。达拉斯、圣保罗、多伦多、华盛顿特区、法兰克福、伦敦、马德里、悉尼和东京不仅仅是销售地理区域。它们是区域选择，其 VPC 可用区映射到通用可用区名称，而这些通用名称标识了底层数据中心代码，如 DAL10、FRA05、LON06、SYD04 或 TOK05。
这使得 IBM Cloud 比那些公开地图只到城市标签的提供商更具可审计性。客户可以看到，VPC 资源逻辑可用区并非漂浮在无名云中。它关联到一个账户特定的可用区映射和一个物理位置代码。经典基础设施和 Power Virtual Server 资源更加直接：位置由数据中心代码指定，而不是区域抽象。IBM 还列出了北美、南美、欧洲和亚太地区的 42 个经典数据中心代码。该清单包括像 DAL08、AMS03、FRA05、LON02、CHE01、SNG01 和 TOK05 这样长期存在的名称。
然而，证据应被理解为其本意。数据中心代码不是街道地址、电力合同、房东披露、运营商管道路线图或库存报告。它是 IBM Cloud 运营模型内的物理位置标识符。它可以支持云产品有物质场所的结论。但它本身不能支持该场所有足够未使用的服务器、足够的备用电力余量、两个独立的光纤入口、独立的燃料物流或经过测试的客户故障切换容量的结论。
这种区别很重要，因为云买家通常将区域作为合规和延迟对象购买，然后在设计或恢复过程中发现它也是一个库存对象。如果客户需要特定的裸机配置、配备 GPU 的经典服务器、Direct Link PoP、本地 Object Storage 类或能够吸收故障工作负载的替换可用区，那么命名的区域只是第一道过滤器。真正的问题是请求的服务、配置、电路和恢复目标在账户可用的 IBM Cloud 物理切片中是否可用。
SoftLayer 留下了一个托管资产，而非无限弹性池
IBM Cloud 当前的基础设施资产仍带有托管业务的形态。2013 年的IBM 10-Q 表格记录了 IBM 以 19.77 亿美元收购 SoftLayer。IBM 历史上的SoftLayer 收购 FAQ描述了一家以达拉斯为基地、拥有大量客户基础的专用和虚拟基础设施业务。这种起源很重要，因为 SoftLayer 并非天生是一个纯区域超大规模抽象。它是一个基于数据中心、裸机库存、VLAN、私有网络、客户特定服务器和围绕命名设施的运营程序构建的托管平台。
现代 IBM Cloud 平台在此资产之上叠加了 VPC、托管服务、Object Storage、Kubernetes、OpenShift 和全球平台服务。然而，经典数据中心列表仍然存在，一些迁移和生命周期通知仍直接引用数据中心代码。位置文档称经典数据中心托管电力、冷却、计算、网络和存储资源，并且它们使用 POD 架构。POD 不是营销形容词。它是一个由机架、服务器、网络、存储和备用发电机构成的容量单元。添加一个 POD 会改变可销售的内容。服务器、路由器、存储类型或电力余量的耗尽会改变可配置的内容。
这就是为什么像 IBM 达拉斯 DAL14 VPC 扩展公告这样的扩张历史不应被解读为无限容量证明。该公告标识了一个新增的达拉斯可用区设施，并解释了 IBM 为何需要更多达拉斯容量。它没有披露安装的兆瓦数、服务器数量、当前利用率、租约条款、设备批次或客户承诺。这是一个 IBM 正在增加物理数据中心位置以服务区域的有用证据。它不是任何后续客户订单都可以假设每个达拉斯配置都有开放库存的证据。
对于老化设施，情况同样如此。IBM 的CHE01 关闭通知称 Chennai 01 的运营将于 2027 年 6 月 10 日停止。该通知设定了市场控制结束、新部署移除、网络维护中断窗口、迁移援助截止以及最终的 PaaS 和 IaaS 迁移窗口等日期。关闭通知是一份罕见的云文档，因为它暴露了通常隐藏在后端的基础设施事实：云站点有生命周期。它们可以被添加、限制、现代化、整合和关闭。一个将 CHE01 视为持久放置的客户现在必须将位置决策变为迁移项目。
完整 MZR 与单园区 MZR 是不同的故障地理
IBM 发布的多可用区区域与单园区多可用区区域之间的区别很有价值，因为它防止区域标签变得过于舒适。完整 MZR 使用跨都市区独立数据中心位置的多个可用区。位置页面将可用区描述为故障域，并说完整 MZR 模型使用三个或更多数据中心。它还提到确切距离因区域而异，并给出了可用区的最小间隔。这是有用的地理信息。它说明达拉斯或伦敦区域不仅仅是带三个软件标签的一个房间。
单园区 MZR 包含另一种事实。同一份 IBM 文档将 Chennai - Airtel、孟买 - Airtel 和大阪列为单园区 MZR。IBM 称其可用区位于同一建筑的不同部分或园区的多个建筑内，电力、冷却、网络和物理安全依赖关系可能重叠。这不是一个小警告。它改变了故障模型。在单园区区域内跨三个可用区分布资源的客户可能针对许多设备和维护故障提高了本地可用性，但其地理特性与三个分离的城域站点不同。
IBM 的VPC 高可用性和灾难恢复指南使这种差异更加明显。它说完整的可用区故障会使该可用区内的区域资源不可用，并且受影响可用区中的虚拟服务器实例不会自动移动到其他健康的可用区。它还提到单园区 MZR 中的数据中心灾难可能影响整个区域，因为可用区关联更紧密，因此服务应使用备份和恢复策略到另一个 MZR。这些行很重要，因为它们将责任从地图推回到架构。客户不能购买 MZR 名称并假设每个资源都变成区域性的。
实际效果很简单。区域性服务可以跨可用区分布其数据平面并在区域内部重新路由请求。区域性虚拟服务器、子网、网关或卷仍然绑定到一个可用区。单主机故障的处理方式与整个可用区丢失不同。完整的区域性灾难又有所不同。每一层都提出了不同的容量问题：剩余可用区是否健康、区域性控制平面是否可用、目标区域是否已储备、快照是否已复制、DNS 和应用程序是否能容忍故障切换、以及客户是否测试过移动。
对于采购而言，这意味着买家在将可用区多样性视为物理多样性之前，应询问账户的可用区映射。IBM 表示，账户的逻辑可用区映射在区域中创建第一个 VPC 资源时建立。两个团队说“可用区 1”可能指的是账户本地的逻辑标识符，不自动是同一个通用数据中心代码。通用可用区名称是更强的证据。没有它，弹性图可能看起来比实际更精确。
容量是动态的，而非由发布的代码隐含
IBM Cloud 文档以多种方式表明发布的位罝仍可能无法满足请求。服务部署政策将核心服务与市场驱动服务分开，并警告硬件相关的配置和功能并非在每个 MZR 中都可用。这是第一个容量边界。一个区域可能开放，核心服务可能存在，但控制台可能仍不提供客户想要的专业配置、加速器、存储选项或托管服务。
第二个边界是实时库存。IBM 的经典虚拟服务器故障排除页面记录了当路由器或数据中心缺乏资源来满足请求时出现的容量不足错误。IBM 建议的响应在操作上具有启发性：尝试不同的路由器、避免指定路由器、使用不同的数据中心、请求更少的实例、选择更小的尺寸或更改存储类型。这不是一个云理论问题。这是一个资源位置问题。请求的服务器不是抽象的计算机量；它必须降落在特定数据中心甚至特定路由器后的可用基础设施上。
第三个边界是硬件位置。同一故障排除页面将 GPU 配置限制在命名的经典数据中心。确切的列表提醒人们，专业硬件并非均匀分布在地图上。客户为 AI 推理、图形工作负载或加速器备份恢复设计时，不能将每个 IBM Cloud 区域视为等同。同样的原则出现在 IBM 的裸机文档中。裸机服务器是专用物理机器，快速配置库存是预配置的，定制服务器取决于复杂性和数量，配置流程暴露了按数据中心的动态库存。IBM 还描述了可能增加时间的压力测试，以及一些服务器增强因配置而异。
这使得容量更可读但也更脆弱。动态库存显示可以帮助买家避免幻想计划，但它不断变化。在设计时可见的预配置服务器可能在灾难演练开始时就不存在了。VPC 预留可以持有专用区域计算容量，但它不预留每个存储、网络、备份、Object Storage、Direct Link、支持或目标区域依赖关系。一个有可用虚拟服务器的区域可能没有相同的裸机配置。一个有可用服务器的区域可能没有客户面向的私有电路在正确的 PoP。
核心工程规则是安装容量、宣传容量和可用容量是不同的东西。IBM 发布了许多位置和服务事实。它没有发布按站点的当前空闲库存、按 POD 的机架电力、已占用负载、预留余量、队列深度、备用路由器或故障条件下的恢复容量。需要硬恢复保证的客户必须创建自己的证据：预留、预置温暖容量、经过测试的自动化、当前库存检查、支持协议以及目标区域在压力下能够吸收工作负载的证明。
电力和冷却位于云合同之下
IBM 的弹性文档称数据中心使用多个电力馈入、光纤链路、专用发电机和电池备份。IBM 的全球数据中心营销页面描述了 N+1 电力和冷却、安全性以及空间、电力、网络和人员的优化。企业环境披露增加了关于数据中心 PUE、可再生能源采购以及供应商或房东在电力采购中作用的聚合证据。综合来看，公开记录明确了一件事：IBM Cloud 并未假装基础设施凌驾于电力之上。电力、冷却和物理网络是服务边界的一部分。
但证据并非站点级电力尽职调查。它没有说明分配给 FRA05、DAL14、SAO01、CHE01 或 TOK05 的公用电力容量。它没有披露燃料合同、发电机运行时间、电池持续时间（按机房）、变压器冗余、冷却系统设计、水暴露、房东义务、维护窗口、开关设备年龄或热浪或电网故障时的负载。企业聚合 PUE 对环境报告有用，但不能回答一位客户是否可以在一个数据中心添加二十台服务器或将重型机架资产故障切换到另一个数据中心。
IBM 自己的高可用性指南包含一个小但重要的硬件警告：一些老旧站点有 1U 单插槽服务器机箱，可能无法容纳双电源馈入。这个细节不应被夸大为对 IBM Cloud 的普遍指控。它很有用，因为它显示了旧设备和设施模式如何能戳破宽泛的冗余陈述。一个数据中心可以有多个电力馈入，而特定的机箱或客户配置仍可能缺乏双馈入保护。可靠性存在于最低的相关层。
事件记录使这一点具体化。IBM Cloud 的事件报告存档和状态历史包括了涉及电网停电、火灾、华盛顿停电、SAO01 冷却电源故障和设施网络中断的位置和服务事件。公开状态材料没有提供每个根本原因或每个修复细节，因此不应将其转化为每个站点的排名风险模型。但它确实表明 IBM 要求客户为之设计的故障路径并非理论上的。电力会失效。冷却可能成为约束条件。设施网络可以在客户未更改应用代码的情况下中断服务。
对于严肃的客户来说，电力问题不是“提供商声称冗余吗？”而是“我的工作负载的哪一部分绑定到哪个物理代码、哪个设备有双馈入、IBM 记录了哪些站点事件、我的支持计划在电力或冷却事件期间给了我什么、以及如果受影响的可用区或站点不能快速恢复，我可以在哪里重新启动？”IBM 在其共享责任模型下负责设施、物理网络、存储和虚拟机管理程序。客户仍然负责放置应用程序和数据，以便这些物理故障不会变成业务故障。
骨干网广泛，但私有入口是独立的
IBM Cloud 的网络证据在平台层面很强。IBM 描述数据中心到数据中心的流量在其骨干网和 ASN 内保持私有连接。其弹性文档描述了将边缘站点连接到区域计算设施的暗光纤提供商、到其他区域的冗余骨干连接，以及通过本地交换和直接对等与多个提供商的对等。PeeringDB 的 AS36351 记录增加了 SoftLayer/IBM Cloud 拥有国际交换足迹和公开可见的网络身份的市场信号。
这是存在严肃云网络的有用证据。但它不是光纤路由图。PeeringDB 由运营商维护且未经审计。IBM 的骨干描述没有发布确切的路由器路线、暗光纤提供商、共享桥梁交叉点、维修合同、利用率、拥塞、维护历史或同时故障暴露。客户可以合理推断 IBM Cloud 运营着一个大型骨干网。客户不能推断设计中的两条路径避免了相同的城市沟渠、建筑 meet-me 房间、长途提供商、交换中断或维修约束。
边界在IBM Cloud Direct Link上更加清晰。Direct Link 是从客户网络到 IBM Cloud 的私有第 3 层入口。IBM 的先决条件页面关于分界点异常直接。客户必须安排并支付通往 PoP、交叉连接和提供商电路的路径。单个 Direct Link 服务路径不受保护。冗余需要多个连接、独立的路由器或地理多样化的 PoP，以及客户路由配置。IBM 还表示不会在 IBM 网络 PoP 中共置客户设备。
这意味着私有云连接的弹性是共同产生的。IBM 控制服务终端和 IBM 侧云网络。客户及其运营商控制通往 PoP 的路由、交叉连接订单、本地环路、路由器对、BGP 策略以及长途路径的多样性。IBM 的 Direct Link 多样性指南和 FAQ 可以显示正确的架构模式，但图表不是两条电路遵循独立物理路由的证据。如果实现不佳，等成本路径仍可能汇聚到公共路由器或公共外部设施。
实际的故障路径通常是平凡的。客户购买两条电路，看到两个 BGP 会话，并称结果为冗余。然后一个建筑 meet-me 房间、运营商交接、最后一英里沟渠、路由策略、计费暂停、路由器维护或错误的 VRF 迁移创建了单点故障。IBM 文档甚至提到 Direct Link 可能因计费相关原因暂停。那不是物理光纤切断，但它仍然是基础设施依赖关系：私有入口可能因为维持其活跃的管理系统失效而消失。
控制平面可以保持运行，而恢复仍然依赖物理
IBM 的 VPC 文档将控制平面与数据平面分开，这种分离很重要。如果控制平面出现问题，现有已配置资源可以继续运行。如果某个可用区中的数据平面失效，区域性或其他可用区的控制平面仍可能管理健康可用区。这种架构可以使云比单个托管设施更具弹性。它也导致了一个常见误解：如果控制台可访问并且控制平面可以在其他地方创建资源，客户可能认为工作负载可以无物理摩擦地恢复。
VPC 灾难恢复指南另有说明。在完整可用区故障中，区域资源不可用，并且失效可用区中的虚拟服务器实例不会自动移动到健康可用区。客户必须设计跨可用区的应用高可用性或恢复到可用位置。对于区域性灾难恢复，IBM 指向脚本、Terraform、Object Storage、Schematics 和可部署架构。客户必须维护 VPC 配置的外部真实来源、保留数据副本并测试计划。IBM 可以努力恢复底层设施、网络设备、存储、服务器、内存和虚拟机管理程序，但如果 IBM 无法恢复服务实例，客户必须通过设计的恢复路径来恢复。
这就是容量和恢复成为同一个问题的地方。仅存在于失效区域的快照不是远程恢复资产。从未在另一个区域应用过的配置文件不是经过测试的故障切换。区域级负载均衡器无法拯救未设计为水平扩展的工作负载。带有本地磁盘的裸机服务器是与带有远程块快照的虚拟服务器不同的恢复问题。IBM 的裸机恢复文档称 IBM 不会自动备份客户设备。客户必须选择并管理备份和恢复方法。
IBM 的块存储快照文档为恢复增加了物理维度。快照和跨区域副本有用，但远程副本需要时间并产生传输和存储成本。IBM 的完整 3 TB 远程副本示例达到数小时而不是数秒。快速恢复克隆可以帮助，但需要启用并支付区域本地准备费用。这些本身都不是弱点。这就是数据移动的工作方式。风险在于买家将快照存在视为仿佛已在另一个区域恢复的计算。
Object Storage 也有类似教训。IBM 的 Object Storage FAQ 区分了跨区域、区域和单站点弹性，并说更改存储桶位置需要创建新存储桶并移动数据。存储桶移动指南讨论了复制、完整性检查、端点选择、计算放置以及必须重新创建的配置。存储桶可以全局可达，而其弹性等级和物理位置仍然重要。在压力事件期间移动它不同于在事件前选择了正确的等级。
驻留缩小了位置，而非每个运营依赖关系
IBM Cloud 的驻留材料让客户有理由关心区域选择，而不仅仅是延迟。对于区域和可用区服务，IBM 称客户内容存储和处理在所选区域，受适用服务行为和条款约束。欧盟支持的账户设置提供了另一层：普通支持可以路由到欧盟团队以获得符合条件的服务，而时间有限的欧盟外专家访问仍可在经过审查的未解决案例中发生。IBM 自己的解释材料区分了数据驻留和数据主权，这意味着物理位置和法律权力相关但不相同。
这很有用，因为它阻止了常见捷径。客户不能简单询问数据是否在法兰克福、伦敦、马德里或多伦多，并宣布运营风险已关闭。区域控制物理放置的大部分，但服务可能仍依赖全球平台功能进行身份、计费、目录、支持、使用计量、公共 IP 管理、DNS、Direct Link 控制、Object Storage 配置或其他管理任务。IBM 的弹性文档称全球平台服务和一些全球控制平面服务即使在另一个区域的工作负载中也可能造成跨区域运营影响。
这并不意味着本地数据承诺毫无意义。这意味着依赖关系图有两层。对于所选服务，字节可能存储在并处理于选定区域。创建资源、认证用户、更改 DNS、附加 Direct Link、查看计费、开支持案例、创建存储桶或配置新容量的能力可能仍涉及区域性或全球控制平面服务。正常运行期间，区别可能不可见。在事件期间，它可以决定工作负载是否持续服务、管理员是否可以更改它、以及客户是否可以快速建立替代方案。
监管和商业条款增加了另一个基础设施后果。IBM 的条款指南讨论了欧盟数据法案降低出站费用以及法国 SREN 豁免程序。这些是法律和定价机制，不是光纤路由。然而，它们影响恢复经济学。将数据移出提供商或在区域之间移动部分是网络问题，部分是合同问题。需要主权或可移植操作的客户不仅应验证数据驻留在何处；还应测试数据如何移动、哪些配置必须更改、需要哪些身份、哪些支持团队可以行动，以及哪些费用或豁免适用。
对于 IBM Cloud，公平的结论很狭窄。公开记录支持许多服务的区域级位置以及符合条件的欧盟账户的文档化支持位置功能。它不支持每个运营依赖关系、专家访问路径、控制平面动作、数据移动或恢复支持活动都保持在所选地理范围内的笼统声明。买家必须检查正在使用的确切服务。
事件将架构转化为证据
云架构文档描述了应该发生什么。事件记录显示了系统的哪些部分实际承受过压力。因此 IBM Cloud 的事件报告和状态历史很重要，不是因为它们让 IBM 看起来特别脆弱，而是因为它们暴露了每个云中重要的普通基础设施类别：电网电力、火灾、冷却电力、设施网络、服务访问和多区域管理路径。
来源遍历发现的事件包括 FRA05 电网停电、首尔火灾、华盛顿停电、SAO01 冷却电源故障和设施网络中断。公开事件列表并未提供排名每个站点所需的所有细节。它们可能受到保留期、摘要和事后语言的限制。但它们仍然比通用的弹性声明更强有力的证据。命名数据中心代码的电网停电是云服务依赖当地电网、开关设备、备份系统和恢复序列的证据。冷却电源故障是计算可用性可能变成散热问题的证据。火灾或设施网络事件是物理访问、安全系统和本地网络可能成为服务依赖的证据。
客户层面的教训是将事件映射到架构。如果工作负载设计为跨完整 MZR 的三个可用区，那么单可用区设施事件不应产生与单服务器设计相同的故障。如果工作负载构建在一个可用区中，带有一条 Direct Link 和一个本地备份，那么同一事件可能变成服务中断、数据恢复练习和支持升级。IBM 的 SLO 和 SLA 文档可以规定信用和指标，但信用不会移动数据、重建服务器或重新打开电路。它们事后分配商业补救。
事件证据也应改变客户阅读骨干多样性语言中“尽可能”的方式。IBM 称其网络使用多样化的提供商和冗余连接。这很有用，但运营商自己的文档并不能证明每个客户路径或每个本地边缘条件。真正的弹性要求将架构层与故障层匹配。具有提供商多样性的骨干网不会在客户唯一的私有入口是单一未受保护的 Direct Link 时拯救客户。三个可用区不会在一切状态都在一个区域卷上且没有经过测试的恢复时拯救工作负载。全球平台服务可以保持活跃，而特定区域配置缺货。
关键不是要求不可能确定的确定性。而是避免将提供商的设计意图替代为客户的证据包。IBM 提供了充足的公开材料用于良好的尽职调查过程：位置代码、可用区映射、故障域指南、Direct Link 边界、容量错误行为、迁移步骤和事件。买家应使用这些事实来测试自己的依赖链。
关闭通知使迁移成为容量问题
CHE01 关闭通知是一份特别有用的文档，因为它从客户侧展示了基础设施现代化。IBM 说 CHE01 将于 2027 年 6 月 10 日停止运营，并设定了从 2026 年 6 月市场结束公告开始的日程。它限制了配置，在后续里程碑移除所有账户的新部署，安排了 2027 年 4 月的网络维护窗口，关闭了迁移援助请求窗口，然后在最终停止之前结束了 PaaS 和 IaaS 迁移窗口。IBM 还表示没有可用延期。
该日程改变了金奈容量的含义。关闭前，CHE01 是 IBM Cloud 库存中的数据中心代码。在关闭过程中，它变成了缩小的服务边界。现有账户可能被允许一段时间，新配置被限制或移除，网络维护造成计划中断，客户必须选择目标位置。IBM 说更新的金奈和孟买位置提供更全面的技术栈和跨 MZR 运营的改进连接。这对长期架构可能有利。但它不会使迁移自动完成。
迁出云数据中心是一系列小物理和逻辑任务。客户必须识别资源、将旧架构映射到新架构、移动数据、构建替换 VPC 资源或经典替代方案、调整 DNS、更改应用端点、安排停机或复制窗口、验证性能、重新配置备份，并更新支持和操作手册。IBM 的经典到 VPC 迁移文档描述了重建和切换，而不是翻转设施标签。其数据迁移材料显示卷和文件数量影响传输时间。Object Storage 移动需要新存储桶和配置。块快照复制对于大卷可能需要数小时。
那么容量问题有两个方面。离开站点需要足够的稳定性持续运行直到客户离开。目标区域需要足够的可用容量、匹配配置、网络访问、存储功能和支持准备来接受工作负载。公开的 IBM 文档没有显示为目标预留了多少 CHE01 迁移容量，或个别客户如何优先排序。该信息可能存在于账户特定通信中，但不在公开证据中。
对于基础设施分析，CHE01 证明了一个更广泛的观点：云提供商可以淘汰地理位置。一个客户因延迟、驻留、价格、硬件配置或私有连接而选择了一个站点，可能必须在不是客户设定的日程下重新选择。最强大的缓解措施不是相信区域会永远存在。而是可移植的架构、经过测试的数据移动、早期库存检查以及使得支持和目标容量在截止日期变成中断之前可见的合同。
严肃买家应验证什么
IBM Cloud 给了买家比许多提供商更好的起点，因为公开文档暴露了机制。因此尽职调查应具体。首先，买家应询问其账户映射到哪些通用可用区名称，而不仅仅是 Terraform 或控制台中出现的逻辑可用区标签。如果工作负载混合了 VPC、经典基础设施和 Power Virtual Server，数据中心代码很重要，因为共置、延迟和故障关联取决于物理映射。
第二，买家应将区域可用性与产品可用性分开。服务部署策略和故障排除页面明确表示并非每个服务、配置、GPU、裸机配置或市场驱动功能在每个区域都存在。如果工作负载依赖硬件配置，客户应验证主要区域和恢复区域的库存和替代方案。如果恢复计划假设在灾难后新鲜配置，应在现实的配额、库存和支持条件下进行测试。如果工作负载无法等待新鲜库存，预配置或预留不是可选的安慰剂；它是设计的一部分。
第三，买家应将私有连接视为其自身的系统。Direct Link 弹性需要至少两个连接、独立的 IBM 侧路由器或多样化的 PoP、尽可能独立的运营商路由、客户 BGP 策略，以及外部设施在到达 IBM 之前不会汇聚的证明。两个会话不是两条管道。两个提供商不自动是两条物理路由。电路订单、LOA/CFA、交叉连接、路由器、路由策略和运营商路径都必须检查。
第四，买家应将数据恢复与计算恢复放在一起。VPC 快照、Object Storage 复制、存储桶副本、文件共享复制和裸机备份产品解决不同问题。另一个区域的快照在稳定后更有用。快速恢复克隆在事件前存在更有用。错误弹性类别的存储桶可能需要在压力下复制。裸机本地磁盘需要客户管理的备份。DNS 和应用状态必须包含，不能视为事后考虑。
第五，买家应将驻留和运营联系起来。如果决策由欧盟、法国、金融、医疗或公共部门要求驱动，客户应验证所选服务条款、支持位置、专家访问规则、全球控制平面依赖关系、数据输出义务和事件程序。物理数据位置缩小风险。它不会消除每个司法、支持或管理依赖关系。
最后，买家应阅读事件记录，不是作为公关噪声，而是作为测试清单。电力中断、冷却电源故障、火灾、设施网络中断、控制平面降级、容量耗尽、迁移截止日期、计费暂停和私有电路故障应各有一个操作手册。如果客户不能说每个案例发生什么，区域选择尚未成为运营设计。
有用的结论比销售地图狭窄
IBM Cloud 的公开证据支持一个强大但有边界的结论。IBM 运营着一个真实的全球云基础设施资产，拥有命名的多可用区区域、单园区区域、经典数据中心代码、公开的可用区映射、私有和公共网络服务、可见的骨干身份、文档化的恢复功能、事件报告和生命周期通知。客户可以用这些证据做出比简单国家或城市标签更物理意识更强的区域决策。
证据不支持更强的声明，即选定的 IBM Cloud 区域自动提供客户所需的容量、物理路径多样性或恢复结果。容量是特定于配置的，并随时间变化。一些服务是市场驱动的。专业硬件是本地的。裸机库存是动态的。经典虚拟服务器配置可能因路由器或数据中心缺乏资源而失败。Direct Link 是进入云的单独路径，没有深思熟虑的重复工程就不是冗余的。分区 VPC 资源在完整分区故障后不会自行移动。单园区 MZR 具有更紧密的物理相关性。数据驻留不会使每个控制平面、支持或法律依赖关系本地化。
这不是 dismiss IBM Cloud 的理由。这是正确定价它的原因。IBM 的文档给买家足够的事实来问具体问题，而不是购买云区域口号。涉及哪些物理数据中心代码？哪些配置有库存？哪些可用区映射到账户？哪些电力和网络事件影响了类似站点？哪些 Direct Link 路径真正多样化？哪些数据副本在其他地方已经稳定？哪些资源已预留？哪些支持层级响应实际威胁工作负载的中断？哪些遗留站点接近关闭？
这些问题的答案才是客户真正购买的基础设施产品。区域名称只是前门。