Olá a todos! Meu nome é Timur Gilmullin, sou vice-chefe do departamento de tecnologias e processos de desenvolvimento da Positive Technologies, estou envolvido em automação e implemento as idéias do DevOps. Hoje vou lhe contar como entrei na profissão, como em nosso departamento vemos a carreira de um engenheiro de DevOps, o que é um mapa de competências e como ajuda a garantir o crescimento dos funcionários.aviso Legal
Este artigo não é uma tentativa de descrever a carreira ideal de um engenheiro de DevOps. Nosso objetivo é compartilhar experiências e contar como elas funcionam conosco. Existem empresas especializadas ( express 42 , flant ) e comunidades ( devops deflope ) que contribuem significativamente para o desenvolvimento das idéias de DevOps na Rússia e selecionamos uma pilha de tecnologias e técnicas que são adequadas para nós.Sobre como desenvolvemos as idéias de DevOps em nosso departamento e na empresa, você pode ler em Habré:E agora vamos lá!Por que precisamos do DevOps
Cada empresa tem suas próprias especificidades do departamento de automação. Como regra, as tarefas difíceis ou caras demais para serem executadas no nível de vários departamentos separados são transferidas para um grupo centralizado ou departamento de automação. Em nossa empresa, o objetivo global da implementação das idéias do DevOps é garantir uma redução consistente no custo de produção e suporte ao produto em termos quantitativos (horas-homem ou horas-máquina, CPU, RAM).Com base nesse objetivo, destaca-se a função do departamento de automação no nível de toda a empresa - para minimizar o custo de executar tarefas seriais típicas em todas as etapas da produção.Como funciona
As responsabilidades funcionais dos departamentos de automação também são altamente dependentes das especificidades de uma empresa em particular. Nossa empresa é desenvolvedora e fornecedora de soluções de segurança da informação, e o departamento de automação é responsável pelo transportador de produção - desde a montagem de componentes individuais de produtos até o envio para teste e entrega de atualizações na infraestrutura do cliente. Ajudamos a automatizar os principais processos de desenvolvimento em equipe e garantimos o desempenho de nossos sistemas (integração contínua e entrega contínua (CI / CD)).Nosso trabalho está dividido em várias áreas funcionais. A direção da integração contínua oferece suporte a montagem e teste de pipelines para desenvolvedores e testadores. A direção da infraestrutura está envolvida na operação e otimização do uso de todos os recursos "de ferro" do departamento, bem como na automação da implantação de máquinas virtuais e seu ambiente (infraestrutura como código). A direção do monitoramento fornece controle da disponibilidade diária de serviços. Também fornecemos monitoramento como serviço para desenvolvedores (monitoramento como serviço).A direção do fluxo de trabalho fornece às equipes ferramentas para gerenciar processos de desenvolvimento e teste, analisando o status do código e obtendo análises do projeto. E, finalmente, o webdev fornece lançamentos de publicação em servidores de atualização corporativos (GUS e FLUS), além de produtos de licenciamento usando o serviço License Lab.Para dar suporte ao pipeline de produção, configuramos e mantemos muitos serviços de suporte diferentes para desenvolvedores. Histórias sobre alguns deles podem ser ouvidas em nossas antigas mitaps: Op! DevOps! 2016 e Op! DevOps! 2017 . Também desenvolvemos ferramentas internas de automação, incluindo DevOpsHQ .
A experiência de nossos engenheiros
Os funcionários do nosso departamento de automação (por simplicidade, informalmente chamado de departamento de DevOps) têm um histórico completamente diferente: existem ex-testadores, programadores, engenheiros e administradores de TI. Sou professora de matemática e ciências da computação. Como se viu, graças à diversidade de experiências, fomos capazes de lidar com as tarefas de todas as nossas áreas.Não há um único engenheiro em nosso departamento que possa resolver sozinho todos os problemas em todas as áreas. Mas juntos nós, como unidade administrativa, somos assim SRE(não apenas um site, um engenheiro de confiabilidade de serviços, já que oferecemos suporte a desenvolvedores), que os especialistas em RH na pessoa de um engenheiro procuram sem êxito. Acreditamos que uma grande variedade de tarefas de produtos da empresa possa ser resolvida apenas como parte de uma equipe de diversos engenheiros.Temos muitos casos técnicos para implementar a automação. Mas o principal é explicar às pessoas por que elas precisam dessa automação. A maneira mais fácil é quando a tarefa técnica vem dos negócios, ou seja, quando as pessoas que trazem dinheiro para a empresa têm um entendimento claro: o que, como e quando fazer ou otimizar. Sugiro que você analise nossos casos de automação: " Experiência pessoal: como é o sistema de integração contínua ".Sobre uma carreira em nosso departamento DevOps
Eu gostaria de dizer que tudo estava pronto e planejado com antecedência, mas não é assim. A princípio, não tínhamos nada em nossos planos de crescimento e desenvolvimento. Em 2014, quando me mudei para o departamento de tecnologia e processos de desenvolvimento, o desenvolvimento de produtos vivia com o espírito de uma startup: tudo precisa ser feito aqui e agora, os planos de longo prazo não foram aceitos, havia muito “legado”. Havia quatro engenheiros na época e tínhamos muitas tarefas técnicas: precisávamos urgentemente fazer o CI, escalar o pipeline de montagem, antes disso, é claro, criar esse pipeline e também criar interação com nossos clientes internos - programadores dos departamentos de desenvolvimento.No entanto, com o tempo, os processos melhoraram, o departamento cresceu. Junto com ele, havia uma crescente compreensão do que nossos engenheiros queriam saber: quais são as perspectivas de desenvolvimento deles como especialistas, o que o departamento pode oferecer para novos engenheiros? A primeira coisa que logicamente se seguiu disso foi que precisaríamos de um gráfico de crescimento para as posições e categorias de engenheiros. Como diz o ditado: Quando a sociedade não tem diferenciação de cores nas calças, então não há propósito! E quando não há objetivo ...Tornamos tudo o mais simples possível. A estrutura organizacional interna de nosso departamento consiste em três posições de liderança (chefe de departamento, vice-líder e líderes de grupo) e quatro posições executivas (engenheiros de software júnior, regular, sênior e principal), que por sua vez são divididos em três categorias cada. O departamento de recursos humanos geralmente usa um cargo semelhante, mas sem divisão em categorias. Para o nosso departamento, as categorias ajudaram a garantir um crescimento mais suave e gradual dos funcionários, à medida que suas áreas de responsabilidade e carga de trabalho aumentavam.
Para cada categoria, desenvolvemos documentos com descrições de cargos, onde as funções e funções dos funcionários foram prescritas e também as áreas de responsabilidade dos funcionários pelos serviços e áreas de trabalho.Mas como nós, além da engenharia, também gostamos de programar, e nenhum de nós gosta de ler documentos chatos, aqui também simplificamos um pouco a nossa vida. Não escrevemos cada instrução no Word, mas na forma de texto sem formatação formatado com uma linguagem de marcação Markdown especial . Ao mesmo tempo, sua legibilidade por uma pessoa em qualquer editor não é perdida. Depois disso, salvamos esses textos em nosso repositório GitLab. O próprio GitLab pode exibir muito bem vários formatos de documentos, incluindo os desenhos do Markdown, para que não possam ser distinguidos do Word. E o cliente Git padrão tem muitos recursos adicionais, por exemplo, pode mostrar diferenças (diferença) entre dois documentos.Isso simplifica bastante a vida de um engenheiro que deseja descobrir quais requisitos formais ele precisa seguir para avançar para a próxima etapa (categoria) de crescimento pessoal em nosso departamento. Para descobrir a diferença entre os requisitos formais das duas descrições de tarefas, é necessário executar algumas etapas simples: faça o download do repositório com descrições de tarefas em nosso GitLab, encontre documentos, execute o comando Git no console para exibir uma comparação dos dois arquivos. Por exemplo, você pode ver a diferença entre um engenheiro sênior da 2ª e da 1ª categorias, da seguinte maneira:git --no-pager diff --no-index
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md
No console, ao qual todos os engenheiros de software estão acostumados, o sinal de menos e a cor vermelha se destacam pelos requisitos que foram alterados ou foram excluídos, e as linhas adicionadas se destacam com um sinal de adição e cor verde: cada linha é mais um novo requisito.Sim, somos um pouco maníacos técnicos, mas depois nos pareceu uma ótima solução:
Mapa de competências de engenheiro do DevOps
À medida que nosso departamento se desenvolvia e o número de transportadores de produtos suportados por nós aumentava, percebemos que, para cada uma das áreas de trabalho em que estamos envolvidos, não será possível descrever uma função única e encontrar um engenheiro adequado no mercado. Temos nossas próprias especificidades de trabalho e, por exemplo, não precisamos de um desenvolvedor de software programador mega qualificado para resolver problemas de IC, mas, no entanto, um engenheiro de CI deve ser capaz de programar pequenos módulos e scripts em Python em um nível aceitável. Da mesma forma, não precisamos de um administrador Linux mega qualificado, mas precisamos de uma pessoa com conhecimento suficiente do sistema operacional Debian ou Ubuntu para que ele possa instalar os agentes de construção do GitLab CI e, melhor ainda, automatizar esses trabalhos por meio do SaltStack, Ansible ou outras ferramentas.Então, o que um engenheiro de DevOps que trabalha em nosso departamento pode fazer? Para fazer isso, primeiro você precisa determinar quais são os conhecimentos, habilidades e habilidades (abreviado ZUN ) no sentido geral.- O conhecimento são as principais leis da área, permitindo que uma pessoa resolva problemas específicos de produção, científicos e outros, isto é, fatos, conceitos, julgamentos, imagens, relacionamentos, estimativas, regras, algoritmos, heurísticas e estratégias de tomada de decisão nessa área. O conhecimento também é um elemento de informação conectado entre si e com o mundo exterior.
- Habilidades - são entendidas como dominadas por uma pessoa como executar uma ação, fornecida com um determinado corpo de conhecimento. A capacidade é expressa na capacidade de aplicar conscientemente o conhecimento na prática.
- — , . , , , , .
Se definirmos o ZUN mais especificamente em relação aos produtos desenvolvidos na empresa, obteremos uma lista geral de competências. Sem dominar essas competências, o engenheiro não poderá trabalhar qualitativamente em nosso departamento. A lista acabou sendo muito longa, porque leva em conta as especificidades do trabalho imediatamente em todas as áreas, tecnologias e produtos.Assim, chegamos à necessidade de descrever e classificar todos os nossos requisitos para um engenheiro de forma tabular e temos um " Mapa de Competências do DevOps Engineers 1.0 ". É assim: A tabela está dividida em quatro seções grandes:
- Descrição das competências gerais dos funcionários de nosso departamento de DevOps, necessárias para a solução bem-sucedida das tarefas diárias.
- Conhecimento é o conhecimento específico e orientado ao produto dos engenheiros do DevOps.
- — ; .
- — ; , .
Nas células da tabela, são indicadas avaliações qualitativas: em que nível um engenheiro deve ter aproximadamente uma ou outra competência. Infelizmente, não consigo imaginar a versão completa da tabela aqui, mas isso não é necessário, pois cada empresa e cada departamento deve criar sua própria tabela semelhante, levando em consideração as especificidades do trabalho.Em 2018, meus colegas e eu desenvolvemos e criamos o chamado mapa tecnológico do processo de produção (leia o artigo sobre a Habr “ Gestão do caos: colocamos as coisas em ordem com a ajuda do mapa tecnológico ”). Graças a ela, chegamos perto de formar um vetor de crescimento e desenvolvimento das competências dos engenheiros do DevOps, dependendo do produto, das tecnologias usadas nele e das etapas do transportador do produto.
Esse mapa descreve todas as etapas e etapas que compõem o transportador tecnológico para a produção de nossos produtos. O principal, do ponto de vista do produto, é entender quantos engenheiros, quais qualificações e com quais competências precisamos para garantir a operação contínua deste transportador. Melhor ainda, planeje e proteja as pessoas para que, apesar do suporte de serviços críticos, elas possam, por exemplo, sair com calma, sabendo que existe alguém no departamento que possui competências cruzadas e que pode substituí-las.Em conjunto, isso deve nos levar ao "Mapa de Competências do DevOps Engineers 2.0", que descreverá claramente o ZUN, dependendo do produto e das competências necessárias para o trabalho de automação neste produto. Ou seja, alguma ligação das etapas no mapa tecnológico ao mapa das competências dos engenheiros deve aparecer. No próximo artigo, tentarei contar o que aconteceu.PS O artigo foi escrito com base na história da reunião de janeiro, para a qual colegas da Hays nos convidaram a trocar experiências (você pode ver a apresentação e o texto ).Autor : Timur Gilmullin- deputado. Chefe de Processos de Tecnologia e Desenvolvimento (DevOps), Positive Technologies.