# 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

Fevereiro 2023

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