Servidor, publicação, backup e monitoramento: a parte do trabalho que ninguém percebe enquanto funciona, e a única que importa no dia em que para.
Quase toda empresa responde “sim” à primeira e trava na segunda. É exatamente aí que mora a diferença: backup que nunca foi restaurado não é backup, é esperança — e o dia de descobrir isso é sempre o pior dia possível.
As outras três são do mesmo tipo. Não perguntam que tecnologia você usa, perguntam quanto tempo a sua empresa fica parada, quem fica sabendo e quem ainda consegue entrar no servidor. A última costuma ser a mais desconfortável: em boa parte dos casos que chegam aqui, quem tem a chave é alguém que não trabalha mais para a empresa há anos.
Se você respondeu as cinco sem hesitar, provavelmente não precisa deste serviço — e é melhor saber disso agora do que depois de uma proposta.
Software que ninguém observa não está sob controle. Está sob sorte.
Disco falha, provedor tem incidente, atualização sai errada. Nenhuma configuração impede isso. O que se decide em projeto é o que acontece depois — se o site cai junto ou se o tráfego contorna sem ninguém do lado de fora perceber.
A verificação de saúde é o que separa uma coisa da outra. Sem ela, a borda continua mandando gente para uma instância morta e o visitante recebe erro. Com ela, a instância some da rotação em segundos e o tráfego se redistribui — o mesmo desvio que você vê acontecendo aí em cima, de tempos em tempos.
Repare que algumas requisições se perdem no momento da queda, em ocre. Isso é honesto: failover não é mágica, e quem promete perda zero está vendendo outra coisa. O que se ganha é a diferença entre alguns pedidos com erro por alguns segundos e a loja inteira fora do ar por três horas.
Quatro frentes que costumam ser vendidas por empresas diferentes — e é na emenda entre elas que o problema some do radar de todo mundo.
Dimensionar, configurar e endurecer o que sustenta a aplicação: sistema atualizado, firewall fechado por padrão, acesso por chave em vez de senha, certificado que renova sozinho e a separação entre o que é público e o que nunca deveria ser. É o trabalho que não aparece em tela nenhuma e responde pela maior parte dos incidentes que não acontecem.
Build e publicação sem passo manual, com ambiente de homologação igual ao de produção e volta atrás quando algo passa batido. Deploy que dá medo é deploy que se adia, e software que não é publicado não é corrigido — a correção fica pronta e envelhece esperando uma janela que nunca chega.
Rotina de cópia, cópia fora do mesmo provedor e — a parte que costuma faltar — restauração testada de verdade, com o tempo de volta medido e escrito na proposta. Enquanto ninguém restaurou, o backup é uma suposição sobre um arquivo que ninguém abriu.
Log, métrica e alerta para o problema aparecer em painel antes de aparecer em reclamação de cliente. E revisão do que a nuvem cobra: boa parte da conta costuma ser máquina superdimensionada por precaução, e cortar isso muitas vezes paga o próprio trabalho no primeiro semestre.
Ninguém precisa de arquitetura elegante antes de ter backup que volta. A ordem abaixo é a do risco, não a do portfólio — e é a mesma tanto para infraestrutura que nós montamos quanto para a que herdamos de outro fornecedor.
Mapear o que existe: onde roda, quem tem acesso, o que já caiu e o que ninguém sabe explicar. Sem isso, assumir um servidor é dirigir com o vidro embaçado.
O que primeiro? Quase nunca é a arquitetura bonita. É backup que volta, acesso sob controle e alerta que chega em alguém — nessa ordem, porque é a ordem do que dói.
Mudanças em etapas, cada uma reversível. Infraestrutura é o lugar onde a mudança grande de uma vez só é como se derruba o que estava de pé.
O regime permanente: acompanhar, ajustar, testar restauração de novo e revisar custo. É aqui que o trabalho deixa de ser projeto e vira contrato.
São camadas diferentes e costumam andar juntas. A manutenção cuida do software — corrigir, evoluir, atender pedido. Esta frente cuida do chão onde ele roda: servidor, publicação, backup e alerta. Dá para contratar só uma; o que não dá é achar que contratar a primeira resolve a segunda, que é o mal-entendido mais caro daqui.
Na maioria das vezes não, e quando a resposta for trocar você vai ouvir o motivo em número, não em opinião. Boa parte do ganho está em configurar direito o que já existe: backup que volta, deploy sem passo manual e alerta que chega em alguém. Migração é decisão cara e só entra na proposta quando se paga.
Provavelmente não. O desenho mostra o princípio, não a receita: para a maior parte dos sites e lojas, uma máquina bem configurada com backup testado e um plano de volta escrito resolve, e redundância seria dinheiro parado. Ela começa a se pagar quando uma hora fora do ar custa mais que o segundo servidor — e esse número quem tem é você. A conta entra na proposta.
Não, e prometer isso seria mentira de time do nosso tamanho. O que existe é alerta automático, prazo de resposta escrito em contrato e sistema montado para degradar sem cair — porque a maior parte dos incidentes se evita na configuração, não no plantão. Se a sua operação exige alguém acordado às três da manhã, essa é uma estrutura maior, e a gente diz isso na primeira conversa em vez de descobrir junto no primeiro incidente.
Sim, e é boa parte do trabalho. Começa pelo levantamento do que existe hoje, porque assumir um servidor sem saber o que roda nele é aceitar a responsabilidade sem a informação. Quando não há documentação nem acesso, o caminho passa antes pelo resgate de sistema — é o mesmo trabalho de investigação, e ele vem primeiro.
Você leva tudo: acesso, documentação do que foi montado, scripts da esteira e o procedimento de restauração. Nada aqui depende de uma ferramenta nossa que só a gente opera. Infraestrutura que só um fornecedor entende é exatamente o problema que a maioria dos nossos clientes chega querendo resolver.
Calango Lab