Pierwszy w historii krajowy alarm najwyższego stopnia. Dla nas — zdarzenie bez znaczenia, bo byliśmy przygotowani.

Dostęp, którego Pan/Pani nie ma, to dostęp, którego Pan/Pani nie posiada. Dla skarbca pozostawanie dostępnym — za każdym razem, z każdego miejsca — nie jest funkcją dodatkową; to całe jego zadanie.

W tym tygodniu Holandia ogłosiła pierwszy w swojej historii krajowy „code red" z powodu ekstremalnych upałów — zdarzenie z temperaturą 40°C, jakiego kraj nie odnotował, odkąd prowadzi pomiary od 1901 roku [1][2]. Do piątku upał dotarł aż do warstwy, o której prawie nikt nie myśli, dopóki nie zawodzi: do centrum danych. Nasz dostawca w Amsterdamie, Leaseweb, postąpił dokładnie tak, jak powinien, i ostrzegł nas wcześnie — obiekt pracował w podwyższonej temperaturze, zaczął wyłączać części własnej infrastruktury, aby odprowadzić ciepło, a maszyna, którą tam utrzymujemy, mogła być kolejna. Sprawdziliśmy ją: zdrowa, działa normalnie. Potem wróciliśmy do pracy. Nie dlatego, że byliśmy pewni, iż Amsterdam wytrzyma — lecz dlatego, że nie musi.

Gorące centrum danych w Amsterdamie nie może być naszym problemem

Maszyna w Amsterdamie to jeden z dwóch kotwic w naszym systemie zarządzania — zapleczu, które uruchamia i koordynuje całą naszą flotę. A przede wszystkim, najważniejszy punkt wyrażony prostym językiem: to nie jest skarbiec, który przechowuje i udostępnia Państwa dane uwierzytelniające. Te działają na zupełnie odrębnej, niezależnej płaszczyźnie — na innym, całkowicie oddzielnym systemie globalnym — której to upał nigdy nie dotknął. Mózg zarządzający i skarbce, z którymi faktycznie komunikują się Państwa agenci, to dwa różne światy: zły dzień dla jednego nie jest złym dniem dla drugiego. Wymagamy jednak od tego mózgu zarządzającego tego samego standardu co od wszystkiego innego — nigdy jednego punktu awarii. Dlatego są dwie kotwice, celowo — jedna w Amsterdamie (Leaseweb), jedna w Osace (Ablenet). Dwa kontynenty. Dwóch dostawców. Dwie sieci energetyczne. Dwa klimaty. Popołudnie z 40°C w Holandii nie ma żadnego fizycznego wpływu na maszynę w Japonii: inna pogoda, inna sieć energetyczna, zupełnie inna domena awarii. (Ciekawostka: gdy Amsterdam dochodził do 40°C przy krajowym alarmie najwyższego stopnia, Osaka utrzymywała około 29°C w środku pory deszczowej — jedenaście stopni chłodniej, o pół świata dalej, w całkowicie niezwiązanym systemie pogodowym. Ta różnica jest projektem.) Obie kotwice pozostają stale zsynchronizowane, więc żadna nie pozostaje daleko w tyle za drugą. Gdyby fala upałów, awaria sieci energetycznej lub incydent u dostawcy wyłączyły Amsterdam, najgorszy scenariusz to krótkie, ograniczone przełączenie na drugą stronę planety — a nie niedostępność.

Odporność nie jest funkcją skarbca danych uwierzytelniających. Jest produktem.

Skarbiec danych uwierzytelniających to element o największym znaczeniu w całym stosie: każda aplikacja, każdy potok i każdy agent uwierzytelnia się przez niego. Kiedy odpowiada — wszystko działa; kiedy nie może odpowiedzieć — wszystko staje jednocześnie. Ta asymetria jest powodem, dla którego odporności nie dokłada się później. Nie chce Pan/Pani przekonać się w najgorętszy dzień stulecia, czy jedno centrum danych, w jednym mieście, przy jednej sieci energetycznej, wytrzyma upał. Decyduje się o tym w chłodny dzień, odmawiając postawienia firmy na jeden klimat. Podjęliśmy tę decyzję dawno temu: żaden region, dostawca, sieć energetyczna ani system pogodowy nie ma prawa być całą historią.

Uczciwa wersja

Nic nie czyni infrastruktury odporną na wszystko. Zawodzi pogoda, zawodzą sieci energetyczne, zawodzą dostawcy — a każdy, kto tworzy inaczej, coś sprzedaje. To, co faktycznie można wybrać, to czy awaria jednego z nich może pociągnąć Pana/Panią w dół. Wybraliśmy dwie półkule, więc odpowiedź brzmi: nie. W tym tygodniu ten wybór został przetestowany w najbardziej dosłowny sposób, a test był nudny: Amsterdam obsługiwał żądania przez upał, a nawet gdyby tak nie było, projekt miał już odpowiedź czekającą w Osace.

Budować pod katastrofę w dzień, w którym jej nie ma

To cała dyscyplina. W chłodny dzień buduje się na ten gorący; w gorący dzień cicho się cieszy, że się to zrobiło. Ten tygodniu był dniem gorącym — rekordowym — i dla nas był zdarzeniem bez znaczenia. Dokładnie tak powinno być.

Należy oddać, co się należy: Leaseweb poradził sobie z upałem tak, jak robią to dobrzy operatorzy — wczesne ostrzeżenie, działanie ochronne, bez dramatyzmu. Najlepsi dostawcy informują, zanim pojawi się problem. Naszym zadaniem jest jedynie upewnić się, że gdy jedna lokalizacja ma zły dzień, nigdy nie była jedyną.

Clavitor (@clavitorai) to skarbiec danych uwierzytelniających zbudowany dla agentów AI — i przeciwko nim. clavitor.ai

Źródła

[1] NL Times — Dutch heatwave now official; historic Code Red hot-weather alert (pierwszy w historii krajowy alarm najwyższego stopnia z powodu ekstremalnych upałów; najdłuższa czerwcowa fala upałów od początku pomiarów w 1901 roku): 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 (szczytowe temperatury w głębi lądu zbliżone do 40°C): https://dutchreview.com/news/netherlands-up-to-40-degrees-then-plummet-to-21-degrees-25062026/