Seu ambiente de produção mora onde? "Na nuvem" é meia resposta

Quem faz software sabe descrever a arquitetura da aplicação nos mínimos detalhes: a linguagem, o banco, a fila, o cache, a forma como cada serviço conversa com o outro. Pergunte onde tudo isso roda e a resposta encolhe para três palavras: "está na nuvem".

É uma resposta que diz onde o servidor não está. E mais nada.

Não é desleixo. É que "nuvem" virou um guarda-chuva grande demais: cabe embaixo dele desde uma máquina virtual avulsa contratada com cartão de crédito até um ambiente desenhado, monitorado e operado por gente. As duas coisas se chamam igual e se comportam de maneiras opostas no dia em que alguma coisa quebra.

As quatro perguntas que "na nuvem" não responde

Antes de discutir provedor, preço ou tecnologia, vale responder a estas quatro. Elas não são técnicas: são operacionais, e é por elas que a conta chega.

1. Quem opera o sistema operacional e o banco fora do horário comercial?

Contratar servidor não é contratar quem cuida dele. Na maior parte dos arranjos de nuvem pública, o provedor garante que a máquina existe e liga — o que roda dentro dela continua sendo trabalho de alguém do seu time. Às três da manhã de um sábado, esse alguém tem nome.

2. O que acontece quando o provedor tem incidente na região?

Provedores grandes têm incidentes. Não é acusação: é estatística de qualquer infraestrutura do mundo. A pergunta útil não é "isso pode acontecer", e sim "quando acontecer, o que a nossa operação faz". Se a resposta for esperar o painel de status do fornecedor mudar de cor, esse é o plano — e é bom que todo mundo saiba disso antes, não durante.

3. Quem restaura, com que cópia e em quanto tempo?

Repare que são três perguntas dentro de uma. Ter cópia não basta; é preciso saber quem executa a restauração, de qual ponto no tempo ela volta, e quanto tempo o processo leva do começo ao fim. Empresa nenhuma decide isso com o incêndio já aceso.

4. Onde está escrito o que foi feito na última mudança que quebrou algo?

Ambiente sem registro de mudança é ambiente que só uma pessoa entende. Funciona muito bem — até o dia em que essa pessoa está de férias, saiu da empresa ou simplesmente não lembra.

Nuvem pública e nuvem privada resolvem problemas diferentes

Não existe a melhor das duas no vácuo, e desconfie de quem afirma o contrário sem perguntar nada sobre a sua operação.

Na nuvem pública você compra uma fatia padronizada de um catálogo enorme e configura sozinho. A vantagem é real: começa em minutos, cresce e encolhe rápido, e você paga pelo que usar. O que vem junto — e quase nunca entra na planilha de comparação — é que o trabalho de operação continua inteiro do seu lado. Dimensionar, endurecer, atualizar, monitorar, testar a volta: tudo isso é seu.

Num ambiente de produção em nuvem privada, a lógica é outra: ele é desenhado para a sua operação e operado por quem o desenhou. Dimensionamento, segurança, cópia e monitoramento vêm no mesmo pacote, porque não fazem sentido separados. Em troca, ela não é elástica do mesmo jeito: crescer envolve conversa e planejamento, não um clique.

A comparação honesta de custo, portanto, não é preço de máquina contra preço de máquina. É preço de máquina mais as horas do seu time contra o valor de um ambiente operado. Feita assim, a conta costuma dar outro resultado — para os dois lados, dependendo do caso.

O teste de dois minutos

Existe uma forma rápida de descobrir em que situação a sua empresa está, e ela não exige consultor nenhum.

Abra o último incidente sério de produção que vocês tiveram. Procure três informações:

1. A hora em que alguém percebeu.
2. A hora em que alguém agiu.
3. O registro do que foi mudado naquele dia e nos dias anteriores.

Se a primeira hora veio de um cliente reclamando, o ambiente não está monitorado — está sendo observado por acaso, e o sensor é o seu cliente. Se a distância entre perceber e agir for grande, o problema não é técnico: é de plantão. E se o terceiro item não existir, a investigação de causa vai depender de memória, que é o pior instrumento disponível numa madrugada.

Backup de repositório não é backup de produção

Este é o engano mais comum em time de software, e ele é honesto: o código está versionado, tem histórico, tem cópia na máquina de todo mundo. Parece que está tudo salvo.

Só que o que derruba a operação raramente é o código. É o banco de dados. É a fila de mensagens no meio do processamento. É o arquivo que o usuário subiu ontem. É a variável de configuração que alguém ajustou na mão, há oito meses, e que não está escrita em lugar nenhum.

Cópia de código é uma parte pequena — e a mais fácil — do que precisa voltar. O resto exige uma decisão consciente sobre o que é copiado, de quanto em quanto tempo, por quanto tempo é guardado e, principalmente, se aquilo volta mesmo.

O dígito que separa backup de esperança

A regra clássica é conhecida: três cópias, em duas mídias diferentes, com uma delas fora do local. A evolução dela acrescentou dois passos, e são eles que fazem diferença.

O primeiro é uma cópia imutável: protegida contra alteração e exclusão durante o prazo de guarda, inclusive por quem tem senha de administrador. É a cópia que sobra depois de um ransomware, justamente porque nem uma credencial roubada consegue apagá-la.

O segundo é a verificação: a cópia é restaurada em ambiente separado e conferida — o sistema abre, os dados estão lá, a data bate. Sem esse passo, o relatório que diz "concluído com sucesso" atesta apenas que a cópia foi gerada. Não que ela volta.

É a diferença entre um extintor pendurado na parede e um extintor que alguém descarregou no ano passado para ver se sai espuma.

O que decide, no fim

Nada disso elimina falha. Equipamento falha em qualquer lugar do mundo, provedor grande falha, disco falha, gente erra. Prometer o contrário seria desonesto, e quem opera infraestrutura há algum tempo sabe.

O que muda é outra coisa, e é ela que vale a conversa: quanto tempo você demora para saber, e quanto tempo leva para voltar. Essas duas medidas não dependem de sorte. Dependem de o ambiente ter sido desenhado por alguém que já perdeu uma madrugada — e de estar escrito, antes de precisar.

Se você responde por um sistema em produção e não sabe dizer de cabeça em quanto tempo ele voltaria, essa conversa começa por aí. O levantamento é sem custo.