Resumo
Em 19 de janeiro de 2026, entre 14:02 e 14:28 UTC, cerca de dois terços de todas as tentativas de login no painel ou de autenticação na API falharam. Sessões existentes também foram invalidadas aleatoriamente. Instâncias em execução, suas redes e seus tráfegos não foram afetados em nenhum momento. O provisionamento foi pausado por vinte e seis minutos e depois foi drenado; nenhum pedido foi perdido.
Linha do tempo
Todos os horários em UTC, 19 de janeiro de 2026.
| Hora | Evento |
|---|---|
| 14:02 | Alteração no esquema do token de sessão aplicada ao plano de controle. A implantação foi marcada como configuração, então foi para todos os seis nós do painel de uma vez. |
| 14:03 | A taxa de erro de login sobe de quase zero para sessenta e um por cento. O alerta automatizado tem uma janela de dois minutos e ainda não dispara. |
| 14:06 | O alerta dispara. O engenheiro de plantão é acionado. |
| 14:08 | O primeiro respondente online. Vê uma taxa de erro, nenhum deploy no log de mudanças de código, e começa a investigar o banco de dados. |
| 14:14 | Um segundo engenheiro entra, verifica o log de mudanças de configuração em vez do log de código, e encontra a entrada das 14:02. |
| 14:16 | Causa entendida: dois nós estão validando tokens com o leitor anterior. |
| 14:19 | O rollback começa. |
| 14:24 | Os tokens são emitidos e validados corretamente em todos os seis nós. A taxa de erro cai para zero. |
| 14:28 | Os jobs de provisionamento na fila são drenados. Recuperação concluída. |
| 15:10 | Página de status atualizada. Quarenta e dois minutos atrasada, o que é uma falha em si e é abordado abaixo. |
Causa raiz
O token de sessão ganhou um campo. Os escritores emitiram o novo formato imediatamente; o leitor em dois dos seis nós do painel não havia sido reiniciado e rejeitava qualquer coisa que carregasse o novo campo. As requisições são distribuídas entre todos os seis nós, então uma sessão criada em um nó novo tinha aproximadamente uma chance em três de ser validada por um nó antigo em qualquer requisição. O resultado parecia intermitente, e é por isso que os primeiros seis minutos de diagnóstico foram para o banco de dados em vez do log de deploy.
A causa mais profunda é uma regra que escrevemos em 2023. Mudanças que tocam um arquivo de esquema em vez de código de aplicação eram classificadas como configuração, e a configuração pulava a fase canário com a justificativa de que era, entre aspas, apenas valores. Essa regra era razoável quando os únicos arquivos de esquema eram feature flags. Ninguém a revisitou à medida que a definição de arquivo de esquema se expandiu, e esta mudança foi corretamente classificada sob uma regra que silenciosamente se tornou errada.
Não foi um erro do engenheiro que a aplicou. A classificação foi seguida exatamente como escrita.
Raio de impacto
- Logins no painel: taxa de falha de sessenta e um por cento por vinte e seis minutos.
- Tokens de API: mesma taxa de falha, mesma janela. Chaves de idempotência garantiram que creates repetidos não duplicassem.
- Instâncias em execução: não afetadas. Sem perda de pacotes, sem reboots, sem impacto no armazenamento.
- Provisionamento: pausado, não falhou. Quatro ordens foram liquidadas durante a janela e todas as quatro foram concluídas até as 14:28.
O que mudamos
- A fase canário agora é incondicional. Qualquer coisa que seja implantada, de qualquer classificação, vai para um nó por cinco minutos com tráfego sintético antes de ir para qualquer outro lugar. Concluído em 21 de janeiro.
- Os leitores aceitam o formato anterior por trinta dias. A validação de tokens agora é explicitamente versionada com uma janela de sobreposição, então uma mudança parcialmente implantada degrada para nada. Concluído em 23 de janeiro.
- Um login sintético roda a cada quinze segundos de fora da nossa rede, em três regiões, e pagina na segunda falha consecutiva em vez de após uma janela de média de dois minutos. Concluído em 22 de janeiro.
- A página de status publica automaticamente quando o login sintético falha duas vezes, sem esperar que um humano escreva uma frase. Uma frase humana a segue. Concluído em 26 de janeiro.
O que não mudamos, e por quê
Ainda não registramos IPs de clientes ou corpos de requisições para o tráfego do painel. Tê-los teria mostrado a distribuição de um em três entre nós imediatamente e provavelmente teria economizado nove minutos. Nove minutos não valem um registro permanente de onde cada cliente faz login. A tabela de retenção na página de logging permanece inalterada.
Não movemos sessões para um armazenamento compartilhado entre sites. Um armazenamento de sessão único abrangendo todos os sites teria evitado o problema do leitor misto por ter um único leitor. Isso também criaria exatamente o registro centralizado e sempre quente de quem está conectado ao que passamos seis anos não construindo.
Não adicionamos um canal de anúncio de indisponibilidade fora da página de status. Várias pessoas sugeriram mídias sociais. A página de status é a única coisa que operamos na qual podemos nos comprometer a manter precisa, e adicionar uma segunda superfície significa uma segunda superfície que fica desatualizada.
O crédito
O SLA cobre a disponibilidade das instâncias. As instâncias estiveram disponíveis durante todos os vinte e seis minutos, então sob o contrato ninguém tinha direito a nada. Aplicamos um crédito de um dia a todas as contas que tiveram uma autenticação falha na janela, o que totalizou cerca de três mil e cem euros, porque discutir a distinção com pessoas que não conseguiam acessar seus servidores é um uso pior da tarde de todos.