L'1 de setembre, un enginyer de Google va desendollar en un centre de dades, un darrere l'altre, el 100% dels camins de fibra que donaven servei a una part de la zona us-central1-b. Va trigar tretze minuts. L'interessant de l'informe no és l'error: és el paràgraf que Google escriu just abans, descrivint una arquitectura redundant impecable.
De l'anterior caiguda de Google ja en vam escriure aquí: aquella va ser d'energia i refrigeració, una fallada d'instal·lació a la sala. Aquesta no s'hi assembla gens, i per això val la pena. Aquí no es va avariar cap peça. Tot el maquinari estava sa; el que estava desconnectat, ho va desconnectar algú, a mà, amb una ordre de treball aprovada.
El que estava ben dissenyat
Abans d'explicar l'error, l'informe preliminar dedica un paràgraf a explicar com està muntada la xarxa de cada centre de dades. Val la pena llegir-lo sencer, perquè és exactament el que qualsevol de nosaltres posaria en una proposta:
«L'arquitectura de xarxa de cada centre de dades està dissenyada amb redundància entre múltiples dispositius d'encaminament. El sistema està dissenyat per ser resistent a qualsevol fallada d'un sol dispositiu o camí de fibra, i la majoria de fallades dobles o triples no afecten el trànsit dels clients. Per garantir-ho, els dispositius i els camins de fibra estan físicament separats a cada centre de dades, amb fonts d'alimentació diverses.»
Tot això és cert i tot això hi era. I no va servir absolutament de res, perquè la frase següent de l'informe diu que «un error de procediment va fer que l'acció de manteniment físic desendollés seqüencialment el 100% dels camins de fibra a tots els dispositius en tretze minuts».
La redundància és una màquina d'emmascarar
Això ja estava explicat, i fa vint-i-tres anys que ho està. El 2003, tres investigadors de Berkeley —David Oppenheimer, Archana Ganapathi i David Patterson— van analitzar per què cauen tres grans serveis d'internet i van publicar els resultats a USENIX. La conclusió que tothom cita és que l'error d'operador era la causa individual més gran de caigudes en dos dels tres serveis. La que gairebé ningú no cita és la que de debò explica el de l'1 de setembre, i és un matís que els mateixos autors es molesten a deixar per escrit:
«Per tant no és el cas que l'error d'operador sigui més freqüent que els problemes de maquinari o de programari, sinó que s'emmascara amb menys freqüència i per això acaba en caiguda de servei més sovint.»
Emmascarar. Aquesta és la paraula exacta del que fa la redundància i del que no fa. Un disc que es mor, una font que es crema, un camí que es talla: són esdeveniments independents, cadascun pel seu compte, i la redundància existeix justament per tapar-los abans que ningú se n'assabenti. Per això la garantia del paràgraf de Google està escrita com està: resistent a qualsevol fallada d'un sol dispositiu, i a la majoria dels dobles o triples. Són afirmacions sobre coincidències improbables. La separació física i l'alimentació diversa serveixen perquè un bassal, un incendi o un quadre elèctric no arribin a dos camins alhora.
Un procediment no és una coincidència. Un procediment recorre: va element per element, en ordre, a propòsit, fins a acabar la llista. I si la llista són els teus camins redundants, recórrer-la sencera equival a arribar al 100% per definició. No hi ha màscara possible, perquè no hi ha res darrere del que amagar-se. Aquest és el sentit literal de «s'emmascara amb menys freqüència».
I hi ha un detall del paper que encaixa amb aquest incident millor del que a ningú li agradaria. Els autors escriuen que «els errors d'operador sorgien quan els operadors estaven fent canvis al sistema, per exemple escalant o reemplaçant maquinari, o desplegant o actualitzant programari», i afegeixen que la majoria «van sorgir durant manteniment normal». La tasca de l'1 de setembre, en paraules de Google, era «una actualització de capacitat programada». Escalar maquinari. Manteniment normal. Vint-i-tres anys després, a la mateixa casella.
Amb una diferència honesta que convé dir: en aquells tres serveis els errors d'operador eren sobretot de configuració —més del 50% en els tres casos— i no errors de procediment físic, que el mateix paper situa en minoria. Aquest és dels rars. El que no canvia és el mecanisme: algú fent un canvi previst, en una finestra prevista, arriba alhora a tot allò que estava separat perquè no s'assolís junt.
La teva llista és més curta del que creus
Aquí és on això deixa de ser una anècdota d'hiperescalador. La teva redundància també porta dins un supòsit que ningú no va escriure: que res no toca totes les còpies. I a qualsevol empresa hi ha una llista curta de coses que sí que les toquen totes, una darrere l'altra, amb credencials i sense preguntar: l'script de pedaçat, l'agent de còpies, l'eina de gestió remota, l'actualització de microprogramari que es llança per lots, l'ordre de treball que diu «els dos switches». No són atacs ni avaries. Són tasques rutinàries, aprovades i ben intencionades, i són les úniques capaces de recórrer la teva redundància de punta a punta. Aquesta llista cap en mitja pàgina i gairebé ningú no la té escrita fins que se li demana.
No és la primera vegada que topem amb un supòsit d'independència que resulta fals. A l'agost vam escriure que redundància no és diversitat de ruta: dos operadors diferents, dos contractes diferents i la mateixa rasa. Allò era una correlació geogràfica que ningú no va triar. Això és més incòmode, perquè la correlació no és accidental: la introdueix, cada vegada, algú del teu propi equip fent bé la seva feina.
La xarxa va tornar a les 09:19. L'incident va acabar a les 11:52
L'informe dóna 4 hores i 11 minuts de durada, de 07:41 a 11:52 hora del Pacífic. Però si segueixes els avisos d'estat que Google va anar publicant durant el matí, aquest número es parteix en dues meitats que no s'assemblen gens. A les 09:19, hora i mitja després del primer cable, l'avís diu que «després dels esforços de mitigació a nivell de xarxa, la infraestructura de xarxa subjacent s'ha recuperat completament» i que els equips de producte «estan validant l'estat de recuperació dels serveis individuals». La fibra ja hi era. Quedaven dues hores i mitja d'incident.
Aquesta segona meitat és la part que gairebé mai no es pressuposta. La detecció, per cert, va ser instantània: l'informe diu que el problema «va ser detectat immediatament pels sistemes automàtics de monitoratge de pèrdua de xarxa, així com per sondes proactives». Assabentar-se no va costar res. Tornar a estar amunt va costar tota la resta, i la major part d'aquell temps no va ser endollar fibra: va ser esperar que els serveis de sobre es recomponguessin. És la mateixa diferència que ja vam explicar a el pla de continuïtat que ningú ha assajat, on el problema era que el paper deia «restaurar» sense que ningú hagués cronometrat el verb.
El que el proveïdor pot moure per tu és trànsit, no estat
El desglossament d'impacte per servei es llegeix bé al costat de la cronologia, i el que en surt no és el que un esperaria. Les màquines virtuals de Compute Engine van patir «impossibilitat d'accedir-hi des de l'exterior, i impossibilitat que arribessin a recursos remots»: ningú no les va moure, es van quedar on eren fins que algú va tornar a endollar la fibra. Les bases de dades gestionades —Cloud SQL, AlloyDB, Spanner, Bigtable, Filestore— van tenir «accés a dades i connectivitat tallats per a instàncies localitzades estrictament a la infraestructura afectada»: les que vivien en un sol lloc, van caure. I Kubernetes va tenir «clústers i nodes inabastables dins de la zona afectada, provocant temps de recuperació de clúster retardats»: capa alta, i tot i així ningú no el va evacuar.
Els únics que es van moure sols van ser Cloud Run i App Engine: «pics de latència temporals i cancel·lació de peticions en cua mentre les càrregues del backend s'evacuaven automàticament i es desplaçaven a capacitat sana». Sense que ningú truqués a ningú. I ara la part que descol·loca: van ser també els últims a tornar. A l'avís de les 11:36, quan la resta ja figura recuperada, els dos únics productes que Google continua anomenant són Cloud Run i App Engine; i l'informe diu que la seva degradació va durar «fins a les 11:52». És a dir, l'hora de fi oficial de l'incident és la seva, no la de la xarxa.
La lectura fàcil seria «com més amunt és la capa, millor». No és això el que diu l'informe. El que diu és que el proveïdor pot moure trànsit sense preguntar-te, i que això té un preu propi: la commutació automàtica també té la seva pròpia recuperació, i en aquest cas va ser la més llarga de totes. Pujar les teves màquines virtuals a un núvol no et compra commutació; et compra una zona. I triar una capa que sí que commuta sola no et compra que sigui instantani. Són dues coses diferents i totes dues s'han de pressupostar.
La mitigació que van publicar era una decisió de fa mesos
En plena caiguda, l'avís d'estat va publicar el seu apartat de workaround. Deia dues coses. Una: «els clients greument afectats que tinguin serveis disponibles en zones alternatives poden commutar a zones alternatives». I dues: «els clients amb reintents a la capa de servei poden veure operacions completades amb èxit, ja que només una part de la zona està afectada».
Les dues mitigacions que el teu proveïdor et pot oferir enmig d'una caiguda de quatre hores són coses que o ja tenies muntades, o no existeixen per a tu. Ningú no compra una segona zona a les 07:41 del matí amb les màquines mudes, ni fica reintents a una aplicació mentre cau. Això és literalment el que és un pla de recuperació: opcions comprades per endavant. El dia de l'incident no es decideix res; el dia de l'incident només es gasta el que ja tenies.
Dues lectures fàcils que no farem
La primera és «per això no ens refiem del núvol». No. Google va publicar un informe amb l'hora d'inici, l'hora de fi, la causa arrel, una admissió explícita que l'error va ser de procediment i el compromís de dir després què canvia. La pregunta incòmoda no és per a ells, és per a la resta: la teva última caiguda té un document així? Amb l'hora exacta, què s'estava tocant i qui ho va aprovar. Si aquest paper no existeix, el mateix canvi tornarà a passar, i la segona vegada tampoc no sabràs per què.
La segona lectura fàcil és riure's de l'enginyer, que és la que han fet gairebé tots els titulars de la setmana. És la pitjor de les dues. La frase més important de tot l'informe és la que va immediatament després de la causa arrel: «la naturalesa de l'error, combinada amb la velocitat de l'acció, va impedir que els avisos d'acció incorrecta arribessin a l'enginyer abans de la desconnexió completa». Hi havia avisos. No van arribar a temps.
Un procediment en què una sola persona pot arribar al 100% dels camins, i en què les alarmes van més lentes que les mans, és un problema de disseny del procediment. No de la persona. Culpar qui va estirar el cable és la manera més eficaç de garantir que el següent ho repeteixi, perquè deixa intacte l'única cosa que es podia arreglar.
I que Google va llegir l'incident així ho diu la seva pròpia acció immediata, a l'últim avís d'aquell dia: «s'ha aturat el manteniment a la regió mentre es duen a terme auditories proactives». No van aturar un equip ni una versió. Van aturar el procediment, a tota la regió, fins a revisar-lo. Quan el que falla és la manera de fer les coses, la primera mitigació seriosa és deixar de fer-les.
Què es pot fer dilluns, i quan no cal fer res
El primer és la llista d'abans: quins procediments teus poden tocar més d'un element redundant. Escrits, no de memòria. El segon és un número que gairebé ningú no té mesurat, el de quant triga el desfer —no el detectar—; i si la resposta inclou «algú hi ha d'anar», cal sumar el viatge, i sumar-lo un diumenge. El nostre últim simulacre de recuperació completa, cronòmetre a la mà, van ser 14 minuts: és una dada interna i una prova, no una promesa contractual, i el que importa no és el nostre número sinó que tu en tinguis un de mesurat en comptes d'un d'estimat. El tercer és mirar els dos workarounds de Google i preguntar-te quin dels dos tindries avui muntat.
I al maquinari, el més barat de tot: que el treball sobre un camí i el treball sobre l'altre no es signin per a la mateixa nit. És el primer que demanem per escrit quan es toca físicament un equip d'un client en una sala de colocation, i no per desconfiança: perquè separar les finestres és l'única cosa que converteix un error de mans en un incident d'un sol camí. No costa diners. Costa escriure-ho a l'ordre de treball.
Ara la part que ens ven menys i que s'ha de dir igualment: si la teva empresa aguanta quatre hores parada una vegada cada dos anys sense que es noti a la caixa, no muntis multizona. Et costarà més el remei que la malaltia. Per a una botiga amb comandes en línia, quatre hores d'un dimarts de setembre són diners comptants i sonants; per a una gestoria, són un matí estrany en què es treballa en local i es rondina. Són dues decisions diferents i totes dues són legítimes. L'única postura que no ho és consisteix a no haver fet mai el compte i descobrir la xifra el dia que passa.
El que no afirmem
- ✗L'informe és preliminar. Google diu literalment que en publicarà un de final amb les accions preventives quan acabi la investigació. No sabem què canviaran, i tot el que escrivíssim sobre això seria inventat.
- ✗No sabem en què va consistir l'«error de procediment». Si va ser una ordre de treball mal redactada, un etiquetatge equivocat, un rack confós o uns passos en mal ordre, l'informe no ho diu. La nostra lectura sobre el que és seqüencial es basa en la paraula que fa servir Google, no en una reconstrucció de l'error.
- ✗La segona meitat de l'incident la reconstruïm amb els avisos d'estat, no amb una explicació de Google. Que la xarxa estigués recuperada a les 09:19 i l'incident tanqués a les 11:52 són dues dades publicades; per què Cloud Run i App Engine van trigar més, no ho diu ningú, i nosaltres tampoc.
- ✗Sabem que hi havia avisos i que no van arribar a temps, però no quin sistema els emet ni quant triga normalment. Que les alarmes fossin més lentes que les mans és el que diu l'informe; el perquè, no.
- ✗Només es va veure afectada una part de la zona
us-central1-b, i el mateix avís repeteix que «les zones restants de la regió no es van veure afectades». La contenció a nivell de regió va funcionar. Dir-ho forma part d'explicar bé l'incident, encara que sigui la part que menys titular dóna.
La redundància emmascara el que passa per casualitat. No emmascara el que passa a propòsit, ordenadament i amb la llista al davant. Si ningú no ha mirat mai quins procediments de casa teva poden recórrer tots els teus camins, la teva arquitectura d'alta disponibilitat té un supòsit sense verificar a la base — i aquests supòsits es comproven una sola vegada, sols, i a l'hora que ells trien. La fallada és inevitable. L'avaria, un altre cop, és una decisió de disseny.
Fonts (verificades el 7-set-2026): incident J5ia5t9p3g9Q5Wi7r8Ev de Google Cloud —informe preliminar publicat el 3-set amb dates, durada de 4 h 11 min, paràgraf d'arquitectura de xarxa, causa arrel («sequentially unplugged 100% of fiber paths across all devices within 13 minutes»), la frase sobre els avisos que no van arribar a l'enginyer, la detecció immediata i el desglossament d'impacte per servei; i els avisos d'estat del mateix 1-set, d'on surten la recuperació de la xarxa a les 09:19, l'estat de Cloud Run i App Engine a les 11:36, els dos workarounds, «the remaining zones in the region are unaffected» i l'aturada del manteniment a la regió—: status.cloud.google.com. Emmascarament de l'error d'operador, canvis durant «scaling or replacing hardware» i proporció d'errors de configuració: Oppenheimer, Ganapathi i Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX USITS 2003 (cites del text complet). Els 14 minuts del simulacre són una dada interna d'everyWAN: un mesurament propi, no un compromís de servei. Les traduccions de les cites són nostres; els originals són en anglès.
Quin canvi teu pot tocar totes les teves còpies alhora?
A everyWAN dissenyem la recuperació amb el compte fet al davant: quins procediments poden recórrer tots els teus camins, quant triga de debò el tornar enrere —cronòmetre a la mà, no estimat— i quina part d'això compensa pressupostar en el teu cas. Si mai no has mesurat aquest segon número, és per on comencem.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN