O desafio
Uma operação que só reagia depois do alarme
Na Didática Digital, a infraestrutura toda era cuidada pelos próprios desenvolvedores, e o modelo era puramente reativo: só se descobria um problema quando um alarme disparava, ou seja, quando já era tarde. Somavam-se a isso um servidor local sujeito a quedas e um banco de dados com queries lentas e travamentos que ninguém tinha tempo de investigar a fundo.
Ponto de partida
- Infra cuidada pelos próprios desenvolvedores
- Modelo reativo: só se sabia pelo alarme
- Servidor local com quedas
- Queries lentas e travamentos no banco
- Backups e acesso sem padrão definido
Onde chegamos
- Operação na IBM Cloud, com menos quedas
- Observabilidade proativa (Zabbix + Uptime Kuma)
- Banco e Tomcats otimizados com o time
- VPN e backups indo direto para o S3
- Devs livres da gestão de infra
Com Zabbix e Uptime Kuma, os sinais aparecem antes de virarem incidente, e dá tempo de agir.
A solução
O que a InfraCtrl fez
Para a IBM Cloud, com Hyper-V
Tiramos a operação do servidor local e migramos para a IBM Cloud, usando Hyper-V como virtualizador. Só essa mudança já reduziu as quedas dos sistemas.
Trabalho lado a lado com os DBAs
Trabalhamos em conjunto com os DBAs para identificar as queries mais lentas, os travamentos e afins, atacando na raiz o que deixava o sistema pesado e instável.
Time no suporte otimizando Tomcats e servidores
Colocamos o time no suporte para otimizar os Tomcats e os servidores, ajustando a operação para ganhar estabilidade e desempenho no dia a dia.
VPN e backup indo direto para o S3
Implantamos VPN para acesso seguro ao ambiente e passamos a enviar os backups direto para o S3, com armazenamento confiável e fora do servidor de produção.
Observabilidade com Zabbix e Uptime Kuma
Trocamos o "só descobrir pelo alarme" por Zabbix e Uptime Kuma, que permitem identificar os problemas antes, quando ainda são um sinal, e não uma queda.