É difícil entender o ponto principal quando se fala em DevOps? Reunimos para você analogias vívidas, formulações impressionantes e conselhos de especialistas que ajudarão até mesmo os não especialistas a ir direto ao ponto. No final, o bônus é o DevOps dos próprios funcionários da Red Hat.
O termo DevOps surgiu há 10 anos e passou de uma hashtag do Twitter a um poderoso movimento cultural no mundo da TI, uma verdadeira filosofia que incentiva os desenvolvedores a fazer as coisas com mais rapidez, experimentar e iterar adiante. O DevOps tornou-se inextricavelmente ligado ao conceito de transformação digital. Mas, como acontece frequentemente com a terminologia de TI, nos últimos dez anos o DevOps adquiriu muitas definições, interpretações e conceitos errados sobre si mesmo.
Portanto, muitas vezes você pode ouvir perguntas sobre DevOps, como: é o mesmo que ágil? Ou isso é alguma metodologia especial? Ou é apenas mais um sinônimo para a palavra “colaboração”?
O DevOps inclui muitos conceitos diferentes (entrega contínua, integração contínua, automação, etc.), portanto, resumir o que é importante pode ser um desafio, especialmente quando você é apaixonado pelo assunto. No entanto, essa habilidade é muito útil, não importa se você está tentando transmitir suas ideias aos seus superiores ou simplesmente contando a alguém da sua família ou amigos sobre o seu trabalho. Portanto, vamos deixar de lado as nuances terminológicas do DevOps por enquanto e focar no panorama geral.
O que é DevOps: 6 Definições e Analogias
Pedimos a especialistas que explicassem a essência do DevOps da forma mais simples e resumida possível, para que seu valor ficasse claro para leitores com qualquer nível de conhecimento técnico. Com base nos resultados dessas conversas, selecionamos as analogias e formulações mais marcantes que ajudarão você a construir sua história sobre DevOps.
1. DevOps é um movimento cultural
“DevOps é um movimento cultural em que ambas as partes (desenvolvedores de software e especialistas em operação de sistemas de TI) reconhecem que o software não traz benefícios reais até que alguém comece a usá-lo: clientes, clientes, funcionários, não é o ponto”, diz Eveline Oehrlich, pesquisadora sênior analista do DevOps Institute. “Portanto, ambas as partes garantem em conjunto a entrega rápida e de alta qualidade de software.”
2. DevOps visa capacitar os desenvolvedores.
“O DevOps permite que os desenvolvedores possuam aplicativos, executem-nos e gerenciem a entrega do início ao fim.”
“Normalmente, fala-se de DevOps como uma forma de acelerar a entrega de aplicações à produção através da construção e implementação de processos automatizados”, afirma Jai Schniepp, diretor de plataformas DevOps da seguradora Liberty Mutual. “Mas para mim é uma coisa muito mais fundamental.” O DevOps capacita os desenvolvedores a possuir aplicativos ou softwares específicos, executá-los e gerenciar sua entrega do início ao fim. O DevOps elimina a confusão de responsabilidades e orienta todos os envolvidos na criação de uma infraestrutura automatizada e orientada para o desenvolvedor.”
3. DevOps trata de colaboração na criação e entrega de aplicativos.
“Simplificando, DevOps é uma abordagem para produção e entrega de software onde todos trabalham juntos”, diz Gur Staf, presidente e chefe de automação de negócios digitais da BMC.
4. DevOps é um pipeline
“A montagem do transportador só é possível se todas as peças se encaixarem.”
“Eu compararia o DevOps a uma linha de montagem de automóveis”, continua Gur Staff. – A ideia é projetar e fabricar todas as peças com antecedência para que depois possam ser montadas sem ajustes individuais. A montagem do transportador só é possível se todas as peças se encaixarem. Aqueles que projetam e constroem um motor devem considerar como montá-lo na carroceria ou na estrutura. Quem faz os freios deve pensar nas rodas, e assim por diante. O mesmo deve acontecer com o software.
Um desenvolvedor que cria uma lógica de negócios ou uma interface de usuário deve pensar no banco de dados que armazena as informações do cliente, nas medidas de segurança para proteger os dados do usuário e em como tudo isso funcionará quando o serviço começar a atender um grande público de usuários, talvez até multimilionário. ."
“Fazer com que as pessoas colaborem e pensem nas partes do trabalho que os outros estão realizando, em vez de se concentrarem apenas nas suas próprias tarefas, é o maior obstáculo a superar. Se você conseguir fazer isso, terá uma excelente chance de transformação digital”, acrescenta Gur Staff.
5. DevOps é a combinação certa de pessoas, processos e automação
Jayne Groll, diretor executivo do DevOps Institute, ofereceu uma ótima analogia para explicar o DevOps. Nas palavras dela, “DevOps é como uma receita com 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, como qualquer boa receita, é como obter as proporções e a mistura corretas desses ingredientes para aumentar a velocidade e a eficiência da criação e do lançamento de aplicações.”
6. DevOps é quando os programadores trabalham como uma equipe de Fórmula 1
“A corrida não é planejada do início ao fim, mas pelo contrário, do final ao início.”
“Quando falo sobre o que esperar de uma iniciativa DevOps, penso em uma equipe de corrida da NASCAR ou de Fórmula 1 como exemplo”, diz Chris Short, gerente sênior de marketing de plataforma em nuvem da Red Hat e editor do boletim informativo DevOps. – O líder de tal equipa tem um objetivo: ocupar o lugar mais alto possível no final da corrida, tendo em conta os recursos à disposição da equipa e os desafios que se abateram sobre ela. Neste caso, a corrida não é planeada do início ao fim, mas, pelo contrário, do fim ao início. Primeiro, uma meta ambiciosa é definida e, em seguida, são determinadas as formas de alcançá-la. Em seguida, elas são divididas em subtarefas e delegadas aos membros da equipe.”
“A equipe passa a semana inteira antes da corrida aperfeiçoando o pit stop. Ele faz treinamento de força e cardio para se manter em forma para um dia cansativo de corrida. Pratica trabalhando em conjunto para resolver quaisquer problemas que possam surgir durante a corrida. Da mesma forma, a equipe de desenvolvimento deve treinar a habilidade de lançar novas versões com frequência. Se você tiver essas habilidades e um sistema de segurança que funcione bem, o lançamento de novas versões em produção também acontecerá com mais frequência. Nesta visão de mundo, maior velocidade significa maior segurança”, afirma Short.
“Não se trata de fazer a ‘coisa certa’”, acrescenta Short, “trata-se de eliminar o máximo possível de coisas que atrapalham o 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 para minimizar o impacto delas no progresso em direção ao seu objetivo. Isto é o que nos espera no mundo do DevOps.”
Como escalar DevOps: 10 dicas de especialistas
Acontece que DevOps e DevOps em massa são coisas completamente diferentes. Diremos como superar barreiras no caminho do primeiro ao segundo.
Para muitas organizações, a jornada para o DevOps começa de forma fácil e agradável. Criam-se pequenas equipes apaixonadas, processos antigos são substituídos por novos e os primeiros sucessos não demoram a chegar.
Infelizmente, isto é apenas um falso brilho, uma ilusão de progresso, diz Ben Grinnell, diretor administrativo e chefe de digital da consultoria North Highland. As vitórias iniciais são certamente encorajadoras, mas não ajudam a atingir o objetivo final de adoção generalizada do DevOps em toda a organização.
É fácil perceber que o resultado é uma cultura de divisão entre “nós” e “eles”.
“Muitas vezes, as organizações lançam estes projetos pioneiros pensando que abrirão o caminho para o DevOps mainstream, sem considerar se outros poderão ou estarão dispostos a seguir esse caminho”, explica Ben Grinnell. – As equipes para implementar tais projetos são geralmente recrutadas entre “varangianos” autoconfiantes que já fizeram algo semelhante em outros lugares, mas são novos em sua organização. Ao mesmo tempo, são encorajados a quebrar e destruir as regras que permanecem vinculativas para todos os outros. É fácil ver que o resultado é uma cultura de “nós” e “eles” que inibe a transferência de conhecimentos e competências.”
“E esse problema cultural é apenas um dos motivos pelos quais o DevOps é difícil de escalar. As equipes de DevOps estão enfrentando desafios técnicos cada vez maiores, típicos de empresas que priorizam a TI em rápido crescimento”, disse Steve Newman, fundador e presidente da Scalyr.
“No mundo moderno, os serviços mudam assim que surge a necessidade. É ótimo implementar e implementar constantemente novos recursos, mas coordenar esse processo e eliminar os problemas que surgem é uma verdadeira dor de cabeça, acrescenta Steve Newman. – Em organizações de crescimento muito rápido, os engenheiros em equipas multifuncionais lutam para manter a visibilidade da mudança e dos efeitos em cascata de nível de dependência que ela cria. Além disso, os engenheiros não ficam felizes quando são privados desta oportunidade e, como resultado, torna-se mais difícil para eles compreenderem a essência dos problemas que surgem.”
Como superar esses desafios descritos acima e avançar para a adoção em massa do DevOps em uma grande organização? Os especialistas recomendam 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 a mudança cultural leva tempo.
Jayne Groll, Diretora Executiva, Instituto DevOps: “Na minha opinião, a expansão do DevOps deveria ser tão incremental e iterativa quanto o desenvolvimento ágil (e igualmente tocar na cultura). Agile e DevOps enfatizam equipes pequenas. Mas à medida que estas equipas crescem em número e integração, acabamos por ter mais pessoas a adotar novas formas de trabalhar e, como resultado, há uma enorme transformação cultural.”
2. Passe bastante tempo planejando e escolhendo uma plataforma
Eran Kinsbruner, evangelista técnico líder da Perfecto: “Para que o dimensionamento funcione, as equipes de DevOps devem primeiro aprender a combinar processos, ferramentas e habilidades tradicionais e, em seguida, nutrir e estabilizar lentamente cada fase individual do DevOps. Tudo começa com um planejamento cuidadoso de histórias de usuários e fluxos de valor, seguido pela escrita de software e controle de versão usando desenvolvimento baseado em tronco ou outras abordagens mais adequadas para ramificação e fusão de código.”
“Depois vem a fase de integração e testes, onde já é necessária uma plataforma escalável para automação. É aqui que é importante que as equipes de DevOps escolham a plataforma certa que se adapte ao seu nível de habilidade e aos objetivos finais do projeto.
A próxima fase é a implantação em produção e isso deve ser totalmente automatizado usando ferramentas de orquestração e contêineres. É importante ter ambientes virtualizados em todas as etapas do DevOps (simulador de produção, ambiente de QA e ambiente de produção real) e utilizar sempre apenas os dados mais recentes para testes para obter conclusões relevantes. A análise deve ser inteligente e capaz de processar big data com feedback rápido e acionável.”
3. Tire a culpa da responsabilidade.
Gordon Haff, evangelista da RedHat: “Criar um sistema e uma atmosfera que permita e incentive a experimentação permite o que é conhecido como falhas bem-sucedidas no desenvolvimento ágil de software. Isso não significa que ninguém mais seja responsável pelas falhas. Na verdade, identificar quem é o responsável fica ainda mais fácil, pois “ser responsável” não significa mais “causar um acidente”. Ou seja, a essência da responsabilidade muda qualitativamente. Quatro fatores tornam-se críticos: a extensão da disrupção, abordagens, processos de produção e incentivos.” (Você pode ler mais sobre esses fatores no artigo de Gordon Huff “Lições de DevOps: 4 aspectos de experimentos saudáveis”.)
4. Limpe o caminho a seguir
Ben Grinnell, diretor administrativo e chefe de digital da consultoria North Highland: “Para alcançar escala, recomendo lançar um programa de “desobstrução de caminhos” juntamente com projetos pioneiros. O objetivo deste programa é limpar o lixo que os pioneiros do DevOps deixam para trás, como regras desatualizadas e coisas assim, para que o caminho a seguir permaneça claro.”
“Dê às pessoas apoio organizacional e impulso por meio de uma comunicação que vai muito além do grupo pioneiro, celebrando amplamente os sucessos de novas formas de trabalhar. Treine pessoas que estão envolvidas na próxima onda de projetos DevOps e que estão nervosas em usar o DevOps pela primeira vez. E lembre-se que essas pessoas são muito diferentes dos pioneiros.”
5. Torne as ferramentas mais democráticas
Steve Newman, fundador e presidente da Scalyr: “As ferramentas não devem ser escondidas das pessoas e devem ser relativamente fáceis de aprender para qualquer pessoa disposta a investir tempo. Se a capacidade de consultar logs for restrita a três pessoas “certificadas” para utilizar uma ferramenta, você sempre terá no máximo três pessoas disponíveis para tratar do problema, mesmo que tenha um ambiente computacional muito grande. Em outras palavras, há aqui um gargalo que pode levar a sérias consequências (comerciais).
6. Crie condições ideais para o trabalho em equipe
Tom Clark, chefe de Plataforma Comum da ITV: “Você pode fazer qualquer coisa, mas não tudo de uma vez. Portanto, estabeleça grandes metas, comece aos poucos e avance em iterações rápidas. Com o tempo, você desenvolverá uma reputação de realizar tarefas, de modo que outras pessoas também desejarão usar seus métodos. E não se preocupe em construir uma equipe altamente eficaz. Em vez disso, forneça às pessoas condições de trabalho ideais e a eficiência será consequência.”
7. Não se esqueça da Lei de Conway e dos quadros Kanban
Logan Daigle, Diretor de Entrega de Software e Estratégia DevOps da CollabNetVersionOne: “É importante compreender as consequências da Lei de Conway. Na minha paráfrase solta, esta lei afirma que os produtos que criamos e os processos que usamos para fazê-lo, incluindo DevOps, acabam por ser estruturados da mesma forma que a nossa organização.”
“Se houver muitos silos em uma organização e o controle mudar de mãos muitas vezes durante o planejamento, construção e lançamento de software, o efeito do dimensionamento será zero ou de curta duração. Se uma organização construir equipes multifuncionais em torno de produtos financiados com foco no mercado, as chances de sucesso aumentam dramaticamente.”
“Outro aspecto importante do dimensionamento é exibir todo o trabalho em andamento (WIP, workinprogress) em quadros Kanban. Quando uma organização tem um lugar onde as pessoas podem ver essas coisas, isso incentiva muito a colaboração, o que tem um impacto positivo na expansão.”
8. Procure cicatrizes antigas
Manuel Pais, consultor DevOps e coautor de Team Topologies: “Levar as práticas de DevOps além de Dev e Ops e tentar aplicá-las a outras funções dificilmente é uma abordagem ideal. Isto certamente terá algum impacto (por exemplo, ao automatizar o controle manual), mas muito mais pode ser alcançado se começarmos pela compreensão dos processos de entrega e feedback.”
“Se existem cicatrizes antigas no sistema de TI de uma organização - procedimentos e mecanismos de gestão que foram implementados como resultado de incidentes passados, mas perderam a sua relevância (devido a mudanças em produtos, tecnologias ou processos) - então elas certamente precisam ser removidas ou suavizados, em vez de automatizar processos ineficientes ou desnecessários.”
9. Não crie opções de DevOps
Anthony Edwards, Diretor de Operações da Berinjela: “DevOps é um termo muito vago, então cada equipe acaba com sua própria versão de DevOps. E não há nada pior quando uma organização de repente tem 20 variedades de DevOps que não se dão muito bem juntas. É impossível para cada uma das três equipes de desenvolvimento ter sua própria interface especial entre desenvolvimento e gerenciamento de produto. Os produtos também não devem ter expectativas próprias quanto ao tratamento do feedback quando transferidos para um simulador de produção. Caso contrário, você nunca será capaz de escalar o DevOps.”
10. Pregue o valor comercial do DevOps
Steve Newman, fundador e presidente da Scalyr: “Trabalhe para reconhecer o valor do DevOps. Aprenda e fique à vontade para falar sobre os benefícios do que você faz. DevOps economiza muito tempo e dinheiro (pense: menos tempo de inatividade, menor tempo médio de recuperação), e as equipes de DevOps devem enfatizar (e pregar) incansavelmente a importância dessas iniciativas para o sucesso dos negócios. Dessa forma você pode ampliar o círculo de adeptos e aumentar a influência do DevOps na organização.”
BÔNUS
На Nosso próprio DevOps chegará em 13 de setembro – 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á sua própria história em russo puro: como a equipe Red Hat DevOps migrou aplicativos de ambientes virtuais Hat Virtualization gerenciados pelo Ansible para um formato de contêiner completo em a plataforma OpenShift.
Mas isso não é tudo:
Depois que as organizações transferem cargas de trabalho para contêineres, os métodos tradicionais de monitoramento de aplicativos podem não funcionar. Na segunda palestra explicaremos nossa motivação para mudar a forma como registramos e mostraremos a continuação do caminho que nos levou aos métodos modernos de registro e monitoramento.
Fonte: habr.com