Resumo

  • Um incidente crítico atingiu múltiplos racks e nós de MKC1 a partir de 11h10 UTC de 19 de agosto, afetando em momentos diferentes GPUs, DOKS, conectividade e operações de cluster.
  • Às 19h34, DigitalOcean marcou o caso como resolvido após recuperar o plano de controle e serviços gerais, embora GPU Droplets continuassem afetados e a restauração de todos os nós ainda estivesse em andamento.

O encerramento de um incidente regional não precisa coincidir com o retorno da última carga. Em MKC1, a própria cronologia da DigitalOcean mostra essa diferença: a camada comum de Kansas City estava saudável quando a empresa encerrou o registro público, mas parte da infraestrutura GPU continuava em recuperação.

O primeiro aviso saiu às 11h10min06s UTC. O problema atingia múltiplos racks e nós, com risco de interrupção para cargas GPU e de nós de trabalho do DigitalOcean Kubernetes (DOKS) entrarem em NotReady. A classificação publicada foi de impacto crítico.

Às 12h22, a DigitalOcean afirmou ter identificado a causa raiz e iniciado a correção, sem divulgar qual era a causa. O alcance descrito incluía cargas GPU, Serverless Inference, trabalhadores DOKS, endpoints da API Kubernetes e operações de administração de clusters afetados. Às 15h28, equipes ainda restauravam a conectividade e traziam nós de volta. Não foram publicados números de racks, nós, clusters ou clientes.

A atualização das 18h59 dividiu o cenário em duas partes. Na primeira, o plano de controle regional estava plenamente saudável. CPU Droplets, Managed Databases, Load Balancers, Block Storage e Spaces operavam normalmente. Criação, redimensionamento e outras ações de gestão de Droplets funcionavam, e os planos de controle DOKS estavam acessíveis.

Na segunda parte, GPU Droplets em MKC1 permaneciam offline ou inacessíveis. Nós de trabalho GPU do DOKS ainda poderiam ficar NotReady, e endpoints de inferência apoiados por GPU poderiam continuar indisponíveis. A DigitalOcean informou que observaria o plano de controle por um curto período e então resolveria o incidente regional. Os clientes de GPU receberiam atualizações personalizadas por Slack e e-mail no lugar da página de status.

Às 19h34min54s, o estado mudou para resolved. O texto final repetiu que o plano de controle e os serviços gerais estavam normais, mas também disse que GPU Droplets seguiam afetados e que a restauração de todos os nós continuava. Assim, as 8 horas, 24 minutos e 48 segundos do registro público formam uma janela de gestão cujo escopo mudou ao longo do dia. Não são uma duração comum de indisponibilidade para todos os produtos e clientes.

O contexto de lançamento torna o episódio relevante para o mercado de infraestrutura de IA. A DigitalOcean havia inaugurado MKC1 em 4 de agosto, apenas 15 dias antes. O anúncio descrevia um data center totalmente refrigerado a líquido, com GPUs NVIDIA B300 e uma oferta ampla que incluía computação, DOKS, bancos de dados, armazenamento, rede, App Platform e Functions. Não existe evidência de que o resfriamento ou o modelo de GPU tenham causado o incidente. O fato verificável é que uma região nova, com GPU no centro de sua proposta, enfrentou cedo um teste público de recuperação.

A separação entre controle e execução aparece com nitidez no DOKS. A DigitalOcean administra o plano de controle Kubernetes; as aplicações dos clientes usam nós de trabalho. Recuperar a API permite inspecionar e operar o cluster, mas não devolve a capacidade de um acelerador preso a um trabalhador que permanece NotReady. Há uma função documentada de remediação automática de nós, porém ela está em prévia pública, é opcional e depende de condições, períodos de tolerância, ações e limites de remediações simultâneas. O registro não mostra que clientes afetados a ativaram.

Também faltam respostas que não podem ser inventadas. A DigitalOcean disse ter identificado a causa e mencionou trabalho com a instalação, mas não informou o mecanismo. Isso não prova falha de energia, refrigeração, rede, hardware ou software. Não há contagem de clientes, horário público para a volta de todos os GPUs, conclusão sobre perda de dados ou integridade de cargas, nem plano detalhado de prevenção. Um componente que aparece operacional mais tarde não fornece retroativamente esses dados.

Para quem opera nuvem, o sinal regional deve ser combinado com prontidão dos trabalhadores, alocação de aceleradores, alcance dos endpoints e métricas da aplicação. Em 19 de agosto, cada camada voltou no seu tempo. A região atingiu o limiar usado pela DigitalOcean para fechar o incidente geral, enquanto a capacidade GPU — mais escassa e menos substituível — permaneceu numa fila específica para clientes.

Fontes