# Report interno sobre os incidentes de Payments - 01/02/23 a 08/02/23 ## Volume de tickets no período - Total de 32 tickets: -> 21 tickets de reclamação -> 11 tickets de solicitação - Times responsáveis: -> 26 tickets fiat -> 4 tickets crypto (entrada e saída) -> 1 ticket backoffice -> 1 ticket quote & trade - Parceiros: -> 8 tickets Antler -> 5 tickets 4Bill -> 5 tickets Bitolo -> 4 tickets Bybit -> 3 tickets Jindou -> 2 tickets Liteforex -> 2 tickets IBLFX -> 1 ticket Binomo -> 1 ticket Dafabet -> 1 ticket Roboforex ## *1. Problema no cosmos* ### Um pouco de contexto Uma partição do cosmos (partitionKey) é um campo que o nosso banco de dados usa para facilitar a buscar de informações. Quando uma query (uma busca) é feita no banco, essa partição funciona como uma espécie de "índice", direcionando corretamente aquela busca. É muito importante que toda query feita no banco tenha uma partitionKey vinculada para não estourarmos os RUs (request units), os recursos gastos na Azure ($$$). Hoje, nós temos uma partitionKey para cada tipo de documento, por parceiro. Exemplo: existe uma partição de transações da Antler, uma de notificações da Antler, uma de payments, e assim por diante, para cada parceiro. Cada partitionKey só pode ter até 20GB, uma limitação da Azure. ### O que aconteceu Na quarta-feira, dia 01/02, devido ao volume da Antler, a sua partição de notificações estourou, ultrapassando o limite de 20GB. Antler começou a parar de receber callbacks. Isso desencadeou uma "bola de neve", porque o nosso sistema de notificações envia os callbacks para uma fila. Devido ao erro de partição, cada vez que o registro falhava, o envio para a fila era retentado, e o número de re-tentativas de envio na fila aumentou exponencialmente. A fila é única para todos os parceiros, então todos os parceiros pararam de receber notificação. Além disso, com o excesso de requisições do sistema de notificações, o Cosmos começou a retornar erro 429 (too many requests) para todos os sistemas, e todos os parceiros começaram a ter problema para operar. ### O que foi feito para resolver (e como isso desencadeou novos problemas) O time parou o sistema de notificações, e rodou um script para deletar os documentos antigos da partição de notificações da Antler. O problema é que, quando começaram a rodar o script, por algum motivo que ainda não foi identificado, vários registros de transações antigas foram instantaneamente apagadas do cosmos (isso aconteceu por volta de 01h da manhã de quinta-feira, dia 02/02). Os saldos que exibimos aos parceiros nada mais é do que um cálculo de todas as transações anteriores. Como transações antigas haviam sido apagadas, os saldos começaram a ser exibidos erroneamente. O time, na quinta-feira: - usou o último backup do banco de dados e reinseriu todas as transações faltantes; - apagou todo o histórico de callbacks da Antler e de quotes da IBLFX para evitar uma nova "explosão" de partições ### Como evitar que aconteça novamente A próxima partição que está quase explodindo é a de transações da Antler, que está com 18GB. Essa não podemos deletar, porque não podemos apagar transações. Para resolver definitivamente o problema, o time vai criar 1 partitionKey nova para a Antler e estabelecer partições novas por mês para cada parceiro. ## *2. Problemas nas credenciais de parceiros* ### O que aconteceu Cada parceiro, para se conectar com os nossos sistemas, possui algumas credenciais conosco. Entre os dias 1º e 8 de fevereiro, dois parceiros tiveram uma de suas credenciais (SecretKey) expiradas, e pararam de conseguir operar. ### O que foi feito para resolver Foram geradas novas credenciais aos parceiros, que voltaram a operar. ### Como evitar que aconteça novamente As novas credenciais estão sendo geradas com 2 anos de expiração. Além disso, o time levantou possíveis parceiros em situação de expiração, e foram implementados alertas para nos avisar sobre a xpiração com 1 mês de antecedência. ## *3. Problema no Banco Central* ### O que aconteceu O Banco Central apresentou diversas instabilidades nos sistemas de Pix, entre sexta-feira 03/02 e domingo 05/02, afetando todas as instituições e o Brasil inteiro. ### O que foi feito para resolver Não há o que fazer aqui, tivemos apenas que aguardar a solução do lado do BACEN e avisar parceiros. ### Como evitar que aconteça novamente Não há o que fazer. ## *4. Problemas de payouts não aprovados automaticamente* ### O que aconteceu Hoje 90% do fluxo das nossas APIs está no AKS (azure kubernetes service) e não no app services. O time de infratech achou que nenhum sistema estava no app service e parou o serviço, mas o Payment Processor estava lá. Como esse é o sistema responsável por processar payouts, todos os pagamentos ficaram como pending, sem aprovação automática. ### O que foi feito para resolver O time passou o sistema do Payment Processor para o AKS. ### Como evitar que aconteça novamente O problema já foi resolvido de forma definitiva. ## *5. Erro 400 no Genial* ### O que aconteceu O Genial reclamou de estarmos usando muito o endpoint de consulta de saldo, e nos pediram para não consultarmos tanto, e passarmos a tratar o erro de falta de saldo, quando esse for o caso. O problema é que o erro de falta de saldo lá é muito genérico, e começamos a receber esse erro por vários motivos. Os payouts de parceiros ficaram presos em "processing". ### O que foi feito para resolver Foi cobrada uma posição do Genial, além de termos passado os parceiros para o BS2. ### Como evitar que aconteça novamente Está fora do nosso controle, podemos passar para outra instituição apenas. ## *6. Erro 204 no Genial* ### O que aconteceu Alguns pagamentos são iniciados, mas nós recebemos callback, e, quando tentamos consultar via polling, recebemos erro 204 (não encontrado). ### O que foi feito para resolver Enviamos o problema para o Genial, eles resolveram para os casos pendentes e não deram explicações. ### Como evitar que aconteça novamente Está fora do nosso controle, podemos passar para outra instituição apenas. ## *7. Problemas de instabilidade no BS2* ### O que aconteceu O BS2 tem sofrido ultimamente alguns problemas de instabilidade internos. ### O que foi feito para resolver Normalmente passamos os parceiros para o Genial, quando isso ocorre. ### Como evitar que aconteça novamente Nosso load balance tem ajudado bastante. No dia 08/02 o BS2 apresentou uma nova instabilidade e ele virou automaticamente para o Genial. ## *8. Problemas de autenticação no BS2* ### O que aconteceu Para o fluxo de TED, o token de autenticação no BS2 está expirando sem qualquer explicação, retornando erro ao parceiro. ### O que foi feito para resolver Pedimos ao parceiro para operar preferencialmente com Pix. O erro impactou pouquíssimas transações, por não ser a principal operação do parceiro. ### Como evitar que aconteça novamente Vamos passar a tratar o pedido de TED como Pix. Estamos cobrando retorno do BS2 sobre os erros. ## *9. Problemas com a Binance* ### O que aconteceu Nossas credenciais na Binance expiraram. Eles chegaram a enviar uma comunicação por e-mail ao nosso time responsável, mas o e-mail caiu no spam e não vimos. O quote e trade parou de funcionar. ### O que foi feito para resolver Foi gerada uma nova credencial. ### Como evitar que aconteça novamente Precisamos ter um controle interno de expiração de credenciais nossas com fornecedores. ## *10. Problemas no backoffice* ### Problemas - Falhas no quote e trade -> problema 9. Binance - Falhas de saldo -> problema 1. Cosmos - Lentidão das telas -> falha no carregamento das telas e na busca de payments antigos ### O que foi feito para resolver A lentidão ainda não foi resolvida. O que está sendo feito é todo o projeto de uma nova API do backoffice, para mitigar todos os problemas de lentidão e paginação. ## Impacto transacional dos incidentes Comparando a primeira semana de fevereiro com a primeira semana de janeiro de 2023, podemos perceber a diferença no coportamento transacional dos parceiros, causa, principalmente, pelo erro *1. Cosmos* (01/02 - 03/02) e pelo erro *3. Banco Central* (03/02 - 06/02). Obs.: o dia 08/02 está com o volume incompleto, porque o gráfico foi gerado no meio do dia. Janeiro 2023 ![](https://i.imgur.com/vr6tD67.png) Fevereiro 2023 ![](https://i.imgur.com/axjojJC.png) ## Impacto financeiro dos incidentes Comparando a primeira semana de fevereiro com a primeira semana de janeiro de 2023, podemos perceber que houve uma receita total em janeiro de R$ 530k, enquanto, em fevereiro, essa receita caiu para R$ 380k (queda de aprox. 28%). Obs.: o dia 08/02 está com a receita incompleta, porque o gráfico foi gerado no meio do dia. ![](https://i.imgur.com/20GmNhX.png)