{"id":38521,"date":"2019-10-31T22:24:16","date_gmt":"2019-10-31T19:24:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kto-takie-devops\/"},"modified":"2019-10-31T22:24:16","modified_gmt":"2019-10-31T19:24:16","slug":"kto-takie-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/kto-takie-devops","title":{"rendered":"Quem s\u00e3o os DevOps?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Atualmente, esta \u00e9 quase a posi\u00e7\u00e3o mais cara do mercado. A agita\u00e7\u00e3o em torno dos engenheiros de 'DevOps' supera todos os limites imagin\u00e1veis, e a situa\u00e7\u00e3o \u00e9 ainda pior com os engenheiros Senior DevOps.
\nEu trabalho como chefe do departamento de integra\u00e7\u00e3o e automa\u00e7\u00e3o, adivinha a tradu\u00e7\u00e3o em ingl\u00eas \u2014 DevOps Manager. A tradu\u00e7\u00e3o em ingl\u00eas reflete realmente nossas atividades di\u00e1rias? Provavelmente n\u00e3o, enquanto a vers\u00e3o em russo \u00e9 mais precisa nesse caso. De acordo com meu trabalho, \u00e9 natural que eu precise entrevistar os futuros membros da minha equipe e, no \u00faltimo ano, passei por cerca de 50 pessoas, e outras tantas foram eliminadas em pr\u00e9-sele\u00e7\u00f5es com meus colaboradores.<\/p>\n

<\/p>\n

Ainda estamos \u00e0 procura de colegas, pois atr\u00e1s do r\u00f3tulo DevOps esconde-se uma grande camada de v\u00e1rios tipos de engenheiros.<\/a><\/noindex><\/p>\n

<\/p>\n

Tudo que est\u00e1 escrito abaixo \u00e9 minha opini\u00e3o pessoal; voc\u00ea n\u00e3o \u00e9 obrigado a concordar com ela. No entanto, eu reconhe\u00e7o que pode influenciar sua percep\u00e7\u00e3o sobre o assunto. Apesar do risco de desagradar, publico minha opini\u00e3o porque considero que ela merece ser dita.<\/p>\n

<\/p>\n

As empresas t\u00eam entendimentos distintos sobre quem s\u00e3o os engenheiros DevOps e, para uma contrata\u00e7\u00e3o r\u00e1pida, aplicam esse r\u00f3tulo a todos. A situa\u00e7\u00e3o \u00e9 estranha, j\u00e1 que as empresas est\u00e3o dispostas a pagar recompensas irreais a essas pessoas, recebendo, na maioria das vezes, apenas um administrador-ferramenta.<\/p>\n

<\/p>\n

Ent\u00e3o, quem s\u00e3o os engenheiros DevOps?<\/h2>\n

<\/p>\n

Vamos come\u00e7ar com a hist\u00f3ria do surgimento \u2014 o Development Operations surgiu como mais um passo para otimizar a intera\u00e7\u00e3o em pequenas equipes, visando aumentar a velocidade de produ\u00e7\u00e3o do produto como resultado esperado. A ideia era fortalecer a equipe de desenvolvimento com conhecimentos sobre procedimentos e abordagens na gest\u00e3o do ambiente do produto. Em outras palavras, um desenvolvedor deve entender e saber como seu produto funciona em determinadas condi\u00e7\u00f5es, deve compreender como implementar seu produto, quais caracter\u00edsticas do ambiente ajustar para aumentar o desempenho. Assim, com o tempo, surgiram desenvolvedores com a abordagem DevOps. Esses desenvolvedores escreviam scripts de constru\u00e7\u00e3o e empacotamento para facilitar suas atividades e a opera\u00e7\u00e3o do ambiente produtivo. No entanto, a complexidade da arquitetura das solu\u00e7\u00f5es e a influ\u00eancia m\u00fatua dos componentes da infraestrutura come\u00e7aram a piorar o desempenho dos ambientes com o passar do tempo; a cada itera\u00e7\u00e3o, eram necess\u00e1rias compreens\u00f5es mais profundas de diversos componentes, diminuindo a produtividade do pr\u00f3prio desenvolvedor devido ao custo adicional de entender os componentes e ajustar os sistemas para tarefas espec\u00edficas. O custo pr\u00f3prio do desenvolvedor aumentava, assim como o custo do produto, e os requisitos para novos desenvolvedores na equipe dispararam, uma vez que tamb\u00e9m precisavam cobrir as responsabilidades da 'estrela' do desenvolvimento, que, naturalmente, se tornava cada vez menos acess\u00edvel. Tamb\u00e9m vale a pena notar que, na minha experi\u00eancia, poucos desenvolvedores se interessam pela especificidade do manuseio de pacotes pelo n\u00facleo do sistema operacional, pelas regras de roteamento de pacotes e pelos aspectos de seguran\u00e7a do host. O passo l\u00f3gico foi trazer um administrador, que est\u00e1 familiarizado com isso, e atribuir a ele responsabilidades desse tipo, o que, gra\u00e7as \u00e0 sua experi\u00eancia, permitiu alcan\u00e7ar os mesmos resultados a um custo inferior em compara\u00e7\u00e3o com o custo da 'estrela' do desenvolvimento. Esses administradores eram colocados na equipe, e sua tarefa principal era gerenciar ambientes de teste e produtivos, de acordo com as regras de uma equipe espec\u00edfica, utilizando recursos designados exclusivamente para essa equipe. Assim, realmente apareceram os DevOps na vis\u00e3o da maioria.<\/p>\n

<\/p>\n

Parcial ou completamente, ao longo do tempo, esses administradores de sistema come\u00e7aram a entender as necessidades dessa equipe espec\u00edfica de desenvolvimento \u2013 como facilitar a vida dos desenvolvedores e testadores, como implantar uma atualiza\u00e7\u00e3o e n\u00e3o ter que passar a noite de sexta-feira no escrit\u00f3rio corrigindo erros de implanta\u00e7\u00e3o. Com o passar do tempo, os administradores de sistema se tornaram os 'her\u00f3is', compreendendo o que os desenvolvedores desejavam. Para minimizar o impacto, come\u00e7aram a ser adotadas ferramentas de gerenciamento, e todos se lembraram de antigos e confi\u00e1veis m\u00e9todos de isolamento em n\u00edvel de sistema operacional, que permitiam minimizar os requisitos de seguran\u00e7a, de gerenciamento da rede e at\u00e9 da configura\u00e7\u00e3o do host como um todo, consequentemente reduzindo as exig\u00eancias para os novos 'her\u00f3is'. <\/p>\n

<\/p>\n

Surge uma 'coisa maravilhosa' \u2013 o docker. Por que maravilhoso? Apenas porque a cria\u00e7\u00e3o de isolamento em chroot ou jail, assim como o OpenVZ, exigia conhecimentos n\u00e3o triviais de sistema operacional, enquanto a ferramenta contr\u00e1ria permite criar facilmente um ambiente isolado para aplica\u00e7\u00e3o em um determinado host com tudo necess\u00e1rio dentro, e entregar as r\u00e9deas novamente ao desenvolvimento, enquanto o administrador de sistema gerencia apenas um host, garantindo sua seguran\u00e7a e alta disponibilidade \u2013 uma simplifica\u00e7\u00e3o l\u00f3gica. Contudo, o progresso n\u00e3o para, e os sistemas est\u00e3o se tornando cada vez mais complexos, com mais e mais componentes, um \u00fanico host j\u00e1 n\u00e3o atende \u00e0s necessidades do sistema, e \u00e9 necess\u00e1rio construir clusters. Retornamos aos administradores de sistema que s\u00e3o capazes de construir esses sistemas.<\/p>\n

<\/p>\n

Ciclo ap\u00f3s ciclo, surgem diferentes sistemas que simplificam o desenvolvimento e\/ou administra\u00e7\u00e3o, e aparecem sistemas de orquestra\u00e7\u00e3o, que at\u00e9 que se precise desviar do processo padr\u00e3o, s\u00e3o simples de usar. A arquitetura de microservi\u00e7os tamb\u00e9m surgiu com o objetivo de simplificar tudo isso \u2013 menos interdepend\u00eancias, mais f\u00e1cil de gerenciar. Em minha experi\u00eancia, n\u00e3o vivenciei uma arquitetura de microservi\u00e7os completa, eu diria que \u00e9 50 a 50 \u2013 50 por cento s\u00e3o microservi\u00e7os, caixas pretas, o que entra \u00e9 processado e sai, os outros 50 \u2013 um mon\u00f3lito despeda\u00e7ado, servi\u00e7os incapazes de operar separadamente de outros componentes. Tudo isso novamente imp\u00f4s restri\u00e7\u00f5es ao n\u00edvel de conhecimento tanto dos desenvolvedores quanto dos administradores.<\/p>\n

<\/p>\n

Essas \"oscila\u00e7\u00f5es\" de n\u00edvel de conhecimento especializado de determinado recurso continuam at\u00e9 hoje. Mas nos desviamos um pouco, h\u00e1 muitos pontos que valem a pena serem abordados.<\/p>\n

<\/p>\n

Engenheiro de Constru\u00e7\u00e3o\/Engenheiro de Lan\u00e7amento<\/h2>\n

<\/p>\n

S\u00e3o engenheiros altamente especializados, surgidos como um meio de padronizar os processos de constru\u00e7\u00e3o de software e seus lan\u00e7amentos. Durante a introdu\u00e7\u00e3o do Agile em larga escala, parecia que haviam perdido a demanda, mas isso est\u00e1 longe de ser verdade. Essa especializa\u00e7\u00e3o surgiu para justamente padronizar a constru\u00e7\u00e3o e a entrega de software em grandes escalas, ou seja, utilizando t\u00e9cnicas padr\u00e3o para todos os produtos da empresa. Com o surgimento do DevOps, os desenvolvedores perderam parcialmente algumas fun\u00e7\u00f5es, visto que se tornaram respons\u00e1veis por preparar o produto para entrega. No entanto, considerando a infraestrutura em mudan\u00e7a e a abordagem voltada para uma entrega r\u00e1pida, sem se preocupar com a qualidade, acabaram se tornando um impedimento \u00e0s mudan\u00e7as, visto que seguir padr\u00f5es de qualidade inevitavelmente retarda as entregas. Assim, gradualmente, parte das fun\u00e7\u00f5es dos engenheiros de Build\/Release foi transferida para os administradores de sistemas.<\/p>\n

<\/p>\n

As ops s\u00e3o t\u00e3o diferentes<\/h2>\n

<\/p>\n

Seguimos em frente e uma vez mais, a ampla gama de responsabilidades e a falta de profissionais qualificados nos impulsionam para uma especializa\u00e7\u00e3o rigorosa. Assim como cogumelos ap\u00f3s a chuva, surgem v\u00e1rias opera\u00e7\u00f5es:<\/p>\n

<\/p>\n