Você me contou que o processo de paper trading caiu durante a noite. Você o reiniciou antes da próxima decisão, não viu erros e presumiu que ele tinha retomado de onde parou. Então, ele enviou uma ordem de compra para um ativo que você já possuía. Você quer saber se há um bug na estratégia.
Pode haver. Mas, primeiro, confira se o processo reiniciado conhece as mesmas informações que a conta paper. Reiniciar é um problema de recuperação de estado: posições, saldo, ordens abertas e qualquer memória da estratégia que afete a próxima decisão precisam estar de acordo. Fazer o código voltar a funcionar é a parte fácil.
O que a estratégia acreditava antes de falhar?
Anote a última decisão tomada pelo processo antes de parar. Para cada instrumento negociado, registre a posição pretendida, a posição real da conta, as ordens em aberto e o estado do sinal que afetará a próxima ação. Se esses registros não existirem, você não consegue saber se o reinício restaurou o estado ou apenas inicializou uma estratégia nova.
Imagine que sua estratégia horária compre uma unidade quando o sinal de tendência fica positivo e mantenha a posição até ele ficar negativo. O processo envia a ordem de compra às 14:00, mas falha antes de registrar que a ordem foi aceita. A plataforma paper executa a ordem. Ao reiniciar, a estratégia não encontra uma posição registrada e vê que o sinal continua positivo, então envia outra ordem de compra. O sinal está se comportando de forma consistente. A memória da estratégia sobre o que a conta possui é que está desatualizada.
Por isso, a posição atual da conta precisa ser reconciliada com o estado persistido da estratégia antes de permitir novas ordens. Um registro local pode ser útil, mas a conta ou a plataforma é a fonte confiável sobre o que foi realmente executado.
Que estado precisa sobreviver a um reinício?
Comece pelo estado que pode alterar a próxima ordem. Mantenha um registro durável, com data e hora e uma versão para cada atualização; faça uma cópia antes de mudar sua lógica de recuperação para poder reproduzir a falha depois.
| Estado | Por que importa | Verificação de recuperação |
|---|---|---|
| Posições e saldo | Determinam a exposição e o poder de compra disponível | Compare os valores persistidos com os da conta paper |
| Ordens abertas | Uma ordem pode ter sido executada enquanto o processo estava parado | Consulte o status das ordens e reconcilie as execuções parciais |
| Memória dos sinais | Cruzamentos, períodos de espera e duração das posições podem se estender por várias decisões | Restaure as últimas entradas de decisão confirmadas |
| Último evento processado | Define de onde a estratégia retoma o consumo de dados | Reproduza os eventos seguintes sem aplicá-los duas vezes |
É fácil deixar passar a memória dos sinais. Uma estratégia que opera com base em um cruzamento pode armazenar o valor do indicador do dia anterior para detectar um novo cruzamento. Se começar com um valor vazio, pode confundir uma condição já existente com um novo evento. Um temporizador de espera tem o mesmo problema: o reinício não deve zerar silenciosamente uma regra que deveria continuar valendo.
Como tornar a recuperação repetível?
Atribua a cada ordem um ID de cliente estável, derivado da execução da estratégia e da decisão que a originou. Se o processo tentar novamente após um timeout, poderá verificar se aquela decisão já criou uma ordem, em vez de enviar uma ordem duplicada. Registre as mudanças de estado somente depois de confirmar o evento correspondente na conta e mantenha os IDs das ordens e das execuções que explicam a mudança.
Em seguida, teste a situação que causou o incidente. Execute a estratégia até uma decisão, salve o estado, pare o processo e restaure-o com as posições e o histórico de ordens da conta paper. Compare a próxima decisão e as ordens resultantes com uma execução sem interrupções. Repita o teste com uma ordem executada parcialmente e com uma falha entre o envio e a confirmação. A execução retomada não deve inventar uma nova posição nem repetir uma ação concluída.
Mantenha um registro de recuperação: último evento processado, horário do snapshot da conta, status das ordens abertas, versão restaurada da estratégia e primeira decisão após o reinício. Assim, “voltou a funcionar” se torna algo que você pode auditar.
Em que você deve confiar após o reinício?
Confie no processo somente depois que os estados da conta e da estratégia forem reconciliados, as ordens pendentes tiverem status conhecidos e a próxima decisão corresponder ao que você esperaria de uma execução contínua. Se não conseguir explicar uma divergência, pause o envio de ordens paper e examine o histórico de eventos. Um processo em execução não prova que a estratégia foi recuperada.
Você já encontrou o lado útil da falha: ela revelou uma suposição que sua execução normal nunca precisou enfrentar. Transforme o reinício em um cenário repetível e você saberá do que sua estratégia se lembra antes de pedir que ela opere novamente.
← Todos os artigos
