O que é DevOps

Definir o DevOps é muito complicado, então você precisa reiniciar a discussão sobre isso sempre. Somente em Habré mil publicações sobre esse assunto. Mas se você ler isso, provavelmente saberá o que é DevOps. Porque eu não. Olá, meu nome é Alexander Titov (@ osminog ) e falaremos sobre DevOps e compartilharei minha experiência.



Pensei por muito tempo em como tornar minha história útil, para que haja muitas perguntas aqui - aquelas que eu me pergunto e aquelas que peço aos clientes de nossa empresa. Ao responder a essas perguntas, o entendimento está melhorando. Vou lhe dizer por que o DevOps é necessário do meu ponto de vista, o que é, novamente, da minha posição e como entender que você está mudando para o DevOps novamente do meu ponto de vista. O último item será através de perguntas. Ao respondê-los você mesmo, você pode entender se sua empresa está migrando para o DevOps ou se há problemas em alguma coisa.


Ao mesmo tempo, caminhei pelas ondas de fusões e aquisições. No começo, trabalhei em uma pequena startup Qik, depois foi comprada por uma empresa um pouco maior do Skype, que foi comprada por uma empresa um pouco maior da Microsoft. Naquele momento, uma visão ficou disponível para mim como a idéia do DevOps estava sendo transformada em diferentes empresas. Depois disso, tornou-se interessante observar o DevOps do ponto de vista do mercado, e meus colegas e eu organizamos a empresa Express 42. Há 6 anos, avançamos sobre ele nas ondas do mercado.

Entre outras coisas, sou um dos organizadores da comunidade DevOps Moscou e o organizador do DevOps -Days 2017, mas não organizei 2018. O Express 42 trabalha com muitas empresas. Germinamos o DevOps lá, vemos como isso acontece, tiramos conclusões, analisamos, informamos nossas descobertas a todos, ensinamos às pessoas as práticas de DevOps. Em geral, de todas as formas, desenvolvemos experiência e conhecimento.

Por que DevOps

A primeira pergunta que assombra todos e sempre - por quê? Muitas pessoas pensam que o DevOps é apenas automação ou algo semelhante a todas as empresas.

- Tivemos integração contínua - ou seja, já havia DevOps, e por que todos esses topos são necessários? Eles se divertem no exterior, mas interferem no nosso trabalho!

Nos nove anos de desenvolvimento da comunidade e da metodologia, já ficou claro que essas não são lanças de marketing, mas ainda não está completamente claro por que é necessário. Como qualquer ferramenta e processo, o DevOps tem objetivos específicos que finalmente resolve.

Tudo isso se deve ao fato de o mundo estar mudando. Ele se afasta da abordagem empresarial, quando as empresas vão direto ao sonho, como cantou o clássico de São Petersburgo, do ponto A ao ponto B de acordo com uma certa estratégia, com uma certa estrutura construída para isso.

Em princípio, em TI tudo deve ser construído para essa abordagem. Aqui, a TI é usada exclusivamente para automação de processos.

A automação não muda com frequência, porque quando uma empresa segue uma trilha irregular - o que há para mudar? Funciona - não toque. Agora, no mundo, as abordagens estão mudando, e a chamada Agile diz que o terminal B não é imediatamente visível.



Quando uma empresa se move pelo mercado, trabalha com um cliente, pesquisa constantemente o mercado e muda seu ponto final B. Além disso, quanto mais a empresa muda de direção, mais bem-sucedida é no final, porque seleciona mais nichos de mercado.

A estratégia é demonstrada por uma empresa interessante, sobre a qual aprendi recentemente. One Box Shave - Um serviço de entrega de barbeadores e barbeadores por caixa. Eles sabem como personalizar sua "caixa" para diferentes clientes. Isso é feito por determinados softwares, que enviam um pedido para uma fábrica coreana que produz mercadorias.

Este produto foi comprado pela Unilever por US $ 1 bilhão. Agora ele está competindo com a Gillette e lhe roubou uma parcela significativa de consumidores no mercado dos EUA. O One Box Shave diz:

- 4 lâminas? Ta falando serio Por que você precisa disso - não melhora a qualidade do barbear. Um creme, perfume e uma lâmina de alta qualidade especialmente selecionados, com duas lâminas, resolvem muito mais questões do que essas estúpidas 4 lâminas da Gillette! Tão logo chegaremos a 10?

Então o mundo está mudando. A Unilever afirma ter um sistema de TI legal que permite isso. No final, parece um conceito de tempo de colocação no mercado sobre o qual ninguém já falou.



O objetivo do time-to-market não é a frequência com que implantamos. Muitas vezes você pode implantar, mas os ciclos de lançamento serão longos. Se os ciclos de liberação de três meses se sobrepõem, mudando uma semana, acontece que a empresa parece ser implantada uma vez por semana. E desde a ideia até a implementação final, 3 meses se passam.

O tempo de colocação no mercado consiste em minimizar o tempo, de uma idéia até a implementação final.

Nesse caso, o software interage com o mercado. É assim que o One Box Shave interage com o site. Eles não têm vendedores - apenas um site em que o visitante clica e deixa desejos. Por conseguinte, o site deve publicar constantemente algo novo, atualizá-lo de acordo com os desejos. Por exemplo, na Coréia do Sul, eles se barbearam diferentemente da Rússia e gostam do cheiro de pinheiro, mas, por exemplo, cenoura baunilha na fragrância.

Como você precisa alterar rapidamente o conteúdo do site, o desenvolvimento de software está mudando bastante. Através do software, precisamos descobrir o que o cliente deseja. Anteriormente, aprendemos isso com algumas soluções alternativas, por exemplo, através do gerenciamento de negócios. Então eles projetaram, estabeleceram os requisitos no sistema de TI e tudo foi legal. Agora é diferente - o software é projetado por todos os envolvidos no processo, incluindo engenheiros, porque eles aprendem através de especificações técnicas como o mercado funciona e também compartilham suas idéias com a empresa.

Por exemplo, no Qik, descobrimos repentinamente que as pessoas realmente gostam de fazer upload de listas de contatos no servidor e nos colocaram o aplicativo. Inicialmente, não pensamos nisso. Em uma empresa clássica, todos decidem que é um bug, já que as especificações não dizem que deve funcionar bem e geralmente foram implementadas no joelho, eles desativavam o recurso e diziam: “Isso não é necessário para ninguém, o mais importante é que a funcionalidade principal funcione” . E a empresa de tecnologia vê isso como uma oportunidade e começa a mudar o software de acordo com isso.



Em 1968, o visionário Melvin Conway formulou a seguinte idéia.

A organização que cria o sistema é limitada a um design que copia a estrutura de comunicação nessa organização.

Mais detalhadamente, para produzir sistemas de um tipo diferente, é preciso também ter uma estrutura de comunicação dentro de uma empresa de outro tipo. Se a sua estrutura de comunicação for hierárquica superior, isso não permitirá que você crie sistemas que possam fornecer um indicador de tempo de lançamento no mercado muito alto.

Você pode ler sobre a lei de Conway seguindo os links . É importante para entender a cultura ou filosofia do DevOps, pois a única coisa que muda fundamentalmente no DevOps é a estrutura de comunicação entre as equipes .

Do ponto de vista do processo, antes do DevOps, todas as etapas: análise, desenvolvimento, teste, operação eram lineares.
No caso do DevOps, todos esses processos ocorrem simultaneamente.



O tempo de colocação no mercado só pode ser feito dessa maneira. Para as pessoas que trabalharam no processo antigo, parece um pouco cósmico e geralmente mais ou menos.

Então, por que você precisa do DevOps?

Para o desenvolvimento de produtos digitais . Se você não possui um produto digital em sua empresa, o DevOps não é necessário - isso é muito importante.

O DevOps supera os limites de velocidade de um esquema consistente de produção de software . Nele, todos os processos ocorrem simultaneamente.

Aumenta a dificuldade. Quando os evangelistas do DevOps lhe dizem que será mais fácil lançar um software com ele, isso não faz sentido.

Com o DevOps, as coisas só ficam mais complicadas.

Na conferência no estande da Avito, era possível ver o que é implantar um contêiner Docker - uma tarefa irrealista. A complexidade se torna proibitiva, você precisa fazer malabarismos com muitas bolas ao mesmo tempo.

O DevOps altera completamente o processo e a organização na empresa - mais precisamente, não altera o DevOps, mas um produto digital. Para chegar ao DevOps, você ainda precisa alterar completamente esse processo.

Perguntas para um especialista

E você? Perguntas que você pode fazer quando estiver trabalhando em uma empresa e se desenvolvendo como especialista.

Você tem uma estratégia de produto digital? Se houver, já é bom. Isso significa que sua empresa está migrando para o DevOps.

Sua empresa já está criando um produto digital? Isso significa que você pode subir outro nível e fazer coisas mais interessantes - novamente, do ponto de vista do DevOps. Eu só falo deste ponto de vista.

Sua empresa é uma das líderes de mercado em um nicho com um produto digital? Spotify, Yandex, Uber - empresas que estão no auge do progresso tecnológico agora.

Faça a si mesmo essas perguntas e, se todas as respostas forem negativas, talvez você não deva lidar com o DevOps nesta empresa. Se o tema do DevOps é realmente interessante para você, talvez ... você deveria mudar para outra empresa? Se sua empresa deseja acessar o DevOps, mas você respondeu "Não" a todas as perguntas, é semelhante a esse belo rinoceronte que nunca mudará.

Organização

Como eu disse, de acordo com a lei de Conway, uma organização muda em uma empresa. Para começar, o que impede o DevOps de entrar na empresa do ponto de vista da organização.

O problema dos "poços"

A palavra em inglês "Silo" é traduzida aqui para o russo como "bem". O significado desse problema é que entre as equipes não há troca de informações . Cada equipe estuda profundamente seus conhecimentos, sem criar um mapa comum no qual você possa navegar.

De certa forma, parece uma pessoa que acaba de chegar a Moscou e ainda não sabe como navegar no mapa do metrô. Os moscovitas geralmente conhecem muito bem sua área e, em Moscou, são guiados pelo mapa do metrô. Quando você vem a Moscou pela primeira vez, não existe essa habilidade e você está simplesmente desorientado.

O DevOps se oferece para passar esse momento de desorientação e para todos os departamentos juntos para criar um mapa comum de interação.

Dois fatores interferem nisso.

Uma conseqüência do sistema de gerenciamento corporativo. É construído por "poços" hierárquicos separados. Por exemplo, existem certos KPIs em empresas que suportam esse sistema. Por outro lado, os cérebros de uma pessoa que é difícil de ultrapassar os limites de seus conhecimentos e navegar por todo o sistema interferem. É apenas desconfortável. Imagine que você chegou ao aeroporto de Bangcoc - lá você não encontrará rapidamente seu rumo. O DevOps também é difícil de navegar e, portanto, as pessoas dizem que você precisa encontrar um guia para encontrá-lo.

Mas o mais importante é que o problema dos "poços" para um engenheiro que foi inspirado pelo espírito do DevOps, foi lido por Fowler e vários outros livros, é expresso no fato de que "poços" não permitem que você faça coisas "óbvias" . Geralmente nos reunimos depois do DevOps Moscow, conversamos e as pessoas reclamam:

- Nós apenas queríamos lançar o CI, mas acabou que a gerência não precisava.

Isto é precisamente devido ao fato de o CI e o processo de Entrega Contínua estarem na fronteira de muitos exames. Apenas não superando o problema dos “poços” no nível organizacional, você não poderá avançar mais, faça o que fizer e quão triste pode ser.



Cada participante do processo na empresa: desenvolvedores de back-end e front-end, testes, DBA, operação, rede, procura em sua própria direção, e ninguém tem um cartão em comum, exceto um gerente que de alguma forma observa e controla o método de dividir e conquistar.

As pessoas lutam por algumas estrelinhas ou bandeiras, cada uma cava sua própria experiência.

Como resultado, quando a tarefa parece conectar tudo isso e construir um pipeline comum, e não há necessidade de lutar pelas estrelas e bandeiras, surge a pergunta - o que devo fazer? De alguma forma, devemos concordar, mas ninguém nos ensinou como fazer isso. Fomos ensinados na escola: a oitava série - uau! - comparado com a sétima série! É o mesmo aqui.

É o mesmo em sua empresa?

Para verificar isso, você pode fazer as seguintes perguntas.

As equipes usam ferramentas comuns, elas contribuem para alterações nessas ferramentas comuns?

Com que frequência as equipes são reformadas? Alguns especialistas de uma equipe se mudam para outra? É no ambiente do DevOps que isso se torna normal, porque às vezes uma pessoa simplesmente não consegue entender o que outra área de especialização está fazendo. Ele se muda para outro departamento, trabalha lá por duas semanas para criar para si um mapa de orientação e interação com esse departamento.

É possível criar um comitê sobre mudança e mudar alguma coisa? Ou isso requer uma mão forte da mais alta liderança e direção? Recentemente, escrevi no Facebook como um banco pouco conhecido implementa ferramentas através de pedidos: escrevemos um pedido, implementamos por um ano e veremos o que acontece. Isso, é claro, é longo e triste.

Quão importante é para os gerentes receberem conquistas pessoais sem levar em conta as conquistas da empresa?

Se você responder essas perguntas por si mesmo, ficará mais claro se você tiver esse problema na empresa.

Infraestrutura como código

Depois que esse problema foi resolvido, a primeira prática importante, sem a qual é difícil avançar no DevOps, é a infraestrutura como código .

Na maioria das vezes, a infraestrutura como um código é percebida da seguinte maneira:

- Vamos automatizar tudo no bash, nos cobrir com scripts para que a área de administração tenha menos trabalho manual!

Mas isso não é verdade.

A infra-estrutura como um código implica que você descreva o sistema de TI com o qual trabalha para entender constantemente seu status.

Juntamente com outras equipes, você cria um mapa na forma de um código que todos entendem, que você pode navegar e navegar. Não importa o que é feito - os arquivos Chef, Ansible, Salt ou YAML são usados ​​no Kubernetes - não há diferença.

Na conferência, um colega do 2GIS falou sobre como eles criaram suas próprias coisas internas para o Kubernetes, que descreve a estrutura de sistemas individuais. Para descrever 500 sistemas, eles precisavam de uma ferramenta separada que gere essa descrição. Quando existe essa descrição, todos podem verificar entre si, monitorar alterações, como alterá-las e melhorá-las, o que está faltando.

Concorde, scripts bash separados geralmente não dão esse entendimento. Em uma das empresas em que trabalhei, havia até um nome “somente gravação” - um script - quando o script é escrito, e já é impossível lê-lo. Eu acho que isso é familiar para você também.

Infraestrutura como um código é um código que descreve o estado atual da infraestrutura . Muitas equipes de produtos, infraestrutura e serviço trabalham juntas nesse código e, o mais importante, todas elas precisam entender como esse código geralmente funciona.

O código é acompanhado de acordo com as melhores práticas de trabalho com código : desenvolvimento conjunto, revisão de código, programação XP, testes, pull-quests, IC para infra-estruturas de código - tudo isso é adequado e pode ser usado.

O código está se tornando uma linguagem comum para todos os engenheiros.

Alterar a infraestrutura no código não leva muito tempo . Sim, também pode haver dívida técnica no código de infraestrutura. Geralmente, as equipes o encontram um ano e meio depois de começarem a implementar a “infraestrutura como código” na forma de vários scripts ou mesmo Ansible, que eles escrevem como código espaguete, e até scripts bash colocam no firebox!

Importante : se você ainda não experimentou, lembre-se de que o Ansible não é uma festa ! Leia a documentação com cuidado, estude o que eles geralmente escrevem sobre ela.

Infraestrutura como código é a divisão do código de infraestrutura em camadas separadas.

Em nossa empresa, distinguimos três camadas básicas, muito claras e simples, mas pode haver mais. Você pode olhar para o seu código de infraestrutura e dizer se você tem essa condição ou não. Se nenhuma camada estiver destacada, você precisará alocar tempo e refatorar um pouco.


A camada base é como o sistema operacional, os backups e outras coisas de baixo nível são configurados, por exemplo, como o Kubernetes é implantado em um nível básico.

O nível de serviços são aqueles que você fornece ao desenvolvedor: log como serviço, monitoramento como serviço, banco de dados como serviço, balanceador como serviço, fila como serviço, Entrega Contínua como serviço - um conjunto de serviços que equipes individuais podem fornecer desenvolvimento. Tudo isso deve ser descrito como módulos separados em seu sistema de gerenciamento de configuração.

A camada em que os aplicativos são feitos e como eles serão implantados sobre as duas camadas anteriores.

Questões de segurança

Você tem um repositório de infraestrutura comum em sua empresa? Você controla a dívida técnica em infraestrutura? Você usa práticas de desenvolvimento no repositório de infraestrutura? Sua infraestrutura é cortada? Você pode verificar o esquema APP de serviço básico. Quão difícil é fazer uma mudança?

Se você se deparar com o fato de que a introdução de mudanças levou um dia e meio, isso significa que você tem uma dívida técnica e precisa trabalhar com ela. Você acabou de encontrar uma dívida técnica no código de infraestrutura. Lembro-me de muitas dessas histórias em que, para alterar qualquer CCTL, é necessário reescrever metade do código de infraestrutura, porque a criatividade e o desejo de automatizar tudo levaram ao fato de que em todo lugar tudo fica em curto, todas as canetas são removidas e você precisa refatorar.

Entrega contínua

Débito semelhante com um empréstimo. Primeiro, uma descrição da infraestrutura é exibida, o que pode ser bastante básico. Não é necessário descrever tudo em detalhes, mas é necessária uma descrição básica para que você possa trabalhar com ele. Caso contrário, não está claro além do que mais fazer entrega contínua. Todas essas práticas se desenvolvem ao mesmo tempo em que você acessa o DevOps, mas é necessário começar entendendo o que você tem e como gerenciá-lo. Essa é apenas a prática da infraestrutura como código.

Depois que ficou claro que você tem como gerenciar isso, começa a pensar em como enviar o código do desenvolvedor para produção o mais rápido possível. Quero dizer, junto com o desenvolvedor - lembramos do problema dos "poços", ou seja, não as pessoas individuais apresentam isso, mas a equipe.

Quando Vanya Yevtukhovich e eu vimos o primeiro livro de Jes Hamble e o grupo de autores “Entrega Contínua” , lançado em 2009, pensamos por um longo tempo como traduzir seu nome para o russo. Eles queriam traduzi-lo como "Entrega constante", mas, infelizmente, traduzido como "Entrega contínua". Parece-me que há algo russo em nosso título com pressão.

Entregue constantemente - isso significa

O código que está no repositório de compras sempre pode ser baixado na produção . Pode não estar vazio, mas está sempre pronto para isso. Assim, você sempre escreve código com uma dificuldade difícil de explicar, com alguma preocupação sob o cóccix. Geralmente aparece quando você lança o código de infraestrutura. — , -. .

, , . « », , , . — : , .

- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

Comentários

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

, , - : .

DevOpsConf 2019 . ++. , , DevOps-. , 20