O que DevOps é, afinal

“DevOps” hoje aparece em título de vaga, nome de time e categoria de ferramenta — três usos que o termo original não previa e que atrapalham quem está começando. Vale voltar ao problema que ele descrevia, porque esse problema continua existindo em quase toda empresa.

A origem

Por volta de 2008–2009, duas conversas se encontraram: a de quem via ganho em aplicar práticas ágeis à infraestrutura e a de quem observava que desenvolvimento e operação, com metas opostas, produziam sistemas piores. A partir daí vieram os devopsdays, o livro The Phoenix Project e a pesquisa que virou o relatório DORA — que trocou opinião por dado.

O muro

O arranjo tradicional cria um conflito estrutural: desenvolvimento é cobrado por entregar mudanças, operação é cobrada por evitar instabilidade. Como mudança é a principal causa de instabilidade, os dois lados otimizam contra o outro.

O sintoma clássico é a entrega por cima do muro: o time escreve, empacota e “passa” para quem opera, junto com um documento. Quem recebe não conhece o sistema, não pode alterá-lo, e é acordado quando ele falha. O incentivo que sobra é dificultar a passagem — comitê, janela mensal, formulário.

DevOps é, na essência, uma resposta a isso: quem constrói participa de operar, e as duas atividades compartilham metas, ferramentas e informação.

O que DevOps não é

• Um cargo. “Pessoa DevOps” quase sempre significa pessoa de infraestrutura que também escreve pipeline. É um papel legítimo — mas chamar de DevOps sugere que o resto do time está dispensado da responsabilidade, o que desfaz a ideia.
• Um time separado. Criar um “time de DevOps” entre desenvolvimento e operação frequentemente constrói um terceiro muro. O que funciona é time de produto assumindo o que escreve, apoiado por uma plataforma que torna isso viável.
• Uma ferramenta. Kubernetes, Terraform e GitHub Actions ajudam. Nenhum deles muda o incentivo de quem aprova o deploy.
• Automatizar tudo. Automação é meio. O fim é fluxo de mudança rápido, seguro e com aprendizado.

Os três caminhos

O modelo mais útil para orientar a prática:

1. Fluxo — otimizar a passagem da ideia até a produção. Lotes pequenos, integração frequente, menos filas e handoffs. É onde entram CI/CD, trunk-based e entrega automatizada.
2. Feedback — encurtar e ampliar o retorno em cada etapa: teste rápido, observabilidade, alerta útil, canário. Problema descoberto cedo custa uma fração.
3. Aprendizado contínuo — transformar incidente e experimento em melhoria do sistema. Postmortem sem culpa, tempo reservado para melhoria, segurança psicológica para relatar erro.

Em qualquer diagnóstico, olhe nessa ordem: sem fluxo, feedback chega tarde; sem feedback, não há o que aprender.

Por que tanta adoção falha

• Adotam ferramenta, não incentivo. O pipeline existe, mas o deploy ainda precisa de aprovação de um comitê que se reúne às quintas.
• Renomeiam o time de operação e mantêm a mesma fronteira de responsabilidade.
• Passam a responsabilidade sem passar a capacidade: “agora vocês operam” sem acesso, sem observabilidade, sem plataforma, sem tempo.
• Medem produtividade individual e criam o incentivo para esconder problema.
• Ignoram a operação como trabalho real: sem tempo para reduzir toil, o time vira suporte do que já existe.

O sinal mais confiável de que está funcionando não é o número de ferramentas: é o time conseguir levar uma mudança pequena até produção, com segurança, em um dia — e ninguém achar isso arriscado.

Próximo passo: troque impressão por medida em Métricas DORA.