DevOps-uoldiveo

DevOps: Execução de mudanças sem medo como estratégia 

Encontramos muitos clientes e parceiros construindo ou revisando sua estratégia de transformação digital, e, inevitavelmente, neste momento de planejamento o tema passa por discutir a cultura e prática DevOps. Esta série de artigos visa apoiar nessa jornada, dividindo um pouco da nossa experiência. 

= 

Série DevOps: Execução de mudanças sem medo como estratégia 

Você deve estar se perguntando: “será este mais um artigo técnico e chato com diversos buzzwords de DevOps?”. 

E a resposta é: talvez sim… mas farei o possível para que ele seja interessante, e que discuta aspectos significativos a serem considerados na sua estratégia de TI.  😉 

Dizer que mudanças são fundamentais para a transformação é algo óbvio, e conhecido na natureza. As mudanças são os maiores ofensores da estabilidade de sistemas de TI, o que fez com que diversas metodologias aparecessem com o objetivo de minimizar este risco, e desenvolvessem inconscientemente a cultura de repudio às mudanças. Processos que tem normalmente objetivos legítimos, mas que sustentam a burocratização de TI, foram promovidos cada vez mais nas empresas. Como resposta a lentidão nas entregas, novas culturas (como Agile e DevOps) têm sido implementadas para estimular a receptividade das empresas às mudanças. Empresas gastam com gurus, ferramentas, treinamentos, qualquer coisa que permita entregar mais. 

Se faça estas perguntas: 

  1. Você tem janelas de manutenção que duram muito tempo (preparação, execução e validação)? 
  2. Com receio do impacto, você opta por fazer estas janelas com baixa frequência e acaba acumulando entregas? 
  3. O processo de validação de entrega é longo e envolve muitas pessoas de diferentes áreas? 
  4. O 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 mudanças geram desconfianças na sua empresa.  

Ok, então chegamos ao nosso ciclo vicioso de “medo das mudanças”.  Agora, como podemos torná-lo virtuoso para evolução do negócio? 

 

via GIPHY

 

O objetivo é simples: todos tem que confiar nas mudanças. 

E quando digo todos, são todos sem exceção, pois se algo der errado haverá a certeza de que os princípios que considero básicos da cultura DevOps estarão presentes: capacidade de medir, automação e controle do impacto.

  • 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 pensam em mudanças incrementais (“menores”), ao invés de enumeras mudanças acumuladas em uma única “janela de manutenção”. As métricas secundárias também são importantes, principalmente para analisar o impacto das mudanças (como usuários afetados ou taxa de sucesso de testes), e para identificar etapas ou componentes que apresentam maiores problemas. Você já pensou em medir suas mudanças assim ao invés dos SLAs básicos de atendimentos de fila? 
  • Automação: promover o aprimoramento das mudanças através 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, é ganhar escala no processo de mudanças para diferentes componentes e aumentar 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 eventualmente cancelando uma entrega?   
  • Controle do impacto: é ser capaz de responder rapidamente às adversidades das mudanças, através do controle da abrangência e da rapidez na restauração. Segmentar a mudança fazendo com que parte dos usuários ou sistemas sejam afetados 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) são técnicas fundamentais de culturas receptivas às mudanças. Estas técnicas demandam colaboração entre as áreas de desenvolvimento e sustentação, pois a definição e implementação depende 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 de suas mudanças é uma cultura que sabe lidar com a estabilidade sem inviabilizar a evolução do negócio.

via GIPHY

Mas, e na prática como funciona? 

Como em quase tudo na cultura DevOps, este tema passa por pessoas, processos e ferramentas, mas se nos focarmos neste último, vamos além da busca de UMA “ferramenta DevOps” perfeita. Temos que buscar característica que contribuam para as práticas acima. Para ilustrar, vamos contrapor dois exemplos: 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, pode-se associar dois serviços, o AWS CloudFormation na documentação e automação da infraestrutura (Infraestructure as code), e AWS CodePipeline para coordenar e visualizar etapas da automação. Bem como é possível utilizar as características on-demand dos serviços AWS para paralelizar o ambiente de mudança, utilizando-o 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 através de aplicações como o Jenkins ou serviços como o Git HUB, em um ambiente on-premises 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. Bem como, os serviços on-premises não tem a característica on-demand necessárias para uma estratégia de deploy como blue/green, precisando que alguma estrutura ociosa fique disponível. 

As ideias DevOps não estão restritas aos ambientes, mas existem estruturas que tem funcionalidades nativas que permitem 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.