Resumo

  • A DigitalOcean abriu o incidente às 18h57min49s UTC de 8 de agosto e declarou resolução completa à 01h01min02s do dia 9, totalizando 6h03min13s.
  • Cadastro de contas, criação de Droplets, Reserved IPs, backups e snapshots, autoscaling, DOKS, GenAI, console e criação de clusters de bancos foram listados em várias regiões.
  • A empresa disse ter identificado a causa raiz às 20h02min35s, sem divulgá-la; às 22h02min55s informou que implementava e distribuía uma correção.
  • O monitoramento começou à 00h31min29s e o encerramento veio 29min33s depois.
  • O registro sustenta uma falha de provisionamento e controle, não a afirmação de que todos os Droplets ativos, fluxos, dados armazenados, bancos existentes ou pedidos GenAI pararam.
  • Não há regiões nomeadas, número ou proporção de clientes, taxa de erro, reconciliação da fila, resultado de SLA, crédito ou correção permanente.

A disponibilidade falhou na hora do verbo

Criar, alocar, escalar, salvar, acessar: a lista da DigitalOcean é formada por verbos. O que estava em jogo não era apenas o substantivo “servidor”, mas a capacidade de agir sobre a infraestrutura. Um Droplet em execução pode seguir atendendo enquanto a criação do substituto falha. Um banco existente pode responder enquanto um novo cluster fica preso em “Creating”.

Essa diferença muda a leitura econômica. A perda pode não aparecer no primeiro minuto. Ela surge quando o tráfego cresce, quando um nó precisa ser trocado, quando uma implantação exige snapshot ou quando a equipe tenta recuperar um ambiente. A falta de elasticidade transforma folga em escassez conforme o tempo avança.

O comunicado não diz que todas as operações falharam para todos os clientes. Sem taxa por produto, não cabe chamar o episódio de apagão total. Também não cabe tratá-lo como simples inconveniente administrativo: para quem precisava da próxima ação, o plano de controle fazia parte do serviço principal.

O relógio da correção teve etapas bem separadas

O primeiro aviso, às 18h57min49s UTC, já citava novas contas, Droplets, Reserved IPs, snapshots e serviços baseados em Droplets. Às 19h38min23s, a investigação acrescentou GenAI, console e bancos que podiam permanecer no estado de criação.

Às 20h02min35s, 1h04min46s depois da abertura, a DigitalOcean afirmou que a causa raiz estava identificada. A causa não foi publicada. Às 22h02min55s, a equipe ainda implementava e distribuía a correção, com possibilidade de continuidade dos problemas.

Somente à 00h31min29s a empresa disse que os clientes já não deveriam encontrar os erros listados e iniciou o monitoramento. A resolução veio à 01h01min02s. Identificar, distribuir, observar e resolver são estados operacionais diferentes; o selo final verde não deve apagar as horas em que a recuperação ainda era parcial.

A simultaneidade sugere um gargalo, mas não revela qual

O histórico oficial de componentes marca Droplets Global, Kubernetes Global, Managed Databases Global e Reserved IP como degradados. As atualizações narrativas incluem ainda cadastro, backups, snapshots, autoscaling, GenAI e console. É razoável inferir que várias ofertas dependiam de alguma superfície comum de provisionamento ou controle.

Essa inferência precisa permanecer identificada como tal. A DigitalOcean não citou sistema de identidade, fila, banco interno, certificado, rede, região controladora ou mudança de software. Dizer qual deles falhou seria inventar exatamente a informação que o fornecedor omitiu.

A documentação ajuda apenas a entender o contexto. DOKS oferece plano de controle gerenciado e se integra a Droplets, volumes, API e ferramentas da plataforma. As APIs de Droplets tratam de criação, imagens, backups, snapshots e pools de autoscaling. As conexões de produto mostram a experiência compartilhada do cliente; não provam a arquitetura privada do incidente.

Preservar o limite da evidência melhora a resposta do cliente

As atualizações falam de criação, alocação, escalonamento, backup, snapshot, console e cluster novo. Não dizem que todos os Droplets em execução desligaram, que o tráfego estabelecido parou, que dados desapareceram ou que consultas em bancos existentes falharam de forma geral.

Isso não reduz a consequência das ações bloqueadas. Se o autoscaling não acrescenta uma instância, um serviço saudável pode saturar depois. Se o banco de recuperação não nasce, a restauração atrasa. Se o console some, uma equipe sem rota alternativa perde seu instrumento de diagnóstico.

Ao separar controle e plano de dados, o cliente sabe o que procurar. Em vez de presumir desastre universal ou ausência de impacto, ele identifica cada mudança solicitada no intervalo e confere seu estado final.

Backup também é uma operação que pode precisar de backup

Automated Backups e Snapshots ficaram no escopo durante todo o incidente. Eles funcionam como proteção, mas a ordem de criá-los depende do mesmo fornecedor que oferece o recurso primário.

A DigitalOcean não relatou perda ou corrupção de cópias existentes. Relatou possibilidade de falha nas operações. São perguntas diferentes: a solicitação foi recebida? O trabalho terminou? O artefato restaura corretamente? A página voltar ao normal depois da 01h01 não responde automaticamente ao que aconteceu com tarefas anteriores.

Não houve contagem de jobs falhos ou atrasados, nem explicação sobre reprocessamento. Antes de repetir uma ordem, o operador deve comparar logs da API, histórico de tarefas e inventário real. Uma segunda tentativa feita no escuro pode criar duplicidade ou esconder que a primeira foi concluída tarde.

A PME guarda capacidade como promessa, não como estoque

Grandes empresas conseguem manter recursos ociosos, automação própria, outro provedor e equipes de plantão. Pequenas organizações compram sob demanda. A reserva delas é a promessa de que o cloud criará um recurso quando solicitado.

Quando o provisionamento falha, a conta aparece em espera, tentativas e conferência manual. A falha do fornecedor pode ainda ampliar um incidente que começou no cliente: a aplicação apresenta um defeito e, na hora de substituí-la, a plataforma não cria a nova capacidade.

Não existem dados para estimar quantas PMEs foram afetadas ou o prejuízo agregado. A classificação “minor” é um rótulo do status da DigitalOcean, não um denominador público. A empresa também não informou créditos nem conclusão de SLA.

Resolver o serviço não fecha automaticamente as transações

No último aviso, a DigitalOcean confirmou resolução completa e orientou a abertura de chamado para quem ainda percebesse problemas. O ciclo de serviço terminou; o destino de cada ação enviada durante as seis horas continua sem demonstração pública.

Quantas solicitações falharam? Quantas ficaram pendentes? A plataforma repetiu algum trabalho? Houve recursos criados depois que o cliente já tinha tentado de novo? Sem essa reconciliação, o cliente precisa construir sua própria contabilidade.

Também faltam regiões específicas, taxas por operação e a causa. Um bom pós-incidente deveria separar causa técnica, raio de impacto, correção, tratamento de pendências e prevenção duradoura. É possível fazer isso sem divulgar detalhes sensíveis de segurança.

O inventário da janela é o ponto de partida

O intervalo auditável vai de 18h57min49s a 01h01min02s UTC. Cadastros, criações de Droplets, Reserved IPs, eventos de autoscaling, operações DOKS, backups, snapshots, acessos ao console e criação de bancos devem ser classificados como concluídos, falhos, cancelados ou incertos.

Da DigitalOcean, a próxima evidência relevante seria uma causa nomeada, regiões, denominadores, reconciliação e remediação permanente. Uma repetição com a mesma combinação de produtos fortaleceria a hipótese de dependência comum, mas este evento não prova vínculo causal com a falha de operações de escrita de 6 de agosto.

Elasticidade é frequentemente apresentada como capacidade infinita atrás de uma API. O incidente mostra uma condição anterior: a API e o sistema que autorizam a mudança também precisam permanecer disponíveis. Redundância no que está rodando resolve apenas metade do problema se a reposição passa por uma única porta.

Fontes