Tres mil·lisegons. Aquest és el temps que va durar la baixada de tensió a l'escomesa elèctrica que, el 15 de juliol, va deixar tres serveis de la zona
Operem maquinari propi en datacenter i donem servei de colocation, així que aquests informes els llegim amb un interès molt poc acadèmic: el que li va passar a Google als Països Baixos li pot passar a qualsevol amb un CPD, i la llista de coses que van fallar aquell dia és exactament la llista de coses que gairebé ningú comprova. L'informe oficial de Google està publicat i és honest fins a fer mal. Val la pena llegir-lo sencer, però si no ho penses fer, aquí hi ha el que importa: la cadena completa, per què la redundància que hi havia sobre el paper no va funcionar, i les preguntes concretes que convé fer —al teu proveïdor i a tu mateix— abans que et toqui.
La cadena, en ordre
Gairebé tots els passos que vénen a continuació són mecanismes de protecció fent exactament la seva feina. El problema és com encaixen. Reconstruït a partir de l'informe:
Les hores de l'informe són en hora del Pacífic; els intervals són relatius a l'inici de la falta elèctrica. La durada total de l'incident va ser de 14 h 55 min, i l'impacte per servei, de 9 h 24 min a Google Cloud VMware Engine (24 núvols privats de 20 clients), 12 h 57 min a Bare Metal Solution (9 clients) i 8 h 31 min a NetApp Volumes.
Dues escomeses, dos DRUPS, i tot i així una filera a les fosques
Sobre el paper, aquell datacenter tenia tot el que se li demana a un datacenter seriós: doble escomesa, suport rotatiu dièsel a cada costat, refrigeració amb font redundant. En un qüestionari d'auditoria, totes les caselles marcades. I tot i així una filera sencera es va quedar sense corrent i una sala va arribar a 44 graus.
La lliçó no és que la redundància no serveixi. És que la redundància només compta si les branques són de debò independents i estan totes disponibles alhora. Aquí va fallar pels dos costats. L'esdeveniment que ho va disparar tot era comú a les dues escomeses —una falta aigües amunt, a la xarxa del subministrador, no distingeix entre el teu costat A i el teu costat B—, i una de les branques de fred estava fora per obres. Una configuració N+1 amb una branca en manteniment no és N+1: és N, i a sobre amb la sensació de tenir marge.
El detall més instructiu, però, és un altre: la filera 3 no va caure perquè li faltés alimentació disponible, sinó perquè en intentar posar tota la seva càrrega per una sola escomesa va saltar una protecció de sobrecàrrega. És la fallada clàssica del repartiment de càrrega: cada branca aguanta la seva meitat, però no aguanta les dues. Es descobreix el dia del tall, mai abans, llevat que algú hagi fet l'exercici de sumar consums reals per branca en comptes de refiar-se del disseny original. Si al teu CPD ningú ha tornat a fer aquesta suma des que es van instal·lar els últims cinc racks, aquesta suma està pendent.
La baula que ningú audita: qui alimenta el que mana arrencar el fred
Si haguéssim de quedar-nos amb una sola frase de l'informe, seria aquesta: el controlador de la refredadora es va quedar sense servei durant el transitori i no va arribar a donar el senyal per tornar a engegar les bombes. No es va trencar la refredadora. No es van trencar les bombes. Va caure l'autòmat que els diu que arrenquin.
Això és molt comú i gairebé mai apareix en un diagrama de resiliència. Quan algú dibuixa la cadena de fred, dibuixa refredadores, bombes, canonades i climatitzadors de sala. El que gairebé mai es dibuixa és l'electrònica de control: els PLC, els sensors, els variadors, els petits quadres de comandament que orquestren tot l'anterior. Són consums ridículs —uns centenars de watts— comparats amb els megawatts que governen, i precisament per ridículs acaben quedant fora de l'alimentació protegida. El resultat és un sistema que sobreviu perfectament al tall però no sap tornar sol.
La prova que aquest era el diagnòstic és a la mateixa resposta: entre les primeres accions de l'equip d'instal·lacions hi va haver portar un SAI portàtil fins als controladors de les refredadores. Un SAI d'emergència, arrossegat fins allà en plena matinada europea, per alimentar uns quadres de control que governen la refrigeració d'una zona d'un hiperescalar. Quan ho llegeixes així sona gairebé domèstic, i aquesta és justament la part que cal retenir: la infraestructura crítica se sosté sobre peces petites que ningú mira fins que cauen.
La pregunta que surt d'aquí, i que serveix tant per a un hiperescalar com per al CPD d'una empresa mitjana: si se'n va la llum i torna trenta segons després, quines parts de la teva instal·lació arrenquen soles i quines necessiten que algú hi vagi i premi un botó? La resposta no és al diagrama unifilar; és a la llista de què hi ha connectat a alimentació protegida. Gairebé sempre hi ha sorpreses, i gairebé sempre són al costat del clima, no al dels servidors.
44 graus: l'apagada no va ser la fallada
Convé dir-ho perquè en les lectures ràpides de l'incident s'hi cola el contrari: apagar les màquines va ser el correcte. A 44 graus d'ambient, l'alternativa a una apagada ordenada no és «seguir donant servei»; és coure discos, fonts i electrònica de xarxa, i convertir un incident de quinze hores en una reposició de maquinari de diverses setmanes. La factura d'haver arribat a aquella temperatura ja estava posada: quatre nodes d'emmagatzematge SAN van fallar per calor abans que comencés l'apagada.
El que sí que és discutible és el marge. Van passar poc més de dues hores entre el tall i els 44 graus. Això és tot el que dona una sala plena quan es queda sense fred, i és bastant menys del que la gent intueix, perquè la densitat per rack ha pujat molt més de pressa que la capacitat de la sala d'absorbir calor. Si el teu pla de contingència assumeix que «hi ha temps per reaccionar», posa-li un número a aquest «hi ha temps». Google, amb tota la seva instrumentació i el seu equip presencial, va tenir dues hores.
És, per cert, un cas de manual de per què la temperatura i l'estat del clima han d'estar a la mateixa consola de monitoratge que la resta —i amb llindars que avisin abans del punt de no retorn, no quan ja no hi ha res a fer. Ja en vam escriure: una alerta que arriba quan ja no pots actuar és soroll car.
La lletra petita: una zona no és un edifici
Aquí hi ha la part que més ens interessa de tot l'incident, i la que menys s'ha comentat. Els tres serveis afectats van ser VMware Engine, Bare Metal Solution i NetApp Volumes. No és casualitat: són precisament els serveis en què el client té ferro dedicat —hipervisors, servidors físics, cabines— i no una abstracció repartida per programari entre diverses sales. I aquells tres serveis operaven des d'un edifici concret dins de la zona.
El consell estàndard de qualsevol hiperescalar és «desplega en diverses zones». És un bon consell. Però amaga un supòsit que gairebé ningú verifica: que el teu servei es comporta com el model de zones diu. Els serveis gestionats especialitzats solen penjar d'un datacenter únic dins de la zona, i això no apareix al diagrama bonic de la documentació. El resultat és una dependència arquitectònica real que molts equips no saben que tenen, fins que l'edifici en qüestió es queda sense fred.
Dit d'una altra manera, i sense cap intenció de fer sang: quan et portes el teu VMware al núvol d'un altre, canvies de propietari del rack, no de física. Els watts i els graus continuen sent-hi, només que ara en un edifici on no pots entrar i sobre el qual no decideixes quan s'hi fan obres. De vegades aquest canvi compensa molt. Però l'avantatge que es compra és operatiu i financer, no és immunitat tèrmica, i convé no confondre les dues coses en escriure el pla de continuïtat.
El que aquest incident NO demostra
No demostra que el núvol sigui fràgil ni que calgui treure-ho tot d'allà. Ho diem nosaltres, que vivim de muntar i mantenir infraestructura fora dels hiperescalars i que tindríem l'incentiu obvi de dir el contrari.
Aquell datacenter tenia doble escomesa, suport rotatiu, refrigeració redundant, telemetria tèrmica que va permetre ordenar una apagada a temps i un equip d'instal·lacions presencial que va resoldre el problema amb un SAI portàtil. L'armari del quarto dels mals endreços d'una oficina —amb el seu SAI de 1.500 VA comprat el 2019, el seu aire condicionat domèstic i el seu endoll compartit amb la cafetera— no té res d'això, i allà el mateix transitori de tres mil·lisegons no hauria donat quinze hores d'incident: hauria donat una sala coent-se sense que cap alarma arribés a ningú fins l'endemà al matí. Que a un hiperescalar li passi això no és un argument a favor de fer-ho a casa; si de cas és el contrari.
La conclusió útil no és on, sinó què preguntes i què assumeixes. Ja vam fer els comptes a cinc anys entre colocation i cloud públic i la resposta honesta va ser «depèn, i aquí tens els números». Aquest incident no canvia aquells comptes. Canvia la llista de preguntes que cal fer abans de signar-los.
Les set preguntes que sí que valen la pena
Serveixen per al datacenter on tens el teu colocation, per al proveïdor cloud a qui compres serveis de ferro dedicat i per a la teva pròpia sala si encara en tens una. Es responen mirant registres i calendaris, no marcant caselles.
- Hi ha obres en marxa ara mateix? I si n'hi ha, quina branca de redundància està degradada mentre durin i fins quan? És la pregunta més rendible de tota la llista i gairebé ningú la fa. Una reforma al circuit de fred converteix el teu contracte N+1 en un N durant mesos, sense que canviï ni una línia del contracte.
- Els controladors del clima estan en alimentació protegida? No les refredadores: els controladors. I les bombes, i els variadors. És la pregunta que aquest incident posa sobre la taula i la que distingeix qui ha pensat el problema de qui ha comprat equips.
- Quan va ser l'última prova de transferència amb càrrega real? Amb data. Arrencar els generadors en buit un dimarts al matí no prova res; el que cal provar és la transferència amb la càrrega que hi ha avui, no la del dia del disseny.
- Si una branca assumeix tota la càrrega, aguanta? Aquesta és la que va tombar la filera 3. Demana el repartiment de consum per branca i compara'l amb el calibre de les proteccions. Si ningú ha refet aquella suma des de l'últim creixement, està desactualitzada per definició.
- Quant temps tinc des que s'atura el fred fins a l'apagada? Un número en minuts, mesurat, no estimat. És la teva finestra real de reacció i determina si un pla manual té sentit o si tot ha de ser automàtic.
- Els meus sistemes estan de debò repartits, o només ho sembla? Al núvol: el servei que faig servir és multi-sala o penja d'un edifici? Al colocation: els meus dos «nodes redundants» són a sales diferents, amb escomeses diferents, o són dos racks contigus alimentats pel mateix quadre?
- Qui m'avisa, quan i per quin canal? I amb quin detall. Google va publicar un informe amb la cadena sencera, les hores al minut i una llista de mesures correctores amb data de tancament. Aquest nivell de detall és el que et permet decidir si continues allà. Un proveïdor que només et dona «incidència resolta» t'està demanant que confiïs sense dades.
I encara responent-les totes set
Encara que el teu proveïdor contesti bé a les set, continua havent-hi una possibilitat real que un dimarts qualsevol una sala sencera s'apagui durant quinze hores. Això no s'arregla amb un contracte millor: s'arregla tenint el servei en un altre lloc i havent-ho provat. És la mateixa conclusió a què vam arribar amb la caiguda d'AWS d'aquest mateix mes, i no ha millorat amb la repetició: la recuperació que no has assajat no és un pla, és una intenció.
A la pràctica, per a la majoria d'empreses mitjanes això significa coses bastant mundanes: que les còpies visquin lluny de la infraestructura que copien, que existeixi una segona ubicació amb capacitat suficient per al que és important —no per a tot, per al que és important—, i que algú hagi cronometrat alguna vegada quant es triga de debò a aixecar allà el que és crític. Nosaltres repartim la nostra pròpia infraestructura de Proxmox i Ceph entre diversos datacenters precisament per això, i la part que de debò ensenya no és muntar-la: és cronometrar la tornada.
Tres mil·lisegons. És un bon recordatori que, per sota de totes les capes de programari, continua havent-hi un edifici, una escomesa i un circuit d'aigua freda. I que la resiliència de debò no es compra: es comprova.
Fonts (verificades): la baixada de tensió de 3 ms i l'actuació de les proteccions del subministrador, la fallada del DRUPS del costat A per avaria de components elèctrics, la transferència correcta de les fileres 1 i 2 i el salt de la protecció de sobrecàrrega a la filera 3, la caiguda del controlador de la refredadora i les bombes que no es van tornar a engegar, la font de fred redundant no disponible per obres, els 44 °C a la sala i el creuament del llindar d'operació segura, l'apagada de servidors, emmagatzematge i commutadors iniciada pels equips d'enginyeria, els quatre nodes SAN NetApp caiguts per calor abans d'aquella apagada, el SAI portàtil provisional per als controladors, la durada total de 14 h 55 min, els impactes per servei (9 h 24 min a GCVE amb 24 núvols privats de 20 clients; 12 h 57 min a BMS amb 9 clients; 8 h 31 min a GCNV) i les mesures correctores amb dates de tancament esglaonades fins a l'octubre del 2026 — informe oficial d'incident de Google Cloud. L'apunt sobre que aquests serveis operaven des d'un datacenter concret dins de la zona i la bretxa de transparència que això suposa: The Register (21 de juliol del 2026) i DataCenterDynamics. La lectura sobre redundància degradada per obres, l'electrònica de control fora d'alimentació protegida, la finestra tèrmica com a número mesurat i les set preguntes són nostres. Imatge de portada: interior d'una sala tècnica (banc d'imatges de llicència lliure).
Saps què hi ha sota la teva infraestructura?
A everyWAN allotgem maquinari propi i de clients en datacenter —colocation— i muntem plans de recuperació que es proven, no que s'arxiven. No venem immunitat als talls de llum: això no existeix. El que sí que fem és respondre les set preguntes de dalt sobre el teu muntatge concret i dir-te, amb números, quant trigaries avui a tornar si una sala s'apagués. De vegades la resposta és tranquil·litzadora. Quan no ho és, millor saber-ho un dimarts qualsevol que a les quatre de la matinada.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN