Na quinta-feira, 28/01, a Konduto teve um incidente de tecnologia que deixou o nosso sistema fora do ar por aproximadamente 2h30, entre 13h06 e 15h39 BRT. Este foi o downtime mais longo dos nossos quase 7 anos de história. Nos orgulhamos em entregar os nossos clientes uma disponibilidade excepcional, mas neste incidente nós falhamos neste quesito.
Este relatório traz os detalhes do incidente de 28/01, detalhando a causa raíz e o plano de ação para que um novo episódio similar não aconteça novamente.
Às 13h06 nosso monitoramento indicou problemas na API principal, gerando timeouts e erros HTTP 500 para nossos clientes. A primeira sondagem dos lugares mais comuns não indicavam problemas - banco de dados, conexão de rede e carga nos servidores estavam dentro do normal.
Os logs indicavam um problema para ler/escrever em disco. Dois dias antes nós havíamos feito mudanças no código que envolviam disco, e pensamos que poderia ser algum bug latente, apesar do código já estar no ar há dois dias e ter sido amplamente testado. Voltamos a uma versão anterior do código, mas isto não surtiu efeito.
O disco dos servidores estava cheio (92%), mas não o suficiente para causar problemas. De qualquer modo, triplicamos a capacidade de disco para garantir que isto não era a causa. Mesmo assim o erro continuava, e os logs apontavam para problemas em ler arquivos em disco, especificamente no diretório de modelos de fraude.
Cada cliente dentro da Konduto tem um modelo de fraude dedicado, e alguns possuem mais de um modelo rodando em paralelo. Por questões de desempenho, estes modelos são baixados de um repositório central e ficam em um diretório dentro de cada servidor. Quando chega uma transação de um determinado cliente, o sistema vai no diretório local, lê o arquivo, carrega o modelo na memória e faz a escoragem do pedido.
Nós não temos a prática de apagar modelos antigos, de clientes que ganharam uma versão nova ou que deixaram de transacionar. O repositório central, então, contém modelos ativos e também o histórico.
Neste dia o diretório continha aproximadamente 33 mil arquivos de modelos, e o que estávamos enfrentando era um gargalo do sistema operacional (SO) em ler e buscar os modelos dentro deste diretório. Eram arquivos demais para o SO conseguir achar e ler em milissegundos.
Para testar esta hipótese nós apagamos, em um dos servidores, todos os arquivos de modelo, exceto por 1. Com isto o sistema voltou a funcionar e confirmamos a causa do problema. Porém, é claro que não poderíamos deixar apenas 1 modelo no ar.
Nosso time então foi ao repositório central e apagou todos os modelos antigos, reduzindo consideravelmente a quantidade de arquivos que eram sincronizados e armazenados nos servidores. Esta tarefa levou quase 1 hora. Quando foi terminada nos re-sincronizamos os servidores com o repositório central, e o sistema voltou a operar normalmente.
Para evitar que este problema aconteça planejamos duas ações de curto prazo: monitoramento e reformulação da sincronização de modelos.
Embora monitoremos o desempenho dos servidores (memória, CPU, disco, rede, etc), o problema foi causado pela concentração de muitos arquivos em um único diretório só, causando perda de eficiência na busca de arquivos. Os servidores em si estavam bons, e o monitoramento de desempenho sozinho não identificaria um novo problema.
A primeira ação, que já está no ar, foi criar um monitoramento especial para o diretório que armazena os modelos. Periodicamente veremos quantos arquivos de modelos há no diretório e gerar um alerta caso ultrapasse um número razoável.
A segunda ação é reformular a forma como sincronizamos e apagamos arquivos de modelos. Não há um motivo técnico para termos modelos antigos nos servidores, então vamos mudar o sistema para sincronizar apenas os modelos novos, ativos e em uso pelos nossos clientes.
Uma vez concluídas estas ações, tiramos do futuro próximo a possibilidade de um problema similar. Vamos, então, estudar alternativas permanentes de gestão destes arquivos de modelos, para evitar problemas quando tivermos de fato ~33 mil modelos ativos.
Sabemos que o nosso serviço é essencial para a operação dos nossos clientes. Nos preocupamos muito com a disponibilidade da ferramenta e nos orgulhamos de ter trazido aos nossos clientes em 2020 um uptime de 99.99%. Porém, neste caso, desapontamos os nossos clientes e pedimos desculpas pelo incidente.
Identificamos a causa do problema, criamos monitoramentos adicionais e estamos alternando a forma de sincronização dos modelos para evitar casos similares no futuro.