Postmortem – lentidão e indisponibilidade parcial no dia 17/02/2022

ÚLTIMA ATUALIZAÇÃO: 25 de Fevereiro de 2022. Infelizmente tivemos uma falha generalizada em nossos sistemas, causada por uma atualização do sistema.

Resumo do ocorrido

Devido à uma falha geral nas instâncias do banco de dados da Becon, em nossos servidores da Azure, tivemos uma lentidão e indisponibilidade no dia 17/02/2022, em todos os ambientes do WhatsApp da Becon. Essa falha geral foi causada por uma atualização de rotina referente à versão 1.16 do sistema, a qual trazia não apenas mudanças na interface da plataforma (e.g. menu Empresas, em configurações), mas também mudanças substanciais referentes à nova precificação do Facebook.

Abrimos um chamado contendo todos os logs para as partes envolvidas, e acionamos imediatamente nossa consultoria, especializada em servidores e erros do tipo.

Processo de Atualização

Todos os módulos desenvolvidos pela equipe da Becon (neste caso, a versão 1.16), ao serem finalizados, tornam-se um artefato, o qual passará por um processo de testes internos, o que chamamos de etapa 1. Após os testes desta etapa serem concluídos, o artegado é encaminho para os nossos ambientes de atendimento ao público (e.g. time de vendas e suporte), para mais uma bateria de testes, a qual durará cerca de 3 a 5 dias – esta é a etapa 2 – até que possa ser disponibilizada para nossos clientes no ambiente de produção.

Seguindo o modelo canary de disponibilização de artefatos, escolhemos clientes aleatórios para receber a nova versão, e os mesmos são monitorados por até 2 horas, o que chamamos de etapa 3. Finalmente, tudo correndo bem, disponibilizamos o artefato via kubernetes para todos os clientes – etapa 4.

 Empresas utilizam o modelo “Canary Deployments” para testar softwares em produção, direcionando um grupo de usuários para uma nova funcionalidade. Um deploy “canary” (que faz referência aos canários de mina, controles básicos de segurança dos mineradores) é um tipo de versão incremental, instalada em paralelo à versão de produção.

Atualização – Versão 1.16 do Sistema

Vale reforçar que o pacote 1.16.7 que estamos nos referindo ao longo deste documento, é o pacote que contém atualizações importantes ligadas a novos objetos que deverão ser salvos na nova versão do wacore do WhatsApp- versão 2.39.1, lançada junto da nova precificação. Ou seja, uma atualização mandatória.

Além de importantes correção de erros, essa nova versão também traz as necessárias APIs do vindouro painel da Becon (e.g. tempo real e financeiro), bem como o novo sistema de marca branca, para alteração de cores e imagens da plataforma.

Linha do tempo
(todos os eventos se referem ao dia 17/02/2022)

14:10 – Artefato entra na etapa 3

A etapa 3 do deploy de atualizações é a primeira etapa que envolve os clientes da Becon. Ela ocorre logo após as atualizações terem sido testadas em ambientes próprios para testes e ambientes internos (i.e. vendas e suporte). Nesta etapa 3 foram selecionados alguns clientes, entre eles os BMW-16 e BMW-17 (códigos internos dos clientes) para receber o artefato.

15:40 – Artefato aprovado para a etapa 4

Nossa equipe monitorou os clientes selecionados para a etapa 3 do processo, processo que durou cerca de uma hora e meia, os quais operaram na nova versão com sucesso. Com isto, o artefato foi aprovado para entrar na etapa 4, com a consequente aplicação gradativa para todos os demais clientes.

16:15 – Início de lentidão e indisponibilidade em alguns clientes

A estrutura de banco de dados, o qual é composto por 3 (três) instâncias master-slave, as quais, por sua vez, são gerenciadas por um operador, pelo haproxy e o percona. Contudo, essa estrutura apresentou falhas e, consequentemente, travou na aplicação da etapa 4 da atualização de rotina. Começa a lentidão e indisponibilidade do sistema. 

16:30 – Plano de contingência foi acionado

O módulo de Whatsapp atualmente processa entre 30 a 50 requisições por segundo. Com a falha no Percona, a queda do banco de dados seria iminente, podendo por sua vez gerar perda de dados. Neste sentido, a rotina de persistência de mensagens foi ativada e as aplicações removidas do ar garantindo que toda mensagem nova que chegasse para qualquer um dos clientes fosse salva no banco de dados, para serem importadas mediante a resolução do problema – garantindo que nenhuma mensagem/conteúdo crítico fosse perdido. Ato contínuo, um war room foi estabelecido.

16:35 – Início da resolução do problema

Foi estabelecida uma sala de guerra com engenheiros da Becon e um especialista de mercado em recuperação de desastres em banco de dados, garantindo integridade dos dados e resolução ágil da situação. Na sala de guerra foi executado na seguinte:

16:40 – Os operadores do mysql foram removidos devido a falta de resposta;

16:45 – Devido ao estado ‘travado’ dos operadores, haproxy e banco de dados, toda a infra-estrutura kubernetes foi reiniciada;

16:55 – A estrutura kubernetes foi reiniciada com sucesso;

17:10 – Foram levantados todos os commits de banco de dados pendentes em cada um dos cluster do banco de dados;

17:15 – O e-mail de indisponibilidade foi enviado para toda a base de clientes;

17:23 – Todos os dados das instâncias dos bancos de dados de dados foram sincronizados;

17:35 – Um backup com os dados sincronizados dos bancos de dados foi realizado;

17:55 – Todas as mensagens recebidas neste periodo foram sincronizadas aos devidos ambientes;

18:12 – Um novo backup com os dados sincronizados foi gerado e armazenado em outra instância de volume ;

18:20 – O primeiro servidor de aplicação subiu executando as rotinas necessárias para o pacote 1.16.7;

18:26 – Todas as rotinas foram executadas;

18:40 – Um novo backup foi gerado do banco de dados e armazenado em outra instância de volume;

18:55 – Todos os demais servidores de aplicação foram retornados e os dados indexados;

19:05 – Todos os servidores (aproximadamente 100) foram reiniciados com sucesso e as devidas conexões com o cluster de banco de dados estabelecida;

19:15 – O serviço de monitoramento foi estabelecido;

19:20 – Início da disponibilização dos domínios/url para todos os clientes.

19:30 – Disponibilização dos ambientes publicamente

Toda a infraestrutura estrutura foi recriada, e restabelecida, os testes necessários executados, garantindo que o sistema estivesse funcionando e disponível para os clientes da Becon.

20:10 – Finalização da sala de guerra

Com o retorno do uso dos sistemas, bem como a normalização das chamadas de API, a sala de guerra foi finalizada.

22:45 – Notificação aos clientes

Um e-mail foi enviado para a base de clientes informando sobre o ocorrido e o retorno do status Online do sistema.

Extras

  • Clientes que utilizam o módulo de proxy tiveram impacto reduzido devido ao uso reduzido de leitura/escrita de dados;

Próximos passos:

Ação 1 – Minimizar novos riscos

Nenhuma atualização de rotina será aprovada antes da análise e correção da causa raiz deste evento – tratado neste documento.

  • Estado: Aplicado
  • Data: 17/02/2022 – 20:30

Ação 2 – Consultoria especializada

Com o serviço já retomado, foi contratado um terceirizado especialista em desastres visando entender no detalhe o ocorrido, as falhas do percona/mysql/haproxy, e para analisar todos os logs, rotinas e execuções dos bancos de dados, para assim levantar todas as melhorias necessárias.

  • Estado: Planejado
  • Data de início: 18/02/2022.

Ação 3 – Revisão do Monitoramento

As receitas do terraform serão alteradas para que atualizações de rotina passem a ser  executadas de formas individuais, ou seja, finalizando uma atualização de artefato, somente quando estável por 10 minutos. Ato contínuo, será aplicado no próximo namespace, e em seguida em outro, até a conclusão de todos os clientes.

  • Estado: Planejado
  • Data: 21/02/2022

Atualização do Postmortem (24/02/2022)

Após uma série de testes e consultas, foi identificado que o ambiente do banco de dados teve sua indisponibilidade causada por uma instabilidade do Percona e o Ha-proxy, que por sua vez foi ocasionada pela lógica de criação de colunas em uma tabela do hibernate.

Em relação ao episódio do dia 17/02, um novo atributo no modelo entidade-relacionamento da tabela de mensagens e um novo índice, motivado pelos novos dados enviados pela nova precificação do Whatsapp, foram os gatilhos que ocasionaram a instabilidade do Percona e Ha-proxy, causando a indisponibilidade.

A Becon atualmente recebe cerca de 100 requisições por segundo de APIs, muitas das quais interagem com a tabela de mensagens. Quando os ambientes foram atualizados, existiam milhões de dados oriundos de mensagens que precisavam do novo atributo, referente à nova precificação, ocasionando a lentidão no banco. A lentidão se prolongando, o ha-proxy começou a apresentar acúmulo de mensagens represadas devido ao alto volume de requisições recebidas, ocasionando no seu estouro de memória devida a quantidade de mensagens na fila. 

Por fim, o operador, responsável por gerenciar os módulos dos Nós do mysql e dos operadores apresentou estouro de memória, causando a falha generalizada. Vale mencionar que, internamente, se o Whatsapp não recebe uma mensagem de retorno http 200 ou 201 ele retenta após algumas horas. Logo, nenhuma mensagem foi perdida porque o servidor retornou para todos os casos uma mensagem http 500.

O Hibernate também é responsável pela criação de índices no banco de dados, o que causa lentidão no banco de dados e que, por sua vez, gerou uma lentidão no dia 23/02/2022, sem causar indisponibilidade, porém um tempo de espera em algumas requisições de até 20 segundos.

Composição dos ambientes:

Atualmente, cada ambiente contém:

  • Banco de dados próprio;
  • Domínio com certificado SSL válido;
  • Servidor de aplicação, responsável por persistir os dados trafegados entre o Whatsapp (Tomcat);
  • Servidor de interface (Node);
  • Servidor de Whatsapp (WaCore e WaWeb), podendo ter mais de um servidor para ambientes de alta disponibilidade;
  • Proxy Istio;
  • Gerenciados por:
    • Kubernetes, responsável pelo gerenciamento de containers (gerenciamento de servidores)
    • Terraform, responsável por iniciar o cluster e a infra-estrutura
    • Helmfile, responsável pelos deploys (atualizações e versionamento)

Próximos passos (após atualização):

Com a causa raiz identificada, as seguintes ações estão sendo executadas:

Ação 4 – Separação do módulo de entidade-relacionamento do processo do git

Toda nova alteração envolvendo criação de entidades, criação de índices, criação de atributos, mudança de tamanho de atributos, e etc. estará isolada em um projeto novo do maven, no qual antes de qualquer atualização do ambiente os bancos de dados devem ser atualizados com suas devidas rotinas um a um.

  • Estado: Em andamento
  • Entrega prevista: 28/02/2022

Ação 5 – Melhorias no processo de recuperação de desastres e mais redundâncias no backup

Atualmente, diariamente é gerado um backup completo do banco de dados, e também de hora em hora é gerado um backup incremental do mesmo. Os artefatos gerados são salvos no blob storage da azure

O processo novo irá incluir um banco de dados novo, no qual o arquivo de backup, último gerado, esteja já disponível na instância, garantindo que seja possível subir uma nova infra de banco de dados em instantes caso seja necessário recuperar algo em instantes. Os dados do último backup e novos dados gerados irão passar por uma lógica de sincronização quando o banco de dados com problema retornar garantindo redução de indisponibilidade.

  • Estado: Em andamento
  • Entrega prevista: 03/03/2022

Ação 6 – Melhorias no processo de atualização

Foi definido que se um artefato de servidor de aplicação ou servidor de Whatsapp for necessário para atualização, serão atualizados em lotes parciais de cinco em cinco no qual um novo lote inicia após, e apenas após, o último lote esteja devidamente atualizado e o monitoramento acuse disponibilidade.

  • Estado: Concluído
  • Data: 23/02/2022

Caso o seu sistema ainda esteja offline, esteja com algum problema outro, ou só tenha dúvidas em relação ao processo, por favor, não hesite em nos procurar. Basta clicar aqui e acionar o nosso suporte.


Autor: Lucas Schiochet

Responsável técnico: Evaldo Neto

DPO: Philippe Silveira

Impacto: Alto – Acima de 30% da base de cliente.

Escrito por:

Philippe Silveira

Philippe Silveira

Auto-proclamado desenhista, escritor, contador de histórias, sonhador, e nascido brasileiro, hoje também é responsável por Sucesso do Cliente na Becon,

últimos posts

A Becon quer ajudar você a conseguir Leads qualificados, de forma orgânica, prontos para mexerem o ponteiro das suas estratégias de marketing online e offline. A Becon é sua parceira para tudo isso – e de acordo com a LGPD e o Marco Civil da Internet.