Caiguda d'Azure: quatre portes i el lloc on guardaves el pla B

Microsoft llista cinc serveis afectats a la caiguda d'Azure del 30 de setembre. Quatre són el camí fins a la teva infraestructura: ExpressRoute Gateway, VPN Gateway, Azure Firewall i Application Gateway amb el seu WAF. El cinquè és Azure VMware Solution.

Si la teva empresa és a Espanya i no té guàrdia de nit, probablement te'n vas assabentar al matí. Va començar a les 22:30 del dimecres, hora peninsular, i es va donar per mitigat a les 04:15 del dijous: cinc hores i quaranta-cinc minuts. L'expedient porta l'identificador 7Q30-010 i continua publicat a l'històric d'estat d'Azure, que és d'on surt tot el que se cita aquí.

Quatre portes i un destí

Les quatre primeres entrades de la llista són la vora de la teva xarxa a Azure: per allà aterra la línia dedicada, per allà entren els túnels i per allà surt el trànsit que publiques a internet. La cinquena, Azure VMware Solution, és una altra cosa: allà dins hi corren màquines virtuals. Si el teu pla de contingència per a l'entorn VMware passa per AVS, el dia 30 el camí i el possible destí eren a la mateixa llista de serveis afectats.

Convé dir de seguida el que el comunicat no documenta, perquè és tan important com el que sí: en cap moment no parla de pèrdua de màquines ni de dades. El que descriu és això, literalment: «a subset of customers using gateway services in multiple regions experienced degraded or interrupted network connectivity. Impacted customers may have observed gateways failing to load in the Azure Portal, along with failures or delays in network management operations across the following impacted services».

Fixa't en el may have observed: Microsoft ho deixa en condicional, i nosaltres ho deixem igual. La segona meitat d'aquesta frase és la que converteix un incident del proveïdor en un incident teu. Les passarel·les podien no carregar al portal, i les operacions de gestió de xarxa podien fallar o retardar-se. El que quedava en dubte, doncs, era la capacitat de tocar la xarxa. Si el teu procediment de contingència diu «si cau la línia principal, aixequem el túnel de reserva des del portal», aquest procediment necessitava precisament allò que estava en dubte.

Què diu Microsoft que va passar

L'explicació ocupa quatre frases i una cinquena amb la mitigació. Van senceres, sense retallar, perquè el detall importa:

L'atribució de Microsoft és clara i convé no retòrcer-la: el canvi del gestor de passarel·les és the contributing, i és el que es reverteix. El manteniment de sistema operatiu només es pausa as a precaution. Qui vulgui la versió curta ja la té: algú va posar un canvi, el canvi va generar més càrrega de la prevista i, en revertir-lo, el servei va tornar.

El que ens interessa és a la primera frase, i és una lectura nostra que marquem com a tal. La càrrega va aparèixer quan un manteniment unrelated —aliè, sense relació amb el canvi— anava avançant gradually per diverses regions. Ningú que revisés el canvi del gestor de passarel·les tenia motiu per obrir el calendari del manteniment de sistema operatiu: eren dues feines diferents sobre coses diferents. I avançar per fases, que és la bona pràctica i el que recomanem sempre, allarga en el temps la finestra en què dues feines sense relació poden coincidir sobre la mateixa infraestructura.

Això no reatribueix res: el canvi continua sent el que va contribuir. El que afegeix és una pregunta de governança que val per a qualsevol empresa, no només per a un hiperescalar. Un desplegament per fases respon bé a «trenca res aquest canvi?». No respon a «què més està rodant ara mateix per aquesta infraestructura?». I aquesta segona pregunta gairebé mai no té amo. La mateixa Microsoft diu que continua investigant «the scaling behavior and the safeguards needed to help prevent recurrence».

El mecanisme del final de la cita mereix una línia. El gestor escalava sol normalment; la demanda sobre els serveis dels quals depèn va pujar a causa d'aquella càrrega extra, i això va impedir que els serveis regionals escalessin com s'esperava. Hi ha allà una cadena de dependències que se satura sencera, que és just el que converteix un autoescalat en un ornament. Vam explicar fa un mes el cas d'una redundància que no va sobreviure a un procediment, i la família del problema és la mateixa: un supòsit que ningú no va arribar a escriure.

El rellotge, que és la part incòmoda

El comunicat publica sis marques de temps. Les restes de l'última columna són nostres, fetes sobre aquestes marques:

Gairebé una hora fins a començar a investigar, i quan van començar va ser per un servei en una regió. Gairebé dues hores fins a identificar que el problema abastava diverses. Dues hores i mitja fins a lligar caps amb el manteniment. A partir d'aquí va quedar tancat en tres hores i deu. Entendre què estava passant va costar bastant més que arreglar-ho. Això no va d'assenyalar Microsoft: si a Microsoft li costa dues hores i mitja correlacionar dues feines pròpies, amb tota la seva telemetria, les teves opcions de correlacionar un canvi teu amb un del teu proveïdor —a cegues, de nit i sense veure el seu calendari— són bastant pitjors.

Quantes regions: la xifra que no és a la font

Aquests dies circula una xifra concreta: 18 o 19 regions. Hem anat a buscar aquest número a l'històric d'estat i no hi és: el registre oficial diu «multiple regions», sense quantitat. L'única llista de regions que arriba a donar apareix a la marca de les 01:36, i es refereix a les que quedaven per recuperar: «including France Central, North Europe, Southeast Asia, UK South, and UK West». Abans d'això només n'anomena una, UK South, que és per on va començar a investigar a les 21:29. Aquest including indica a més que ni tan sols aquesta enumeració està tancada. Pot ser que aquesta xifra sigui correcta; simplement no es pot verificar contra la font primària, i per això aquí no la fem servir com a dada.

Hi ha un detall més, escrit a la capçalera de la mateixa entrada, que explica força per què els números ballen: «Incorrect Region: correction: Impacted region(s) within a previous communication has been corrected». Microsoft va corregir la llista de regions respecte d'una comunicació anterior. Portat a la pràctica: l'avís que vas llegir en calent, mentre decidies si commutaves o esperaves, no és l'avís que queda. Qui aquella nit va decidir amb el criteri «la meva regió no surt a la llista» estava fent servir una dada que després va canviar. Ja vam escriure sobre aquesta mateixa mena de lletra petita en llegir el perímetre que publica el proveïdor, quan explicàvem que el teu núvol aguanta perdre una zona, no una regió.

Tres coses que sí que estan a la teva mà

No pots evitar que al teu proveïdor se li creuin dues feines. Pots aconseguir que la pròxima nit així et surti més barata. Tres coses concretes, comprovables aquesta setmana:

• Comprova per on administres quan el portal no respon. Si l'única via per tocar el tallafoc o la passarel·la és la consola del proveïdor, un incident del pla de gestió et deixa sense mans. Val la pena escriure quina és la via alternativa i, sobretot, provar-la un cop amb el portal tancat expressament.
• Mesura el camí, no només el destí. Una monitorització que únicament comprova que la màquina virtual respon des de dins del núvol es queda en verd durant un incident de passarel·la. Nosaltres mesurem latència i pèrdua extrem a extrem amb Zabbix i SmokePing precisament per això: el símptoma que importa és el que veu l'usuari des d'on és.
• Cronometra el pla. La pregunta útil és quant vas trigar l'última vegada que el vas executar de debò. El nostre últim simulacre de recuperació completa van ser 14 minuts: és una dada interna, d'una prova pròpia, i la donem com a prova i no com a promesa. El que val allà és haver posat el cronòmetre.

L'informe que ho explicarà arribarà, en teoria, a mitjan octubre

El comunicat inclou un compromís: «Once that is completed, generally within 14 days, we will publish a Post Incident Review (PIR) to all impacted customers». Convé llegir-ho amb cura, perquè hi ha dos supòsits encadenats. Els catorze dies comencen a comptar quan acabi la retrospectiva interna, i d'aquesta retrospectiva no hi ha data publicada, així que la nostra estimació de mitjan octubre és això, una estimació. I aquest to all impacted customers assenyala els afectats: el document que diria quina salvaguarda han posat —i per tant si el teu disseny ha de canviar— va dirigit a ells.

D'aquí la insistència amb les alertes d'Azure Service Health configurades amb un destinatari real. La notificació en calent arriba tard i amb la llista de regions a mig corregir, però és el canal pel qual després arriba l'anàlisi, i aquesta anàlisi és l'únic que serveix per redissenyar res.

El conflicte d'interès al davant, com sempre: everyWAN viu de dissenyar i operar infraestructura i cloud, així que quan diem «mesura el camí» descrivim una cosa que facturem. El que no depèn de nosaltres és el comprovable: l'incident 7Q30-010 està publicat i enllaçat al final, les cites van en anglès i literals, i les restes de la taula les pot refer qualsevol amb les sis marques de temps.

Fonts (verificades el 5 d'octubre del 2026): finestra d'impacte, llista de serveis afectats, descripció del símptoma, explicació de Microsoft sobre el que sap fins ara, reversió del canvi contribuent, les sis marques de temps, la nota de correcció de regions i el compromís del PIR — històric d'estat d'Azure, incident 7Q30-010 («Mitigated- Multiple services experiencing connectivity issues in multiple regions», 30-09-2026). Totes les cites en cursiva estan preses literalment d'aquesta entrada. Són nostres els elements següents, i així s'indiquen al text: la conversió a hora peninsular (UTC+2), les durades de la taula, l'estimació de mitjan octubre per al PIR i la lectura sobre la finestra que obre un desplegament per fases. La xifra de 18-19 regions que circula aquests dies no apareix al registre oficial i per això no s'utilitza aquí. La dada dels 14 minuts del simulacre de recuperació és interna d'everyWAN, d'una prova pròpia, i s'ofereix com a prova i no com a compromís contractual. Fotografia de portada: «Cable closet bh.jpg», Wikimedia Commons, domini públic; retallada i enfosquida per nosaltres.