Entendendo o que é operacional na prática
Operacional não é um conceito de departamento ou hierarquia. É um estado em que algo funciona quando precisa funcionar, sem improvisação de última hora. Quando digo que uma equipe é operacional, quero dizer que ela tem processos previsíveis, documentação que alguém já leu, e alguém disponível para resolver problemas antes que eles virem incêndios. A diferença entre teórico e operacional é onde você perde sono à noite.
Casos em que eu vi o termo ser mal aplicado
Trabalhei em uma empresa onde vendíamos software de gestão logística. O Vendas prometia aos clientes que tudo era "operacional em tempo real". Quando fui chamador para sanar um problema num sábado à noite, descobri que a integrações com API dos correios tinha um fallback manual numa planilha do Google que ninguém atualizava desde março. Isso não era operacional. Era teatro operacional. O cliente via o dashboard verde e eu via o caos nos logs por trás. O problema real é que muitas empresas confundem operacional com disponível. Um sistema que fica no ar mas não processa dados corretamente não é operacional. É apenas online. Para algo ser operacional de verdade, você precisa de observabilidade, procedure de escalonamento conhecido, e SLA que não seja apenas palavras bonitas num site institucional.
Como funciona a operação no dia a dia
No início dos anos 2023, migrei uma stack de dados de um warehouse Snowflake para BigQuery. A equipe de BI queria apenas "conectar e usar". A operação pediu três semanas de validação cruzada porque os contratos deSLA eram contraditórios entre o time de engenharia e o de compliance. O resultado foi que o projeto saiu do prazo em seis meses, mas entrou em produção com monitoramento que funcionou desde o primeiro dia. A lição prática aqui é que operação boa é operação chatinha. Você mede latência p95, não média. Você testa recovery após falha de provider, não apenas o fluxo happy path. Você documenta procedure de rollback antes de fazer deploy, não depois que o cliente liga reclamando. Isso parece lento no início, mas economiza horas de debug às três da manhã.
O que é operacional na minha experiência técnica
O que é operacional? É quando você sabe exatamente quem chamar, onde estão os backups, e quanto tempo leva para restaurar um serviço após uma corrupção de dados. Na minha primeira vez como SRE num fintech, tivemos uma falha de rede que isolou o datacenter secundário por 47 minutos. O sistema não caiu porque tinhamos circuit breakers configurados corretamente, mas demoramos dois dias para mapear todos os pontos de falha após o incidente. Isso me ensinou que operacional é sobre preparação para o pior caso, não expectativa do melhor. Equipes que só testam o fluxo normal geralmente descobrem brechas reais durante incidentes. O tempo que você gasta documentando procedure de emergência é o mesmo tempo que você perderá tentando adivinhar o que fazer durante uma crise. A diferença é que na crise você está sob pressão de cliente reclamando.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Cenários onde a operação simples falha
Uma ferramenta como o Prometheus com Grafana é excelente para monitoramento, mas torna-se insuficiente quando você precisa de alertas contextualizados que leve em conta padrões sazonais. Eu vi um case onde um alerta de CPU alta disparava todo dia às 9h da manhã porque era horário de pico natural de processamento. O time recebeu centenas de falsos positivos e acabou ignorando alertas reais até que um servidor foi pro espaço em produção. A solução foi implementar machine learning básico de detecção de anomalias sobre as métricas de séries temporais. Não era perfeito, mas reduziu os falsos positivos em 80% e capturou eventos que passam despercebidos em thresholds estáticos. O downsite é que isso exige manutenção contínua e expertise que nem toda equipe tem disponível.
Checklist operacional prático
Para validar se algo é realmente operacional, faça estas perguntas antes de que está pronto para produção: 1. RTO e RPO definidos e testados. Recovery Time Objective e Recovery Point Objective não são números bonitos num slide. São tempo máximo aceitável de downtime e perda de dados que você consegue tolerar. Se não tiver testado restore em ambiente isolado pelo menos uma vez por trimestre, você não sabe se consegue atingir esses números quando precisar.
2. Runbook com steps executáveis. Documentação que só arquiteto entende não serve para operação. Cada procedimento deve ter sequência clara de comandos, inputs esperados, e critérios de sucesso que qualquer engenheiro júnior consiga executar sem consultar o autor original. Eu já vi runbook com apenas "verificar logs e reiniciar". Isso é inútil sob pressão. 3. Ownership claro de cada componente. Quando múltiplos times claimam responsabilidade sobre um mesmo serviço, ninguém responde quando algo quebra. Defina um nome único por componente e verifique trimestralmente se esse ownership ainda faz sentido após mudanças organicas.
4. Capacidade de rollback em menos de 15 minutos. Deploy sem procedure conhecida de reversão é aposta, não engenharia. Teste rollback após cada release importante, não apenas em staging. Isso cobre o básico. Operacional de verdade leva tempo para construir e mantém custos ocultos que aparecem apenas durante crises. Vale a pena porque evita noites perdidas debugando problemas que poderiam ter sido prevenidos com disciplina operacional desde o início.
