{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"O que \u00e9 DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A defini\u00e7\u00e3o de DevOps \u00e9 bastante complexa, por isso a discuss\u00e3o sobre o tema \u00e9 constantemente reaberta. Apenas no Habr h\u00e1 mil publica\u00e7\u00f5es sobre isso. Mas se voc\u00ea est\u00e1 lendo isso, com certeza j\u00e1 sabe o que \u00e9 DevOps. Porque eu n\u00e3o sei. Ol\u00e1, meu nome \u00e9 Alexander Titov (@osminog<\/a><\/noindex><\/b>), e n\u00f3s vamos simplesmente conversar sobre DevOps e eu vou compartilhar minha experi\u00eancia.<\/p>\n

\"O
\n
\nPensei bastante em como tornar meu relato \u00fatil, por isso haver\u00e1 muitas perguntas \u2014 aquelas que fa\u00e7o a mim mesmo e aquelas que fa\u00e7o aos clientes da nossa empresa. Respondendo a essas perguntas, a compreens\u00e3o se torna melhor. Vou explicar por que DevOps \u00e9 necess\u00e1rio do meu ponto de vista, o que \u00e9 isso, novamente, do meu ponto de vista, e como entender se voc\u00ea est\u00e1 avan\u00e7ando em dire\u00e7\u00e3o ao DevOps, novamente do meu ponto de vista. O \u00faltimo ponto ser\u00e1 por meio de perguntas. Ao responder a elas para si mesmo, voc\u00ea conseguir\u00e1 entender se sua empresa est\u00e1 caminhando para o DevOps ou se h\u00e1 problemas em algum aspecto.
\n<\/a><\/noindex>
\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center>
\nDurante um tempo, naveguei pelas ondas de fus\u00f5es e aquisi\u00e7\u00f5es. Primeiro trabalhei em uma pequena startup chamada Qik, depois ela foi adquirida por uma empresa um pouco maior, a Skype, que, por sua vez, foi comprada por uma empresa ainda maior, a Microsoft. Nesse momento, consegui ter uma vis\u00e3o de como a percep\u00e7\u00e3o de DevOps se transforma em empresas de diferentes tamanhos. Depois disso, fiquei interessado em olhar para o DevOps do ponto de vista de mercado, e com colegas, fundamos a empresa Express 42. H\u00e1 6 anos navegamos nas ondas do mercado.<\/p>\n

Al\u00e9m de tudo isso, sou um dos organizadores da comunidade DevOps Moscow e organizei o DevOps Days 2017, mas n\u00e3o organizei em 2018. A Express 42 trabalha com muitas empresas. N\u00f3s fazemos crescer o DevOps l\u00e1, observamos como isso acontece, tiramos conclus\u00f5es, analisamos, compartilhamos nossas conclus\u00f5es com todos, e treinamos pessoas em pr\u00e1ticas de DevOps. Em suma, estamos cultivando a experi\u00eancia e a expertise nesse sentido.<\/p>\n

Por que DevOps<\/h2>\n

\nA primeira pergunta que persegue a todos sempre \u00e9: por qu\u00ea? Muitos acreditam que DevOps \u00e9 apenas automa\u00e7\u00e3o ou algo similar que j\u00e1 existe em cada empresa.<\/p>\n

\u2014 N\u00f3s j\u00e1 t\u00ednhamos Integra\u00e7\u00e3o Cont\u00ednua \u2014 isso significa que j\u00e1 t\u00ednhamos DevOps, e para que precisamos de toda essa confus\u00e3o? L\u00e1 fora eles se divertem, e aqui eles s\u00f3 atrapalham o trabalho!<\/i><\/p>\n

Em 9 anos de desenvolvimento da comunidade e da metodologia, j\u00e1 ficou claro que isso, de fato, n\u00e3o \u00e9 um brilho de marketing, mas ainda n\u00e3o est\u00e1 totalmente claro para que serve. Como qualquer ferramenta ou processo, o DevOps tem objetivos espec\u00edficos que acaba alcan\u00e7ando.<\/p>\n

Tudo isso est\u00e1 relacionado ao fato de que o mundo est\u00e1 mudando. Ele est\u00e1 se afastando da abordagem empresarial, onde as empresas avan\u00e7am diretamente em dire\u00e7\u00e3o ao sonho, como cantou nosso cl\u00e1ssico de S\u00e3o Petersburgo, do ponto A ao ponto B, seguindo uma estrat\u00e9gia definida, com uma estrutura espec\u00edfica constru\u00edda para isso. <\/p>\n

\"O
\n<\/p>\n

Em princ\u00edpio, tudo em TI deveria ser estruturado com base nessa abordagem. Aqui, a TI \u00e9 usada exclusivamente para a automa\u00e7\u00e3o de processos.<\/p><\/blockquote>\n

\nA automa\u00e7\u00e3o n\u00e3o muda com frequ\u00eancia, porque quando uma empresa est\u00e1 na mesma rota, o que h\u00e1 para mudar? Funciona \u2014 n\u00e3o mexa. Hoje em dia, no mundo, as abordagens est\u00e3o mudando, e a que \u00e9 conhecida como Agile diz que o ponto final B n\u00e3o \u00e9 imediatamente vis\u00edvel.<\/p>\n

\"O
\n
\nQuando uma empresa opera no mercado e trabalha com o cliente, ela est\u00e1 constantemente pesquisando o mercado e mudando o ponto final B. Quanto mais frequentemente a empresa muda sua dire\u00e7\u00e3o, mais bem-sucedida ela acaba se tornando, porque escolhe mais nichos de mercado.<\/p>\n

Uma estrat\u00e9gia \u00e9 demonstrada por uma empresa interessante, da qual soube recentemente. One Box Shave \u00e9 um servi\u00e7o de entrega de l\u00e2minas e acess\u00f3rios de barbear por assinatura em uma caixa. Eles conseguem personalizar sua 'caixinha' para diferentes clientes. Isso \u00e9 feito por um software espec\u00edfico, que depois envia o pedido para uma f\u00e1brica na Cor\u00e9ia que produz o produto.<\/p>\n

Esse produto foi adquirido pela Unilever por 1 bilh\u00e3o de d\u00f3lares. Agora ele compete com a Gillette e tomou uma parte significativa do p\u00fablico no mercado americano. A One Box Shave diz:<\/p>\n

\u2014 4 l\u00e2minas? Voc\u00ea est\u00e1 falando s\u00e9rio? Por que voc\u00ea precisaria disso - isso n\u00e3o melhora a qualidade do barbear. Um creme especialmente selecionado, uma fragr\u00e2ncia e uma l\u00e2mina de qualidade com duas l\u00e2minas resolvem muito mais quest\u00f5es do que essas bobas 4 l\u00e2minas da Gillette! Vamos chegar a 10 em breve?<\/i><\/p>\n

Assim, o mundo est\u00e1 mudando. A Unilever afirma que possui um sistema de TI incr\u00edvel que permite isso. No final, isso se parece com o conceito Time-to-market<\/b>, sobre o qual j\u00e1 se falou muito.<\/p>\n

\"O
\n
\nO significado de Time-to-market n\u00e3o est\u00e1 em qu\u00e3o frequentemente fazemos deploy. Muitas vezes, \u00e9 poss\u00edvel fazer deploy, mas os ciclos de lan\u00e7amento podem ser longos. Se sobrepormos ciclos de lan\u00e7amento de tr\u00eas meses, adiando um pouco, parece que a empresa faz deploy toda semana. Mas na verdade, desde a ideia at\u00e9 a implementa\u00e7\u00e3o final, passam-se tr\u00eas meses.<\/p>\n

Time-to-market \u00e9 sobre minimizar o tempo desde a ideia at\u00e9 a implementa\u00e7\u00e3o final.<\/p><\/blockquote>\n

\nNesse caso, o software interage com o mercado. Assim, no One Box Shave, o site interage com o cliente. Eles n\u00e3o t\u00eam vendedores \u2014 apenas um site onde o visitante clica e deixa suas prefer\u00eancias. Portanto, \u00e9 necess\u00e1rio atualizar constantemente o site com coisas novas, alinhando-o com os desejos dos usu\u00e1rios. Por exemplo, na Coreia do Sul, o m\u00e9todo de barbear \u00e9 diferente do da R\u00fassia, e eles preferem fragr\u00e2ncias diferentes, como baunilha em vez de pinho.<\/p>\n

Como \u00e9 necess\u00e1rio mudar rapidamente o conte\u00fado do site, o desenvolvimento de software muda muito. Atrav\u00e9s do software, precisamos entender o que o cliente quer. Antes, isso era feito de maneira indireta, como atrav\u00e9s da gest\u00e3o de neg\u00f3cios. Depois, projet\u00e1vamos e incorpor\u00e1vamos requisitos no sistema de TI, e tudo corria bem. Agora \u00e9 diferente \u2014 o software \u00e9 projetado por todos os envolvidos no processo, incluindo engenheiros, que entendem atrav\u00e9s das especifica\u00e7\u00f5es t\u00e9cnicas como o mercado opera e tamb\u00e9m compartilham suas percep\u00e7\u00f5es com os neg\u00f3cios.<\/p>\n

Por exemplo, na empresa Qik, descobrimos de repente que as pessoas adoram carregar listas de contatos no servidor, e acabaram desenvolvendo um aplicativo para isso. Inicialmente, n\u00e3o t\u00ednhamos pensado nisso. Em uma empresa cl\u00e1ssica, todos teriam decidido que isso era um bug, pois n\u00e3o estava especificado que precisava funcionar bem e, na verdade, foi implementado de maneira improvisada, teriam desativado a funcionalidade e teriam dito: 'Isso n\u00e3o interessa a ningu\u00e9m, o mais importante \u00e9 que a funcionalidade principal funciona.' Mas uma empresa tecnol\u00f3gica v\u00ea nisso uma oportunidade e come\u00e7a a mudar o software de acordo.<\/p>\n

\"O
\n
\nEm 1968, um cara perspicaz, Melvin Conway, formulou a seguinte ideia.<\/p>\n

Uma organiza\u00e7\u00e3o que cria um sistema \u00e9 limitada pelo design que copia a estrutura de comunica\u00e7\u00e3o dessa organiza\u00e7\u00e3o.<\/p><\/blockquote>\n

\nSe for mais detalhado, para produzir sistemas de outro tipo, voc\u00ea ainda precisa ter uma estrutura de comunica\u00e7\u00e3o dentro da empresa de outro tipo. Se voc\u00ea tem uma estrutura de comunica\u00e7\u00e3o hier\u00e1rquica superior, isso n\u00e3o permitir\u00e1 que voc\u00ea crie sistemas que possam garantir um alto \u00edndice de Time-to-market.<\/p>\n

Ler sobre a lei de Conway<\/a><\/noindex> \u00e9 poss\u00edvel nos links<\/a><\/noindex>. Ela \u00e9 importante para compreender a cultura ou filosofia DevOps, j\u00e1 que a \u00fanica coisa que muda basicamente no DevOps \u00e9 precisamente a estrutura de comunica\u00e7\u00e3o entre as equipes.<\/b>.<\/p>\n

Do ponto de vista do processo, at\u00e9 o DevOps, todas as etapas: an\u00e1lise, desenvolvimento, teste, opera\u00e7\u00e3o, aconteciam de forma linear.\"O
\nNo caso do DevOps, todos esses processos ocorrem simultaneamente.<\/p>\n

\"O
\n
\nTime-to-market s\u00f3 pode ser alcan\u00e7ado assim. Para as pessoas que trabalharam no antigo processo, isso parece um pouco espacial e \u00e9 de fato bastante complicado.<\/p>\n

Ent\u00e3o, por que o DevOps \u00e9 necess\u00e1rio?<\/h3>\n

\nPara o desenvolvimento de produtos digitais<\/b>. Se voc\u00ea n\u00e3o tem um produto digital na sua empresa, o DevOps n\u00e3o \u00e9 necess\u00e1rio - isso \u00e9 muito importante.<\/p>\n

O DevOps supera as limita\u00e7\u00f5es de velocidade do modelo de produ\u00e7\u00e3o sequencial de software<\/b>. Nele, todos os processos ocorrem ao mesmo tempo.<\/p>\n

A complexidade aumenta.<\/b> Quando os evangelistas do DevOps dizem que ficar\u00e1 mais f\u00e1cil lan\u00e7ar software - isso \u00e9 absurdo.<\/p>\n

Com o DevOps, tudo se tornar\u00e1 apenas mais complicado.<\/p><\/blockquote>\n

\nNa confer\u00eancia, no estande da Avito, voc\u00eas podiam ver o que significa implantar um cont\u00eainer Docker - uma tarefa irreal. A complexidade se torna excessiva, \u00e9 necess\u00e1rio malabarizar muitas bolas ao mesmo tempo.<\/p>\n

O DevOps muda completamente o processo e a organiza\u00e7\u00e3o na empresa<\/b>\u00a0\u2014 na verdade, n\u00e3o \u00e9 o DevOps que muda, mas o produto digital. Para chegar ao DevOps, voc\u00ea deve realmente transformar completamente este processo.<\/p>\n

Perguntas para o especialista<\/h3>\n

\nE quanto a voc\u00ea? Perguntas que voc\u00ea pode se fazer, trabalhando na empresa e se desenvolvendo como especialista.<\/p>\n

Voc\u00ea tem uma estrat\u00e9gia para criar um produto digital?<\/b> Se sim, isso j\u00e1 \u00e9 bom. Isso significa que sua empresa est\u00e1 avan\u00e7ando em dire\u00e7\u00e3o ao DevOps.<\/p>\n

Sua empresa j\u00e1 est\u00e1 criando um produto digital?<\/b> Isso significa que voc\u00ea pode subir mais um n\u00edvel, se envolver em assuntos mais interessantes - ainda do ponto de vista do DevOps. Estou falando apenas desse ponto de vista.<\/p>\n

Sua empresa \u00e9 uma das l\u00edderes de mercado em um nicho com produto digital?<\/b> Spotify, Yandex, Uber \u2014 empresas que est\u00e3o no auge do progresso tecnol\u00f3gico atualmente.<\/p>\n

Fa\u00e7a a si mesmo estas perguntas e, se todas as respostas forem negativas, talvez voc\u00ea n\u00e3o deva se envolver em DevOps nesta empresa. Mas se a quest\u00e3o de DevOps realmente lhe interessa, ser\u00e1 que\u2026 talvez voc\u00ea deva mudar para outra empresa? Se a sua empresa quer avan\u00e7ar em DevOps, mas voc\u00ea respondeu \"N\u00e3o\" a todas as perguntas, ent\u00e3o ela se assemelha a aquele lindo rinoceronte que nunca vai mudar.<\/p>\n

\"O
\n<\/p>\n

Organiza\u00e7\u00e3o<\/h2>\n

\nComo j\u00e1 mencionei, pela lei de Conway, a organiza\u00e7\u00e3o dentro da empresa muda. Come\u00e7arei discutindo o que impede o DevOps de penetrar na empresa sob a perspectiva da organiza\u00e7\u00e3o.<\/p>\n

O problema dos \"silos\"<\/h3>\n

\nA palavra inglesa \"Silo\" foi traduzida aqui para o russo como \"\u043a\u043e\u043b\u043e\u0434\u0435\u0446\" (po\u00e7o). O significado desse problema \u00e9 que n\u00e3o h\u00e1 troca de informa\u00e7\u00f5es entre as equipes<\/b>. Cada equipe escava sua especializa\u00e7\u00e3o em profundidade, sem construir um mapa comum que permita a orienta\u00e7\u00e3o.<\/p>\n

Isso se assemelha a uma pessoa que acabou de chegar a Moscou e ainda n\u00e3o sabe se orientar pelo mapa do metr\u00f4. Os moscovitas geralmente conhecem bem seu bairro, enquanto se orientam em toda Moscou pelo mapa do metr\u00f4. Quando voc\u00ea chega a Moscou pela primeira vez, n\u00e3o possui essa habilidade e est\u00e1 completamente desorientado.<\/p>\n

O DevOps prop\u00f5e passar por esse momento de desorienta\u00e7\u00e3o e construir um mapa comum de intera\u00e7\u00e3o junto com todos os departamentos.<\/p><\/blockquote>\n

\nDois fatores dificultam isso.<\/p>\n

As consequ\u00eancias do sistema de gest\u00e3o corporativa.<\/b> Ele \u00e9 constru\u00eddo por \"silos\" hier\u00e1rquicos separados. Por exemplo, existem certos KPIs nas empresas que sustentam esse sistema. Por outro lado, a mente humana dificulta a sa\u00edda de sua zona de conforto e a orienta\u00e7\u00e3o em todo o sistema. Isso \u00e9 simplesmente desconfort\u00e1vel. Imagine que voc\u00ea est\u00e1 em um aeroporto em Bangkok \u2014 \u00e9 dif\u00edcil se orientar rapidamente l\u00e1. No DevOps, tamb\u00e9m \u00e9 complicado se orientar, e por isso as pessoas dizem que \u00e9 necess\u00e1rio encontrar um guia para chegar l\u00e1.<\/p>\n

Mas o mais importante \u00e9 que o problema dos \"silos\" para um engenheiro que se deixou levar pelo esp\u00edrito do DevOps, que leu Fowler e muitos outros livros, se expressa no fato de que \"silos\" n\u00e3o permitem realizar coisas \"\u00f3bvias\"<\/b>. Frequentemente nos reunimos ap\u00f3s o DevOps Moscow, conversamos uns com os outros, e as pessoas reclamam:<\/p>\n

\u2014 Quer\u00edamos apenas iniciar a CI, mas acabou que a gest\u00e3o n\u00e3o precisa disso.<\/i><\/p>\n

Isso acontece exatamente por causa do\u00a0CI <\/b>e\u00a0processo de Entrega Cont\u00ednua<\/b> est\u00e3o na fronteira de v\u00e1rias especializa\u00e7\u00f5es. Simplesmente n\u00e3o conseguir\u00e3o avan\u00e7ar sem superar o problema dos \"po\u00e7os\" a n\u00edvel organizacional, n\u00e3o importa o que fa\u00e7am, e por mais triste que isso seja.<\/p>\n

\"O
\n
\nCada participante do processo na empresa: desenvolvedores de backend e frontend, testadores, DBA, opera\u00e7\u00f5es, rede, cavando na sua pr\u00f3pria dire\u00e7\u00e3o, e ningu\u00e9m al\u00e9m do gestor, que os observa e controla com a t\u00e9cnica do \"dividir para conquistar\", possui um mapa geral.<\/p>\n

As pessoas lutam por algumas estrelinhas ou bandeirolas, cada um se dedica \u00e0 sua pr\u00f3pria especialidade.<\/p><\/blockquote>\n

\nNo final, quando surge a tarefa de conectar tudo isso e construir um pipeline comum, e j\u00e1 n\u00e3o \u00e9 necess\u00e1rio lutar por estrelinhas e bandeirolas, surge a pergunta \u2014 e agora, o que fazer? Precisamos de algum tipo de acordo, mas como fazer isso, ningu\u00e9m nos ensinou na escola. Estamos ensinados desde a escola: o oitavo ano \u2014 uau! \u2014 em compara\u00e7\u00e3o com o s\u00e9timo ano! Aqui \u00e9 a mesma coisa.<\/p>\n

Na sua empresa \u00e9 assim tamb\u00e9m?<\/h3>\n

\nPara verificar isso, voc\u00ea pode fazer as seguintes perguntas.<\/p>\n

As equipes utilizam ferramentas comuns, contribuem para as mudan\u00e7as dessas ferramentas comuns?<\/p>\n

Com que frequ\u00eancia as equipes se reconfiguram - alguns especialistas de uma equipe mudam para outra equipe?<\/b> Na verdade, isso se torna normal no ambiente DevOps, porque \u00e0s vezes a pessoa simplesmente n\u00e3o consegue entender o que outra \u00e1rea de especializa\u00e7\u00e3o est\u00e1 fazendo. Ela se muda para outro departamento, trabalha l\u00e1 por duas semanas para criar um mapa de orienta\u00e7\u00e3o e intera\u00e7\u00e3o com esse departamento.<\/p>\n

\u00c9 poss\u00edvel criar um comit\u00ea de mudan\u00e7a e fazer alguma altera\u00e7\u00e3o? <\/b>Ou isso requer uma m\u00e3o forte da alta dire\u00e7\u00e3o e uma ordem? Recentemente escrevi no Facebook sobre como um banco pouco conhecido implementa ferramentas atrav\u00e9s de ordens: escreveram a ordem, passaram um ano implementando, vendo o que acontece. Isso, claro, \u00e9 demorado e triste.<\/p>\n

Qu\u00e3o importante \u00e9 para os gerentes obter conquistas pessoais independentemente das conquistas da empresa? <\/b><\/p>\n

Se voc\u00ea responder a essas perguntas para si mesmo, ficar\u00e1 mais claro se voc\u00ea tem esse problema na sua empresa.<\/p>\n

Infraestrutura como c\u00f3digo<\/h2>\n

\nDepois que esse problema for resolvido, a primeira pr\u00e1tica importante, sem a qual \u00e9 dif\u00edcil avan\u00e7ar em DevOps, \u00e9 infraestrutura como c\u00f3digo<\/b>. <\/p>\n

Normalmente, a infraestrutura como c\u00f3digo \u00e9 entendida assim:<\/p>\n

\u2014 Vamos automatizar tudo com bash, usar scripts, para que os administradores tenham menos trabalho manual!<\/i><\/p>\n

Mas isso n\u00e3o \u00e9 verdade.<\/p>\n

Infraestrutura como c\u00f3digo implica que o sistema de TI com o qual voc\u00ea trabalha \u00e9 descrito em forma de c\u00f3digo, para que voc\u00ea entenda constantemente seu estado.<\/p><\/blockquote>\n

\nJuntamente com outras equipes, voc\u00ea cria um mapa em forma de c\u00f3digo, que seja compreens\u00edvel a todos, para orienta\u00e7\u00e3o e navega\u00e7\u00e3o. N\u00e3o importa em que isso \u00e9 feito \u2014 Chef, Ansible, Salt, ou se s\u00e3o usados arquivos YAML no Kubernetes \u2014 n\u00e3o faz diferen\u00e7a.<\/p>\n

Em uma confer\u00eancia, um colega da 2GIS contou como eles criaram sua pr\u00f3pria ferramenta interna para Kubernetes, que descreve a configura\u00e7\u00e3o de sistemas individuais. Para descrever 500 sistemas, eles precisaram de uma ferramenta separada que gera essa descri\u00e7\u00e3o. Quando essa descri\u00e7\u00e3o existe, qualquer um pode se comparar, monitorar mudan\u00e7as, como modific\u00e1-la e melhor\u00e1-la, e o que est\u00e1 faltando. <\/p>\n

Concorde que scripts bash separados geralmente n\u00e3o oferecem essa compreens\u00e3o. Em uma das empresas em que trabalhei, havia at\u00e9 o nome de \"script write only\" \u2014 quando o script \u00e9 escrito, mas n\u00e3o pode ser lido depois. Acredito que isso seja familiar para voc\u00ea tamb\u00e9m.<\/p>\n

Infraestrutura como c\u00f3digo \u00e9 o c\u00f3digo que descreve o estado atual da infraestrutura<\/b>. Esse c\u00f3digo \u00e9 colaborativamente trabalhado por v\u00e1rias equipes de produtos, infraestrutura e servi\u00e7os, e, mais importante, todos devem entender como esse c\u00f3digo realmente funciona.<\/p>\n

O c\u00f3digo \u00e9 mantido de acordo com as melhores pr\u00e1ticas de codifica\u00e7\u00e3o<\/b>: desenvolvimento colaborativo, revis\u00e3o de c\u00f3digo, programa\u00e7\u00e3o XP, testes, pull requests, CI para c\u00f3digos de infraestrutura \u2014 tudo isso \u00e9 v\u00e1lido e pode ser utilizado.<\/p>\n

O c\u00f3digo torna-se uma linguagem comum para todos os engenheiros.<\/p><\/blockquote>\n

\nModificar a infraestrutura no c\u00f3digo n\u00e3o leva muito tempo<\/b>. Sim, tamb\u00e9m pode haver d\u00edvida t\u00e9cnica no c\u00f3digo de infraestrutura. Normalmente, as equipes enfrentam isso cerca de um ano e meio ap\u00f3s come\u00e7arem a implementar \"infraestrutura como c\u00f3digo\" na forma de uma cole\u00e7\u00e3o de scripts ou at\u00e9 mesmo Ansible, que eles escrevem como c\u00f3digo espaguete, e ainda adicionam scripts bash na mistura! <\/p>\n

Importante<\/b>: se voc\u00ea ainda n\u00e3o experimentou essa coisa ruim, lembre-se de que Ansible n\u00e3o \u00e9 bash<\/b>! Leia a documenta\u00e7\u00e3o com aten\u00e7\u00e3o e estude o que dizem sobre isso.<\/p>\n

Infraestrutura como c\u00f3digo \u00e9 a divis\u00e3o do c\u00f3digo de infraestrutura em camadas distintas.<\/p><\/blockquote>\n

\nNa nossa empresa, destacamos 3 camadas b\u00e1sicas, que s\u00e3o muito claras e simples, mas podem existir mais. Voc\u00ea pode analisar seu c\u00f3digo de infraestrutura e determinar se possui essa condi\u00e7\u00e3o ou n\u00e3o. Se n\u00e3o houver camadas definidas, \u00e9 necess\u00e1rio reservar um tempo para fazer um pequeno refatoramento.
\n\"O
\n
\nCamada b\u00e1sica<\/b>\u00a0\u2014 \u00e9 como o sistema operacional \u00e9 configurado, backups e outras coisas de baixo n\u00edvel, como o Kubernetes \u00e9 implantado em n\u00edvel b\u00e1sico.<\/p>\n

N\u00edvel de servi\u00e7os<\/b>\u00a0\u2014 s\u00e3o os servi\u00e7os que voc\u00ea fornece ao desenvolvedor: logging como servi\u00e7o, monitoramento como servi\u00e7o, banco de dados como servi\u00e7o, balanceador como servi\u00e7o, fila como servi\u00e7o, Continuous Delivery como servi\u00e7o \u2014 uma s\u00e9rie de servi\u00e7os que diferentes equipes podem disponibilizar para desenvolvimento. Tudo isso deve ser descrito como m\u00f3dulos distintos em seu sistema de gerenciamento de configura\u00e7\u00e3o.<\/p>\n

Camada onde os aplicativos s\u00e3o feitos<\/b> e descrito como ser\u00e3o implantados sobre as duas camadas anteriores.<\/p>\n

Perguntas de controle<\/h3>\n

\nVoc\u00ea tem um reposit\u00f3rio de infraestrutura comum na sua empresa? Voc\u00ea controla a d\u00edvida t\u00e9cnica na infraestrutura? Utiliza pr\u00e1ticas de desenvolvimento no reposit\u00f3rio de infraestrutura? Sua infraestrutura est\u00e1 dividida em camadas? Voc\u00ea pode consultar o esquema Base-service-APP. Qu\u00e3o dif\u00edcil \u00e9 fazer uma altera\u00e7\u00e3o? <\/p>\n

Se voc\u00ea enfrentou situa\u00e7\u00f5es em que fazer altera\u00e7\u00f5es levou um dia e meio, isso significa que voc\u00ea acumulou d\u00edvida t\u00e9cnica, e precisa trabalhar nisso. Voc\u00ea acabou de encontrar as armadilhas da d\u00edvida t\u00e9cnica no c\u00f3digo de infraestrutura. Eu me lembro de muitas hist\u00f3rias em que, para mudar algum CCTL, \u00e9 preciso reescrever metade do c\u00f3digo de infraestrutura, porque a criatividade e o desejo de automatizar tudo levaram a um emaranhado, onde tudo ficou muito complicado, e precisa ser refatorado.<\/p>\n

Implanta\u00e7\u00e3o cont\u00ednua<\/h2>\n

\nVamos analisar o d\u00e9bito e o cr\u00e9dito. Primeiro, aparece uma descri\u00e7\u00e3o da infraestrutura, que pode ser bastante b\u00e1sica. N\u00e3o \u00e9 necess\u00e1rio descrever tudo em detalhe, mas \u00e9 preciso ter uma descri\u00e7\u00e3o b\u00e1sica para que voc\u00ea possa trabalhar com isso. Caso contr\u00e1rio, fica dif\u00edcil entender sobre o que construir a entrega cont\u00ednua. Todas essas pr\u00e1ticas se desenrolam simultaneamente quando voc\u00ea entra no DevOps, mas \u00e9 fundamental come\u00e7ar com o entendimento do que voc\u00ea tem e como gerenci\u00e1-lo. Isso \u00e9, na verdade, a pr\u00e1tica de infraestrutura como c\u00f3digo.<\/p>\n

Depois que ficou claro o que voc\u00ea tem e como gerenci\u00e1-lo, voc\u00ea come\u00e7a a imaginar como o c\u00f3digo do desenvolvedor pode ser enviado para a produ\u00e7\u00e3o o mais r\u00e1pido poss\u00edvel. Quero dizer, junto com o desenvolvedor \u2014 lembre-se do problema dos 'po\u00e7os', ou seja, n\u00e3o s\u00e3o pessoas separadas que criam isso, mas sim a equipe.<\/p>\n

Quando n\u00f3s\u00a0Vania Evtukhovich<\/b> vimos o primeiro livro Jez Humble<\/b> e o grupo de autores \u00abContinuous Delivery\u00bb<\/b>, que foi lan\u00e7ado em 2009, pensamos por muito tempo sobre como traduzir seu t\u00edtulo para o russo. Quer\u00edamos traduzir como 'Entregar continuamente', mas, infelizmente, foi traduzido como 'Entrega cont\u00ednua'. Eu acho que o nosso t\u00edtulo tem algo bem russo, com uma for\u00e7a especial.<\/p>\n

'Entregar continuamente' significa<\/h3>\n

\nO c\u00f3digo que est\u00e1 no reposit\u00f3rio do produto pode sempre ser lan\u00e7ado na produ\u00e7\u00e3o<\/b>. Ele pode n\u00e3o ser lan\u00e7ado, mas est\u00e1 sempre pronto para isso. Assim, voc\u00ea sempre escreve c\u00f3digo com uma sensa\u00e7\u00e3o dif\u00edcil de explicar de certa inquieta\u00e7\u00e3o. Isso frequentemente surge quando voc\u00ea implementa o c\u00f3digo da infraestrutura. Essa sensa\u00e7\u00e3o de inquieta\u00e7\u00e3o deve estar presente \u2014 ela provoca processos mentais que permitem escrever c\u00f3digo de uma forma um pouco diferente. Isso deve ser registrado nas regras dentro do desenvolvimento.<\/p>\n

Para entregar continuamente, \u00e9 necess\u00e1rio um formato de artefato que percorra a plataforma de infraestrutura. <\/b>Se voc\u00ea joga res\u00edduos de formatos diferentes pela plataforma de infraestrutura, ela se torna n\u00e3o unificada, \u00e9 dif\u00edcil de manter, e surge o problema da d\u00edvida t\u00e9cnica. O formato do artefato precisa ser uniformizado \u2014 essa tamb\u00e9m \u00e9 uma tarefa coletiva: todos precisam se reunir, usar a criatividade e pensar nesse formato.<\/p>\n

O artefato est\u00e1 em constante melhoria e mudan\u00e7a para o ambiente de produ\u00e7\u00e3o enquanto passa pelo pipeline de entrega. <\/b>Quando o artefato se move pelo pipeline, ele constantemente se depara com situa\u00e7\u00f5es desconfort\u00e1veis que se assemelham \u00e0s que o artefato encontrado em produ\u00e7\u00e3o enfrenta. Se na desenvolvimento cl\u00e1ssico isso \u00e9 feito por um administrador de sistema que faz a entrega, no processo DevOps isso acontece continuamente: aqui ele \u00e9 testado de v\u00e1rias formas, ali \u00e9 inserido em um cluster Kubernetes, que \u00e9 semelhante ao ambiente de produ\u00e7\u00e3o, e, de repente, um teste de carga \u00e9 iniciado.<\/p>\n

Isso \u00e9 um pouco como o jogo Pac-Man - o artefato passa por uma certa hist\u00f3ria. Ao mesmo tempo, \u00e9 importante controlar se o c\u00f3digo realmente est\u00e1 passando por essa hist\u00f3ria e se est\u00e1 de alguma forma relacionado ao seu ambiente de produ\u00e7\u00e3o. Hist\u00f3rias sobre produ\u00e7\u00e3o podem ser incorporadas ao processo de Entrega Cont\u00ednua: acontecia assim quando algo falhou, agora vamos programar esse cen\u00e1rio no sistema. Dessa forma, toda vez que o c\u00f3digo passar, ele tamb\u00e9m enfrentar\u00e1 esse cen\u00e1rio, e voc\u00ea n\u00e3o encontrar\u00e1 essa problem\u00e1tica novamente. Voc\u00ea estar\u00e1 ciente dela muito antes de ela afetar seu cliente.<\/p>\n

Diferentes estrat\u00e9gias de deploy. <\/b>Por exemplo, voc\u00ea utiliza testes A\/B ou deploys canary para 'testar' o c\u00f3digo com diferentes clientes, coletando informa\u00e7\u00f5es sobre como o c\u00f3digo se comporta, muito antes de ser liberado para 100 milh\u00f5es de usu\u00e1rios.<\/p>\n

Entregar de forma cont\u00ednua se parece assim.<\/p>\n

\"O
\n<\/p>\n

O processo de entrega Dev, CI, Test, PreProd, Prod - n\u00e3o \u00e9 um ambiente separado, s\u00e3o est\u00e1gios ou esta\u00e7\u00f5es com somas inextingu\u00edveis, pelas quais passa seu artefato.<\/p><\/blockquote>\n

\nSe voc\u00ea tem c\u00f3digo de infraestrutura descrito como Base Service APP, ele ajuda a n\u00e3o esquecer todos os cen\u00e1rios<\/b>, e a registr\u00e1-los tamb\u00e9m como c\u00f3digo para esse artefato, a promover o artefato<\/b> e a alter\u00e1-lo ao longo do caminho.<\/p>\n

Perguntas para autoavalia\u00e7\u00e3o<\/h3>\n

\nO tempo desde a descri\u00e7\u00e3o da funcionalidade at\u00e9 a entrega em produ\u00e7\u00e3o \u00e9 inferior a uma semana em 95% dos casos? A qualidade do artefato aumenta em cada etapa do pipeline? Existe uma hist\u00f3ria pela qual ele passa? Voc\u00ea utiliza diferentes estrat\u00e9gias de deploy?<\/p>\n

Se todas as respostas forem sim, voc\u00ea \u00e9 incrivelmente incr\u00edvel! Escreva suas respostas nos coment\u00e1rios - ficarei feliz em ver).<\/p>\n

Feedback<\/h3>\n

\nEsta \u00e9 a pr\u00e1tica mais complexa de todas. Na confer\u00eancia DevOpsConf, um colega da Infobip estava falando sobre isso e se atrapalhou um pouco nas palavras, porque realmente \u00e9 uma pr\u00e1tica muito complicada sobre o que deve ser monitorado em geral.<\/p>\n

\"O
\n
\nPor exemplo, h\u00e1 muito tempo, quando eu trabalhava na Qik e percebemos que precis\u00e1vamos monitorar tudo. N\u00f3s fizemos isso, e no Zabbix surgiram 150.000 itens que eram monitorados constantemente. Foi assustador, o diretor t\u00e9cnico revirou os olhos:<\/p>\n

\u2014 Pessoal, por que voc\u00ea est\u00e1 maltratando o servidor com coisas que n\u00e3o conseguimos entender?<\/i><\/p>\n

Mas depois aconteceu um caso que mostrou que essa \u00e9 realmente uma estrat\u00e9gia muito legal.<\/p>\n

Um dos servi\u00e7os come\u00e7ou a falhar constantemente. Inicialmente, ele n\u00e3o falhava; o que \u00e9 interessante, nenhum c\u00f3digo foi acrescentado, porque era um broker b\u00e1sico, que praticamente n\u00e3o tinha funcionalidade de neg\u00f3cios \u2014 ele apenas transmitia mensagens entre servi\u00e7os separados. O servi\u00e7o n\u00e3o mudava h\u00e1 4 meses e, de repente, come\u00e7ou a falhar com o erro \"Segmentation fault\".<\/p>\n

Ficamos em choque, abrimos nossos gr\u00e1ficos no Zabbix e descobrimos que, na verdade, h\u00e1 uma semana e meia, o comportamento das requisi\u00e7\u00f5es no servi\u00e7o API havia mudado drasticamente. Depois, observamos que a frequ\u00eancia de envio de um determinado tipo de mensagem havia mudado. Ap\u00f3s investiga\u00e7\u00e3o, descobrimos que eram os clientes Android. Perguntamos:<\/p>\n

\u2014 Pessoal, o que aconteceu com voc\u00eas h\u00e1 uma semana e meia?<\/i><\/p>\n

Em resposta, ouvimos uma hist\u00f3ria interessante sobre como eles reformularam a interface do usu\u00e1rio. \u00c9 bem improv\u00e1vel que algu\u00e9m diga de imediato que mudou a biblioteca HTTP. Para os clientes Android, isso \u00e9 como trocar o sabonete no banheiro \u2014 eles simplesmente n\u00e3o se lembram. No final, ap\u00f3s 40 minutos de conversa, descobrimos que eles realmente mudaram a biblioteca HTTP, e isso alterou os tempos padr\u00e3o. Isso levou a uma mudan\u00e7a no comportamento do tr\u00e1fego no servidor API, que provocou uma corrida interna no broker, fazendo-o falhar.<\/p>\n

Sem monitoramento profundo, isso \u00e9 imposs\u00edvel de detectar.<\/b>. Caso exista ainda o problema dos \"po\u00e7os\" na organiza\u00e7\u00e3o, onde cada um passa a responsabilidade para o outro, isso pode persistir por anos. Voc\u00ea simplesmente reinicia o servidor porque \u00e9 imposs\u00edvel resolver o problema. Quando voc\u00ea monitora, rastreia e acompanha todos os eventos que possui, e utiliza o monitoramento como um teste \u2014 escreve o c\u00f3digo e imediatamente indica como monitor\u00e1-lo, tamb\u00e9m em forma de c\u00f3digo (j\u00e1 temos infraestrutura como c\u00f3digo), tudo fica claro como o dia. Mesmo problemas complexos s\u00e3o facilmente rastre\u00e1veis.<\/p>\n

\"O
\n<\/p>\n

Colete todas as informa\u00e7\u00f5es sobre o que acontece com o artefato em cada fase do processo de entrega \u2014 n\u00e3o em produ\u00e7\u00e3o.<\/p><\/blockquote>\n

\nCarregue o monitoramento no CI, e l\u00e1 j\u00e1 ser\u00e3o vis\u00edveis algumas quest\u00f5es b\u00e1sicas. Depois voc\u00ea as ver\u00e1 tanto no Test quanto no PredProd e nos testes de carga. Colete informa\u00e7\u00f5es em todas as fases, incluindo n\u00e3o apenas m\u00e9tricas e estat\u00edsticas, mas tamb\u00e9m logs: como o aplicativo foi implantado, anomalias \u2014 colete tudo. <\/p>\n

Caso contr\u00e1rio, ser\u00e1 dif\u00edcil entender. J\u00e1 mencionei que DevOps \u00e9 uma complexidade maior. Para lidar com essa complexidade, \u00e9 necess\u00e1rio ter uma an\u00e1lise adequada.<\/b>.<\/p>\n

Quest\u00f5es para autocontrole.<\/h3>\n

\nSeu monitoramento e registro de logs s\u00e3o uma ferramenta de desenvolvimento para voc\u00ea?<\/b> Seus desenvolvedores, e voc\u00ea tamb\u00e9m, ao escrever c\u00f3digo, pensam em como monitor\u00e1-lo?<\/p>\n

Voc\u00ea descobre problemas pelos clientes? Voc\u00ea entende o cliente melhor atrav\u00e9s do monitoramento e do registro de logs?<\/b> Voc\u00ea entende o sistema melhor atrav\u00e9s do monitoramento e do registro de logs?<\/b> Voc\u00ea muda o sistema simplesmente porque viu que a tend\u00eancia est\u00e1 crescendo e entende que mais 3 semanas e tudo vai desmoronar? <\/p>\n

Quando voc\u00ea tem esses tr\u00eas componentes, voc\u00ea pode pensar sobre qual \u00e9 a plataforma de infraestrutura da sua empresa.<\/p>\n

Plataforma de infraestrutura. <\/h2>\n

\nO sentido n\u00e3o est\u00e1 no fato de que se trata de um conjunto de ferramentas desconexas que est\u00e3o em cada empresa.<\/p>\n

O sentido da plataforma de infraestrutura \u00e9 que todas as equipes utilizam essas ferramentas e as desenvolvem em conjunto.<\/p><\/blockquote>\n

\n\u00c9 claro que existem equipes separadas que s\u00e3o respons\u00e1veis pelo desenvolvimento de partes espec\u00edficas da plataforma de infraestrutura. No entanto, a responsabilidade pelo desenvolvimento, funcionalidade e promo\u00e7\u00e3o da plataforma de infraestrutura recai sobre cada engenheiro. Em n\u00edvel interno, isso se torna uma ferramenta comum.<\/b>. <\/p>\n

Todas as equipes desenvolvem a plataforma de infraestrutura, tratando-a com cuidado como se fosse seu pr\u00f3prio IDE.<\/b>. No seu IDE, voc\u00ea instala diferentes plugins para tudo ficar bonito e r\u00e1pido, al\u00e9m de configurar teclas de atalho. Quando voc\u00ea abre o Sublime, Atom ou Visual Studio Code, aparecem erros de c\u00f3digo e voc\u00ea percebe que \u00e9 imposs\u00edvel trabalhar, fica imediatamente triste e corre para consertar seu IDE.<\/p>\n

Trate sua plataforma de infraestrutura da mesma forma. Se voc\u00ea perceber que algo n\u00e3o est\u00e1 certo, fa\u00e7a uma solicita\u00e7\u00e3o, caso n\u00e3o consiga corrigir sozinho. Se for algo simples, conserte por conta pr\u00f3pria e envie um pull request \u2014 a equipe revisa e adiciona. Essa \u00e9 uma abordagem diferente em rela\u00e7\u00e3o \u00e0s ferramentas de engenharia na mente do desenvolvedor.<\/p>\n

A plataforma de infraestrutura garante a transfer\u00eancia de artefatos do desenvolvimento para o cliente, com melhora cont\u00ednua da qualidade.<\/b>. Na IP, um conjunto de hist\u00f3rias est\u00e1 programado, que ocorre com o c\u00f3digo em produ\u00e7\u00e3o. Ao longo dos anos de desenvolvimento, essas hist\u00f3rias se acumulam, algumas delas s\u00e3o \u00fanicas e se referem apenas a voc\u00ea \u2014 n\u00e3o \u00e9 poss\u00edvel encontr\u00e1-las na internet. <\/p>\n

Nesse momento, a plataforma de infraestrutura se torna sua vantagem competitiva.<\/b>, porque ela cont\u00e9m o que n\u00e3o existe na ferramenta do concorrente. Quanto mais madura sua IP, maior sua vantagem competitiva em termos de Time-to-market. Aqui surge o problema do vendor lock.<\/b>: voc\u00ea pode adotar a plataforma de algu\u00e9m, mas ao utilizar a experi\u00eancia de terceiros, n\u00e3o compreender\u00e1 qu\u00e3o relevante ela \u00e9 para voc\u00ea. Sim, nem toda empresa pode construir uma plataforma como a da Amazon. \u00c9 uma linha t\u00eanue, onde a experi\u00eancia da empresa \u00e9 pertinente \u00e0 sua posi\u00e7\u00e3o no mercado, e n\u00e3o se deve aceitar vendor lock. Isso tamb\u00e9m \u00e9 algo importante para se pensar.<\/p>\n

Esquema<\/h3>\n

\nEste \u00e9 o esquema b\u00e1sico da plataforma de infraestrutura, que ajudar\u00e1 voc\u00ea a organizar todas as pr\u00e1ticas e processos em uma empresa de DevOps.<\/p>\n

\"O
\n
\nVamos considerar do que ela \u00e9 composta.<\/p>\n

Sistema de orquestra\u00e7\u00e3o de recursos<\/b>, que fornece CPU, mem\u00f3ria e disco para aplicativos e outros servi\u00e7os. Acima disso, existem servi\u00e7os de baixo n\u00edvel:<\/b>monitoramento, registro, CI\/CD Engine, armazenamento de artefatos, infraestrutura como c\u00f3digo para sistemas.<\/p>\n

Servi\u00e7os de n\u00edvel superior.<\/b>: banco de dados como servi\u00e7o, filas como servi\u00e7o, Load Balance como servi\u00e7o, redimensionamento de imagens como servi\u00e7o, Big Data como servi\u00e7o. Em cima disso \u2014 um pipeline que fornece c\u00f3digo constantemente modificado ao seu cliente<\/b>.<\/p>\n

Voc\u00ea obt\u00e9m informa\u00e7\u00f5es sobre como seu software est\u00e1 funcionando para o cliente, modifica, fornece novamente esse c\u00f3digo, obt\u00e9m informa\u00e7\u00f5es \u2014 e assim desenvolve continuamente tanto a plataforma de infraestrutura quanto seu software.<\/p>\n

Na representa\u00e7\u00e3o, um delivery pipeline consiste em v\u00e1rias etapas. Mas esta \u00e9 uma representa\u00e7\u00e3o conceitual, que serve como exemplo \u2014 n\u00e3o deve ser replicada exatamente. As etapas interagem com os servi\u00e7os como servi\u00e7os \u2014 cada componente da plataforma traz sua pr\u00f3pria hist\u00f3ria: como os recursos s\u00e3o alocados, como o aplicativo \u00e9 iniciado, trabalha com os recursos, \u00e9 monitorado e modificado.<\/p>\n

\u00c9 importante entender que cada parte da plataforma traz uma hist\u00f3ria, e perguntar a si mesmo \u2014 que hist\u00f3ria esse componente traz, talvez seja melhor descart\u00e1-lo e substitu\u00ed-lo por um servi\u00e7o de terceiros. Por exemplo, \u00e9 poss\u00edvel substituir um componente pelo Okmeter? Talvez eles j\u00e1 tenham aprimorado essa expertise muito mais do que n\u00f3s. Mas talvez n\u00e3o \u2014 talvez tenhamos uma expertise \u00fanica e precisemos implementar o Prometheus e desenvolver isso ainda mais.<\/p>\n

Cria\u00e7\u00e3o da plataforma<\/h3>\n

\n\u00c9 um processo de comunica\u00e7\u00e3o complexo. Quando voc\u00ea tem pr\u00e1ticas b\u00e1sicas, voc\u00ea inicia a comunica\u00e7\u00e3o entre diferentes engenheiros e especialistas, que elaboram requisitos e padr\u00f5es e os modificam constantemente para diferentes ferramentas e abordagens. Aqui, a cultura presente no DevOps \u00e9 fundamental.<\/p>\n

\"O
\nCom a cultura, tudo \u00e9 muito simples \u2014 \u00e9 colabora\u00e7\u00e3o e comunica\u00e7\u00e3o<\/b>, ou seja, a vontade de trabalhar juntos em um espa\u00e7o comum, o desejo de dominar uma ferramenta juntos. N\u00e3o h\u00e1 nada de complicado \u2014 \u00e9 tudo muito simples, quase banal. Por exemplo, todos n\u00f3s vivemos em um pr\u00e9dio e mantemos sua limpeza \u2014 esse \u00e9 o n\u00edvel de cultura.<\/p>\n

E quanto a voc\u00ea?<\/h3>\n

\nNovamente, perguntas que voc\u00ea pode se fazer.<\/p>\n

A plataforma de infraestrutura est\u00e1 bem definida? Quem \u00e9 respons\u00e1vel pelo seu desenvolvimento? Voc\u00ea compreende as vantagens competitivas da sua plataforma de infraestrutura?<\/p>\n

Essas perguntas devem ser constantemente feitas a si mesmo. Se algo pode ser transferido para servi\u00e7os externos, deve ser feito; se um servi\u00e7o externo come\u00e7a a bloquear seu progresso, ent\u00e3o \u00e9 necess\u00e1rio construir um sistema internamente.<\/p>\n

Ent\u00e3o, DevOps\u2026<\/h2>\n

\n\u2026 \u00e9 um sistema complexo que deve conter:<\/p>\n