史上首次全国红色预警。对我们而言，毫无波澜——因为我们早已准备就绪。

取不到的凭证，等于没有凭证。对一座保险库而言，保持可用——随时随地、次次如一——不是一项功能，而是全部职责所在。

本周，荷兰宣布了史上首次全国极端高温"红色预警（code red）"——一场 40°C 的高温事件，为该国自 1901 年开始有记录以来所未遇 [1][2]。到周五，高温一路攀升到了一个几乎无人会想起、直到它出故障才被关注的层面：数据中心。我们在阿姆斯特丹的服务商 Leaseweb 做得完全正确，提前向我们发出警告——该设施运行温度偏高，已开始关闭自身部分基础设施以散热，我们托管在那台机器可能就是下一个。我们检查了一下：状态正常，服务照常。然后我们回去继续工作。不是因为我们确信阿姆斯特丹能扛住——而是因为它根本不必独自扛。

阿姆斯特丹的数据中心过热，不该成为我们的问题

阿姆斯特丹的那台机器是我们管理系统中的两个锚点之一——这套幕后系统负责运行并协调我们的整个集群。在展开之前，先说清最重要的一点：这并不是存放和提供您凭证的那座保险库。那些运行在完全独立、彼此隔离的另一套平面上——一个截然不同的全球系统——这次高温根本没有触及。管理大脑与您的智能体实际访问的保险库是两个不同的世界：一边的糟糕日子，绝不等于另一边的糟糕日子。我们只是对这套管理大脑采用了与其余一切相同的标准——绝不允许单点。因此我们有意设置了两个锚点——一个在阿姆斯特丹（Leaseweb），一个在大阪（Ablenet）。两个大洲。两家服务商。两张电网。两种气候。荷兰一个 40°C 的午后，对日本的一台机器没有任何物理影响：不同的天气、不同的电网、完全不同的故障域。（顺带一提：当阿姆斯特丹在全国红色预警下逼近 40°C 时，大阪正处于梅雨季，气温约 29°C——低了十一度，远隔半个地球，天气系统毫无关联。这个差距正是设计所在。）两个锚点持续保持同步，因此任何一方都不会落后另一方太多。如果热浪、电网故障或服务商事故让阿姆斯特丹下线，最坏情况也只是一次短暂、有界的切换，切到地球另一端——而不是一次中断。

韧性不是凭证保险库的一项功能。它就是产品本身。

凭证保险库是技术栈中承重最重的一环：每一个应用、每一条流水线、每一个智能体都要通过它完成认证。它应答时，一切正常；它不应答时，一切同时停摆。正是这种不对称，决定了韧性不是事后可以补装的东西。您不会想在百年最热的那一天，才发现自己那唯一一座数据中心、那唯一一座城市、那唯一一张电网，到底扛不扛得住高温。您要在凉爽的日子里做出决定——拒绝把整个公司押在单一气候上。我们很早就做出了这个决定：绝不允许任何单一区域、服务商、电网或天气系统成为全部。

诚实的版本

没有什么能让基础设施免疫。天气会失效，电网会失效，服务商会失效——谁若告诉你相反的结论，那是在推销。您真正能选择的，是其中任何一项失效时，是否会把您一并拖垮。我们选择了两个半球，所以答案是不会。本周以最直白的方式检验了这个选择，而检验过程平淡无奇：阿姆斯特丹在高温中持续提供服务；即便它没有，设计中也早已备好了答案，就在大阪。

在灾难尚未发生的那一天，为它做好准备

这就是全部要义。凉爽的日子，是您为炎热的日子做准备的时候；炎热的日子，是您暗自庆幸早已准备好的时候。本周就是一个炎热的日子——而且创下了纪录——而对我们来说毫无波澜。这恰恰是它应有的样子。

功劳该给谁就给谁：Leaseweb 应对高温的方式，正是优秀运维者的方式——提前预警、采取防护、不制造戏剧性。最好的服务商，会在问题出现之前就告诉您。我们要做的，只是确保当某个站点遭遇糟糕的一天时，它从来不是唯一的站点。

Clavitor（@clavitorai）是为 AI 智体而建、也防备 AI 智体的凭证保险库。clavitor.ai

来源

[1] NL Times — Dutch heatwave now official; historic Code Red hot-weather alert（史上首次全国极端高温红色预警；自 1901 年有记录以来持续最久的六月热浪）：https://nltimes.nl/2026/06/25/dutch-heatwave-now-official-historic-code-red-hot-weather-alert-debated

[2] DutchReview — NL temperatures to reach up to 40 degrees（内陆最高气温逼近 40°C）：https://dutchreview.com/news/netherlands-up-to-40-degrees-then-plummet-to-21-degrees-25062026/