El pla de control és el primer que cau, i el teu pla B el necessita

Fa un any, un dilluns a les 8:48 del matí hora d'aquí, un registre DNS es va quedar sense cap adreça a dins i va arrossegar mig internet al darrere. El que gairebé no es va explicar llavors, i consta a l'informe oficial, és què va continuar funcionant: les màquines enceses. No se'n va apagar cap. El que no es podia fer era arrencar-ne una altra.

Què va passar, amb el rellotge d'aquí

AWS gestiona els registres DNS dels seus endpoints amb dues peces automàtiques: un DNS Planner, que mira la salut dels balancejadors i escriu un pla, i un DNS Enactor, que aplica aquest pla des de tres zones de disponibilitat independents. Aquella nit un Enactor es va quedar anormalment endarrerit reintentant les seves actualitzacions. Mentrestant, un segon Enactor va aplicar un pla més nou i va disparar la neteja dels vells. Quan el primer per fi va acabar, va sobreescriure el pla nou amb el seu, ja caducat, i la neteja es va endur aquest pla obsolet: el registre dynamodb.us-east-1.amazonaws.com es va quedar sense ni una adreça a dins. La comprovació que ho havia d'evitar existia. En paraules d'AWS, «la comprovació que es feia al principi del procés d'aplicació del pla, que garanteix que el pla és més nou que l'aplicat anteriorment, ja havia caducat en aquell punt pels retards inusualment alts en el processament de l'Enactor».

L'informe dona les hores en hora del Pacífic. Traduïdes a la península, perquè s'entengui què va veure aquí qui ho va viure: la fallada va començar el dilluns 20 d'octubre del 2025 a les 8:48, just quan obrien les oficines. A les 9:38 AWS ja sabia que la causa era a l'estat del DNS de DynamoDB. A les 10:15 hi havia mitigacions temporals perquè alguns dels seus serveis interns tornessin a connectar. A les 11:25 el registre estava restaurat i a les 11:40 havien expirat les memòries cau. Dues hores i cinquanta-dos minuts. Aquest és el número que es va quedar als titulars, i és el que més enganya.

Les que ja estaven enceses no se'n van assabentar

L'informe ho diu sense adorns: les instàncies EC2 que ja estaven en marxa van continuar sanes i sense afectació. El pla de dades d'EC2 va aguantar: les màquines enceses, els seus processos i les seves connexions. El de DynamoDB no, perquè ningú no podia resoldre'n el nom, i per això una aplicació perfectament sana retornava errors. El que va rebentar del tot va ser el pla de control: la part del sistema que serveix per crear, modificar i destruir coses.

Repassa la llista del que va estar caigut i mira-la com si fos el teu procediment de recuperació, perquè s'hi assembla molt: arrencar instàncies noves, crear o actualitzar funcions Lambda, aixecar contenidors a ECS, EKS i Fargate, substituir un clúster de Redshift, demanar credencials temporals a STS, autenticar-se a la consola i entrar a la consola de suport per obrir un tiquet. Tot això és pla de control. I tot això és, gairebé literalment, el guió que executa algú a les nou del matí quan decideix que cal anar-se'n a un altre lloc.

La consola de suport, per cert, va estar inaccessible des de les 8:48 fins a les 11:40. Exactament la mateixa finestra. El canal per preguntar què està passant formava part del que estava passant.

La cua llarga: 2 h 52 min de titular, 28 h 17 min de veritat

Quan el DNS va tornar, va començar el segon acte. El subsistema que assigna feina als servidors físics d'EC2 (el DropletWorkflow Manager) va intentar renovar de cop els contractes de tots els servidors físics de la regió i, en paraules del mateix informe, «havia entrat en un estat de col·lapse congestiu i era incapaç d'avançar en la recuperació dels contractes dels droplets». Ho van arreglar a mà, frenant el ritme a les 13:14 i reiniciant servidors de manera selectiva fins a les 14:28. És exactament el patró que expliquem a la segona caiguda la provoques tu: el sistema no s'enfonsa per la caiguda, s'enfonsa per l'allau de la recuperació.

I després va venir el tercer acte, el més desagradable: les instàncies acabades de crear trigaven a tenir xarxa, el sistema de comprovació de salut les donava per bones abans d'hora, i el balancejador de xarxa les ficava i les treia en cicles —retirant capacitat sana—. AWS va acabar desactivant el failover automàtic a les 18:36. Amb les hores d'aquí posades, el quadre queda així:

Un dia i mig llarg entre el primer error i l'última cosa que AWS va donar per restablerta. (L'impacte en contenidors va arrencar tres minuts abans del minut zero, a les 8:45; la resta de la columna compta des de les 8:48.) Si vas signar un acord amb un percentatge anual de disponibilitat, aquest percentatge no et va dir res d'això, i és l'argument que desenvolupem a un percentatge anual no diu quant dura una caiguda. El que va notar l'empresa no va ser el 99 coma el que sigui: va ser que el dimarts al migdia encara hi havia clústers que no responien a una consulta perquè el reemplaçament automàtic s'havia quedat a mitges.

Per què això és un problema de pla B

Gairebé tots els plans de recuperació que llegim estan escrits amb verbs de creació. «S'aixequen les màquines a la regió secundària.» «S'escala el grup a X nodes.» «S'emet un certificat.» «Es restaura la còpia en una instància nova.» «S'obre incidència amb el proveïdor.» Són verbs que suposen que, el pitjor dia de l'any, el proveïdor et deixarà crear. I el pitjor dia de l'any és precisament el dia en què el que falla és la capacitat de crear.

Això no és una peculiaritat d'AWS. És com està construïda qualsevol plataforma gran, la seva, la del costat i la que muntis tu. Fa dues setmanes vam escriure el mateix amb un altre proveïdor i un altre símptoma —el portal no carregava i les operacions de gestió fallaven durant l'incident d'Azure del 30 de setembre—; la diferència és que aquí el proveïdor ho posa per escrit, amb noms i amb hores. La separació entre pla de control i pla de dades és una bona decisió d'enginyeria —gràcies a ella les màquines enceses van aguantar— i, alhora, és la raó per la qual la peça de la qual depèn la teva recuperació és la fràgil. Si ja vas llegir el perímetre que el teu proveïdor ja té escrit, aquesta és la segona meitat d'aquella idea: no n'hi ha prou amb saber quin perímetre de dany aguanta el teu proveïdor; cal saber quines operacions et permet fer mentre l'aguanta.

Les sis preguntes que fem a un pla de recuperació

És el que marquem en vermell quan ens asseiem amb un procediment de continuïtat al davant.

• Compta els verbs de creació. Subratlla al teu procediment cada pas que necessita que algú de fora et deixi crear alguna cosa: arrencar, escalar, emetre, proveir, demanar una IP, obrir un tiquet. El número que et surt és la superfície del teu pla que no controles.
• Mira on viu la teva identitat d'operació. Si per desplegar a Frankfurt t'has d'autenticar contra un servei global que viu físicament en un altre lloc, aquell altre lloc és al teu pla B encara que no aparegui al diagrama. Aquell dilluns STS va donar errors i latència de les 8:51 a les 18:59 d'aquí, i AWS escriu que qui feia servir credencial arrel o federació d'identitat contra signin.aws.amazon.com va tenir errors en entrar a la consola «en regions fora de» Virgínia del Nord.
• Tingues capacitat creada, no per crear. Una màquina encesa i mig buida al lloc B costa diners els 365 dies i val exactament el que val el dia que ningú no et deixa arrencar-ne cap.
• Frena els teus reintents abans de necessitar-ho. Espera creixent i una mica d'aleatorietat a cada client que reintenta. No ho arregla ningú a les nou del matí: o està escrit al codi i als proxys des d'abans, o la teva recuperació empeny en contra.
• Tingues una via de suport que no sigui la consola. Telèfon, contacte nominal, el que sigui. Si l'únic camí per obrir una incidència és el web del proveïdor i el web del proveïdor és dins l'incident, no tens canal.
• Desa el procediment fora del que cau. Un manual de recuperació que viu al mateix servei que estàs recuperant és un acudit car. El mateix per a l'inventari: nosaltres el portem a NetBox com a font de veritat, precisament per no dependre de la memòria de ningú un dilluns al matí.

On no val aquesta lectura

Declarem l'interès abans de la part incòmoda: everyWAN ven infraestructura i cloud, colocation amb maquinari propi i recuperació davant de desastres. Tenim un incentiu evident perquè aquesta història acabi en «munta-t'ho amb nosaltres». Doncs no, no acaba aquí.

Muntar-ho al teu propi maquinari no et treu del problema: te'l deixa a casa. El teu hipervisor té el seu pla de control, i si el quòrum del clúster es trenca no arrenques cap màquina nova encara que les que ja estan en marxa continuïn tan contentes; nosaltres operem Proxmox VE amb Ceph en producció i aquesta escena la coneixem. El mateix amb el directori, amb el DNS intern, amb l'autoritat que emet els teus certificats. La diferència real no és núvol contra maquinari: és si la peça que et deixa crear és en una mà, en dues, o en cap que puguis tocar. I, fent honor a la veritat, en una caiguda del teu propi pla de control hi ha una cosa que no tens amb un hiperescalador: el telèfon de qui ho pot arreglar.

L'informe que pots llegir continua sent el de fa un any

La pàgina de resums públics d'incidents greus d'AWS arrenca el 2011. Hi ha divuit entrades. El més recent, a 19 d'octubre del 2026, continua sent el d'aquell dilluns: cap del 2026 no ha entrat encara en aquella pàgina. No ho expliquem com a retret —aquest document és bo, detallat i molt més del que publiquen d'altres—, sinó com a mesura de com n'és d'estrany tenir un relat tècnic d'una caiguda gran. De gairebé totes les caigudes que t'afectaran no hi haurà mai cap informe. Quedarà una línia en un tauler d'estat que desapareix, i el que tu hagis apuntat mentre passava.

L'eix de sempre, aplicat aquí: la fallada és inevitable, l'avaria és una decisió de disseny. Que a un proveïdor se li buidi un registre DNS a les nou menys dotze d'un dilluns no està a la teva mà. Que això signifiqui que la teva empresa no pot treballar durant catorze hores sí que ho està, i es decideix mesos abans, quan algú escriu el pla B amb verbs de creació sense preguntar-se qui li ha de donar permís.

Fonts i mètode: tot el relat de l'incident, les cites literals i les hores surten del resum oficial d'AWS «Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region» — aws.amazon.com/message/101925. Les hores d'aquell document són en hora del Pacífic; la conversió a hora peninsular (nou hores més, amb tots dos fusos en horari d'estiu aquella data) i els càlculs de durada (2 h 52 min, 14 h 2 min, 14 h 21 min, 14 h 32 min i 28 h 17 min des de les 23:48 PDT del 19 d'octubre) són nostres, i qualsevol pot refer-los amb les hores de l'informe. El recompte de divuit resums publicats i el fet que el més recent sigui el del 19 d'octubre del 2025 procedeixen de la pàgina de resums d'AWS, consultada el 19 d'octubre del 2026 — aws.amazon.com/premiumsupport/technology/pes. No vam tenir cap client afectat per aquest incident ni telemetria pròpia d'aquell dia: el que expliquem del cas és lectura d'un document públic. El que diem de la nostra manera de treballar —Proxmox VE amb Ceph en producció, NetBox com a font de veritat de l'inventari— és nostre i va sense xifres: no publiquem mètriques internes que ningú no pugui comprovar.