Postmortem: erro 500 inesperado ocorreu durante o login do usuário

Resumo#

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

• Usuários afetados: Todos os usuários do Cloud tentando autenticar
• Regiões afetadas: Europa e EUA
• Gravidade: Crítica, interrompendo a experiência de login do usuário

Causa raiz#

Durante uma implantação recente do Cloud, uma mudança impactante no esquema do banco de dados fez com que a API de experiência de login falhasse durante a transição entre os ambientes de staging e produção.

Cronologia#

• 2024-07-18 08:57 (UTC): Atualizações implantadas no Logto Cloud
• 2024-07-18 09:28 (UTC): Primeiro usuário relatou um erro 500
• 2024-07-18 09:31 (UTC): Equipe 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#

Qual é a mudança impactante no banco de dados e por quê?#

Atualmente, estamos desenvolvendo um novo recurso chamado "Traga sua UI", que permite que os usuários personalizem a experiência de login do Logto com suas próprias páginas web. Esse recurso requer uma nova coluna na tabela sign-in-exp para armazenar a configuração da UI personalizada.

Devido a algumas mudanças de requisitos durante o desenvolvimento, o lançamento do recurso foi atrasado, mas a primeira parte da mudança no esquema já havia sido implantada na produção há várias semanas, apesar de ainda não estar em uso. Uma atualização da coluna do banco de dados foi introduzida neste PR.

Infelizmente, essa mudança não era retrocompatível, fazendo com que as requisições de API do código antigo falhassem ao se comunicar com o novo banco de dados.

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

Ao implantar uma nova versão do Logto Cloud, primeiro a implantamos no ambiente de staging e, em seguida, trocamos os ambientes de staging e produção. O processo é o seguinte:

1. Executar o script de alteração do banco de dados e atualizar o banco de dados.
2. Implantar 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 usuários acessem a nova versão sem tempo de inatividade.

No entanto, ambos os ambientes compartilham o mesmo banco de dados, e todo o processo leva tempo. Então, no intervalo de tempo entre a atualização do banco de dados e a troca de ambiente, os usuários online permanecem no ambiente de produção com o código antigo, mas tentam se comunicar com o novo banco de dados.

Essa foi a causa raiz do incidente e a razão pela qual ele foi resolvido automaticamente em 35 minutos.

Por que isso não foi abordado no processo de revisão de código?#

Nós TEMOS uma tarefa de CI para verificar a retrocompatibilidade das mudanças no banco de dados. No entanto, anteriormente não era obrigatório passar na verificação de CI antes de mesclar o PR. Isso ocorre porque, na maioria das vezes, a fase de desenvolvimento normalmente é curta dentro de alguns sprints, e a primeira e a segunda parte das mudanças no esquema geralmente são incluídas na mesma fase de lançamento.

Desta vez, o lançamento do recurso foi atrasado, espalhando as mudanças no esquema por dois lançamentos. O desenvolvedor assumiu que a falha no CI era esperada e informou os revisores que isso não deveria impedir a mesclagem do PR.

Houve definitivamente uma lacuna de comunicação também, e finalmente o PR foi mesclado sem fornecer qualquer suporte necessário à retrocompatibilidade.

Lições aprendidas#

• Ao fazer uma alteração impactante no esquema do banco de dados, devemos sempre considerar a retrocompatibilidade com a versão antiga do código-fonte.
• Ao alterar uma coluna do banco de dados, devemos evitar alterá-la diretamente no esquema, mas sim usar a abordagem de depreciação e migração.
• O desenvolvedor deve estar mais ciente do processo de lançamento e do cronograma.

Medidas corretivas e preventivas#

• ✅ Agora é obrigatório passar na verificação de retrocompatibilidade do banco de dados antes de mesclar um PR que contenha alteração de esquema.
• ✅ Enfatizar a importância da retrocompatibilidade dentro da equipe.