É difícil captar o essencial ao falar sobre DevOps? reunimos analogias claras, frases de impacto e conselhos de especialistas que vão ajudar até os não especialistas a chegar ao cerne da questão. No final, um bônus – o próprio DevOps dos funcionários da Red Hat.
O termo DevOps surgiu há 10 anos e transitou de uma hashtag no Twitter para um poderoso movimento cultural no mundo da TI, uma verdadeira filosofia que incentiva os desenvolvedores a alcançar resultados mais rápido, a experimentar e a seguir em frente por meio de iterações. O DevOps se tornou indissociável do conceito de transformação digital. Mas, como acontece frequentemente com a terminologia de TI, ao longo de uma década, o DevOps acumulou uma série de definições, interpretações e mal-entendidos.
Por isso, sobre DevOps, não é raro ouvir perguntas como, isso é a mesma coisa que Agile? Ou isso é alguma metodologia específica? Ou é apenas mais um sinônimo da palavra "colaboração"?
O DevOps abrange muitos conceitos diferentes (entrega contínua, integração contínua, automação, etc.), por isso extrair o fundamental pode ser difícil, especialmente quando você não é indiferente ao assunto. No entanto, essa habilidade é muito útil, não importa se você está tentando transmitir suas ideias para a liderança ou apenas contando sobre seu trabalho a amigos ou familiares. Portanto, por enquanto, deixaremos de lado as nuances terminológicas do DevOps e nos concentraremos na visão geral.
O que é DevOps: 6 definições e analogias
Pedimos a especialistas que explicassem a essência do DevOps da forma mais simples e breve possível, visando que seu valor fosse compreendido por leitores com qualquer nível de formação técnica. Ao final dessas conversas, selecionamos as analogias mais impactantes e frases de destaque que irão ajudá-lo a estruturar sua narrativa sobre o DevOps.
1. DevOps é um movimento cultural
"DevOps é um movimento cultural, no qual ambos os lados (desenvolvedores de software e profissionais de operações de sistemas de TI) reconhecem que o software não tem utilidade real até que alguém o utilize: clientes, usuários, funcionários, não importa, " afirma Eveline Oehrlich, analista sênior do Instituto DevOps. "Portanto, ambas as partes trabalham juntas para garantir uma entrega rápida e de qualidade do software."
2. DevOps é o que empodera os desenvolvedores
«DevOps empodera os desenvolvedores a possuírem aplicações, a lançá-las e a gerenciar a entrega do início ao fim»
«Costuma-se falar de DevOps como uma forma de acelerar a entrega de aplicações em produção através da estruturação e aplicação de processos automatizados, – diz Jai Schniepp, diretor de plataformas DevOps da seguradora Liberty Mutual. – Mas para mim, é algo muito mais fundamental. DevOps empodera os desenvolvedores a possuírem aplicações ou partes específicas de software, a lançá-las e a gerenciar a entrega do início ao fim. DevOps elimina a confusão sobre responsabilidades e leva todos os participantes do processo a criar uma infraestrutura automatizada e gerenciada pelo desenvolvedor».
3. DevOps é colaboração na criação e entrega de aplicações
«Em termos simples, DevOps é uma abordagem para a produção e entrega de software em que todos trabalham juntos», – observa Gur Staf, presidente e chefe da automação de negócios digitais da BMC.
4. DevOps é uma linha de montagem
«A montagem em linha é possível apenas se todas as peças se encaixarem».
«Eu compararia DevOps a uma linha de montagem de carros, – continua Gur Staf. – A ideia é projetar e fabricar todas as peças de forma que possam ser montadas sem ajustes individuais. A montagem em linha é possível apenas se todas as peças se encaixarem. Aqueles que projetam e fabricam o motor devem pensar em como fixá-lo ao chassi ou à estrutura. Aqueles que fabricam os freios devem pensar nas rodas, e assim por diante. Da mesma forma deve ser o software.
Um desenvolvedor que cria a lógica de negócios ou a interface do usuário deve considerar o banco de dados que armazena informações sobre os clientes, os recursos de segurança para proteger os dados dos usuários, e como tudo isso funcionará quando o serviço começar a atender uma grande audiência de usuários, possivelmente até mesmo milhões de pessoas».
«Fazer com que as pessoas colaborem e pensem nas partes do trabalho realizadas por outros, em vez de se concentrarem exclusivamente em suas próprias tarefas, é o maior obstáculo a ser superado. Se isso for alcançado, você terá ótimas chances de transformação digital», acrescenta Gur Staff.
5. DevOps é a combinação certa de pessoas, processos e automação
Jayne Groll, diretora executiva do Instituto DevOps, fez uma analogia excelente para explicar DevOps. Segundo ela, «DevOps é como uma receita culinária, que tem três categorias principais de ingredientes: pessoas, processos e automação. A maioria desses ingredientes pode ser retirada de outras áreas e fontes: Lean, Agile, SRE, CI/CD, ITIL, liderança, cultura, ferramentas. O segredo do DevOps, assim como de qualquer boa receita, é como combinar corretamente as proporções e misturar esses ingredientes para aumentar a velocidade e a eficácia no desenvolvimento e lançamento de aplicativos».
6. DevOps é quando os programadores trabalham como uma equipe de Fórmula 1
«A corrida é planejada não do início ao fim, mas ao contrário, do fim ao início».
«Ao falar sobre o que esperar da iniciativa DevOps, cito como exemplo uma equipe de corrida da NASCAR ou da Fórmula 1», diz Chris Short, gerente sênior de marketing de plataformas em nuvem da Red Hat e editor da newsletter DevOps’ish. «O líder dessa equipe tem um único objetivo: conquistar a melhor posição possível na corrida, considerando os recursos da equipe e os desafios enfrentados. Nesse processo, a corrida é planejada não do início ao fim, mas ao contrário, do fim ao início. Primeiro, uma meta ambiciosa é estabelecida e, em seguida, são definidos os caminhos para alcançá-la. Após isso, as tarefas são divididas e delegadas aos membros da equipe».
«Toda a semana antes da corrida, a equipe aprimora o pit stop. Realiza treinos de força e cardio para estar em forma no dia exaustivo da corrida. Treina ações conjuntas para resolver quaisquer problemas que possam surgir durante a corrida. Da mesma forma, a equipe de desenvolvedores deve treinar suas habilidades para lançar novas versões com frequência. Com essas habilidades e um sistema de segurança bem ajustado, o lançamento de novas versões em produção ocorre mais frequentemente. Dentro dessa mentalidade, o aumento da velocidade significa aumento da segurança», diz Short.
«A questão não é fazer as 'coisas certas', – acrescenta Short, – mas remover o máximo possível de obstáculos que estão no caminho do resultado desejado. Colabore e adapte-se com base no feedback que você recebe em tempo real. Esteja preparado para anomalias e trabalhe para melhorar a qualidade, de modo a minimizar seu impacto na trajetória rumo ao objetivo. É isso que nos aguarda no mundo do DevOps».
Como escalar DevOps: 10 dicas de especialistas
DevOps simples e DevOps em larga escala são coisas absolutamente diferentes. Vamos falar sobre como superar as barreiras do primeiro para o segundo.
Para muitas organizações, o caminho para o DevOps começa de forma fácil e prazerosa. Pequenas equipes apaixonadas são formadas, os processos antigos são substituídos por novos e os primeiros sucessos não demoram a aparecer.
Infelizmente, isso é apenas um brilho falso, uma ilusão de progresso, como diz Ben Grinnell, diretor executivo e líder da prática de tecnologia digital da consultoria North Highland. As primeiras vitórias são, sem dúvida, encorajadoras, mas não ajudam a alcançar o objetivo final, que é a adoção em larga escala do DevOps na organização.
É fácil ver que, como resultado, se forma uma cultura de divisão entre 'nós' e 'eles'.
«Frequentemente, as organizações lançam projetos pioneiros, acreditando que eles abrirão caminho para o DevOps em massa, sem considerar se outros estarão dispostos a seguir esse caminho», explica Ben Grinnell. «As equipes para a implementação desses projetos geralmente são formadas por “estrangeiros” autoconfiantes, que já realizaram algo semelhante em outros lugares, mas são novatos em sua organização. Além disso, eles são incentivados a quebrar e desestabilizar regras que continuam obrigatórias para todos os outros. É fácil ver que, como resultado, se forma uma cultura de divisão entre “nós” e “eles”, que impede a transferência de conhecimentos e habilidades.»
«E esse problema cultural é apenas uma das razões pelas quais o DevOps é difícil de escalar. As equipes de DevOps enfrentam um aumento das complexidades técnicas, características de empresas em rápido desenvolvimento que apostaram em tecnologias de TI», diz Steve Newman, fundador e presidente do conselho da Scalyr.
«No mundo moderno, os serviços mudam assim que a necessidade aparece. Implementar e lançar novas funcionalidades constantemente é realmente ótimo, mas coordenar esse processo e resolver os problemas que surgem é uma verdadeira dor de cabeça», acrescenta Steve Newman. «Em organizações de crescimento rápido, engenheiros em equipes multifuncionais lutam para manter a capacidade de rastrear mudanças e os efeitos em cascata que elas geram no nível das dependências. Além disso, os engenheiros não ficam nada felizes quando são privados dessa capacidade, tornando-se mais difícil entender a essência dos problemas que surgem.»
Como superar as dificuldades descritas acima e passar para o uso em massa do DevOps em uma grande organização? Especialistas pedem paciência, mesmo que seu objetivo final seja acelerar o ciclo de desenvolvimento de software e os processos de negócios.
1. Lembre-se de que mudanças culturais levam tempo
Jayne Groll, CEO do Instituto DevOps: «Na minha opinião, a expansão do DevOps deve ser tão gradual e iterativa quanto o desenvolvimento ágil (e igualmente afetar a cultura). Em Agile e DevOps, o foco está em pequenas equipes. Mas à medida que o número de equipes cresce e sua integração avança, temos cada vez mais pessoas adotando novos métodos de trabalho, resultando em uma transformação cultural em grande escala».
2. Dedique tempo suficiente ao planejamento e à escolha da plataforma
Eran Kinsbruner, principal evangelista técnico da Perfecto: «Para que a escalabilidade funcione, as equipes de DevOps precisam, inicialmente, aprender a combinar processos, ferramentas e habilidades tradicionais, e então cultivar lentamente cada fase do DevOps e estabilizá-la. Tudo começa com um planejamento cuidadoso das histórias de usuário e dos fluxos de criação de valor, seguido pela fase de desenvolvimento de software e controle de versões utilizando trunk-based development ou outras abordagens mais adequadas para o branching e merging de código».
«A fase seguinte é a integração e teste, onde uma plataforma escalável para automação já é necessária. Aqui, é crucial que as equipes de DevOps escolham a plataforma certa que corresponda ao seu nível de habilidades e objetivos finais do projeto.
A próxima fase é a implantação em um ambiente de produção, que deve ser completamente automatizada utilizando ferramentas de orquestração e contêineres. É importante ter ambientes virtualizados em todas as etapas do DevOps (simulador do ambiente de produção, ambiente de controle de qualidade e, efetivamente, o ambiente de produção) e sempre usar os dados mais recentes para testes, a fim de obter conclusões precisas. A análise deve ser inteligente e capaz de processar grandes volumes de dados com feedback rápido e eficaz».
3. Libere as responsabilidades do gosto pela culpa
Gordon Haff, evangelista da RedHat: «Criar um sistema e uma atmosfera que permitam e incentivem experimentos possibilita a realização dos chamados fracassos bem-sucedidos no desenvolvimento ágil de software. Isso não significa que ninguém mais é responsável pelos fracassos. Na verdade, estabelecer a responsabilidade se torna ainda mais simples, já que "ser responsável" não significa mais "ser o culpado pelo acidente". Ou seja, a essência da responsabilidade muda qualitativamente. Nesse contexto, quatro fatores se tornam extremamente importantes: a magnitude do fracasso, as abordagens, os processos produtivos e os incentivos». (Saiba mais sobre esses fatores no artigo de Gordon Haff "DevOps lessons: 4 aspects of healthy experiments").
4. Desobstruam o caminho à frente
Ben Grinnell, diretor executivo e líder da área de tecnologias digitais da consultoria North Highland: «Para alcançar a escalabilidade, recomendo lançar um programa de "limpeza de caminho" juntamente com projetos-pioneiros. O objetivo deste programa é remover a bagunça deixada pelos pioneiros do DevOps, como regras obsoletas e outras coisas do gênero, para que o caminho à frente permaneça livre».
«Dê apoio organizacional às pessoas e estimule por meio de uma comunicação que vá muito além do grupo de pioneiros, celebrando amplamente os sucessos dos novos métodos de trabalho. Treine as pessoas que estão envolvidas na próxima onda de projetos DevOps e que estão nervosas por estarem usando o DevOps pela primeira vez. E lembre-se de que essas pessoas são muito diferentes dos pioneiros».
5. Tornem as ferramentas mais democráticas
Steve Newman, fundador e presidente do conselho da Scalyr: «As ferramentas não devem ser escondidas das pessoas e devem ser relativamente fáceis de aprender para qualquer um que esteja disposto a dedicar tempo a isso. Se a capacidade de solicitar logs é dada apenas a três pessoas, "certificadas" para trabalhar com uma determinada ferramenta, você sempre terá no máximo três pessoas capazes de lidar com o problema correspondente, mesmo que tenha um ambiente computacional muito grande. Em outras palavras, isso cria um gargalo que pode levar a sérias consequências (para o negócio)».
6. Crie condições ideais para o trabalho da equipe
Tom Clark, líder da área de Common Platform na ITV: «Você pode fazer qualquer coisa, mas não tudo de uma vez. Portanto, estabeleça grandes objetivos, comece com pequenas etapas e avance rapidamente por iterações. Com o tempo, você ganhará a reputação de uma equipe que consegue tudo, fazendo com que outros queiram adotar seus métodos. E não busque construir uma equipe de alta performance. Em vez disso, forneça às pessoas as condições ideais para trabalhar, e a eficiência virá naturalmente.»
7. Não se esqueça da lei de Conway e das quadros Kanban
Logan Daigle, diretor de entrega de software e estratégia DevOps da CollabNetVersionOne: «É importante estar ciente das consequências da lei de Conway. Em minha interpretação livre, essa lei afirma que os produtos que criamos e os processos que utilizamos, incluindo DevOps, são organizados da mesma forma que nossa organização.»
«Se em uma organização a desconexão é alta, e durante o planejamento, criação e lançamento de software a gestão muitas vezes troca de mãos, o efeito da escalabilidade será nulo ou efêmero. Por outro lado, se a organização forma equipes multifuncionais em torno de produtos que são financiados com um foco no mercado, as chances de sucesso aumentam drasticamente.»
«Outro aspecto importante da escalabilidade é exibir todos os trabalhos em andamento (WIP, work in progress) nos quadros Kanban. Quando há um local na organização onde as pessoas podem ver essas informações, isso estimula muito a colaboração, o que impacta positivamente na escalabilidade.»
8. Procure cicatrizes antigas
Manuel Pais, consultor em DevOps e coautor do livro 'Team Topologies': «Levar práticas DevOps para além de Dev e Ops e tentar aplicá-las a outras funções provavelmente não é a abordagem ideal. Isso, sem dúvida, terá algum efeito (por exemplo, através da automação da gestão manual), mas pode-se alcançar muito mais ao começar com a compreensão dos processos de entrega e feedback.»
«Se na infraestrutura de TI da organização existem cicatrizes antigas – procedimentos e mecanismos de gestão que foram implementados após incidentes passados, mas que se tornaram obsoletos (devido à mudança de produtos, tecnologias ou processos) – eles devem, sem dúvida, ser removidos ou suavizados, e não automatizar processos ineficazes ou desnecessários».
9. Não crie variantes de DevOps
Antony Edwards, diretor de produção da Eggplant: «DevOps é um termo muito vago, por isso cada equipe cria sua própria versão de DevOps. E não há nada pior do que ter 20 variantes de DevOps dentro da organização, que não se integram bem. Não deve haver um interface única entre desenvolvimento e gestão de produtos em cada uma das três equipes de desenvolvimento. Além disso, os produtos não podem ter suas próprias e únicas expectativas sobre como o feedback deve ser tratado ao ser transferido para um simulador de ambiente de produção. Caso contrário, você nunca conseguirá escalar o DevOps».
10. Pregue o valor do DevOps para os negócios
Steve Newman, fundador e presidente do conselho da Scalyr: «Trabalhe para reconhecer o valor do DevOps. Aprenda e não tenha vergonha de falar sobre os benefícios do que você faz. DevOps economiza imensamente tempo e dinheiro (basta pensar: menos períodos de inatividade, tempo médio de recuperação mais curto), e as equipes de DevOps devem incessantemente enfatizar (e pregar) a importância dessas iniciativas para o sucesso dos negócios. Assim, você poderá ampliar o número de adeptos e aumentar a influência do DevOps na organização».
BÔNUS
Sobre Em 13 de setembro, nosso próprio DevOps chegará – sim, a Red Hat, como fabricante de software, tem suas próprias equipes e práticas de DevOps.
Nosso engenheiro, Mark Birger, que desenvolve serviços de automação interna para outros grupos em toda a organização, contará em russo claro sua própria história – como a equipe de DevOps da Red Hat migrou aplicações de ambientes virtuais Hat Virtualization, gerenciados pelo Ansible, para um formato de contêiner completo na plataforma OpenShift.
Mas isso ainda não é tudo:
Depois que as organizações migraram suas cargas de trabalho para contêineres, os métodos tradicionais de monitoramento de aplicativos podem não funcionar. No segundo relatório, explicaremos nossa motivação para mudar a forma de registro e mostraremos a continuidade da jornada que nos levou a métodos modernos de registro e monitoramento.
Fonte: habr.com
