É difícil entender o que se fala quando se trata de DevOps? Reunimos para você analogias vívidas, formulações de percussão e conselhos de especialistas que ajudarão até mesmo os não especialistas a chegar ao ponto. No final, o bônus é o DevOps da Red Hat.
O termo DevOps surgiu há 10 anos e passou de uma hashtag no Twitter para um poderoso movimento cultural no mundo da TI, uma verdadeira filosofia que incentiva os desenvolvedores a obter resultados mais rapidamente, experimentar e avançar usando o método de iteração. O DevOps tornou-se inextricavelmente vinculado ao conceito de transformação digital. Mas, como costuma ser o caso da terminologia de TI, ao longo de uma década, o DevOps conseguiu obter muitas definições, interpretações e conceitos errôneos.
Portanto, sobre o DevOps, muitas vezes você pode ouvir perguntas como: é o mesmo que ágil? Ou é algum tipo de metodologia especial? Ou é apenas outro sinônimo para a palavra "colaboração"?
O DevOps inclui muitos conceitos diferentes (entrega contínua, integração contínua, automação etc.), portanto, o isolamento do principal pode ser difícil, especialmente quando você é parcial no assunto. No entanto, essa habilidade é muito útil, não importa se você está tentando transmitir suas idéias aos seus superiores ou apenas dizendo a seus parentes ou amigos sobre o seu trabalho. Portanto, por enquanto, deixe de lado as nuances terminológicas do DevOps e concentre-se no quadro geral.
O que é o DevOps: 6 definições e analogias
Pedimos que os especialistas explicassem a essência do DevOps da maneira mais simples e breve possível, para que seu valor fique claro para o leitor em qualquer nível de treinamento técnico. Com base nos resultados dessas conversas, selecionamos as analogias e formulações de percussão mais impressionantes que ajudarão você a construir sua história sobre o DevOps.
1. DevOps é um movimento cultural
“O DevOps é um movimento cultural em que ambas as partes (desenvolvedores de software e especialistas em operações 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 é esse o ponto, diz Eveline Oehrlich, analista sênior do DevOps Institute. “Portanto, ambas as partes juntas fornecem entrega de software rápida e de alta qualidade.”
2. DevOps é o que capacita os desenvolvedores
“O DevOps capacita os desenvolvedores com a propriedade dos aplicativos, o gerenciamento de lançamento e entrega do início ao fim”"Geralmente eles falam sobre o DevOps como uma maneira de acelerar a entrega de aplicativos à produção, criando e aplicando processos automatizados", disse Jai Schniepp, diretor de plataformas do DevOps, Liberty Mutual Insurance Company. "Mas para mim é uma coisa muito mais fundamental." O DevOps dá aos desenvolvedores a autoridade para possuir aplicativos ou certas partes do software, iniciá-los e gerenciar a entrega do início ao fim. O DevOps elimina a confusão de responsabilidades e leva todos os participantes do processo a criar uma infraestrutura automatizada e orientada ao desenvolvedor. ”
3. DevOps é uma colaboração na criação e entrega de aplicativos
"Simplificando, o DevOps é uma abordagem para a produção e entrega de software quando todos trabalham juntos", disse Gur Staf, presidente e chefe de automação comercial digital da BMC.
4. DevOps é um pipeline
“A montagem do transportador só é possível se todas as peças se encaixarem.”"Eu compararia o DevOps com uma linha de montagem de automóveis", continua Gur Staf. - A idéia é pré-projetar e fazer todos os detalhes para que depois possam ser montados sem um ajuste individual. A montagem do transportador só é possível se todas as peças se encaixarem. Aqueles que projetam e fabricam o motor devem considerar como montá-lo no corpo ou na estrutura. Aqueles que freiam devem pensar em rodas, e assim por diante. Deve ser o mesmo com o software.
Um desenvolvedor que cria uma lógica comercial ou interface de usuário deve pensar em um banco de dados que armazena informações sobre clientes, sobre medidas de segurança para proteger os dados do usuário e como ele funcionará quando o serviço começar a atender a um grande, possivelmente até vários milhões público do usuário ".
“Fazer as pessoas cooperarem e pensarem sobre as partes do trabalho que são realizadas por outros, e não se concentrarem apenas em suas próprias tarefas - esse é o maior obstáculo que deve ser superado. Se for bem-sucedido, você tem excelentes chances de transformação digital ”, acrescenta Gur Staf.
5. DevOps é a combinação certa de pessoas, processos e automação
Jayne Groll, diretora executiva do DevOps Institute, ofereceu uma ótima analogia para explicar o DevOps. Segundo ela, “o DevOps é como uma receita culinária na qual existem três categorias principais de ingredientes: pessoas, processos e automação. A maioria desses ingredientes pode ser obtida de outras áreas e fontes: Lean, Agile, SRE, CI / CD, ITIL, liderança, cultura, ferramentas. O segredo do DevOps, assim como qualquer boa receita, é como escolher as proporções certas e misturar esses ingredientes para aumentar a velocidade e a eficácia do trabalho ao criar e liberar aplicativos. ”
6. DevOps - é quando os programadores trabalham como uma equipe de Fórmula 1
"A corrida está planejada não do começo ao fim, mas do começo ao fim"."Falando sobre o que esperar da iniciativa DevOps, citarei a equipe de corrida NASCAR ou Fórmula 1 como exemplo", diz Chris Short, gerente geral de marketing de plataforma em nuvem da Red Hat e editor da lista de discussão do DevOps. - O chefe de uma equipe tem um objetivo: obter o máximo de lugar possível de acordo com os resultados da corrida, levando em consideração os recursos disponíveis para a equipe e os testes que caíram em sua parte. Além disso, a corrida não está planejada do início ao fim, mas do começo ao fim. Um objetivo ambicioso é primeiro definido e, em seguida, as formas de alcançá-lo são determinadas. Em seguida, eles são divididos em subtarefas e delegados aos membros da equipe. ”
“A semana inteira antes da corrida, a equipe aprimora o pit stop. Ele está envolvido em treinamento de força e cardio para estar em forma em um dia cansativo de corrida. Ele realiza ações conjuntas para resolver quaisquer problemas que possam surgir na corrida. Da mesma forma, a equipe de desenvolvimento deve treinar as habilidades de lançar frequentemente novas versões. Com essas habilidades e um sistema de segurança que funcione bem, o lançamento de novas versões na produção também ocorre com mais frequência. Dentro dessa visão de mundo, um aumento na velocidade significa um aumento na segurança ”, afirma Short.
“O objetivo não é fazer a“ coisa certa ”, acrescenta Short,“ mas eliminar o maior número possível de coisas que atrapalhem o resultado desejado. Colabore e se adapte com base nos comentários que você recebe em tempo real. Esteja preparado para anomalias e trabalhe na melhoria da qualidade para minimizar seu impacto no movimento em direção à meta. É isso que nos espera no mundo do DevOps. ”
Como escalar DevOps: 10 dicas de especialistas
Apenas DevOps e DevOps maciço são duas coisas completamente diferentes. Nós lhe diremos como superar as barreiras do primeiro ao segundo.Para muitas organizações, o caminho para o DevOps começa de maneira fácil e agradável. Pequenas equipes apaixonadas são criadas, processos antigos são substituídos por novos e os primeiros sucessos não demoram a chegar.
Infelizmente, isso é apenas um brilho falso, uma ilusão de progresso, de acordo com Ben Grinnell, diretor-gerente e chefe de tecnologia digital da empresa de consultoria North Highland. As vitórias iniciais são certamente encorajadoras, mas não ajudam a alcançar o objetivo final, a saber, o uso massivo de DevOps na organização.
É fácil perceber que, como resultado, é formada uma cultura de separação entre "nós" e "eles".“Muitas vezes, as organizações lançam projetos pioneiros, acreditando que abrirão o caminho para DevOps em massa, sem hesitação, eles podem e vão querer que outras pessoas sigam esse caminho”, explica Ben Grinnel. - As equipes para a implementação de tais projetos geralmente são recrutadas por “vikings” autoconfiantes que já fizeram algo semelhante em outros lugares, mas são novos na sua organização. Ao mesmo tempo, são incentivados a quebrar e destruir as regras que permanecem vinculativas para todos os outros. É fácil perceber que, como resultado, é formada uma cultura de separação entre "nós" e "eles", o que impede a transferência de conhecimentos e habilidades ".
“E essa questão cultural é apenas uma das razões pelas quais é difícil escalar o DevOps. As equipes de DevOps são confrontadas com o crescimento de dificuldades puramente técnicas, características de empresas de rápido crescimento que confiam na tecnologia de TI ”, disse Steve Newman, fundador e presidente do conselho da Scalyr.
“No mundo moderno, os serviços mudam assim que essa necessidade surge. É claro que continuar implementando e implementando novos recursos é ótimo, mas coordenar esse processo e corrigir problemas é uma verdadeira dor de cabeça ”, acrescenta Steve Newman. - Em organizações de rápido crescimento, os engenheiros, como parte de equipes multifuncionais, lutam para manter a capacidade de rastrear alterações e os efeitos em cascata que geram no nível de dependência. Além disso, os engenheiros não ficam nada felizes quando são privados de tal oportunidade e, como resultado, fica mais difícil para eles entender a essência dos problemas que surgem. ”
Como superar essas dificuldades descritas acima e passar para o uso maciço do DevOps em uma grande organização? Os especialistas pedem que você seja paciente, 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 do Instituto DevOps: “Na minha opinião, a extensão DevOps deve ser tão gradual e iterativa quanto o desenvolvimento ágil (e afetar igualmente a cultura). O Agile e o DevOps se concentram em equipes pequenas. Mas à medida que o número e a integração dessas equipes aumentam, cada vez mais pessoas aplicam novos métodos de trabalho e, como resultado, surge uma transformação cultural em larga escala. ”
2. Gaste tempo suficiente planejando e escolhendo uma plataforma
Eran Kinsbruner, Evangelista Técnico Líder, Perfecto: “Para que o dimensionamento funcione, as equipes do DevOps precisam primeiro aprender como combinar processos, ferramentas e habilidades tradicionais, e depois crescer lentamente cada fase individual do DevOps e estabilizá-lo. Tudo começa com um planejamento cuidadoso de histórias de usuários e fluxos de valor (valuestream), seguido pelo estágio de criação de software e controle de versão usando desenvolvimento baseado em tronco ou outras abordagens mais adequadas para ramificação e mesclagem de código. ”
“Depois vem a fase de integração e teste, onde uma plataforma de automação escalável já é necessária. E aqui é importante que as equipes de DevOps escolham a plataforma certa que atenda ao seu nível de habilidade e aos objetivos finais do projeto.
A próxima fase é a implantação em um ambiente de produção e deve ser totalmente automatizada usando ferramentas e recipientes de orquestração. Ao mesmo tempo, é importante ter ambientes virtualizados em todas as etapas do DevOps (um simulador de ambiente de produção, um ambiente de controle de qualidade e, de fato, um ambiente de produção) e sempre usar apenas os dados mais recentes para testes, a fim de obter conclusões relevantes. O Analytics deve ser inteligente e capaz de processar grandes dados com feedback rápido e eficiente. ”
3. Livre-se do sabor culpado
Gordon Haff, evangelista da RedHat: “Criar um sistema e uma atmosfera que permita e incentive a experimentação nos permite perceber as chamadas falhas bem-sucedidas no desenvolvimento ágil de software. Isso não significa que ninguém mais seja responsável pelas falhas. De fato, é ainda mais fácil estabelecer uma pessoa responsável, pois "ser responsável" não significa mais "tornar-se o culpado do acidente". Ou seja, a essência da responsabilidade está mudando qualitativamente. Nesse caso, quatro fatores se tornam extremamente importantes: a magnitude da falha, abordagens, processos de produção e incentivos. ” (Para saber mais sobre esses fatores, consulte as lições de DevOps de Gordon Huff: 4 aspectos de experimentos saudáveis.)
4. Limpe o caminho a seguir
Ben Grinnell, diretor administrativo e chefe de tecnologia digital da North Highland Consulting: "Para expandir, recomendo que, juntamente com os projetos pioneiros, lançemos o programa Clearing Path. O objetivo deste programa é limpar o lixo que permanece com os pioneiros do DevOps, como regras que perderam relevância e outras coisas semelhantes, para que o caminho a seguir permaneça claro. ”
“Ofereça apoio organizacional às pessoas e incentive a comunicação que vai muito além do grupo pioneiro, comemorando amplamente o sucesso de novos métodos de trabalho. Treine as pessoas envolvidas na próxima onda de projetos do DevOps e que estejam nervosas em usar o DevOps pela primeira vez. E lembre-se de que essas pessoas são muito diferentes dos pioneiros. ”
5. Tornar 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 quem estiver disposto a gastar tempo com isso. Se a capacidade de solicitar logs for fornecida apenas a três pessoas que são "certificadas" para trabalhar com algum tipo de ferramenta, você sempre terá no máximo três pessoas que podem lidar com o problema correspondente, mesmo se você tiver um ambiente de computação muito grande. Em outras palavras, surge aqui um gargalo que pode levar a sérias conseqüências (para os negócios). ”
6. Crie condições ideais para o trabalho em equipe
Tom Clark, chefe da plataforma comum da ITV: “Você pode fazer qualquer coisa, mas não tudo de uma vez. Portanto, defina grandes metas, comece pequeno e avance com iterações rápidas. Com o tempo, você ganhará uma reputação de equipe bem-sucedida, para que outros também desejem usar seus métodos. E não procure construir uma equipe altamente eficaz. Em vez disso, fornecer às pessoas as condições ideais de trabalho e a eficiência surgirão por si só. ”
7. Não esqueça a lei de Conway e os conselhos Kanban
Logan Daigle, diretor de estratégia e entrega de software da CollabNetVersionOne DevOps: "É importante entender as consequências da lei de Conway. Na minha paráfrase gratuita, esta lei afirma que os produtos que criamos e os processos que usamos, incluindo DevOps, acabam sendo os mesmos da nossa organização. ”
“Se a organização é altamente fragmentada e, ao planejar, criar e liberar software, o gerenciamento passa de mão em mão muitas vezes, o efeito da escala será zero ou terá vida curta. Se a organização formar equipes multifuncionais em torno de produtos que são financiados com uma orientação de mercado, as chances de sucesso aumentam dramaticamente. ”
“Outro aspecto importante do dimensionamento é exibir nos quadros Kanban todo o trabalho em andamento (WIP, progresso do trabalho). Quando uma organização aparece em um lugar onde as pessoas podem ver essas coisas, ela estimula bastante a cooperação, o que tem um efeito positivo no dimensionamento. ”
8. Procure cicatrizes antigas
Manuel Pais, consultor de DevOps e co-autor de Team Topologies: “Levar as práticas do DevOps além do próprio Devi Ops e tentar aplicá-las a outras funções dificilmente pode ser chamada de abordagem ideal. Isso sem dúvida dará um certo efeito (por exemplo, devido à automação do controle manual), mas muito mais poderá ser alcançado se começarmos com uma compreensão dos processos de entrega e feedback. ”
"Se houver cicatrizes antigas no sistema de TI da organização - procedimentos e mecanismos de gerenciamento que foram implementados como resultado de incidentes passados, mas perderam sua relevância (devido a uma alteração nos produtos, tecnologias ou processos), eles certamente precisam ser removidos ou suavizados, e não automatizar processos ineficientes ou desnecessários ".
9. Não gerar opções de DevOps
Anthony Edwards, diretor de produção de berinjela: “DevOps é um termo muito vago, para que cada equipe tenha sua própria versão do DevOps. E não há nada pior quando 20 variedades de DevOps aparecem imediatamente na organização, o que não se dá muito bem. Cada uma das três equipes de desenvolvimento não pode ter sua própria interface especial entre desenvolvimento e gerenciamento de produtos. Como é impossível que os produtos tenham suas próprias expectativas únicas em relação ao processamento de feedback ao transferir o ambiente de produção para o simulador. Caso contrário, você nunca poderá escalar DevOps. "
10. Pregue o valor do DevOps para negócios
Steve Newman, fundador e presidente da Scalyr: “Trabalhe para reconhecer o valor do DevOps. Aprenda e sinta-se à vontade para falar sobre os benefícios do que você faz. O DevOps economiza incrivelmente tempo e dinheiro (pense: menos tempo de inatividade, menor tempo médio de recuperação) e as equipes do DevOps devem enfatizar (e pregar) incansavelmente a importância dessas iniciativas para o sucesso dos negócios. Assim, você pode expandir o círculo de adeptos e fortalecer a influência do DevOps na organização. "
BÔNUS
Em 13 de setembro, nosso próprio DevOps chegará ao Fórum da Red Hat na Rússia - sim, a Red Hat, como fabricante de software, tem suas próprias equipes e práticas de DevOps.Nosso engenheiro Mark Birger, que está desenvolvendo serviços de automação interna para outros grupos em toda a organização, conta sua própria história em russo puro - como a equipe do Red Hat DevOps migrou aplicativos da Ansible dos ambientes gerenciados do Hat Virtualization para um formato de contêiner completo na 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. No segundo relatório, explicaremos nossa motivação para mudar o método de registro e mostrar a continuação do caminho que nos levou a métodos modernos de registro em diário e monitoramento.