Sete hábitos de DevOps de sucesso

DevOps é uma empreitada que vale a pena, já que produz uma compreensão mais profunda entre a equipe de desenvolvimento e a de operações de TI. No entanto, talvez seja apenas uma fraude criada pelos charlatões no fim do corredor.

Esses parecem ser os dois polos de desentendimento em relação à DevOps, sugerem os analistas da Forrester Research, Glenn O?Donnell e Kurt Bittner. Eles publicaram um relatório na última terça-feira, ?Os sete hábitos de DevOps altamente eficientes?.

Inicialmente, o relatório soa um pouco como aquela famosa fala do filme Cool Hand Luke (1967): ?O que temos aqui é uma falha na comunicação?. O?Donnell e Bittner apontam que um líder de TI que deseja implementar DevOps deve esclarecer alguns mal entendidos. No passado, o que a equipe de desenvolvimento produzia nem sempre se dava bem em operações, e o feedback oferecido pela equipe de operações era visto como hipercrítico pelos desenvolvedores. ?Os resíduos de estereótipos acumulados e reforçados são destrutivos para a harmonia da organização?, alertam os autores em uma seção chamada ?Estereótipos negativos limitam seu negócio?.

Mas a introdução de DevOps não é primeiro rodeio para uma legião de profissionais de TI. Eles têm muita experiência em que baseiam sua visão de inadequações sobre o outro lado. Essa rixa existe há muito mais tempo do que se imagina.

Os sete hábitos, no entanto, não são apenas sobre melhores relações públicas. Os autores, com muita habilidade, resumiram como cada lado isolado vê o outro lado.

Desenvolvedores veem operações como profissionais comprometidos com seus sistemas obsoletos e incapazes de se adaptar às demandas dos desenvolvedores. Eles são, basicamente, burocratas que gostam de dizer ?não? em vez de mudar. A incompetência deles leva ao fracasso do mais recente código de aplicativo criado pela equipe de desenvolvimento, ferindo, assim, a credibilidade da equipe. O aplicativo não funcionou direito porque a equipe de operações ?não é criativa o bastante para compreender a complexidade artística dos aplicativos?. A equipe de operações está, constantemente, ?remendando coisas ? não é engenharia?. Desenvolvedores teriam muito mais êxito se pudessem driblar operações e ir trabalhar na nuvem.

A caracterização sobre como os profissionais de operações veem a equipe de desenvolvimento segue o mesmo padrão.

Desenvolvedores querem acreditar que tudo é possível e não têm noção do quanto custa para a TI atender suas demandas. Eles gostam de ?brincar com os brinquedinhos mais novos?. As equipes ?entregam códigos ruins que afetam negativamente a credibilidade das operações?. Seus ambientes de testes não testam o que deveriam ? a habilidade do aplicativo em se manter em produção. Os desenvolvedores são ?descuidados, carentes de disciplina… um bando de hackers, não são profissionais reais?. A equipe de operações tem de realizar tarefas heroicas dia após dia para manter códigos rodando. Poderia ter muito mais êxito driblando a área de desenvolvimento e usando SaaS e softwares prontos para o uso.

As duas caracterizações são estereótipos. Existe alguma dúvida de que há um abismo, muitas vezes do tamanho do Grand Canyon, na comunicação dos dois grupos? Como se coloca essas duas áreas juntas em uma organização DevOps? Como se faz para que desenvolvimento produza códigos que funcionem da forma como as operações esperam? Como se faz para que a equipe de operações ajude a equipe de desenvolvimento a produzir o código que precisa sem atacar seus modos ?descuidados??

Não surpreende que a lista dos sete hábitos de DevOps de sucesso comece com um esforço para que os dois lados conversem. É um clichê, mas conversar cara a cara quebra estereótipos e permite que cada lado veja as dificuldades e batalhas travadas pelo outro lado todos os dias. Não é um insight tão profundo, mas é um primeiro passo necessário.

?Adote uma abordagem de fora pra dentro para tudo?, aconselham os autores como hábito número dois. O pensamento tradicional da TI é de dentro para fora: ?Eis o que a TI tem de recursos pra fazer e o que nós fizemos. Use isso da melhor forma possível?. Em vez disso, os dois lados focam nos clientes do negócio e no que deveria ser feito para satisfazer as necessidades deles. Aquele aplicativo ficou 10 horas fora do ar na semana passada? Isso não é bom para o cliente. O que precisamos fazer para produzir mais estabilidade em código de produção?

O hábito número três é automatizar os processos de criação, teste e lançamento, para que contenham menos erros humanos. Para que os testes funcionem, eles devem incluir testes de escalabilidade nos sistemas em que o aplicativo irá rodar, assim como testes de função de negócio, ponto em que as equipes tradicionais de desenvolvimento destacam-se.  Puppet e Chef hoje capturam e ajudam a automatizar configurações e desenvolvimentos; use-os. (Os autores da pesquisa não mencionam Puppet e Chef especificadamente).

Toda a infraestrutura de datacenter deve ser reforçada para entregar serviços por um ambiente mais padronizado. O processo será longo, com usuários do negócio e desenvolvedores perdendo alguns de seus melhores e preferidos sistemas em favor dos sistemas suficientemente bons, como Windows e Linux. Os caminhos antigos levavam à sempre crescente complexidade, e essa complexidade vinha acompanhada por uma crescente fragilidade. Assim, o hábito número quatro consiste em simplificar e padronizar o ambiente de produção e desenvolvimento. Reforce, rigorosamente, essa simplificação em novos aplicativos.  Então, simplifique os aplicativos legados o máximo que puder. É uma tarefa impactante.

O número cinco é introduzir gradualmente uma cultura de engenharia de sistemas tanto em operações quanto em desenvolvimento. ?Engenharia real funciona de forma disciplinada e atenciosa para reduzir soluções a serem ? como recomendou Albert Eistein ? o mais simples possível, mas não mais simples?. Construir software com base em módulos simples torna mais fácil implementar e manter, e reutilizar.

O hábito número seis, de acordo com os autores, é a implementação de um loop de feedback e feed-forward. Softwares são complexos e exigem feedback sobre como estão operando. Muitas vezes, desenvolvedores não sabem.

Verificadores e operadores estão, geralmente, engajados apenas no final do projeto. Eles precisam ser envolvidos mais cedo. Da mesma forma, informações que expliquem como um aplicativo deve funcionar, como informações de mapeamento de dependências, precisam ser entregues mais cedo para equipes de operações e desenvolvimento que podem estar trabalhando em um próximo aplicativo semelhante.

O sétimo e último hábito coloca desenvolvedores na linha de frente de suporte. Eles não querem estar ali. Isso os tira do processo criativo do desenvolvimento de outros códigos, o lugar onde sua reputação já foi assumida. Mas os desenvolvedores que criam o código terão melhor compreensão sobre os motivos pelos quais o aplicativo está rodando com deficiência na produção e podem conserta-lo rapidamente. E, obviamente, os desenvolvedores irão aprender muito sobre produção conforme assistem seus códigos rodarem no ambiente alvo.

Esses sete hábitos não deve ser nenhuma surpresa para as pessoas que já passaram pelas dificuldades de DevOps e conseguiram chegar a uma equipe de TI de função combinada.

Mas serão vistos como educacionais por equipes mais tradicionais, que estão confortáveis em isolamento. Esse isolamento inclui um pouco de proteção contra ser retirado da zona de conforto e colocado numa situação em que algo mais é esperado de você.

O Facebook automatizou configuração e implementação de software em 17 mil servidores usando um servidor Chef, de acordo com os autores. Isto porque a empresa foi capaz de construir do zero um ambiente simplificado e padronizado. O que uma DevOps ganha com automação é auto evidente.

A Amazon está constantemente atualizando seus sistemas de produção sem medo de prejudicar, involuntariamente, suas operações. A empresa faz isso por meio de um procedimento de teste automatizado em um ambiente que simula o ambiente de produção.

Jon Jenkins, diretor de análise de plataforma da Amazon, declarou durante o evento Velocity, em 2011, que estavam implementando código para produção ?a cada 11.6 segundos?, geralmente em 10 mil servidores pode vez. Em um departamento normal de TI, tais implementações seriam suicidas, considerando que as principais interrupções são devido a atualizações de software. O que uma DevOps ganha em confiabilidade de produção são auto evidentes.

A Etsy implementa novas funções online com apenas um profissional de TI trabalhando, graças ao rigor de desenvolvimento de novos códigos pela DevOps. Cada adição é cuidadosamente testada e lançada quando pronta, em vez de planejarem uma grande equipe de atualização de sistema uma ou duas vezes por ano.

O ponto da DevOps é fazer com que ambas as equipes tratem suas responsabilidades como uma ciência e reduzam a quantidade de ciência fictícia envolvida no relacionamento delas.