DevOps-uoldiveo

DevOps: execução de mudanças estratégicas sem medo

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 os riscos, e consequentemente, se desenvolveu a cultura de repúdio às mudanças como um efeito colateral. Através desta cultura, os processos que  normalmente possuem objetivos legítimos, muitas vezes sustentam a burocratização da TI para postergar mudanças.

Como resposta, novas culturas – como Agile e DevOps – têm sido promovidas para estimular a receptividade das empresas às mudanças. Ok, então chegamos ao nosso ciclo vicioso de medo de mudanças, mas como podemos torná-lo virtuoso para evolução do negócio?

O objetivo é simples: todos precisam 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 básicos de controle do impacto e aprimoramento do processo de mudança serão respeitados, ou seja, mudanças frequentes e incrementais.

Para isso, é preciso reconsiderar alguns pontos:

  • Métricas

    • Primeiramente, medir mudanças de forma coerente é fundamental para determinar o sucesso. Mudar com maior frequência e maior taxa de sucesso são características de culturas que pensam em mudanças incrementais e de menor risco, ao invés de enumeras mudanças acumuladas em uma única “janela de manutenção”. As métricas secundárias são importantes e ajudam a dimensionar e mitigar o impacto das mudanças, se focando no entendimento da taxa de sucesso e cobertura dos testes, ou performance e abrangência do impacto em usuários. Você se pensou em medir assim ao invés dos SLAs básicos de atendimentos de fila?
  • Práticas

    • Promover o aprimoramento das mudanças para minimizar o impacto através da automação e controle de sua abrangência. Sendo que a automação de sucesso é aquela que executa de forma simplificada receitas de atividades conhecidas ao invés de execução manual de extensos e desatualizados procedimentos documentados, bem como é aquela que se baseia no feedback sistêmico ao invés de subjetivos testes manuais. Já manter a abrangência do impacto sob controle é diretamente proporcional a segurança com a mudança proposta, quão menos confiante estamos, menor será o número de usuários submetidos a entrega. Afinal, quem nunca atendeu um requisito que exigiu alterações para as quais nossa suíte de testes não estava preparada?

 

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 mitigação de impacto e evolução dos processos. Uma cultura que mede suas mudanças e automatiza etapas e feedbacks, é uma cultura que sabe lidar com impacto e é capaz de reverter ações para restaurar a estabilidade. Para que então possa se pensar em reiniciar o próximo ciclo de mudanças…

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 e rollback (se necessário), 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, precisando que alguma estrutura ociosa fique disponível para isso.

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

Gerente de TI no UOL DIVEO, responsável por um novo grupo de inovação para mudar o processo de TI tradicional, para arquitetar sistemas e implementar iniciativas ágeis e DevOps no processo de desenvolvimento de nossos clientes. Promovendo novos conceitos operacionais entre equipes internas e clientes, como colaboração, segurança, testes, monitoração, orquestração e estratégia de delivery em um ambiente cloud native ou on-premises.