DevOps: o que é realmente

Olá pessoal!

Imprimimos o livro "DevOps Philosophy" e também planejamos criar um novo livro sobre esse tópico.


Muitas cópias são quebradas sobre o que o DevOps é ou não, assim como o relacionamento entre o DevOps e a integração contínua. Portanto, pedimos que você fale da maneira mais objetiva possível. Você compartilha o ponto de vista do autor de hoje Adam Mackay (Adam Mackay) sobre a essência do DevOps - ou, na sua opinião, a imagem que ele propôs é um tanto incompleta ou tendenciosa?

Nós lemos e comentamos!

Trabalho no campo tecnológico a vida toda e, diante de meus olhos, várias metodologias de desenvolvimento de software amadureceram e se formaram. A maioria das idéias subjacentes se resume à otimização usual da produtividade, no espírito do senso comum, e é emprestada de diferentes setores da economia. Alguns anos atrás, todos queriam mudar de um modelo de desenvolvimento em cascata para um desenvolvimento ágil e ágil. Recentemente, fui trabalhar em uma empresa progressista, onde eles estão tentando implementar o DevOps. Essa empresa, Verifa, adere há muito tempo ao Agile e está tentando estender as vantagens desse modelo não apenas ao desenvolvimento de software, mas também aos negócios como um todo.

DevOps é uma nova palavra da moda na indústria de software. Esse conceito combina muitas idéias sólidas sobre a integração de negócios e desenvolvimento, além de formular uma narrativa que nos permite falar sobre o desenvolvimento, entrega e operação de software em um único contexto.



O DevOps é uma abordagem na qual engenheiros de desenvolvimento e engenheiros administrativos participam juntos de todo o ciclo de vida de um produto de software, do design e desenvolvimento ao suporte completo ao produto. Assim, o DevOps foi projetado para eliminar a desunião tradicional, onde uma equipe escreve o código, o outro o testa, o terceiro é implantado e o quarto é responsável pela operação.

Com o DevOps, os funcionários do administrador de sistemas começam a usar, com o suporte dos sistemas que lhes foram confiados, muitas das técnicas que foram corrigidas no arsenal do desenvolvedor. No DevOps, a engenharia de sistemas é criada exatamente como um fluxo de tarefas durante o desenvolvimento. Todos os recursos são inseridos no sistema de contabilidade de origem e cobertos por testes apropriados.

Temos vários tópicos principais de DevOps em nossa empresa: valores, princípios, métodos, práticas e ferramentas.



Valores

Qualquer engenheiro é preso por encontrar uma solução, e essa aspiração às vezes se traduz em uma rejeição de novas tecnologias, uma falta de vontade de experimentar coisas novas, que são expressas de maneiras diferentes: da síndrome da "rejeição do desenvolvimento de outro" às tentativas contraproducentes de defender o nicho de alguém. Para realmente fazer a transição para o DevOps, esses preconceitos devem primeiro ser reconhecidos e depois superados. Nenhuma tecnologia, nem o Docker, o Kubernetes ou o Amazon Web Services resolverão seus problemas se você não entender qual é a proposta de valor.



"De mãos dadas, amigos!" Instantâneo Rawpixel de Unsplash

Princípios

Os princípios de nossa empresa são baseados no modelo das três maneiras. Foi desenvolvido por Gene Kim, autor de "Visible Ops" e "The Phoenix Project", e Mike Orzen, autor de "Lean IT". Recomendamos a construção de um ambiente no qual o pensamento sistêmico seja estimulado, os ciclos de feedback sejam fortalecidos e uma cultura de experimentação e aprendizado contínuos seja instilada.
Pense constantemente em todo o sistema. Pergunte a si mesmo: "Como você obtém ainda mais loops de feedback?" Monitoramento, métricas e log são três desses ciclos que ajudam os administradores a participar do design. Em um ambiente saudável de DevOps, são estimulados processos que promovem a criação de ciclos de feedback curtos e eficazes, exemplos de tais processos são gerenciamento de incidentes, análise objetiva de post-mortem, transparência ...



“Aperto de mão antes do MacBook Pro”, um instantâneo de rawpixel da Unsplash

Métodos

Gerenciamento flexível

Flexível = simples. Divida seu projeto em pequenas áreas de trabalho, construa, limitando o limite de progresso, implemente ciclos de feedback e obtenha visualização. Este é o meu elemento favorito de qualquer projeto; técnicas de gerenciamento flexíveis produzem resultados mais eficazes, incluindo melhoria da produtividade e estabilidade do sistema; os funcionários experimentam menos estresse no trabalho e obtêm mais satisfação no trabalho.

Pessoas primeiro, depois processos e ferramentas

Uma das primeiras metodologias propostas pelos pioneiros do DevOps é formulada como “primeiro pessoal, depois processa e depois ferramentas”. Em nossa empresa, é recomendável que você primeiro concorde com quem é responsável por uma tarefa de trabalho específica. Em seguida, determinamos quais processos são necessários para resolver esse problema. Depois disso, são selecionadas as ferramentas necessárias para a implementação do processo. No papel, tudo isso parece lógico, no entanto, engenheiros e gerentes frequentemente sucumbem à cativante "pressa de obtê-lo!" dos fornecedores e, nesse caso, eles estão tentando fazer exatamente o oposto: comprar uma ferramenta e formar todo o fluxo de tarefas para ela.

Entrega contínua

Esse termo é tão comum nos lábios de todos que, às vezes, é equivocado equivocadamente com o DevOps. Em princípio, essa é a prática de programação dinâmica e teste de software, fornecendo lançamentos rápidos de fragmentos muito pequenos, completos e prontos. Em geral, a entrega contínua pode melhorar a qualidade e a velocidade gerais. A entrega contínua é um componente essencial do projeto, que deve ser estabelecido o mais cedo possível, o fator determinante para a implementação bem-sucedida do DevOps.

Gerenciamento de mudanças



Na minha experiência, existe uma correlação direta entre o quão bem o sistema está sendo operado e como o gerenciamento de mudanças está organizado. Isso não significa que você precise implementar o controle tradicional, o que atrasa o desenvolvimento e é mais provável que seja prejudicial do que ajudar. Nesse caso, você precisa de uma plataforma escalável e confiável para entrega contínua. Concentre-se na eliminação de artefatos frágeis, na reprodutibilidade do processo de construção, no gerenciamento de dependências e na criação de um ambiente propício à melhoria contínua.

Infraestrutura no código (Configuração no código ... Tudo no código)

Uma das revelações com as quais a empresa atual me enriqueceu é que qualquer sistema pode e deve ser interpretado como código. As especificações do sistema são inseridas nos sistemas de controle de versão e revisadas por pares. Usando mecanismos modernos de implantação, em especial o Docker e o Kubernetes, você pode criar, testar e criar automaticamente sistemas reais com base nas especificações e gerenciá-los programaticamente. Essa abordagem permite que você compile e execute o sistema, e não faça muletas trabalhosas a longo prazo, que com o tempo se tornam muito difíceis de desenvolver.

Prática

Em todas as organizações de TI anteriores em que trabalhei, a abordagem dos projetos foi: "vamos escrever algo ... e depois instruiremos alguém a testá-lo e implantá-lo". Esse método não se encaixa bem nos planos: o tempo muda e, quando a equipe de desenvolvimento passa para o próximo projeto, os custos operacionais tornam-se insuportáveis.



“Montanha russa sob um céu azul e nuvens brancas”, um instantâneo de Priscilla Du Preez da Unsplash

Na organização atual, nos esforçamos para manter os desenvolvedores a par do serviço que eles criaram e parcialmente responsáveis ​​por sua operação. O resultado são ciclos de feedback mais eficientes que ajudam a equipe a responder muito mais rapidamente, não apenas aos bugs, mas também aos novos recursos e garantem que o produto se desenvolva na direção certa.

As ferramentas

Adoramos nossas ferramentas! Eles ajudam o engenheiro a programar, montar, testar, empacotar, liberar, configurar e rastrear sistemas e aplicativos. Nós possuímos nossas ferramentas com maestria e conhecemos toda a gama de soluções que nos interessam - de código aberto e comercial. Antes do desenvolvimento do paradigma DevOps, a inovação e as ferramentas estavam estagnadas. Durante muito tempo, usei as mesmas ferramentas do início da minha carreira (programa desde 2000). Muitas das ferramentas usadas no DevOps são incrivelmente versáteis e ajudam a organizar o ciclo de vida do serviço de uma maneira completamente nova.



“Todos os tipos de ferramentas de carpintaria na oficina” da coleção Barn Images da Unsplash

Você precisa decidir sobre ferramentas confiáveis ​​para o DevOps. Não existe uma ferramenta única para todas as ocasiões, você precisa de uma linha inteira, cujo inventário pode ser combinado levando em consideração as necessidades existentes. E como queremos que tudo isso funcione juntos ... qualquer ferramenta é tão útil quanto ajuda todo o nosso sistema.

Você precisa escolher ferramentas que funcionem bem com o restante do seu inventário. As ferramentas devem ajudar a automatizar qualquer trabalho. Eles devem ser fáceis de chamar da API ou da linha de comando. Em princípio, as ferramentas altamente dependentes da interface do usuário não se encaixam muito bem, mesmo em ferramentas bem integradas.

O que vem a seguir ...

Faça o download da imagem do Docker e comece a experimentar. Bifurque o código de outra pessoa e comece a construí-lo. Implante um servidor ou cluster de servidores com o Kubernetes. Então você faz DevOps. Inicie no seu próprio computador e vá para a nuvem.



“Um garoto parado na escada e alcançando as nuvens”, filmado por Samuel Zeller da Unsplash

Quando você ouve pela primeira vez sobre o paradigma de "infraestrutura em código" ou "entrega contínua", imediatamente deseja dizer "não, funciona de maneira diferente conosco". No entanto, para ter sucesso com o DevOps, você precisa dominar gradualmente essas técnicas, elas não são tão complicadas. Por muitos anos, o setor usou métodos exatamente opostos ao DevOps, mas o DevOps realmente funciona.