Caiguda de Snowflake: què revela un incident cloud sobre les vostres dependències
Snowflake va registrar l'incident INC20000199 entre les 07:00 i les 08:30 UTC, amb impacte en la disponibilitat del servei. La caiguda de Snowflake és un bon recordatori que els processos de dades també necessiten un pla quan la plataforma no respon.
Resum de la notícia
Segons la pàgina d'estat del propi proveïdor, l'incident INC20000199 es va prolongar aproximadament entre les 07:00 i les 08:30 UTC. Ens cenyim a aquesta dada confirmada: va haver-hi una finestra de degradació i posterior recuperació. No entrem en causes que el proveïdor no ha detallat públicament.
Hora i mitja sembla poc. Deixa de semblar-ho quan aquesta finestra coincideix amb la càrrega nocturna que alimenta els quadres de comandament del matí, amb la sincronització que proveeix un ERP o amb el procés que calcula preus i estoc abans d'obrir. L'impacte no es mesura en minuts de caiguda, sinó en processos que arriben tard en cadena.
L'anàlisi de Seintec és que en les arquitectures de dades actuals el risc s'ha desplaçat: ja no es troba al servidor, sinó en l'encadenament. Un retard en l'origen es propaga a la ingesta, a les transformacions, als informes i a les decisions que en depenen. I moltes organitzacions no tenen visibilitat d'aquesta cadena fins que es trenca.
Hi ha mesures senzilles i eficaces. Programar reintents amb espera progressiva evita que una fallada transitòria deixi un procés caigut tot el matí. Dissenyar càrregues idempotents permet rellançar sense duplicar dades. I alertar per retard de procés, i no només per error, detecta el problema abans que el detecti la direcció.
També convé decidir per endavant què passa amb la informació mentre el servei no respon: si es descarta, si s'acumula en una cua o si es conserva en un emmagatzematge intermedi per a reprocessar-la després. Aquesta decisió, presa en fred, estalvia reconciliacions manuals.
Cap proveïdor ofereix disponibilitat absoluta, i no és raonable exigir-la. El que és raonable és conèixer l'SLA contractat, saber quins processos propis en depenen i tenir per escrit què es fa durant la finestra en la qual no respon.
Font: Snowflake Status / Keboola — 4 de setembre del 2026
Què va passar
Segons la pàgina d'estat del mateix proveïdor, l'incident INC20000199 de Snowflake es va allargar aproximadament entre les 07:00 i les 08:30 UTC. És la dada confirmada: hi va haver una finestra de degradació i posterior recuperació, sense que el proveïdor detallés públicament les causes.
Hora i mitja sembla poc fins que aquesta finestra coincideix amb la càrrega nocturna que alimenta els quadres de comandament del matí, la sincronització que proveeix un ERP o el procés que calcula preus i estoc abans d'obrir.
Què ensenya a una empresa mitjana
En les arquitectures de dades actuals el risc s'ha desplaçat: ja no és al servidor, és a l'encadenament. Un retard a l'origen es propaga a la ingesta, a les transformacions, als informes i a les decisions que en depenen, i moltes organitzacions no tenen visibilitat d'aquesta cadena fins que es trenca.
Cap proveïdor ofereix disponibilitat absoluta, i no és raonable exigir-la. El raonable és conèixer l'SLA contractat i tenir escrit què es fa mentre el servei no respon.
Què convé revisar
Mesures concretes per a processos que depenen d'un proveïdor cloud de dades:
- Reintents amb espera progressiva perquè una fallada transitòria no deixi un procés caigut tot el matí.
- Càrregues idempotents que permetin relanç sense duplicar dades.
- Alertes per retard de procés, no només per error, per detectar el problema abans que direcció.
- Decisió prèvia sobre què passa amb les dades mentre el servei no respon: descartar, encuar o conservar per reprocessar.
Preguntes freqüents
- Quant va durar l'incident de Snowflake?
- El proveïdor va registrar l'incident INC20000199 amb una finestra aproximada entre les 07:00 i les 08:30 UTC. El detall de causes no s'ha fet públic.
- Té sentit replicar les dades en una altra plataforma per si de cas?
- Només quan el cost de l'aturada supera el de la duplicitat. En la majoria de pimes és més rendible dissenyar processos tolerants al retard que mantenir una segona plataforma en paral·lel.
- Es coneix la causa tècnica de l'incident?
- No. El proveïdor va confirmar la finestra de degradació i recuperació, però no ha detallat públicament les causes.
Conceptes esmentats en aquest article: Cloud · Emmagatzematge
Si les teves decisions depenen de dades que viatgen per diverses plataformes, convé saber on es trenca la cadena. A Seintec auditem la teva arquitectura cloud i les seves dependències, i proposem millores concretes de resiliència. Demana una auditoria cloud.
Contactar amb SeintecServei relacionat
Serveis Cloud
Serveis al núvol per escalar la teva empresa.