Gestão de incidentes para um grande evento de automobilismo

Em um grande evento em autódromo, uma falha elétrica ou hidráulica exige resposta rápida e coordenada. Quando o aviso corre por canais soltos, como rádio e telefone, ninguém tem a visão do conjunto: a mesma ocorrência chega por várias pessoas, a equipe perde tempo para achar o local exato e, no fim, não sobram dados sobre os tempos de atendimento.

O sistema substitui esses canais por um só painel, que se atualiza na hora, no qual cada ocorrência é aberta, acompanhada e encerrada com histórico completo.

Um aplicativo web instalável (PWA), usado no celular pela equipe de campo, e um painel para a central de operação. Com ele, é possível:

• registrar uma ocorrência em poucos toques, com nome e horário preenchidos automaticamente e a área sugerida a partir dos dados cadastrados com antecedência;
• escolher a categoria (elétrica ou hidráulica), o tipo de problema em uma lista e a urgência (alta, média ou baixa), e anexar até três fotos;
• registrar mesmo sem conexão, deixando o envio por conta do aplicativo quando a rede voltar;
• acompanhar todas as ocorrências em um quadro ao vivo com seis colunas, uma por situação;
• designar a equipe técnica, mudar a urgência e controlar os prazos de primeira resposta e de solução;
• receber a sugestão de agrupamento quando duas ocorrências parecem ser a mesma;
• encerrar em duas etapas: a equipe resolve e informa o que foi feito, e o coordenador geral valida;
• consultar relatórios por situação, urgência, área e categoria.

Os avisos chegam por notificação no aplicativo e por e-mail. Uma configuração ampliada acrescenta WhatsApp, SMS, um alerta reforçado que se repete até a confirmação dentro do aplicativo, mapa interativo, vídeo e um relatório executivo diário de sete seções.

Sem rede. Quando não há conexão, o aplicativo guarda a ocorrência no aparelho, com o selo “aguardando sincronização”, e a envia automaticamente quando a rede volta, desde que o aplicativo esteja aberto. Ao receber, a central devolve ao solicitante a confirmação “recebido pela central”, com o número da ocorrência. O prefixo do número indica a categoria (EL- ou HI-), a numeração é única e sequencial, e a categoria não muda depois do registro.

Localização. Cada ocorrência é vinculada a uma área. A localização usa pontos fixos da planta do autódromo, cadastrados antes do evento, sem depender de GPS nem de sinal de rede.

Ciclo de vida. A ocorrência passa por seis situações: não atendido, em triagem, em andamento, pendente, resolvido e finalizado. Quem registra não encerra, e quem resolve não valida. Uma ocorrência resolvida só é finalizada quando o coordenador geral a valida, e ele pode reabri-la com um motivo.

Prazos. Cada nível de urgência tem prazo de primeira resposta e de solução, iguais para as duas categorias. Quando a central muda a urgência de uma ocorrência, os prazos são recalculados a partir da abertura, e o relógio não reinicia.

Tempo real. O painel é atualizado por Server-Sent Events. Toda mudança de situação passa por um único ponto de escrita, que confere a permissão pelo contrato, grava o evento e, na mesma transação, emite pelo PostgreSQL o aviso que acorda os demais módulos. Cada notificação é gravada antes do envio e, se a falha for temporária, é reenviada em intervalos cada vez maiores.

Segurança. Cada usuário tem acesso individual, com troca de senha no primeiro acesso e limite de tentativas de login, e as senhas são protegidas com argon2id. Nome, celular e e-mail são usados apenas na operação do evento.

O sistema foi dividido em módulos independentes, como registro, sincronização, painel, notificações e relatórios, construídos sobre um contrato compartilhado escrito em código. O contrato reúne as enumerações, a máquina de estados, as regras de prazo, os esquemas de sincronização, os eventos e as notificações. O plano de cada módulo só pode alterar a própria pasta.

A especificação da API e os tipos do frontend são gerados desse contrato, e a integração contínua reprova a mudança que os deixe fora de sincronia. Operações que levam mais de dois segundos rodam em segundo plano: a API responde com o código 202 (aceito) e o aplicativo mostra o aviso de processamento.

Para testar o sistema antes da entrada em operação, um kit de ensaio simula queda de rede, reinício do backend com notificações em andamento e restauração de backup. Para produção, o sistema é empacotado em três contêineres: PostgreSQL 16, o backend FastAPI e um servidor Caddy, que serve o aplicativo com TLS automático.

O sistema distingue cinco papéis:

• usuário geral cadastrado, que registra e acompanha as ocorrências que abriu;
• coordenador de área, que registra e acompanha as das suas áreas;
• equipe técnica, que recebe designações e registra chegada, andamento e solução;
• responsável técnico da central, que faz triagem, designação e mudança de urgência;
• coordenador geral, que valida o encerramento e decide as duplicidades.

O sistema foi desenvolvido sob medida para um cliente, e não como produto de prateleira. Está totalmente desenvolvido e ainda não foi entregue. A documentação inclui o manual do usuário, o manual do administrador e um roteiro para a entrada em operação. Os limites estão documentados: no iPhone, as notificações exigem o aplicativo na Tela de Início; as ações da equipe técnica precisam de rede; e um registro feito por engano não é cancelado, e sim encerrado pela central.