DevOps-uoldiveo

DevOps: exorcizando o medo de mudanças

Na nova economia, é preciso rever estratégias. É um processo delicado, mas inevitável para a sobrevivência do negócio.

Muitas empresas estão em fase de construção ou revisão de suas estratégias de transformação digital. Nesse momento, é praticamente inevitável discutir a cultura e prática DevOps. É preciso estar atento e para isso você terá a oportunidade de esclarecer suas dúvidas e entender aqui um pouco mais sobre esse universo.

Rever estratégias é um procedimento fundamental para a transformação. Contudo, as mudanças são os maiores ofensores da estabilidade de sistemas de TI, o que faz com que diversas metodologias apareçam com o objetivo de minimizar esse risco. Mudanças sempre trazem perdas e ganhos e, por essa razão, na maior parte das vezes, elas provocam resistências e ceticismos nas equipes. Processos que têm normalmente objetivos legítimos, ainda sustentam a burocratização de TI.

A solução para reverter esse quadro, responsável por provocar lentidão nas entregas, veio pelas mãos de  culturas como Agile e DevOps. Elas têm sido implementadas para estimular a receptividade das empresas às mudanças, tão necessárias na nova era.

Para um diagnóstico mais assertivo sobre o quadro na sua empresa, pergunte-se as seguintes questões:

  • Possuo janelas de manutenção que duram muito tempo (preparação, execução e validação)?
  • Com receio do impacto, opto por fazer essas janelas com baixa frequência e acaba acumulando entregas?
  • Meu processo de validação de entrega é longo e envolve muitas pessoas de diferentes áreas?
  • Meu plano de restauração é complexo e nem todos estão confiantes de sua eficiência?

Se você respondeu “sim” para alguma das perguntas, mesmo para entregas consideradas simples pelo negócio, provavelmente as mudanças costumam gerar desconfianças na sua empresa.  Provavelmente, o diagnóstico é: “Medo de mudanças”. Como é possível reverter esse quadro para permitir a evolução do negócio?

via GIPHY

 

O primeiro passo é fazer com que todos da equipe entendam que é vital confiar nas mudanças e acreditar em seus resultados. Todos deverão estar alinhados aos princípios básicos da cultura DevOps: capacidade de medir, automação e controle do impacto. Entenda a importância de cada um deles:

Métricas – Primeiramente, medir mudanças de forma coerente é fundamental para determinar o sucesso e possibilitar o aprimoramento. Mudar com maior frequência e maior taxa de sucesso são características de culturas que contemplam mudanças incrementais (“menores”), em vez de várias mudanças acumuladas em uma única “janela de manutenção”.

As métricas secundárias também são importantes, em especial para analisar o impacto das mudanças (como usuários afetados ou taxa de sucesso de testes) e identificar etapas ou componentes que apresentam grandes problemas. Você já pensou em medir suas mudanças assim em vez dos SLAs básicos de atendimentos de fila?

Automação – É preciso promover o aprimoramento das mudanças por meio da minimização de etapas manuais sujeitas às falhas de interpretação e execução, deixando de cometer “erros conhecidos” mesmo com o turnover. Ser capaz de trocar procedimentos extensos e desatualizados por automações que contemplem feedbacks sistêmicos gera ganho de escala no processo de mudanças para diferentes componentes e aumenta a confiança das áreas nas etapas de entrega, especialmente para as áreas de sustentação. Quantos erros se repetiram nas suas mudanças que atrasaram a conclusão ou eventual cancelamento de uma entrega?  

Controle do impacto – Ser capaz de responder rapidamente às adversidades das mudanças, por meio do controle da abrangência e da rapidez na restauração, é ter as rédeas nas mãos. É preciso implementar técnicas fundamentais de culturas receptivas às mudanças como segmentar a mudança, fazendo com que parte dos usuários (ou sistemas) seja afetada pela entrega (como canary ou feature toggling) e oferecer ainda formas mais fáceis de restauração em caso de desvios de comportamentos ou impactos severos (como no redirecionamento do blue/green delivery). Essas técnicas demandam colaboração entre as áreas de desenvolvimento e sustentação, pois a definição e a implementação dependem da compatibilidade com as funcionalidades. Quantas foram as situações de Disaster Recovery por impactos menores? 

O fato é que erros inevitavelmente acontecerão, mesmo com uma nova cultura. O ponto de sucesso está em entender que eles fazem parte da transformação, e que melhor do que negar mudanças, é colocar esforços na evolução do processo e mitigação de impacto. Uma cultura que mede, automatiza e controla o impacto das suas mudanças é uma cultura que sabe lidar com a estabilidade sem inviabilizar a evolução do negócio.

via GIPHY

Como funciona, na prática?

Como em quase tudo na cultura DevOps, sua estruturação passa por pessoas, processos e ferramentas. Mas se o foco estiver nesta última, é preciso ir além de uma “ferramenta DevOps” perfeita e buscar características que contribuam para as melhores práticas. Como exemplos temos cloud-native e on-premises, para analisar características de automação e capacidade de restauração rápida.

Cloud-native (como AWS)

Para automatizar as etapas da mudança, é possível associar dois serviços, o AWS CloudFormation na documentação e na automação da infraestrutura (Infraestructure as code), e AWS CodePipeline para coordenar e visualizar etapas da automação.

Outra alternativa são as características on-demand dos serviços AWS para paralelizar o ambiente de mudança, usando-as na estratégia de delivery como blue/green, sem afetar significativamente os custos.

On-premises

Apesar de ser perfeitamente possível coordenar as etapas de automação por meio de aplicações como Jenkins ou serviços como Git HUB, o ambiente on-premise não permite a automação de serviços de infraestrutura (infraestructure as code) sem a adoção de alguma plataforma de abstração como Openstack ou VMWare.

Além disso, serviços on-premises não têm a característica on-demand necessária para uma estratégia de deploy como blue/green, que necessita que alguma estrutura ociosa fique disponível.

As ideias DevOps não estão restritas aos ambientes, mas existem estruturas que têm funcionalidades nativas que possibilitam maior flexibilidade para adoção de diversas práticas.

 

 

Marcus Camillo

Marcus Camillo é um gestor de TI do UOLDIVEO, que trabalha há mais de 10 anos nos times de Engenharia e Desenvolvimento. Tendo desenvolvido projetos com diversas tecnologias, acredita na provocação de que há sempre uma forma diferente e melhor de trabalhar com TI. Nerd nato, é incapaz de negar discussões sobre tecnologia, ciência, futebol ou política, principalmente se acompanhadas de uma bela IPA.