Recursos/White Papers

Tecnologia

O lado negro do DevOps

Cenários ideais raramente acontecem na vida real, e com o DevOps não é diferente. Saiba como a implementação dessa filosofia pode fracassar e como evitar os desastres

Josh Fruhlinger, CIO/EUA

Publicada em 09 de outubro de 2018 às 08h40

O DevOps é uma filosofia organizacional cada vez mais popular que aumenta a colaboração entre a equipe de desenvolvimento e a de operações - talvez até combinando-as em um único departamento - e prescreve integração constante e entrega contínua (CI/CD) de novos códigos, com recursos de software incrementados a cada poucos dias ou semanas, em vez de desencadeadas como enormes atualizações monolíticas. Em teoria, isso torna o desenvolvimento mais ágil e reduz o conflito interno.

Evidentemente, a teoria nem sempre funciona na prática. Falamos com pessoas que ajudaram a desenvolver o DevOps no mundo real para descobrir o lado obscuro da filosofia - tanto os problemas inerentes a ela quanto as formas pelas quais seus implementadores frequentemente ficam aquém ou fracassam. Esperamos que esses contos preventivos o ajudem a entrar em qualquer distribuição com os olhos abertos.

DevOps é mais que um conjunto de ferramentas
Ernest Mueller, no site Agile Admin, define o que descreve como "Ferramentas DevOps":

"No mundo DevOps houve uma explosão de ferramentas (jenkins, travis, teamcity), para gerenciamento de configuração (puppet, chef, ansible, cfengine), orquestração (zookeeper, noah, mesos), monitoramento, virtualização e conteinerização (AWS, OpenStack, vagrant, docker) e muito mais. Embora, como acontece com o Agile, seja incorreto dizer que uma ferramenta é “uma ferramenta de DevOps” , certamente existem ferramentas específicas sendo desenvolvidas com o objetivo expresso de facilitar a aplicação dos princípios, métodos e práticas, e uma compreensão holística do DevOps deve incorporar essa camada.

Infelizmente, tratar essas ferramentas ou outros como um totem que "implantarão o DevOps magicamente" é exatamente o que muitas empresas fazem, deixando de lado o esforço necessário para mudar processos ou mentalidades. "Mike", que trabalhou como CTO de uma empresa de tecnologia de médio porte durante a tentativa de mudança para o DevOps, descreve esse tipo de visão "cult". "Eu culpo a visão dos engenheiros", diz ele, "porque engenheiros de software olham para problemas com soluções de software. Olham para o DevOps como um conjunto de tecnologias a serem instaladas em muitas aplicações. Isso é um grande erro".

A transição para o DevOps, no fim das contas, foi repleta de fracassos, e ele atribui grande parte da culpa a essa falha original de compreensão, até mesmo dos objetivos do projeto. "Se o DevOps não é software, é o quê, então?" pergunta Mike.  "Olhando para trás, me sinto idiota por não notar. DevOps é uma cultura. Mudar cultura é uma das coisas mais difíceis que uma organização pode fazer. As pessoas - e talvez os engenheiros, em particular - são naturalmente desafiadoras. A cultura deve ser cultivada em toda a empresa. "

Nem todo mundo vai estar a bordo
E isso nos leva ao nosso próximo lado negro do DevOps. O sonho é que a sua equipe de tecnologia esteja ansiosa para entrar na nova filosofia e maneira de fazer as coisas que o DevOps propõe. A realidade é que a mudança é difícil, e muitas pessoas não vêem nada de errado com o trabalho que já estão fazendo e com a maneira como o fazem. Cody Swann é o CEO da Gunner Technology, uma empresa de desenvolvimento de software que ajuda organizações do setor público e privado a migrar para o DevOps - e ele já viu de tudo quando se trata de resistência, com alguns funcionários tomando medidas ativas para dificultar a transição. Por exemplo, em uma tarefa, os funcionários questionaram a viabilidade da nova infraestrutura que estavam propondo. "A equipe de operações tentou argumentar que os microsserviços são uma moda passageira", disse ele, "e não são".

As coisas não melhoraram necessariamente quando mudaram para a implementação. "Nós estávamos desmembrando uma enorme infraestrutura/aplicativo .NET monolítico em microservices JavaScript baseados em AWS Lambda", diz ele. "Parte disso incluiu a migração de dados do Oracle para uma solução DynamoDB/Elasticsearch." A pegada? "A equipe de operações local assumiu a posição de que era impossível nos conceder acesso ao banco de dados Oracle para migração dos dados. As desculpas eram obviamente inventadas - eles alegavam que o banco de dados estava disponível apenas para endereços IP internos, por exemplo".

Na transição de Mike, as coisas ficaram ainda piores, porque acabaram desafiando o senso profissional de alguns funcionários. "Em uma cultura de DevOps, as dores de implantações ruins e falhas de produção são sentidas diretamente pelos engenheiros que construíram o sistema", diz ele. "Em uma abordagem tradicional de duas equipes, a de operações assumem a tarefa de corrigir erros de produção. O pessoal de operações gosta disso. Corrigir um erro de produção e retornar o serviço a um estado totalmente funcional é o objetivo.' Mas a transição para o DevOps, independentemente de seus outros benefícios, "muda tudo isso", explica Mike. O resultado? "Metade do pessoal de operações abandonou o projeto."

A segurança, como sempre, é um problema
O DevOps pode não ser mais inseguro do que outras filosofias organizacionais, mas sua implementação pode causar problemas de segurança de maneiras novas e desafiadoras. "Com integração, implementação e entrega contínuas como principais impulsionadores do DevOps, uma grande parte das boas práticas de segurança é muitas vezes automatizada ou excluída do processo devido ao impacto na velocidade de lançamentos", explica Davy Hua, chefe de DevOps na  ShiftLeft. "Como resultado, o aumento da velocidade de lançamentos muitas vezes produzirá códigos inadequadamente controlados, o que pode levar a um vazamento de dados sensíveis inadvertidamente em logs de endpoints, ou herdar vulnerabilidades de bibliotecas de software de terceiros, como foi o caso da violação da Equifax." 

"Se a aplicação é monolítica ou dividida em vários microsserviços, as complexidades entre os fluxos de dados exigem uma grande compreensão, a fim de implementar um programa de segurança eficaz", continua Hua. "Acoplar as complexidades com restrição de tempo, outro fator para acelerar os lançamentos, resultará em um certo nível de negligência quando se trata de fiscalização de segurança".

Igor Livshitz, diretor de gerenciamento de produtos da GuardiCore, vê a segurança se tornando um problema particular no DevOps.

"No mundo atual de instâncias de curta duração, microsserviços e infraestruturas híbridas, qualquer ponto único de controle baseado em humanos é falho", explica ele. "Assim, o controle de políticas é transferido para os desenvolvedores como parte de um modelo de responsabilidade compartilhada. Os desenvolvedores descrevem a política necessária que deve ser aplicada a seus aplicativos e os administradores de segurança de rede podem analisá-la e aplicar ferramentas de auditoria e monitoramento para garantir que não haja violações. Dessa forma, todas as partes estão satisfeitas: DevOps e desenvolvedores podem se mover rapidamente sem esperar por uma luz verde e os administradores de segurança  garantem a implementação de políticas rígidas criadas por proprietários de aplicativos que precisam apenas ser auditados. "

Muitas vezes esse cenário ideal não acontece na vida real. "Tudo isso pode ser quebrado se houver falta de confiança entre as funções de segurança e DevOps na organização. Nos casos analisados, ambos geralmente fazem parte de unidades de negócios separadas, e estão fazendo isso por anos - o partidarismo está enraizado no DNA da empresa.A desconfiança pode ter se originado de um incidente de segurança que aconteceu devido à falta de conhecimento em um ou ambos os lados que levou à paralisação do aplicativo ou dos serviços devido ao "bloqueio" das equipes de segurança. " Para a Livshitz, a chave para evitar isso é criar confiança entre as equipes e “integrar os controles de segurança necessários como parte do ciclo de DevOps - controles que devem ser definidos pelas equipes de segurança.

devops

Mova-se rapidamente, mas não depressa demais
O ponto principal de mudar para o DevOps é que você acaba produzindo atualizações úteis de software muito mais rapidamente. Mas muitas vezes as equipes acham que sua mudança para o DevOps deve ocorrer com a mesma rapidez - com resultados desastrosos, especialmente se a mudança cultural da força de trabalho não tiver a chance de acompanhar o ritmo. O resultado pode ser uma espécie de Frankenstein. Ed Price, diretor de conformidade do Devbridge Group, dá um exemplo de alguns sinais de alerta: "Se as empresas ainda veem migrações de código manuais e colocam manualmente o código em produção. Se ainda dependem de uma equipe de ambientes. Se não virem nenhuma unidade automatizada, regressão, ou testes de desempenho incorporados em seu pipeline CI para impedir que o código que ainda não está pronto chegue ao mercado."

Também leva tempo para obter o mix de pessoal que você precisa para uma boa equipe de DevOps.  "É comum as organizações identificarem os 'astros de rock' estereotipados - os membros de alto desempenho da equipe, como seleções para qualquer nova iniciativa", diz Justin Rodenbostel, vice-presidente de desenvolvimento de aplicativos de código aberto da SPR. "No entanto, a construção de equipes baseadas estritamente em perícia técnica ou experiência nos assuntos de negócio pode sair pela culatra se outras habilidades como colaboração e comunicação não forem consideradas."

Se há uma lição a ser aprendida com tudo isso é a de que as pessoas são o fator mais importantes para determinar se o seu projeto de DevOps vai para o lado sombrio ou para o lado da luz. 



Reportagens mais lidas

Acesse a comunidade da CIO

LinkedIn
A partir da comunidade no LinkedIn, a CIO promove a troca de informações entre os líderes de TI. Acesse aqui