DevOps virou uma palavra que todo mundo usa e poucos definem. Na prática, é a aproximação entre desenvolvimento e operações para encurtar o caminho entre “escrevi o código” e “está rodando em produção de forma confiável”. E existe um jeito objetivo de medir se isso funciona.
O que muda na prática
Antes, era comum o time de desenvolvimento “jogar o código por cima do muro” para operações, que descobria os problemas em produção sem contexto. DevOps derruba esse muro: quem escreve o código também carrega parte da responsabilidade por ele funcionar. Duas práticas sustentam isso:
- CI/CD (integração e entrega contínuas): cada mudança passa por build, teste e deploy automatizados, em vez de alguém rodar tudo manualmente. Ferramentas comuns: GitHub Actions, GitLab CI e Jenkins;
- Infraestrutura como código (IaC): servidores, redes e configuração viram arquivos versionados no Git, não cliques num painel, o que ajuda a recriar tudo do zero se algo falhar.
As métricas DORA: são cinco, não quatro
A pesquisa DORA define métricas para medir entrega de software. Muito conteúdo ainda fala em quatro, mas o guia oficial hoje lista cinco, divididas em dois grupos:
Vazão (throughput):
- Tempo de entrega de mudança (change lead time): do commit no controle de versão até o código em produção;
- Frequência de deploy: quantos deploys em um período, ou o tempo entre eles;
- Tempo de recuperação de deploy falho: quanto leva para se recuperar de um deploy que falha e exige intervenção imediata.
Instabilidade:
- Taxa de falha de mudança: a proporção de deploys que exigem intervenção imediata;
- Taxa de retrabalho de deploy: a proporção de deploys não planejados que acontecem por causa de um incidente em produção.
A quinta métrica, de retrabalho, é a novidade em relação à lista clássica. O objetivo de um DevOps bem feito é melhorar vazão e estabilidade ao mesmo tempo.
Por onde começar sem virar um projeto de seis meses
- CI básico: todo push roda os testes automaticamente. O GitHub Actions cobre isso, com limites que variam por plano;
- Deploy automatizado do que hoje é manual, mesmo que seja um script simples;
- Monitoramento básico, como um alerta de “o servidor respondeu?”, antes de pensar em observabilidade completa;
- Só então IaC completo e ferramentas mais sofisticadas.
Perguntas comuns
DevOps é cargo ou cultura? As duas coisas coexistem. “Engenheiro DevOps” virou um cargo comum, mas o conceito original é de responsabilidade compartilhada entre os times.
Preciso de Kubernetes? Não. Ele resolve a orquestração de contêineres em escala, e dá para praticar CI/CD, IaC e deploy frequente sem ele.
Como saber se meu time vai bem? Meça as métricas por um ou dois meses antes de mudar qualquer processo. Sem uma linha de base, não dá para saber se a mudança ajudou.
DevOps não é comprar ferramenta nem seguir um checklist de moda. É medir a distância entre escrever código e ele funcionar, e reduzi-la aos poucos.
