Introdução

Quem trabalha com infraestrutura sabe que o papel aceita tudo. Você passa meses desenhando a arquitetura perfeita no Miro, calcula a latência, planeja a janela de manutenção milimetricamente e bota a mão no fogo pelo deploy. Aí chega o dia de rodar o pipeline em produção e o mundo real te dá um choque de realidade.

Recentemente, tirei uns dias de férias para pedalar o Caminho da Fé de bicicleta. Foram dois anos planejando a logística, os gastos e as metas. No meu roteiro, a meta eram 6 dias de pedal. Na prática? Nada saiu como planejado — e foi a melhor coisa que aconteceu.

No DevOps e na vida real, o planejamento não serve para prever o futuro com precisão cirúrgica, mas sim para te dar um norte quando a infraestrutura (ou as pernas) resolverem cobrar a conta.

O plano de capacidade que cai no primeiro pico de tráfego

No meu primeiro dia de pedal, saindo de Águas da Prata/SP, encontrei dois parceiros de rota. Alinhamos o ritmo e tomamos a decisão técnica mais acertada da viagem: pedalaríamos até o final da tarde, sem a obrigação de chegar a um ponto fixo pré-determinado. Tiramos a pressão do "target" estático.

Fechamos o dia com 66 km rodados e impressionantes 1.748 metros de subida acumulada. Eu nunca tinha subido tanto na minha vida.

Bash

# O que o "planejamento" achou que ia ser:
pedal_estimado_por_dia="50km" 

# O que a "produção" entregou logo no monitoramento do Day 1:
subida_acumulada="1748m"
status_pernas="overloaded_95_percent"

Se estivéssemos engessados em um cronograma rígido de hotel reservado por quilometragem exata, o estresse mental teria engolido a experiência. Trazendo para o nosso dia a dia na TI: monitoramento serve para você entender o comportamento do sistema em tempo real e tomar decisões baseadas em dados vivos, não para tentar forçar a aplicação a rodar dentro de um PDF de arquitetura estático.

Quando o martelo do Thor bate na sua infraestrutura

No terceiro dia, o cansaço acumulado cobrou o preço. O clima esquentou, encaramos a Serra do Caçador e o peso das subidas bateu firme. É o equivalente àquele vazamento de memória silencioso que vai consumindo o cluster até dar um Out of Memory (OOM) Killer no meio do plantão.

Minha ideia inicial era chegar até Luminosa, mas o "martelo do Thor" bateu forte e o limite físico e mental deu as caras. Tivemos que abortar o plano original e parar antes, em São Bento de Sapucaí.

⚠️ Erro comum de arquitetura: Achar que sua resiliência é infinita. No mundo real, quando o sistema dá sinais de fadiga (alertas de latência subindo ou saturação de disco), insistir em empurrar a carga para bater a meta do dia vai derrubar a operação inteira.

💡 Melhoria prática: Aprenda a implementar o conceito de Graceful Degradation (degradação suave). Não dava para chegar no destino final? Paramos antes, descansamos na Pousada da Vó, jantamos uma comida feita no fogão a lenha e recuperamos o fôlego para encarar a subida mais desafiadora (a Serra da Luminosa) com o "sistema" reiniciado e estável no dia seguinte.

Conclusão

Planejar é obrigatório para concentrar gastos, definir metas e mitigar riscos. Mas o plano é só um mapa, não o território. A verdadeira maturidade de um engenheiro de DevOps não está em criar um pipeline que nunca falha — porque ele vai falhar —, mas sim em desenhar uma arquitetura que permita recalcular a rota sem pânico quando o imprevisto acontecer.

Seja subindo uma serra debaixo de sol quente ou migrando um banco de dados legado na madrugada: tenha um norte, mas saiba ouvir os sinais da sua infraestrutura.

Dúvidas sobre resiliência ou quer trocar uma ideia sobre rotas de cicloturismo? Me chama no LinkedIn ou deixa um comentário.