摘要
- Green Cloud Technologies,LLC 的运营证据比一个休眠的托管标签要多：ARIN 将 AS54155 与 Green Cloud Technologies,LLC 关联，RIPEstat 的 2026 年 7 月视图显示其有活跃的 IPv4 公告、广泛的路由可见性和六个观察到的邻居。然而，路由表面在证明可通达性方面，比证明站点多样性、备用硬件深度或客户恢复能力方面要强。
- 最有力的公司证据是历史性和交易性的。11:11 Systems 表示，它在 2021 年 12 月完成了对 Green Cloud Defense 的收购，将 Green Cloud 描述为一家大型的纯渠道独立 IaaS 提供商，并列出在亚特兰大、格林维尔、休斯顿、明尼阿波利斯、纳什维尔和凤凰城的数据中心。这一证据是真实的，但目前的客户需要的是一份当前的交付点安排，而不仅仅是一份收购时的城市列表。
- Green Cloud 的路由资产看起来是混合的。ARIN 的 RDAP 记录将一些前缀直接关联到 Green Cloud，而当前公告的其他地址块则指向 Cirrity、ipHouse、Advanced Network Solutions 或带有 INAP 分配的 Green Cloud 记录。这与收购、租赁容量和继承的基础设施相符，但也意味着在弹性审查中，所有权、设施访问权限和支持责任必须分开考量。
- 公共互联故事并不完整。RIPEstat 看到的邻居 ASN 包括 Cogent、Level 3、Zayo、Hurricane Electric、Megaport 和 Unitas，而 PeeringDB 没有返回 AS54155 的 Green Cloud 网络配置文件，并且采样的 RPKI 检查返回未知状态。这些差距本身并不表示服务弱；它们标记了必须通过合同证明的部分。
- 证据等级为中等，而非强。Green Cloud 的公开记录支持一个活跃的云和网络运营表面，但该品牌已整合到 11:11 中，Green Cloud 特定的运营地图已经过时，恢复取决于设施、传输、支持和数据导出细节，而公开页面只部分披露了这些信息。
云标签背后是硬件业务
Green Cloud Technologies,LLC 是一个例子，说明为什么托管容量应该从机架往外读，而不是从品牌往里读。该公司通过合作伙伴销售云基础设施。客户看到的是一个虚拟机、桌面、备份存储库、恢复目标或托管安全包装。底层的运营义务则更加具体：建筑、电力、冷却、机柜、管理程序、存储架、路由器、交叉连接、传输合同、监控系统和技术人员。
公开的身份踪迹始于号码资源。ARIN 对 AS54155 的 RDAP 记录显示名称为 GREENCLOUD，并列明 Green Cloud Technologies,LLC 为注册人。RIPEstat 的 AS 概览使用持有者标签“GREENCLOUD - Green Cloud Technologies,LLC”，并在其 2026 年 7 月的视图中将该 AS 标记为已公告。这比一个过时的网站更有力，因为它显示了与法律名称相关联的活跃互联网控制面存在。
但这仍不足以购买弹性。一个自主系统号码只能说明全球路由中出现的源头。它不能说明哪座建筑承载着客户的工作负载，两台路由器是否位于独立的防火区，第二条传输承诺能否承载峰值负载，或者现场是否有备用磁盘和更换服务器。AS54155 可以建立一个边缘；但它本身不能建立恢复承诺。
品牌历史之所以重要，是因为 Green Cloud 从一个独立的渠道云转变为更大的托管基础设施平台的一部分。11:11 Systems 宣布完成对 Green Cloud Defense 的收购是在 2021 年 12 月，并将 Green Cloud 描述为一家渠道专有的 IaaS 提供商，服务管理服务提供商、增值经销商和 IT 顾问。同一份公告还提到，这些合作伙伴为 2,000 多家企业提供服务，并列出在亚特兰大、格林维尔、休斯顿、明尼阿波利斯、纳什维尔和凤凰城的数据中心。对买手来说，这些事实意味着爆炸半径不仅限于 Green Cloud 的直接客户列表。它还波及下游企业，这些企业可能更熟悉当地的 MSP，而不知道背后基础设施运营商的名字。
这使得 Green Cloud 成为一个依赖倍增器。当直接云提供商发生故障时，客户通常看到的是供应商的名字。当渠道云发生故障时，首先可见的可能是打包服务的 MSP、经销商或顾问。合同的支持路径可能需要经过多个层级，才能到达能够更改路由、更换硬件或批准迁移的人员。这就是为什么 Green Cloud 的真实运营表面不仅仅是 AS54155。它是 AS54155 加上合作伙伴渠道、支持队列、继承的平台组件以及当前 11:11 的交付点策略。
Green Cloud 当前证据是活跃的，但不简单
最有用的路由快照不是公司口号，而是公共路由状态。RIPEstat 对 AS54155 的路由状态在本文使用的 2026 年 7 月的视图中，显示了 30 个 IPv4 前缀、8,192 个 IPv4 地址、在该输出中报告的 RIS 对等点之间的完整 IPv4 可见性、没有可见的 IPv6 公告，以及六个观察到的邻居。RIPEstat 的已公告前缀视图包括诸如 162.218.104.0/22、198.71.76.0/22、207.200.176.0/23、45.42.134.0/24 等区块以及许多单独的 /24 路由。
这些不是修饰性的事实。三十个当前 IPv4 前缀意味着有一个活跃的路由表面可供测试。广泛的收集器可见性意味着在公开观察时该路由不仅仅是本地或私有的广告。同一视图中没有可见的 IPv6 也是一个有用的限制：不应从云标签推断双栈就绪。依赖 IPv6 可通达性、仅 IPv6 监控、双栈故障转移或公共部门采购要求的客户需要当前的产品证据，而不是一个模糊的说法说现代云提供商会具备。
地址记录也显示为什么一个干净的单公司叙事会误导人。ARIN 对 162.218.104.0 的 RDAP 记录指向一个 Green Cloud 区块。ARIN 对 198.71.76.0 的 RDAP 记录也指向 Green Cloud。但其他已公告的地址范围带有不同的线索：207.200.176.0指向 Advanced Network Solutions，162.244.152.0指向 Cirrity，而一些带有 INAP 分配记录则带有 Green Cloud 标签。这种模式符合一个通过收购、分配和租赁基础设施进行积累或运营的提供商，而不是拥有单一同质地址资产的提供商。
Cirrity 的线索尤为重要。公开报道来自VMblog 关于 Green Cloud 收购 Cirrity 的文章将 Cirrity 描述为一家亚特兰大的云服务提供商。如果一个当前由 Green Cloud 发起的公告前缀追溯到 Cirrity，这并不能自动证明任何当前的工作负载放在哪里，但它解释了为什么 Green Cloud 容量应作为继承资产进行审查。收购的平台通常带来独立的存储设计、不同的管理程序版本、不同的供应商合同、不同的客户义务和不同的维护传统。整合可以改善服务；也可能留下隐藏的接缝，只有在发生故障时才会暴露。
这是对强评级的第一层降级。Green Cloud 在互联网上是可见的。它不是一个纯粹的纸上公司。但是，当前的路由表是一个混合的地图，而公开证据不允许外部人士准确地说出每个客户工作负载背后的城市、机架、供应商或云集群是什么。
六城市列表有用，但不是交付点保证
2021 年收购公告是 Green Cloud 最清晰的公开城市列表。11:11 列出 Green Cloud 在亚特兰大、格林维尔、休斯顿、明尼阿波利斯、纳什维尔和凤凰城的数据中心。BusinessWire 的收购公告和PRNewswire 关于 Tiger Infrastructure 的投资组合公司 11:11 Systems 收购 Green Cloud 的新闻稿强化了相同的战略故事：Green Cloud 正在被整合到一个更大的连接、云和安全平台中。
城市列表很有价值，因为它将分析从模糊的“美国云”标签转移到一组物理市场。亚特兰大是东南部主要的连接枢纽。格林维尔提供了南卡罗来纳州的总部和区域运营背景。休斯顿、明尼阿波利斯、纳什维尔和凤凰城在电力、风暴、人员配备、运营商密度和客户延迟方面是实质上不同的风险区域。在这六个市场都有节点的单一提供商可能提供有用的交付点选择。但在各个节点之间，其深度可能不均衡。
该列表并不是任何单独账户的交付点保证。一个 MSP 客户的虚拟服务器可能放在一个城市，而备份放在另一个城市。灾难恢复目标可能已预留但规模不足。桌面即服务池的放置可能根据支持实践而不是数据主权偏好。安全服务可能将日志或票据存储在与计算服务不同的平台上。在没有当前报价、服务时间表或架构展示的情况下，旧城市列表应被视为待验证的地理范围，而不是可依赖的承诺。
11:11 当前的覆盖范围扩大了背景。其云区域页面称公司在全球运营超过 25 个设施，数据安全、稳定性和主权是其云姿态的核心。该页面还列出了在亚特兰大、芝加哥、达拉斯、洛杉矶、纽约市、圣何塞、斯科茨代尔和多伦多等主要城市的北美数据中心，以及弗吉尼亚州和新泽西州等其他州的地点。这表明母公司的覆盖范围比历史上的 Green Cloud 地图更大。
对于数据主权而言，更大并不自动意味着更好。一个更广泛的平台可以提供更多的恢复选项和更多的本地交付点选择，但也可能模糊哪些需要满足的旧 Green Cloud 承诺仍然映射到哪些当前的 11:11 区域。客户应要求提供一份确切的交付点矩阵：生产计算、复制存储、备份、快照、管理平面日志、工单记录、安全遥测以及任何跨境的支持访问。相关的国家不仅是公司在美国的注册地；它是客户数据、元数据和运营访问可能存在的每一个地方。
服务组合指向容量销售商，而不仅仅是网络
Green Cloud 旧有的公开描述和 11:11 当前的产品页面都指向托管容量，而不是简单的连接。2021 年的收购材料将 Green Cloud 描述为一家提供备份、灾难恢复、桌面即服务和托管安全服务的 IaaS 提供商。11:11 的云概览现在描述基于 VMware 的公共和私有云托管、迁移支持、安全、合规和备份。11:11 托管私有云强调单租户私有云、迁移支持、预构建和定制配置、专用服务器、存储选择和 N+1 弹性模型。11:11 灵活云环境和主机代管将这种语言扩展到裸机、主机代管、低延迟网络、监控和全天候支持。
这是一个物理资产的故事。一个私有云需要足够的专用服务器库存来满足承诺的块。裸机服务需要实际的硬件备件、固件管理以及能够接触机器的支持人员。VMware 服务需要许可、管理程序生命周期管理、存储兼容性和迁移工具。主机代管扩展需要设施、笼子或机架、交叉连接订购、远程手和电力容量。客户购买一个抽象；而提供商运营硬件和合同业务。
11:11 私有云页面的 N+1 语言有帮助，但不完整。N+1 可以意味着集群内有一个额外的组件、一个额外的电源单元、一个额外的主机、一个额外的阵列控制器或更广泛的设计理念。它不一定意味着双站点故障转移、每种故障下的完全在线迁移，或能够吸收整个城市中断的能力。客户应询问哪一层具有 N+1 保护：计算主机、存储控制器、汇聚交换机、边缘路由器、电力馈送、冷却、备份存储库和支持人员。正确的答案因工作负载而异。一个小的 web 服务可能只需要自动重启和足够的带宽。一个受监管的数据库可能需要同步或谨慎治理的复制、审计跟踪、保留保证和文档化的退出程序。
这一区别很重要，因为 Green Cloud 历史上的渠道模型会使容量感觉比实际更具弹性。一个合作伙伴可以快速销售服务。基础设施运营商只能部署、保留和修复它实际拥有的东西。当硬件库存、机架电力或传输余量变得稀缺时，故障并不是市场营销上的失败。它表现为缓慢的配置、延迟的升级、受限的恢复窗口、维护延期或需要平台团队的支持工单。
SLA 展示了客户的暴露面
对 Green Cloud 最实用的公开文件之一是较早的Green Cloud Technologies 服务等级协议和维护政策 PDF。它已注明日期，未经确认不应视为当前合同，但仍然是了解 Green Cloud 如何界定故障边界的实际窗口。该文档描述了围绕 Green Cloud 自有基础设施的服务可用性、计划维护、灾难恢复层和支持优先级。它还排除了提供商控制之外的部分，如客户端网络和更广泛的互联网依赖性。
这种结构对于托管提供商来说是正常的，这也正是为什么客户应该仔细阅读边界的原因。如果服务在 Green Cloud 的边缘内部是可以到达的，但客户的 ISP 路径中断，云可能被当作可用而客户却处于停机。如果虚拟环境正常运行但特定的应用程序配置错误，基础设施提供商可能不拥有应用程序中断的责任。如果计划了一个维护窗口，受影响的服务可能不可用，但不会产生与计划外故障相同的补救措施。实际的问题不是 SLA 是否使用了高可用性百分比。而是哪些故障算数，哪些不算，以及谁在中间承受运营痛苦。
同一文档的支持模型提醒人们，劳动力是容量的一部分。优先级 1 的问题获得最快的关注；较低严重性的问题可以等待。非工作时间的紧急支持侧重于关键事件。维护被视为服务寿命的正常部分。换句话说，支持不是一个无限的工程师池。它是按严重性、时间表和权限配给的。这是理性的，但当一次恢复、迁移或交叉连接变更落在最高优先级以下时，即使客户自己的业务承受着压力，它也会成为客户风险。
11:11 当前的支持页面延续了更大范围的支持边界主题。它列出了全球支持电话号码、账户和控制台链接，以及云服务、安全服务、连接服务和计费的单独联系方式。这种区分在操作上是有用的，但它也告诉客户要提前映射故障所有权。一个源自 Green Cloud 的工作负载可能通过计算、安全、连接、计费或访问管理失败。每条路径可能有不同的队列和升级实践。
计费路径值得关注，因为云故障不仅仅是技术性的。一个被暂停的账户、合同争议、许可证不匹配、耗尽的预付余额或失败的付款方式都可能造成一个看起来像基础设施问题给最终用户的停机事件。一个有渠道合作伙伴的提供商增加了另一层：最终客户可能向 MSP 付款，MSP 可能向上游平台付款，任何一层的争议都可能影响服务连续性。因此，弹性审查应该包括计费升级和账户控制规则，而不仅仅是备份和路由图。
传输多样性是暗示的，而非证明的
RIPEstat 的ASN 邻居视图对 AS54155在本文使用的 2026 年 7 月数据中观察到了六个邻居。这些 ASN 对应到大型或与基础设施相关的名称：Cogent、Level 3、Zayo、Hurricane Electric、Megaport和Unitas。在公开路由视图中看到多个上游比只看到一个孤独的上游要好。
但 BGP 邻接和物理多样性是不同的东西。一个路由收集器可以看到邻居，但并不能告诉买家这些邻居是完整的传输提供商、部分对等、交换路由、私有互联还是继承的会话。两个看似不同的上游可能通过同一个汇接室进入同一栋建筑，甚至依赖于同一条城域光纤断裂。一个 Megaport 会话对于软件定义互联可能很有价值，但它仍然依赖于底层的访问路径、端口、平台和远程端点。一个提供商可以拥有多个逻辑路径，但仍然脆弱于一次设施中断、一个交叉连接积压或一次变更控制错误。
PeeringDB 通常有助于填补部分空白，因为它通常列出设施、交换点、对等政策和流量提示。而在 Green Cloud 的案例中，对 AS54155 的 PeeringDB API 查询没有返回网络配置文件。PeeringDB 中的缺失本身并不是失败。许多合法的提供商并不保持资料的更新。然而，这移除了一种运营商维护的来源，该来源本可以澄清互联站点、流量政策或设施附件。这是证据等级停留在强以下的另一个原因。
路由起源安全在公共检查中同样不完整。对 AS54155 和 162.218.104.0/22 的采样RIPEstat RPKI 验证查询返回未知状态，因为该响应中没有出现验证过的 ROA。对另一个当前前缀的第二次查询产生了同样的未知结果。未知的 RPKI 状态并不证明路由错误，也不意味着路由不可用。这意味着依赖严格路由起源验证的客户应询问对于实际承载其服务的前缀是否存在 ROA，如果不存在，运营者的路由安全计划是什么。
网络可见性页面，如BGP.tools 对 AS54155、Hurricane Electric 的 BGP Toolkit和IPinfo 的 AS54155 页面是有用的交叉检查，但它们有相同的限制。它们显示可通达性和路由元数据。它们不审计机架电力、路由多样性、恢复程序或每个会话背后的商业义务。
收购改善了到达，也增加了整合风险
Green Cloud 在 11:11 之前并没有停滞。该公司通过收购和安全服务分层进行了扩张。11:11 关于 Green Cloud 达成收购 Cascade Defense 最终协议的档案页面以及后来的Green Cloud 收购并重新品牌的公告展示了该公司如何从纯粹的云基础设施向托管安全迈进。MSSP Alert 对 Cascade 的报道将该交易置于托管安全提供商市场中，而MSSP Alert 对 11:11 收购的报道则将 Green Cloud 的云和安全平台与 11:11 更广泛的战略联系起来。
收购本身并不具有风险。它们可以带来资本、自动化、新产品、更好的安全实践和更深厚的支持。11:11 的收购公告称，合并将为 Green Cloud 的全国渠道合作伙伴网络增加连接和安全能力。它还提到了交易后的技术和领导连续性，这对运营交接很重要。
风险在于，收购的资产往往老化得不均匀。一个被收购的云可能使用不同的存储复制、不同的工单系统、不同的防火墙标准、不同的备份栈或不同的一组设施合同。安全服务可能有它们自己的日志和监控依赖。渠道合作伙伴可能在上游平台正在被合理化的时候，依然根据旧习惯进行销售。一个客户如果只问提供商是否“现在是 11:11 了”，可能会错过更重要的问题：到底哪个旧平台承载着这个工作负载？
这就是为什么 Cirrity 和 Cascade 的历史对弹性审查很重要。Cirrity 解释了部分云和地址继承。Cascade 解释了托管安全层。11:11 解释了当前的母平台。这些事实都不坏；总之它们意味着客户应要求一张地图。这张地图应将命名的服务连接到物理站点、地址块、上游路径、备份目标、安全监控栈、支持队列和合同实体。
供应商合作伙伴关系显示平台形态
Green Cloud 公开的技术引用支持了一个真实的托管容量平台的图景。思科数据中心博客关于 Green Cloud 使用思科 UCS S 系列描述了该公司使用思科服务器基础设施以支持新的业务线。VMware 云提供商博客对 Green Cloud Defense 的介绍将该公司置于 VMware 的云提供商生态系统中。11:11 的云概览现在继续采用了基于 VMware 的框架。
这些引用很重要，因为它们将讨论从纯虚拟化的语言转移开。VMware 云运行在主机、集群、数据存储、管理服务器、许可协议和补丁周期上。思科 UCS 环境具有矩阵互联、服务器配置文件、固件依赖和存储选择。Fortinet 和托管安全服务有传感器、日志导入路径、分析师和升级规则。每一层在管理得当的情况下可以增强服务。每一层也可能引入自身的维护窗口或单点运营失败。
公开的技术合作伙伴提及并不是容量审计。它们不说安装了多少台服务器，保留了多少台，对特定客户的存储是全闪存还是混合，或者在每个城市更换故障主机的速度有多快。然而，它们确实告诉买家该问什么。客户应该询问其工作负载是运行在 VMware Cloud Foundation、vCloud Director、旧有的 VMware 栈、专用裸机上还是主机代管平台上。它应该询问备份是否与生产在同一个存储系列上。它应该询问管理访问是否依赖于独立的控制网络。它应该询问许可变更，特别是在 VMware 生态系统中，如何影响价格或迁移时间。
同样的原则适用于安全。一个有人员的托管防火墙、SIEM 或端点服务可以在有人员配备和集成的情况下降低风险。它也可能造成对安全平台自身可用性的依赖。如果安全管理平面失败，客户还能改变防火墙规则吗？如果 SIEM 导入路径延迟，谁会注意到？如果服务通过 MSP 转售，谁接收警报，谁有权批准遏制措施？
渠道客户继承分层问责
Green Cloud 的渠道专有导向不是一个脚注。11:11 的收购公告描述了一个由超过 700 个 MSP、VAR 和 IT 顾问组成的全国性渠道合作伙伴网络，服务超过 2,000 家企业。这意味着许多受影响的最终用户可能不将 Green Cloud 作为直接供应商来体验。他们可能将其体验为当地技术提供商的云、备份或安全服务。
渠道分销改变了事件行为。一个下游业务可能致电 MSP。MSP 可能向 11:11 或旧有的 Green Cloud 支持路径开一张工单。11:11 可能需要涉及云、连接、安全或计费团队。然后，可能需要一个设施提供商、运营商或硬件供应商来采取行动。每次交接都会花费时间。每一方可能有不同的可见性和不同的权限。在一次小事件中，这种分层可能是不可见的。在一次区域中断、迁移或计费锁定期间，它可能成为可衡量恢复和数日不确定性之间的区别。
降低这种风险的最佳方式是在故障前定义升级路径。最终客户应知道哪一方可以批准恢复，哪一方可以授权故障转移，哪一方可以导出数据，哪一方可以更改 DNS，哪一方可以配置替换容量，以及哪一方可以与受影响的用户沟通。MSP 应知道他们是否拥有控制台访问、API 访问、紧急电话访问和非工作时间的变更权限。平台运营商应知道哪些渠道合作伙伴拥有关键账户，以及哪些账户需要特殊的恢复计划。
公开信息表明，渠道模型是 Green Cloud 增长的核心。Green Cloud 的Inc. 5000 简介以及 11:11 的存档页面庆祝 Green Cloud 第五次登上 Inc. 5000 榜单更佐证了该公司是一个增长阶段的基础设施销售商，而不是静态的企业 IT 部门。增长可以是积极的，但在基础设施领域，它提出了一个容量问题：支持、硬件库存、自动化和恢复测试是否随着合作伙伴基础的扩大而扩展？
维护窗口是产品的一部分
托管服务通常销售连续性，但它无法避免维护。固件更新、管理程序补丁、安全更新、路由器维护、存储控制器更换、备份平台升级和物理修复都需要计划内工作。Green Cloud 的 SLA 和维护文档通过描述维护窗口和服务优先级处理使这一点可见。再次强调，该文档应根据 11:11 当前条款进行确认，但运营现实对任何提供商都成立。
实际的问题在于维护如何与客户恢复相互作用。如果生产和备份在同一个窗口内被维护，一个失败的变更可能影响两者。如果在维护期间暂停存储复制，恢复点目标可能拉长。如果一次网络变更同时触及主路径和备用路径，一个隐藏的公共依赖可能会出现。如果一个维护事件通过同样受影响的网页门户告知，客户可能同时失去服务和状态可见性。
公共状态聚合器如StatusGator 的 Green Cloud Technologies 页面、Rootly 的外部状态页面列表和Netbeep 的 Green Cloud Technologies 状态页面是非官方的信号。不应将其视为权威的事件历史。它们确实暗示外部观察者跟踪多个 Green Cloud 服务组件，且维护/故障沟通是客户体验服务的一部分。能够解决该问题的证据是运营商控制的状态存档、当前维护政策和客户通知条款。
维护还带来了数据可移植性问题。客户通常在系统健康时测试备份，然后在故障期间发现导出速度比预期慢、完整性不如预期或更多权限限制。一个恰当的 Green Cloud 或 11:11 弹性审查应包括对最大重要工作负载的计时导出，而不仅仅是在同一平台内从备份恢复。数据导出是一个物理和运营任务：数据必须从存储中读取，通过网络移动，以可用格式打包，并交给有权限在别处使用它的人。
数据本地性取决于记录、日志和恢复副本
Green Cloud 的美国服务区标签是合理的，但数据本地性不应止于国家标签。历史的数据中心列表以美国为基础。当前的 11:11 云覆盖全球。该公司销售云、备份、灾难恢复、托管安全和连接服务。每项服务可能将不同的数据放在不同的地方。
受监管的客户应询问六个位置，而不是一个。第一，主计算实例或裸机主机在哪里？第二，保存生产数据的存储阵列在哪里？第三，备份和快照存储在哪里？第四，灾难恢复容量是在哪里预留或预配的？第五，日志、监控记录和安全遥测驻留在哪里？第六，支持工单和远程管理会话起源于哪里？
答案之所以重要，是因为云本地性可能按类别失效。客户可能将生产数据放在亚特兰大，一个备份副本放在凤凰城，安全日志放在母公司的平台中，计费数据在另一个系统中，支持访问来自多个国家。这些没有一项是自动错误的。它甚至对弹性有用。但它需要披露，以便客户可以决定该交付点是否符合隐私、合同、保险、客户承诺和行业规则。
11:11 的云区域页面说，公司专注于数据安全、稳定性和主权，并强调有保证的物理驻留。这是一个有用的承诺，值得测试。买家应该询问书面机制：该保证是按区域、国家、设施、云产品还是客户合同适用？它是否包括备份？它是否包括日志？它是否包括托管安全遥测？它是否在灾难恢复故障转移后仍然有效？它是否在支持升级后仍然有效？
故障路径是机架、路由、修复、合同和退出
Green Cloud 最重要的故障路径不是一个灾难性场景。它是一条链条。客户工作负载位于一个物理平台上。它通过 AS54155 或母/合作伙伴路径到达用户。它依赖于存储和备份策略。它通过渠道路径和 11:11 服务团队获得支持。它可能受到维护、计费和合同状态的影响。它必须具备足够的可移植性，以便在服务不再满足要求时离开。
在机架层，问题是主机、存储和网络组件是否为所支付的服务级别提供了足够的冗余。在路由层，问题是观察到的邻居是否转化为真实、多样、足够的上游容量。在修复层，问题是备件和技术人员是否在故障发生的城市可用。在支持层，问题是合适的人是否能在无需等待渠道交接的情况下采取行动。在合同层，问题是哪些事件计入服务承诺，而哪些被排除在外。在出口层，问题是客户能否在期限内取回完整的数据和配置。
Green Cloud 的公开证据支持用具体的细节来问这些问题。AS54155 是活跃的。一些前缀直接映射到 Green Cloud。其他的则暗示继承或分配的容量。11:11 发布了当前的云、私有云、主机代管和支持页面。历史的 Green Cloud 材料显示了六个美国数据中心市场、一个庞大的合作伙伴网络，以及包括 IaaS、备份、灾难恢复、DaaS 和安全在内的服务组合。公开证据没有显示的是当前的每产品容量地图、经过审计的故障转移测试结果、当前的客户导出条款或每个站点的传输图表。
这就是为什么正确的姿态既不是否定也不是盲目信任。一个休眠的单前缀空壳公司将会被给出远为严厉的结论。Green Cloud 不是那样。但是完整的强评级将要求当前的运营商证据，该证据要将旧有的 Green Cloud 资产映射到 11:11 当前的云区域、证明路径多样性、记录 RPKI 状态、解释获得地址的管理职责，并展示客户在压力下如何恢复或退出。
客户在依赖之前应验证什么
一个审视 Green Cloud 支撑容量的客户或渠道合作伙伴应从交付点安排开始。该安排应当针对实际的服务，而非笼统的品牌，指定生产城市、辅助城市、备份存储库、安全日志位置和支持管辖权。它应当说明该账户是位于旧有的 Green Cloud、Cirrity 继承的基础设施、带有 INAP 分配的环境、11:11 公共云、11:11 私有云、灵活裸机还是主机代管上。
其次，客户应要求一份路由和起源安全声明。AS54155 有活跃的 IPv4 公告和观察到的邻居，但客户需要用于服务的前缀、上游或对等设计、路由过滤策略以及这些前缀的 RPKI 状态。如果 ROA 不存在，提供商应解释是否有计划，以及如何以其他方式管理路由劫持或路由泄露风险。
第三，客户应测试故障转移，而不仅仅是阅读恢复语言。恢复测试应衡量检测、授权、故障转移、应用验证、用户访问、回滚和计费影响。如果客户通过渠道购买，则应包括渠道合作伙伴。应包括状态和通信路径。如果工作负载被假定为全天候受保护，则应包括非工作时间的支持升级。
第四，客户应测试数据退出。导出应包括虚拟机镜像或应用数据、元数据、备份目录信息、防火墙规则、DNS 依赖、访问控制配置和审计所需的日志。导出应通过一个现实的网络路径执行，并测量完成时间。只能在同一提供商内部恢复的备份对于许多事件有用，但对于提供商合同失败或强制迁移是不够的。
最后，客户应将合同与现实故障路径对齐。不应将 SLA 解读为单一可用性百分比。应将其解读为包含和排除依赖关系的示意图：公共互联网可通达性、客户配置、计划维护、安全事件、第三方运营商故障、计费锁定、合作伙伴错误和不可抗力。客户应当知道哪些故障产生积分，哪些产生运营帮助，以及哪些都不产生。
底线
Green Cloud Technologies,LLC 销售一种可见为真实但在操作上是分层之后的容量形式。公共互联网仍然看到 AS54155。ARIN 仍然将 AS 与 Green Cloud Technologies,LLC 关联。11:11 的收购记录和当前云页面支持 Green Cloud 已成为更广泛托管基础设施平台的一部分而非消失的观点。历史服务文档、收购记录和合作伙伴引用显示了一家公司通过大型渠道网络销售 IaaS、备份、灾难恢复、DaaS 和安全服务。
降级同样重要。Green Cloud 特定的城市和服务证据在很大程度上是历史性的。当前的公共路由表混合了直接的 Green Cloud、收购和分配的地址记录。PeeringDB 没有提供互联配置文件。采样的 RPKI 检查是未知的。支持和维护模型清楚地表明修复窗口、严重性队列和排除的依赖关系很重要。公共记录并不能证明每个广告或继承的位置都有相等的备用容量、相等的传输多样性或相等的恢复深度。
对读者来说，有用的结论是实用性的。将 Green Cloud 视为在 11:11 轨道内的一个活跃基础设施依赖，而非一个简单的云标志。在将关键工作负载放在其上之前，要求查看站点交付点、路由多样性、恢复容量、支持权限、维护实践和数据可移植性的当前证据。服务的价值不仅在虚拟机或备份存储库。它在于机架、路由、人员和合同，当容易的路径消失时，这些仍然必须工作。