A definição de DevOps é muito complexa, por isso temos que recomeçar a discussão sobre isso todas as vezes. Existem mil publicações sobre este tema só em Habré. Mas se você está lendo isso, provavelmente sabe o que é DevOps. Porque eu não sou. Olá meu nome é Alexandre Titov (@) e falaremos apenas sobre DevOps e compartilharei minha experiência.
Há muito tempo que penso em como tornar a minha história útil, por isso haverá muitas perguntas aqui - aquelas que faço a mim mesmo e aquelas que faço aos clientes da nossa empresa. Ao responder a essas perguntas, a compreensão se torna melhor. Vou lhe dizer por que o DevOps é necessário do meu ponto de vista, o que é, novamente, do meu ponto de vista e como entender que você está caminhando novamente para o DevOps do meu ponto de vista. O último ponto será por meio de perguntas. Ao respondê-las você mesmo, você poderá entender se sua empresa está caminhando para o DevOps ou se há problemas de alguma forma.
Houve uma época em que eu estava navegando nas ondas de fusões e aquisições. Primeiro, trabalhei para uma pequena startup chamada Qik, depois ela foi comprada por uma empresa um pouco maior chamada Skype, que depois foi comprada por uma empresa um pouco maior chamada Microsoft. Naquele momento, comecei a ver como a ideia de DevOps estava se transformando em empresas de diferentes portes. Depois disso, fiquei interessado em olhar o DevOps do ponto de vista do mercado, e meus colegas e eu fundamos a empresa Express 42. Há 6 anos que seguimos as ondas do mercado.
Entre outras coisas, sou um dos organizadores da comunidade DevOps Moscou e organizador do DevOps-Days 2017, mas não organizei 2018. Express 42 trabalha com muitas empresas. Desenvolvemos o DevOps lá, observamos como isso acontece, tiramos conclusões, analisamos, contamos a todos nossas conclusões e treinamos pessoas em práticas de DevOps. Em geral, estamos fazendo o possível para aumentar nossa experiência e conhecimento nesse sentido.
Por que DevOps
A primeira pergunta que sempre assombra a todos é: por quê? Muitas pessoas pensam que DevOps é apenas automação ou algo semelhante que toda empresa já tinha.
— Tínhamos Integração Contínua – isso significa que já tínhamos DevOps, e por que tudo isso é necessário? Eles estão se divertindo no exterior, mas nos impedem de trabalhar!
Ao longo de 9 anos de desenvolvimento da comunidade e da metodologia, já ficou claro que isso ainda não é brilho de marketing, mas ainda não está totalmente claro por que é necessário. Como qualquer ferramenta e processo, o DevOps tem objetivos específicos que, em última análise, atinge.
Tudo isso se deve ao fato de o mundo estar mudando. Ele se afasta da abordagem empresarial, quando as empresas caminham direto em direção a um sonho, como cantava nosso clássico de São Petersburgo, do ponto A ao ponto B de acordo com uma determinada estratégia, com uma determinada estrutura construída para isso.
Em princípio, tudo em TI deveria ser construído de acordo com esta abordagem. Aqui a TI é usada exclusivamente para automatizar processos.
A automação não muda com frequência, porque quando uma empresa segue um caminho trilhado, o que há para mudar? Funciona - não toque nele. Agora as abordagens no mundo estão mudando, e aquela chamada Agile sugere que o ponto final B não é imediatamente visível.
Quando uma empresa passa pelo mercado, trabalha com um cliente, ela explora constantemente o mercado e muda o ponto final B. Além disso, quanto mais a empresa muda de rumo, mais sucesso ela tem no final, porque escolhe mais mercado nichos.
A estratégia é demonstrada por uma empresa interessante que conheci recentemente. One Box Shave é um serviço de entrega por assinatura de lâminas de barbear e acessórios de barbear em uma caixa. Eles sabem personalizar sua “caixa” para diferentes clientes. Isso é feito por um determinado software, que então envia o pedido para a fábrica coreana que produz a mercadoria.
Este produto foi comprado pela Unilever por US$ 1 bilhão. Agora compete com a Gillette e conquistou uma parcela significativa de consumidores no mercado americano. Uma caixa de barbear diz:
— 4 lâminas? Você está falando sério? Por que você precisa disso - não melhora a qualidade do barbear. Um creme especialmente selecionado, uma fragrância e uma navalha de alta qualidade com duas lâminas resolvem muito mais problemas do que aquelas estúpidas 4 lâminas Gillette! Chegaremos a 10 em breve?
É assim que o mundo muda. A Unilever afirma ter um sistema de TI interessante que permite fazer isso. No final parece um conceito Tempo de lançamento no mercado, sobre o qual ninguém ainda falou.
O objetivo do tempo de lançamento no mercado 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 lançamento de três meses se sobrepõem, mudando-os em uma semana, acontece que a empresa parece estar implantando uma vez por semana. E da ideia à implementação final demoram 3 meses.
O tempo de lançamento no mercado consiste em minimizar o tempo desde a ideia até a implementação final.
Nesse caso, o software interage com o mercado. É assim que o site One Box Shave interage com o cliente. Eles não têm vendedores – apenas um site onde os visitantes clicam e deixam desejos. Dessa forma, novidades devem ser constantemente postadas no site e atualizadas de acordo com a vontade. Por exemplo, na Coreia do Sul eles se barbeiam de maneira diferente do que na Rússia e gostam do cheiro não de pinho, mas, por exemplo, de cenoura e baunilha.
Como é necessário alterar rapidamente o conteúdo do site, o desenvolvimento de software muda bastante. Através do software devemos descobrir o que o cliente deseja. Anteriormente, aprendemos isso através de algumas formas indiretas, por exemplo, através da gestão empresarial. Depois projetamos, colocamos os requisitos no sistema de TI e tudo ficou bem. Agora é diferente – o software é projetado por todos os envolvidos no processo, inclusive engenheiros, pois por meio de especificações técnicas eles aprendem como funciona o mercado e também compartilham seus insights com o negócio.
Por exemplo, na Qik descobrimos de repente que as pessoas realmente gostavam de enviar listas de contatos para o servidor e nos forneceram um aplicativo. Inicialmente não pensamos nisso. Em uma empresa clássica, todos teriam decidido que isso era um bug, já que a especificação não dizia que deveria funcionar bem e geralmente era implementado no joelho, eles teriam desligado o recurso e dito: “Ninguém precisa disso, 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, um visionário, Melvin Conway, formulou a seguinte ideia.
A organização que cria o sistema é limitada por um design que replica a estrutura de comunicação dessa organização.
Mais detalhadamente, para produzir sistemas de outro tipo, é necessário 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, isso não permitirá que você crie sistemas que possam fornecer um indicador de tempo de lançamento no mercado muito alto.
Ler uma lata . É importante compreender a cultura ou filosofia DevOps porque 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 é a única maneira de fazer isso. Para as pessoas que trabalharam no processo antigo, isso parece um tanto cósmico e, geralmente, mais ou menos.
Então, por que você precisa de DevOps?
Para desenvolvimento de produtos digitais. Se a sua empresa não possui um produto digital, o DevOps não é necessário – é muito importante.
DevOps supera as limitações de velocidade da produção sequencial de software. Nele todos os processos ocorrem simultaneamente.
A dificuldade aumenta. Quando os evangelistas do DevOps dizem que será mais fácil lançar software, isso é um absurdo.
Com o DevOps, as coisas ficarão ainda mais complicadas.
Na conferência no estande da Avito, você pôde ver como era implantar um contêiner Docker - uma tarefa irreal. A complexidade torna-se proibitiva; você tem que fazer malabarismos com muitas bolas ao mesmo tempo.
DevOps muda completamente o processo e a organização da empresa — mais precisamente, não é o DevOps que muda, mas o produto digital. Para chegar ao DevOps, você ainda precisa mudar completamente esse processo.
Perguntas para um especialista
O que você tem? Perguntas que você pode se fazer enquanto trabalha em uma empresa e se desenvolve como especialista.
Você tem uma estratégia para criar um produto digital? Se houver, já está 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 as coisas de maneira mais interessante – novamente do ponto de vista do DevOps. Só estou falando deste ponto de vista.
A sua empresa é uma das líderes de mercado no nicho de produtos digitais? Spotify, Yandex, Uber são empresas que estão agora no auge do progresso tecnológico.
Faça essas perguntas a si mesmo e, se todas as respostas forem não, talvez você não deva fazer DevOps nesta empresa. Se o tema DevOps é realmente interessante para você, talvez... você devesse mudar para outra empresa? Se a sua empresa quer entrar no DevOps, mas você respondeu “Não” a todas as perguntas, então é como aquele lindo rinoceronte que nunca vai mudar.
Organização
Como disse, de acordo com a Lei de Conway, a organização de uma empresa muda. Começarei explicando o que impede o DevOps de penetrar na empresa do ponto de vista organizacional.
O problema dos "poços"
A palavra inglesa "Silo" é traduzida aqui para o russo como "bem". O ponto deste problema é que não há troca de informações entre equipes. Cada equipe se aprofunda em seus conhecimentos, sem construir um mapa comum para navegar.
De certa forma, isso me lembra uma pessoa que acabou de chegar a Moscou e ainda não sabe navegar no mapa do metrô. Os moscovitas geralmente conhecem muito bem sua área e podem navegar por Moscou usando o mapa do metrô. Quando você vem a Moscou pela primeira vez, você não tem essa habilidade e fica simplesmente desorientado.
DevOps sugere superar esse momento de desorientação e todos os departamentos trabalharem juntos para construir um mapa de interação comum.
Dois fatores dificultam isso.
Consequência do sistema de gestão corporativa. É construído em “poços” hierárquicos separados. Por exemplo, existem certos KPIs em empresas que suportam este sistema. Por outro lado, o cérebro de uma pessoa que tem dificuldade em ir além dos limites de sua especialização e navegar por todo o sistema atrapalha. É simplesmente desconfortável. Imagine que você está no aeroporto de Bangkok - você não encontrará o caminho rapidamente. O DevOps também é difícil de navegar, e é por isso que as pessoas dizem que você precisa encontrar um guia para chegar lá.
Mas o mais importante é que o problema dos “poços” para um engenheiro imbuído do espírito do DevOps, que leu Fowler e vários outros livros, se expressa no fato de que "poços" não permitem que você faça coisas "óbvias". Muitas vezes nos reunimos depois do DevOps Moscou, conversamos e as pessoas reclamam:
— Queríamos apenas lançar a CI, mas descobrimos que a gestão não precisava disso.
Isso acontece justamente porque CI и Processo de entrega contínua estão na fronteira de muitos exames. Simplesmente sem superar o problema dos “poços” no nível organizacional, você não conseguirá avançar, não importa o que faça e por mais triste que seja.
Cada participante do processo na empresa: desenvolvedores backend e frontend, testes, DBA, operação, rede, cava em sua própria direção, e ninguém tem um mapa comum exceto o gestor, que de alguma forma os monitora e gerencia usando o “dividir e conquistar”.
As pessoas estão lutando por algumas estrelas ou bandeiras, todos estão investindo em seus conhecimentos.
Como resultado, quando surge a tarefa de conectar tudo isso e construir um gasoduto comum, e não há mais necessidade de lutar por estrelas e bandeiras, surge a pergunta - o que fazer afinal? Precisamos chegar a um acordo de alguma forma, mas ninguém nos ensinou como fazer isso na escola. Fomos ensinados desde a escola: oitava série - uau! - em comparação com a sétima série! É a mesma coisa aqui.
É o mesmo na sua empresa?
Para verificar isso, você pode se fazer as seguintes perguntas.
As equipes usam ferramentas comuns e contribuem para mudanças nessas ferramentas comuns?
Com que frequência as equipes se reorganizam – alguns especialistas de uma equipe mudam para outra equipe? É em um ambiente DevOps que isso se torna normal, pois às vezes uma pessoa simplesmente não consegue entender o que outra área de atuaçã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 formar um comitê de mudança e mudar as coisas? Ou requer a mão forte da mais alta administração e direção? Escrevi recentemente no Facebook como um banco pouco conhecido está implementando ferramentas por meio de pedidos: escrevemos um pedido, implementamos por um ano e vemos o que acontece. Isto, claro, é longo e triste.
Quão importante é para os gestores receberem conquistas pessoais sem considerar as conquistas da empresa?
Se você mesmo responder a essas perguntas, ficará mais claro se você tem esse problema em sua empresa.
Infraestrutura como código
Passado esse problema, a primeira prática importante, sem a qual é difícil avançar ainda mais no DevOps, é infraestrutura como código.
Na maioria das vezes, a infraestrutura como código é percebida da seguinte forma:
— Vamos automatizar tudo no bash, nos cobrir de scripts para que os administradores tenham menos trabalho manual!
Mas isso não é verdade.
Infraestrutura como código significa que você descreve o sistema de TI com o qual trabalha na forma de código para compreender constantemente seu estado.
Junto com outras equipes, você cria um mapa em forma de código que todos podem entender e navegar e navegar. Não importa o que é feito – Chef, Ansible, Salt ou usando arquivos YAML no Kubernetes – não há diferença.
Na conferência, um colega do 2GIS contou como eles criaram seu próprio item interno para o Kubernetes, que descreve a estrutura de sistemas individuais. Para descrever 500 sistemas, eles precisavam de uma ferramenta separada que gerasse essa descrição. Quando há essa descrição, todos podem verificar entre si, acompanhar as mudanças, como mudar e melhorar, o que está faltando.
Concordo, scripts bash individuais geralmente não fornecem esse entendimento. Em uma das empresas onde trabalhei, havia até um nome para script “write only” – quando o script está escrito, mas não é mais possível lê-lo. Acho que isso também é familiar para você.
Infraestrutura como código é código que descreve o estado atual da infraestrutura. Muitas equipes de produtos, infraestrutura e serviços trabalham juntas nesse código e, o mais importante, todas precisam entender como esse código realmente funciona.
O código é mantido de acordo com as melhores práticas de código: desenvolvimento conjunto, revisão de código, programação XP, testes, solicitações pull, CI para infraestruturas de código - tudo isso é adequado e pode ser usado.
O código se torna uma linguagem comum para todos os engenheiros.
Mudar a infraestrutura no código não leva muito tempo. Sim, o código de infraestrutura também pode ter dívida técnica. Normalmente as equipes se deparam com isso um ano e meio depois de começarem a implementar a “infraestrutura como código” na forma de um monte de scripts ou até mesmo do Ansible, que escrevem como código espaguete, e também adicionam scripts bash à mistura!
É importante: Se você ainda não experimentou essas coisas, lembre-se disso Ansible não é bash! Leia a documentação com atenção, estude o que escrevem sobre ela.
Infraestrutura como código é a separação do código de infraestrutura em camadas separadas.
Na nossa empresa distinguimos 3 camadas básicas, que são muito claras e simples, mas podem haver mais. Você pode olhar seu código de infraestrutura e saber se tem essa condição ou não. Se nenhuma camada estiver destacada, será necessário dedicar algum tempo e refatorar um pouco.
camada de base - é assim que o sistema operacional, os backups e outras coisas de baixo nível são configurados, por exemplo, como o Kubernetes é implantado no nível básico.
Nível de serviço - estes são os serviços que você fornece ao desenvolvedor: registro 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 monte de serviços que equipes individuais pode proporcionar ao desenvolvimento. Tudo isso precisa ser descrito em módulos separados no seu sistema de gerenciamento de configuração.
A camada onde as aplicações são feitas e descreve como elas se desdobrarão sobre as duas camadas anteriores.
Perguntas de controle
Sua empresa possui um repositório de infraestrutura comum? Você está gerenciando dívida técnica em sua infraestrutura? Você utiliza práticas de desenvolvimento em um repositório de infraestrutura? A sua infraestrutura está dividida em camadas? Você pode verificar o diagrama Base-service-APP. Quão difícil é fazer uma mudança?
Se você percebeu que demorou um dia e meio para fazer alterações, isso significa que você tem uma dívida técnica e precisa trabalhar com ela. Você acabou de se deparar com uma dívida técnica em seu código de infraestrutura. Lembro-me de muitas dessas histórias quando, para alterar algum CCTL, é preciso reescrever metade do código da infraestrutura, porque a criatividade e a vontade de automatizar tudo levaram ao fato de que tudo estava corroído em todos os lugares, todas as alças foram removidas, e é necessário refatorar.
Entrega Contínua
Vamos comparar o débito com o crédito. Primeiro vem uma descrição da infraestrutura, que pode ser bastante básica. Você não precisa descrever tudo em detalhes, mas é necessária alguma descrição básica para que você possa trabalhar com isso. Caso contrário, não está claro o que fazer a seguir com a entrega contínua. Todas essas práticas se desenrolam simultaneamente quando você chega ao DevOps, mas começa com a compreensão do que você tem e como gerenciá-lo. Esta é precisamente a prática da infraestrutura como código.
Assim que ficar claro que você o possui e como gerenciá-lo, você começa a descobrir como enviar o código do desenvolvedor para produção o mais rápido possível. Quer dizer, junto com o desenvolvedor - lembramos do problema dos “poços”, ou seja, não são pessoas individuais que inventam isso, mas uma equipe.
Quando estamos com Vânia Evtukhovich vi o primeiro livro Jez humilde e grupos de autores "Entrega Contínua", lançado em 2009, pensamos muito em como traduzir seu título para o russo. Queriam traduzir como “Entregar constantemente”, mas, infelizmente, foi traduzido como “Entrega contínua”. Parece-me que há algo de russo em nosso nome, com pressão.
Fornecendo meios constantemente
O código que está no repositório do produto sempre pode ser baixado para produção. Ele pode não estar desanimado, mas está sempre pronto para isso. Conseqüentemente, você sempre escreve código com uma sensação difícil de explicar de alguma ansiedade no cóccix. Geralmente aparece quando você implementa o código de infraestrutura. Essa sensação de alguma ansiedade deve estar presente - ela desencadeia processos cerebrais que permitem escrever código de maneira um pouco diferente. Isso deve ser registrado nas regras do empreendimento.
Para entregar de forma consistente, você precisa de um formato de artefato que seja executado em uma plataforma de infraestrutura. Se lançarmos “desperdícios de vida” de diferentes formatos numa plataforma de infra-estrutura, então esta torna-se unificada, é difícil de manter e surge o problema da dívida técnica. O formato do artefato precisa estar alinhado - essa também é uma tarefa coletiva: todos precisamos nos reunir, mexer a cabeça e chegar a esse formato.
O artefato é continuamente aprimorado e alterado para se adequar ao ambiente de produção à medida que avança pelo pipeline de entrega. Quando um artefato se move ao longo do pipeline, ele encontra constantemente algumas coisas inconvenientes para ele, que são semelhantes às encontradas pelo artefato que você coloca em produção. Se no desenvolvimento clássico isso é feito por um administrador de sistema que faz o rollout, então no processo DevOps isso acontece o tempo todo: aqui eles testaram com alguns testes, aqui eles jogaram em um cluster Kubernetes, que é mais ou menos semelhante para a produção e, de repente, eles começaram o teste de carga.
Isso lembra um pouco o jogo Pac-Man - o artefato passa por algum tipo de história. Ao mesmo tempo, é importante controlar se o código realmente passa pela história e se está de alguma forma relacionado à sua produção. As histórias da produção podem ser arrastadas para o processo de Entrega Contínua: era assim quando alguma coisa caiu, agora vamos apenas programar esse cenário dentro do sistema. Cada vez que o código também passará por esse cenário, você não encontrará esse problema na próxima vez. Você aprenderá sobre isso muito antes de chegar ao seu cliente.
Diferentes estratégias de implantação. Por exemplo, você usa testes AB ou implantações canário para testar o código de maneira diferente em clientes diferentes, obter informações sobre como o código funciona e muito antes de ser implementado para 100 milhões de usuários.
“Entregar consistentemente” é assim.
O processo de entrega Dev, CI, Test, PreProd, Prod não é um ambiente separado, são etapas ou estações com somas à prova de fogo pelas quais seu artefato passa.
Se você tiver um código de infraestrutura descrito como APP de serviço básico, isso ajuda não se esqueça de todos os scriptse anote-os como código para este artefato, promover artefato e mude conforme você avança.
Perguntas de autoteste
O tempo desde a descrição do recurso até o lançamento em produção em 95% dos casos é inferior a uma semana? A qualidade do artefato melhora em cada estágio do pipeline? Existe uma história que isso passa? Você usa estratégias de implantação diferentes?
Se todas as respostas forem sim, então você é incrivelmente legal! Escreva suas respostas nos comentários - ficarei feliz).
Contacte-nos
Esta é a prática mais difícil de todas. Na conferência DevOpsConf, um colega da Infobip, falando sobre isso, ficou um pouco confuso em suas palavras, pois essa é realmente uma prática muito complexa sobre o fato de que é preciso monitorar tudo!
Por exemplo, há muito tempo, quando trabalhava na Qik e percebemos que precisávamos monitorar tudo. Fizemos isso e agora temos 150 mil itens no Zabbix, que são monitorados constantemente. Foi assustador, o diretor técnico torceu o dedo na têmpora:
- Pessoal, por que vocês estão estuprando o servidor com algo que não está claro?
Mas então ocorreu um incidente que mostrou que essa é realmente uma estratégia muito legal.
Um dos serviços começou a travar constantemente. Inicialmente não travou, o que é interessante, o código não foi adicionado ali, pois se tratava de uma corretora básica, que praticamente não tinha funcionalidade de negócio - simplesmente enviava mensagens entre serviços individuais. O serviço não mudou por 4 meses e de repente começou a travar com o erro “Falha de segmentação”.
Ficamos chocados, abrimos nossos gráficos no Zabbix e descobrimos que há uma semana e meia o comportamento das solicitações no serviço API que esta corretora utiliza mudou muito. A seguir vimos que a frequência de envio de determinado tipo de mensagem havia mudado. Mais tarde descobrimos que se tratava de clientes Android. Nós perguntamos:
— Pessoal, o que aconteceu com vocês há uma semana e meia?
Em resposta, ouvimos uma história interessante sobre como eles redesenharam a IU. É improvável que alguém diga imediatamente que mudou a biblioteca HTTP. Para clientes Android, é como trocar sabonete no banheiro: eles simplesmente não se lembram. Como resultado, após 40 minutos de conversa, descobrimos que eles haviam alterado a biblioteca HTTP e seus tempos padrão haviam mudado. Isso fez com que o comportamento do tráfego no servidor API mudasse, o que levou a uma situação que causou uma corrida dentro do corretor e ele começou a travar.
Sem um monitoramento profundo, geralmente é impossível abrir este. Se a organização ainda tiver o problema dos “poços”, quando todos jogam dinheiro uns nos outros, isso pode durar anos. Você simplesmente reinicia o servidor porque é impossível resolver o problema. Quando você monitora, rastreia, rastreia todos os eventos que você tem, e usa o monitoramento como teste - escreve código e indica imediatamente como monitorá-lo, também na forma de código (já temos a infraestrutura como código), tudo fica claro como na palma da mão. Mesmo esses problemas complexos são facilmente rastreados.
Colete todas as informações sobre o que acontece com o artefato em cada etapa do processo de entrega – não na produção.
Faça upload do monitoramento para o CI e algumas coisas básicas já estarão visíveis lá. Mais tarde, você os verá em Test, PredProd e teste de carga. Colete informações em todas as etapas, não apenas métricas, estatísticas, mas também registros: como o aplicativo foi implementado, anomalias - colete tudo.
Caso contrário, será difícil descobrir. Já disse que DevOps é mais complexo. Para lidar com essa complexidade, você precisa ter análises normais.
Questões de autocontrole
Seu monitoramento e registro são a ferramenta de desenvolvimento para você? Ao escrever código, seus desenvolvedores, inclusive você, pensam em como monitorá-lo?
Você ouve falar de problemas dos clientes? Você entende melhor o cliente através do monitoramento e registro? Você entende melhor o sistema através do monitoramento e registro? Você muda o sistema simplesmente porque viu que a tendência do sistema está crescendo e entende que em mais 3 semanas tudo vai morrer?
Depois de ter esses três componentes, você pode pensar em que tipo de plataforma de infraestrutura possui em sua empresa.
Plataforma de infraestrutura
A questão não é que se trate de um conjunto de ferramentas díspares que toda empresa possui.
O objetivo de uma plataforma de infraestrutura é que todas as equipes usem essas ferramentas e as desenvolvam juntas.
É claro que existem equipas separadas que são responsáveis pelo desenvolvimento de peças individuais da plataforma de infraestrutura. Mas, ao mesmo tempo, cada engenheiro é responsável pelo desenvolvimento, desempenho e promoção da plataforma de infraestrutura. A nível interno, torna-se uma ferramenta comum.
Todas as equipes desenvolvem a plataforma de infraestrutura e a tratam com cuidado como se fosse seu próprio IDE. No seu IDE você instala diferentes plugins para deixar tudo bonito e rápido, e configura teclas de atalho. Quando você abre Sublime, Atom ou Visual Studio Code, erros de código aparecem e você percebe que é impossível trabalhar, você imediatamente fica triste e corre para consertar seu IDE.
Trate sua plataforma de infraestrutura da mesma maneira. Se você entende que há algo errado com isso, deixe um pedido se não conseguir consertar sozinho. Se houver algo simples, edite você mesmo, envie um pull request, a galera vai considerar e adicionar. Esta é uma abordagem ligeiramente diferente das ferramentas de engenharia na cabeça do desenvolvedor.
A plataforma de infraestrutura garante a transferência do artefato do desenvolvimento para o cliente com melhoria contínua na qualidade. O IP é programado com um conjunto de histórias que acontecem com o código em produção. Ao longo dos anos de desenvolvimento, há muitas dessas histórias, algumas delas são únicas e dizem respeito apenas a você - elas não podem ser pesquisadas no Google.
Neste ponto, a plataforma de infraestrutura se torna sua vantagem competitiva, porque tem algo embutido que não está na ferramenta do concorrente. Quanto mais profundo for o seu IP, maior será a sua vantagem competitiva em termos de Time-to-market. Aparece aqui problema de bloqueio de fornecedor: Você pode usar a plataforma de outra pessoa, mas usando a experiência de outra pessoa, você não entenderá o quão relevante ela é para você. Sim, nem toda empresa pode construir uma plataforma como a Amazon. Esta é uma linha difícil onde a experiência da empresa é relevante para a sua posição no mercado, e aí não se pode usar um bloqueio de fornecedor. Também é importante pensar nisso.
Condução
Este é um diagrama básico de uma plataforma de infraestrutura que o ajudará a configurar todas as práticas e processos em uma empresa DevOps.
Vejamos em que consiste.
Sistema de orquestração de recursos, que fornece CPU, memória, disco para aplicativos e outros serviços. Além do mais - serviços de baixo nível: monitoramento, registro em log, mecanismo CI/CD, armazenamento de artefatos, infraestrutura como código do sistema.
Serviços de nível superior: banco de dados como serviço, filas como serviço, Load Balance como serviço, redimensionamento de imagem como serviço, Big Data factory como serviço. Além do mais - pipeline que entrega código constantemente modificado ao seu cliente.
Você recebe informações sobre como o seu software funciona para o cliente, altera-o, fornece esse código novamente, recebe informações - e assim você desenvolve constantemente tanto a plataforma de infraestrutura quanto o seu software.
No diagrama, o pipeline de entrega consiste em vários estágios. Mas este é um diagrama esquemático dado como exemplo - não há necessidade de repeti-lo um por um. Os estágios interagem com os serviços como se fossem serviços – cada bloco da plataforma carrega sua própria história: como os recursos são alocados, como o aplicativo é iniciado, funciona com os recursos, é monitorado e muda.
É importante entender que cada parte da plataforma carrega uma história, e pergunte-se que história esse tijolo carrega, talvez deva ser jogado fora e substituído por um serviço de terceiros. Por exemplo, é possível instalar o Okmeter em vez de um tijolo? Talvez a galera já tenha desenvolvido essa expertise muito mais do que nós. Mas talvez não - talvez tenhamos conhecimentos únicos, precisamos instalar o Prometheus e desenvolvê-lo ainda mais.
Criação da plataforma
Este é um processo de comunicação complexo. Quando você tem práticas básicas, você inicia a comunicação entre diferentes engenheiros e especialistas que desenvolvem requisitos e padrões, e os altera constantemente para diferentes ferramentas e abordagens. A cultura que temos em DevOps é importante aqui.
Com a cultura tudo é muito simples - trata-se de colaboração e comunicação, isto é, o desejo de trabalhar em um campo comum entre si, o desejo de manejar um instrumento juntos. Não há ciência de foguetes aqui - tudo é muito simples, banal. Por exemplo, todos nós moramos na entrada e a mantemos limpa - esse é o nível de cultura.
O que você tem?
Novamente, perguntas que você pode fazer a si mesmo.
A plataforma de infraestrutura é dedicada? Quem é o responsável pelo seu desenvolvimento? Você entende as vantagens competitivas da sua plataforma de infraestrutura?
Você precisa se perguntar constantemente essas perguntas. Se algo pode ser transferido para serviços de terceiros, deve ser transferido; se um serviço de terceiros começar a bloquear seu movimento, você precisará construir um sistema dentro de você.
Então, DevOps...
... este é um sistema complexo, deve ter:
- Produto digital.
- Módulos de negócios que desenvolvem este produto digital.
- Equipes de produto que escrevem código.
- Práticas de entrega contínua.
- Plataformas como serviço.
- Infraestrutura como um serviço.
- Infraestrutura como código.
- Práticas separadas para manter a confiabilidade, integradas ao DevOps.
- Uma prática de feedback que descreve tudo.
Você pode utilizar este diagrama, destacando nele o que você já tem de alguma forma na sua empresa: já foi desenvolvido ou ainda precisa ser desenvolvido.
Acabará em algumas semanas . como parte do RIT++. Venha para a conferência, onde você encontrará muitos relatórios interessantes sobre entrega contínua, infraestrutura como código e transformação DevOps. , o último prazo de preço é 20 de maio
Fonte: habr.com