Quando uma Dependência Entra em Colapso: A Nossa Análise Pós-Incidente de 22 e 23 de Junho

Hora (UTC)

O Que Aconteceu a Montante (Relatório Completo)

O Que Aconteceu Internamente / A Nossa Experiência

22 de Junho, 19:00

O Gatilho: A escassez de capacidade da AWS em us-east-1 força a acumulação de cerca de 10 000 execuções nas filas a montante.

As nossas tarefas em segundo plano começam a abrandar silenciosamente. As filas começam a crescer nos bastidores.

22 de Junho, 20:09

O Colapso: O plano de controlo de Kubernetes a montante atinge os 100% de CPU, perde o quórum da base de dados e a região us-east-1 desliga-se completamente.

O nosso ambiente de produção deixa de processar execuções. Milhares de tarefas em toda a plataforma ficam bloqueadas no fluxo de trabalho pendente.

22 de Junho, 21:58

A engenharia do fornecedor a montante está a combater ativamente um ciclo de "tempestade de reconexão".

Incidente Reportado: São registadas taxas de falha elevadas e é iniciada uma sala de incidentes interna.

23 de Junho, 00:59

O fornecedor a montante recomenda que os utilizadores mudem manualmente as cargas de trabalho para a sua região eu-central-1.

Líder de Incidente Atribuído: A sala de resposta a incidentes é totalmente ativada com um líder atribuído para gerir a avaliação entre regiões.

23 de Junho, 01:01 - 02:10

O fornecedor a montante implementa uma atualização de emergência no painel de controlo para permitir a migração em massa de execuções entre regiões.

Mitigação Ativa: Às 01:10, a equipa cancela manualmente as nossas execuções em fila nos EUA para libertar a capacidade de execução bloqueada da nossa conta e direciona todo o novo tráfego para a região europeia. Às 02:10, as mensagens voltam a ser processadas.

23 de Junho, 02:02 - 02:33

O fornecedor a montante está a dimensionar manualmente o cluster de armazenamento de suporte da base de dados.

Gravidade Atualizada para Crítica: Mais de 30 000 das nossas próprias tarefas estão agora em fila e em espera. A equipa publica uma atualização de estado crítica na nossa página de estado pública.

23 de Junho, 04:35 - 05:05

As atualizações de infraestrutura a montante reduzem drasticamente as velocidades de execução.

O Gargalo de Webhooks: As taxas de processamento caem. Às 05:05, identificamos que a nossa fila de envio de webhooks é o principal gargalo que não se consegue escoar.

23 de Junho, 08:38

A Segunda Cascata: O tráfego global redirecionado sobrecarrega la região europeia do fornecedor, colocando-a completamente offline.

Paralisação Total: Ambas as regiões a montante estão agora efetivamente inativas. Temos mais de 13 000 tarefas congeladas a meio do processo, dependendo inteiramente da recuperação a montante.

23 de Junho, 10:34

A engenharia do fornecedor a montante está a ter dificuldades em restabelecer a sua região europeia.

Implementação do Disjuntor (Circuit Breaker): Percebendo que a camada primária de processamento em segundo plano está totalmente paralisada, a nossa equipa muda a abordagem de mitigação de infraestrutura para um desvio arquitetónico. Implementamos uma correção rápida de emergência em todos os ambientes principais de aplicação e API para desativar temporariamente a gestão de tarefas assíncronas.

23 de Junho, 10:41

O fornecedor a montante continua a trabalhar no redimensionamento dos nós do plano de controlo.

Alívio Imediato: O desvio arquitetónico funciona perfeitamente. Ao contornar as filas em segundo plano congeladas, os processos críticos da aplicação recorrem a caminhos de execução direta. A engenharia confirma: "Os emails voltaram a fluir."

23 de Junho, 17:06

O fornecedor a montante estabiliza finalmente ambas as regiões e restaura as velocidades de processamento.

Fila de Espera Limpa: A engenharia confirma que as nossas filas em ambas as regiões estão completamente vazias. O desempenho do sistema regressa ao normal.

23 de Junho, 19:31

A estabilidade pós-recuperação mantém-se.

Incidente Resolvido: Os sistemas estão totalmente operacionais; a equipa entra no fluxo de revisão pós-incidente.