DevOps e Infraestrutura ágil

Então o que mais acontecia era gerar dor de cabeça para ambas as partes. Os Administradores de Sistemas possuíam o objetivo de manter a estabilidade dos softwares, dos servidores, evitar indisponibilidade dos sistemas e, claro, manter o cliente feliz com aplicativos cada vez melhores. Já os desenvolvedores eram os responsáveis por zelar pela inovação, qualidade e agilidade.

O problema era que isso não entrava em consenso. Pode-se dizer que havia uma verdadeira guerra entre os Desenvolvedores e os Administradores de Sistemas (os operacionais). Mesmo estando ambos com o mesmo objetivo, agradar clientes, eles não se entendiam muito bem. Isso ficou obsoleto e tinha que acabar, pois os processos não andavam no mesmo ritmo, e as entregas, atualizações e implementações (deploys), não ficavam em dia.

Quando os engenheiros do Flickr chegaram com o conceito de DevOps, as pessoas ficaram aliviadas com a expectativa da maior entrega das soluções, ou seja, uma entrega mais rápida e eficiente em produção.

Embora isso tenha mesmo acontecido, seria injusto falar de DevOps sem falar no Agile, que surgiu em 2008. Para quem não sabe, o Agile foi uma ideia de otimização de infraestrutura que inspirou o DevOps. A partir daí, surgiu-se o termo “infraestrutura ágil”. Veremos mais sobre isso daqui pra frente.

O que é DevOps?

Não se sabe ao certo o que é DevOps, só se sabe que ele funciona. A ideia do DevOps é fazer com que todas as equipes (Desenvolvimento e Operação) trabalhem em conjunto, alinhem suas estratégias e mantenham uma harmonia no funcionamento das aplicações, com uma entrega maior, mais ágil e com mais qualidade.

Quando falamos que não sabemos o que é o DevOps, queremos dizer que não sabemos se ele é uma cultura, uma metodologia ou um sistema de comunicação. Enfim, trata-se de algo ainda em discussão. Na opinião deste autor, o DevOps se caracteriza mais próximo de uma filosofia ou uma ideia bem abrangente, pois define um conceito de conduta intersetorial, ou seja, o verdadeiro entendimento de que os setores de desenvolvimento de software, administradores de sistemas (e infraestrutura) devem caminhar de mãos dadas.

Dentro de tal filosofia, o que se prega (e se encoraja) é que o segredo da otimização dos resultados é a cooperação das duas partes em busca da automação das operações, das mudanças e das configurações.

Desenvolvedores x operacionais (antes e depois do DevOps)

Eis o estopim disso tudo. Como já foi dito, o grande problema da arritmia da infraestrutura era justamente a independência, a autonomia e o distanciamento que existia entre desenvolvedores e operacionais. Na própria etimologia do termo “DevOps” pode-se ver: “dev” (developers) e “ops” (operations).

Parece exagero dizer, mas o DevOps deveria ganhar um nobel da paz. Era uma guerra infinita entre os desenvolvedores e operacionais. Mas como? Vamos entender o conflito.

Primeiramente, como funciona o setor operacional. Essa galera é o pessoal da infraestrutura, composta por administradores de sistema. Eles possuem uma grande e simples responsabilidade dentro de uma empresa: manter o sistema estável, sem problemas e sem quedas, pois isso é o que mantém a empresa gerando seus lucros e a satisfação do cliente.

Como eles fazem isso? Bom, monitorando constantemente, fazendo deploys sem bugs e buscando aprimoramento constante. Logo,  pode-se dizer que o objetivo do pessoal de infraestrutura é “manter a casa em ordem”.

Dito isso, pode-se notar que eles realmente se preocupam com a integridade do sistema e, por isso, retêm uma grande responsabilidade nas mãos. Já dizia o Tio Ben: “com grandes poderes, vêm grandes responsabilidades”. Eles são cobrados sempre pelos executivos, que estão “com o chicote em suas costas”. Se algo der errado no sistema ou caso haja indisponibilidade, os chefes vão cobrar dos administradores de sistema. Mas este chicote também está nas costas dos desenvolvedores, que são sempre cobrados por agilidade e inovação.

Falando neles, por outro lado, temos os desenvolvedores, o pessoal de criação, a galera do café e das linhas de códigos. Eles que são responsáveis por elaborar novas versões do sistema/site/aplicativo, por implantar melhorias e por desenvolver a lógica do produto. Um pessoal bem dedicado e com o grande objetivo de agregar cada vez mais valor para a empresa e deixar os clientes felizes.

Ok, mas qual era o conflito? Os desenvolvedores elaboravam atualizações com muita velocidade, muita mesmo. Porém, eles não podem simplesmente pegar essa atualização e fazer o deploy dela quando bem entender. Ela tem que passar pelo administrador de sistema, que vai avaliar se aquela atualização causará um estrago ou não (manter a estabilidade).

Então, como o pessoal da infraestrutura tinha grande responsabilidade com isso, eles também tinham muito medo de que o sistema falhasse e, assim, colocar suas cabeças na guilhotina. Com isso eles checavam o sistema, avaliavam, repetiam o processo, e faziam de novo e, por fim, faziam o que mais despertava a raiva dos desenvolvedores: limitavam o número de deploys.

Sério, os desenvolvedores queriam colocar suas atualizações no ar o quanto antes, com rapidez, agilidade, velocidade. Mas, quando chegavam nos administradores de sistemas, eles barravam. Então, existiam empresas que permitiam apenas um deploy por semana, outras, uma por mês. Assim, os programadores não conseguiam ver o fruto do seu trabalho, o que era revoltante para eles.

Essa caminhada a passos lentos deixava o cliente insatisfeito, e ele, por sua vez, reclamava. Os gestores de TI procuravam um culpado e sempre acontecia o mesmo: Desenvolvedores reclamando que o pessoal da infraestrutura não dava liberdade para colocar seu trabalho no ar e que eles eram muito lentos, já os administradores de sistema falavam que a coisa não era bem assim.

Basicamente, os administradores diziam que não poderiam fazer deploys com frequência sem avaliar os códigos, pois algum usuário poderia encontrar algum erro (bug) em produção e prejudicar os negócios. Mas, para resolver isso, surgiu o que se chama de infraestrutura ágil.

Infraestrutura ágil (Agile)

Por fim, descobrimos que o maior culpado pelo conflito é a própria empresa, que, claro, também sofre com isso. Ela está sempre cobrando estabilidade dos sysadmins e inovação e agilidade dos desenvolvedores. Mas o que ela mais esquece é que o gargalo disso tudo é a própria infraestrutura.

A empresa, muitas vezes, não dá aos profissionais as devidas ferramentas para trabalharem corretamente, resultando no conflito entre os lados, devs e ops, que brigam até a “morte”. Claro que ambos os lados, muitas vezes, não buscam se entender, mas a empresa, em vários momentos, não ajuda.

A infraestrutura ágil (lembra do Agile de 2008?) é um conceito que está dentro do DevOps. Não basta apenas juntar as duas equipes, deve-se ter recursos para que a infraestrutura seja otimizada e para que ambos trabalhem em harmonia. Isso faz com que as equipes comecem a agilizar os processos, realizar deploys com velocidade e diminuir os riscos de problemas e bugs.

Para que isso possa virar realidade, existem algumas ferramentas chave que serão pontos característicos da infraestrutura ágil, por exemplo:

• Orquestrador(es): é um software/aplicativo gerente que vai sintonizar todo mundo e vai, como diz o nome, orquestrar a infraestrutura. Ele vai executar comando e controlar instâncias nas máquinas em tempo real.

• Gerenciamento de configuração: é o que vai garantir a padronização do ambiente de TI.

O Gerenciador de configuração vai evitar problemas como: precisa-se atualizar uma linha de código em um sistema que está instalado em 100 máquinas. Ao invés de ir em uma por uma, ou usar aqueles programinhas que abrem inúmeras janelas, o orquestrador já adianta a vida e instala em todas as máquinas de forma uniforme e nivelada.

• Provisionamento: permite que sejam criados ambientes simples ou complexos, independentemente do gerenciamento de configurações ou do orquestramento.

Pilares do DevOps: a solução

Para que exista a paz entre os lados e a verdadeira compreensão do que é trabalhar bem, com agilidade e com qualidade (sem se “matarem” ou “saírem no braço”), é necessário o entendimento dos pilares básicos do DevOps. São eles:

Colaboração e Humildade

A verdade é que isso parece óbvio: a pessoa deve ter, acima de tudo, empatia pelos colegas de trabalho ou pessoas de outros setores. O desenvolvedor, quando entende o DevOps, começa a conhecer o lado do sysadmin, compreendendo que ele tem um compromisso com a estabilidade e que é extremamente normal se sentir inseguro em fazer diversos deploys no mesmo dia.

Por outro lado, o sysadmin também se coloca no lugar do desenvolvedor e pensa que aquele cara está lá, trabalhando pesado, criando dia e noite, e que ele também será cobrado pela empresa que atua. Entender que a cobrança também está nas “costas deles” e, que no final, todos sofrem com uma má administração é essencial para alcançar a harmonia entre as partes.

Sim, tudo isso é uma má administração. É difícil ouvir que a empresa é a verdadeira culpada disso, justamente porque ela também sofre com todo este relacionamento falho. Como já foi dito, cobrar duas tarefas conflitantes, deixando cada um em seu quadrado e esperar que tudo dê certo… bom, é problema. Por isso, entendemos que o primeiro pilar é a calma, a empatia, a compreensão e a colaboração.

Automação das coisas

Neste caso, automação é a palavra-chave para agilidade. A automação dos processos é importantíssima na filosofia DevOps, porque ela promoverá praticidade evitando ao máximo serviços manuais e demorados.

Um exemplo simples de automação é um software de uma empresa que emite tickets com as informações pessoais de cada um dos dez mil funcionários que trabalham lá.

Então, uma pessoa precisa pegar as informações do indivíduo de determinado CPF. Se esse cara abrir cada ticket para conferir um por um, ele vai levar, no mínimo, uma eternidade. Agora, um software automatizado possui um sistema de busca (lembrando que este é um exemplo mais básico). O portador daquele CPF será achado em questão de segundos. – isso é automatização. Levando essa ideia para programas mais complexos, nos aproximamos do real entendimento do DevOps.

Métricas

Medir e monitorar tudo! Exatamente. A formação de métricas estatísticas, informações gráficas e adjacências são peças fundamentais do DevOps. Além da agilidade, é muito importante gerar estratégias para trabalhar a curto, médio e longo prazo.

Para fazer isso, é muito bom que a infraestrutura seja monitorada, mostrando um monitor de métricas em tempo real. A aplicação Zabbix, por exemplo, quando bem configurada para cada tipo de infraestrutura, faz isso com excelência.

Então lembre-se, conhecimento através do monitoramento de infraestrutura é uma parte fundamental, pois dados visuais sobre comportamento, banco de dados e portas nos garantem uma visão direta e palpável sobre progressos e falhas, facilitando a implantação de melhorias e identificação de erros. Isso também pode ajudar leigos a entender o processo.

Transparência

A transparência, neste caso, é compartilhar as notícias com a equipe, destacar as melhorias que cada um dos colaboradores conseguiram conquistar, reconhecer o trabalho das pessoas, mostrar como o sistema foi beneficiado com o trabalho alheio e, através disso, incentivar a equipe a melhorar mais com tais notícias.

Além disso, deve-se ser transparente com os erros, as falhas e as métricas ruins. Do mesmo modo, o objetivo é fazer com que as pessoas possam ver onde elas erraram e, assim, aprender com os erros e buscar melhorar da próxima vez. Lembre-se: reportar notícias ruins nunca deve ser algo para jogar as pessoas para baixo, muito pelo contrário, é fazer com que a pessoas se sintam motivadas a aprender mais e mais com o processo.

Enfim, a paz

Antes de surgir o termo DevOps, ou toda essa ideia de infraestrutura ágil, existiam conflitos enormes entre os administradores de sistemas e os desenvolvedores. Ambos trabalhavam em seu quadrado, e ambos se recusando a dar o braço a torcer. Ainda existem pessoas e empresas que trabalham com este perfil, mas isso está ficando para trás.

O DevOps se aproxima de uma filosofia que faz com que estes dois grupos de profissionais trabalhem em equipe, de maneira integrada e com mais agilidade, um buscando entender o outro e seguindo os mesmos objetivos: manter a qualidade de seus produtos para uma melhor experiência para o cliente.

Gostou desse conteúdo? Acompanhe nosso blog para ter acesso a outros textos ricos e interessantes.