Preenchendo lacunas: a importância da comunicação DevOps

Embora a metodologia DevOps esteja conosco há algum tempo, ainda é o centro de discussões acaloradas. As empresas querem isso, mas não têm certeza de como abordá-lo.

O DevOps está em toda parte. E embora seja uma tendência interessante, deve ser ajustada aos produtos, e não o contrário.

Mas algumas pessoas não veem assim. Muitas vezes me fazem perguntas como: “Você acha que devemos começar a usar o Docker ou ir direto para o Kubernetes?” Essas perguntas não têm sentido mesmo sem saber do que se trata o produto.

Todos esses termos sofisticados – nuvem, Kubernetes, contêineres, gerenciamento de configuração, infraestrutura como código – prometem algumas melhorias. Mas eles estão para o DevOps assim como os telescópios estão para a astronomia. Eles podem ser úteis, mas não são necessários.

Em sua essência, o DevOps visa preencher a lacuna entre o que o cliente pediu e o que a equipe de desenvolvimento entregou. Há uma ênfase em ciclos de lançamento curtos, abordagem iterativa de design e automação de etapas repetitivas. O que você acha que é mais importante para trazê-los à realidade?

Se você disse “ótima comunicação”, acertou. As ferramentas estão todas boas. Mas eles só valem o dinheiro investido neles quando melhoram a comunicação.

Um aspecto da comunicação é saber o que é necessário para realizar o trabalho. E o trabalho não significa que “o código está comprometido com o repositório”. Pense nisso como “o cliente viu a mudança na produção e a aceitou”.

Assim que esse primeiro passo for determinado, e todos souberem o que precisa acontecer, esse é o melhor momento para anotá-lo. Onde? Bem, eu sou um grande defensor da manutenção de um README.md . Cada pessoa em uma equipe sempre pode espiar dentro dela e conhecer o estado de um projeto, e é uma escolha natural para os recém-chegados ao projeto.

A automação, o próximo passo após escrever um README, é opcional. É, no entanto, uma consequência natural da documentação do processo. E sim, a automação é o que muitas vezes vem à mente quando se pensa em DevOps.

Espere um minuto... a automação é opcional quando se trata de DevOps? O DevOps não é o departamento da pessoa que faz as implantações?

O que as pessoas geralmente entendem sob o termo “engenheiro de DevOps” é um engenheiro de confiabilidade de software, um engenheiro de plataforma ou um engenheiro de automação de operações. Essas são todas as funções válidas que permitem a prática de DevOps, mas usar o termo coletivo “engenheiro de DevOps” pode ser um pouco ambíguo.

Então, vamos dar uma olhada no próprio DevOps.

DevOps explicado

Primeiro, deixe-me mostrar o que o DevOps não é:

1. Não é apenas um prefixo de cargo
2. Não é uma equipe (mas “Dev” e “Ops”) são)
3. Não é uma tecnologia
4. Não significa “um administrador de sistema que pode codificar”
5. Não significa “automatizar coisas”
6. Isso não significa “não há equipe de operações agora”

Sabendo disso, agora você está ciente de que não pode simplesmente “contratar um engenheiro de DevOps” ou “criar uma equipe de DevOps” em uma empresa para garantir que você esteja preparado para o futuro. DevOps é semelhante ao desenvolvimento ágil. Você contrataria um desenvolvedor Agile como tal ? Provavelmente não. Ou você desenvolve o produto de forma ágil ou não.

Como então o DevOps pode ser descrito? É uma metodologia. Ou talvez uma cultura. Talvez até um espírito. Fazer um produto de acordo com os princípios do DevOps significa que todos – seja desenvolvedor, engenheiro de operações ou gerente de produto – compartilham uma visão comum, mantendo-a por meio da comunicação. Em menor grau, também significa que todos usam as mesmas ferramentas. Essas ferramentas não se destinam a ajudar nenhum grupo de pessoas. Eles são destinados a empurrar o produto para a frente.

Seguir com esse conceito requer uma séria mudança de mentalidade, que é o principal obstáculo. Por que é que? É porque as pessoas têm que sair de sua zona de conforto e começar a colaborar com pessoas que têm competências diferentes. De repente, os desenvolvedores precisam aprender como a nuvem funciona e começar a implantar seu próprio código. O pessoal de operações precisa abandonar as configurações manuais e começar a codificar. Todo mundo precisa aprender novos conceitos. Todos têm novas responsabilidades .

Isso não é fácil, mas com uma boa comunicação e um objetivo comum, é bastante viável. Essa comunicação envolve estabelecer uma cultura, configurar processos leves e manter a documentação adequada.

Automação DevOps é Documentação

Você provavelmente nunca pensou dessa forma. Mas a maioria das ferramentas comumente associadas ao DevOps são ferramentas de documentação :

• Scripts de construção escritos para legibilidade servem para documentar o processo de construção
• Os pipelines de integração contínua documentam o processo de integração, desde a criação de peças únicas até um produto inteiro
• Os pipelines de implantação contínua vão além, documentando como implantar um produto que seu cliente pode usar
• Os arquivos de gerenciamento de configuração documentam o processo de instalação e configuração
• As especificações de infraestrutura como código documentam a infraestrutura necessária (bem formalmente, na verdade!)
• Os contêineres vêm com seus próprios Dockerfile que documentam como construir e configurar um determinado microsserviço

Todos esses conceitos extravagantes fazem basicamente uma coisa: eles ajudam os membros da equipe a se comunicarem melhor documentando os processos. Esses processos podem ser executados manualmente ou automatizados. O importante é que todas as partes interessadas em um projeto sejam capazes de acompanhá-los.

Documentar seus processos como código tem uma grande vantagem sobre os manuais de instruções usuais. O código pode ser verificado e se comporta de forma preditiva. Dada a mesma entrada, produz a mesma saída.

Com instruções escritas, você terá tantas interpretações quanto leitores. Se você escrever uma documentação ambígua ou vaga, a pessoa que a ler preencherá as lacunas. A questão é que você não tem controle sobre o que vai para as lacunas.

É muito mais simples com código. Sem passos concretos, o programa deixará de funcionar. Essas etapas concretas são um aspecto fundamental da comunicação do DevOps.

Comunicação DevOps: a única maneira de preencher a lacuna entre desenvolvimento e operações

No livro The Phoenix Project, testemunhamos os problemas de um gerente recém-promovido encarregado de implantar um grande projeto. Como ninguém sabe o que está acontecendo, todos estão combatendo incêndios sem muito progresso. O subtítulo do livro menciona que é um conto de DevOps. Eu concordo com isso.

Mas o interessante é que, ao longo do livro, nenhuma nova ferramenta é apresentada. Você pode alcançar um estado de DevOps melhorando a comunicação sozinho? Os protagonistas do livro fizeram isso, então há esperança para você também!

Mesmo que a abordagem dos protagonistas possa ser considerada “old school” (usando cartões de papel reais em vez de um sistema de rastreamento de bugs adequado), as coisas começam a mudar para melhor apenas quando todas as partes envolvidas começam a conversar entre si.

Você pode pensar que só é possível melhorar a colaboração entre desenvolvimento e operações criando melhores interfaces entre eles, como acordos de nível de serviço ou pendências de incidentes. Mas o oposto é verdadeiro. Ao derrubar as interfaces e introduzir empatia e uma causa comum, você terá uma equipe que trabalha em direção a um objetivo comum.

Estrutura da equipe DevOps: quem está em uma equipe?

Idealmente, cada produto deve ter apenas uma equipe: a equipe do produto.

Certa vez, eu estava em uma equipe de desenvolvimento onde não havia um objetivo comum com outras equipes. A equipe de desenvolvimento queria fazer o máximo de mudanças possível. A equipe de validação foi encarregada de prevenir a introdução de defeitos. Eles tinham gestores diferentes e eram avaliados individualmente.

O resultado? Desenvolvimento e Validação jogou pingue-pongue com relatórios de defeitos. Quando a Validação encontrou um teste que não passaria, o Desenvolvimento estava mais interessado em encontrar falhas no próprio código de teste do que em tentar tornar seu próprio código livre de bugs.

O ciclo de liberação aumentou, é claro, pois havia uma enorme sobrecarga necessária para preencher adequadamente os relatórios, os contra-relatórios e assim por diante. O que a maioria parecia não reconhecer era que, em termos de produto, ambas as equipes deveriam compartilhar um objetivo comum e trabalhar em conjunto para alcançá-lo. Mas a falta de cooperação adequada e mentalidade de silo tornou muito difícil perceber.

Combater o desperdício é um esforço conjunto

A mentalidade de produção enxuta que inspirou The Manifesto for Agile Software Development (que, por sua vez, nos apresentou ao DevOps) era sobre combater o desperdício. Por desperdício, queremos dizer tudo o que não é diretamente relevante para o que o cliente encomendou. O trabalho em andamento empilhado é um desperdício. Cada etapa de um processo que não leva claramente à liberação é um desperdício.

Mas o desperdício só pode ser visto de alto nível. No âmbito de uma equipe, alguns procedimentos podem parecer essenciais. Do ponto de vista do produto, porém, eles podem ser inúteis.

Para descobrir quais esforços são desperdiçados, você precisa unir forças e considerar o ciclo de vida de um produto enviado. Você também precisa pensar a partir da perspectiva do cliente. Esse recurso é algo que o cliente queria? Se não, você também pode ignorá-lo neste momento. Seus processos são simples e enxutos? Dê uma olhada mais profunda, especialmente naqueles que cruzam os limites da equipe.

Você quer garantir que o desenvolvimento de um produto seja o mais eficiente possível? Convide alguém de fora para ver como você trabalha. Uma pessoa que não faz parte de sua equipe poderá fazer perguntas perspicazes e identificar novas áreas de melhoria.

Princípios de DevOps: mantenha sua CALMA(S)

CALMS é uma descrição muito precisa de como se deve praticar DevOps:

• Cultura
• Automação
• Lean
• Medição
• Compartilhamento

Observe que é formado como um sanduíche. Os três valores intermediários são mais técnicos, enquanto os externos estão relacionados às habilidades sociais. Mas a base de toda cultura é a comunicação: trocamos nossos valores e crenças com outros membros da equipe até chegarmos a um consenso sobre como as coisas devem se comportar.

O mesmo acontece com o compartilhamento. Compartilhar algo básico como comida não requer comunicação. O gesto em si, no entanto, também pode ser visto como um ato de comunicação. “Eu me importo com você, então compartilho com você.” Não queremos limitar o escopo apenas à comunicação verbal.

Compartilhar ideias e ferramentas, no entanto, requer comunicação. Como devemos compartilhá-los? Onde devemos colocá-los? Eles são úteis para todas as pessoas em uma equipe ou apenas para um grupo menor?

Se você se concentrar apenas nos aspectos mais técnicos – Automação, Lean e Medição – você está perdendo o foco do DevOps. O que há de tão bom em ter um script de implantação automatizado que ninguém usa além do autor? Se o script lhe poupar algum tempo, isso pode ser justificado. Mas imagine quanto tempo poderia ser economizado se todos compartilhassem esse script. Isso diz algo sobre a luta contra o desperdício!

DevOps aproxima os negócios do desenvolvimento

Alguns dizem que o DevOps aproxima as operações do desenvolvimento. Isso é verdade, mas não é toda a verdade. Quando bem feito, o DevOps aproxima cada unidade. Ele permite que empresas e clientes vejam o que o desenvolvimento está fazendo, quase em tempo real.

Esse ciclo de feedback mais curto beneficia todas as partes interessadas. O trabalho geralmente é mais visível e os desenvolvedores também podem ver facilmente como os clientes usam o código que produzem. Com a implantação tradicional, você pode esperar vários meses antes que alguém perceba bugs ou requisitos perdidos. Com a implantação contínua, todos podem reagir a quaisquer problemas à medida que surgem. Desenvolvedores, operações, negócios e clientes podem se sentar em uma sala e modificar o aplicativo de trabalho de acordo com as necessidades atuais.

Ferramentas DevOps primeiro? Pense de novo

Claro, há uma necessidade de todas as ferramentas para tornar isso possível.

Mas nenhuma quantidade de ferramentas pode substituir uma boa comunicação e empatia dentro da empresa. Certa vez, observei um produto em que o processo de construção pertencia a uma equipe, enquanto o código fornecido pertencia a outra.

Problemas com o sistema de compilação eram comuns. Os desenvolvedores não tinham certeza de como usá-lo. Foi baseado em ferramentas padrão, mas foram customizadas a ponto de toda documentação disponível na web se mostrar inútil.

Todos queriam melhorar a situação, mas não havia entendimento entre as duas equipes. Isso significava que ambos os lados introduziram novas ferramentas sem consultar o outro lado. Isso apenas ampliou a lacuna, em vez de fechá-la.

Se você deseja iniciar uma transformação de DevOps em sua organização, comece melhorando a maneira como você se comunica. Não assuma simplesmente uma solução: faça um brainstorming com a mente aberta primeiro . Então você pode descobrir que, por exemplo, o suporte de ferramentas é insuficiente para suas necessidades. É quando você pode considerar ajustar suas ferramentas atuais ou introduzir algumas novas – caso contrário, você provavelmente estará aumentando o problema original.

A maneira mais rápida de estabelecer DevOps? Melhor Comunicação!

Na introdução, mencionei a pergunta que os clientes costumam me fazer: “Devo ir com o Docker ou devo pular direto para o Kubernetes?” Depois de ler este artigo, você pode ver que essa pergunta é melhor respondida depois de fazer algum trabalho de preparação – com uma mentalidade de DevOps.

Se você sabe que sua equipe de produto entende os benefícios do DevOps para si e para o cliente, a equipe e o cliente podem começar definindo suas expectativas. Em seguida, os engenheiros podem descobrir o modelo de desenvolvimento e implantação. Finalmente, você pode determinar quais ferramentas são necessárias.

Uma vez que todos os requisitos são documentados, as escolhas de tecnologia são muito mais fáceis de fazer.

Sou um defensor de todas as excelentes ferramentas de automação de DevOps que tornam nosso trabalho mais fácil e gerenciável. Mas nosso trabalho diário é trabalhar com pessoas . Vamos investir algum tempo para melhorar esse aspecto das práticas recomendadas de DevOps, em vez de obter outro certificado de tecnologia.