Recuperação de desastres em uma carteira de trading ativa: checklist semanal

Decida o que entra em failover e o que deve parar

Um operador promove um standby assim que o primário perde conectividade. Outro isola o primário, verifica a posição da replicação e o estado das ordens e, então, promove o standby. A primeira abordagem pode restabelecer a entrada de ordens mais rápido.

A segunda reduz a possibilidade de dois processos ativos enviarem ordens para a mesma carteira. Nenhuma das decisões é segura por si só: a sequência correta depende de como a plataforma lida com autoridade, estado e sessões com venues.

Para uma carteira ativa, a recuperação não significa simplesmente iniciar servidores em outra zona. Significa estabelecer um único processo com autoridade para gravar, restaurar o estado necessário para tomar decisões seguras e comprovar que ordens, execuções, posições e limites de risco estão de acordo. Uma página de login rápida não é evidência de que o serviço de trading está pronto.

Comece nesta semana definindo objetivos de recuperação por função, em vez de estabelecer uma única meta ampla para a plataforma. Separe aceitação de ordens, dados de mercado, preços, verificações de risco, acesso de clientes, relatórios e feeds de back office. Decida quais funções podem ficar temporariamente em modo somente leitura ou indisponíveis e quais devem ser bloqueadas até que o estado seja conciliado. Um objetivo típico pode permitir que os relatórios para clientes fiquem defasados por vários minutos, enquanto exige que a entrada de ordens permaneça desativada até que a carteira esteja consistente.

Registre quem pode declarar um desastre, quem controla o token de failover e quem pode interromper o trading. Um runbook que depende de uma única pessoa reconhecer um alerta não é um runbook. Para uma visão mais ampla das operações de plataforma, a cobertura de infraestrutura da Trading Technology analisa os sistemas dos quais brokers e prop firms dependem.

Mapeie o estado e defina metas mensuráveis

Liste todos os componentes que podem alterar o estado da carteira: gerenciamento de ordens, risco, gateways de execução, serviço de posições, livro-caixa, repositório de sessões de clientes e log de eventos. Para cada um, identifique a fonte de verdade, o método de replicação, o alerta de atraso e o responsável pela recuperação. Inclua sessões com venues e conexões com câmaras de compensação ou prime brokers. Uma réplica de banco de dados não reproduz uma sessão FIX ativa, um cancelamento sem confirmação ou a visão de uma venue sobre uma ordem.

Os números abaixo são faixas típicas de mercado para discussões de planejamento, não garantias nem resultados auditados. As metas de uma empresa dependem de sua arquitetura, venues, conjunto de produtos e obrigações regulatórias. Meça-as em um ensaio sob carga representativa.

Para cada meta, defina os pontos inicial e final da medição. "RTO de cinco minutos" é ambíguo se uma equipe começa a contar a partir do alerta e outra, da declaração do incidente. Registre detecção, isolamento, promoção, validação e primeira ordem permitida como marcações de tempo separadas.

Faça um ensaio controlado nesta semana

Escolha uma janela de baixo risco e uma carteira representativa, incluindo o gateway ou grupo de instrumentos mais movimentado que o ambiente de teste possa suportar com segurança. Não faça failover em produção cortando a energia ou bloqueando uma rota de rede sem uma mudança aprovada, um plano de reversão e coordenação com as venues. Se os testes em produção não forem autorizados, injete falhas no ambiente de staging e compare a configuração e o fluxo de eventos com os de produção.

1. Defina o escopo. Especifique os serviços, venues, contas e operadores incluídos no teste. Registre as posições atuais, as ordens abertas, os limites, o atraso da replicação e o estado das sessões dos gateways.
2. Estabeleça um limite de eventos conhecido. Registre o último número de sequência persistido no primário e no standby. Confirme qual log, banco de dados ou stream define esse número. Anote todos os feeds assíncronos que podem chegar depois.
3. Acione a falha acordada. Simule a perda do serviço ou site primário pelo método aprovado. Observe os alertas e as marcações de tempo. Não permita que o standby aceite gravações antes que o mecanismo de isolamento comprove que o primário antigo não pode gravar.
4. Promova o standby e restaure as dependências. Verifique a configuração, os segredos, os certificados, o DNS ou as alterações de rota, a sincronização do relógio e a conectividade com as venues. Confirme que o standby tem os limites de risco e as configurações de produtos corretos, não apenas um status de processo saudável.
5. Concilie a carteira. Compare as ordens abertas e execuções internas com os registros drop copy das venues ou outros registros equivalentes e oficiais. Resolva ordens novas, pendentes, rejeitadas e parcialmente executadas. Verifique os cancelamentos em andamento; nunca presuma que a falta de uma confirmação significa que uma ordem não chegou à venue.
6. Valide o risco antes de habilitar a entrada de ordens. Recalcule posições e exposição com base na fonte de verdade acordada. Verifique crédito, margem, concentração e limites de envio. Confirme que os kill switches funcionam no site de recuperação.
7. Libere o tráfego de forma controlada. Comece com uma conta de teste designada ou um fluxo limitado e só aumente depois que o monitoramento confirmar as confirmações, execuções, rejeições e atualizações de posição esperadas. Mantenha um operador identificado e autorizado a interromper o teste.
8. Restaure e registre. Teste o failback separadamente, em vez de tratá-lo como o inverso da promoção. Registre os tempos, os eventos perdidos ou duplicados, as intervenções manuais e as divergências não resolvidas; depois, atribua responsáveis e datas para cada correção.

Antes do teste, defina as condições para interrompê-lo. Entre os exemplos estão um primário não isolado, uma lacuna de sequência além do objetivo de ponto de recuperação aprovado, diferenças de posição sem explicação, limites de risco desatualizados ou uma sessão com uma venue que ainda possa estar ativa nos dois sites. Registre quem tem autoridade para abortar e deixe clara para toda a equipe a ação de interrupção.

Comprove que é seguro negociar após a recuperação

Depois do ensaio, analise as evidências em vez de confiar em um painel verde. Verifique a continuidade da sequência de eventos, o tratamento de duplicatas, a conciliação de ordens e execuções, os cálculos de risco, o estado visível para os clientes e a cobertura do monitoramento. Compare os tempos reais com as metas de cada função. Se a aceitação de ordens voltou em quatro minutos, mas o recálculo de risco levou doze, a carteira não foi recuperada em quatro minutos.

Registre as constatações em uma lista breve de ações:

• Elimine qualquer caminho que permita dois processos gravando, inclusive credenciais antigas ou uma concessão de liderança ainda válida.
• Configure alertas para atraso na replicação, falhas nos feeds de drop copy e desvios do relógio antes de um incidente.
• Faça com que o runbook mostre comandos, permissões, responsáveis pelas decisões e etapas de reversão. Valide o acesso a partir do ambiente de recuperação.
• Repita o teste após mudanças relevantes no gerenciador de ordens, no mecanismo de risco, na conectividade com venues, na região de nuvem ou na topologia de replicação.

Mantenha o registro da recuperação junto aos procedimentos de incidentes e às evidências de auditoria. Inclua o escopo do teste, as versões, as marcações de tempo, as divergências, as decisões dos operadores e os responsáveis pelas correções. Um exercício trimestral de recuperação de todo o site pode testar dependências mais amplas, mas verificações curtas e direcionadas toda semana podem detectar antes certificados expirados, rotas alteradas e desvios de configuração.

Este checklist pressupõe que a empresa ou seu provedor de tecnologia pode controlar a promoção e inspecionar o estado oficial de trading. Ele não se aplica sem alterações durante uma interrupção de bolsa ou câmara de compensação, quando a troca da infraestrutura do próprio broker não pode restaurar a venue externa, nem quando um contrato de plataforma terceirizada não dá à empresa controle sobre os mecanismos de failover. Nesses casos, siga o processo de incidentes da venue ou obtenha do provedor evidências de recuperação testada e defina as responsabilidades antes de confiar nas metas de recuperação dele.

#failover do livro de trading #recuperação de desastres para brokers #resiliência da plataforma de trading #failover ativo-passivo #reprodução de ordens #conciliação de operações #objetivo de tempo de recuperação #controles de risco