Fechar

DevOps: rompendo a barreira entre desenvolvimento e operações

O que é DevOps?

O DevOps nos deu uma vantagem

"O DevOps ajudou-nos a realizar liberações muito frequentes, dando-nos uma vantagem em termos de tempo para lançamento no mercado. Agora conseguimos fazer liberações de produto diárias, em vez de a cada seis meses, e enviar correções aos clientes em um período de poucas horas."

— Hamesh Chawla, VP de engenharia na Zephyr

O DevOps é um conjunto de práticas que automatizam os processos entre equipes de desenvolvimento de software e de TI para que possam criar, testar e liberar softwares de maneira mais rápida e confiável. O conceito de DevOps baseia-se em criar uma cultura de colaboração entre equipes que historicamente operam em silos relativos. Os benefícios prometidos incluem maior confiança, liberações de software mais rápidas, habilidade de resolver problemas críticos rapidamente e melhor gerenciamento do trabalho não planejado.

Na Atlassian, DevOps é a segunda portmanteau (combinação de duas palavras) mais famosa, logo depois de Brangelina (Brad Pitt e Angelina Jolie), unindo o melhor do desenvolvimento de software e de operações de TI. E, assim como as nossas piadas, requer alguma explicação. 

Em essência, DevOps é uma cultura, um movimento, uma filosofia.

É um aperto de mão firme entre desenvolvimento e operações que enfatiza uma mudança de mentalidade, melhor colaboração e integração mais forte. Ele une agile, entrega contínua, automação e muito mais para ajudar as equipes de desenvolvimento e operações a serem mais eficientes, inovarem mais rapidamente e gerarem mais valor aos negócios e aos clientes.

História do DevOps

O movimento de DevOps começou a tomar forma em algum momento entre 2007 e 2008, quando as operações de TI e as comunidades de desenvolvimento de software passaram a expressar o que acreditavam ser um nível fatal de disfuncionalidade no setor.

Elas foram contra o modelo tradicional de desenvolvimento de software, que exigia daqueles que escreviam o código estarem separados em termos organizacionais e funcionais daqueles que implantavam e davam suporte ao código.

Desenvolvedores e profissionais de TI/Ops tinham objetivos separados (e às vezes concorrentes), liderança de departamento separada, indicadores-chave de desempenho separados pelos quais eram avaliados e muitas vezes trabalhavam em andares ou mesmo prédios separados. O resultado consistia em equipes em silos preocupadas apenas com o próprio escopo, longas horas, versões problemáticas e clientes insatisfeitos.

Com certeza existe uma maneira melhor, elas disseram. Assim, as duas comunidades uniram-se e começaram a conversar – com pessoas como Patrick Dubois, Gene Kim e John Willis conduzindo a conversa.

O que começou em fóruns on-line e reuniões locais agora é um importante tema no zeitgeist do software, e provavelmente é o que o trouxe aqui! Você e sua equipe estão sentindo a dor causada por equipes em silos e linhas de comunicação divididas dentro da sua empresa.

Você está usando metodologias agile para planejamento e desenvolvimento, mas ainda tem dificuldade em liberar aquele código para o mundo sem um belo drama. Você ouviu algumas coisas sobre DevOps e o efeito aparentemente mágico que ele tem sobre as equipes, então pensou: "eu quero um pouco dessa mágica".

As más notícias são que DevOps não é mágica e as transformações não acontecem da noite para o dia. A boa notícia é que você não precisa esperar a alta gerência para implantar uma iniciativa em grande escala. Ao entender o valor de DevOps e fazer pequenas mudanças incrementais, sua equipe pode embarcar na jornada de DevOps agora mesmo. Vamos analisar cada um desses benefícios em detalhes.

A infraestrutura como código permitiu-nos realizar 10x mais compilações sem incluir uma única pessoa na nossa equipe. — Michael Knight, engenheiro de compilação da Atlassian

Qual é a vantagem para você?

Colaboração e confiança

A cultura é o fator de sucesso nº 1 em DevOps. Criar uma cultura de responsabilidade compartilhada, transparência e feedback mais rápido é a base de toda equipe de DevOps de alto desempenho.

Equipes que trabalham em silos muitas vezes não aderem ao "pensamento de sistemas" do DevOps. O "pensamento de sistemas" é estar ciente de como suas ações não apenas afetam a sua equipe, mas todas as outras equipes envolvidas no processo de liberação. A falta de visibilidade e de metas compartilhadas gera a falta de planejamento de dependência, prioridades desalinhadas, busca de culpados e a mentalidade "não é problema nosso", resultando em menor velocidade e qualidade abaixo do padrão. DevOps é essa mudança de mentalidade ao analisar o processo de desenvolvimento de maneira holística e derrubar a barreira entre Desenvolvedores e Operações.

Libere versões mais rapidamente e trabalhe de modo mais inteligente

Velocidade é tudo. Equipes que praticam DevOps liberam versões com mais frequência, com qualidade e estabilidade maiores.

A falta de ciclos automatizados de teste e revisão bloqueia a liberação para produção, e o tempo de resposta a incidente insatisfatório mina a velocidade e a confiança da equipe. Ferramentas e processos distintos aumentam o OPEX, levam à mudança de contexto e desaceleram o momentum. Por meio de automação e ferramentas e processos padronizados, as equipes podem aumentar a produtividade e fazer liberações mais frequentes com menos contratempos.

Acelere o tempo para a resolução

A equipe com o ciclo de feedback mais rápido é a que prospera. Transparência total e comunicação contínua possibilitam às equipes de DevOps minimizar o tempo de inatividade e resolver problemas mais rapidamente.

Se problemas críticos não forem resolvidos rapidamente, a satisfação do cliente afundará. Problemas importantes infiltram-se pelas frestas na ausência de comunicação aberta, resultando em maior tensão e frustração entre as equipes. Comunicação aberta ajuda as equipes de Desenvolvedores e Operações a atacar problemas, corrigir incidentes e desbloquear o pipeline de liberação mais rapidamente.

Gerencie melhor o trabalho não planejado

Trabalho não planejado é uma realidade que todas as equipes enfrentam –uma realidade que costuma afetar a produtividade da equipe. Com processos estabelecidos e priorização clara, as equipes de Desenvolvedores e Operações podem gerenciar melhor o trabalho não planejado enquanto continuam a focar no trabalho planejado.

Fazer a transição e priorizar trabalho não planejado em diferentes equipes e sistemas é ineficiente e distrai do trabalho em questão. Porém, com maior visibilidade e retrospecção proativa, as equipes podem prever e compartilhar melhor o trabalho não planejado.

Cultura

Se pudéssemos resumir a cultura de DevOps em uma palavra, seria "colaboração" – e se pudéssemos usar duas palavras, seriam "colaboração interfuncional". (Ok, são quase três palavras.)

Todas as ferramentas e toda a automação do mundo são inúteis se não forem acompanhadas pela verdadeira disposição dos profissionais de desenvolvimento e TI/Ops em trabalhar juntos. Porque DevOps não resolve problemas de ferramentas. Resolve problemas humanos. Portanto, é improvável que você um dia estique a cabeça para fora do seu cubículo, olhe ao redor e descubra que as equipes na sua empresa adotam a cultura de DevOps. Porém, há medidas simples que você pode adotar para incentivá-la.

Pense em DevOps como agile, mas incluindo as operações. Formar equipes orientadas por projeto ou produto para substituir equipes com base em funções é um passo na direção certa. Inclua desenvolvimento, QA, gerenciamento de produto, design, operações, gerenciamento de projeto e qualquer outro conjunto de habilidades que o projeto exija. Na Atlassian, integramos inclusive marketing em nossas equipes de produto.

Poucas coisas promovem mais a colaboração do que compartilhar uma meta em comum e ter um plano para atingi-la juntos. Em algumas empresas, mudar de repente para equipes com base em projetos é excessivo e precoce. Assim, dê passos menores. As equipes de desenvolvimento podem, e devem, convidar os membros adequados da equipe de operações para participar de sessões de planejamento, reuniões rápidas diárias e demonstrações de sprint. As equipes de operações podem convidar seus principais desenvolvedores. É uma maneira agile e orgânica de acompanhar o andamento dos projetos, das ideias e das dificuldades uns dos outros. O tempo gasto escutando e interpolinizando conhecimento em áreas específicas compensa ao tornar o gerenciamento de versão e a resolução de problemas de emergência muito mais eficiente.

E por falar em emergências, elas são um teste eficiente da cultura de DevOps. Os desenvolvedores, as operações e o suporte ao cliente atacam o problema e resolvem-no em equipe? Todos começam com a pressuposição de que seus colegas de equipe tomaram as melhores decisões possíveis com as informações e os recursos que estavam disponíveis no momento? A análise post-mortem do incidente é focada na correção dos processos, e não em encontrar culpados? Se a resposta for "sim", essa é uma boa indicação de que sua equipe opera centrada na cultura de DevOps.

Observe que as empresas mais bem-sucedidas adotaram a cultura DevOps em todos os departamentos e em todos os níveis do fluxograma. Elas têm canais abertos de comunicação e conversam regularmente. Elas garantem que as metas de todos estejam alinhadas e fazem ajustes conforme o necessário. Elas presumem que manter o cliente satisfeito é tanto responsabilidade do gerenciamento de produto quanto da equipe de desenvolvimento. Elas entendem que DevOps não é trabalho de apenas uma equipe. É o trabalho de todos.

Automation

Investir em automação elimina o trabalho manual repetitivo, produz processos repetíveis e cria sistemas confiáveis.

Compilação, teste, implementação e provisionamento automatizados são o ponto de partida típico para equipes que ainda não têm isso implantado. E, veja só: quer motivo melhor para desenvolvedores, testadores e operadores trabalharem juntos que criar sistemas para o benefício de todos?

Equipes novas em automação geralmente começam com entrega contínua: a prática de executar cada código muda ao longo de uma odisseia de testes automatizados, frequentemente facilitados por infraestrutura baseada em nuvem, então empacotamento de compilações bem-sucedidas e sua promoção para produção usando implementações automatizadas. Como você pode imaginar, entrega contínua não é algo tão rápido e fácil preparar, mas o retorno do investimento faz valer muito a pena.

Por quê? Computadores executam testes de maneira mais rigorosa e fiel que humanos. Esses testes podem detectar erros e falhas de segurança mais cedo, permitindo aos desenvolvedores corrigi-los mais facilmente. E as implantações automatizadas alertam a TI/Ops sobre "desvios" de servidor entre ambientes, o que reduz ou elimina surpresas na hora da liberação.

Outra das principais contribuições de DevOps é a ideia de "configuração como código". Os desenvolvedores esforçam-se para criar aplicativos modulares e que possam ser combinados porque eles são mais confiáveis e sua manutenção é mais fácil. O mesmo pensamento pode ser expandido para a infraestrutura que os hospeda, estejam eles na nuvem ou na rede da própria empresa.

É verdade, os sistemas estão sempre mudando. Porém, podemos criar uma fachada de imutabilidade usando código para provisionar de modo que reprovisionar um servidor comprometido torne-se mais rápido que corrigi-lo, sem falar que é mais confiável. Isso também reduz os riscos. As áreas de desenvolvimento e de operações podem incorporar novas linguagens ou tecnologias por meio do código de provisionamento e compartilhar as atualizações entre si. Problemas de compatibilidade ficam claros imediatamente, em vez de manifestarem-se no meio de uma liberação.

"Configuração como código" e "entrega contínua" não são os únicos tipos de automação no mundo de DevOps, mas merecem ser especialmente mencionados porque ajudam a derrubar a barreira entre desenvolvimento e operações. E, quando o DevOps usa implantações automatizadas para enviar códigos cuidadosamente testados para ambientes provisionados de maneira idêntica, "Funciona no meu computador!" torna-se irrelevante.

Enxuto

Quando escutamos "enxuto" no contexto de software, normalmente pensamos em eliminar atividades de baixo valor e avançar rapidamente – sendo fragmentário, sendo agile. Ainda mais relevante para o DevOps são os conceitos de melhoria contínua e aceitação da falha.

Uma mentalidade de DevOps vê oportunidades de melhoria contínua em toda parte. Algumas são óbvias, como realizar retrospectivas regulares para que os processos da sua equipe possam melhorar. Outras são sutis, como teste A/B de diferentes abordagens de integração para novos usuários do seu produto.

Podemos agradecer o desenvolvimento agile por tornar a melhoria contínua em uma ideia dominante. Os primeiros a adotar a metodologia agile comprovaram que um produto simples nas mãos dos clientes hoje vale mais que um produto perfeito nas mãos dos clientes daqui a seis meses. Se o produto for melhorado continuamente, os clientes se manterão fiéis.

Adivinhe só: falhar é inevitável. Então você pode muito bem preparar sua equipe para absorver isso, recuperar-se e aprender com as falhas (alguns chamam isso de "ser antifrágil"). Na Atlassian, acreditamos que, se você não falha de vez em quando, não está se esforçando o bastante.

Desafiamos nossas equipes com metas ambiciosas, complicadas e ousadas e garantimos que tenham a autonomia e os recursos para atingi-las. Contratamos pessoas inteligentes e ambiciosas e esperamos que elas falhem às vezes.

No contexto de DevOps, falhar não é um crime condenável. As equipes presumem que tudo está fadado a desandar em algum momento, assim, elas criam pensando em detecção rápida e recuperação rápida. (Leia mais sobre o Chaos Monkey da Netflix para um excelente exemplo.) Análises post-mortem focam no ponto em que o processo desandou e como torná-lo mais consistente, não em qual membro da equipe inseriu o código. Por quê? Porque melhoria contínua e falha andam lado a lado.

DevOps evoluiu de modo que o desenvolvimento tenha mais operações – e é assim que o Chef funciona. Não podemos mais simplesmente jogar tudo por cima do muro. Nossos engenheiros são responsáveis por realizar QA, escrever e executar os próprios testes para levar o software aos clientes. — Julian Dunn, gerente de produto da Chef

Medição

É difícil provar que nossos esforços de melhoria contínua estão de fato rendendo qualquer melhoria sem dados. Felizmente, há muitas ferramentas e tecnologias para medir o desempenho, como o tempo que os usuários dedicam ao seu produto, se uma postagem de blog gerou alguma venda ou com que frequência alertas críticos aparecem nos seus logs.

Embora você possa medir praticamente qualquer coisa, isso não significa que precise (ou deva) medir tudo. Pegue uma página do desenvolvimento agile e comece com o básico:

  • Quanto tempo levou para ir do desenvolvimento à implementação? 
  • Com que frequência erros ou falhas recorrentes acontecem?
  • Quanto tempo a recuperação leva depois de uma falha do sistema?
  • Quantas pessoas estão usando seu produto no momento?
  • Quantos usuários você ganhou/perdeu nesta semana?

Com uma base forte estabelecida, é mais fácil capturar métricas mais sofisticadas quanto a uso de recursos, jornadas do cliente e acordos de nível de serviço (SLAs). As informações que você obtém vêm a calhar quando é hora de mapear o roteiro e especificar sua próxima ação importante.

Todos esses dados interessantes ajudarão a sua equipe a tomar decisões, mas são ainda mais eficientes quando compartilhados com outras equipes, especialmente de outros departamentos. Por exemplo, suas equipes de marketing querem belos novos recursos que possam vender. Porém, enquanto isso, você está percebendo uma alta rotatividade de clientes porque o produto está repleto de débitos técnicos. Fornecer ao usuário dados que apoiem seu roteiro (mesmo que tenha poucos recursos e muitas correções) torna mais fácil obter um consenso e adesão das partes interessadas.

O DevOps não é o trabalho de uma pessoa individual. É o trabalho de todos. — Christophe Capel, gerente principal de produto, Jira Service Desk

Compartilhamento

O antigo conflito entre equipes de desenvolvimento e operações deve-se muito a uma falta de base em comum. Acreditamos que compartilhar responsabilidades e sucessos ajudará muito a criar uma ponte entre elas. Os desenvolvedores obterão boa-vontade instantânea ao ajudar a realizar uma das cargas mais pesadas da equipe de operações: o paginador. O DevOps é ambicioso na ideia de que as mesmas pessoas que criam um aplicativo devem estar envolvidas no seu envio e na sua execução.

Isso não significa que você contrata desenvolvedores e simplesmente espera que eles sejam excelentes operadores também. Significa que desenvolvedores e operadores trabalham juntos em cada fase do ciclo de vida do aplicativo.

As equipes que adotam o DevOps costumam ter uma função rotativa em que os desenvolvedores tratam dos problemas capturados pelos usuários finais e, ao mesmo tempo, resolvem problemas de produção. Essa pessoa responde a problemas urgentes relatados pelo cliente, criando correções quando necessário, e trabalha na lista de pendências de defeitos relatados pelo cliente. O "desenvolvedor no suporte" aprende muito sobre como o aplicativo é usado no mundo real. Ao estarem altamente disponíveis à equipe de operações, as equipes de desenvolvimento estabelecem confiança e respeito mútuo.

Enfrentar as difíceis correções juntos torna a comemoração dos sucessos muito mais saborosa. Você saberá que a cultura de DevOps tomou conta da sua empresa quando observar a equipe de desenvolvimento levando bolinhos para a equipe de operações no dia do lançamento.

Feedback positivo de colegas motiva-nos tanto quanto nosso salário e ambições de carreira. Reconhecer publicamente um colega de equipe que tenha detectado um erro horrível antes de ele ser ativado significa muito. Se o seu departamento tiver um orçamento opcional para parabenizações a funcionários, não deixe de usá-lo!

Pronto para começar sua jornada de DevOps?

Comece a sua jornada