DevOps: Um movimento cultural e profissional quebrando barreiras

Como tudo começou

O movimento DevOps não começou em um lugar só, existem muitos lugares que dão pistas sobre as origens do termo, mas aparentemente as informações mais concretas sobre as origens deste movimento nos levam ao ano de 2008. Neste ano, começaram a utilizar o termo “infraestrutura ágil” em algumas listas de discussão com foco em desenvolvimento ágil, e na mesma época durante evento “Agile 2008”, surgiram conversas que abordavam o tema metodologia ágil para a administração de infraestrutura, inspirada no modelo ágil de desenvolvimento, no entanto, foi a lista de discussão europeia com nome “agile-sysadmin” que começou a abordar o tema com propriedade, com isso ela ajudou a colocar os primeiros tijolos na ponte que faria a ligação entre developers e sysadmins. Um dos participantes desta lista era Patrick Debois, além de muito ativo ele era e ainda é um grande entusiasta do assunto.

O termo DevOPS só foi criado de fato em 2009 durante a conferência Velocity da O’Reilly, nesta conferência John Allspaw e Paul Hammond apresentaram o trabalho “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”.

A palestra acima deixou Patrick Debois muito animado, foi então que ele teve a ideia de criar um encontro chamado DevOpsDay, este encontro ocorreu em Ghent no final de 2009, foi um encontro de dois dias e aparentemente foi lá que tudo começou. De lá para cá, Patrick Debois, Gildas Le Nadan, Andrew Clay Shafer, Kris Buytaert, JezzHumble, Lindsay Holmwood, John Willis, Chris Read, Julian Simpson, R.I.Piennar  e muitos outros levaram o evento para diversas localidades, dentre elas:

  • New York 2012

  • Rome 2012

  • Mountain View 2012

  • India 2012

  • Tokyo 2012

  • Austin 2012

  • Goteborg 2011

  • Bangalore 2011

  • Melbourne 2011

  • Mountain View 2011

  • Boston 2011

  • Göteborg 2011

  • Sao Paulo 2010

  • Hamburg 2010

  • Mountain View 2010

  • Sydney 2010

É importante falar que ao levar o evento para diversos países, estas pessoas foram responsáveis por disseminar a cultura DevOps pelo globo, com isso, direta ou indiretamente eles se tornaram a força motriz de uma discreta revolução no mundo da TI.

Inicialmente a cultura DevOps se mostrou muito presente no ambiente das startups, porém, algum tempo depois começou a fazer parte do mundo corporativo.

Manifesto DevOps

Apesar de terem organizado o DevOpsDays em diversos países, não foi estabelecido um manifesto para o assunto, logo existem muitas interpretações acerca deste termo.

Mas antes de argumentar acerca do possível conteúdo de um manifesto DevOps, primeiro tem que entender a dinâmica na relação entre as áreas de infraestrutura (infra) e desenvolvimento (devel).

 31-2

Analisando Infra e Devel

Para entender melhor o que DevOps significa, precisamos então analisar de forma prática e direta a vida de sysadmins, desenvolvedores e o cotidiano destas áreas.

Imagine hipoteticamente uma empresa de comunicação que desenvolve aplicações web em sua maioria para portais de notícias, e em alguns casos também faz aplicações web internas (rh, financeiro, administrativo), nessa empresa o devel trabalha com PHP, PYTHON, RUBY e JAVA.

Para um melhor entendimento, considere as duas características abaixo como cotidianas nesta empresa fictícia:

  1. A Infra continua trabalhando no modelo tradicional de administração (manual, caótico e reativo).

  2. O Devel está começando a trabalhar com metodologias ágeis (pró-ativo, evolutivo e contínuo).

Infra em foco

A infra é composta em parte pelos sysadmins, estes rapazes e moças tem a missão de manter os sistemas funcionando, são eles que fazem os deploys e os rollbacks das aplicações do devel, é responsabilidade deles manter o ambiente de produção intacto.

Os sysadmins tem que rodar as aplicações, monitorar o funcionamento, a performance, avaliar e propor melhorias de forma a manter as aplicações sob seu cuidado rodando de forma rápida e estável, além disto, eles devem planejar as mudanças com cautela, tentando minimizar os riscos envolvidos.

Eles se preocupam com segurança, estabilidade e principalmente com o acordo de nível de serviço (SLA) de cada produto sob sua responsabilidade, esta preocupação é fundamental para o negócio.

Entenda que se uma aplicação parar de funcionar isto vai impactar no SLA, podendo significar perdas financeiras significativas relacionadas ao produto, afinal produto fora significa cliente insatisfeito e prejuízo, seja ele financeiro, seja ele institucional, e no caso da sustentação do produto, isto significa que a prestadora do serviço, neste caso a empregadora dos sysadmins, pode ser multada. De todo o jeito, o que ocorre de forma direta é diminuição do valor do negócio.

Em resumo, a infra (sysadmins) se preocupa em proteger o valor do négocio.

Devel em foco

O devel é composto em parte por desenvolvedores, estas moças e rapazes trabalham com lógica e criatividade, eles passam boa parte de seu tempo codificando soluções, e focam seu trabalho nos requisitos que o analista conseguiu mapear junto ao cliente.

Os desenvolvedores estão constantemente criando e aprimorando suas aplicações, com isto novas versões são criadas e precisam ser disponibilizadas, assim seus clientes poderão usufruir dos recursos solicitados.

Nova versão significa novo deploy, e caso ocorra algum problema, isto irá demandar um rollback, ambos os procedimentos envolvem equipes de infra.

Em resumo, podemos dizer que o devel se preocupa em aumentar o valor do negócio.

Onde está o conflito?

31-3

Os desenvolvedores querem colocar suas aplicações no ar o mais rápido possível, no entanto os sysadmins querem ter certeza que a aplicação está estável o suficiente para entrar em produção sem gerar incidentes.

Nos últimos anos esse conflito foi latente no mundo de TI, algumas empresas tinham regras tão rígidas que só permitiam deploy uma vez por semana, em casos mais rígidos apenas uma vez por mês, tudo isto pensando em proteger o negócio.

Com o devel mudando de metodologia, esse método de deploy uma vez por semana não combina com desenvolvimento ágil, com isso a infra teve que evoluir, e quem antes fazia deploy uma vez por semana, teve que aprender a fazer várias vezes por dia.

É claro que a infra trabalhando com os métodos que estava acostumada (deploy 1 vez por semana e manual) não dava vazão as demandas, e também é óbvio que o devel não possuía uma infra adequada para fazer o desenvolvimento de forma contínua.

Além de tudo isso, normalmente o devel não conhece e não tem como prever aspectos importantes relativos à infra que fica de cara para o cliente, portanto, quando a aplicação vai para produção, normalmente ocorrem constantes pequenos incidentes que geram uma enorme perda de valor no negócio. Traduzindo, são aqueles ajustes na aplicação que precisam ser feitos de última hora, pois o ambiente devel é completamente diferente da produção.

O cliente por sua vez reclama com razão e depois a gerência de TI ficava tentando encontrar o dono do problema (caça as bruxas), de um lado devel dizendo que infra é engessada, lenta e que não oferece um ambiente adequado para desenvolverem suas aplicações, do outro lado a infra dizendo que o devel faz código ruim e instável e que não é culpa deles se a aplicação não funciona.

Incidentes

Quando ocorre algum incidente, você vai ouvir da infra falando para o devel que “o problema não são as máquinas, é o código”, e certamente o devel vai falar para infra que “o problema não é o código, são as máquinas”, e provavelmente ainda vão dizer que o sistema “está funcionando no notebook deles”, e infelizmente isso será algo do cotidiano.

É preciso entender que infra e o devel trabalham em nichos, cada um no seu quadrado, cada um em sua realidade e nenhum deles está muito disposto a mudar sua cultura, nenhum deles está disposto a ceder. A infra não conhece o devel e não sabe como mudar para ajudá-los, o devel não conhece a infra e não sabe como pedir o que precisam.

No final das contas, as pessoas não conseguem estabelecer uma forma sadia e eficiente de comunicação, e com isso, não existe trabalho colaborativo entre estas duas áreas.

Mudanças Necessárias

A infra precisa evoluir, e tem de fazer isto rapidamente, começando a trabalhar de forma automatizada e dinâmica, precisa ser mais veloz para subir novos ambientes ou mesmo reconstruir/duplicar os ambientes existentes para suprir as necessidades do devel, não dá mais para trabalhar de forma manual e usar as mesmas metodologias da época dos mainframes.

O devel precisa ter controle de todas as fases do deploy e conseguir passar para infra suas necessidades de forma clara, e tem que se esforçar para fazer a infra entender isto, e eles não vão entender na primeira vez.

Busca de soluções

E foi a busca de soluções para estas necessidades que motivou importantes discussões no mundo da TI, foi então que começaram a falar de “Infraestrutura ágil” no ano de 2008, vamos agora entender o que é isso.

Infraestrutura ágil

A discussão acerca de infraestrutura ágil ganhou força com o crescimento de duas tendências, virtualização e computação em nuvem. Desde 2003 empresas começaram a conviver com ambientes virtualizados, logo um parque com poucas máquinas físicas poderia se tornar um parque com dezenas de máquinas virtuais, e após o recente advento da nuvem, dezenas de máquinas virtuais podem se tornar centenas ou milhares de instâncias a serem administradas na nuvem.

Não havia mais espaço para se trabalhar infraestrutura da forma tradicional, foi necessário dar um passo a diante e pensar em infraestrutura como código, principalmente quando paramos para analisar o recente boom das startups, empresas pequenas com produtos de enorme alcance, produtos que rodam em centenas de instâncias na nuvem, atendendo milhões de usuários, e tudo isso é administrado por equipes mínimas.

O objetivo é fazer deploy não só de aplicações, mas deploy de infraestrutura de forma rápida e controlada.

Isso significa que se precisa subir um ambiente JBOSS (servidor de aplicações baseado em Java), vai fazer isto em poucos minutos e não em dias.

Ferramentas de infraestrutura ágil

Quando se fala em infraestrutura ágil o que vem a mente são ferramentas, e de fato elas são parte disto.

Basicamente temos três tipos de ferramentas, são elas:

Orquestradores: são ferramentas que permitem executar comandos e controlar nodes/instâncias de nosso parque em tempo real. Alguns destes são Fabric, Capistano, Func e Mcollective.

Ferramentas para gerenciamento de configurações: controlam estados do sistema, ajudam a centralizar todas as configurações e facilitam a administração e criação de novos ambientes. Algumas delas são Puppet, Chef, Cfegine e Salt.

Ferramentas para bootstrapping e provisionamento: são ferramentas que ajudam a instalar um sistema operacional seja em uma máquina física, seja em uma máquina virtual, seja em uma instância na nuvem, dentre elas temos alguns provedores de CLOUD como AWS e Rackspace que já oferecem isso nativamente, existem também ferramentas como o Kickstart e Cobbler que atuam neste segmento.

A combinação destes três tipos de ferramentas nos permite ter o que chamamos de infraestrutura ágil, mas apesar da qualidade e dos ganhos em utilizar tais tecnologias, a ferramenta sozinha não resolverá seus problemas, é preciso mudar a cultura e a forma de trabalhar a infraestrutura.

Equipe de infraestrutura ágil

Equipes que trabalham com infraestrutura ágil também precisam de um método diferenciado de organização, normalmente estas equipes estão trabalhando seguindo estes eixos:

  1. Parece com SCRUM, mas não é, mas é fortemente inspirado nele e no Kanban.

  2. Reuniões ágeis periódicas (retrospectiva e planejamento de sprints).

  3. Reuniões ágeis diárias (standup meeting de 10 minutos – em pé)

  4. Divisão das atividades em sprints

  5. Trabalho em pares

  6. Organização de atividades de forma visual (KANBAN BOARD)

  7. Versionamento do código e arquivos de configuração (git)

Então DevOps e Infraestrutura ágil são a mesma coisa?

Não, infraestrutura ágil é parte da cultura DevOps, mas ainda tem muito mais.

Apesar da evolução da infra, ainda falta algo que conecte as duas áreas, precisamos de um agente de mudanças principalmente no meio corporativo.

Cultura DevOps

Para entender a cultura DevOps sem fazer um texto muito longo, Guto Carvalho Sysadmin Linux por formação (RHCE/LPIC3), entusiasta DevOps, especialista em gerência de configurações e automação (PCP-203), consultor, palestrante e instrutor, pontua as principais características em sua opinião.

Patrick Debois (foi quem cunhou o termo) diz que DevOps essencialmente é uma cultura, e a descreve utilizando 4 eixos, são eles:

  • Cultura

    • Colaboração

    • Fim das divisões

    • Relação saudável entre as áreas

    • Mudança de comportamento

  • Automação

    • Deploy

    • Controle

    • Monitoração

    • Gerência de configuração

    • Orquestração

  • Avaliação

    • Métricas

    • Medições

    • Performance

    • Logs e integração

  • Compartilhamento

    • O feedback é tudo

    • Boa comunicação entre a equipe

Detalhando um pouco mais esses eixos:

Características técnicas

Um ambiente DevOps deve ter/possuir/oferecer/permitir:

  • Backup e restore confiável

  • Capacidade de resposta rápida a incidentes e problemas

  • Monitoramento eficaz com processamento adequado dos eventos e métricas

  • Os desenvolvedores devem conseguir fazer o deploy sem interferência da infra [5]

  • Ambiente de entrega contínua [4]

  • Devel deve participar das reuniões de infra [3]

  • Infra deve participar das reuniões de devel [2]

  • Infra deve participar dos projetos desde o início [1]

  • O ambiente de devel deve possibilitar TDD

  • Ambiente de desenvolvimento, teste e produção (no mínimo)

  • Controle de versões compartilhado entre infra e devel

  • Provisionamento dinâmico de ambientes

  • Gerência de configurações

  • Orquestração de servidores

  • Infraestrutura como código

[1] O devel precisa envolver a infra nos projetos desde o início, isso significa participar das reuniões técnicas ou SCRUM, afinal sem a infra não há projeto, e além disto, quanto mais problemas foram resolvidos durante o projeto com ajuda da infra, menos problemas serão expostos aos clientes.

[2] A infra também precisa observar quais são as metas da empresa á longo prazo, principalmente aquelas ligadas ao devel, pois enxergando aonde o devel quer chegar, ela pode se programar melhor para ter certeza que a infraestrutura tecnológica estará preparada para atendê-los quando esse momento chegar.

[3] A infra precisa envolver o devel em suas reuniões técnicas para que o devel entenda e tenha ciência da realidade da infra, assim eles vão conseguir enxergar suas qualidades, atribuições, planos de melhorias, atualizações programadas, agendas de manutenção, eles vão conhecer os recursos disponíveis e também descobrir a limitações da equipe, sejam elas técnicas, sejam materiais. Além disto, o devel pode ser um grande aliado da infra na solução de problemas, afinal o conhecimento que o devel traz pode ajudá-los a melhorar a forma com que administram seu ambiente, tornando este processo mais eficiente.

[4] O devel precisa adotar alguma metodologia de entrega ou desenvolvimento contínuo e a infra precisa entender esse processo para que juntos criem os ambientes com as ferramentas certas.

[5] A infra precisa ceder um pouco e evoluir, precisa oferecer ao devel um ambiente adequado onde eles sejam o dono do produto, onde o devel consiga fazer todo o ciclo de desenvolvimento de forma direta, o devel precisa conseguir gerar e controlar o código, precisa fazer o commit com segurança, precisa fazer o build, testar o build, validar a aplicação e entregar a nova versão de forma transparente sem que para isso precise passar por um burocrático e engessado processo de mudança.

 

Relação com os valores humanos

Para a adoção da cultura funcionar, a equipe precisa observar e exercitar os seguintes valores:

  • Confiança no trabalho de sua equipe

  • Respeito pessoal e profissional por todos da equipe

  • Sinceridade sobre eventos e incidentes ocorridos

  • Honestidade sobre as causas dos incidentes (não esconda nada da sua equipe)

  • Entendimento de que o problema é responsabilidade de todos

  • Entendimento de a solução é responsabilidade de todos

  • Entendimento de que os resultados são o reflexo do trabalho de toda a equipe

  • Comunicação efetiva e dinâmica

  • Postura construtiva sempre

  • Espírito de colaboração

Relação com a forma de trabalho

É recomendável que a equipe:

  • Internalize e adapte métodos ágeis como KABAN e SCRUM para seu dia-a-dia

  • Aprofunde estudos em entrega contínua

  • Aprofunde estudos em gerência de configurações e orquestração

Aplicando a cultura

Após observar as principais características deste movimento, normalmente pensamos em como aplicar isto em nosso meio. Para ajudar na reflexão vamos avaliar o meio startup e o meio corporativo.

A realidade no ambiente startup

A cultura DevOps combina muito com startups, nestes locais normalmente já se trabalha desenvolvimento utilizando metodologias ágeis, foi inclusive neste nicho em que começaram a discutir infraestrutura ágil, a precursora do movimento DevOps. Portanto, as pessoas deste meio conseguem absorver os conceitos e a cultura DevOps sem grandes dificuldades, eles conseguem compreender os preceitos de colaboração e feedback pois já fazem isto em seu dia-a-dia.

Quem está em uma startup não tem as amarras e vícios da corporação, este é um grande facilitador e não é necessário nenhum tipo de intervenção para internalizar a cultura, a partir do estímulo de um líder as pessoas começarão a estudar e aplicar DevOps naturalmente.

Na startup normalmente não existe divisões, departamentos, todos trabalham juntos e isso também é um facilitador, afinal não existem barreiras para se comunicar.

A realidade no ambiente corporativo

A corporação não funciona como a startup, lá existe burocracia e o uso vicioso de métodos ultrapassados, portanto não bastará o estímulo da alta hierarquia para que equipes de infra e devel comecem a vivenciar a cultura DevOps, neste tipo de ambiente, em minha opinião pessoal e profissional, é necessário intervir cirurgicamente para conseguir internalizar a cultura DevOps.

Em resumo, você precisa trazer alguém de fora que conhece a cultura DevOps para que esta pessoa passe a contaminar os demais.

Esse processo é lento, mas se o especialista tiver os meios e o apoio do alto escalão, mudanças fantásticas poderão ocorrer.

O especialista DevOps no meio corporativo

Ele atua como um agente de mudanças, ele precisa contaminar as áreas e mostrar que a cultura DevOps funciona.

Característica gerais de um especialista DevOps:

  • Está na casa dos 30 anos ou mais

  • É um profissional sênior em infraestrutura

  • Tem um bom background em desenvolvimento

  • Tem um bom background em metodologias ágeis

  • Tem sólidos conhecimentos em soluções opensource e similares

  • Trabalha intensamente com automação e infraestrutura como código

Onde esse especialista irá atuar:

O especialista em DevOps terá um pé na infra e outro no devel, em alguns casos também terá o pé na área de garantia de qualidade (QA).

31-4

Como esse especialista irá atuar:

O especialista será a ponte entre as áreas de infra e devel, ele conhece a infra a fundo e entende de forma ampla processos de desenvolvimento ágil.

No devel:

Ele participa dos projetos de desenvolvimento desde o seu nascimento, seu foco é oferecer os recursos para que os desenvolvedores trabalhem da forma mais eficiente, além disto, com sua ótica de infra ele toma todas as precauções para que os aspectos de segurança, monitoramento, eficiência e escalabilidade sejam observados desde o início do projeto.

O especialista em DevOps vai ainda estudar todo o processo de desenvolvimento e definir em conjunto com o devel as ferramentas que irão permitir um processo de desenvolvimento e entrega contínua. Após definir ele vai instalar e manter esse infra.

Alguns especialista em DevOps conseguem até avaliar o código do produto e enxergar problemas de performance, esse tipo de visão sistêmica e raciocínio rápido são diferencias importantes para uma entrega com mais qualidade.

Na infra:

Na infra ele é o principal agente de mudanças, é ele que vai puxar a fila para iniciar a implantação de uma infraestrutura ágil, ele domina as ferramentas de orquestração, gerência de configuração e provisionamento e vai usar esse conhecimento para que a equipe passe a trabalhar a infraestrutura como código.

Este profissional também vai ajudá-los a mudar seu comportamento e cultura, ele vai orientá-los nos métodos ágeis de execução de atividades, aqueles inspirados no SCRUM e KANBAN.

 

O especialista fica na infra ou no devel?

Para internalizar DevOps, normalmente estas barreiras não existem, infra e devel devem habitar o mesmo espaço, sem paredes, sem divisórias, todos na mesma sala, isso é fundamental para extinguir os nichos e criar uma equipe mais unida e coesa.

Ele deve ficar junto com as duas equipes se for possível, esse é o melhor dos mundos. Se não for possível ficarem todos juntos, o especialista deve se esforçar para interagir com as duas equipes diariamente.

Ele vai ser o agente de mudanças até que infra e devel comecem a entender e adotar a cultura de forma natural.

Ganhos em adotar a cultura DevOps

Na infra os ganhos são:

  • Infraestrutura como código (equipe para de administrar e passa a desenvolver a infra)

  • Infra mais eficiente e rápida usando métodos ágeis

  • Equipe de Infra mais organizada

  • Equipe de Infra se comunicando melhor

  • Infra fazendo mais em menos tempo com menos gente

  • Ambientes de gerência de configuração, orquestração e provisionamento implantados

  • Deploys de infra (novos ambientes) mais rápidos e seguros => entrega rápida

  • Ambiente padronizado e sobcontrole

  • Feedback rápido em todas as atividades de infra

No devel os ganhos são:

  • Devel tem ambiente mais adequado para trabalhar (dev/teste/prod)

  • Devel passa a contar com ambiente de desenvolvimento contínuo

  • Devel passa a contar com testes automatizados

  • Deploys de apps (novas versões) mais rápidos e seguros => entrega rápida

  • Feedback rápido em todas as fases de desenvolvimento

Os ganhos mútuos Infra/Devel são:

  • Acaba a divisão Infra vs Devel (acaba a guerra)

  • Infra participa dos projetos e acompanha de perto tudo o que acontece

  • Infra participando resulta em melhor planejamento do ambiente de produção

  • Infra participando resulta em monitoramento mais eficaz da aplicação

  • Devel começa a compreender melhor a infra e isso resulta em um produto melhor

  • Equipes trabalhando em conjunto para aumentar o valor do negócio

Os ganhos para a empresa são:

  • Melhor comunicação entre devel e infra (diminuição de conflitos)

  • Soluções rodando com maior estabilidade e desempenho

  • Entregas mais rápida

  • Menor tempo de paradas

  • Diminuição de incidentes

  • Diminuição de custos

  • Diminuição de riscos

  • Aumento do valor do negócio

Como ser um especialista em DevOps ?

Não há um tutorial para isto, você tem que estudar desenvolvimento ágil e procure entender o processo de desenvolvimento do local onde você trabalha, estude ferramentas para desenvolvimento contínuo, estude ferramentas de gerência de configuração, orquestração e provisionamento, fazendo isto você poderá dar os primeiros passos como entusiasta da cultura DevOps e estará apto a atuar em seu ambiente, você poderá agir como uma ponte entre as áreas de devel e infra, e principalmente, poderá modernizar os processos e o ambiente de infra.

Trabalho com infra ágil, sou um especialista em DevOps ?

Não existe um manual de conduta para dizer se você é um DevOps ou não, mas é bastante comum encontrar profissionais que estão estudando infraestrutura ágil e se denominando DevOps.

Se você está buscando melhorar seu ambiente, entregar mais rápido, entregar algo com mais qualidade, algo que minimize custos, algo que diminua riscos, algo que envolva automatização pesada, se você trabalha infraestrutura como código, se você está atuando como um agente de mudanças em sua equipe, DevOps é um termo adequado para descrever o seu trabalho, mesmo que não esteja diretamente envolvido com uma equipe de Devel.

Fonte: GutoCarvalho

 

Related Post

0 Comentários

Envie uma Resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

*

CONTACT US

We're not around right now. But you can send us an email and we'll get back to you, asap.

Enviando

© [2017] Blog da Inovação - Tecnologia, Criatividade, Inovação .

Fazer login com suas credenciais

Esqueceu sua senha?