Desvendando os Anti-Padrões DevOps: Como otimizar a entrega de software

Introdução

Um dos maiores problemas que (acredito eu!) deve afeta grande parte das equipe de desenvolvedores de software, não é “como transformar uma ideia em um bom sistema”, mas sim em “como entregar este sistema para os usuários o quanto antes ?”

Este sempre foi uma grande preocupação para os times, pois após realizado todo levantamento de requisitos, definido o escopo e os entregáveis, a codificação passa a ser a grande diversão para esses profissionais, porém precisam garantir que tudo funcione de forma adequado e entregue valor ao cliente final o mais rápido possível, é nesse ponto que as atividades fogem das mãos dos desenvolvedores e é necessário passar por outros processos que envolvem outras equipes, como testadores, analistas de segurança e time de operações, tornando tardio o uso da aplicação pelo usuário.

Foi aí então que surgiu a Buzzword mais badalada da área TI, o DevOps, pois este conceito veio como uma mágica para dizer que todo o processo deve ser integrado para que seja possível construir, entregar, testar e implantar software de forma confiável, rápida e com poucos riscos sempre que necessário ou quando um novo commit for realizado no repositório, através de processos automatizados.

Coisa de outra dimensão até então, pois todo lançamento de versão era sempre considerado um grande evento nas organizações (em algumas isso ainda é realidade) e por que isso acontece ? Na maioria massiva dos casos, esta ligado ao risco que este processo envolve por ser intensamente manual, transformando o que deveria ser um simples apertar de botão, em algo muito mais complexo e assustador, pois se cada passo não for executado perfeitamente por todos envolvidos, a aplicação poderá não funcionar perfeitamente ou ainda quebrar todo o processo.

Normalmente, as práticas e processos utilizados  por essas empresas que ainda “não experimentaram o DevOps”, costuma se enquadrar em ao menos 1 dos processos que conhecemos atualmente como “Anti Padrões DevOps”. Não existe nada errado com essas práticas ou processo, é um padrão que as empresas adotaram no passado e ainda funciona para elas, no entanto para as práticas e processos da Cultura DevOps são considerados ineficientes… e provavelmente vocês irão concordar.

Anti-Padrões DevOps

Listaremos abaixo os 6 principais Anti-padrões:

DevOps é uma equipe que só envolve SysAdmins e Desenvolvedores ?!

Primeiramente, DevOps não é uma pessoa, equipe, time ou uma área da empresa! É bem comum recebermos contato de clientes na área de consultoria da 4Linux onde o pessoal ao se apresentar diz: “Sou DevOps da empresa XPTO …”

DevOps é uma Cultura, que tem como seus pilares a Colaboração, Afinidade, as Ferramentas e Adaptatividade/Dimensionamento.

Apesar de seu nome ser originário da junção das palavras Development + Operations = DevOps, suas práticas não se restringem apenas à esses times, sendo um processo que deve ser abraçado por toda a organização de maneira holística para ser realmente efetivo. Afinal, esses dois times não se interagem apenas entre si, pois recebem demandas de acordo com as necessidades do negócio, interagindo com as áreas de projetos, arquitetura, suporte, segurança, testes, etc.

Setorização

Um silo departamental ou setor organizacional descreve a mentalidade de equipes que não compartilham seus conhecimentos umas com outras equipes na mesma empresa, o que dificulta ou torna lento o trabalho quando envolve várias equipes, pois as pessoas precisam de diversas autorizações,  passando por vários níveis da cadeia gerencial, para só então obter algum recurso ou informação de pessoas que estão em uma outra equipe ou setor.  Isso também diminui a moral da organização quando essas equipes ou silos começam a se ver como adversários.

Este anti-padrão destrói totalmente um dos principais pilares do DevOps que é justamente a colaboração, assim empresas estão criando equipes multifuncionais e autogerenciadas.

Cultura de Culpa

Como os erros são tratados em suas organizações ? Na grande maioria dos casos é um apontando o dedo para o outro, afim de levar a “culpa” para o mais longe de si ou de sua equipe, aquele empurra-empurra que quando software não funciona “o problema está na infraestrutura”, quando o acesso é negado “o problema está no banco” e por aí vai.

Nesta cultura é realizado uma análise, como uma autopsia que pode apontar para as ações de uma pessoa/equipe como sendo a “causa raiz” do problema e consequentemente essa pessoa será culpada, repreendida, ou mesmo demitida pelo seu papel no incidente, pois os erros sempre são causados por “maçãs podres” que precisam ser descartadas.

Isso motiva as pessoas a se concentrarem em simplesmente evitar ter um dedo apontado para elas, ficando menos focados na aprendizagem e colaboração.

O DevOps adota uma cultura Blameless (sem culpa), onde os erros são vistos como oportunidade de aprendizagem, sem repreendimentos.

Implantação manual

As aplicações modernas de qualquer tamanho é complexa e envolve muitas partes moveis (como os microsserviços e APIs), na entrega manual cada passo é independente e executado de forma individual,  sendo necessário realizar uma analise em cada passo, o que o torna o processo mais suscetível ao erro humano. Qualquer diferença na ordenação e no tempo de execução dos passos podem levar a resultados diferentes e essas diferenças raramente são boas.

Isso leva a uma série de fatores, como a entrega de versões imprevisíveis, que muitas vezes precisam ser canceladas e ambientes que precisam ser restaurados aos seus padrões anteriores em função de problemas desconhecidos. Qualquer processo de implantação manualmente é tedioso, repetitivo e costuma exigir um alto grau de conhecimento, o que faz-se necessário designar um bom analista para esta tarefa e historicamente este tipo de profissional não gostam de tarefas tediosas e repetitivas, porém é a melhor maneira para se evitar erros humanos.

É neste ponto que entra a automação, pois ela permite que sua equipe altamente capacitada trabalhe em tarefas que de fato agregam valor ao negócio e se existe um processo automatizado, ele deve ser o único modo pelo qual o software é implantado (em qualquer ambiente).

Implantar em um ambiente similar ao de produção somente quando o desenvolvimento estiver completo

Nesse caso, a primeira vez em que um software é implantado em um ambiente similar ao de produção (Homologação, por exemplo) é quando todo o desenvolvimento está concluído ou pelo menos o que foi
definido como concluído pelo time de desenvolvimento. Sendo esta também a primeira vez em que o time de operações tem contato com o software – há caso em que existem times de operações para implantar em homologação produção, o que piora a situação, pois um time só terá contato e conhecimento do software quando o mesmo ir para produção.

Se existe uma equipe de testes, este só conseguiram testar as partes do software em ambiente de desenvolvimento e mesmo que a equipe de desenvolvimento crie todos os instaladores corretos, os arquivos
de configuração, as migrações de bancos de dados e a documentação necessária para passar ao time de operações que executará a implantação, tudo isso ainda não foi testado em um ambiente de homologação, tendo grandes chances de haver um retrabalho em cima desses componentes devido aos erros que irão aparecer no processo.

Uma vez que a aplicação esteja em homologação, é comum que sejam encontrados defeitos. Infelizmente, muitas vezes não é possível resolver todos eles, pois a data de implantação está se aproximando rapidamente e, nesse estágio do projeto, adiá-la seria inaceitável. Sendo assim, os defeitos mais críticos  são resolvidos às pressas, e uma lista de defeitos conhecidos é guardada pelo gerente de projeto, e será priorizada quando o trabalho recomeçar, no próximo release.

Neste caso a saída é integrar todas as atividades de teste, implantação e entrega de versão ao processo de desenvolvimento. Transforme-as em uma etapa normal e contínua do desenvolvimento, de modo que haja pouco risco, já que todos processos foram ensaiados diversas vezes em ambientes cada vez mais próximos do produtivo.

Gerência de configuração manual dos ambientes de produção

É bem comum encontrarmos organizações que realizam o gerenciamento de configurações dos seus ambientes de produção por meio de uma equipe de operação, assim quando uma mudança é necessária ela é feita manualmente nos servidores de produção.

Assim como falamos acima, processos manuais são suscetíveis à erros humanos o que pode afetar o ambiente produtivo, por exemplo, um cluster de 5 nós que precisa de uma alteração no arquivo de configuração, no primeiro e segundo nó, provavelmente estará correto, na quarta e quinta pode haver um valor divergente por erro de digitação e a terceira ter sido esquecida, fazendo com que um dos nós suporte menos carga, outro demore mais tempos para processar requisições, etc.

Sendo um processo manual, se houver registro da mudança, será feito em uma espécie de Wiki e salvo em um banco de dados, o que não possibilita restaurar a versão anterior da configuração de forma eficiente.

Uma boa prática neste caso é manter toda a configuração dos ambientes em um controle de versão e aplicá-las de forma automatizada, isso significa que cada mudança feita em produção deve ser registrada, auditável e passível de ser repetida, o que torna todo o ambiente mais resiliente, pois em caso de desastre é possível recriar todo o cenário de produção de forma exata e preferencialmente com um clique de botão.

Finalizando …

Trouxe aqui o que é considerado pela cultura DevOps um anti-padrão, tema que é cobrado por algumas certificações da área como a Exin DevOps Master. É comum encontrarmos literaturas que trazem 10 ou 13 anti padrões, mas abordei aqui os principais e como podem ser resolvidos, espero ter contribuído de alguma forma 😉

Até a próxima ! E lavem as mãos !

Fonte: Entrega contínua: como entregar software de forma rápida e confiável / Jez Humble, David Farley ; tradução: Marco Aurélio Valtas Cunha, Ronaldo Melo Ferraz ; revisão técnica: Rafael Prikladnicki. Porto Alegre: Bookman, 2014.

Líder em Treinamento e serviços de Consultoria, Suporte e Implantação para o mundo open source. Conheça nossas soluções:

CURSOSCONSULTORIA