A palestra do Flickr sobre '10+ deploys por dia' encerra a guerra entre desenvolvedores e operações

Em 2009, o Flickr, o site de compartilhamento de fotos dentro do Yahoo, atualizava seu serviço constantemente, e a divisão padrão do setor — desenvolvedores entregam funcionalidades, operações mantêm o site estável — transformava cada mudança em uma briga. A mudança é a causa raiz da maioria das indisponibilidades, então as equipes que 'protegem' o site com mais afinco são as que entregam mais devagar.

Tornar a mudança segura em vez de rara: ferramentas compartilhadas — feature flags, deploys em um passo, métricas compartilhadas, robôs de chat — mais uma cultura sem culpa tornam rotina mais de 10 deploys por dia.

O gerente do lado de operações, John Allspaw, e o gerente do lado de engenharia, Paul Hammond, reconstruíram as entregas em torno da propriedade conjunta: infraestrutura automatizada, um único tronco compartilhado de controle de versão, build e deploy em um passo, feature flags, painéis de métricas compartilhados e robôs de chat no IRC — combinados com uma lista explícita de cultura: respeito, confiança, uma atitude saudável em relação a falhas e evitar a culpa.

A sessão deles na Velocity em junho de 2009 atraiu mais atenção do que qualquer outra palestra da conferência, e o enquadramento de ferramentas mais cultura tornou-se o núcleo do manual do DevOps: meses depois, o movimento se batizou no primeiro devopsdays em Ghent, e 'deploys por dia' virou um benchmark do setor.

Em 2009, o Flickr, o site de fotos dentro do Yahoo, entregava constantemente: em um dia normal, fazia dez ou mais implantações completas do site em produção. Na conferência Velocity da O'Reilly em San Jose naquele junho, os dois gerentes que comandavam os lados de operações e engenharia do Flickr, John Allspaw e Paul Hammond, explicaram como, em uma palestra intitulada '10+ Deploys Per Day: Dev and Ops Cooperation at Flickr'. O relato do Data Center Knowledge sobre a conferência chamou-a de apresentação que gerou mais burburinho do evento.

O argumento deles atacava o organograma padrão do setor. O estereótipo — desenvolvedores adicionam funcionalidades, operações mantêm o site estável e rápido — transforma a mudança em inimiga, já que a mudança causa a maioria das indisponibilidades. Allspaw e Hammond o inverteram: o trabalho de ops é viabilizar o negócio, o negócio exige mudança, então o trabalho real é reduzir o risco da mudança por meio de ferramentas e cultura. O kit de ferramentas: infraestrutura automatizada, um tronco compartilhado de controle de versão, build e deploy em um passo, feature flags que entregam código oculto, métricas compartilhadas e robôs de IRC que permitem a qualquer pessoa acompanhar as releases acontecendo.

A outra metade era cultural: respeito, confiança, uma atitude saudável em relação a falhas e evitar a culpa — incluindo simulações de incêndio para que até engenheiros júniores tenham praticado incidentes em produção antes de um real, porque falhas vão acontecer. Naquele outubro, Patrick Debois organizou o primeiro devopsdays em Ghent, na Bélgica; o movimento que tirou seu nome daquele evento levou o enquadramento da palestra do Flickr — releases pequenas, seguras e frequentes por equipes que compartilham ferramentas e não culpam ninguém — para organizações de engenharia em todo lugar.

Ela nomeou a restrição real: em um negócio web, o trem de releases é o negócio, e uma equipe que consegue implantar com segurança dez vezes por dia simplesmente aprende mais rápido do que uma que entrega mensalmente.

Ferramentas compartilhadas fabricaram destino compartilhado — um tronco, um painel, um botão de deploy — de modo que nenhum dos lados poderia vencer fazendo o outro perder.

Ela redefiniu ops de guardiã da estabilidade para viabilizadora da mudança, permitindo que automação e cultura fossem julgadas por uma única pergunta: com que frequência conseguimos entregar com segurança?

Ela tratou a culpa como um defeito de engenharia, não uma falha de caráter: se as pessoas escondem erros, o risco se acumula silenciosamente; simulações de incêndio e revisões sem culpa mantêm a informação circulando.

A vazão vem de tornar a mudança segura, não rara. Ferramentas compartilhadas criam destino compartilhado; a culpa ensina engenheiros a esconder riscos; ops viabiliza o negócio, não protege o tempo de atividade contra o negócio.

A gravação da sessão ainda está online e ainda é exibida como um artefato fundador do DevOps. Naquele outubro, o primeiro devopsdays de Debois em Ghent deu nome ao movimento, e 'quantos deploys por dia?' tornou-se tanto um benchmark quanto um desafio. Allspaw levou a abordagem para a Etsy, onde seus primos — postmortems sem culpa e implantação contínua — ficaram famosos por mérito próprio. Uma década e meia depois, a frequência de implantações é uma métrica padrão de engenharia, e 'dev versus ops' sobrevive principalmente como o espantalho que esta palestra demoliu.