Postmortem: ocorreu um erro 500 inesperado durante o login de utilizador

Resumo#

Em 18 de julho de 2024, o Logto Cloud sofreu uma interrupção de serviço com erro interno do servidor 500 proveniente dos serviços de autenticação.

• Utilizadores afetados: Todos os utilizadores do Cloud que tentaram autenticar-se
• Regiões afetadas: Europa e EUA
• Severidade: Crítica, perturbando a experiência de login dos utilizadores

Causa raiz#

Durante uma recente implementação no Cloud, uma alteração na estrutura da base de dados causou a falha da API de experiência de login durante a transição entre os ambientes de staging e produção.

Linha do tempo#

• 2024-07-18 08:57 (UTC): Atualizações implementadas no Logto Cloud
• 2024-07-18 09:28 (UTC): Primeiro utilizador relatou um erro 500
• 2024-07-18 09:31 (UTC): A equipa de desenvolvimento reconheceu o problema e começou a investigar
• 2024-07-18 09:32 (UTC): O problema foi resolvido automaticamente
• 2024-07-18 09:40 (UTC): Causa raiz identificada

Análise do incidente#

O que foi a alteração na estrutura da base de dados, e porquê?#

Estamos atualmente a desenvolver uma nova funcionalidade chamada "Traga a sua IU", que permite aos utilizadores personalizar a experiência de login do Logto com as suas próprias páginas web. Esta funcionalidade requer uma nova coluna na tabela sign-in-exp para armazenar a configuração personalizada da IU.

Devido a algumas alterações de requisitos durante o desenvolvimento, o lançamento da funcionalidade foi adiado, mas a primeira parte da alteração da estrutura já tinha sido implementada na produção há várias semanas, apesar de ainda não estar em uso. Uma atualização da coluna da base de dados foi introduzida neste PR.

Infelizmente, esta alteração não foi compatível com versões anteriores, causando falhas nas solicitações API do código antigo ao comunicar com a nova base de dados.

Como implementamos uma nova versão do Logto Cloud?#

Ao implementar uma nova versão do Logto Cloud, primeiro implementamos no ambiente de staging e depois trocamos os ambientes de staging e produção. O processo é o seguinte:

1. Executar o script de alteração da base de dados e atualizar a base de dados.
2. Implementar o novo código-fonte no servidor de staging.
3. Executar o servidor de staging e realizar testes.
4. Trocar os servidores de staging e produção, para que o "staging" se torne "produção", permitindo que os utilizadores acedam à nova versão sem tempo de inatividade.

No entanto, ambos os ambientes partilham a mesma base de dados, e todo o processo leva tempo. Por isso, na janela de tempo entre a atualização da base de dados e a troca dos ambientes, os utilizadores que estavam online permaneceram no ambiente de produção com o código antigo mas tentavam comunicar-se com a nova base de dados.

Esta foi a causa raiz do incidente e o motivo pelo qual foi resolvido automaticamente em 35 minutos.

Porque é que isto não foi abordado no processo de revisão de código?#

TEMOS uma tarefa de CI para verificar a compatibilidade com versões anteriores das alterações na base de dados. No entanto, anteriormente não era obrigatório passar na verificação de CI antes de fazer o merge do PR. Isto porque, na maioria das vezes, a fase de desenvolvimento é geralmente curta, dentro de poucas sprints, e a primeira e a segunda parte das alterações na estrutura geralmente estão incluídas na mesma fase de lançamento.

Desta vez, o lançamento da funcionalidade foi adiado, espalhando as alterações na estrutura em duas versões. O desenvolvedor presumiu que a falha de CI era esperada e informou os revisores que isso não deveria impedir o merge do PR.

Houve definitivamente uma falha de comunicação, e, finalmente, o PR foi feito merge sem fornecer qualquer suporte necessário de compatibilidade com versões anteriores.

Lições aprendidas#

• Ao fazer uma alteração na estrutura da base de dados que quebra a compatibilidade, devemos sempre considerar a compatibilidade com versões anteriores com o código-fonte antigo.
• Ao alterar uma coluna na base de dados, devemos evitar alterá-la diretamente na estrutura, mas sim usar a abordagem de descontinuação e migração.
• O desenvolvedor deve ter maior consciência do processo de lançamento e cronograma.

Medidas corretivas e preventivas#

• ✅ A verificação de compatibilidade com versões anteriores da base de dados no CI agora é obrigatória para passarem antes da realização do merge de um PR que contém alterações na estrutura.
• ✅ Enfatizar a importância da compatibilidade com versões anteriores dentro da equipa.