Nos últimos anos, o termo DevOps apareceu em centenas de artigos, apresentações, keynotes e discussões em geral. O DevOps alega criar um ciclo de feedback rápido e reduzir o custo de criação de novas versões de produtos, ao mesmo tempo que melhora a estabilidade geral dos sistemas. Dadas essas alegações talvez exageradas, era fácil ignorar ou desmentir o movimento, considerando imaturidade ou falta de evidências. Mas as empresas continuaram a mostrar ganhos reais, e surgiram vários processos para adoção de DevOps nas organizações. Por isso, o momento nunca foi melhor para investigar e trazer o movimento para o seu ambiente de trabalho.
Para quem não conhece, é facil imaginar o DevOps como uma mudança única, de uma vez só, como um apagar ou acender de luzes. Olhando dessa maneira, adotar tal mudança pode parecer uma tarefa desanimadora. E como na engenharia civil, tentar construir algo complexo com uma única mudança normalmente resulta em falhas. Felizmente, o DevOps não é instantâneo, e pode ser quebrado em uma série de pequenas mudanças. A implantação e a escolha dos melhores momentos para aplicá-las podem ser controladas e ajustadas com base no que é mais adequado para sua organização.
Convenientemente, as mudanças necessárias para que o DevOps aconteça podem ser ilustradas em um gráfico no estilo linha do tempo, onde a extrema esquerda representa as culturas e práticas tradicionais da equipe de operações, e a extrema direita representa o novo estilo DevOps. Nessa visão de mundo, a questão não é se "Sua empresa está praticando DevOps?", e sim "Qual a profundidade da adoção da cultura DevOps na sua empresa?".
A amplitude do DevOps
Considerando a gama de adoção do DevOps, é importante estabelecer claramente o que de fato representam os extremos esquerdo e direito dessa gama, para que possamos entender melhor o que significa passar de um ponto a outro.
O lado esquerdo representa a cultura e as práticas tradicionais da equipe de operações. Uma descrição comum desse extremo pode ser "operações caixa preta". Nessa cultura, a equipe de operações é isolada da de desenvolvimento, e as interação entre as duas é evitada ou forçada. A característica marcante desse extremo é que o desenvolvimento e as operações têm objetivos marcadamente contrários. A equipe de desenvolvimento é comprometida e recompensada com entregas de novas funcionalidades e em levar o produto adiante. O objetivo da equipe de operações é manter a estabilidade acima de tudo. Sem a comunicação correta, os objetivos entram em conflito, pois o interesse da equipe de operações é não entregar novas funcionalidades, e o maior interesse do desenvolvimento é entregar novas funcionalidade o mais rápido possível. Como a introdução de qualquer tipo de mudança em um sistema estável pode potencialmente introduzir instabilidades inesperadas, o grupo de operações evita essa ação o máximo possível.
Um exemplo concreto é o de um desenvolvedor de aplicações que introduz um defeito no código, causando um loop infinito em um caso de exceção não detectado nem pelo QA, nem pelos testes. Se essa modificação fosse aplicada pela equipe de operações, um servidor poderia aumentar a CPU para 100%, causando instabilidades. Se a equipe de operações evitasse aplicar tal alteração, não haveria um problema, ou ao menos não haveria um novo problema. Esse é o ponto de vista desse extremo. O lado direito representa a completa aceitação da cultura DevOps, em que desenvolvimento e operações são uma coisa só. A equipe de desenvolvimento faz atividades de operações, e a equipe de operações faz atividades de desenvolvimento - e ambas as equipes têm o objetivo comum de entregar juntas novas funcionalidades, enquanto mantêm certo nível de confiabilidade.
Conhecer os dois extremos - que de fato são extremos - faz parecer assustador sair de um lado para o outro. E é mesmo assustador, se a mudança for vista como um único grande passo. Ao quebrar o processo em uma série de partes gerenciáveis, a tarefa torna-se muito mais factível, os benefícios mais nítidos e os resultados finalmente parecem atingíveis.
Mudanças culturais e técnicas para o DevOps
A implantação do DevOps em uma organização requer tanto uma mudança cultural quanto mudanças técnicas. O ajuste é cultural por um lado, pois barreiras precisam ser quebradas para que as equipes de operações e de desenvolvimento possam se comunicar mais abertamente e compartilhar objetivos em comum. Por outro, é uma mudança técnica, pois os desenvolvedores precisam entender melhor como a equipe de operações trabalha, assim como necessitam obter um bom conhecimento da arquitetura do sistema. A equipe de operações precisa conhecer como o processo de desenvolvimento funciona e ter um melhor entendimento do código.
É mais fácil introduzir o DevOps quando essa introdução é dividida em partes menores, alternando-se entre mudanças culturais e mudanças técnicas. As próximas seções seguirão esse modelo, pois se as mudanças comuns já são difíceis de se conseguir, as radicais então são praticamente impossíveis. E ao alternar o que se está mudando, cada mudança é introduzida de forma mais sutil.
Ao invés de uma grande mudança, ocorrerá uma pequena mudança cultural, seguida por uma pequena mudança técnica, seguida por outra mudança cultural e assim sucessivamente. Dessa maneira, as equipes nunca irão acordar sentindo que tudo mudou repentinamente. Ao invés disso, sentirão que as mudanças ocorreram mais organicamente e em ritmo natural, o que aumenta a probabilidade de que tais mudanças perdurem na empresa.
Métricas por todos os lados
A primeira parte ao se mover da esquerda para a direita na gama de adoção do DevOps é permitir a agregação de métricas por toda a organização, tanto na infraestrutura quanto no nível das aplicações. Existem muitas palestras excelentes sobre o assunto, mas no final o objetivo sempre é responder a uma questão crucial: o que meu código faz?
A equipe de desenvolvimento responderá rapidamente a essa questão, mostrando o código que, infelizmente, só mostra o que deveria fazer, não o que efetivamente faz. Código é como uma receita culinária que descreve os passos para chegar a um resultado saboroso, mas não tem muito efeito no resultado final. Da mesma forma, o código pode descrever um processo para atingir algum efeito desejável, mas tal efeito no sistema real é imprevisível se olharmos apenas o código. Veja abaixo um exemplo de código no qual o desenvolvedor trocou o tempo de expiração do cache de 3600 para 1800 segundos. Olhando apenas para o código, pode-se ver essa mudança, mas é difícil prever o impacto no sistema como um todo.
A equipe de operações responderá a essa questão acessando o servidor e levantando alguns dados do sistema, como por exemplo o consumo de memória e de CPU. Essa é uma resposta boa, pois mostra o efeito do código no mundo real. A equipe de operações tem acesso a muito mais dados, permitindo respostas para questões importantes como "Qual é o efeito desta mudança no sistema como um todo", ou "Por que o serviço Y ficou mais lento depois que o serviço X entrou em produção?". Antes, os desenvolvedores podiam apenas responder a esta questão especulando a partir de como o código iria operar, o que podia funcionar algumas vezes; mas ter acesso aos dados reais é sem dúvida muito mais poderoso. A imagem abaixo ilustra o que a equipe de operações pode ver: dados do sistema em produção.
É importante lembrar em que ponto estamos na faixa de adoção de DevOps: Estamos começando a deixar a extrema esquerda, ou seja, ainda estamos em um ambiente tradicional de operações. Por isso, dar acesso aos desenvolvedores para o ambiente de produção não parece ser uma boa solução. Muitos desenvolvedores não se sentem confortáveis nesse ambiente, e quando as pessoas não se sentem confortáveis é natural que voltem ao que consideram um ambiente confortável. Tentar qualquer tipo de mudança em uma organização sem manter um certo nível de conforto no processo significará uma mudança com pouco embasamento, a qual provavelmente acabará culminando na volta dos velhos hábitos.
Disponibilizar esses dados de maneira amigável para o desenvolvedor é muito simples: gráficos. Tecnologias para geração de gráficos estão por aí há muito tempo, mas têm ficado particularmente populares nos últimos anos com o surgimento de ferramentas como Graphite e Statsd. Ao se capturar métricas do sistema para dentro do Graphite e expor a API para os desenvolvedores, consegue-se levar ao melhor dos dois mundos: a equipe de operações pode expor as métricas do sistema e os desenvolvedores podem expor as métricas da aplicação. Assim, os desenvolvedores têm acesso à memória, ao uso de CPU etc. além de estatísticas sobre eventos da aplicação, como registros de entrada (login), de saída (logout) e assim por diante.
Para um desenvolvedor, implementar uma métrica pode representar apenas uma linha de código:
Isso resulta em um gráfico no Graphite parecido com o seguinte:
Configurar um sistema de gráficos é um trabalho normal para um time tradicional de operações, e a interface com Statsd e Graphite é tão simples que desenvolvedores podem começar a plotar gráficos com apenas algumas linhas de código. Com apenas essas pequenas mudanças técnicas, desenvolvedores podem passar a conhecer melhor o desempenho, os efeitos do código no sistema como um todo, e operações em geral. Pode-se dizer, agora, que sua organização está fazendo alguma coisa de DevOps, porque as equipes de desenvolvimento e operações estão agora interagindo ao menos de forma mínima. As interações irão aumentar, mas esta é uma posição inicial confortável.
Documentação da infraestrutura
Com a possibilidade de se ter uma visão do desempenho e da saúde do sistema em produção, é natural que os desenvolvedores tornem-se curiosos sobre o que está contido no sistema. Para muitos desenvolvedores, um sistema de larga escala em produção é uma caixa preta: uma requisição entra e uma resposta sai, mas os vários sistemas utilizados no caminho são desconhecidos.
Como solução, a infraestrutura deveria ser documentada. Isto pode começar com um diagrama em alto nível do fluxo de uma requisição, indicando qual software é acessado em qual ponto. Quando isso estiver maduro, a documentação deveria mostrar o que cada parte da arquitetura faz e porque foi escolhida ao invés das soluções dos competidores. Adicionalmente, a documentação deve mostrar pontos sobre como novos servidores são disponibilizados, potenciais cenários de falhas e resoluções, introdução a ferramentas Unix, e daí por diante. O objetivo dessa documentação é permitir que os desenvolvedores tenham uma fonte de informação para ficarem mais confortáveis com a arquitetura, em alto nível, do sistema em produção.
Uma vez que esses recursos estejam disponíveis, os desenvolvedores poderão aprender mais sobre a arquitetura do sistema se estiverem interessados. E o interesse na infraestrutura virá do sistema gráfico implementado anteriormente, já que ele oferece aos desenvolvedores uma maneira fácil de olhar para o sistema em produção. Com métricas e documentação, a caixa preta por trás de operações está começando a desaparecer. Ainda não existem muita colaboração entre os dois times, mas as barreiras para que isso se torne realidade começam a rapidamente desaparecer.
Ambientes de desenvolvimentos e produção espelhados
Até este ponto, os desenvolvedores interagiram com a equipe de operações, principalmente por meio da instrumentação do sistema e da documentação escrita. Estando equipados com esse conhecimento básico, seria ótimo se pudessem realmente experimentar e interagir com os sistemas internos de operações. Fazer isso com o ambiente em produção neste momento não é apenas irreal, mas implica em uma ameaça à estabilidade dos seus sistemas. É preferível dar aos desenvolvedores uma área segura para que possam experimentar.
Feito especificamente com esse propósito, o Vagrant é uma ferramenta para empacotar e distribuir ambientes de desenvolvimento na forma de máquinas virtuais VirtualBox. Essas máquinas virtuais são construídas utilizando gerenciadores de configuração padrão como o Chef, o Puppet, ou mesmo shell scripts básicos. Graças a isso, o grupo de operações pode usar os mesmos scripts de configuração de produção para preparar ambientes de desenvolvimento portáveis. Para os desenvolvedores, é esperado que o trabalho seja feito nesses ambientes, porque são os mais próximos possíveis aos de produção. Além disso, os desenvolvedores não precisam mais se preocupar com configuração manual do seus computadores, porque a equipe de operações pode cuidar disso usando máquinas Vagrant corretamente configuradas.
Esses ambientes de desenvolvimento, criados com base em scripts de produção da equipe de operações, dá aos desenvolvedores uma área para experimentar com sistemas reais. Se algum dano for feito, a máquina virtual pode ser destruída e recriada. Além de simplesmente oferecer uma área para experimentos, a configuração real da máquina virtual dá aos desenvolvedores uma visão de como os servidores são provisionados, como as mudanças de operações são aplicada nas máquinas, e uma visão do mundo real da arquitetura dos sistemas.
DevOps no horário comercial
Os desenvolvedores agora têm uma área para experimentar com o sistema real, além de documentação para aprender mais sobre o sistema, assim como métricas como uma forma de obter dados de produção. Mesmo com todo esse aparato, o trabalho de operações ainda é uma novidade e portanto intimida. É hora de iniciar interações reais entre as duas equipes. Essa interação pode vir de fóruns, help desks, ou mesmo caminhando até a outra pessoa para uma conversa cara a cara.
A melhor forma que encontrei até o momento para introduzir essa nova prática é a de "horário comercial". O horário comercial tem uma quantidade fixa de tempo agendada de forma regular, em que as operações e os desenvolvedores ficam dedicados para responder a qualquer tipo de dúvida. Estas dúvidas podem variar das mais básicas, por exemplo, "Como posso buscar arquivos na máquina?" até algumas relativamente avançadas como "Você pode explicar a razão por trás deste parâmetro de configuração HAProxy?". O princípio mais importante dessas "horas comerciais" é que nenhum julgamento pode ser feito, não importa a questão. Essas horas são um tempo para que engenheiros possam se sentir seguros fazendo qualquer pergunta relevante, conseguindo dessa forma atingir um importante marco: a comunicação! Ambos, desenvolvedores e operações ganham entendimento do que cada equipe faz; ambos veem e interagem com o trabalho do outro, e ambos estão conversando.
Mitigando os riscos de desenvolvedores fazendo operações
Antes de continuar, gostaria de ressaltar que nesse ponto sua organização já atingiu uma cultura de DevOps mais saudável que a maioria das organizações. Essa cultura foi introduzida de maneira lenta, metódica e com baixo risco. Continuando, começamos a chegar ao extremo direito de nossa linha do tempo de DevOps, uma área ainda radical se comparada aos passos anteriores e não tão bem definida. No entanto, algumas organizações têm conseguido chegar nesse ponto com sucesso, obtendo os benefícios dessas mudanças.
Os desenvolvedores possuem agora todas as ferramentas para começarem a executar mudanças reais de operações e tomar responsabilidade por isso. Como nos passos anteriores, isso pode ser introduzido em pequenos pedaços, para reduzir riscos e deixar todos mais confortáveis.
O primeiro passo é adotar um modelo padrão do mundo open source para mudanças em operações: pull requests e revisões de código. Quando os desenvolvedores desejam introduzir algo novo, podem realizar as alterações e abrir um pull request. No cenário de DevOps, os desenvolvedores podem testar a mudança numa máquina Vagrant gerenciada configurada anteriormente. O pull request daria à equipe de operações a chance de revisar e checar a mudança. Caso haja algo errado, comentários podem ser feitos para que o desenvolvedor evite cometer os erros novamente no futuro. No final, o pull request é aceito, com o desenvolvedor se sentindo confiante de ter feito a mudança, enquanto a equipe de operações sente segurança ao saber que a modificação foi aprovada por eles.
O segundo passo, e bastante experimental ainda, é utilizar algum nível de integração contínua com as operações. Em um nível básico, isso seria um servidor de integração contínua como o Jenkins, verificando se os scripts de operações rodam sem erros em cada commit, dentro de um ambiente próprio, possivelmente gerenciado via Vagrant. Smoke Tests básicos também podem ser realizados, como uma verificação de que um request HTTP pode ser feito para a infraestrutura resultante.
Com uma ou ambas soluções aplicadas, os desenvolvedores podem fazer alterações de operações com segurança, ao mesmo tempo que a equipe de operações sente-se segura, porque a validação das mudanças ainda é responsabilidade deles. Trata-se da primeira vez que o desenvolvimento e as operação estão realmente trabalhando juntos e compartilhando algum nível de responsabilidade. Ainda há equipes de desenvolvimento e de operações distintos, mas essa distinção está em processo de desaparecimento acelerado.
Desenvolvedores: Divirtam-se!
Agora, no lado extremo direito da linha do tempo de DevOps: os desenvolvedores fazem toda as atividades de operações. Tendo implementado todos os pedaços anteriores, as mudanças culturais e técnicas aplicadas tornam isso uma possibilidade real. Na prática, isso geralmente funciona mantendo duas equipes separadas que trabalham muito mais próximas. A equipe de operações pode ser menor e mais desenvolvedores podem ser contratados, pois podem realizar atividades de operações com a supervisão de poucas pessoas da equipe de Ops. Os desenvolvedores podem e devem ser acionados em casos de problemas, com a equipe de operações sendo a segunda linha de defesa.
Repetindo, isso só funciona por causa da fundação que construímos passo a passo. As métricas oferecem uma visão ampla dos efeitos do código do desenvolvedor sobre o sistema como um todo. A documentação permite ao desenvolvedor aprender mais sobre a arquitetura em produção, para ajudar a entender melhor os efeitos de diferentes modificações. As máquinas virtuais, juntamente com um fluxo criado sobre scripts de configuração automáticos economizam tempo para a equipe de operações, pois permitem que haja uso de ferramentas de produção para criar ambientes de desenvolvimento; enquanto isso, oferecem aos desenvolvedores uma área para realmente experimentarem com a arquitetura do sistema.
As "horas comerciais", ou fóruns, são um ambiente para qualquer tipo de questões que os desenvolvedores ou a equipe de operações possam ter sobre suas respectivas atividades, e provêm um ambiente seguro para aprendizagem. Os testes automatizados de infraestrutura e a revisão de código dão a ambos, desenvolvedores e operações, uma cobertura para que o risco de mudanças operacionais seja mitigado. O resultado final é que ambas as equipes comunicam-se muito mais livremente, confiando mais no outro, e no final as diferenças entre as equipes tornam-se muito menos claras.
DevOps
Os benefícios de DevOps são muitos. Em primeiro lugar, existe mais colaboração e confiança dentro da empresa. A taxa de funcionalidades entregues é aumenta porque existem mais pessoas para fazer as operações e a equipe de operações não precisa apenas dizer "não", pois os desenvolvedores também são responsáveis por qualquer alteração. O DevOps também melhora a estabilidade geral do sistema, porque existem mais olhos capacitados observando os efeitos das várias mudanças.
Como as funcionalidades podem ser (e são) mais rapidamente entregues, ocorrem menos entregas grandes que requerem indisponibilidade do sistema. Ao invés disso, mudanças são implantadas em pedaços pequenos e mais gerenciáveis, que não requerem indisponibilidade alguma.
Onde está sua organização na linha de adoção do DevOps? Onde deseja estar? Contanto que não se esteja na extrema esquerda, sua organização já está praticando DevOps. Essa estruturação dos passos lhe dá o caminho necessário para seguir com confiança e com baixo risco. E caso sinta que as mudanças não estejam funcionando corretamente, elas serão pequenas o suficiente para serem revertidas e experimentadas novamente no futuro.