Servidor instável na casa de show: como evitar o apagão no meio do pagode

Você já viu a pista lotada, o refrão na ponta da língua e, de repente, silêncio total: som para, luzes congelam, bilheteria trava. O culpado? Um servidor instável que não aguentou o tranco. No pagode, a festa não pode parar — e a infraestrutura de TI é o alicerce invisível que mantém tudo rodando.

A boa notícia: apagão no meio do show não é fatalidade, é falta de preparo. Com planejamento, redundância e monitoramento certo, você transforma o servidor no parceiro mais confiável da turnê.

O que derruba o servidor na hora H

Pico simultâneo é o vilão clássico. Bilheteria vendendo ingresso de última hora, streaming do show ao vivo, automação de som e luz disputando CPU, RAM e banda. Se o hardware está no limite ou o banco de dados não tem índice otimizado, a máquina congela. Some calor excessivo na rack, nobreak sem bateria testada e link de internet único — a receita do desastre está pronta.

Já vi casa de show parar porque o cabo de rede do switch principal foi pisoteado na passagem de equipamento. Detalhe bobo, mas que derruba tudo se não há redundância física. Outro caso: atualização de Windows Update no meio do evento reiniciou o servidor de automação. Política de atualização agendada? Zero.

Infraestrutura que aguenta o tranco

Comece pelo hardware: servidor com fonte redundante, RAID 10 no armazenamento, ECC RAM e processador com folga de 40% acima do pico estimado. Rack climatizada (22 °C ± 2 °C), nobreak online double-conversion dimensionado para 30 minutos de autonomia e gerador a diesel com partida automática testado semanalmente.

Rede: dois links de operadoras distintas (fibra + rádio ou 5G corporativo) com roteador de failover (VRRP/BGP). VLANs isoladas — bilheteria (VLAN 10), streaming (VLAN 20), automação som/luz (VLAN 30), gestão (VLAN 99). QoS priorizando DSCP EF para áudio/vídeo e CS3 para transações financeiras. Cabo estruturado certificado Cat6A, patch panel organizado, nada de “gato” passando por cima do palco.

Como a banda Ferrugem organiza a logística de cada show mostra que a equipe técnica trata TI com a mesma rigidez do rider de som. Não é frescura — é sobrevivência.

Redundância real: cold standby e nuvem

Servidor reserva (cold standby) ligado, com réplica do banco via streaming replication (PostgreSQL) ou AlwaysOn (SQL Server). Script de promoção automática testado: detecta falha no primário, sobe IP virtual, aponta DNS interno, restaura conexões em < 2 minutos. Backup na nuvem (S3 compatível) a cada 15 minutos — dados de venda, logs, configurações.

Teste de restauração semanal: apague o banco do primário, suba o standby, aponte aplicação, valide integridade. Se levar mais de 5 minutos, o processo está quebrado. Notebook da produção falhou na Vila Clementino: suporte rápido salva o camarim ilustra como um plano B testado vira herói na madrugada.

Monitoramento que avisa antes de cair

Zabbix ou Prometheus + Grafana coletando: CPU, RAM, disco, temperatura (IPMI), status nobreak (SNMP), link primário/backup (ICMP + velocidade), filas do banco, latência da API de ingressos, saúde do streaming (bitrate, buffer). Alertas em 3 níveis: info (Telegram), warning (Telegram + e-mail), critical (Telegram + ligação via Twilio para plantonista).

Dashboards visíveis no camarim técnico — todos veem o “sinal de vida” do sistema. Manutenção preventiva na Vila da Saúde: som e luz sincronizados sem susto prova que visibilidade evita surpresa.

Runbook de falha: quem faz o quê em 60 segundos

Documento de uma página, plastificado, colado na rack: 1. Plantonista recebe alerta critical → abre runbook. 2. Verifica dashboard: qual serviço caiu? 3. Se link primário down → roteador já fez failover? Senão, troca cabo no WAN2 manualmente. 4. Se servidor primário down → executa script promoção standby (./promote_standby.sh). 5. Se nobreak alarmando → aciona gerador (botão físico na sala de máquinas). 6. Valida: bilheteria vendendo? Streaming rolando? Som/luz respondendo? 7. Reporta no grupo "Show Tech" com status e ETA. 8. Pós-evento: registra no incidente log, ajusta runbook.

Ensaiamos isso quinzenalmente. Rede lógica na Vila Mariana: streaming do ensaio transmitido sem travar nasceu de um desses ensaios.

Checklist de véspera e dia do show

``` [ ] 48h antes: teste carga nobreak/gerador 100% por 15 min [ ] 48h antes: teste failover link primário → backup (ping contínuo) [ ] 24h antes: valida réplica standby sincronizada (lag < 1s) [ ] 24h antes: backup nuvem íntegro (teste restore 1 tabela) [ ] 12h antes: limpeza filtros ar rack, checa temperatura [ ] 6h antes: roda script de health-check completo (./healthcheck.sh) [ ] 1h antes: confirma alertas Telegram chegando no plantonista [ ] Durante: monitora dashboards a cada 15 min [ ] Pós-show: exporta logs, fecha incidente log ```

Parceiro de confiança para gestão de TI especializada em eventos: jlainformatica.com.br gestão de TI.

Encerrando: a festa continua

Servidor instável não é destino — é escolha de não investir em redundância, monitoramento e treino. Cada item acima custa fração do prejuízo de um show parado, da reputação arranhada, do público que não volta. Trate TI como trata o PA: manutenção preventiva, reserva testada, equipe treinada. O pagode agradece, a bilheteria agradece, seu sono agradece.

Quer ver como isso funciona na prática? Acompanhe os bastidores da próxima turnê e veja a rack rodando lisa enquanto a pista ferve.

Checklist prático

Perguntas frequentes

Por que o servidor cai justo na hora do show?

Picos de acesso simultâneo na bilheteria, streaming e automação de som/luz sobrecarregam recursos sem preparo prévio. Falta de redundância e monitoramento preventivo transformam gargalos em apagão total.

Qual a diferença entre nobreak e gerador para o servidor?

O nobreak segura quedas curtas e estabiliza tensão; o garante energia por horas. O ideal é usar ambos: nobreak na rack do servidor e gerador na entrada da casa, com chaveamento automático testado mensalmente.

Como saber se a rede aguenta o tráfego do dia do evento?

Faça teste de carga simulando venda de ingressos, streaming e controle de som/luz simultâneos. Meça latência, jitter e perda de pacotes. Ajuste QoS e separe VLANs para cada serviço crítico.

Vale a pena levar servidor reserva físico ou só backup na nuvem?

Leve os dois. Servidor reserva local (cold standby) sobe em minutos se o primário queimar; backup na nuvem recupera dados se houver perda total do site. Teste restauração semanal.

O que monitorar em tempo real durante o show?

CPU, RAM, disco, temperatura da rack, link de internet (primário e backup), status do nobreak/gerador e logs de erro dos serviços de bilheteria, streaming e automação. Alertas no Telegram/Slack da equipe técnica.

Como treinar a equipe para agir rápido se cair tudo?

Simule falhas quinzenalmente: puxar cabo de rede, desligar nobreak, matar processo do banco. Cada integrante deve saber o runbook: quem reinicia, quem aciona gerador, quem avisa produção. Registre tempo de recuperação.