7 armadilhas que prejudicam o sucesso do DevOps

Muitas organizações começaram a incorporar DevOps em sua combinação de TI, seja para projetos pequenos ou em uma escala maior.

Embora o DevOps possa fornecer vários benefícios – entrega mais rápida de aplicativos e recursos, comunicação e colaboração aprimoradas entre as equipes de desenvolvimento e de operações, resolução mais rápida de problemas e entrega iterativa de serviços de TI – não há garantias de sucesso.

Como observou a empresa de pesquisa Gartner, “DevOps está rapidamente se tornando popular, mas ainda restam dúvidas sobre como essa abordagem relativamente nova de cultura, automação e design de plataforma pode cumprir o que promete”. Muitas organizações ainda enfrentam obstáculos na implementação e dimensionamento de uma prática de DevOps, afirma a empresa.

Até 2022, 75% das iniciativas de DevOps não atenderão às expectativas devido a questões relacionadas ao aprendizado e mudança organizacional, diz o Gartner.

Aqui estão algumas armadilhas comuns a serem evitadas.

Falta de habilidades necessárias

A lacuna nas habilidades de tecnologia pode afetar praticamente todos os aspectos da TI, e DevOps não é exceção. Se os membros da equipe de desenvolvimento ou operações do DevOps não tiverem as habilidades de que uma organização precisa, qualquer tentativa de obter benefícios do DevOps provavelmente falhará.

“É fundamental que os membros da equipe tenham habilidades físicas e sociais”, afirma Sam Babic, Vice-Presidente Sênior e Diretor de Inovação da fornecedora de serviços de conteúdo Hyland.

A empresa emprega DevOps e automação em várias áreas do negócio. “Essas práticas são aproveitadas em nossa organização de TI para satisfazer as necessidades operacionais do negócio, como contabilidade, finanças, vendas, marketing, etc.”, diz Babic. A Hyland também usa DevOps para criar os produtos de software que entrega aos clientes por meio de vários canais.

Para produtos baseados em nuvem que seguem um modelo de entrega contínua, “usamos DevOps e automação para atualizar a única fonte de software que todos os clientes compartilham, bem como para atualizar quaisquer modelos de dados e outros componentes periféricos necessários para a operação”, diz Babic. “Este ambiente também aproveita a automação para monitoramento”.

E o ambiente requer habilidades difíceis em várias áreas, incluindo sistema de orquestração de contêiner Kubernetes; aplicativos de gerenciamento de liberação; provisionamento de software, gerenciamento de configuração e ferramentas de implantação de aplicativos; ferramentas e serviços de controle de versão, como GitHub; linguagens como Python, JavaScript, Bash e Node.js; e várias tecnologias de segurança.

“Visto que as cargas de trabalho que gerenciamos para nossos clientes estão na nuvem, a equipe deve estar bem ciente das plataformas e serviços de nuvem disponíveis”, diz Babic.

Do ponto de vista das habilidades sociais, a comunicação e a colaboração são vitais. “É obrigatório que os campeões [DevOps] se comuniquem com clareza e muitas vezes no compartilhamento de ideias e práticas”, diz Babic. “Nas áreas em que as equipes operam como um serviço compartilhado, elas devem entender as considerações de implantação dos vários produtos e trabalhar em estreita colaboração com as equipes de produto para garantir que seus produtos se alinhem com as estratégias de implantação no início dos estágios de design”.

Os ciclos de feedback são importantes, de modo que as práticas de automação estão constantemente melhorando, diz Babic.

Falha em estabelecer processos bem definidos

DevOps é um processo, cultura e disciplina que combina tarefas de desenvolvimento com procedimentos operacionais, diz Emal Ehsan, Diretor da Cervello, uma unidade da empresa de consultoria de gerenciamento global Kearney.

“Cada organização deve olhar para suas abordagens atuais e mapear um conjunto básico de processos e procedimentos para construir DevOps como uma competência central e qual seria o impacto dessas mudanças”, diz Ehsan. “Uma vez feito isso, reserve um tempo para construir os recursos básicos com a expectativa de que o encanamento extra exija planejamento”.

Isso pode ser uma mudança de ritmo intimidante para organizações que valorizam processos ágeis e vitórias antecipadas, diz Ehsan. “Mas você vai compensar com a melhor qualidade de trabalho que pode ser repetida várias vezes”, diz ele.

Na primeira vez que o processo é montado, pode demorar mais do que o esperado para a primeira implantação. Mas as implantações subsequentes podem ser feitas em uma fração do tempo, diz Ehsan. O retorno sobre o investimento para o custo inicial virá inevitavelmente dessas iterações subsequentes, diz ele.

“Durante sua fase de fundação, também é muito importante definir o que significa ‘sucesso’ e como você o medirá”, diz Ehsan. “Você está reduzindo o número de interrupções de aplicativos em 20%? Aumentando a porcentagem de implantações de primeira tentativa bem-sucedidas para lançamentos de versão em 30%? Reduzindo os prazos de entrega para novos ambientes de infraestrutura em quatro dias?”

Definir sucesso serve a dois propósitos. “O primeiro é dar a você a base para encorajar novas adoções”, diz Ehsan. “O segundo é dar à equipe um objetivo tangível. Se sua equipe é competitiva por natureza, uma barreira alta pode gerar os melhores resultados; ao passo que as equipes com medo de falhar podem precisar de uma meta inferior para construir confiança no processo e nos membros da equipe. Em ambos os casos, o sucesso muitas vezes leva a excelência além da meta”.

Começar muito grande

As empresas não devem lançar iniciativas de DevOps em grande escala, porque isso pode sobrecarregar os recursos, incluindo equipes de desenvolvimento e operações.

“As transformações DevOps são ‘elefantes’ que não podem ser comidos com uma mordida”, diz Ehsan. “Escolha um ponto de partida para o foco – por exemplo, um pequeno projeto que requer contribuições de diferentes departamentos – e implemente o DevOps lá”.

Os conjuntos de ferramentas que uma empresa usará para atingir seus objetivos terão vários níveis de maturidade, assim como as pessoas que os implementarão, diz Ehsan. “O suporte cultural e tecnológico para seus casos de uso iniciais pode estar em sua infância, e não importa o quão bem planejada sua abordagem seja, inevitavelmente chegará um momento em que você descobrirá que não pode fazer o que precisa da maneira que você pensou que poderia fazer isso”, diz ele.

Se uma empresa se encontra sobrecarregada por um programa DevOps que não estava preparada para assumir, o melhor antídoto é garantir que haja uma variedade de solucionadores de problemas na equipe que abordam as tarefas de ângulos diferentes, diz Ehsan.

“Pequenos ganhos e boa colaboração tornam-se infecciosos, portanto, garantir que você tenha a equipe certa, flexível e capaz de se virar quando necessário ajudará a garantir o sucesso inicial e a adoção do processo em geral”, diz Ehsan.

Oferecer muita ou pouca autonomia

Um dos mantras duradouros do DevOps é dar às equipes autonomia para determinar sua própria maneira particular de trabalhar e obter resultados, diz Ola Chowning, Sócia da empresa de consultoria e pesquisa em tecnologia ISG.

“A armadilha aqui é que o excesso de autonomia pode resultar em expansão arquitetônica, tanto lógica quanto com ferramentas; incapacidade de mudar os membros da equipe facilmente entre as equipes de DevOps; e um verdadeiro desafio com a supervisão da gestão do desempenho organizacional”, diz Chowning.

“Vimos vários exemplos de autonomia excessiva”, incluindo uma proliferação de ferramentas, estilos e métodos.

Pouca autonomia, incluindo a criação de barreiras que retardam o trabalho e o fornecimento de ferramentas abaixo do ideal para uma necessidade específica da equipe, também não é bom, diz Chowning.

Uma boa prática para enfrentar o desafio do equilíbrio da autonomia é criar um órgão de padrões, como um centro de excelência (CoE). Isso deve ser composto por profissionais de várias equipes, que estabelecem grades de proteção em torno das áreas onde os padrões podem impulsionar a eficiência e para ajudar na seleção e uso de ferramentas, metodologias e parâmetros de governança.

“Definir o piso dos padrões necessários; coisas que você deve fazer, como controle de versão, segurança, privacidade, etc.”, diz Chowning. “Permitir que as equipes tragam necessidades fora dos padrões atuais para o CoE para melhoria contínua” em ferramentas, processos e formas de trabalho. Além disso, faça a rotação dos indivíduos que compõem o CoE, diz ela, permitindo que mais membros da equipe participem.

Supor que DevOps seja um modelo único

Quando as empresas implementam o DevOps de forma mais ampla, geralmente há uma tendência de padronizar tudo para simplificar a implementação, diz Chowning. Isso pode não ser uma boa ideia.

“Produtos / recursos específicos podem ter menos ou mais necessidade, ou menos ou mais capacidade, de oferecer suporte a todos os elementos de tal modelo padrão”, diz Chowning. “Isso pode ser devido à arquitetura, necessidade de negócios – altas taxas de mudanças versus baixas – e outras características”.

Por exemplo, um cliente ISG tentou direcionar o desenvolvimento e a responsabilidade operacional para todas as suas equipes de produtos usando um modelo padrão consistente. Uma das equipes estava trabalhando em um ambiente de mainframe, que raramente precisava de mudanças.

Quando o cliente tentou fazer com que a equipe operacional assumisse as funções de desenvolvimento, descobriu que a equipe não tinha as habilidades ou experiência para fazer o trabalho. “Ainda assim, quando eles procuraram contratar recursos com experiência em desenvolvimento, eles descobriram que o preço de manter essas habilidades em tempo integral – quando raramente faziam alterações no desenvolvimento – representava mais custo do que poderiam obter em benefício”, diz Chowning.

A experiência levou ao reconhecimento de que essa capacidade de tecnologia específica não se prestava a um alto grau de DevOps de uma perspectiva de equipe. “Até mesmo o padrão de automação e ferramentas foi considerado inadequado, dada a arquitetura e o cronograma de eventual substituição em apenas um ou dois anos”, diz Chowning.

Em vez de adotar um modelo de DevOps de tamanho único, o ISG recomenda a criação de modelos de “DevOps completo” e “DevOps mínimo”. “A partir desses dois modelos, crie uma lista de requisitos mínimos que se apliquem a ambos os modelos e dos quais todas as equipes possam se beneficiar, e eles se tornam suas principais práticas e princípios de DevOps”, diz Chowning. “O que você acaba obtendo são essencialmente vários níveis de DevOps que diferem efetivamente de equipe para equipe e até mesmo permitem que cada equipe ‘suba de nível’ ou ‘desça de nível’”.

Negligenciar para medir o impacto da mudança

DevOps significa mudança, e a mudança nem sempre ocorre sem problemas. Melhor descobrir mais cedo ou mais tarde se algo não está funcionando como deveria.

“Se você estiver fazendo testes automatizados em um novo pipeline de implantação, os primeiros avisos podem salvá-lo de desastres posteriores”, diz Ehsan. “Infelizmente, ninguém nota incêndios que nunca aconteceram ou celebra o eletricista que não incendiou a casa”.

Com o tempo, as organizações que coletam métricas sobre o impacto do DevOps colherão os benefícios por meio da qualidade do trabalho e da satisfação dos clientes, interna e externamente, porque as coisas funcionam.

Além disso, é difícil justificar o tempo e os dólares gastos em DevOps sem mostrar o impacto, diz Ehsan. “Se você deseja que as equipes de vendas adicionem tempo de espera, deseja que o CFO aprove o orçamento e dimensione o exercício para o resto da sua organização, você precisará de dados e resultados para mostrá-los”, diz ele.

Não criar uma cultura DevOps

Para que o DevOps seja altamente bem-sucedido, as equipes precisam ser apaixonadas por ele, e isso vem da construção da cultura certa.

“Cultura é a chave. A equipe precisa ser uma equipe que queira trabalhar com métodos DevOps”, afirma Brian Balzer, Vice-Presidente de Tecnologia Digital e Transformação de Negócios da empresa de engarrafamento G&J Pepsi.

“Eles têm suas funções, mas querem trabalhar juntos para cumprir a meta”, diz Balzer. “Eles precisam ter habilidades interdisciplinares e bons conhecimentos de negócios. Se os membros da equipe quiserem apenas trabalhar em sua disciplina ou o que sua descrição de trabalho definida é, você terá dificuldade”.

A G&J Pepsi opera na estrutura de DevOps desde 2009 e adotou oficialmente DevOps como uma disciplina definida em 2018. “Como temos sido uma equipe enxuta e pequena, essa forma de trabalhar não foi necessariamente escolher encontrar uma definição formal de como trabalhar, mas mais uma necessidade para agregar valor à organização, sobreviver à tecnologia em constante mudança e concluir projetos”, afirma Balzer.

Levou muito tempo para criar um ambiente e uma equipe DevOps, incluindo treinamento e educação rigorosos. No outono de 2020 a empresa trouxe um coach ágil para avaliar seus processos e como a equipe estava trabalhando. “Isso foi muito valioso e, depois de alguns meses, reestruturamos a forma como organizávamos nossa equipe”, diz Balzer. A equipe progrediu e agora está funcionando perfeitamente no método DevOps.

“A equipe adotou essa nova forma de operar, suas cadências, e agora está começando a entregar”, diz Balzer. “Medimos nosso rendimento, nossa capacidade de fazer o storyboard e o valor que entregamos ao negócio. E o mais importante, estamos construindo credibilidade com a equipe executiva, melhoramos drasticamente o relacionamento com nossos parceiros de negócios e aumentamos a adoção dos produtos que implementamos em toda a organização”.