Considerado por muitos a próxima etapa do Agile, o DevOps teve sua eficácia comprovada na aceleração dos ciclos de desenvolvimento, melhorando o desempenho, reduzindo os bugs e proporcionando melhorias gerais à inovação e à velocidade das equipes de desenvolvimento.

Existem algumas maneiras de encarar o DevOps: primeiro, o DevOps é uma metodologia de desenvolvimento baseada na integração e na entrega contínuas, com o respaldo de um conjunto de ferramentas de gerenciamento de configurações, como Chef, Puppet, Salt e Ansible. Também podemos pensar no DevOps como um conjunto mais simples de princípios que orientam as práticas de desenvolvimento e implantação: automatizar, monitorar e registrar tudo em log. Tudo com a meta de obter visibilidade de como cada alteração em um processo iterativo acelerado afeta o desempenho.

O desafio – além da complexidade envolvida na implementação dessas ferramentas, da criação de scripts e da transformação de todo o processo de desenvolvimento – é que o DevOps exige uma mudança de cultura e um novo conjunto de habilidades. Assim, a principal pergunta é: por onde começar? Como as equipes podem começar a desfrutar dos benefícios do DevOps sem precisar esperar meses ou anos até que as novas habilidades, ferramentas e processos estejam prontos e a nova cultura tenha se arraigado?

Noções básicas

Talvez, o melhor lugar para se começar seja pelas noções básicas. A ideia central por trás do DevOps é que os desenvolvedores e as equipes de operações devem trabalhar juntos, colaborando em tempo real para fornecer aos desenvolvedores informações sobre como os aplicativos são executados, a fim de melhorar o desempenho à medida que os aplicativos são criados. Assim, um aspecto essencial do estabelecimento de uma cultura de DevOps é proporcionar às equipes de desenvolvimento e operações visibilidade da execução dos aplicativos e dos congestionamentos de desempenho. Todo grande líder compreende que as equipes trabalham bem juntas quando têm um propósito compartilhado e um entendimento em comum da realidade. O que isso significa no âmbito do desenvolvimento de aplicativos é que, para que o DevOps tenha um impacto, todos devem chegar a um acordo quanto a uma única versão da verdade, o que proporciona um entendimento comum do que está funcionando e do que não está.

Embora isso pareça simples, a realidade é que, com bastante frequência, as diferentes equipes que trabalham em aplicativos estão organizadas em silos, sendo que cada equipe executa seu próprio painel e tem sua perspectiva única de uma parte específica da pilha de aplicativos. O resultado é a troca de acusações e problemas que se ocultam no espaço entre os silos e nas interdependências entre os componentes da pilha de aplicativos.

Um grande primeiro passo rumo ao DevOps é trabalhar no sentido de proporcionar uma única versão da verdade para essas equipes – uma estrutura comum em que todos os membros da equipe possam compreender o que acontece nos sistemas de aplicativo, banco de dados, sistema operacional, hipervisor, servidor de host e armazenamento. Esse sistema elimina a troca de acusações determinando com clareza onde estão os problemas, o que elimina a ambiguidade, restando apenas a ação.

Como implementar

Com isso em mente, apresentamos cinco recomendações para implementar uma cultura de DevOps em sua organização:

1. Proporcione aos desenvolvedores uma visibilidade direta do monitoramento dos servidores de produção, preparo e teste. Até que o desenvolvedor veja o comportamento efetivo do código aplicado a bancos de dados carregados, ele não sabe como o aplicativo se comportará de fato.
2. Torne as equipes autossuficientes com relação às observações que fazem do desempenho, eliminando gatekeepers e silos de informações de desempenho. Quando os desenvolvedores têm informações diretas sobre o desempenho, a interação deles com as operações são construtivas e eles não precisam implorar por informações.
3. Torne o desempenho um requisito explícito logo de saída. Por muito tempo, o desempenho foi considerado algo secundário, com que se deve lidar apenas quando as especificações funcionais tiverem sido atendidas. Tornar requisitos de desempenho específicos uma parte essencial do processo de design, com testes e avaliações de desempenho logo no início do ciclo de desenvolvimento, garante que eles não tenham que ser acrescentados posteriormente.
4. Estabeleça métricas compartilhadas, de modo que o desenvolvimento, a produção e a gerência tenham uma base para comparação dos resultados, avaliação do progresso e rastreamento do impacto das alterações. Quando os engenheiros de software e de sistema têm uma base comum para discussão e avaliação do progresso, estão em melhor posição de trabalhar por uma meta comum.
5. Concentre o foco na experiência do usuário final, seja este um cliente externo ou o responsável por um aplicativo em uma unidades de negócio interna. Quando a TI se volta para o serviço, o nível de serviço proporcionado ao cliente torna-se a única métrica realmente importante para avaliação do departamento de TI. Com a meta comum de proporcionar um serviço responsivo e previsível para aplicativos de usuário final, tanto a produção quanto o desenvolvimento podem colaborar para o cumprimento da meta comum.

Mas isso não é tudo

Há mais duas considerações importantes. Primeiro, somente as ferramentas de monitoramento não são suficientes. O monitoramento baseado em integridade fornece o status ativo/inativo, em geral com foco em indicadores de status verde, amarelo ou vermelho para dezenas ou centenas de componentes. Eles são úteis para identificar quando algo não funciona, mas são muito limitados para identificar a causa raiz de problemas e na correlação entre componentes. Um sistema pode ser totalmente ineficiente e, mesmo assim, o painel de monitoramento mostrar apenas luzes verdes, já que nada em especial está avariado. Por isso, é importante olhar para um sistema com uma visão de desempenho, para compreender os tempos de espera e os congestionamentos.

Segundo, muitas equipes de DevOps tentam monitorar tudo. O resultado são logs de mais de um gigabyte que exigem ferramentas avançadas e muito tempo de análise. Embora os gráficos produzidos possam ser muito interessantes, sua utilidade é limitada à capacidade de produzir informações. Um terabyte de dados de log é algo inútil, a menos que possa especificar o que há de errado com o sistema.

Conclusão

Para resumir, as equipes de desenvolvimento e de operações podem trabalhar melhor em conjunto quando:

• Compartilham uma mesma visão do sistema, que fornece visibilidade de todas as camadas da pilha e das dependências entre elas.
• Estão voltadas para o desempenho e seu foco se concentra em localizar congestionamentos e informações que resultem em ação.

Mesmo sem a complexidade de um sistema completo de gerenciamento de configurações, partir das metas corretas e contar com um ferramental de desempenho eficaz pode deixar você um passo mais próximo do nirvana do DevOps, o que significa aplicativos mais rápidos e inovação acelerada.