Indisponibilidade da Snowflake: o que revela um incidente cloud sobre as suas dependências
A Snowflake registou o incidente INC20000199 entre as 07:00 e as 08:30 UTC, com impacto na disponibilidade do serviço. A indisponibilidade da Snowflake é um bom lembrete de que os processos de dados também precisam de um plano quando a plataforma não responde.
Resumo da notícia
Segundo a página de estado do próprio fornecedor, o incidente INC20000199 prolongou-se aproximadamente entre as 07:00 e as 08:30 UTC. Limitamo-nos a esse dado confirmado: houve um período de degradação e posterior recuperação. Não abordamos causas que o fornecedor não tenha detalhado publicamente.
Uma hora e meia parece pouco. Deixa de parecer quando esse período coincide com o carregamento noturno que alimenta os painéis de indicadores da manhã, com a sincronização que fornece dados a um ERP ou com o processo que calcula preços e stock antes da abertura. O impacto não se mede em minutos de indisponibilidade, mas em processos que se atrasam em cadeia.
A análise da Seintec é que nas atuais arquiteturas de dados o risco mudou de lugar: já não está no servidor, está no encadeamento. Um atraso na origem propaga-se à ingestão, às transformações, aos relatórios e às decisões que deles dependem. E muitas organizações não têm visibilidade dessa cadeia até que ela se rompe.
Há medidas simples e eficazes. Programar novas tentativas com intervalos de espera progressivos evita que uma falha transitória deixe um processo indisponível toda a manhã. Conceber carregamentos idempotentes permite voltar a executá-los sem duplicar dados. E emitir alertas por atraso no processo, e não apenas por erro, permite detetar o problema antes de a direção o detetar.
Também convém decidir antecipadamente o que acontece à informação enquanto o serviço não responde: se é descartada, se é acumulada numa fila ou se é conservada num armazenamento intermédio para ser reprocessada mais tarde. Essa decisão, tomada com ponderação, evita reconciliações manuais.
Nenhum fornecedor oferece disponibilidade absoluta, e não é razoável exigi-la. O razoável é conhecer o SLA contratado, saber que processos internos dependem dele e ter documentado o que fazer durante o período em que o serviço não responde.
Fonte: Snowflake Status / Keboola — 4 de setembro de 2026
O que aconteceu
Segundo a página de estado do próprio fornecedor, o incidente INC20000199 da Snowflake prolongou-se aproximadamente entre as 07:00 e as 08:30 UTC. Este é o dado confirmado: houve um período de degradação e posterior recuperação, sem que o fornecedor tenha detalhado publicamente as causas.
Uma hora e meia parece pouco até esse período coincidir com o carregamento noturno que alimenta os painéis de indicadores da manhã, a sincronização que fornece dados a um ERP ou o processo que calcula preços e stock antes da abertura.
O que ensina a uma empresa de média dimensão
Nas arquiteturas de dados atuais o risco mudou de lugar: já não está no servidor, está no encadeamento. Um atraso na origem propaga-se à ingestão, às transformações, aos relatórios e às decisões que deles dependem, e muitas organizações não têm visibilidade dessa cadeia até esta se romper.
Nenhum fornecedor oferece disponibilidade absoluta, e não é razoável exigi-la. O razoável é conhecer o SLA contratado e ter por escrito o que fazer enquanto o serviço não responde.
O que convém rever
Medidas concretas para processos que dependem de um fornecedor cloud de dados:
- Novas tentativas com tempos de espera progressivos para que uma falha transitória não deixe um processo parado toda a manhã.
- Carregamentos idempotentes que permitam voltar a executar o processo sem duplicar dados.
- Alertas de atraso no processo, não apenas de erro, para detetar o problema antes da direção.
- Decisão prévia sobre o destino dos dados enquanto o serviço não responde: descartar, colocar em fila ou conservar para reprocessamento.
Perguntas frequentes
- ¿Quanto tempo durou o incidente da Snowflake?
- O fornecedor registou o incidente INC20000199 com um período aproximado entre as 07:00 e as 08:30 UTC. Os detalhes das causas não foram tornados públicos.
- ¿Faz sentido replicar os dados noutra plataforma por precaução?
- Só quando o custo da paragem supera o da duplicação. Na maioria das PME é mais rentável conceber processos tolerantes a atrasos do que manter uma segunda plataforma em paralelo.
- ¿É conhecida a causa técnica do incidente?
- Não. O fornecedor confirmou o período de degradação e recuperação, mas não detalhou publicamente as causas.
Conceitos mencionados neste artigo: Cloud · Armazenamento
Se as suas decisões dependem de dados que circulam por várias plataformas, convém saber onde se quebra a cadeia. Na Seintec auditamos a sua arquitetura cloud e as respetivas dependências, e propomos melhorias concretas de resiliência. Peça uma auditoria cloud.
Contactar a SeintecServiço relacionado
Serviços Cloud
Serviços na nuvem para expandir a sua empresa.