O que é DevOps, e por que não é um cargo

DevOps é uma forma de organizar o trabalho para que software chegue a produção com frequência e com segurança, aproximando quem constrói de quem opera. O nome vem da junção de development e operations, e a prática se sustenta em automatizar e monitorar todas as etapas entre o código escrito e o serviço funcionando.

Antes de entrar no como, vale eliminar três leituras erradas, porque elas são a causa da maioria das adoções frustradas.

Não é um cargo. Contratar uma pessoa DevOps não cria DevOps.

Não é uma ferramenta. Pipeline, contêiner e orquestrador ajudam. Nenhum deles decide como duas áreas trabalham juntas.

E não é um time novo. Esse é o erro mais comum e o mais silencioso: criar uma equipe DevOps entre desenvolvimento e operação recria exatamente o muro que a prática existe para derrubar, agora com nome moderno e mais uma fila de espera.

De onde veio

A origem tem data e palestra.

Em 2009, no evento Velocity, John Allspaw e Paul Hammond apresentaram "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr", contando como a aproximação entre desenvolvimento e operação no Flickr permitiu mais de dez implantações por dia. Na época isso soava impossível para a maior parte do mercado.

Patrick Debois assistiu à palestra e organizou, no mesmo ano, o primeiro DevOpsDays, em Gante, na Bélgica. A abreviação usada para divulgar o evento acabou virando o nome do movimento, e os eventos se espalharam por vários países, inclusive o Brasil.

Repare no que a palestra tratava: não era ferramenta, era cooperação entre duas áreas.

O muro que ele derruba não é técnico

Aqui está o ponto que mais importa para quem lidera, e ele é sobre incentivo, não sobre tecnologia.

Em boa parte das organizações, desenvolvimento, infraestrutura e operação são áreas separadas, com metas diferentes e, muitas vezes, opostas.

Desenvolvimento é medido por entrega. Quanto mais mudança sobe, melhor.

Infraestrutura responde por segurança, integridade, confiabilidade e disponibilidade. Cada mudança é um risco a ser controlado.

Operação vive de plantão. Cada implantação malsucedida cai no colo dela, à noite e no fim de semana.

Nenhuma das três está errada. Elas estão respondendo aos incentivos que receberam. E é por isso que a conversa entre elas degenera no padrão conhecido: cada um empurra o problema para o outro lado.

Na minha visão, é aqui que a maioria das iniciativas de DevOps morre. A organização compra ferramenta e treinamento, mas mantém intactas as metas que colocam as áreas em lados opostos. Ferramenta nenhuma resolve conflito de incentivo.

O que muda o jogo é fazer as áreas responderem pelo mesmo resultado: o serviço funcionando para o cliente. Não a entrega de um lado e a estabilidade do outro, mas as duas coisas juntas, para todos.

Integração, entrega e implantação contínua

Esses três termos são usados como sinônimo e não são. A confusão custa dinheiro, porque leva organizações a começar pela etapa errada.

Integração contínua é integrar código com frequência, com build e teste automatizados a cada mudança. O objetivo é descobrir conflito e defeito em horas, não em semanas. É a base, e sem ela as outras duas não existem.

Entrega contínua acrescenta as etapas que deixam um artefato pronto para ir a produção a qualquer momento. O código está testado, o pacote está montado, o ambiente está preparado. Quem decide publicar é uma pessoa.

Implantação contínua remove essa decisão. O que passa por todas as etapas vai a produção sozinho.

A diferença entre as duas últimas é de negócio, não de engenharia. Existe contexto regulado, com janela de mudança acordada em contrato, em que entrega contínua é o teto razoável. Isso não é imaturidade técnica, é restrição legítima.

O que não dá é pular a primeira. Automatizar deploy sem teste automatizado não acelera entrega, acelera a chegada de defeito em produção.

O que os ambientes têm a ver com isso

Um detalhe operacional que decide o resultado: os ambientes de teste, homologação e produção precisam ser equivalentes.

Ambiente configurado à mão fica igual no primeiro dia e diverge em três meses. A partir daí, "funciona no meu ambiente" deixa de ser piada e passa a ser a explicação real de metade dos incidentes.

A saída é tratar infraestrutura como código: configuração, script e definição de ambiente versionados no mesmo repositório, no mesmo fluxo de revisão do código da aplicação. Isso torna o ambiente auditável, reproduzível e reversível.

E vale a mesma disciplina para o resto: provisionamento automatizado, política de rollback definida antes de precisar dela, e monitoramento que avisa antes do cliente avisar.

Como medir, sem inventar métrica

Esta é a parte que mais evoluiu desde a primeira versão deste texto, e vale substituir a lista de indicadores que eu tinha aqui por algo com base em pesquisa.

O programa de pesquisa DORA, conduzido por Nicole Forsgren, Jez Humble e Gene Kim e publicado no livro Accelerate, identificou quatro métricas que se correlacionam com desempenho organizacional:

• Frequência de implantação. Com que frequência o time coloca mudança em produção.
• Lead time para mudança. Quanto tempo leva do commit até estar em produção.
• Taxa de falha em mudança. Que percentual das implantações causa problema.
• Tempo para restaurar serviço. Quanto demora para voltar ao normal depois de uma falha.

As duas primeiras medem vazão. As duas últimas medem estabilidade.

E aqui está o achado que muda a conversa executiva: times de alto desempenho são bons nas quatro ao mesmo tempo. Velocidade e estabilidade não são uma troca em que se escolhe um lado.

Isso desmonta o argumento mais comum contra acelerar entrega, o de que ir mais rápido quebra mais. Na prática, quem implanta com frequência implanta mudança pequena, e mudança pequena falha menos e é mais fácil de reverter. Quem implanta a cada três meses acumula risco em um único evento.

Um aviso de uso: essas quatro medem o sistema de entrega, não pessoas. Usá-las para comparar indivíduos garante que elas parem de dizer a verdade em duas semanas.

Onde isso encosta no Lean

A linha até o Lean é direta, e reconhecê-la ajuda a entender por que essas práticas funcionam.

Lote pequeno em vez de lote grande é o mesmo princípio de fluxo contínuo. Implantação frequente é reduzir estoque de trabalho pronto e não entregue, que é desperdício. E parar o pipeline quando o teste falha é literalmente Jidoka, o pilar da Toyota de interromper a linha ao detectar defeito em vez de seguir produzindo.

Vale também a ligação com o Kanban: limitar trabalho em progresso reduz o tempo de ciclo, que é o mesmo que o lead time para mudança tenta medir do outro lado do processo.

E com o ágil a relação é de complemento, não de sobreposição. Os métodos ágeis encurtaram o ciclo entre decidir e construir. DevOps encurta o caminho entre construir e estar em produção, e o alvo aqui é frequência: implantar muitas vezes, em lotes pequenos, sem que a implantação seja um evento.

Sem essa segunda parte, o time fecha a Sprint rápido e o incremento fica na fila esperando janela. A velocidade existe até a porta da operação e para ali.

O que realmente precisa mudar

Automação é a parte visível e a mais fácil de comprar. O que sustenta o resultado é menos vistoso.

Ambiente sem caça ao culpado. Se o custo de um incidente é encontrar o responsável, as pessoas escondem risco e evitam mudança. Postmortem que procura causa em vez de culpado é pré-requisito, não gentileza.

Autonomia com responsabilidade. Time de desenvolvimento com autonomia para implantar precisa responder pelo que implantou, incluindo o que acontece de madrugada. Autonomia sem essa responsabilidade produz descuido; responsabilidade sem autonomia produz frustração.

Representação de todas as áreas nas decisões. Discussão técnica sem quem vai operar produz decisão que não sobrevive à produção. Basta um integrante de cada área nas conversas de arquitetura e requisito técnico para que a maioria dos problemas apareça antes.

Uma correção à primeira versão deste texto: eu listava entre os benefícios a "redução de técnicos envolvidos". Hoje eu não colocaria assim. Tratar DevOps como redução de pessoal é a forma mais rápida de inviabilizar a adoção, porque pede colaboração exatamente de quem entende que o resultado dela é a própria dispensa. O ganho é de fluxo: menos trabalho manual repetido, menos espera entre áreas, menos retrabalho. Automação libera tempo de gente qualificada para problema que exige julgamento, e sempre há fila desses.

Na sua organização, quem escreve o código é chamado quando ele quebra às três da manhã? A resposta dessa pergunta explica quase tudo sobre a qualidade que ele terá.