• Azure Databricks relatou dois incidentes distintos na região central dos EUA em 5 de setembro, ambos afetando a inicialização de recursos computacionais e a execução de tarefas
  • Os dois incidentes foram resolvidos, e os relatórios de status disponíveis não estabelecem que tiveram a mesma causa

O fato

Azure Databricks relatou dois incidentes de serviço distintos na região central dos EUA em 5 de setembro. O primeiro, ES-2194668, afetou Classic Compute, Declarative Pipelines e Jobs. Os problemas relatados incluíram falhas na inicialização de clusters, clusters presos nos estados Pending ou Starting, falhas ao anexar notebooks e tarefas ou fluxos de processamento que falharam ou continuaram atrasados. O monitoramento de status registrou o incidente por mais de duas horas.

Um segundo incidente, ES-2195009, afetou posteriormente Compute e Unity Catalog na região central dos EUA. Os clientes voltaram a enfrentar falhas na inicialização de clusters, erros ao anexar notebooks e tarefas que falharam ou ficaram paradas enquanto os recursos computacionais eram inicializados. O incidente foi resolvido em até uma hora. Os relatórios não afirmam que os dois incidentes tiveram a mesma causa raiz. Ambos foram resolvidos separadamente e devem ser tratados como dois eventos de serviço, e não como uma única indisponibilidade contínua.

A avaliação

Ambos os incidentes interromperam o trabalho no momento em que o Databricks precisava disponibilizar recursos computacionais. Os dados, o código e os notebooks de um cliente ainda podiam estar disponíveis, mas uma tarefa agendada não podia ser executada se seu cluster permanecesse nos estados Pending ou Starting. Isso torna a inicialização do cluster uma dependência distinta da simples disponibilidade de dados armazenados na plataforma.

Em interrupções curtas, reexecutar uma tarefa pode ser suficiente. Cargas de trabalho sujeitas a prazos precisam de outro plano se não puderem esperar pela recuperação dos recursos computacionais da região. Isso pode significar ter uma forma testada de executá-las em outro local ou estruturar as tarefas para que possam ser retomadas após uma inicialização atrasada. Como não foi demonstrado que os dois incidentes têm a mesma causa, ainda não se pode presumir que uma única correção técnica seja suficiente para ambos. Para os leitores da BTW, as equipes que usam computação gerenciada precisam saber quais tarefas podem esperar e quais não podem.

Essa decisão determina se simples novas tentativas bastam ou se outra região precisa ser preparada com antecedência.

O que acompanhar

Acompanhe informações separadas sobre a causa raiz de ES-2194668 e ES-2195009, novos incidentes de computação na região central dos EUA e qualquer orientação da Databricks sobre novas tentativas ou recuperação regional. Para os clientes, a evidência útil será verificar se tarefas críticas conseguem reiniciar sem problemas após uma interrupção ou ser transferidas para outra região quando a inicialização dos recursos computacionais continuar indisponível.