Entendendo o DevOps

Quer você esteja mantendo a infraestrutura da sua empresa em funcionamento, dando suporte a clientes nos seus problemas de TI, construindo, testando ou corrigindo softwares, ou mantendo seus colegas protegidos contra ameaças de segurança, provavelmente já se deparou com o DevOps.

Afinal, o termo existe há 15 anos e sua adoção aumentou exponencialmente. No entanto, isso não significa que sua definição, posicionamento e aplicação tenham sido universais. Isso levou a muitas corrupções semânticas, como BizDevOps, DevSecOps, AIOps, NoOps, FinOps etc. Tudo isso aumenta a confusão sobre o que é DevOps e sua relevância para qualquer pessoa no ecossistema digital. Dessa maneira, vamos dedicar algum tempo para descobrir os fundamentos, princípios e verdades ocultas por trás do DevOps, ok?

Como tudo começou

Primeiramente, vamos começar com uma definição comum do que é DevOps. Esta pergunta simples por si só pode levar a inúmeras horas de debate, brigas ou até mesmo guerras religiosas. Então, sem dúvida, vamos voltar à fonte para obter uma resposta sólida e confiável. Isso nos leva a Patrick Debois, que cunhou o termo pela primeira vez em 2009, ao organizar os primeiros DevOps Days em Ghent, Bélgica. A frustração de Debois como administrador de sistemas, sofrendo com a falta de colaboração na cadeia de entrega de tecnologia, foi o ponto de partida para o movimento global DevOps. O muro de confusão surgiu como uma metáfora dolorosa para falta de empatia, compartilhamento e colaboração eficaz, principalmente visível entre o desenvolvimento e as operações.

Uma de suas melhores citações sobre a definição de DevOps foi, "DevOps é tudo o que você faz para superar o atrito entre silos. Todo o resto é pura engenharia".

Esta abordagem muito ampla do DevOps ilustra sua visão holística e aplicabilidade, bem como a filosofia subjacente. Embora o próprio termo sugira um escopo restrito apenas para desenvolvedores (dev) e operadores (ops), o principal fator para iniciar tudo foi melhorar a colaboração e o fluxo em todos os silos relevantes, incluindo negócios, segurança, qualidade ou suporte. Portanto, entender por que este desejo subjacente resultou na eventual adoção do DevOps como o principal veículo de mudança organizacional, cultural e tecnológica é muito mais relevante do que procurar um nome melhor e mais abrangente.

DevOps NÃO é o objetivo

Agora que sabemos como definir DevOps, também devemos entender que ele não é o objetivo em si. Quer vejamos o DevOps como um conjunto de práticas, princípios ou até mesmo uma construção sociotécnica, trata-se apenas de um meio para atingir os objetivos subjacentes. A comunidade ativa do BVSSH nos forneceu um conjunto lógico de objetivos primários: Melhor Valor Mais Cedo Mais Feliz (Better Value Sooner Safer Happier - BVSSH). Em outras palavras, as práticas e princípios do DevOps podem nos ajudar a obter o valor ideal, melhor qualidade, entregas mais seguras, feedback mais rápido e clientes e funcionários mais satisfeitos. Você não está acertando se considera que está fazendo DevOps, mas isso não leva a nenhum desses objetivos subjacentes.

Na última década, muitas adoções de DevOps não conseguiram agregar o valor desejado. A prática tem mostrado que um dos principais motivos do fracasso das transformações de DevOps é porque nós a chamamos assim. Esta necessidade de rotular novas iniciativas retirou o nosso foco dos objetivos (de negócios) subjacentes, como clientes mais satisfeitos ou entregas de alta qualidade.

As três maneiras/three ways de DevOps

Apresentada no livro The Phoenix Project no início da década anterior, a promessa do DevOps é construída em três maneiras: Fluxo, feedback e aprendizagem e experimentação contínuas.

1. Primeiro Princípio/First Way: Fluxo/Flow

O Primeiro Princípio/First Way centra-se na otimização do fluxo de trabalho, desde a ideação até a produção, do desenvolvimento às operações. Isso significa quebrar silos entre equipes, criar uma cultura de colaboração e automatizar processos para eliminar gargalos. O objetivo é garantir que o trabalho seja concluído da maneira mais tranquila e rápida possível. As estratégias para otimizar o fluxo ponta a ponta incluem:

• Tamanho do lote: lotes menores de trabalho passando pelo sistema. Construções como grandes versões minam gravemente o fluxo ideal.
• Trabalho em andamento: limitar o número de itens nos quais uma equipe está trabalhando ao mesmo tempo.
• Filas: reduzir o número de filas e seus respectivos tempos de processamento
• Priorização: a tomada de decisões econômicas ou orientadas para o valor apoia o foco nos aspectos mais relevantes trazidos para o fluxo.

2. Segundo Princípio/Second Way: Feedback

O Segundo Princípio/Second Way enfatiza a criação de um ciclo de feedback rápido e confiável dentro, entre e em torno do desenvolvimento e operações. Isso significa implementar testes contínuos, monitoramento e mecanismos de feedback de clientes ou usuários. Significa também tornar mais fácil as equipes compartilharem conhecimentos e aprenderem umas com as outras. Isso permite que as equipes recebam feedback antecipado sobre se suas hipóteses de valor são válidas ou não. Além disso, inclui a coleta de dados de experiência de clientes, usuários, desenvolvedores, fornecedores ou quaisquer outras partes interessadas no ecossistema. Afinal de contas, as nossas hipóteses sobre o valor potencial dos produtos ou serviços que entregamos só podem ser validadas mensurando a eventual experiência uma vez entregue. Alimentar o sistema com dados operacionais e de sentimento estimula a melhoria e aprendizagem contínuas.

3. Terceiro Princípio/Third Way: Aprendizagem e experimentação contínuas/Continuous Learning and Experimentation

O Terceiro Princípio/Third Way enfatiza a importância da aprendizagem e experimentação contínuas. Isto significa promover uma cultura de experimentação, abraçar o fracasso como uma oportunidade de aprender, construir resiliência nos processos, tecnologia e equipes, e utilizar dados e métricas para impulsionar a melhoria contínua. Ao aprender e experimentar continuamente, as equipes podem melhorar seus processos e resultados ao longo do tempo.

Ao entender e implementar as Três Maneiras, as organizações podem melhorar a colaboração, feedback e melhoria contínua, levando a resultados superiores e processos mais eficientes. Em outras palavras, elas ajudam a trazer verdadeira propriedade e responsabilidade ponta a ponta para as equipes. Ou, como afirmou o CTO da Amazon, Werner Vogels: “Você constrói, você executa”. Quanto menos dependências uma equipe encontrar ao criar valor, melhores resultados veremos na prática.

Mantenha a CALMA (CALMS), desenvolva suas práticas de DevOps

CALMS é uma sigla amplamente aceita utilizada em DevOps que significa Culture (Cultura), Automation (Automação), Lean, Measurement (Medição) e Sharing (Compartilhamento). Quando aplicados em conjunto no equilíbrio certo, os pilares CALMS fornecem uma estrutura sólida para orientar as organizações na adoção das Três Maneiras e integração das práticas de DevOps correspondentes no seu ecossistema:

• Cultura refere-se à criação de uma cultura de colaboração, empatia, confiança e aprendizagem contínua na organização.
• Automação refere-se à automatização incansável de processos e fluxos de trabalho para melhorar a eficiência e reduzir o risco de erro humano.
• Lean refere-se à base metodológica das maneiras de se trabalhar do Lean (e Agile), como eliminar desperdícios e focar no valor e fluxo do cliente.
• Medição refere-se ao uso de dados (evidências) e métricas para medir a eficácia de produtos, serviços, processos e práticas e identificar áreas de melhoria.
• Compartilhamento refere-se a promover o compartilhamento de conhecimentos e colaboração entre equipes e indivíduos na organização.

Cultura: Promover a empatia, colaboração e responsabilidade compartilhada

Há uma razão pela qual o CALMS começa com a Cultura. Ela é a base da filosofia de DevOps, enfatizando uma mudança em direção à colaboração, responsabilidade compartilhada e quebra de silos organizacionais. Esta transformação cultural não se limita às equipes de desenvolvimento e operações, mas estende-se às partes interessadas da empresa, usuários, especialistas em segurança e fornecedores. Ela abrange uma mentalidade que valoriza a comunicação, empatia e um compromisso coletivo de entregar valor aos usuários finais.

Incentivar uma cultura de DevOps envolve promover a transparência e canais de comunicação abertos entre diferentes equipes e departamentos. As unidades de negócios são integradas ao processo de desenvolvimento, garantindo que as iniciativas de TI estejam alinhadas com os objetivos organizacionais. A essência de uma cultura DevOps é melhorar a velocidade, qualidade e confiabilidade da entrega de produtos e serviços, eliminando os silos entre as equipes e promovendo uma cultura de responsabilidade compartilhada.

O foco nestes aspectos culturais permitirá uma entrega mais rápida de valor, maior qualidade e confiabilidade, mais agilidade na resposta às mudanças nas necessidades de negócios e maior colaboração e trabalho em equipe. Além disso, a cultura de DevOps pode ajudar as organizações a reduzir custos e melhorar a eficiência, automatizando tarefas repetitivas e simplificando processos.

Automação: Minimizar o trabalho manual e simplificar os fluxos de trabalho para a eficiência

A automação é o mecanismo que alimenta a máquina de DevOps, permitindo que as organizações simplifiquem fluxos de trabalho, reduzam erros manuais e acelerem prazos de entrega. Do desenvolvimento do código à implantação e monitoramento, as ferramentas de automação desempenham um papel fundamental na obtenção da descoberta, integração, entrega e implantação contínuas.

Os testes automatizados garantem que as mudanças no código sejam avaliadas minuciosamente, reduzindo a probabilidade de introdução de defeitos no ambiente de produção. Os pipelines de integração contínua automatizam os processos de construção e integração, fornecendo uma base consistente e confiável para as implantações. As ferramentas de implantação automatizada facilitam a implantação contínua e reproduzível de aplicações, minimizando o tempo de inatividade e aumentando a eficiência geral.

Além disso, inúmeras outras soluções tecnológicas abordam tarefas relevantes, como controle de versões, gerenciamento de versões, orquestração de contêineres, provisionamento da infraestrutura, gestão do conhecimento, medição da experiência, monitoramento e capacidade de observação.

Lean: Centrar-se no valor, eliminar desperdícios e otimizar o fluxo

Lean e Agile estão no centro da maneira de se trabalhar do DevOps. A organização digital depende fortemente dos princípios e práticas Agile e Lean para gerenciar seu ambiente volátil e imprevisível. Quer as equipes usem Scrum ou Kanban ou qualquer outro instrumento para gerenciar seu (fluxo de) trabalho, as principais características de trabalho do DevOps envolvem um foco obsessivo no valor, fluxo e resiliência.

Se você faz parte de uma equipe Scrum envolvida no desenvolvimento de um novo produto para sua organização e tem dificuldade para obter feedback dos incrementos do produto que já colocou em produção. Nesse caso, você pode considerar o uso do trabalho em pares, capacidade de observação ou medição da experiência para coletar o feedback necessário. Ao fazer isso, as práticas Lean, como gerenciamento visual, mapeamento do fluxo de valor e Kaizen, podem aplicar estes conceitos eficazmente, removendo gargalos ou reduzindo os esforços manuais na obtenção do feedback necessário. Da mesma forma, se você é um agente de Service Desk que lida com clientes diariamente, certamente ficaria entusiasmado com a colaboração e fluxo de trabalho eficientes entre os grupos de resolução que trabalham em incidentes complexos ou com ciclos de feedback contínuos de dados de experiência utilizados para criar clientes e usuários satisfeitos.

A noção e entendimento de que nem todos os contextos são iguais são essenciais na aplicação de formas de trabalho Lean e/ou Agile. Se a sua equipe atua em um ambiente predominantemente previsível, com procedimentos de trabalho padrão, sua necessidade de aplicar abordagens Agile será bem diferente das equipes de desenvolvimento de produtos que enfrentam altos níveis de incerteza e volatilidade. Consequentemente, a última equipe provavelmente vai se beneficiar de princípios e estruturas ágeis, como desenvolvimento incremental, timeboxing ou Scrum. Da mesma forma, as equipes com um contexto previsível e estável seriam mais ajudadas com melhorias Lean para apoiar a padronização e automação das suas tarefas e fluxos de trabalho repetitivos.

A mentalidade Lean também incentiva o uso de métricas (evidências) para identificar áreas de melhoria. Ao analisar indicadores como satisfação do cliente, prazo de entrega e tempo de recuperação, as organizações podem identificar ineficiências e priorizar melhorias de processos.

Medição: Tomada de decisões baseada em dados e melhoria contínua

A medição é a base do DevOps, fornecendo os dados necessários para a tomada de decisões fundamentadas e melhoria contínua. As métricas de DevOps ajudam as organizações a avaliar a eficácia dos seus produtos, serviços e processos digitais, identificar áreas de melhoria e acompanhar o progresso ao longo do tempo. A coleta, interpretação e aplicação contínuas de dados e métricas relevantes corroboram uma melhor colaboração em todo o ciclo de vida de valor, desde o projeto até a operação e liderança às equipes.

A maioria das organizações e equipes de alto desempenho aplicou as métricas DORA típicas para DevOps com sucesso: tempo de espera para mudanças, frequência de implantação, taxa de falhas e tempo de recuperação. Além disso, as organizações começaram a explorar métricas de resultado ou valor, como taxa de retenção de clientes, satisfação dos usuários e felicidade dos funcionários. Ao introduzir uma medição rigorosa de resultados, experiência e impacto, o foco está mudando para a verdadeira entrega, otimização e colaboração ponta a ponta, em vez de resultados parciais ou da equipe.

Em linha com o Terceiro Princípio do DevOps, a medição também é um ingrediente fundamental para uma cultura de aprendizagem contínua para apoiar ecossistemas em constante evolução. Considere a repetição zero como um dos indicadores inovadores para estimular um ambiente seguro para aprender (“não há problemas em cometer um erro”), destacando ao mesmo tempo a importância de aprender com os erros anteriores (“só não cometa o mesmo erro duas vezes”).

Compartilhamento: Distribuir a carga cognitiva e compartilhamento de conhecimentos

O aspecto Compartilhamento do CALMS enfatiza a importância da comunicação, colaboração e compartilhamento de conhecimentos dentro e entre equipes. Em uma cultura DevOps, as informações fluem perfeitamente entre desenvolvimento, operações e outras partes interessadas, promovendo um entendimento compartilhado dos objetivos e prioridades.

O compartilhamento também se estende à documentação e transferência de conhecimentos. O DevOps incentiva a criação da documentação necessária (Lean como somos: apenas o suficiente) que captura todo o ciclo de vida de desenvolvimento. Esta documentação serve como um recurso valioso para integrar novos membros da equipe, solucionar problemas e garantir a continuidade em caso de mudanças de pessoal.

Seguindo o mantra “você constrói, você administra”, as organizações se esforçam para trazer o máximo de propriedade e responsabilidade para as equipes reais. Quanto mais autonomamente uma equipe puder executar suas tarefas, mais confiável será seu fluxo, mais curtos serão seus ciclos de feedback e mais valor ela entregará para os seus clientes. Uma armadilha comum é esperar que todas as tarefas do ciclo de vida de produtos e da cadeia de entrega convirjam em uma equipe. O conceito de carga cognitiva nos ensinou que os limites humanos tornam impossível ter todos os conhecimentos e capacidades relevantes, do simples ao complexo, combinados em uma equipe de 5 a 9 engenheiros.

É por isso que as organizações adotam construções organizacionais que diferenciam produto e plataforma, permitindo que as equipes separem a entrega do produto da engenharia da plataforma, e do suporte especializado. Isso permite que as equipes de produtos se concentrem no entendimento, criação e entrega de produtos digitais para seus clientes, enquanto usam serviços padronizados fornecidos pelas equipes de plataforma e apoiados por especialistas em segurança ou automação de testes de equipes de capacitação.

Colocando o DevOps em prática

Tudo isso contribui para a discussão se há algo como um engenheiro de DevOps. Do ponto de vista fundamental, DevOps é um movimento, uma maneira de pensar, um conjunto de práticas. Afirmar que temos um engenheiro de DevOps que abrange tudo isso em uma função é como dizer que designamos uma pessoa para colaborar. Um ponto de vista mais prático seria que podemos ter engenheiros em qualquer organização moderna realizando atividades relacionadas ao DevOps e adotando seus princípios e práticas típicos. Quer façam parte de uma equipe de produto ou plataforma ou tenham uma função facilitadora, poderíamos usar o termo abrangente engenheiro de DevOps para identificar os recursos e comportamentos desejados.

DevOps está relacionado com remover o atrito entre silos aplicando as Três Maneiras e equilibrando os respectivos pilares CALMS. Se realmente entendermos isso, poderemos aproveitar o seu potencial para as nossas próprias organizações. Isso fará com que os ecossistemas apresentem maior empatia, melhor colaboração, fluxo otimizado e, em última análise, mais valor para os nossos clientes.