Exames nacionais (PT): por que grandes sistemas falham quando mais precisamos deles?

Em Portugal, as dificuldades técnicas confirmadas no processo de correção eletrônica dos exames nacionais recolocaram uma pergunta essencial: como um sistema pode funcionar normalmente e revelar limitações justamente quando se torna mais necessário?

O Governo português confirmou as dificuldades e a mudança do calendário. Sem acesso à arquitetura, aos testes, às métricas e aos relatórios técnicos, ninguém pode afirmar com rigor o que aconteceu nesse caso. Qualquer explicação sobre servidores, bancos de dados, redes ou código seria apenas uma hipótese.

O ponto central vai além do episódio em Portugal. Um sistema que funciona não é necessariamente um sistema preparado para escalar, resistir a falhas e se recuperar. Essa diferença afeta plataformas públicas, bancos, universidades, hospitais e empresas cujo negócio depende da internet.

Funcionar não é o mesmo que escalar

Quando milhares de requisições chegam em um intervalo curto, não basta aumentar a potência de uma máquina. A arquitetura precisa distribuir a carga, evitar trabalho repetido, retirar tarefas demoradas do caminho principal e impedir que um único componente limite todo o sistema.

Na escalabilidade vertical, aumenta-se a capacidade da máquina existente. Na horizontal, o trabalho é distribuído entre várias máquinas. O cache evita operações repetidas, o balanceamento reparte as requisições e as filas organizam tarefas demoradas. Contudo, cada mecanismo resolve um problema diferente.

Mais servidores podem aumentar a capacidade, mas não corrigem automaticamente uma arquitetura limitada. Se todas as máquinas dependerem do mesmo banco de dados ou do mesmo serviço, o gargalo permanece. A pressão apenas muda de lugar.

Escalabilidade não é o mesmo que resiliência

Escalabilidade responde ao crescimento da demanda. Resiliência responde à falha. Um sistema pode suportar mais usuários e continuar vulnerável à perda de uma máquina, de uma conexão, de uma região ou de um fornecedor.

Um projeto resiliente parte do princípio de que algum componente deixará de responder. Por isso, distribui recursos, replica dados e prepara uma alternativa capaz de assumir a operação. Se uma parte falhar, o restante do sistema deve continuar ou reduzir as funções de forma controlada.

A infraestrutura precisa de resiliência e escalabilidade. Se uma parte falhar, o sistema deve se redistribuir sem transferir a falha para o usuário.

— Wenderson Wanzeller

Colocar uma aplicação na nuvem também não garante resiliência. Se toda a operação permanecer na mesma região, conta ou infraestrutura, ainda pode existir um único domínio de falha. Dois servidores sujeitos ao mesmo incidente não representam verdadeira independência.

Backup não é recuperação

Guardar uma cópia dos dados é apenas o primeiro passo. A organização precisa confirmar que o backup está completo, acessível e protegido do mesmo incidente que atingiria o sistema principal. Além disso, deve testar regularmente a restauração.

Definir um plano de recuperação exige duas respostas objetivas: quantos dados a organização aceita perder e por quanto tempo pode ficar sem operar? Esses limites orientam a frequência das cópias, a redundância necessária e o investimento adequado.

O sistema precisa avisar antes de parar

Há ainda um elemento decisivo: a observabilidade. Um sistema crítico deve mostrar, em tempo real, onde a pressão está crescendo, qual componente está atrasando e em que ponto uma dificuldade localizada começa a afetar o restante do serviço.

Indicadores como tempo de resposta, erros, uso de recursos e tarefas em espera ajudam a detectar a degradação. Sem essa visão, a equipe técnica pode descobrir o problema apenas quando os usuários já sentem os seus efeitos.

Talvez essa seja a principal lição. O dia crítico não cria necessariamente todas as fragilidades. Ele pode apenas expor limites que permaneciam invisíveis durante o uso habitual.

Minha tese

Por isso, não precisamos conhecer a causa técnica dos problemas nos exames nacionais de Portugal para compreender o alerta. Um sistema crítico não deve ser avaliado apenas pelo dia em que funciona. Deve ser avaliado pelo limite que suporta, pela forma como reage à falha e pelo tempo que leva para se recuperar.

Na tecnologia, o momento em que um sistema para pode ser apenas o ponto final de uma degradação iniciada muito antes. Preparar a infraestrutura para esse momento não é excesso de prudência. É Engenharia de Software.

Referência rápida

Termos deste artigo

Conceitos essenciais para compreender a preparação de grandes sistemas.

Escalabilidade vertical

Aumento da capacidade da máquina existente.

Escalabilidade horizontal

Distribuição do trabalho entre várias máquinas.

Gargalo

Componente que limita o desempenho de todo o sistema.

Resiliência

Capacidade de continuar funcionando ou se recuperar após uma falha.

Domínio de falha

Conjunto de recursos que pode ser afetado pelo mesmo incidente.

Observabilidade

Acompanhamento do estado interno do sistema por meio de métricas e registros.