As equipes de desenvolvimento podem ser fracamente acopladas e trabalhar em direções diferentes, sem saber e sem querer usar o DevOps. No artigo de hoje, falaremos sobre como as práticas de DevOps podem ser distorcidas e transformadas para que possam ser implementadas em empresas com regulamentos, políticas e hábitos das pessoas estabelecidos há muito tempo.



O material é baseado em um relatório de diálogo de Sergey Berdnikov (Golden Crown) e Artem Kalichkin (CFT) da conferência DevOops 2017 de outubro. Sob o recorte - transcrição de vídeo e texto do relatório.




Sergey: Eu sou o chefe do departamento de operações da nossa empresa. Artem e eu começamos uma pequena revolução-evolução. Tudo começou com a revolução, agora passou para o estágio de evolução.



Artem: A empresa atua no mercado financeiro desde 1992. O trabalho consiste em duas partes principais. A primeira parte é desenvolvimento de software, Core Banking, contabilidade bancária e assim por diante. Aqui, atuamos como fornecedor: desenvolvemos e vendemos uma caixa para você, e você a implantou e operou.

A segunda parte é o processamento de serviços. Aqui prestamos serviços diretamente a indivíduos ou por meio de nossos parceiros. São grandes redes de negociação, bancos e outros participantes no mercado de serviços financeiros. Aqui elaboramos o ciclo completo, desde a ideia até o desenvolvimento, implementação e operação adicional.

Trabalhamos com Sergey na parte de processamento de nossa empresa. Sobre como chegamos à história com o DevOps nesse processamento, contaremos.

O que foi

Sergey: Nosso legado era completamente bancário. A empresa inicialmente fabricou produtos bancários, respectivamente, tudo era familiar: toda a infraestrutura do SPARC apenas, seus próprios data centers, todo o núcleo foi escrito em Oracle. Código PL / SQL, muitas coisas - não é fácil de escalar.

Escalamos apenas na vertical: compramos um pedaço poderoso de ferro, o usamos até ficar obsoleto, substituímos por um novo e o antigo foi levado para a montagem.

Também escreveu muito código em Java. Reservamos através de uma reserva quente: existe um data center e toda a estrutura copiada - switches, servidores, tudo em um, parafuso a parafuso.



Aqui você pode ver como toda a estrutura parecia do ponto de vista dos processos. Havia diretórios técnicos separados Dev e Firewalls com fogo. Em seguida foi a TI centralizada, envolvida na remoção, implantação e assim por diante. Ou seja, os Devs escreveram uma grande instrução e as Operações de TI foram divididas em três divisões:

• Administradores aplicados que estavam envolvidos em uma implantação. Eles não tinham uma raiz, havia usuários nas máquinas, eles podiam executar instruções - isso é chamado de código de macaco.
• Administradores Unix que podiam e sabiam como configurar, adicionar hardware e assim por diante.
• Havia especialistas em bancos de dados individuais. E como os bancos de dados são o principal objetivo para nós, a essência de nossa existência há muito tempo, muitos processos ocorreram lá.

Artem: O DevOps ainda não está aqui, trabalhamos de acordo com os regulamentos, com os quais Sergey não estava feliz.

Sergey: Entrei para a equipe de administradores aplicados e lembro quais eram os "bons tempos". Poderíamos fazer uma solicitação por três semanas. Um aplicativo entra, eles descobrem algum tipo de erro e o cancelam, acreditando que os tolos não podem escrever aplicativos. E o conhecimento necessário para a escrita correta do aplicativo estava comigo.

Então, as pessoas vieram correndo em um dia: "E o que escrevemos incorretamente?" Expliquei que em algum lugar eles não colocaram um sinal de mais ou menos, eles esqueceram uma vírgula. Eles escrevem um aplicativo, eu dou algum tipo de conhecimento sobre como trabalhar no Oracle e o envio mais adiante para o DBA, onde estão as pessoas especialmente treinadas que sabem como atender a esses aplicativos.

E eles também trabalham comigo, dizem: "Por que você não indicou o principal indicador aqui, não escreveu ponto e vírgula?" A aplicação é cancelada, o ciclo recomeça. Agora, que pena, mas o que fazer, antes de trabalhar dessa maneira.

Artem: Então começamos a mudar. Havia realmente muitas aplicações. Quando Sergey se juntou à nossa equipe, ele foi o resultado de uma pequena evolução e transformação. Eu era o autor de um número razoavelmente grande de regulamentos para vários tipos de aplicativos, porque tinha que sobreviver de alguma forma. Em geral, toda a nossa transformação ocorreu não por hype ou moda, mas por causa da necessidade de resolver problemas específicos.

Por exemplo, alterações na configuração levam ao fato de que meu combate foi interrompido e não funcionou corretamente. Descobri isso em um dia ou à noite: aconteceu às seis da noite que rolaram alguma coisa e até as três da manhã tudo isso funcionou incorretamente.

Havia instalações da versão anteriores às quais ninguém iria e não discutia o que fazer se algo desse errado. As famosas instruções de instalação de várias páginas foram transmitidas a todos, literalmente, meia hora antes do início do trabalho em operação. Era necessário resolver alguma coisa e, naquele momento, encontramos uma solução - implementação adaptativa dos processos ITIL.

Começamos a verificar se tudo rolou corretamente após a rolagem para o combate, se o serviço e os principais indicadores-chave estão funcionando normalmente. Começamos a namorar antes de instalar as versões. E então, de fato, foi o começo do DevOps, quando a equipe de desenvolvimento, que transmite o kit de distribuição, começou a conhecer pelo menos a equipe de operações, discutindo o que aconteceria no trabalho noturno.

Sergey: E havia algo a discutir: tínhamos quatro páginas de instruções de instalação - executar um comando, executar um plano. Era quase impossível escrever sem erros. Juramos constantemente entre o desenvolvimento que escrevemos incorretamente, o lemos e coisas assim. As reuniões às vezes se transformavam em inferno.

Artem: Tentamos avançar com os aplicativos para o Confluence, pois é inconveniente transmitir no Word - foi possível formar algo errado. No Confluence, eles sempre planejavam fazer upload da versão atual com todas as alterações.

Inserimos um código para entrar em combate. Confluence mastigou a meta-marcação, emitiu outra coisa incorreta, o administrador pegou o código, que se transformou em macarrão e começou a trabalhar com ele - foi um desastre.

Percebemos que, por mais perverso que tenha sido com as instruções da página, tudo isso se transformou em um completo absurdo, não importando como foi enquadrado.

Havia pré-requisitos importantes para o tempo de inatividade prolongado à noite, o que levava a uma decolagem ruim após a instalação, a batentes e a um grande número de conflitos entre desenvolvimento e operação.

• Muitos erros humanos na transmissão de mudanças;
• Busca constante pelos culpados;
• A taxa de remoção de novos módulos por até 3 semanas;
• Pontos únicos de falha (somente escala vertical), falta de balanceamento;
• Tempo de inatividade planejado durante as atualizações por 2 horas.

Fundo de Transformação

Sergey: Houve muitas mudanças, nós constantemente erramos. Toda semana nos reuníamos, amaldiçoamos e nos acalmamos. Esse processo foi repetido para sempre, e eles procuraram o culpado: "Todos esses desenvolvedores escrevem código curvo, mesmo o módulo Java não pode ser transmitido".

Artem: Mas os desenvolvedores pensaram que isso era algo elementar: ocorreu um erro nos logs - resolva, pesquise no Google e entenda o que precisa ser corrigido nas configurações.

Sergey: Eles também lançaram novos produtos por muito tempo. Isso é estruturalmente relacionado: eles criaram uma solicitação para nós, tivemos que criar uma solicitação para criar um usuário no servidor e depois criar um esquema. Então o futebol começou com as aplicações. Os desenvolvedores emitiram módulos, mas não podemos usá-los, temos tudo de acordo com os regulamentos.

Além disso, estabelecemos um período muito longo. As instruções são enormes, enquanto você lê, enquanto lê, o carretel levou cerca de duas horas. As ações em si não foram concluídas em um segundo.

Artem: Também houve ações de rotina, por exemplo, 30 módulos Java. Ao todo, há uma configuração, em cada configuração você precisa entrar e fazer alterações. Primeiro, você pode enlouquecer ao fazer a mesma mudança: você se odeia e ao resto da humanidade. Em segundo lugar, a probabilidade de cometer um erro na 25ª configuração se torna extremamente alta.

Sergey: Lembro-me de como recebi uma oferta para escalar horizontalmente. E temos 150 módulos com configurações diferentes: se o erro estiver em uma versão da configuração, eles me colocarão em uma segunda e eu cometerei um erro nela. Afinal, não somos robôs.

Artem: O tempo de inatividade programado de 2 horas de atualização é um dos fatores críticos do motivo pelo qual começamos a procurar uma solução, como fugir dela.

O fato é que prestamos serviços financeiros, serviços de processamento. Trabalhamos em países estrangeiros. Naquele momento, eles já trabalhavam em 11 fusos horários; em 2013, tínhamos apenas uma hora de janelas, quando o serviço era mínimo, o número de chamadas de clientes era minimizado, a calma chegava e algo podia ser feito.

Condicionalmente, poderíamos realizar trabalhos de uma hora a duas à noite. Duas horas é muito mais do que esta janela. Estávamos nos aproximando de um desastre, se não fosse pela transformação, porque agora não temos janelas fisicamente.

A resposta para todos esses problemas eu tive uma ideia, uma tentativa de descobrir o que é DevOps.

Naquela época, nosso colega veio com o HighLoad, eu estava ocupado com a implementação do CMBD, porque precisava para que as configurações não quebrassem e eu pudesse pelo menos gerenciar alguma coisa. Ele ouviu o relatório de Sasha Titov, que falou sobre um chef. Parece ser gerenciamento de configuração também

Em 2013, li tudo sobre isso, decidi que não precisava de lixo. Eu preciso controlar, e eles forçam o código a escrever lá. No entanto, a situação não mudou, os problemas se acumularam e eu me forcei a ficar em casa e começar a resolver as coisas. Eu pensei que havia algo nisso, algum tipo de salvação.

E então descobri os postulados e valores de que deveríamos ter o mesmo ambiente, o mesmo script de implementação e atualização, que deveríamos verificar esses cenários, começando com o ambiente de teste.

Houve uma oportunidade de minimizar as instruções e ações manuais e automatizar tudo o máximo possível, não apenas com scripts bash díspares, nos quais outro administrador quebraria sua perna mais tarde.

Foi quando eu tive essa ideia, com a primeira declaração do que eu quero receber. Este é o documento de 2013, o primeiro criado na empresa sobre o DevOps.

Sergey: Aqui está uma idéia-chave: reduzir a velocidade de remoção de novos módulos, reduzir o número de erros durante a remoção para a batalha. Ou seja, havia objetivos específicos que queríamos alcançar no primeiro estágio do lançamento de novos lançamentos.



Havia muitos argumentos contra isso. Por exemplo, o medo de que a automação vá quebrar tudo: funciona de maneira incompreensível, é assustador executar o código de outra pessoa, é um ótimo serviço, as pessoas recebem dinheiro através de nós. Não é serio.

O próximo a se juntar aos guardas. Eles nos atravessaram por completo: algum tipo de estágio idêntico! E eles têm uma imagem perfeita do mundo: na unidade flash, transfira as versões, assinaremos com uma chave PGP e tudo ficará bem - o serviço perfeito. Trabalhamos com eles por tanto tempo para chegar ao fim, graças às atividades do projeto que fizemos alguma coisa.

Artem: Aqui procedemos dos valores: é aqui que perdemos dinheiro, este simples é inaceitável.

Os caras e eu criamos uma maneira de minimizar essas perdas. Você tem uma opção melhor? Se não, fique quieto; se estiver, critique e ofereça. Nada a oferecer? Então tentamos.

Houve um processo de persuasão e forçamento: sugerimos o uso de nossas idéias em um número limitado de sistemas.

Sergey: Nos pediram para escrever todos os riscos, como o lançaríamos. Era necessário coordenar com pessoas que poderiam perder dinheiro. Além disso, os programadores disseram: "Nós escrevemos algum tipo de código, costumávamos transmitir zip normalmente, escrevemos instruções e algum código adicional para escrever para fins de remoção?!"

Artem: “Escrevo códigos de aplicativos de lógica de negócios, uso estruturas para minimizar qualquer parte desnecessária do código. E você pede mais código para escrever. Tirar e tirar, no final ”- esses diálogos estavam no início. No entanto, tudo isso gradualmente trabalhou com demonstrações e crenças.



Sergey: Nas primeiras iterações, tomamos muitas decisões importantes em termos da estrutura da nossa empresa e em termos de tecnologia. Primeiro, implementamos o gerenciamento de configuração. Isso nos salvou o problema de remover a configuração errada com uma instrução de 10 páginas A4.

Em seguida, as operações começaram a afundar e os administradores de aplicativos foram para a diretoria técnica com os desenvolvedores. Dava uma sensação de comando, uma sensação de cotovelo. Começamos a entender que estávamos produzindo um produto e não preenchendo aplicativos incompreensíveis com o desejo de rejeitá-los - havia objetivos específicos.

O trabalho em equipe se reúne quando você se senta ao lado das pessoas, quando você vê como elas funcionam, quando elas vêem como nós trabalhamos. Chegamos a ter um diálogo entre as equipes: esta é a primeira centelha de DevOps real. Não havia tecnologia, nenhuma tecnologia nova. Do ponto de vista da tecnologia, pensávamos que nada criaria raízes, trabalhamos de maneira diferente em outro mundo.

A primeira idéia é escrever nós mesmos o Gerenciamento de Configuração, existem muitos desenvolvedores. Então nos lembramos de tudo o que escrevemos e recusamos - todos nós sentimos.

Artem: Eu vou corrigir meu colega. Sergey está errado: tudo o que escrevemos funcionou perfeitamente em nosso campo aplicado, no qual somos fortes. E quando eles tentaram escrever algumas de suas aranhas para criar automaticamente o CMDB ou algum tipo de sistema de monitoramento auto-escrito para controlar a lógica de negócios - sim, aqui vem um sistema de outra classe.

Nesse estágio, os administradores de aplicativos passaram do departamento de TI para o departamento técnico. Como Sergey disse, eles começaram a sentir todo o valor comercial, fundamental devido a coisas mercantis.

Tivemos a oportunidade de pagar a eles bônus por conquistas, foi bastante motivador. Quando eles começaram o diálogo, a remoção de módulos foi reduzida de três semanas para uma semana ou mais, e houve algum progresso mesmo sem nenhuma automação profunda.



Sergey: Nesse momento, se não entendíamos algo com o aplicativo, pedíamos ao desenvolvedor que surgisse: "Vamos decidir juntos e escrever como o aplicativo deve soar".

Artem: E nessa estrutura de comando condicional, começamos a avançar para a tecnologia.

Sergey: Agora vamos dizer como escolhemos o sistema. Foi interessante o suficiente. Primeiro de tudo, tentamos o Chef, por uma razão simples: conhecíamos um guru que conhece o Chef. Depois, tentamos o Puppet, porque na época a Oracle anunciou o suporte ao Puppet.

O Ansible também tentou, mas ambas as equipes não gostaram como um sistema. Havia também problemas de segurança: o Ansible em 2013 era muito diferente do atual.

Lançamos dois projetos diferentes com a mesma funcionalidade em paralelo. E tudo funcionou bem, havia uma sensação de que algo estava errado aqui e deveria ser deixado em paz. Como escolhemos?

Artem: Os programadores escreveram no Chef, os administradores escreveram no Puppet. A ideia era o que tentaríamos, depois comparar onde é melhor e escolher. Mas quando montamos, quando o tempo acabou passando, a dualidade começou a criar problemas, porque o volume de código está crescendo, continua a crescer e todos gostam de tudo, os desenvolvedores escrevem e automatizam.

Reuni todos e perguntei no que escreveríamos. Os programadores disseram: "Nós realmente gostamos do Chef". E administradores: "E para nós no Puppet!". Era uma lata completa. Eu comparei e entendi que no ambiente atual e nos parâmetros atuais não existe uma maneira objetiva de escolher este ou aquele produto.

Como resultado, fiz, como eles gostam de dizer em nosso país, eleições com um resultado previsível. Algum tipo de voto "fechado" entre os participantes. Mas não houve falsificação, houve um efeito condicional no cérebro, como resultado do qual Puppet foi escolhido. Decidi acalmar os desenvolvedores ofendidos mais rapidamente do que os administradores ofendidos. Simplesmente não havia outro critério de seleção.

Sergey: Naquele momento, pensamos por muito tempo em como colocar o binarismo. No slide, você pode ver uma foto de nossa diretoria e reunião. Decidimos que você precisa usar algum tipo de sistema de embalagem, e não sua bicicleta. Mais uma vez ganhou a mente.

De fato, escolhemos não o RPM, mas o IPS - o gerenciador de pacotes Solaris. Nós nos importamos da 11ª versão para os dez primeiros, que ficaram, e começamos a usá-lo. Recusar-se de muletas e zíperes escritos à mão naquele momento foi a decisão mais correta.

Artem: É por isso que ainda era importante: na receita, o resultado aparece na forma de uma alteração no número da versão, se estende cada vez mais longe do repositório e se torna necessário.

Quando viemos treinar o DevOps, Chef, todas essas coisas e pensamos: "Agora eles nos dirão como transferir binários", mas não nos disseram nada sobre isso. As respostas são geralmente: "Todo mundo decide à sua maneira e sai o quanto pode". Portanto, eles perceberam que a resposta da indústria a isso é "42", a partir do "Guia do Mochileiro das Galáxias", a resposta para a principal questão do universo.

Sergey: Também tivemos um longo debate sobre como criar um CI / CD, o que é. Como o Configuration Management - um utilitário, eles pegaram e entregaram. E aqui estão muitas opções e escolhas, eles argumentaram por um longo tempo, os desenvolvedores criaram seu próprio sistema e, em operação, criamos o nosso para a remoção.

Naquele momento, percebemos que não havia solução perfeita. Basta pegar tudo o que ganhamos e suportar. Os desenvolvedores tinham seu próprio sistema de montagem, nós mesmos fizemos nossa entrega. Não havia uma escolha perfeita e ainda trabalha com equipes diferentes de maneiras diferentes. Não há ideal.

Também temos uma pilha grande, a maior parte do nosso código está embutida no banco de dados: todo o processamento financeiro, no qual, infelizmente, o paradigma é "quanto mais próximo dos dados, mais rápido ele funciona". A Oracle vende, concorda Fowler. As transações financeiras estão suspensas no PS / SQL; não encontramos nenhum produto de código-fonte aberto que ajudasse a resolver nosso problema com versões e entrega. Talvez ele estivesse, mas começamos a escrever nosso próprio instrumento.

Artem: De fato, temos um grande problema, porque, como mencionado no slide inicial, a produção é um grande servidor vertical. Consequentemente, elevar o mesmo servidor vertical grande para o Stage é muito caro e muito difícil. Isso não é tão ruim.

O fato é que precisamos criar um ambiente com desempenho aproximadamente semelhante e preenchê-lo com dados semelhantes em volume e, não menos importante, em cardinalidade, para que nossos testes de palco sejam aprovados corretamente.

Aqui foram decisões muito difíceis. Primeiro de tudo, o que fizemos em termos de escala - percebemos que não podíamos fornecer os mesmos veículos verticais no Palco e na batalha.Porém, no momento X, podemos corrigir os indicadores de referência das solicitações de desempenho do sistema no ambiente Stage e compará-los quando novos pacotes forem lançados. Se eles começam a mudar de forma anormal, significa que algo flutuou em nós e que algo não está funcionando errado. Este é um problema.

Em seguida, descobrimos um problema com a transferência de dados da batalha para o palco para preenchê-los com a mesma quantidade de dados. É impossível que nenhuma das pessoas que não tem acesso aos dados do cliente de acordo com os documentos tenha acesso a eles.

Não temos o direito de despejar dados pessoais e segredos bancários de clientes no Stage. Para transferir esses dados, escrevi scripts de ofuscação de dados para que não sejam recuperáveis ​​nem comparáveis ​​aos reais. Ao mesmo tempo, é importante que seja impossível substituir todos os nomes por aaa bbb, porque estamos perdendo a cardinalidade dos dados e todas as nossas verificações no Stage mostram informações incorretas.

Portanto, também escrevemos esse script com o objetivo de gerar alguma cardinalidade condicionalmente aleatória desses dados de texto, para que nossos pedidos mostrassem uma imagem adequada comparável a uma batalha e pudéssemos entender as mudanças.

Estamos nos afastando de um estado absoluto de desempenho, estamos observando mudanças. A situação não piorou em relação à versão anterior, que, em nossa opinião, não foi ruim no desempenho.



Esta é a segunda iteração. Provavelmente a frase-chave aqui é que o projeto terminou aqui. Não havia projeto do DevOps. Aqui estava originalmente um cliente interno - eu. Obtive meu resultado: a instrução foi reduzida, os erros durante o lançamento da versão foram reduzidos, a configuração de combate começou a mudar, gerenciada através do Puppet, tornou-se controlada, compreensível. O que eu queria era o que eu conseguia.

Sergey: Houve pequenas alterações em sua inscrição. Mais uma vez, as responsabilidades fluíram da TI centralizada para a diretoria técnica.

Tornou-se um OPS completo com uma raiz. Isso realmente ajudou a cumprir as tarefas em termos de remoção de novos módulos. Começamos a acelerar os módulos, após três semanas a execução em apenas três dias parecia ideal para nós. O resultado foi tangível: houve um impulso, a equipe começou a gerar idéias sobre como e como melhorar.



O que fizemos do ponto de vista de unidades relacionadas: temos uma equipe de mais de 200 pessoas, 150 desenvolvedores, 6 OPS. Havia muitas escoltas, seguranças. Primeiro - chegou-se à conclusão de que a melhor aplicação ideal que não precisa ser feita. Eles começaram a ir para isso e tentar: se uma pessoa tem a oportunidade de fazer algo sem criar um aplicativo - todos estão bem. E isso é feito perfeitamente rápido.

Artyom:Aqui está um exemplo, fazemos uma oferta através do git. O próprio gerente entra e faz uma oferta para a batalha.

Sergey: Encontramos ferramentas como o Gitlab, gostamos que uma pessoa possa trabalhar com uma interface gráfica. Existe um botão "download", o usuário pode nem entender o que o commit realmente faz.

Ao mesmo tempo, escrevemos scripts para verificar o conteúdo, por exemplo, que pdf é pdf, verificando o tamanho do arquivo e outra lógica de acordo com as regras emitidas pela equipe de segurança. As pessoas tiveram a oportunidade de atualizar esses documentos sem criar aplicativos. A carga nas operações diminuiu.

Outra dificuldade foi como calcular esses momentos. Na rotina, não está claro como procurar áreas problemáticas. Por isso, criamos nossa própria balança e a chamamos de "Jackals".

Nós fomos inspirados pela imagem antiga. Consideramos que atribuímos a cada aplicativo executado o número de chacais, como é chato e chato e não queremos fazê-lo. No final do mês, eles consideraram quais aplicativos os chacais obtiveram mais pontuação.

Eles se sentaram como uma unidade inteira e pensaram em como se livrar dessa desgraça. Como não era necessário criar aplicativos para isso, foi legal e levou as pessoas.

O próximo estágio, onde encontramos os métodos de automação, são os bots. Nós dominamos a API do Telegram, começamos a cortar bots para todos em uma fila, especialmente para nós mesmos. Concluímos os últimos gatilhos.



Os negócios gostaram: há situações em que algo está mentindo, todo mundo começa a ligar e perguntar o que está acontecendo. E para que uma pessoa possa atender o telefone, selecione o comando "incidentes" e leia os últimos incidentes. As pessoas começaram a conduzir incidentes com mais detalhes, para que ninguém ligasse ou perguntasse sobre eles.

Então começamos a escrever recursos adicionais para obter informações que costumavam ser consultas no Jira. A empresa deseja saber se a transferência foi concluída: insere um número e obtém o resultado. Isso também facilitou muito a vida em termos de aplicações.

Artyom:Ao mesmo tempo, fizemos outra transformação organizacional, mas já local, dentro do departamento de Sergey. Então, ficamos muito infectados com a idéia de um engenheiro de plantão e, graças a Sergey, conseguimos criar esse esquema no departamento. Há um engenheiro sentado em incidentes, há um engenheiro sentado em aplicações, todo o resto destrói os chacais, está envolvido em seu tiroteio.

Trabalhar com DEV

Sergey: O que a unidade começou a fazer: surgiram rearranjos, as pessoas estavam envolvidas não apenas em chacais, mas também em outros assuntos. Antes de tudo, tivemos um diálogo com o desenvolvimento. Dissemos às novas equipes o que é DevOps, como prepará-lo corretamente, ensinou CM.

Percorremos um longo caminho desde quando nós mesmos escrevemos as receitas, então eles aprenderam a editá-las e depois escrever por conta própria. Também falamos sobre CI, ajudamos a configurar o pipeline e coletamos pacotes. Ajudamos a criar um ambiente de desenvolvimento seguro.

Artem: Do ponto de vista da CI, tudo isso é muito importante. Paralelamente, atuo como produtora de produtos, lidera projetos e lidera equipes de desenvolvimento. E aqui está um caso muito interessante.

Em equipes pequenas, combinamos as funções de operação, ou seja, Stage e Prod na mesma unidade. Nesses pequenos projetos, pequenos produtos, equipes e infraestruturas, isso se mostrou muito conveniente. Você vê direito como vai rolar a batalha.

Sergey: Quando um engenheiro de combate cria um ambiente de teste, ele faz um contra um, sabendo que ela o procurará mais tarde e ele sofrerá com isso. Este é um fator psicológico importante que não pode ser gratuito, é melhor fazer tudo de uma vez e normalmente.



O que aconteceu? Aqui, muitos dizem que não há departamento de DevOps, acreditamos que temos um departamento de DevOps. Quais são as principais tarefas do departamento?

Ele anda, promove, fala sobre DevOps. Todo mundo entende o que é e como cozinhá-lo. Eles informam e mostram como um novo produto com um banco de dados pode ser lançado em cinco minutos.

Nossa única limitação é a segurança, a coordenação de esquemas. Quando temos uma máquina virtual e os esquemas são acordados, tudo leva cinco minutos. Tudo rola completamente automaticamente.

Artem: Quando em agosto tive o lançamento de um novo produto em batalha, ou seja, completamente novo, lançamos de 15 a 20 lançamentos por dia, sem conflitos e tensão. Há uma sensação de valor aqui: é legal quando você se acalma silenciosamente e vai para a próxima.



Sergey:Eu vou falar sobre dor. Apoiamos o plano de recuperação de DRP do zero. E quando não havia automação, copiamos quase as configurações lá. Novos módulos foram adicionados constantemente, e o plano precisa ser constantemente atualizado. Com o advento do DevOps e da automação, o plano diminuiu: pegamos a versão atual mais recente do Git e adicionamos planos a ela.

Esse plano de implantação está se tornando honesto. Isso é suportado, entre outras coisas, pelas execuções de implantação de teste. Fazemos testes e, em combate, mudamos para a reserva. Toda a história da rotina se foi. A propósito, isso nos ajudou a mover um pouco a pilha.

Costumávamos usar o SPARC Solaris, agora o x86 aparecia por uma razão simples: hoje ninguém escreve ou testa aplicativos hipster para o Sparc. E usamos, por exemplo, o Haproxy, junto com os desenvolvedores, vimos correções de bugs no Solaris. Nos incomodou, eu não queria mais suportar. Escolhemos uma plataforma na qual todos estão testando produtos e agora estamos trabalhando nela normalmente. Isso também nos levou a acelerar todo o processo.

Artem: Isso geralmente abriu as portas para um novo mundo cheio de milagres. Porque o advento do x86 nos permitiu usar utilitários realmente relevantes e úteis para nossas tarefas. Além disso, quando tivemos essa oportunidade, mudamos simultaneamente para o cluster.

De fato, agora tudo, exceto o processamento central e nuclear, está agrupado e funciona bem conosco. Não nos preocupamos: ou não há tempo de inatividade ou leva no máximo um minuto, mesmo onde não há cluster.

O único lugar em que ele ficou e tinha pelo menos duas horas de idade foi a migração de esquemas de processamento central. Agora leva oito minutos.



Sergey: No slide, há um novo documento, um aplicativo de uma linha: mesclar no git. Já não existem essas dez folhas A4.

A implantação de novos módulos leva até três horas. Esses são alguns casos difíceis quando você precisa fazer algo no Oracle, por exemplo, obter uma máquina virtual. As compensações desapareceram. Não me lembro de alguém passando algo errado. Obviamente, existem algumas rugas, mas são todas pequenas, frívolas, corrigidas muito rapidamente.



O que nos permitiu alcançar o sucesso? Antes de tudo, não iniciamos uma revolução aqui e agora. Eu não disse: "Precisamos implementar o DevOps em três semanas". Abordamos esse processo metodicamente, agitados por um longo tempo, contamos às pessoas, pingamos em nossos cérebros, conversamos sobre os objetivos que estamos alcançando.

Artem: Lutei contra as perguntas das autoridades: "Artem, quando é o DevOps?" Ele disse que não haverá prazo, tentamos no Prod, não pergunte nada.

Sergey:Por outro lado, tudo também é muito legal. Não impusemos a todas as unidades as tecnologias que usamos. A empresa é grande, os vizinhos parecem, eles dizem: "Bem, sim, ótimo, mas vamos implantar a cada seis meses". Eles não precisam disso. Não andamos, não dizemos, que temos a única decisão certa. Em algum lugar que não queremos usar nossa pilha, montamos para eles scripts simples do bash que permitem a integração com outros comandos.

Artem: Aqui estou convencido de que o topo não pode ser forçado a implementar o DevOps. Isso não é realista para esse projeto.



Sergey: Analisamos onde perdemos a maior parte do tempo: hoje perdemos a maior parte do tempo em segurança.

Sabemos trabalhar rapidamente, implantar rapidamente, mas concordamos com um esquema de implantação - isso é algum tipo de inferno. Agora, vimos o que lembra a mesma coisa quando havia divisões completamente diferentes de Dev e Ops. Agora não temos um plano, estamos pensando em como incluir segurança em nosso processo para que eles possam analisar as alterações.

Artem: por exemplo, você pode usar Mesclar para isso, veja o que mudou na receita. O guarda de segurança também é um engenheiro.

Sergey:Muitas vezes, nossos processos formais não fornecem segurança real. Quando realizamos uma auditoria, entendemos que todos os procedimentos foram aprovados, mas ainda não recebemos o nível de segurança desejado e muito tempo e recursos foram gastos. Constantemente, encontramos alguns problemas que ocorreram devido à má integração dos processos de segurança e do CI / CD.

Do ponto de vista do OPS, ainda temos o problema de perder tempo com o IC e ajustar as receitas. Essa coisa já está começando a ganhar "chacais". Portanto, olhamos para os sistemas para apresentar estruturas para desenvolvedores, olhamos para o Docker, Kubernetes, para que possamos escrever: "Pessoal, existem ferramentas, não existem documentos grandes, você pode unificar o processo de entrega".

Queremos avançar nessa idéia, mas a segurança está novamente resistindo. Eles dizem: "Que tipo de redes virtuais você possui, como esses serviços funcionam sem um firewall?" Existem algumas contradições, mas acho que venceremos de qualquer maneira.

Artem: Eu tenho minha própria dor, gostaria de terminar. Temos um problema muito grande: somos uma empresa e não somos a única empresa, há representantes que estão na mesma situação. Estamos sob controle constante do regulador, o Banco Central vem constantemente com uma auditoria. Passamos por uma auditoria, passamos por uma auditoria aparentemente independente.

É difícil culpar o auditor, ele faz o trabalho com base em padrões que afirmam que o hardware físico deve ser uma máquina separada e não virtual. Sem recipientes.

No momento, nem um único padrão internacional mudou um pingo para novas tecnologias. Existe um buraco negro. Eles não percebem que este é um grande problema. Não posso culpar os auditores, eles realizam auditorias de acordo com os padrões. Eles não têm para onde tirar isso, mas nenhum padrão está tentando, nesse sentido, mudar, transformar em algum lugar e se mover.

Preciso descobrir como fazer uma imagem da empresa existente com essas palavras terríveis para que tudo esteja correto e honesto.

Se você está cansado de longas leituras - recomendamos ouvir o lançamento do podcast “Five Minute PHP” com nossos amigos Baruch Sadogursky e Vyacheslav Kuznetsov. Tendências DevOps, DecSecOps, vitória do Kubernetes e relatório State of DevOps 2018 da DORA.

E se você quiser relatórios mais interessantes, venha para a conferência DevOops 2018. Haverá Baruch, Glory e até John Willis ! Todos os palestrantes e o programa estão no site .

Um bom bônus: até 1º de outubro, um ingresso para o DevOops 2018 pode ser reservado com desconto .