Erros na API de Pedidos
Incident Report for Konduto
Postmortem

Introdução

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.

Resumo do incidente

  • Às 13h06 nosso monitoramento identificou problemas na API, causando erros para os clientes
  • As causas mais comuns foram rapidamente descartadas
  • A reversão de um código recente e o aumento da capacidade dos servidores também não surtiram efeito, direcionando o time para uma investigação mais detalhada
  • O problema foi identificado: um gargalo do sistema operacional (SO) ligado a quantidade de arquivos (modelos de risco) que estavam sendo sincronizados no sistema
  • Nossa equipe passou a remover arquivos (modelos) antigos, permitindo que o SO voltasse a operar normalmente às 15h39

Detalhamento e causa raíz

À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.

Plano de ação

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.

Conclusão

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.

Posted Feb 01, 2021 - 13:51 GMT-03:00

Resolved
A aplicação está respondendo bem e estamos há bastante tempo sem erros. Vamos continuar monitorando a API, mas encerraremos este incidente.

Novamente, pedimos desculpas por esta instabilidade de aproximadamente 2h30. Nos orgulhamos de prover um serviço com excelente uptime, mas hoje falhamos nesta missão.

Nos próximos dias publicaremos um relatório de incidente após uma investigação mais profunda.
Posted Jan 28, 2021 - 18:21 GMT-03:00
Update
Continuamos a monitorar o desempenho da API após as correções. Vamos mantendo-os atualizados.
Posted Jan 28, 2021 - 17:15 GMT-03:00
Update
Ainda estamos vendo alguma instabilidade na API. Estamos trabalhando para resolvê-la.
Posted Jan 28, 2021 - 16:57 GMT-03:00
Monitoring
Uma correção foi ao ar agora há pouco que parece ter resolvido o problema. Vamos monitorar a performance do sistema para garantir a integridade. Agradecemos a paciência e pedimos desculpas pelo downtime. Iremos submeter um registro de incidente após uma investigação mais profunda.
Posted Jan 28, 2021 - 15:40 GMT-03:00
Update
Identificamos o problema causando downtime na API. Estamos trabalhando para uma correção assim que possível.
Posted Jan 28, 2021 - 14:50 GMT-03:00
Update
Continuamos trabalhando para recuperar a API de Pedidos.
Posted Jan 28, 2021 - 14:21 GMT-03:00
Update
Nossa primeira tentativa de correção não deu frutos. Estamos tentando um rollback para recuperar a API.
Posted Jan 28, 2021 - 14:04 GMT-03:00
Identified
Estamos trabalhando para recuperar a API de Pedidos. Em breve postaremos atualizações.
Posted Jan 28, 2021 - 13:53 GMT-03:00
Investigating
Estamos investigando erros de HTTP 500 e timeouts na API de Pedidos.
Posted Jan 28, 2021 - 13:44 GMT-03:00
This incident affected: API.