No ambiente de TI sempre vimos equipes de Operações e Desenvolvedores muitos separadas, cada um olhando para o seu próprio umbigo.
A equipe de operações sempre preocupada com as necessidades do negócio que é o de manter a infraestrutura 100% do tempo disponível, segura, sem bugs e com alto desempenho. Para isso, sempre foi necessário realizar a criação de inúmeros processos e procedimentos em que todos os usuários tinham que serem inseridos. Essa é uma visão natural de quem é cobrado por isso.
Já os desenvolvedores estão sempre preocupados em colocar suas versões em produção, visando agregar, o mais rápido possível, valor ao negócio do cliente. Porém, eles tem um fator impeditivo, que são os processos das equipes de operações, com seus procedimentos rígidos que impactam a implantação de sistemas, assim que testados.
Para termos uma visão mais clara, gerei um quadro comparativo entre as necessidades das equipes de desenvolvimento e operações:
Desenvolvimento | Operações |
Desenvolvimento ágil | Disponibilidade |
Inovação | Desempenho |
Entrega contínua | Redução de riscos |
Metodologias ágeis: Scrum, XP, etc | Governança: Cobit, Itil, etc |
Ambiente de testes | Segurança |
Mudança agrega valor | Mudança é risco |
Frase: Eu quero / Eu preciso | Frase: Não |
No final das contas, ambas as equipes estão querendo agregar valor ao negócio, porém não há uma sinergia dos objetivos, gerando um conflito muito grande entre os dois setores.
Quebrando paradigmas…
Antes de misturar as equipes, é necessário a maturidade dos envolvidos criando um senso de responsabilização do negócio, onde os objetivos estão alinhados e que também haja respeito mútuo entre as pessoas.
Esse é um ponto de extrema importância, pois em uma equipe temos percepções diferentes das necessidades.A equipe de operações tem que abrir mão, em partes, dos seus processos e os desenvolvedores entender as responsabilidades que, antes era da equipe de operações, para tomar para si o peso dos impactos nos negócios caso ocorram falhas em ambientes de produção.
Em um caso real, um dia estávamos com problemas em um ambiente de produção que tornava a aplicação indisponível, gerando uma grande pressão, inicialmente, em cima da operação. Conversando com as equipes durante um desses momentos de falha, o desenvolvedor queria que o sistema ficasse indisponível enquanto ele analisava a falha, já a equipe de operações, reiniciava os serviços para tornar a mesma disponível rapidamente. Não estou falando que um ou outro esta certo, porém cada um buscava o melhor para minimizar o impacto em sua equipe. Tal cenário gerou uma grande discussão entre as equipes e o foco da resolução foi totalmente deixado de lado.
Assim, se ambos se responsabilizassem de verdade pela falha em questão e, respeitando a visão das pessoas envolvidas, com certeza a resolução seria muito mais rápida, não gerando a discussão de quem estava certo ou errado.
Também é necessário salientar o alinhamento com alta gestão da empresa. Pois não adianta as equipes continuarem a ser cobradas de forma separada e contraditória, operações por manter 100% o sistema no ar e o desenvolvimento em entregar melhorias a todo momento.
Mas precisa tudo de uma vez?
A introdução ao DevOps pode ser feita aos poucos, principalmente com a abertura da equipe de operações liberando ambientes de testes iguais aos de produção, ou melhor, deixando o desenvolvedor criar seus próprios ambientes de testes, gerando para si um know-how referente ao ambiente de produção.
Hoje, Cloud Computing é uma realidade e, com isso, a facilidade de replicar ambientes de produção é fácil e acessível para todos, independente do contexto. Porém, para termos uma paridade de ambientes, ferramentas como Vargrant, Puppet ou Chef, podem auxiliar muito bem na replicação e gestão dos ambientes de testes e produção.
Para ajudar a adaptação da “metodologia” DevOps, liberar sistemas de monitoramento pode ser um dos primeiros passos para criar um ambiente propício para a adoção. Outros passos são: liberação fácil de logs, processos automatizados para deploy em produção até chegarmos na gestão do ambiente de produção por apenas uma equipe multidiciplinar, a equipe DevOps.
DevOps quer dizer que os desenvolvedores gerenciaram o ambiente de produção?
Em muitos casos, as configurações de Kernels ou dos Sistemas Operacionais são tão específicos ou importantes para manter o ambiente disponível que pode haver um grande receio das equipes de operações realizar a liberação total do ambiente de produção. Além disso, em equipes de desenvolvimento existem diferenciados perfis e conhecimento que podem se tornar outro fator da dificuldade na adoção.
Outros pontos importantes, que não podem ser ignorados, são os processos aplicados com Cobit ou Itil que, por sua vez, chegam a “travar” os processos de entrega contínua, e com razão. Pense agora em uma equipe DevOps gerenciando um sistema de CallCenter, onde a cada atualização, todas as ligações caem, gerando um cenário extremamente instável para o negócio. Ou, então, fazendo entrega contínua em sistemas que gerenciam UTIs, onde a cada falha, mortes podem ocorrer.
Porém, ter procedimentos automatizados de deploy, monitoramento com informação compartilhada e acesso aos logs podem ser suficiente para ter um ambiente cooperativo e, com isso, atingir o DevOps. Lembrando que DevOps não é necessariamente o desenvolvedor dando suporte total ao ambiente de produção, e sim ter equipes que trabalham de forma integrada para trazer benefício ao negócio.
A cultura integrada é muito mais importante do que as permissões que um ou outro tem em cima de alguma funcionalidade em ambientes de teste e ou produção.
Ignorar processos de entrega e gestão de ambiente, muitas vezes, pode ser uma falha para alavancar os negócios, por isso a necessidade na agilidade em todas as frentes da tecnologia.
[Crédito da Imagem: Programação – ShutterStock]