Você usa a abordagem do DevOps em casa? Aqui está o código do marido implantado para funcionar. A esposa de infraestrutura prepara ovos fritos, prepara café e passa roupas. O gato que monitora escorrega debaixo dos pés com o tempo, limpa a bandeja e indica em voz alta quando a esposa se desvia do protocolo estabelecido.
No primeiro dia do Slurm DevOps, conheci Artyom Galonsky, escritório do Bureau do STO. Ele lecionou sobre CI / CD e a introdução à automação. Ele falou sobre as linhas transportadoras de montagem da fábrica e sua aplicação em TI. E, ao mesmo tempo, ele compartilhou exemplos práticos, como a construção de um pipeline "comum".
Após o discurso, eu o peguei em uma pausa para o café e me pedi para contar sobre o lugar do DevOps em sua atividade profissional e, ao mesmo tempo, quais requisitos ele vê para o cargo de engenheiro do DevOps. Artyom me chocou, dizendo que os engenheiros de DevOps existem no mesmo universo que os unicórnios rosa. E para ele, " não há engenheiros de DevOps, há bons administradores que entendem o Kubernetes ".
Sobre carreira
Você está em desenvolvimento há 11 anos. Começou no Bureau Bureau?
Não. Ele começou como freelancer em 2008, depois criou várias startups. "Otfermery" era uma startup. Existiu por 2 anos e tomou forma. Em 2011, ele começou a se envolver em sistemas de CRM para uma agência de seguros. Havia uma equipe pequena - 4 pessoas. Entre 11 e 12, ele se tornou um líder de equipe. Ele foi um desenvolvedor líder, chefe do departamento de desenvolvimento da empresa. Em 2017, tornou-se o STO da RedStart em Kaliningrado. E no início de 2018, mudei para o Bureau of the Bureau.
O que te atraiu?
O próximo passo. Eles ofereceram condições interessantes. A oportunidade de montar sua equipe. Além de projetos interessantes. Mudei-me de Kaliningrado para Moscou. Ele trabalhou em Moscou por seis meses. Então os diretores do Bureau of Bureau decidiram que deveríamos abrir um escritório em Kaliningrado.
Porque
Em primeiro lugar, eu próprio sou de Kaliningrado. Conheço mais profissionais de alta qualidade e fortes em Kaliningrado do que em Moscou. A manutenção de qualquer necessidade é mais barata em Kaliningrado. E a comunidade de TI é forte lá. E a zona econômica livre está avançando lentamente.
Em Southbridge, acreditamos que o potencial da província ainda não foi totalmente liberado. Que existe um grande número de pessoas talentosas e inteligentes que, por várias razões - psicológicas, sociais, financeiras - não podem se mudar para a capital.
Sim, nem é psicológico ou por que razões ... As pessoas simplesmente não querem se mudar.
Sim, estou falando sobre isso. Nem todo mundo quer se mudar.
E isso não é algum tipo de problema - psicológico ou financeiro. Uma pessoa simplesmente não quer.
Sim Eu concordo "Problema" é uma palavra ruim. Em vez disso, "instalação".
Uma pessoa simplesmente não quer. Ele está confortável lá. Trabalhei seis meses em Moscou, colecionando uma equipe. Era difícil para mim de manhã passar 40 minutos em uma viagem ao metrô. Ou em engarrafamentos no carro ainda mais. Agora estou em Kaliningrado esses quarenta minutos andando por lugares pitorescos, lagos passados, casas bonitas. E esses quarenta minutos eu aproveito a vida. E respire ar puro. 20 minutos - e estou no mar. 40 minutos - e eu estou na Europa. Além disso, muitos caras que moram em Kaliningrado quando descobriram que eu estava voltando disseram: " OK, vamos lá, teremos o maior prazer em retornar à sua equipe e continuar trabalhando com você ". E, há um ano, nosso back office - desenvolvimento, testes, análises, gerentes de suporte - está localizado em Kaliningrado. E nós somos felizes e felizes.
E em Moscou?
Em Moscou, temos um escritório da frente. Gerenciamento, gerentes de projeto, conta de diretor, designers de interface, designers e administradores de sistema.
E como é a interação?
Nada interfere. Tudo funciona quase perfeitamente. Tudo depende de como você o configura.
Você, como estação de serviço, a quem você prefere - funcionários remotos ou no escritório?
O principal é estabelecer a troca correta de conhecimentos. Eu omito o fluxo de trabalho - porque, se o fluxo de trabalho não for estabelecido, não importa como o conhecimento é trocado. Nada vai funcionar de qualquer maneira. Mas a troca de conhecimento para que as pessoas compartilhem suas práticas - o que inventaram, entenderam, fizeram - é melhor internamente quando estão sentados no mesmo escritório. De uma forma ou de outra, eles começarão a se comunicar sobre esse tópico. E quando as pessoas estão remotamente, elas podem não compartilhar. Portanto, é importante criar uma base de conhecimento. É necessário motivar as pessoas a compartilhar essas informações. Toda sexta-feira, a tecnologização, ou seja, todo mundo que não tem um projeto de “queima”, está envolvido em auto-educação na segunda metade da sexta-feira. E então ele compartilha com os outros.
Sobre desenvolvimento
Como você se motiva?
Eu motivo o desenvolvimento. Francamente falando, tudo muda muito rapidamente na "web" e, se você não se desenvolver, permanecerá nesse nível para sempre. E em termos de dinheiro você não crescerá, e em termos de desenvolvimento.
Uma das minhas citações favoritas de Lewis Carroll de "Alice no País das Maravilhas": "Aqui você tem que correr o mais rápido possível para permanecer no mesmo lugar, mas para chegar a outro lugar, você precisa correr duas vezes mais rápido".
Temos quase o mesmo. Nos 11 anos em que estive envolvido na web, a tecnologia mudou drasticamente. Há dois anos, relativamente falando, não sabíamos o que é o Kubernetes e como implementá-lo. Agora está em todo lugar. E em um ano será necessário para todos. Porque a carga aumentará. Se você não bombear conhecimento e usá-lo em seus projetos, ficará para trás. Iniciando cada projeto, tentamos apresentar algo novo. Trabalhando constantemente em um produto, é bastante difícil introduzir um novo. E é um pouco mais fácil para nós: iniciando um novo projeto, apresentamos novas tecnologias que estudamos e testamos. E estamos desenvolvendo de projeto para projeto.
Quais tecnologias você usa agora e quais considera relevantes, necessárias?
Temos o que estamos fazendo agora, a pilha é bastante simples - o front-end do react.js, para o back-end que usamos parcialmente o PHP antes e agora, agora estamos tentando mudar para o Go. Esta é uma linha reta, para onde estamos nos movendo, para deixar o PHP completamente no Go e desenvolver nele. Esta é uma tecnologia nova, boa e estável, que proporciona um excelente aumento na velocidade - tanto no desenvolvimento quanto na velocidade do próprio produto. Ou seja, nossa pilha é React.js, PHP e Go. Isto é para linguagens de programação. Bem, assim como as tecnologias padrão do Redis, PostgreSQL, RabbitMQ.
Você pode se lembrar de tecnologias que já estão desatualizadas. Nós conversamos recentemente com os caras - então eles se provocaram porque eram profissionais em Perl.
Sim Bem, provavelmente alguém está usando Perl. O mesmo JS, que está em constante evolução ... O que era antes do ES6 foi descontinuado ou o mesmo jpl. Os mesmos js chegaram ao "nó" e tornaram-se node.js. O mesmo php, bem, alguém não gosta - a versão 5 estava ruim, agora o 7.2 está se desenvolvendo sob as tendências atuais. Para mim, não há um que esteja completamente desatualizado. Moralmente, talvez sim. Ou eu cresci com a tecnologia. Anteriormente, há 10 anos, usei o MySQL, agora para os projetos que estou apresentando, é inútil em quase todos os lugares. As tecnologias que eu tinha ... Provavelmente, apenas cresci com elas do que estavam desatualizadas.
Do que você gosta no Go agora?
Velocidade de execução, economizando. Para todo mundo. O que vejo, comunicando-me com meus arquitetos, líderes e desenvolvedores, digamos apenas que o que estamos acostumados a ver no script php, ele permanece no Go, além dos recursos das linguagens compiladas. Goroutines, multicanal. Aquilo que não estava no php, e nós o fizemos através do php-fpm, relativamente falando. Além de forte digitação de dados. E também uma compilação rápida do próprio binário.
O que é um bom desenvolvedor para você?
Para mim, um bom desenvolvedor é alguém que pode mudar para uma nova linguagem de programação em cerca de 2-3 meses para entendê-la. Naturalmente, ele não fará nada por 2-3 meses. Ele estará na fase de "junho", faça tarefas simples. Bombeado rapidamente - e começa a fechar tarefas complexas e boas.
Com qual empresa você se relaciona - laranja, turquesa?
Não somos turquesas, com certeza. Em vez de laranja. Com controle vertical. Eu próprio sou um pouco autoritário em administração. Fazemos isso e aquilo - e se eles não vierem a mim e provarem com exemplos óbvios que é melhor de outra maneira, será muito difícil me convencer. Se não for comprovado, isso não será necessário. Suponha que um funcionário venha e diga: “Artyom, precisamos fazer isso. Por esse e esse motivo. Você sugeriu uma má ideia. Sim, você é o diretor e arquiteto. Mas você não ofereceu uma ideia muito boa. E devemos fazê-lo. E se eu não tiver sido claramente e 100% comprovado, seguirei em frente com minha decisão. Portanto, não turquesa, com certeza.
Digamos, relativamente falando, uma nova tecnologia apareceu. E como um funcionário pode provar a você que vale a pena usá-lo se poucas pessoas ainda o usam e não há exemplos representativos e casos práticos? Mas a tecnologia é supostamente promissora.
Mostrar projeto de estimação. Bem, não apenas: " Olha, foi o que eu fiz ." Isso já deve estar montado. Para que uma pessoa conscientemente faça isso, ele tentou colocá-lo em produção, para lhe dar uma carga. Ele veio até mim e disse: “ Encontrei esse recurso, linguagem, tecnologia. Criei um pequeno produto ou microsserviço concluído ". Então eu escuto. Ainda existe um problema - ao trabalhar com um negócio sério, são necessárias tecnologias estabelecidas. Podemos seguir em frente e seguir em frente. E nossos clientes - às vezes são monstruosos, devido ao fato de serem muito grandes, principalmente os estaduais -, estão prontos apenas para tecnologias estáveis e não gostam de experimentos. Lembro-me de dois anos atrás, sugeri o react.js para alguém - e a resposta precisa é “ Não. Nós não vamos trabalhar. Porque Este é algum tipo de biblioteca para interface do usuário. Não. HTML, CSS, JS - isso nos convém. " Nas grandes empresas, as estruturas estatais mostram que o desenvolvimento de novas tecnologias está um pouco atrasado. Até que a tecnologia se estabilize, até encontrar uma pessoa que a conheça e a apóie por dentro, eles não correrão riscos.
Sobre projetos
Quando é fácil trabalhar com um cliente?
Eu acho que quando existe um bom arquiteto do lado do cliente. Então torna-se interessante trabalhar. Então obtemos uma boa ordem, boas tarefas e boas soluções. E eles entendem como isso será implementado. E quando no local do cliente há apenas a gerência e um analista de produto que desejam algo assim, fica mais difícil. Os sistemas são muito grandes. E entregamos um produto que fará parte do sistema. E eles nos dizem: “ Ah, e conecte esses dois produtos. Para que o usuário clique neste botão e ele tenha isso ... ”E há muita coisa escondida - autorização, transferência de dados. E você pergunta: “ Pessoal, tudo bem, como isso deve acontecer lá dentro? O que exatamente você quer? "E eles responderam:" Oh, nós não sabemos. O principal é que tudo deve ser bonito. E o que está por trás - você conta à nossa segurança da informação. Deixe-os verificar se funciona bem ou não .
Você consegue se lembrar de um exemplo quando resolveu um problema rápida e originalmente?
Temos projetos em que a autorização é apenas da ESIA. E a ESIA frequentemente se deita. Quando uma pessoa faz login, verificamos que foi ele quem fez login. E há uma reconciliação de dados da ESIA de que seu passaporte ou outros documentos não foram atualizados. E então a ESIA estragou algo. E temos um grupo de clientes que tentou fazer login e recebeu a mensagem “ Seus dados foram alterados. Por favor confirme . " A ESIA começou a emitir um novo nome ou nome do meio ou novos dados de passaporte. E não podemos fazer nada, porque nosso sistema está tão configurado que a ESIA é o centro da verdade para nós. E paramos a autorização por um tempo. A ESIA rapidamente decidiu tudo. Nossos administradores no nível do balanceador de usuários acessaram a página " Desculpe, temporariamente não funciona ". E concluímos rapidamente, para que apenas clientes antigos pudessem fazer login sem atualizações temporariamente. E novos usuários não eram permitidos. Bem, essa não é realmente a nossa situação, mas nos conectamos lá para uma solução.
Diga-me, qual foi o projeto de desafio mais interessante para você ultimamente? De que você obteve prazer profissional?
A: Eu gostei ... Fizemos uma conta pessoal para a Siemens Finance. Uma subsidiária da Siemens, que atua na área de leasing na Rússia. Juntamente com eles, desenvolvemos uma conta pessoal. É um prazer aqui que a Siemens nos deu a oportunidade de construir uma boa arquitetura, o cliente não interveio e transmitiu " Pessoal, confiamos em você ". Fizemos uma boa interface do usuário e UX para eles. Muito bom trabalho com o cliente. E isso não foi um desafio ou superação. Então gostei muito do trabalho. Do produto que é finalmente recebido. E agora o produto funciona, vive. Todo mundo gosta dele - e eu gosto dele. E assim os desafios que temos são constantemente. Ao trabalhar com grandes empresas sem isso, de forma alguma. Cada empresa possui 12 departamentos - existe um departamento de TI, um departamento de infraestrutura, um departamento de lógica de negócios e outra coisa. Além disso, existem vários fornecedores, pessoas como você, que integram o CRM deles. E coordenar quaisquer mudanças com todos esses departamentos é um desafio. Você oferece sua arquitetura, comunica-se com o arquiteto da empresa principal, interage com arquitetos de fornecedores ...
Mas o arquiteto da empresa cliente não deveria lidar com isso?
Nem sempre. Existe um tópico tão na moda - transformação digital. Por exemplo, a empresa tem um arquiteto e ele estava diretamente envolvido na arquitetura de sua solução. Por exemplo, cobrança ou setor bancário. Mas ele, como arquiteto de todo o sistema, não possui a experiência e competência necessárias. Mas um bom especialista começa a aprender. E quem não é muito ou já tem idade é um pouco mais complicado aqui - porque eles estão mal observando as novas tendências. E você tem que se comunicar por um longo tempo e explicar, dizem eles, pessoal, vamos tentar esta solução progressiva. E em algum lugar há jovens arquitetos que cresceram na moderna "web". É bem simples lá - condicionalmente, sincronizamos assim, conectamos esses módulos assim. E eles dirigem com rapidez e competência.
Então você já vê duas gerações diferentes de desenvolvedores?
Na web, sim. Porque agora tudo está se movendo para a web. Agora, mesmo os sistemas internos estão gradualmente migrando para microsserviços que se comunicam pela API. E a API geralmente é http e https. Os arquitetos devem entender como isso funciona. E a maneira mais fácil de ouvir aqueles que trabalharam na web. Na minha opinião. Muitas vezes essa situação ocorre. O cliente deseja um novo site interessante. Ele vê qual site um concorrente possui, como esse site funciona. E ele vem, exige que estabeleçamos toda a história digital do site, até o CRM. E nós lidamos apenas com o site. Estamos prontos para integrar com o CRM de alguém. E acontece que nos tornamos um impulsionador de mudanças para uma empresa em particular.
Sobre a tecnologia
Transformação digital - quanto você acha que é necessário?
Como qualquer tema publicitário, é elegante e necessário. Temos um número muito grande de pedidos para fazer um download do Excel. Um número incrível de empresas trabalha no Excel. E eles precisam fazer esse "excel" carregar, analisar, se transformar em um banco de dados e então você pode trabalhar com ele e, em seguida, descarregá-lo. A transformação digital deve levar à transição para sistemas de trabalho normais - CRM, sistemas de conteúdo, CMS. E abandone o excel e viva em um mundo da web normal. Existe um bom exemplo. Na empresa anterior, onde trabalhei antes do Bureau-Bureau, tínhamos duas empresas clientes. E pudemos acompanhar em detalhes como tudo acontece. Em uma empresa, o atendimento ao cliente passou pelo Excel. Havia um grande banco de dados. Foi o ano de 2012-2013. O CRM normal não era adequado para isso - muito fluxo de trabalho e demorou muito tempo para configurá-lo no CRM comum. E uma empresa foi trabalhar no Excel. E o segundo passou meio ano - e escreveu seu CRM. Como resultado, a primeira empresa, seis meses depois de atingir o pico de vendas, começou a trabalhar com os clientes - eles entraram em colapso. Só que o serviço de chamadas não foi capaz de fornecer um serviço bom e rápido. E a segunda empresa, com seu CRM, pelo contrário, rastreou rapidamente com um botão, que tipo de cliente, como ele chegou a eles, quais gerentes responderam. Eles sobreviveram a esse pico de crescimento - e ainda estão trabalhando. O fluxo de trabalho eletrônico também é uma tendência. Economia de tempo. Quem opera mais rápido com informações, ele ganha mais rapidamente. Então, em tudo. Se não houver um bom monitoramento e um bom registro no projeto, os engenheiros não serão capazes de entender rapidamente qual é o problema. E a sobrevivência e o sucesso dos negócios realmente dependem disso agora. Portanto, é necessário não apenas foder um site bonito, mas criar o site certo e o sistema de registro correto. A transformação digital é necessária. É necessário manter-se atualizado. Se existem tais tecnologias, devemos tentar apresentá-las.
Que tecnologias você vê agora que serão promissoras no futuro próximo? Por exemplo, há dois anos, Kubernetes era considerado promissor. Agora é simplesmente necessário.
O futuro é aprendizado de máquina e IA. Em cinco anos, isso se tornará relevante. Há um ano, havia criptografia e aprendizado de máquina no hype. Agora está tudo quieto. Mas ainda assim, nos próximos cinco anos, o aprendizado de máquina disparará, como penso. O trabalho está em andamento - a experiência e as soluções estão se acumulando.
Acredita-se que, com o aprendizado de máquina e a inteligência artificial, muitas profissões simplesmente desapareçam. Isso se aplica a professores e economistas. E os advogados dizem que a tecnologia blockchain moverá certas áreas da jurisprudência. Que profissões em TI, como você vê, desaparecerão?
As capas, como penso, desaparecerão. Parece-me nos próximos três anos. Como diz o ditado, lembre-se deste tweet. (risos) Provavelmente, o aprendizado de máquina será escrito em breve, o que será um bom layout. Eles inventarão alguma coisa. E então, provavelmente, programadores de sistemas simples desaparecerão. Ainda assim, sempre haverá programadores que projetarão e programarão o núcleo do microchip. Sempre haverá programadores.
O devops
Agora, no mercado, há um certo déficit de engenheiros de DevOps ...
Ouça, sou categoricamente contra um engenheiro de DevOps.
Porque
DevOps é uma prática, é uma filosofia. Engenheiro de DevOps - quem é? É um administrador bombeado ou é um "back-end" bem bombeado que pode estar no administrador? Para mim, não há engenheiros de DevOps, para mim existem bons administradores que entendem o Kubernetes. Mas o Kubernetes não é DevOps. A única coisa que aceito para mim é o evangelista do DevOps. Quem pode vir à empresa e dizer: “ Gente, precisamos seguir nessa direção. Aprenda a se comunicar e interagir . ” Porque o DevOps não é sobre tecnologia. Em geral, toda a filosofia do DevOps é sobre interação. Para aprender como se comunicar, desenvolvimento e controle de qualidade e suporte adicional. E todos esses engenheiros de DevOps me lembram o hype dos mestres de scrum cerca de três anos atrás. Todo mundo precisava de mestres de scrum, ninguém poderia trabalhar sem eles. Ou cinco anos atrás, todos precisavam urgentemente de um gerente de instalação do Jira. , «», . , DevOps — .
, - ?
, - . . , — , , «», , . , «». , DevOps. , DevOps-. . — . Kubernetes.
, IT-?
. . . . 90- .
, , ?
. . , . - . — , . , . , , , . . . , . , . , , . — .
Post scriptum
. , , , , - — , , . . , , , , , -. , . ? «Time will tell. Sooner or later time will tell».©