Ahir al matí, a les 06:08 UTC, va caure una zona. Una de sola: europe-west2-b, una de les tres de la regió de Londres de Google Cloud. La causa que va publicar el tauler d'estat no va ser un desplegament mal fet, ni un certificat caducat, ni un canvi de configuració un divendres: va ser un «esdeveniment elèctric». Vuit hores més tard, la frase que més es va repetir per explicar per què uns van caure i altres no —«estem repartits en dues zones»— havia resultat ser una frase sobre etiquetes, no sobre llocs.
El que va dir Google, paraula per paraula
La nota del tauler d'estat, amb el tall marcat: «A power event caused an outage within europe-west2-b zone. The power event is mitigated. We are seeing the recovery of services and are prioritizing the recovery of existing workloads. […] Customers may not be able to yet create new workloads». Traduït: un esdeveniment elèctric va provocar una caiguda dins la zona europe-west2-b; l'esdeveniment està mitigat; s'estan recuperant els serveis i es prioritza recuperar les càrregues de treball existents; potser encara no se'n poden crear de noves. Aquella última frase val més del que sembla, i hi tornem al checklist.
The Register va recollir set productes afectats: BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, App Engine, Google Cloud NetApp Volumes, Google Kubernetes Engine i el servei gestionat d'Apache Kafka. El tauler d'estat en va acabar llistant força més, i entre ells productes regionals com Cloud Storage i Compute Engine. Aquell detall importa i hi tornem al final. Pel costat de qui ho va patir a fora: Lloyds, HSBC, Revolut, Royal Mail, Rightmove, DPD, BT i Screwfix, entre d'altres; pagaments, transferències, repartiment, portals immobiliaris i part de les vistes judicials per vídeo a Anglaterra i Gal·les. Google va avisar a les 11:58 UTC que la recuperació completa arribaria «temptativament» a les 13:00, i va marcar servei normal per a la majoria a les 14:03 UTC.
A l'hora d'escriure això no hi ha informe d'incident publicat. Google diu que n'hi haurà: «We will publish an analysis of this incident once we have completed our internal investigation». Fins llavors, què va fallar exactament —escomesa, quadre, commutació a grup electrogen, bateries— no ho sabem, i qui ho estigui afirmant en una xarxa social tampoc. El que sí que tenim és l'etiqueta de la causa i l'abast.
En aquell diagnòstic no hi ha programari. Hi ha electricitat. I l'electricitat no surt en cap diagrama d'arquitectura que ens hagin ensenyat mai en una reunió.
«Estem repartits en dues zones» no és una resposta
La documentació de Google ho diu sense adorns: «Zones and regions are logical abstractions of underlying physical resources» —zones i regions són abstraccions lògiques dels recursos físics subjacents— i «A zone is a deployment area within a region», una zona és una àrea de desplegament dins d'una regió. Abstracció lògica. Àrea de desplegament. Ni una paraula sobre sales, quadres, escomeses o grups.
La documentació d'AWS ho porta més lluny. Text literal: «the us-east-1a for your AWS account might not be the same physical location as the us-east-1a for another AWS account». És a dir: la meva zona «a» i la teva zona «a» poden no ser el mateix edifici. No és un error: va ser una decisió deliberada per repartir la càrrega, perquè si no tothom tria la primera de la llista. Per poder coordinar-se entre comptes existeixen els AZ ID, identificadors estables del tipus use1-az1, que sí que assenyalen —cita textual— «the same physical location in every AWS account».
Aquell repartiment independent ja no és general. Totes les regions posteriors al novembre del 2012 fan servir un mapatge uniforme, i des del novembre del 2025 els comptes nous també el tenen a les antigues. Però continua viu per als comptes creats abans d'aquella data en nou regions, i la llista inclou tres que surten molt en arquitectures espanyoles: Irlanda, Nord de Virgínia i Oregon, a més de Nord de Califòrnia, Singapur, Sydney, Tòquio, São Paulo i GovCloud Oest. I convé no confondre proveïdors: això és AWS, no Google; Google no documenta cap aleatorització per projecte, i no insinuarem que n'hi hagi.
El que comparteixen els dos proveïdors és el que importa: el nom d'una zona és una etiqueta de repartiment. No et diu a quina sala és, de quin quadre penja, si comparteix escomesa amb la zona del costat ni a quants metres és. El que compres és un compromís d'independència, que és una cosa seriosa i normalment es compleix. El que no compres és un plànol. Que una zona no és un edifici ja ho vam escriure al juliol, quan a Google se li'n va anar europe-west4-a per tensió i refrigeració (ho vam explicar al juliol amb europe-west4-a); avui l'angle és el pas següent: què pots auditar tu. I des de l'altre extrem, quan el que va caure va ser una regió sencera: el teu núvol aguanta perdre una zona, no una regió.
El domini de fallada més vell és el que menys es dibuixa
La redundància es pensa per capes, i gairebé tothom es queda a les dues primeres. Capa disc: mirall. Capa màquina: doble font, perquè la màquina sencera peta —memòria corrupta, penjada—. Capa sala: un centre de dades fora per tall elèctric, incendi o inundació. El corrent és per sota de les tres, i és el que pitjor es dibuixa per una raó de fons: no és un component, és la condició perquè existeixin els components. En un diagrama lògic res no està endollat a res.
El núvol públic afegeix un parany propi. Els recursos es classifiquen en zonals, regionals i globals, i aquesta classificació la posa el proveïdor producte a producte, no la teva intuïció. Un disc persistent zonal, un clúster de Kubernetes d'una sola zona o un volum de fitxers viu en una zona, encara que la teva consola digui europe-west2 i encara que la paraula «regió» aparegui tres vegades a la presentació que va aprovar el pressupost. L'arquitectura sembla regional. El recurs no ho és.
Ceph va posar nom a això fa anys, i es diu «pdu»
Per a qui té ferro propi això té nom des de fa anys. La jerarquia per defecte de CRUSH —l'algorisme amb què Ceph decideix on va cada còpia de cada objecte— té aquesta llista de tipus de cub, i hi és des de fa moltes versions: osd, host, chassis, rack, row, pdu, pod, room, datacenter, zone, region, root.
Entre row (fila d'armaris) i pod hi ha un tipus de cub que es diu unitat de distribució elèctrica. Hi és perquè qui va dissenyar això sabia exactament el que va passar ahir a Londres: que el corrent és un domini de fallada de ple dret, que no coincideix amb l'armari ni amb la fila, i que dues màquines separades per vint metres poden morir juntes si pengen de la mateixa regleta. La documentació ho diu sense circumloquis: «By reflecting the underlying physical organization of the installation, CRUSH can model (and thereby address) the potential for correlated device failures» —en reflectir l'organització física real de la instal·lació, CRUSH pot modelar, i per tant tractar, el potencial de fallades correlacionades de dispositius—.
El domini de fallada que Ceph fa servir per defecte és host: tres rèpliques en tres màquines diferents. Això protegeix que es mori una màquina, que és la fallada més freqüent, i està ben triat com a valor per defecte. Però si aquelles tres màquines són al mateix armari, i aquell armari penja d'un quadre, davant d'un esdeveniment elèctric tens tres còpies i un sol domini de fallada: a efectes del quadre, una còpia. Ceph et dirà HEALTH_OK tota l'estona, perquè està complint amb exactitud la regla que li vas escriure. El sistema no menteix; és que ningú no li va preguntar pel corrent.
La diferència entre una zona de núvol i un cub de CRUSH no és tecnològica: un es pot imprimir i l'altre no. Un ceph osd tree et treu l'arbre sencer —quin disc penja de quina màquina, de quin armari, de quina fila— en una pantalla, i el pots posar al costat de l'esquema elèctric de la teva sala i discutir-lo amb l'electricista. La «zona b» de Londres no es pot imprimir. No perquè te l'amaguin, sinó perquè per a tu no és un lloc: és una etiqueta amb un compromís al darrere. Això no fa dolent el núvol; fa que la pregunta sigui una altra. Ho vam explicar sencer quan vam parlar de com un Ceph de tres nodes no es cura sol: aguanta.
Quan NO pujar el domini de fallada
La reacció natural a tot això és dir «doncs ho pujo a rack i llestos». Direm el contrari, perquè és el que hem vist trencar-se. Si el teu pool té tres còpies i li demanes a l'algorisme un armari diferent per còpia, necessites tres armaris amb lloc i amb discos. Amb dos, CRUSH no troba on posar la tercera: els grups de col·locació es queden infrareplicats (undersized) i, segons el min_size que tinguis, el pool deixa d'acceptar escriptures tan bon punt alguna cosa més es torci.
El que has fet allà és canviar un risc de durabilitat per un problema de disponibilitat. I el segon arriba abans: el quadre elèctric et pot fallar una vegada cada molts anys, però un clúster que no accepta escriptures te'l trobes el dimarts que ve. Declarar room quan tens una sala no és resiliència, és un clúster aturat amb molt bona intenció. En un clúster de tres nodes el domini raonable gairebé sempre continua sent host.
El quadre elèctric no s'arregla amb una ordre. S'arregla amb feina d'electricista i d'inventari —dues escomeses, dos quadres, un SAI provat amb càrrega de debò— i d'això en vam escriure sencer el dia que tocava: els dos cables del teu servidor van a la mateixa regleta. El que aporta Ceph és que, un cop feta aquella feina, li ho pots dir al sistema i el sistema ho respecta.
El plànol que falta: una fila per rèplica
Aquest plànol l'omplim dret davant de l'armari, amb una llanterna, seguint cada mànega fins al seu quadre. No des de l'inventari, no des del full de càlcul de l'última auditoria, no des de la memòria del company que va muntar allò. Una fila per còpia de les teves dades.
Si dues files comparteixen quadre, tens dues còpies i no tres. Si les tres comparteixen SAI, en tens una. Tant li fa el que digui el tauler. El compte no el fa el sistema d'emmagatzematge, el fa l'electricista.
Si el teu cas és al núvol el plànol és un altre, però l'exercici és el mateix i es contesta en una tarda:
- Apunta l'identificador, no el nom. A AWS,
aws ec2 describe-availability-zones --query "AvailabilityZones[].{Name:ZoneName,ID:ZoneId}" --output tableet dona les dues columnes. Si reparteixes entre comptes o organitzacions, la que val és la de l'ID. - Marca quins recursos són zonals. Un a un, mirant la fitxa del producte i no el nom de la carpeta. El disc, el clúster, el volum de fitxers, la cua. El que sigui en una sola zona, subratllat.
- Pregunta pel pla de control. No només «sobreviu la meva aplicació a perdre una zona?», sinó «puc arrencar coses noves mentre aquella zona és caiguda?». Són dues preguntes diferents i la segona és la que decideix quant dura la mala estona.
- Posa-li data a la prova. Apagar a propòsit el que viu en una zona, en horari d'oficina, amb tothom al davant. Si la resposta a «ho podem fer dijous a les onze?» és «ni de broma», ja tens el resultat de l'experiment sense haver apagat res.
La factura que deixa Londres
De les 06:08 a les 14:03 hi ha set hores i cinquanta-cinc minuts. Un compromís de disponibilitat del 99,9% dona dret a 8 hores i 46 minuts de caiguda en tot l'any. És a dir: l'incident d'ahir, ell sol, es va menjar el 90% del pressupost anual d'un 99,9%. I som a l'octubre.
Convé a més no confondre el compromís del proveïdor amb el teu: el que tu vas signar amb els teus clients i el que el proveïdor et compensa amb crèdits de servei són dues coses diferents, i els crèdits no paguen el dia que el magatzem no va treure comandes. Sobre aquella confusió vam escriure sencer fa uns dies: el 99,9% no et diu quant dura la caiguda.
Queda una cosa que no encaixa, i és la que més ens ha fet pensar: l'aïllament de zones no va aguantar del tot. Google va acotar la causa a europe-west2-b, però el resum del seu propi tauler diu que «some services in europe-west2 region might experienced elevated errors and intermittent network issues», i entre els productes llistats n'hi ha de regionals. És a dir: ahir no n'hi havia prou amb estar repartit. El límit de la zona no va caure on el diagrama deia que queia, que és —un altre cop— l'argument d'aquest post. Dit això, la regió va continuar dempeus: Google va perdre una de tres zones i no va perdre Londres.
De quin quadre penja la segona còpia
Aquesta és la pregunta, i no admet «estem replicats» per resposta. Si ningú a la sala no la sap contestar, el que hi ha no són dues còpies: són dos llocs on és la mateixa. Nosaltres muntem emmagatzematge distribuït amb Ceph precisament quan el repartiment ha de ser una cosa que puguis assenyalar amb el dit, i la resta de la infraestructura amb l'esquema elèctric sobre la taula des del primer dia. Si vols que mirem el teu, la primera conversa és omplir aquella taula: escriu-nos.
Fonts. Nota del tauler d'estat de Google Cloud sobre l'esdeveniment elèctric a europe-west2-b i cronologia del 20 d'octubre del 2026, recollides per The Register; llista d'organitzacions afectades segons la mateixa cobertura i la de la premsa britànica. Documentació de Google Cloud, «Regions and zones» (zones i regions com a abstraccions lògiques; zona com a àrea de desplegament). Documentació d'AWS, «AZ IDs» (mapatge independent per compte, identificadors use1-az1, regions afectades i canvi del novembre del 2025). Documentació de Ceph, «CRUSH Maps» (tipus de cub de la jerarquia per defecte, fallades correlacionades, ceph osd tree) i perfils de codi d'esborrat (crush-failure-domain per defecte host). Resum i cronologia de l'incident al tauler d'estat públic de Google Cloud, consultat el 21-10-2026. El càlcul dels nous és aritmètica nostra. A data de publicació no hi ha informe d'incident públic del proveïdor; Google ha dit que el publicarà quan acabi la seva investigació interna.
Microsoft 365
ES 
CAT 
EN