O que é DevOps além das ferramentas

Numa reunião de kickoff de infraestrutura, o engenheiro de plataforma disse que o time precisava "adotar DevOps". Três semanas depois, tinham Jenkins configurado, um pipeline no GitLab e um dashboard de métricas que ninguém abria. Continuavam com os mesmos problemas de antes: deploy sexta às 17h, bugs que aparecem só em produção, e dev e ops que se falavam só via ticket.

Ferramentas novas. Cultura antiga.

DevOps não é um cargo e não é um pipeline

O erro mais comum que vejo em times é tratar DevOps como uma função ou uma stack. Tem empresa que criou o cargo "Engenheiro DevOps" e jogou pra ele toda a responsabilidade de CI/CD, containers, monitoramento e cloud. O time de desenvolvimento continuou fazendo o que fazia antes. O time de operações também. Só que agora tem um Jenkins no meio.

A premissa original do DevOps — derivada do livro The Phoenix Project e dos trabalhos de Gene Kim, Jez Humble e Patrick Debois lá atrás — é que o gargalo em software não é tecnologia. É a separação organizacional entre quem escreve código e quem coloca em produção.

Quando dev e ops são silos, os incentivos são opostos por definição: dev quer entregar rápido, ops quer estabilidade. O resultado é o ciclo clássico: dev joga código por cima do muro, ops tenta não quebrar produção, todo mundo culpa o outro quando algo falha.

DevOps é a tentativa de resolver isso — não com ferramentas, mas com responsabilidade compartilhada. "You build it, you run it", como Jeff Bezos definiu pra AWS em 2006.

O que muda de verdade quando DevOps funciona

Não é a ausência de downtime. É a velocidade de recuperação.

Times que praticam DevOps de verdade não são infalíveis — eles falham rápido, detectam rápido, e recuperam rápido. O DORA (DevOps Research and Assessment), que mede saúde de times de engenharia em empresas do mundo todo, usa quatro métricas como proxy de maturidade:

• Deployment frequency — com que frequência o time sobe para produção
• Lead time for changes — tempo entre commit e produção
• Change failure rate — percentual de deploys que causam incidente
• Mean time to restore (MTTR) — quanto tempo pra recuperar de um incidente

O que os dados mostram, consistentemente desde 2019, é que times de alto desempenho não trocam velocidade por estabilidade. Eles têm as duas. Lead time de horas (não semanas), múltiplos deploys por dia, MTTR em minutos.

Isso não acontece porque eles têm ferramentas melhores. Acontece porque o ciclo de feedback é curto — entre escrever código e ver o resultado em produção.

Os mitos que persistem

"DevOps significa que dev também opera"

Parcialmente verdade, mas não literalmente. O dev não precisa ser engenheiro de redes ou especialista em kernel. O que muda é que o dev tem visibilidade do que acontece em produção e responsabilidade sobre a operação do serviço que escreveu — observabilidade, alertas, runbook básico. Não é o mesmo que fazer on-call de infraestrutura completo.

"CI/CD é DevOps"

CI/CD é uma prática que viabiliza DevOps. É possível ter um pipeline impecável e ainda ter um processo de aprovação de deploy que leva cinco dias e exige sign-off de três gerentes. Tecnicamente, CI/CD. Culturalmente, o oposto de DevOps.

"Precisa de Kubernetes pra fazer DevOps"

Um time de dois devs num VPS com deploy via git push + script bash pratica DevOps melhor do que um time de vinte com Kubernetes gerenciado por uma equipe separada que faz reunião semanal de change approval. A complexidade da infraestrutura não é um proxy de maturidade.

"DevOps resolve comunicação entre times"

Não diretamente. DevOps resolve o problema específico de dev vs. ops. Se o problema é comunicação entre produto e engenharia, ou entre engenharia e segurança, ou entre times de plataforma e times de produto — isso é um problema de organização e processo que DevOps não toca.

O que bloqueia a transição cultural

Nos times onde vi a mudança funcionar, o ponto de virada foi sempre o mesmo: alguém com autoridade decidiu que o time de desenvolvimento é responsável pelo que está em produção. Não parcialmente — integralmente.

O que bloqueia essa transição, na prática:

Processos de change management herdados de ITIL. Change advisory boards que aprovam deploys manualmente, janelas de manutenção mensais, rollback que exige ticket. Não é burocracia à toa — tem origem legítima em ambientes regulados. Mas aplicado sem discriminação a serviços web modernos, vira um custo de processo que supera o risco que deveria mitigar.

Separação de environments sem automação. Se o processo de promover código de staging para produção é manual e envolve pessoas diferentes com aprovações diferentes, você criou um gargalo humano no critical path. Automation de ambiente é pré-requisito, não feature.

Métricas de time que incentivam o silo. Se o time de ops é avaliado por disponibilidade e o time de dev por velocidade de entrega, o conflito de incentivos está no sistema de avaliação — não nas pessoas. Mudar a cultura sem mudar as métricas é esperança.

Automação como consequência, não objetivo

Um erro que cometi num time anterior foi vender DevOps como "vamos automatizar tudo". É uma venda fácil — tem ROI tangível, tem deliverables claros, todo mundo entende o que é um pipeline rodando verde.

O problema é que automação sem visibilidade é uma caixa preta mais rápida. Você entrega mais rápido pra produção e descobre os problemas mais rápido também — mas se o time não tem cultura de monitoramento, alertas e postmortem, a velocidade maior só acelera o ciclo de incidentes.

A ordem que funciona:

1. Visibilidade primeiro — logs estruturados, métricas de aplicação, alertas que chegam pra quem pode agir
2. Deployment confiável — pipeline que passa nos mesmos testes do ambiente de produção
3. Ciclo de feedback curto — de commit a produção em minutos, não horas
4. Rollback simples — que qualquer dev consegue executar sem cerimônia

Nada aqui exige Kubernetes. Exige decisão.

O papel das automações recorrentes

Uma das primeiras coisas que muda num time que está amadurecendo em DevOps é a forma como lida com tarefas operacionais recorrentes. Backup de banco, rotação de logs, geração de relatórios, limpeza de filas — tudo isso vira cron job documentado, monitorado, com alerta quando falha.

O problema é que cron expression é uma daquelas coisas que todo dev escreve de memória, acha que está certa, e descobre o erro só quando o job não rodou na janela esperada. Um job semanal mal configurado pode saltar execuções por meses antes de alguém perceber. Para validar a expressão antes de commitar, uso o Gerador de Expressão Cron — você vê as próximas execuções com data e hora, o que resolve qualquer dúvida sobre timezone ou campo ambíguo antes de subir.

Perguntas frequentes

DevOps e SRE são a mesma coisa?

Não exatamente. SRE (Site Reliability Engineering) é uma implementação específica de DevOps criada pelo Google — usa engenheiros de software para resolver problemas que seriam resolvidos por operações tradicionais. Um SRE escreve código pra automatizar tarefas de ops. O foco é confiabilidade mensurável via SLOs e error budgets. DevOps é o conceito mais amplo; SRE é uma forma concreta de implementá-lo em escala.

Empresa pequena precisa de DevOps?

Sim, e é mais fácil. Em times pequenos, dev e ops naturalmente sobrepõem — um dev de startup que faz deploy do próprio serviço e vê os logs já está praticando DevOps. O desafio de DevOps é manter essa proximidade quando o time cresce e a tentação de criar silos especializados aumenta.

Como medir se o time está avançando?

Use as quatro métricas DORA como baseline. Lead time e deployment frequency são as mais fáceis de instrumentar — um pipeline com timestamp de commit e timestamp de deploy já dá lead time. Change failure rate exige que incidentes sejam registrados e correlacionados com deploys. MTTR exige que incidentes tenham tempo de detecção e resolução registrados. Se você não tem nenhum desses dados hoje, esse é o primeiro passo: medir antes de otimizar.

DevOps funciona em empresas com compliance pesado (LGPD, PCI, SOC 2)?

Sim, mas exige trabalho extra de design. Compliance não é incompatível com delivery rápido — é incompatível com approval manual como mecanismo de controle. A solução é compliance as code: policies de segurança verificadas automaticamente no pipeline, separação de duties implementada via controle de acesso, auditoria via logs imutáveis. Mais trabalho inicial, mas o resultado é compliance mais robusto que depende menos de processo manual.

"You build it, you run it" é a frase que importa

DevOps não vai se resolver com mais ferramentas. O próximo observability platform, o próximo orquestrador de containers, o próximo SaaS de CI/CD — todos são multiplicadores. Multiplicam o que já existe. Se o que existe é um time com incentivos opostos e ciclo de feedback longo, as ferramentas multiplicam o problema.

A mudança que importa é de responsabilidade. O time que escreveu o código é o time que recebe o alerta quando cai. Isso muda como o código é escrito, como é testado, como é documentado, quanto cuidado vai pro deploy. Não porque alguém mandou — porque o custo de não fazer fica visível rapidamente.

Ferramentas ajudam quando a responsabilidade já está no lugar certo.