凤凰城数据中心冷却失效后，Namecheap将所有服务中断15小时

2026年8月13日，一场强风暴导致RadiusDC凤凰城数据中心的冷却系统失效，该设施托管着Namecheap自己在事后复盘中所称的“部分关键Namecheap业务”。温度攀升至临界水平，运营商指示Namecheap将服务完全下线，以免设备过热并造成持久损坏。Namecheap——一家拥有25年历史的注册商和托管公司——遵照执行，所有服务瞬间陷入黑暗：共享主机、VPS和独立主机、EasyWP、DNS管理、Private Email、计费系统以及公司自己的网站。

次日由CEO Hillan Klein撰写的事后复盘坦率地描述了连锁反应。客户无法管理DNS记录或重定向。许多网站不可用、缓慢或报错；EasyWP站点即使在控制面板恢复后仍不断抛出数据库连接错误；Private Email既不能发送也不能接收。关键在于，支持服务台运行在同一套故障基础设施上——在十五个小时里，客户没有在线聊天、没有邮件支持、没有任何途径联系到真人。恢复工作依靠临时冷水机组和分阶段重启，约十五小时后服务全面恢复。

刺痛之处在于该设施的资质。RadiusDC凤凰城是一个“按高冗余级别设计”的Tier 3数据中心，Namecheap指出在其25年历史中从未经历过类似情况。但Tier评级认证的是建筑本身，而非租户的架构：Namecheap将其关键业务——以及面向客户的控制平面——集中在那单一建筑内，因此一场亚利桑那风暴中的一次冷却故障同时瘫痪了管理界面、沟通渠道和收入系统。

托管、EasyWP、DNS管理、Private Email和计费系统累计中断15小时；服务台也一并宕机，客户无处求助

关键业务集中在凤凰城单一设施内，因此设施的故障变成了Namecheap的故障——没有第二个站点能维持控制平面存活。

服务台运行在同一套故障基础设施上，因此网站宕机、邮件中断的客户也失去了求助能力——一次可用性故障演变成了沟通故障。

管理平面没有连续性计划：DNS管理、计费和邮件管理在整个事件期间始终处于黑暗状态，尽管DNS区域解析本身保持正常。

设施层面的Tier 3冗余掩盖了租户层面的单点故障；事后复盘称此事件在25年中前所未有。

设施的Tier 3徽章不是你的冗余：让你的控制平面——DNS管理、邮件、计费、支持——依赖于一栋建筑，一次冷却故障就会让一切同时陷入黑暗。

通过将临时冷水机组接入Namecheap所在设施区域，冷却得以恢复，服务随温度稳定逐步回归——公司辩称分阶段恢复是唯一安全的顺序。事后复盘承诺在欧洲和亚洲的其他数据中心实现更高冗余。Namecheap还发布了一则更正：X上的早期帖子错误地将责任归咎于运营商PhoenixNAP，而该设施实际由RadiusDC运营。十五小时的中断引发了客户的广泛愤怒，公司公开承认“我们辜负了你们”。