El 12 de juny de 2025 Google Cloud va tenir una caiguda global, amb desenes dels seus serveis avall alhora. Als 40 minuts la mitigació estava desplegada i les regions van començar a recuperar-se, les petites primer. Una no: us-central1 no va quedar resolta del tot fins 2 hores i 40 minuts després de començar l'incident. Mateix bug, mateixa gent arreglant-lo. El que va allargar aquella regió no va ser la fallada: van ser els reintents.
Aquest post no va de Google. Va del fet que aquest mateix mecanisme està muntat, ara mateix, a la infraestructura de qualsevol empresa amb una desena de servidors i tres integracions: en un cron, a l'agent de còpies, al client de correu de cada lloc de treball i al mateix sistema de monitorització. I que ningú no ho ha escrit enlloc, perquè el reintent no es decideix: ve posat de fàbrica.
Què va passar exactament en aquella regió
L'informe públic de l'incident explica l'arrencada sense adorns: va entrar un canvi de política de quotes amb camps en blanc, i aquests camps buits «van recórrer la ruta de codi que topava amb el punter nul, i van fer que els binaris entressin en un bucle de caigudes». Fins aquí, un bug —i un que feia des del 29 de maig que estava desplegat sense protecció de feature flag, esperant que una dada amb la forma adequada el despertés—. El que va venir després és el que ens interessa: en reiniciar-se en massa, aquelles tasques «van crear un efecte ramat sobre la infraestructura de la qual depenen (és a dir, aquella taula de Spanner), i la van sobrecarregar». I una frase que hauria d'estar emmarcada a més sales de màquines: «Service Control no tenia implementat el backoff exponencial aleatoritzat apropiat per evitar això». (Les cites són traducció nostra; l'informe és en anglès.)
Per sortir del forat van haver de fer el contrari del que demana l'instint: frenar. Van limitar la creació de tasques i van desviar trànsit a bases de dades multiregionals per treure càrrega a la que s'estava ofegant. Per això la regió gran va ser l'última a tancar-se: no perquè l'arranjament fos més difícil allà, sinó perquè calia recuperar-la a poc a poc, de manera que la recuperació no la tornés a tombar.
Una tempesta de reintents és això: un sistema que ja no pot amb la càrrega en rep més precisament perquè no pot. És l'embús on tothom toca el clàxon. El soroll no desencalla la carretera; la col·lapsa una mica més.
On viu això si no tens una regió sencera
La reacció normal en llegir un informe així és «ja, però això és a escala de Google». No cal escala. Calen dues coses: un recurs compartit i unes quantes coses que insisteixin alhora. Els llocs on ens el trobem:
- ▸El
cronque triga més que el seu interval. Es va programar cada cinc minuts quan trigava dos. Avui triga set perquè la taula ha crescut. A partir d'aquell dia no hi ha un procés: n'hi ha dos, després tres, cadascun barallant-se pel mateix bloqueig de base de dades. Ningú no va canviar res; només va créixer la dada. - ▸La feina de còpia que falla i torna a entrar. Una finestra de backup que no tanca i reintenta se solapa amb la següent. Dues passades llegint els mateixos discos fan que la tercera trigui encara més. El símptoma que es veu al panell no és «la cabina va lenta»: és «els backups triguen cada dia una mica més».
- ▸Torna la llum i arrenca tot alhora. És l'efecte ramat de la pime. Seixanta equips, vint màquines virtuals i un parell de serveis demanant DNS, controlador de domini i llicències el mateix segon. La tallada va durar quatre minuts; tornar a treballar, quaranta.
- ▸El monitoratge, que pitja just quan fa mal. A la família Nagios/Icinga hi ha dos intervals: el normal i el de reintent, que entra quan una comprovació acaba de posar-se en mal estat i que gairebé sempre es configura més curt. Són uns quants sondejos —els que van de l'estat SOFT al HARD, fins a esgotar
max_check_attempts, i després es torna a l'interval normal—, o sigui que no és cap tempesta. Però és el teu sistema de vigilància empenyent en la mateixa direcció que tots els altres, i convé saber-ho abans d'abaixar l'interval «per assabentar-nos abans». - ▸I el reintent humà. Quan alguna cosa no carrega, la gent prem F5. Quaranta persones prement F5 són una prova de càrrega no autoritzada contra un servidor que ja demanava auxili.
En cap d'aquests cinc casos no hi ha res modern: ni microserveis, ni res que soni a conferència. Hi ha una taula, una cabina o un controlador de domini, i unes quantes coses insistint-hi a sobre alhora. Que és exactament la recepta d'us-central1, només que amb tres zeros menys.
La multiplicació que ningú no va dissenyar
Hi ha un càlcul al llibre d'SRE de Google que convé tenir a mà quan algú proposa «doncs que reintenti, per si de cas». Si la base de dades no dona l'abast, i el backend, el frontend i el JavaScript del navegador fan cadascun 3 reintents —4 intents—, una sola acció d'un usuari pot acabar en 64 intents contra la base de dades (4³). Ningú no va dissenyar 64. Cada capa va posar un 3 defensiu, sense saber què feien les altres, i els tresos es van multiplicar en comptes de sumar-se.
El que diu el capítol és més tou del que ens agradaria: pensa en el servei com un tot, decideix si de debò necessites reintentar en aquell nivell i, sobretot, «evita amplificar els reintents llançant-los en diversos nivells». La nostra regla és més dura, i la signem com a nostra: reintenta en un sol lloc, el de més amunt, i deixa que la fallada pugi neta per les capes de sota. Un error que arriba ràpid a l'usuari és informació. Un error que rebota deu vegades pel camí és càrrega.
Els quatre números que cal tenir escrits
No és un projecte. Són quatre valors que algú ha de decidir i deixar per escrit, i que avui a la majoria de llocs són on els va deixar l'instal·lador:
- 1El temps d'espera. Sense un timeout explícit no hi ha reintent que valgui: hi ha connexions penjades acumulant-se fins que s'esgota el pool. Un temps d'espera és la promesa d'alliberar el recurs encara que la resposta no arribi mai.
- 2El sostre d'intents. Google fa servir un pressupost de fins a tres intents per petició; si ha fallat tres vegades, deixen que l'error pugi a qui ha fet la crida. El raonament és senzill: si una petició ha caigut tres vegades en tasques saturades, és poc probable que la quarta arregli res.
- 3L'espera creixent i aleatòria. «Fes servir sempre backoff exponencial aleatoritzat en planificar reintents», diu el llibre. L'important d'aquesta frase no és «exponencial»: és «aleatoritzat». Si mil clients esperen exactament un segon, d'aquí a un segon tindràs mil clients una altra vegada. L'aleatorietat és el que reparteix el ramat; és exactament la peça que faltava a la regió que va trigar 2 h 40.
- 4El pressupost global. Amb el sostre per petició no n'hi ha prou, perquè moltes peticions amb sostre petit continuen sumant. Per això, a Google, cada client vigila quina proporció del seu trànsit són reintents i només reintenta mentre aquesta proporció estigui per sota del 10%. La xifra publicada és contundent: amb sostres per petició, el creixement en el pitjor cas es queda una mica per sota de 3x; afegint el pressupost del 10%, en el cas general baixa a 1,1x. La versió per a qui no té aquest mecanisme: «com a molt 60 reintents per minut en un procés; superat això, no reintentis, falla».
Quatre números. Cap no costa diners. El que costa és la conversa de decidir-los, perquè obliga a admetre que hi ha peticions que és millor deixar caure.
Quan NO tocar els reintents
Diríem una ximpleria si el missatge fos «treu els reintents». Un reintent ben posat és el que fa que un microtall de xarxa no arribi mai a l'usuari. Però hi ha dues operacions que no admeten reintent automàtic i convé tenir-les escrites abans que els quatre números: les que no es poden repetir sense conseqüències —un cobrament, un enviament de comanda, un correu: si no pots garantir que repetir-la és innòcua, el reintent no et dona resiliència, et dona duplicats que algú netejarà a mà— i els errors que no canviaran: un 401 o un 404 no milloren per insistir. Reintentar serveix per al que és transitori, no per a un «no» ferm.
I hi ha una tercera cosa que no faríem: muntar una plataforma per arreglar això. Aquí discrepem del discurs habitual. No cal una malla de serveis, ni un producte de resiliència, ni un redisseny. Calen quatre valors decidits i un inventari de qui reintenta a qui. Si algú et ven el primer abans que hagis escrit el segon, t'està venent la part cara.
El pitjor moment no és la caiguda: és l'arrencada
El que fa especial el cas del 12 de juny és que la tempesta no va passar durant la fallada, sinó en tornar. Tot va arrencar alhora i es va trepitjar. I aquesta és justament la part que ningú no assaja, perquè els simulacres solen mesurar «quant trigo a restaurar» i gairebé mai «què passa quan 200 coses tornen alhora i totes volen autenticar-se, resoldre noms i llegir del mateix lloc».
Nosaltres cronometrem recuperacions completes de forma periòdica —l'últim simulacre intern va sortir en 14 minuts, i ho expliquem com a prova, no com a promesa contractual— i el que s'aprèn allà no és el temps: és l'ordre. Què ha d'estar en marxa abans que què, què convé arrencar escalonat i quina integració es posa nerviosa si la seva dependència triga trenta segons de més. Aquest ordre s'escriu una vegada i val per a la resta d'ensurts. Sobre per què un pla sense assajar és literatura, ja en vam parlar aquí: el pla de continuïtat que ningú no ha assajat.
Hi ha un parentiu evident amb l'alta disponibilitat: un clúster tampoc no evita la caiguda, l'escurça. El reintent és el mateix a l'inrevés: no evita la fallada i, mal posat, l'allarga.
Cinc preguntes per a la propera reunió
Amb una regla: «sí» no compta com a resposta. La resposta és un número o un lloc on està escrit.
- 1.Quantes capes hi ha entre l'usuari i la base de dades, i quantes reintenten? Si ningú no ho sap, el número real és el producte, no la suma.
- 2.Quines tasques programades triguen avui més del que dura el seu interval? És una consulta, no una opinió: la durada mitjana és a l'històric.
- 3.Les esperes entre reintents porten aleatorietat, o tots els clients tornen el mateix segon?
- 4.Quines operacions NO s'han de reintentar mai automàticament? Si la llista és buida, és que no s'ha mirat.
- 5.Quan torna la llum, què arrenca primer i què espera? Si la resposta és «tot alhora», ja tens escrita la propera incidència.
La part incòmoda
Un estudi ja clàssic sobre per què fallen els grans serveis d'internet (Oppenheimer, Ganapathi i Patterson, USENIX 2003) va situar l'error de l'operador —i dins seu, en més de la meitat dels casos, els errors de configuració— al capdavant de les caigudes de servei en dos dels tres serveis que va estudiar. Amb un matís que els mateixos autors subratllen i que ja vam explicar en parlar de per què la redundància no sobreviu al procediment: no és que l'operador falli més que el maquinari, és que els seus errors s'emmascaren menys. La redundància tapa el disc mort; no tapa qui toca producció. Vint-i-tants anys després, la fotografia de juny de 2025 rima: un canvi de configuració amb camps buits, una ruta de codi sense protegir i, sobretot, una decisió que ningú no va prendre —com es reintenta— allargant el pitjor cas fins a les dues hores i quaranta.
La fallada és inevitable. L'avaria —que la teva empresa deixi de funcionar, i durant quant— continua sent una decisió de disseny. Els reintents són d'aquelles decisions que es prenen soles si no les pren ningú.
A everyWAN això ho mirem on es veu: a la plataforma que sosté les aplicacions de negoci (dades i aplicacions), a la infraestructura que hi ha a sota (infraestructura i cloud) i al monitoratge, que ha de distingir un servei lent d'un servei que s'ofega per insistència pròpia. Fem servir Zabbix i SmokePing, amb una regla que se'ns nota: alertes que importen, no soroll.
Fonts (verificades el 28-set-2026): informe públic de l'incident de Google Cloud del 12 de juny de 2025 —bucle de caigudes, efecte ramat sobre Spanner, absència de backoff exponencial aleatoritzat i temps de recuperació per regió— status.cloud.google.com; pressupost de tres intents, ràtio de reintents del 10% i creixement de 3x a 1,1x — Google SRE Book, «Handling Overload»; multiplicació 4³ = 64 intents, backoff exponencial aleatoritzat, pressupost de 60 reintents per minut i reintentar en un sol nivell — Google SRE Book, «Addressing Cascading Failures»; causes de caiguda en grans serveis — Oppenheimer, Ganapathi i Patterson, Why Do Internet Services Fail, and What Can Be Done About It?, USENIX 2003. La dada de 14 minuts és un simulacre intern d'everyWAN: un mesurament, no un compromís de servei.
Saps quantes coses reintenten contra la teva base de dades ara mateix?
Ho mirem amb tu: qui reintenta a qui, quines feines se solapen i en quin ordre ha de tornar tot després d'una tallada. Sense vendre't una plataforma pel camí.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN