Exames nacionais: porque falham os grandes sistemas quando mais precisamos deles?

As dificuldades informáticas confirmadas no processo de classificação eletrónica dos exames nacionais voltaram a colocar uma pergunta essencial: como pode um sistema funcionar normalmente e revelar limitações precisamente no momento em que se torna mais necessário?

O Governo português confirmou as dificuldades e a alteração 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 neste caso. Qualquer explicação sobre servidores, bases de dados, redes ou código seria apenas uma hipótese.

O ponto importante está além deste episódio. Um sistema que funciona não é necessariamente um sistema preparado para escalar, resistir a falhas e 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 pedidos chegam num intervalo curto, não basta aumentar a potência de uma máquina. A arquitetura precisa de 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, distribui-se o trabalho por várias máquinas. A cache evita operações repetidas, o balanceamento reparte os pedidos 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 da mesma base de dados ou do mesmo serviço, o ponto de estrangulamento permanece. A pressão apenas muda de lugar.

Escalabilidade não é o mesmo que resiliência

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

Um projeto resiliente assume 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 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 redistribuir-se sem transferir a falha para o utilizador.

— Wenderson Wanzeller

Colocar uma aplicação na cloud também não garante resiliência. Se toda a operação permanecer na mesma região, conta ou infraestrutura, pode continuar a 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 constitui apenas o primeiro passo. A organização precisa de 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 quanto tempo pode permanecer parada? Esses limites orientam a frequência das cópias, a redundância necessária e o investimento adequado.

O sistema precisa de 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á a crescer, que componente está a atrasar e em que ponto uma dificuldade localizada começa a afetar o restante serviço.

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

Talvez seja esta a principal lição. O dia crítico não cria necessariamente todas as fragilidades. Pode apenas expor limites que, sob uma utilização habitual, permaneciam invisíveis.

A minha tese

Por isso, não precisamos de conhecer a causa técnica dos problemas nos exames nacionais 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 demora a 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 Informática.

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 por várias máquinas.

Ponto de estrangulamento

Componente que limita o desempenho de todo o sistema.

Resiliência

Capacidade de continuar a funcionar ou 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 através de métricas e registos.