【Continuação avançada de CJ 14/30 · Artigo n.º 42】
O erro mais fácil de cometer num programa é forçar um estado sem resposta a ser classificado como «falha» ou «sucesso».
Um pedido ter expirado não significa que a ordem não tenha sido executada; uma resposta anómala da interface não significa que a posição já tenha sido encerrada. Se, nesse momento, o sistema voltar a tentar como se tivesse ocorrido uma falha, poderá enviar ordens duplicadas; se prosseguir como se tivesse sido bem-sucedido, poderá deixar por tratar uma exposição que exige atenção. O perigo de um estado desconhecido está no facto de levar o programa a fingir que conhece os factos.
A abordagem mais segura é tratar o estado desconhecido como um estado de primeira classe: suspender as ações relacionadas, guardar a identidade e a hora do pedido, confirmar o resultado real através de uma consulta independente e só então decidir se deve retomar, cancelar ou solicitar intervenção humana. O tempo de espera pela confirmação também deve ser monitorizado, em vez de ficar pendente para sempre.
Mesmo depois de obter o resultado, não se deve ignorar a identidade do pedido original. É preciso primeiro confirmar a que ordem corresponde o resultado da consulta e, depois, tratar o que resta. Só assim se evita confundir uma ordem semelhante com a resposta pretendida. A retoma deve basear-se em factos confirmados, não em suposições feitas após uma espera demasiado longa.
Um sistema de negociação não consegue eliminar todas as incógnitas, mas pode evitar que os riscos aumentem enquanto elas persistem. Admitir «não sei» é, por vezes, a ação de automação mais profissional.
No próximo artigo: uma execução parcial pode facilmente transformar uma única cobertura em dois tipos de risco.
#状态机 #Fiabilidade do sistema
O erro mais fácil de cometer num programa é forçar um estado sem resposta a ser classificado como «falha» ou «sucesso».
Um pedido ter expirado não significa que a ordem não tenha sido executada; uma resposta anómala da interface não significa que a posição já tenha sido encerrada. Se, nesse momento, o sistema voltar a tentar como se tivesse ocorrido uma falha, poderá enviar ordens duplicadas; se prosseguir como se tivesse sido bem-sucedido, poderá deixar por tratar uma exposição que exige atenção. O perigo de um estado desconhecido está no facto de levar o programa a fingir que conhece os factos.
A abordagem mais segura é tratar o estado desconhecido como um estado de primeira classe: suspender as ações relacionadas, guardar a identidade e a hora do pedido, confirmar o resultado real através de uma consulta independente e só então decidir se deve retomar, cancelar ou solicitar intervenção humana. O tempo de espera pela confirmação também deve ser monitorizado, em vez de ficar pendente para sempre.
Mesmo depois de obter o resultado, não se deve ignorar a identidade do pedido original. É preciso primeiro confirmar a que ordem corresponde o resultado da consulta e, depois, tratar o que resta. Só assim se evita confundir uma ordem semelhante com a resposta pretendida. A retoma deve basear-se em factos confirmados, não em suposições feitas após uma espera demasiado longa.
Um sistema de negociação não consegue eliminar todas as incógnitas, mas pode evitar que os riscos aumentem enquanto elas persistem. Admitir «não sei» é, por vezes, a ação de automação mais profissional.
No próximo artigo: uma execução parcial pode facilmente transformar uma única cobertura em dois tipos de risco.
#状态机 #Fiabilidade do sistema