Els teus servidors els pot apagar algú amb qui no has signat res

El 13 d'agost es van quedar sense servei més de 5.000 servidors en un edifici de Phoenix, i amb ells les webs, el correu, els panells de control i el DNS de milers d'empreses repartides per mig món. Cap atacant, cap CVE. La refrigeració de la sala va deixar de donar l'abast i es va haver d'apagar abans que la calor s'endugués el maquinari. El que crida l'atenció del cas no és l'avaria: és que l'ordre d'apagar no la va donar l'empresa a qui aquests clients paguen.

Entre una assessoria de Sabadell amb la seva web i el seu correu i la mà que va decidir tallar el corrent hi havia diverses empreses, i cap no havia signat res amb ella. Aquesta distància és el que ens interessa aquí, perquè es pot mesurar abans de contractar i gairebé ningú la mesura.

Trenta hores i mitja, amb hores

La seqüència pública és aquesta. Durant la matinada del 13 d'agost una tempesta afecta el centre de dades de RadiusDC a Phoenix. El comunicat tècnic recollit per HostingJournalist és més específic que «una tempesta»: les temperatures de sala pugen després de diversos microtalls de subministrament elèctric durant les tempestes nocturnes. A les 10:28 UTC s'emet el primer avís de temperatura del centre de dades. Els equips es van retirant de servei de manera escalonada durant les hores següents, més de 5.000 servidors en total.

Sobre si apagar va estar bé no ens hi allargarem, perquè ja vam defensar aquesta postura al juliol arran de la caiguda de Google Cloud per energia i refrigeració: l'apagada tèrmica és la decisió correcta, no l'avaria. Les guies tèrmiques d'ASHRAE situen el rang recomanat de temperatura d'entrada d'aire entre 18 i 27 °C i el permès per a equip de classe A1 entre 15 i 32 °C, i aquest sostre descriu la condició en què el fabricant verifica que allò funciona, amb l'advertiment que operar-hi de manera prolongada escurça la vida útil. Amb la sala a plena càrrega i la meitat de les màquines de fred aturades, continuar encès era apostar a quant triguen a degradar-se discos i fonts.

La cadena per la qual baixa l'ordre

Tothom té clara la resposta curta a qui pot reiniciar els seus servidors: jo, o el meu proveïdor si l'hi demano. La llista llarga és una altra cosa. A Phoenix, per damunt del client final hi havia l'agència o el partner que li va muntar la web, el proveïdor d'allotjament que li va vendre el pla, phoenixNAP —que va vendre el negoci de l'edifici i continua a dins com a inquilí, i que és qui publica el detall tècnic del que va passar— i RadiusDC, que gestiona la sala. Quatre esglaons per damunt, cap amb el seu telèfon.

I l'edifici havia canviat de mans feia pocs mesos. RadiusDC va anunciar el 12 de març l'acord per comprar el negoci de centre de dades i colocation de phoenixNAP a Phoenix, amb tancament previst per al segon trimestre. Qui mana avui a la sala on viu el teu maquinari pot no ser qui manava quan vas signar, i aquest canvi no apareix en cap factura.

Que l'operador de l'edifici tingui aquesta autoritat està bé: és qui veu els termòmetres i qui ha de respondre si la sala es crema. El problema és que aquesta autoritat no surt mai a la conversa comercial, on es parla de percentatges de disponibilitat. Un percentatge es respon amb un número de fullet. La pregunta de qui et pot apagar es respon amb noms d'empreses, i aquests noms canvien.

El DNS va arribar més lluny que l'edifici

Quan el DNS de Namecheap va deixar de respondre es van trencar també llocs que no hi estaven allotjats. Qualsevol web del món els servidors de noms de la qual apuntessin a Namecheap va deixar de trobar-se, tant se val on visqués. Una empresa que hagués fet els deures —web en un proveïdor, correu en un altre, còpies en un tercer— podia quedar-se a les fosques igualment, perquè les tres coses es localitzen preguntant a la mateixa zona.

El DNS es concentra gairebé sempre per una raó que no és tècnica: ve inclòs. Compres el domini, el registrador et regala la zona i allà es queda. Ningú decideix posar tota la seva resolució en un únic proveïdor; el que passa és que ningú decideix el contrari, igual que passa amb les renovacions de què parlàvem al post sobre els dominis .es caducats. La solució és de les que surten barates: el protocol sempre ha estat preparat per tenir servidors de noms secundaris en un altre operador, i muntar-ho costa una tarda. Amb un matís que convé dir, perquè protegeix menys del que sembla: això manté viva la resolució, no el servei. Si la teva web està apagada, el DNS secundari respondrà sense cap problema l'adreça d'una màquina que no contesta.

El que diuen els números, que no és el que sembla

Aquí convé resistir-se a la moralina fàcil de «revisa la refrigeració del teu proveïdor». En el repartiment de causes de caigudes de servei de TI que Network World extreu de l'anàlisi anual del 2026 de l'Uptime Institute, la refrigeració és l'última de la llista amb un 8 %, per darrere de xarxa i connectivitat (23 %), energia (21 %), sistema i programari (18 %) i proveïdors tercers (10 %). Per a caigudes de centre de dades en concret, l'energia s'endú el 45 % de les que tenen impacte. Phoenix és el cas rar, no el típic.

Cosa que reforça l'argument en comptes de debilitar-lo. Una causa que explica vuit de cada cent caigudes es va endur 5.000 servidors durant un dia i mig, i va arribar a empreses que ni tan sols tenien res en aquell edifici. Planificar per freqüència no hauria servit de res. Del mateix informe surten dues xifres per a la conversa amb direcció: el 57 % dels enquestats diu que la seva última caiguda important va costar més de 100.000 dòlars, i per segon any consecutiu un de cada cinc declara costos per damunt del milió. La freqüència per emplaçament, mentrestant, baixa per cinquè any seguit, i només al voltant d'un de cada deu diu que la seva última caiguda va tenir impacte greu o sever. Amb aquestes dues tendències juntes es calcula un RTO i un RPO amb números en comptes d'adjectius.

Tres preguntes sobre l'edifici

Operem infraestructura pròpia repartida en diversos centres de dades, així que aquestes preguntes les hem fet i també ens les han fet. Van sobre la cadena de comandament, que és el que no acostuma a estar escrit enlloc.

Quan això no et cal

Venem colocation i plans de recuperació, així que aquest paràgraf té interès de part i ho diem abans d'escriure'l. Trenta hores de web caiguda no arruïnen tothom. Si la web és un fullet amb un formulari, el correu va per Microsoft 365 i no toca aquell edifici, i el negoci es fa per telèfon i al taulell, muntar un DNS secundari en un altre operador val la pena perquè costa poc, i duplicar infraestructura en un segon centre de dades no. Recomanar que no es dupliqui quan el compte no surt forma part de la feina, igual que hem recomanat quedar-se a VMware quan tenia sentit.

La línia es creua quan el negoci no pot treballar sense això. Un magatzem que no expedeix sense l'ERP, una clínica que no passa consulta sense les històries, una assessoria a final de trimestre. Allà, un dia i mig aturat es mesura en facturació, i el preu de la redundància deixa de comparar-se amb zero.

Fa setmanes que escrivim aquí sobre versions que caduquen, avisos amb termini i errors amb el seu número assignat. Aquest no té número, ni butlletí per subscriure, ni inventari per creuar. Hi va haver una tempesta d'estiu sobre el desert i un edifici que no es va poder treure la calor de sobre. La feina que serveix per a això es fa abans, i consisteix sobretot a saber on són les teves coses i qui mana al lloc on són, encara que no li hagis signat res.

Fonts (verificades el 16 d'agost del 2026): cronologia de l'incident (primer avís de temperatura a les 10:28 UTC del 13-ag-2026, tancament a les 17:00 UTC del 14-ag-2026, 30 h 32 min en total, 11 h 42 min per al lloc principal, més de 5.000 servidors, llista de serveis afectats, efecte sobre llocs de tercers que resolien per Namecheap, absència de pèrdua de dades i anunci de redundància entre els seus centres de dades dels EUA, Europa i Àsia), a partir de la pàgina d'estat i el comunicat de Namecheap recollits per Cyber Kendra; comunicat tècnic amb els microtalls de subministrament durant les tempestes nocturnes, afectació simultània de Hosting.com i operació per la qual RadiusDC es queda el negoci de centre de dades i colocation de phoenixNAP a Phoenix (anunciada el 12 de març del 2026, tancament previst per al segon trimestre; phoenixNAP continua com a inquilí), segons HostingJournalist i la nota de premsa de l'operació; dues de les quatre refredadores operatives cap al migdia (hora de l'Est) i ús de refredadores temporals, segons TechBarrista; rangs tèrmics recomanat (18–27 °C) i permès de classe A1 (15–32 °C) de les guies tèrmiques d'ASHRAE TC 9.9; repartiment de causes de caigudes de servei de TI (xarxa 23 %, energia 21 %, sistema i programari 18 %, tercers 10 %, refrigeració 8 %) i energia com a causa del 45 % de les caigudes de centre de dades amb impacte, segons la lectura de Network World de l'Annual Outage Analysis 2026 de l'Uptime Institute, d'on surten també el 57 % per damunt de 100.000 USD, l'1 de cada 5 per damunt d'1 M USD, el cinquè any consecutiu de descens per emplaçament i l'~1 de cada 10 amb impacte greu o sever. Discrepància declarada: Cyber Kendra i TechBarrista atribueixen a RadiusDC la instrucció de retirar els sistemes de servei; HostingJournalist la presenta com a decisió de Namecheap. No hem pogut accedir al comunicat propi de Namecheap. Les cites en català de textos originalment en anglès són traducció nostra. La lectura sobre la cadena d'autoritat de l'apagada, sobre la concentració del DNS i les tres preguntes són nostres, no de les fonts.