摘要
- Cloud Management Center 在公共网络记录中与 AS33229 相关联。需要问的有用问题不是该名称是否出现在注册表中，而是该记录是否映射到全球路由系统中可用的、可恢复的客户服务。
- RIPEstat 显示当前有 3 个已通告前缀，包括 170.39.24.0/23、170.39.27.0/24 和 2602:fd2f:10::/44。路由来源检查返回了 3 个有效的路由来源验证结果。这些是正面的网络信号，但并未透露机架数量、电力余量或支持能力。
- 互联证据表明：PeeringDB 名称为 Any2Cloud；一般策略为开放；1 个交换中心连接数；2 个设施数；配置文件中包含 10 个 IPv4 前缀和 10 个 IPv6 前缀。邻居证据显示：AS137409（左）、AS17557（左）、AS6939（左）、AS9583（左）和 AS136565（右）。这些记录有助于定位运营表面，但并不能证明物理路径多样性或商业传输独立性。
- 面向客户的风险在于注册容量与可用容量之间的差距。一个活跃的 ASN 仍可能因单个机架、单个上游、单个远程手操作队列、单个计费锁或单个迁移陷阱而失效；一个休眠的 ASN 仍可能在公开证据无法支持的范围内被营销。
- 证据等级为中等偏强。公共路由面是活跃的，但公司标签、Any2Cloud PeeringDB 名称和目录名称需要仔细区分。公开证据并未公布数据中心合同或客户恢复模式。
云账单终究落在一个物理位置
理解 Cloud Management Center 的最简单方法就是不要停留在“云”这个词上。“云”或“托管”账户是围绕处理器、内存、存储、路由器、地址资源、设施访问以及能够在故障时进行干预的人员的商业包装。公共路由表仅显示该安排的控制平面边缘。它不显示线槽、锁定的机柜、电源馈线、备用光模块或能够在午夜后进入站点的工程师。
对于 Cloud Management Center，可见的边缘是 AS33229。本文使用的公共网络捕获发现当前有 3 个已通告前缀，包括 170.39.24.0/23、170.39.27.0/24 和 2602:fd2f:10::/44。这足以说明存在一个可观察的操作表面，而不仅仅是公司列表中的一个名称。但这不足以说明每个客户工作负载位于何处，或在移除一个组件后还剩多少余量。
托管服务的经济模式是：提供商将混乱的物理资产转化为月费。客户获得一个界面和一张发票；提供商保留机架规划、运营商合同和维修计划。这种交易可能是合理的，但它集中了判断力。当 Cloud Management Center 负责可达性时，客户必须问：当第一条好路径消失时，实际还剩什么可用？
公共证据始于RDAP、RIPEstat 概览、路由状态、已通告前缀、邻居、路由历史、PeeringDB、Cloudflare Radar、BGP.tools、Hurricane Electric、IPinfo、RPKI 验证。这些记录不是营销文案。它们是帮助将活跃的路由足迹与需要合同证据的主张区分开来的机械观测结果。
身份记录有用，但不是服务本身
AS33229 标识一个网络边界。它并不标识 Cloud Management Center 下的每个法律实体、员工、数据机房或产品。这种区别很重要，因为责任可能是分散的。注册表对象可能列出一个持有者，PeeringDB 可能使用一个商业名称，网站可能描述一个更广泛的服务，客户合同可能由另一个关联方签署。
RIPEstat 概览中的持有者标签是 ANY2CLOUD - Any2Cloud。该标签有助于将 ASN 关联到主题，但这不是一个服务级别的承诺。它表明号码资源证据指向何处。它并不表示客户获得的是裸机托管、虚拟机、IP 传输、托管网络服务还是内部企业网络功能。
该名称听起来操作范围很广，但可验证的事实更为狭窄：一个可见的 ASN、几个前缀和互联声明。因此，买家应区分三个问题：谁控制号码资源？当前使用它的（如果有）是哪个服务？当服务故障时，谁承担合同责任？公开数据有助于回答第一个问题。第二个和第三个问题需要实时的技术和商业证明。
这种区分对于托管品牌名称尤其重要。托管术语可能在服务器迁移、客户迁移或 ASN 变为未使用后仍然存在。标签应触发调查，而非替代调查。
不应过度解读路由历史
历史路由证据是有用的，但不应被当作当前容量出售。RIPEstat 列出了首条观测路由 12.184.148.0/24 于 2005-02-19T00:00:00，最后观测路由 2602:fd2f:10::/44 于 2026-07-11T08:00:00。
历史有助于识别连续性风险。一家公司可能因迁移客户、更换上游、出售资产、外包交付或停止服务而停止通告前缀。每种原因对客户都有不同的含义。在没有运营商声明或当前流量证据的情况下，路由收集器无法区分它们。
因此，路由历史视图最宜用作时间线。它可以显示路由是短暂测试、长期运行、间歇性使用还是在特定时期后撤回。它不能证明服务器位于何处、客户是否受到影响，或同一组织是否仍控制着该服务。
对于采购而言，规则很简单：不要用过去的 BGP 购买当前的弹性。历史通告可以支持身份和过往运营。它们不能确定当前容量、备份路径或事件响应。
RPKI 有助于解决来源风险，但不能解决所有故障
路由来源验证提出一个具体问题：AS33229 是否被授权通告给定前缀？对于 Cloud Management Center，验证快照返回了 3 个有效的路由来源验证结果。此处使用的第一个验证 URL 是RIPEstat RPKI 验证。
有效的来源数据很有用，因为它降低了路由被实施路由来源验证的网络拒绝的可能性。它还表明，拥有号码资源控制权的人已采取行政步骤发布授权。对于相同的活跃前缀，这比未知或无效的来源状态要好。
RPKI 并不能解决所有故障。它不能证明服务是快速的、冗余的、本地的、人员充足的或在物理上是多样化的。它不能防止接入光纤中断、上游过载、电源转换失败、防火墙变更错误或等待远程手操作的支持工单。它保护了控制平面的一个切片，而非整个服务。
更广泛的方法由RFC 6811以及APNIC和ARIN的操作材料描述。这些文档解释了为什么来源验证属于弹性对话的一部分，同时也明确了它只是众多控制手段之一。
对等互连和设施线索不是容量审计
PeeringDB API 查询PeeringDB返回：PeeringDB 名称 Any2Cloud；一般策略开放；1 个交换中心连接数；2 个设施数；配置文件中 10 个 IPv4 前缀；10 个 IPv6 前缀。人工页面是PeeringDB 网络页面。
PeeringDB 很有价值，因为它常常暴露互连的实用词汇：策略、交换中心数量、设施数量、大致前缀数量，有时还包括 Looking Glass。对于 Cloud Management Center，这些字段有助于判断公共足迹看起来像是一个孤立的路由块、一个交换中心连接的网络，还是一个更广泛的互连参与者。
但 PeeringDB 不是审计。配置文件可能过时、稀疏或理想化。设施数量并不能保证客户工作负载位于那些建筑内。交换中心连接不能证明付费传输的多样性。诸如开放、选择或限制等一般策略并不说明接受哪些路由、哪些会话具有默认能力，或在故障后如何处理拥塞。
实际用途是将公共配置文件转化为问题。列出的设施中，哪一个实际用于客户接入？是否有两台路由器、两个电源域和两个光纤入口？是否有交换中心路由服务器会话承载关键流量，还是仅用于所选目的地的无结算对等互连？如果设施、交换中心或某个上游不可用，提供商能否保持服务存活？
传输多样性需要证明两次
传输多样性需要在路由层和物理层都得到证明。RIPEstat 邻居视图显示 AS33229 的邻居为 AS137409（左）、AS17557（左）、AS6939（左）、AS9583（左）和 AS136565（右）。这告诉我们公共 BGP 能看到什么，但并未说明这些邻居是上游、对等体、客户还是交换中心学习到的路径。它也没有揭示会话下方的管道或交叉连接。
一个网络可能有两个逻辑上游共享一个建筑入口。它可能有两台路由器使用同一个电源插座。它可能有一个备份传输合同，但在最繁忙时段太小而无法承载流量。它可能有一个看似多样化的 BGP 表，但仍然依赖于一个交换中心交换机、一个远程手操作队列或一个管理跳板机。
因此，客户需要区分术语。路由多样性意味着控制平面有替代路径。运营商多样性意味着不同的商业和运营对手方。物理多样性意味着光纤路径、入口、机架和电源布置不会同时失效。容量多样性意味着剩余路径能够承载关键负载而不丢弃流量。
这正是MANRS和RFC 7454作为有用背景的地方。它们定义了良好的路由行为和操作规范。但它们并未证明 Cloud Management Center 已经购买或测试了客户可能需要的每一条多样路径。
已安装容量并非客户能使用的容量
已安装容量和可用容量在故障期间迅速分化。已安装容量是看似存在的东西：可路由前缀、端口、服务器、存储、传输承诺和设施合同。可用容量是在组件宕机、维护窗口开始或上游撤回路由后仍然有效的东西。可恢复容量是能够在客户的操作截止时间内恢复的部分。
对于 Cloud Management Center，公开证据可以描述地址空间和一些互连线索。它无法告诉我们有多少台虚拟机监控器正在通电、存储如何镜像、是否有备用光学器件和服务器在现场，或者一次可以移动多少客户工作负载。一个具有有效路由和公共配置文件的网络，如果恢复站点规模过小或支持队列过载，仍然可能缺乏可恢复容量。
同样的情况也适用于 IPv6。可见的 IPv6 聚合体可能表明技术成熟度，但它不能证明客户应用程序、监控、支持工具和接入网络同样准备就绪。双栈操作仅在两个栈都得到运行维护且一个栈的故障不会导致关键服务瘫痪时才能增加弹性。
买家应按层询问测量余量：客户接入、汇聚、边缘路由、存储、计算、备份和支持。单一的平均利用率数字过于粗糙。重要的数字是在测试故障期间还剩下什么，而不是在安静时段存在什么。
电源、备件和人员决定维修时钟
物理维修是服务抽象变得具体的环节。如果路由器线卡故障，需要某人有备件和安装权限。如果服务器电源故障，需要某人进入房间。如果交叉连接故障，设施操作员可能控制工单。如果云存储卷不一致，提供商可能需要专家团队而非现场技术员。
公开记录很少公布这些细节，Cloud Management Center 也不例外。这种缺失是正常的，但不应被忽视。购买托管容量的客户也在购买提供商的接入安排、维护合同、供应商关系和人员配置模型。故障时钟在官方事件通知之前就已启动；它从检测、分类和站点接入开始。
维修问题应以操作时间而非宣传语言来询问。从报警到合格负责人的时间是多长？到达设施需要多长时间？哪些部件本地备有库存？哪些维修需要第三方工单？变更窗口是否由处理紧急恢复的同一批人值班？如果支持门户是受影响系统的一部分，客户如何获得通知？
这些问题对于规模较小或区域性的网络尤其重要。大的足迹可以掩盖薄弱的本地流程；小的足迹如果拥有纪律严明的备件、清晰的升级路径和诚实的容量限制，则可能具有韧性。公共路由证据不能决定这个问题。
数据本地化是一个布局问题，而非国家代码
数据本地化常常被简化为公司或 ASN 所属的国家代码。这过于简单。Cloud Management Center 在这里与全球路由系统相关联，但托管工作负载可能将客户数据、日志、备份、管理访问和支持记录放置在多个不同地点。ASN 国家不一定是存储国家、支持国家或法律合同国家。
客户需要一个布局矩阵。主服务在哪里？恢复副本在哪里？备份存储在哪里？哪些供应商可以访问系统？日志和工单存储在哪里？哪个国家的法律管辖访问请求和删除？网络路由可以跨越国界而客户不易察觉，支持工程师可以从与机架不同的管辖区访问系统。
数据主权也有恢复角度。如果提供商故障或客户退出，客户能否以可用格式获取完整数据？在主服务降级期间，是否能够进行导出？导出是否包含文件、元数据、日志和配置，还是仅数据库提取？终止后的导出窗口有多长？
这里引用的公开记录无法回答这些合同问题。它们只能说明这些问题为何重要：地址资源和互连是服务表面的一部分，但客户的操作依赖通常延伸到存储、身份、计费和支持流程，而这些在 BGP 中不可见。
支持条款是基础设施的一部分
支持不是基础设施的软附加项。它是无形故障变为已修复服务的机制。提供商可能拥有有效路由，但如果工单接收缓慢、升级不明确，或者能够进行变更的团队在事件期间不可用，客户仍可能陷入困境。
最重要支持事实是可衡量的。谁可以宣布重大事件？哪些症状符合电话升级条件？状态通道是否独立于生产控制平面？客户是否可以看到路由、设施或存储事件的详细信息，还是仅收到通用中断通知？如果正常控制台不可用，支持人员能否执行数据导出？
计费和账户状态也是基础设施。暂停账户、支付失败、域名过期、控制面板锁定或有争议的支持权利都可能像光纤断裂一样停止服务。托管容量依赖于行政连续性以及技术连续性。
对于 Cloud Management Center，公共网络证据足以证明这些支持问题，但不足以解答它们。这是公开研究的合理边界：它不应发明服务级别，也不应因缺乏公开细节而忽视操作风险。
监控将路由转化为操作信号
AS33229 的实际价值在于它可以被观察。客户可以从多个地点监控前缀集、路由来源验证、邻居变化和基本可达性。这不能取代提供商的监控，但它为客户提供了独立查看公共边缘是否改变的能力。
监控应区分症状。路由撤回不同于服务器中断。一条国际链路上的丢包不同于设施故障。控制面板中断不同于客户工作负载丢失。买家在事件前能越多分离这些层，在事件中损失的时间就越少。
这里使用的公共工具很有用，因为它们处于提供商自身故事之外。RIPEstat、PeeringDB、Cloudflare Radar 和公共 BGP 聚合器各自看到边缘的不同部分。它们之间的一致增加了信心。不一致不一定是故障，但它告诉客户下一步该问哪里。
监控计划也需要所有权。必须有人决定哪个变更重要、谁呼叫提供商、捕获什么证据，以及何时转向备用方案。没有这种操作习惯，公共路由数据就会变得有趣但无用。
变更控制是一个隐藏的依赖关系
托管容量即使客户不触及也会发生变化。路由器接收策略变更、服务器打补丁、证书续期、存储池扩展、过滤器调整、供应商执行维护。每个变更都可能保护服务或引入新故障。客户很少看到完整的变更日历，因此他们需要明确的变更通知和回滚期望。
对于 Cloud Management Center，本次审查的公开记录未公布变更政策。这很正常，但使得合同语言变得重要。客户应了解紧急变更如何批准、是否通知客户影响性维护、是否先在较小群体上测试变更，以及提供商如何沟通回滚。
变更控制也是薄弱的公开证据变得危险的环节。如果提供商无法显示当前路由、设施或支持边界，客户可能不知道存在哪些变更域。上游、设施、经销商或云供应商的变更可能影响服务，即使发票上的品牌名称从未改变。
良好的变更实践不会消除事件。它使事件可诊断。它保留了谁批准了变更、监控看到了什么以及哪些恢复步骤是安全的历史记录。该历史记录是客户购买能力的一部分。
迁移是最终的弹性测试
托管容量的最终测试是客户能否离开。一个仅在提供商健康时有效的服务给客户带来效率，但不是独立性。一个能够导出完整记录、配置和操作证据的服务，即使主平台不可用或商业上不适用，客户也有备用方案。
对于 Cloud Management Center，公共网络层无法显示导出路径。它只能说明它们为何重要。如果提供商的路由边缘、支持渠道或计费系统故障，客户可能需要在压力下移动 DNS、地址、备份、应用程序数据和访问控制。迁移规划属于弹性审查，而不仅仅是终止条款。
客户应询问哪些数据可以在没有专业服务的情况下导出，哪些需要提供商协助，导出保留多长时间，是否包含日志和附件，以及提供商能否在生产事件期间进行导出。在依赖导出之前，应先在小型但完整的工作负载上测试。
迁移不是对提供商的威胁。它表明提供商理解客户的依赖关系。一个有弹性的托管服务应使客户在故障期间更有能力，而非更受困。
买家应如何测试声明
买家应从证明活跃服务开始。询问哪些面向客户的服务使用 AS33229，哪些前缀分配给产品，以及是否也涉及提供商分配或云提供商地址。将答案与RIPEstat 已通告前缀以及独立观测结果（如BGP.tools或Hurricane Electric）进行比较。
然后询问站点模型。提供商应标识生产设施或云区域、恢复站点、备份位置和网络入口。应说明站点是主动-主动、主动-备用还是仅备份。应解释当一个站点被隔离时会发生什么，以及恢复后如何协调客户数据。
第三，询问测试结果。从未转移过流量或恢复过工作负载的弹性计划只是一个假设。客户应查看近期演练日期、测量恢复时间、数据丢失结果、事件沟通样本，以及任何对第三方远程手操作或云支持的依赖。
最后，询问退出证据。提供商应演示客户如何检索数据、在其他地方重建服务，以及在托管服务降级时保持基本记录可用。没有这些证据，客户拥有依赖关系，但没有实际退出的途径。
证据等级
Cloud Management Center 在本文中获得中等偏强的证据等级。该等级不是对公司质量的判断。它是对公开证据能够支持什么的判断。这里，有用的公开事实包括 AS33229、3 个当前已通告前缀（170.39.24.0/23、170.39.27.0/24 和 2602:fd2f:10::/44）、3 个有效的路由来源验证结果、PeeringDB 名称 Any2Cloud、一般策略开放、1 个交换中心连接、2 个设施、配置文件中 10 个 IPv4 前缀和 10 个 IPv6 前缀，以及邻居证据 AS137409（左）、AS17557（左）、AS6939（左）、AS9583（左）和 AS136565（右）。
事实显示了一个依赖候选，在当前路由情况下显示了一个操作表面，但未达到弹性证明的程度。公共路由可见性可以告诉客户从哪里开始测试；它无法显示每个机架、电源馈线、备件、支持人员名单或合同边界。这个差距就是为什么托管容量采购应以证据为主导而非品牌为主导的原因。
实际结论是狭窄且有用的：公共路由面是活跃的，但公司标签、Any2Cloud PeeringDB 名称和目录名称需要仔细区分。公开证据并未公布数据中心合同或客户恢复模式。客户应将可见的网络足迹视为初始地图，而非完整的保证报告。
该公司很重要，因为故障不会是抽象的。如果托管服务或网络边缘故障，客户可能失去可达性、管理访问、数据移动、计费控制或迁移选项。公开记录有助于命名这种依赖；合同和测试必须证明它如何存活。
谁感受到故障
Cloud Management Center 的最直接用户可能是客户管理员、经销商、开发者、远程员工或依赖该托管边缘的其他网络运营商。然而，故障的影响很少止于第一个看到超时的人。路由撤回、存储故障或支持延迟可能停止配置、监控、发票访问、软件部署、客户门户、备份或旨在降低其他风险的迁移。
这种传播就是为什么小基础设施名称值得关注。一个有限的可视前缀集仍可能承载管理服务或面向客户的端点。一个小的支持团队仍可能成为短事件与一天临时工作之间的区别。稀疏的公开记录仍可能存在于下游公司视为常规且无形直至故障的服务之下。
对于全球路由系统中的客户，品牌与基础设施之间的距离尤其重要。AS33229 所属的国家或地区并不自动告诉客户数据位于何处、使用哪条运营商路径、哪个法院或监管机构重要，或者本地支持渠道能否在不等待其他供应商的情况下行动。故障首先是操作性的，然后才是法律或合同性的。
实际问题不是每个依赖都是坏的。托管服务之所以存在，是因为共享基础设施可能比许多客户自有系统更便宜、人员更充足、更安全。实际问题在于客户是否知道自己已经接受了哪个依赖，以及提供商能否演示恢复，而不仅仅是描述可用性。
公开证据如何误导
公共网络证据之所以强大，是因为它独立于销售宣传。但它也容易被过度解读。AS33229 可见，而客户服务可能实际运行在另一个网络上。一个前缀可能被通告，但仅管理组件使用它。PeeringDB 配置文件可能由技术联系人维护，但不反映当前客户产品。一个休眠的 ASN 可能在基础服务已迁移后仍保留在记录中。
最安全的解读方式是分层的。注册表证据支持身份。路由收集器证据支持某一时刻的公共可达性。路由来源验证支持一种路由授权形式。PeeringDB 支持互连发现。这些层中单独一层都不能证明站点冗余、可用计算、存储持久性、客户布局、帮助台权限或导出就绪性。
这种分层解读既保护了 Cloud Management Center，也保护了读者。它避免仅因公司保持设施细节私密就指责其弱点。它也避免因某一公共层看起来健康就给公司不应得的弹性信用。公共证据应使下一个问题更尖锐，而非将答案变成口号。
自律在于清晰地陈述不确定性。当前路由就是当前路由。有效来源就是有效来源。邻居就是观测到的邻居。设施数量就是目录字段。这些术语有用，因为它们狭窄。一旦它们被延伸为更广泛的保证，读者就失去了证据的价值。
供应商边界决定恢复
托管服务可能在提供商拥有的部分、租赁的部分或供应商操作的部分中故障。这种区别很重要，因为维修路径不同。提供商拥有的路由器可能由其自己的工程师修复。托管电源事件可能依赖建筑人员。云配额或存储事件可能依赖超大规模支持渠道。光纤故障可能依赖运营商和民事维修队。
围绕 Cloud Management Center 的公开记录并未揭示这些供应商边界。这就是为什么买家应索要责任地图而非通用正常运行时间承诺的原因。地图应说明谁控制设施、谁控制路由器、谁控制存储、谁控制备份、谁控制 DNS、谁控制身份、谁可以批准紧急变更。
供应商边界也是财务边界。提供商可能拥有强大的技术能力，但仅拥有有限的设施或上游支持权利。客户可能与提供商有强有力的合同语言，但无权直接对抗实际控制故障组件的供应商。恢复继而依赖于升级关系，这些关系在公共路由数据中不可见。
最透明的提供商将这些边界作为服务的一部分。他们能够解释哪些是内部的、哪些是外包的、哪些承诺有延续、哪些没有，以及在供应商成为瓶颈时他们如何保持客户知情。这种解释是一种能力形式，因为它减少了故障期间因混乱而损失的时间。
恢复需要演练
从未执行过的恢复计划只是理论。演练不一定是戏剧性的。它可以是一次受控的故障转移，涉及一个客户工作负载、从备份恢复到隔离环境、一次路由撤回测试、一次支持升级演练或一次数据导出预演。重要的是提供商已测量时间，且客户看到了什么会出问题。
对于 Cloud Management Center，公开证据无法显示演练结果。因此，客户应直接请求它们。有用的证据是近期、具体且谦逊的：测试了什么、什么出错了、改进了什么、恢复花了多长时间、丢失或重放了什么数据、以及客户需要采取什么行动。一个光鲜的高可用性声明不如一份坦诚的演练报告有用。
演练也暴露了隐藏的序列。备份可能恢复很快，但需要 DNS 更改。路由可能故障转移很快，但监控仍指向旧地址。支持团队可能知道技术修复，但无权联系设施。客户可能拥有数据，但缺乏在降级模式下操作的人员培训。这些不是边缘情况。它们是恢复的正常纹理。
找到这些依赖的最佳时机是在事件之前。一旦客户离线，每个缺失的权限、过时的联系人和未记录的步骤都会变得更加昂贵。演练将弹性从承诺转变为经过实践的操作习惯。
狭窄的结论更有用
Cloud Management Center 的狭窄结论比宽泛结论更强，因为它可以被测试。公开证据识别了 AS33229，提供了路由和注册表基线，显示了哪些互连数据可见或不可见，并框定了客户在将该服务视为弹性托管容量之前必须回答的问题。
该结论不需要对隐藏资产有确定性。不需要猜测设施或发明客户。它只是认识到现代基础设施通常将物理层隐藏在服务标签之后，而公共网络数据可以重新打开该层足够的部分，以便严肃的买家提出知情的问题。
剩余工作属于提供商和客户。提供商必须展示当前服务布局、路径多样性、支持权限、恢复演练和数据导出。客户必须决定它能容忍哪些故障、哪些必须通过合同转移、以及哪些必须用自己的备用流程处理。
如果这些证据到位，证据等级可以改进。如果没有，公开记录应保持为依赖地图，而非弹性证书。这不是一个胆怯的结论。这是唯一尊重证据价值和局限的结论。
下一步关注什么
Cloud Management Center 的下一个公共变化应是具体的：新增或撤回的前缀、AS33229 的不同持有者标签、PeeringDB 更新、路由来源验证更改、新的可见邻居，或者命名生产地点和支持职责的网站及服务页面。每一个都将改变足迹的实际解读。
买家还应关注沉默。如果配置文件保持过时而提供商营销增长，那么差距本身就成了问题。如果路由发生变化但客户通知未变，客户应询问该移动是否经过规划、测试并按协议覆盖。
最强的未来证据将结合公共和私人证据：当前 BGP、有效的路由来源授权、维护的互连记录、命名的设施、测试过的恢复以及数据导出演示。在证据汇编完成之前，最安全的立场是自律的好奇心。
用简单术语进行运营尽职调查
Cloud Management Center 的简单尽职调查测试是要求证据遵循依赖关系，而非仅仅重复品牌。客户应能指出其购买的服务、承载它的地址或上游服务、托管它的地点或提供商类别、修复它的支持路径、以及允许客户离开的导出路径。如果其中任何一条模糊，风险只是移出了视线。
同样的测试应在重大变更后重复。新的上游、不同的设施、修订的支持计划、新的备份目标、变更的计费平台或变更的产品名称都可能改变风险状况，而不改变头版服务。客户常常在中断期间才发现这些变化，此时实际问题不再是承诺什么，而是谁可以行动以及多快。
一个好的提供商无需向公众暴露敏感图示即可回答。它可以共享保密架构说明、当前责任矩阵、近期恢复演练、状态通道设计以及数据返回程序。它还可以解释它不会承诺什么。这种诚实很有价值，因为它让客户决定要复制、投保、监控或接受什么。
对于 Cloud Management Center，公共网络证据提供了起始地图。该地图很有用，因为它标识了公共边缘及其周围的空白。如果被当作整个领域，它就没有用。公开记录应启动一个关于路由可见性、站点布局、电源、传输、支持和退出的实际对话。它不应结束那个对话。