Plataformas · Software · Provedores · Mercados
Devin Hartcastle
O site de recuperação só é útil se puder assumir a carteira sem perder o controle das ordens já enviadas ao mercado. Esse requisito pesa mais no custo do que um segundo conjunto de servidores. Um plano viável precisa recuperar posições, limites de risco, estado das ordens, dados de mercado e sessões com as venues em uma sequência controlada e, em seguida, comprovar que o sistema recuperado pode operar com segurança.
Defina metas de recuperação com base no estado do trading
O objetivo de tempo de recuperação (RTO) mede por quanto tempo o serviço pode ficar indisponível. O objetivo de ponto de recuperação (RPO) mede quanto estado a empresa pode se dar ao luxo de perder. Para uma carteira de trading, uma meta genérica de recuperação de banco de dados não basta: uma ordem aceita pelo sistema primário, mas não confirmada por uma venue, gera uma incerteza que a infraestrutura, por si só, não consegue resolver.
As faixas típicas de planejamento variam conforme a arquitetura e o acesso às venues. Um warm standby pode ter como meta um RTO de 5 a 30 minutos e um RPO de 1 a 10 segundos. Um hot standby pode ter como meta de 30 segundos a 5 minutos, com um RPO de menos de um segundo a cerca de 2 segundos. Arquiteturas active-active podem ter como meta de 1 a 30 segundos, mas o roteamento, a recuperação de sessões e a reconciliação de ordens podem levar mais tempo do que a descoberta do serviço. Considere essas faixas como parâmetros de projeto, não como garantias.
Defina metas separadas para envio de ordens, verificações de risco, posições, dados de mercado e relatórios para clientes. Uma carteira pode restaurar rapidamente o acesso de leitura e manter o envio de ordens bloqueado até que o sistema primário seja isolado e o estado das ordens nas venues seja reconciliado. Isso é mais seguro do que anunciar um RTO curto que considera recuperado um sistema ativo, mas ainda não verificado.
Orce todo o caminho de recuperação
Os valores abaixo são faixas típicas de planejamento em dólares americanos para uma implantação de broker ou prop firm de pequeno a médio porte. Não são resultados auditados.
Os custos mensais incluem uma alocação indicativa para engenharia e operações, mas excluem licenças de dados de mercado, taxas de bolsas e grandes reescritas de aplicações. Esses itens dependem de contratos e bases de código e podem alterar significativamente o total.
| Arquitetura, faixas típicas de mercado | Custo recorrente por mês, faixa típica | Custo de implementação, faixa típica | Meta típica de RTO | Meta típica de RPO |
|---|---|---|---|---|
| Warm standby, capacidade iniciada ou ampliada durante a recuperação | $15,000 a $60,000 | $50,000 a $250,000 | 5 a 30 minutos | 1 a 10 segundos |
| Hot standby, serviços centrais em execução e dados replicados | $30,000 a $115,000 | $150,000 a $750,000 | 30 segundos a 5 minutos | Menos de 1 segundo a 2 segundos |
| Active-active, tráfego e estado gerenciados entre os sites | $60,000 a $200,000+ | $400,000 a $1.5 milhão+ | 1 a 30 segundos | Quase zero a 1 segundo |
As faixas incluem computação e armazenamento, bancos de dados ou logs de eventos replicados, links de rede, monitoramento, trabalho de implantação e uma parcela da mão de obra operacional. Os custos aumentam com a quantidade de instrumentos, o pico de ordens por segundo, a retenção, a distância geográfica e o número de venues que exigem conectividade independente. Active-active não significa simplesmente o dobro do custo dos servidores: também exige tratamento de conflitos mais complexo, testes e cobertura operacional.
Direitos de uso de dados de mercado e conectividade com venues são lacunas comuns no orçamento. Confirme se feeds do site de backup, sessões, cross-connects e acesso para recuperação de desastres estão incluídos nos contratos existentes. Um site tecnicamente pronto ainda pode não conseguir receber dados licenciados ou se conectar a uma venue.
Torne o failover seguro para ordens em andamento
Replique um registro somente de acréscimo dos eventos de negócio, não apenas um snapshot copiado periodicamente. O sistema de recuperação precisa manter uma sequência consistente de solicitações de ordens, confirmações, execuções, cancelamentos, decisões de risco e alterações de posição. Use chaves de idempotência e números de sequência para que a reprodução não transforme uma instrução do cliente em duas ordens.
Durante uma falha de site, não presuma que um timeout significa que a ordem foi rejeitada. A venue pode tê-la aceitado enquanto a confirmação se perdia.
Isole o sistema primário para impedir que envie mais tráfego, restaure o estado durável mais recente e, em seguida, reconcilie ordens em aberto e execuções usando os registros oficiais da venue ou o drop copy antes de habilitar novas ordens. A sequência exata depende do protocolo da venue e do projeto do gateway.
- Mantenha os limites de risco, o status das contas e o estado das posições no caminho de recuperação, com verificações para dados desatualizados ou incompletos.
- Defina qual site é responsável por cada sessão com uma venue. Use tokens de fencing ou um controle equivalente para impedir que os dois sites atuem como primários.
- Separe a recuperação dos dados de mercado da recuperação do envio de ordens. Preços desatualizados devem bloquear as verificações de risco afetadas, em vez de serem aceitos silenciosamente como atuais.
- Registre cada decisão de failover e transição de estado com timestamps que as equipes de operações possam comparar entre os sistemas.
A replicação síncrona pode reduzir a perda de dados, mas adiciona latência e vincula a disponibilidade ao link. A latência típica de ida e volta entre regiões pode variar de cerca de 20 a 80 milissegundos; um link metropolitano pode ficar em torno de 1 a 5 milissegundos.
Muitos sistemas de trading replicam eventos críticos de forma assíncrona e usam controles de reconciliação, em vez de adicionar uma ida e volta de longa distância a cada ordem. A escolha certa depende da tolerância à perda para cada tipo de estado.
Teste o serviço, não apenas os servidores
Uma troca de infraestrutura bem-sucedida não comprova que uma carteira de trading foi recuperada. Simule falhas no gateway de ordens, no banco de dados, no caminho de rede, no processador de dados de mercado e no site primário. Inclua uma desconexão da venue durante uma ordem em andamento, porque testes com desligamento controlado não detectam a ambiguidade que cria o risco de execuções duplicadas.
Um exercício útil começa com uma carteira conhecida, injeção controlada de falhas, uma autoridade definida para declarar que o sistema primário foi isolado e uma etapa de reconciliação antes da retomada do trading. Meça o RTO desde a primeira falha detectada até a primeira ordem verificada e habilitada para risco, não até o momento em que um processo é iniciado. Meça o RPO em relação ao log de eventos e compare as posições reconstruídas com as execuções da venue.
- Faça mensalmente um teste de recuperação em nível de componente, incluindo backups, credenciais, certificados e acesso às configurações.
- Faça um exercício completo do site pelo menos anualmente e após alterações relevantes em gateways, roteamento, bancos de dados ou conectividade com venues.
- Registre o tempo decorrido, eventos ausentes ou duplicados, intervenções manuais e qualquer diferença entre o estado interno das ordens e o estado na venue.
Designe um responsável para cada modo de falha e registre as evidências necessárias para declarar a recuperação. Um runbook que depende da memória de um único engenheiro representa um custo operacional oculto. Uma etapa manual controlada pode ser aceitável, mas sua duração e a autoridade de decisão precisam ser incluídas no RTO.
Escolha o projeto de menor custo que atenda ao risco da carteira
Warm standby costuma ser adequado para empresas que podem interromper o trading por alguns minutos e fazer uma reconciliação cuidadosa antes de reabri-lo. Hot standby é mais apropriado quando uma interrupção prolongada gera custos diretos para clientes ou riscos, mas ainda exige uma transferência deliberada das sessões. Active-active só se justifica quando a empresa precisa de serviço contínuo e a aplicação consegue gerenciar com confiabilidade a titularidade do estado, as solicitações duplicadas e as condições de split-brain.
Monte o orçamento a partir dos componentes, em vez de aplicar um único percentual de resiliência. Calcule o custo de uma segunda localização, da replicação de dados, da rede e do acesso às venues, dos ambientes de teste, da cobertura operacional e dos exercícios anuais.
Em seguida, estime o custo dos direitos de uso de dados de mercado e de qualquer suporte de fornecedores necessário durante um incidente. O panorama mais amplo de plataformas e provedores altera as opções disponíveis; a cobertura de infraestrutura da Trading Technology é um dos lugares para acompanhar essas dependências.
Mantenha o primeiro objetivo de recuperação restrito: restaurar uma visão verificada da carteira, reconciliar o estado nas venues e habilitar o envio de ordens somente quando os controles de risco estiverem atualizados. Amplie a automação depois que os exercícios demonstrarem que a sequência funciona.
Realize ou inspecione o próximo exercício e meça os segundos entre a injeção da falha e a primeira ordem verificada e habilitada para risco. O limite a verificar é 60 segundos.
Perguntas frequentes
Qual é um RTO realista para uma plataforma de trading?
As metas típicas de planejamento variam de 5 a 30 minutos para warm standby, de 30 segundos a 5 minutos para hot standby e de 1 a 30 segundos para algumas arquiteturas active-active. A recuperação de sessões com venues e a reconciliação de ordens podem prolongar o tempo até a retomada segura do trading.
Quanto custa a recuperação de desastres para uma plataforma de trading?
As faixas típicas de planejamento mensal são de $15,000 a $60,000 para warm standby, de $30,000 a $115,000 para hot standby e de $60,000 a $200,000 ou mais para active-active. Licenças de dados de mercado, taxas de bolsas e grandes alterações nas aplicações podem elevar significativamente esses valores.
Como um broker deve lidar com ordens em andamento durante o failover?
Isole o sistema primário com falha para impedir que continue enviando ordens e, em seguida, reconcilie o estado recuperado com os registros oficiais da venue ou o drop copy. Trate o timeout de uma ordem como uma situação incerta, não como rejeição, e não habilite novos fluxos de ordens até que o risco de duplicidade esteja controlado.
Com que frequência uma empresa de trading deve testar a recuperação de desastres?
Faça testes de recuperação em nível de componente regularmente. Verificações mensais são uma prática operacional comum, e um exercício completo do site deve ser realizado pelo menos anualmente. Repita os testes após alterações significativas em gateways, roteamento, bancos de dados ou conectividade com venues.
