Na conferência do ano passado,
DevOpsDays Moscow, o diretor de operações do portal Banki.ru, Andrei Nikolsky, falou sobre serviços órfãos: como identificar um órfão na infraestrutura, quais são os maus serviços órfãos, o que fazer com eles e como ser, se nada ajudar.
Abaixo do corte, está a versão em texto do relatório.
Olá colegas! Meu nome é Andrey, lidero a operação no Banki.ru.
Temos ótimos serviços, são serviços monolíticos, existem serviços em um sentido mais clássico, existem muito pequenos. Na terminologia de meu trabalhador e camponês, digo que se o serviço é simples e pequeno, então é micro, e se não é muito simples e não é pequeno, é apenas um serviço.
Profissionais de serviço
Analisarei rapidamente as vantagens dos serviços.
A primeira é a escala. Você pode fazer algo rapidamente no serviço e iniciar a produção. Você chegou ao trânsito, clonou o serviço. Você ainda tem tráfego, ainda clonou e vive com ele. Este é um bom bônus e, em princípio, quando começamos, era considerado o mais importante entre nós, por que fazemos tudo isso.
Em segundo lugar, desenvolvimento isolado, quando você tem várias equipes de desenvolvimento, vários desenvolvedores diferentes em cada equipe e cada equipe vê algum tipo de serviço.
Há uma nuance com as equipes. Os desenvolvedores são diferentes. E há, por exemplo,
pessoas-flocos de neve . Vi pela primeira vez isso com Maxim Dorofeev. Às vezes, as pessoas têm flocos de neve em algumas equipes e outras não. Isso torna os diferentes serviços usados na empresa um pouco desiguais.
Olhe para a foto: ele é um bom desenvolvedor, ele tem grandes mãos, ele pode fazer muito. O principal problema é de onde essas mãos crescem.
Os serviços possibilitam o uso de diferentes linguagens de programação mais adequadas para diferentes tarefas. Alguns serviços no Go, outros no Erlang, outros no Ruby, outros no PHP, outros no Python. Em geral, você pode se virar muito amplamente. Também há nuances aqui.
A arquitetura orientada a serviços é principalmente sobre devops. Ou seja, se você não possui automação, não há processo de implantação; se você configurar com as mãos, suas configurações podem mudar de uma instância de serviço para uma instância e você precisa ir lá para fazer alguma coisa, então está no inferno.
Por exemplo, você tem 20 serviços e precisa implantar com as mãos, 20 consoles e simultaneamente pressiona “enter”, como um ninja. Isso não é muito bom.
Se você tiver um serviço após o teste (se houver, é claro) e também precisará finalizá-lo com um arquivo para que ele funcione na produção, também tenho más notícias para você.
Se você confia nos serviços específicos da Amazon e trabalha na Rússia, há dois meses você também tinha "Tudo está pegando fogo, estou bem, tudo é legal".
Usamos Ansible para automação de implantação, Puppet para convergência, Bamboo para automação de implantação, Confluence para descrever tudo de alguma forma.
Não vou me debruçar sobre isso em detalhes, porque o relatório é mais sobre a prática de interações e não sobre implementação técnica.
Por exemplo, tivemos problemas com o Puppet no servidor que trabalha com o Ruby 2, e alguns aplicativos foram escritos no Ruby 1.8, e juntos eles não funcionam. Existe algum tipo de batente. E quando você precisa manter várias versões do Ruby na mesma máquina, geralmente tem problemas.
Por exemplo, damos a cada desenvolvedor uma plataforma na qual há praticamente tudo o que temos, todos os serviços que podem ser desenvolvidos para que ele tenha um ambiente isolado, ele pode decompô-lo e construí-lo como quiser.
Acontece que você precisa de algum tipo de pacote especialmente compilado com suporte para algo lá. Isso é difícil o suficiente. Ouvi um relatório em que a imagem do docker pesa 45 GB. No Linux, é claro, é mais simples, tudo é menor lá, mas, de qualquer forma, não haverá lugares suficientes.
Bem, existem dependências conflitantes quando você tem uma parte de um projeto, dependendo da biblioteca de uma versão, outra parte do projeto em uma versão diferente e as bibliotecas não são reunidas.
Temos sites e serviços no PHP 5.6, temos vergonha deles, mas o que fazer. Este é o nosso site. Existem sites e serviços no PHP 7, há mais deles, não temos vergonha deles. E cada desenvolvedor tem sua própria base, onde ele pode ser feliz.
Se você escreve na empresa em um idioma, três máquinas virtuais por desenvolvedor - parece normal. Se você tiver diferentes linguagens de programação, a situação se agrava.
Você tem sites e serviços nisto, nisto, então outra plataforma para Go, uma plataforma para Ruby, outro Redis ao lado. Como resultado, tudo isso se transforma em um grande campo de suporte e, durante todo o tempo, parte disso pode ser interrompida.
Portanto, substituímos os pães da linguagem de programação pelo uso de diferentes estruturas, uma vez que as estruturas em PHP são bem diferentes, elas têm capacidades diferentes, comunidades diferentes, suporte diferente. E você pode escrever um serviço para que você já tenha algo pronto para ele.
Cada serviço tem sua própria equipe.
Nossa principal vantagem, que se cristalizou ao longo de vários anos, é que cada serviço tem sua própria equipe. Isso é conveniente para um projeto grande, você pode economizar tempo com documentação, os gerentes estão bem cientes de seu projeto.
Tarefas do suporte podem ser executadas perfeitamente. Por exemplo, o serviço de seguros quebrou. E imediatamente a equipe de seguros vai reparar.
Novos recursos são criados rapidamente, porque quando você tem um serviço atômico, pode rapidamente estragar algo nele.
E quando você interrompeu seu serviço, e isso inevitavelmente acontece, você não prejudicou os serviços de outra pessoa, e os desenvolvedores com partes de outras equipes não recorrem a você e eles não dizem: "Ah, não faça isso.
Como sempre, existem nuances. Temos equipes estáveis, os gerentes são acertados na equipe. Existem documentos claros, os gerentes monitoram tudo isso de perto. Cada equipe com um gerente possui vários serviços e há um ponto específico de competência.
Se as equipes estão flutuando (isso às vezes também é usado conosco), existe um bom método chamado mapa estelar.
Você tem uma lista de serviços e pessoas. Um asterisco significa que uma pessoa é especialista neste serviço, um livro significa que uma pessoa está estudando esse serviço. A tarefa do homem é trocar um livrinho por um asterisco. E se nada estiver escrito em frente ao serviço, começam os problemas, sobre os quais continuarei falando.
Como os serviços órfãos aparecem?
O primeiro problema, a primeira maneira, de tornar um serviço órfão em sua infraestrutura é demitir pessoas. Alguém já aconteceu quando os prazos chegam das empresas antes de avaliar as tarefas? Às vezes acontece que os prazos são apertados e simplesmente não há tempo suficiente para a documentação. "Devemos entregar o serviço à produção e depois o adicionaremos."
Se a equipe é pequena, acontece que há um desenvolvedor que escreve tudo, o resto está nas asas. "Eu escrevi a arquitetura básica, você me deu as interfaces." Então, em algum momento, o gerente, por exemplo, sai. E durante esse período, quando o gerente foi embora e um novo ainda não foi nomeado, os próprios desenvolvedores decidem para onde o serviço está se movendo, o que está acontecendo lá. E como sabemos (vamos voltar alguns slides), em algumas equipes existem pessoas-flocos de neve, às vezes um floco de neve-timlid. Então ele sai, e temos um serviço órfão.
Ao mesmo tempo, as tarefas de suporte e de negócios não desaparecem, elas são liquidadas na lista de pendências. Se houver algum erro de arquitetura durante o desenvolvimento do serviço, eles também serão resolvidos no backlog. O serviço está se degradando lentamente.
Como identificar um órfão?
Esta lista descreve bem a situação. Quem aprendeu alguma coisa na infraestrutura?
Sobre as soluções alternativas documentadas: existe um serviço e, em geral, funciona, possui um manual de duas páginas, como trabalhar com ele, mas ninguém sabe como funciona por dentro.
Ou, por exemplo, há algum tipo de encurtador de link. Por exemplo, agora usamos três encurtadores de link para diferentes propósitos em diferentes serviços. Essas são as consequências.
Agora serei o capitão da evidência. O que precisa ser feito? Primeiro, você precisa transferir o serviço para outro gerente, outra equipe. Se o líder da sua equipe ainda não desistiu, nessa outra equipe, quando você entender que o serviço é como um órfão, precisará incluir alguém que entenda pelo menos algo sobre ele.
O principal: você deve ter procedimentos de transmissão por sangue. No nosso caso, geralmente sigo isso, porque preciso que isso funcione. Os gerentes precisam que isso seja entregue rapidamente, e o que acontecerá com ele mais tarde não é tão importante para eles.
A próxima maneira de tornar um órfão é "Vamos fazer a terceirização, será mais rápido e depois a transferiremos para a equipe". É claro que todo mundo tem alguns planos na equipe, na fila. Freqüentemente, um cliente comercial pensa que um terceirizado fará o mesmo que o departamento técnico que está na empresa. Embora seus motivadores sejam diferentes. A terceirização tem soluções tecnológicas estranhas e soluções algorítmicas estranhas.
Por exemplo, tivemos um serviço em que o Sphinx estava em vários lugares inesperados. Eu vou te dizer mais tarde o que eu tinha que fazer.
Os terceirizados têm estruturas auto-escritas. Este é apenas PHP nu com copiar e colar do projeto anterior, onde você pode encontrar tudo. Muletas grandes nos scripts de implantação, quando você precisa alterar várias linhas em algum arquivo com alguns scripts Bash complexos, enquanto esses scripts de implantação são chamados por algum terceiro script. Como resultado, você altera o sistema de implantação, escolhe outra coisa, pula e seu serviço não funciona. Porque havia mais 8 links para colocar entre pastas diferentes. Ou acontece que mil registros funcionam, mas cem mil se foram.
Vou continuar a capitão. Aceitar um serviço de terceirização é um procedimento necessário. Quem aconteceu que um serviço de um contratador chega, mas não é aceito em lugar algum? Obviamente, isso não é tão popular quanto um órfão de serviço, mas ainda assim.
O serviço deve ser verificado, o serviço deve ser revisado, as senhas devem ser alteradas. Tivemos um caso quando o serviço nos lançou, o painel de administração "se login == 'admin' && password == 'admin' ..." está escrito diretamente no código. Sentamos e pensamos, e as pessoas escrevem isso em 2018?
Testar o volume de armazenamento também é obrigatório. Você precisa observar o que acontecerá em cem mil registros, mesmo antes de iniciar esse serviço em algum lugar da produção.
Enviar o serviço para revisão não deve ter vergonha. Quando você diz: "Não aceitaremos este serviço, temos 20 tarefas, execute-as e depois aceitaremos", isso é normal. A consciência não deve prejudicar o fato de você substituir um gerente ou de uma empresa gastar dinheiro. A empresa gastará mais.
Tivemos um caso quando decidimos fazer um projeto piloto de terceirização.
Foi entregue dentro do prazo e esse foi o único critério de qualidade. Portanto, eles fizeram outro projeto piloto, nem mesmo um projeto piloto. Esses serviços foram aceitos, disseram de maneira administrativa: aqui está o seu código, aqui está uma equipe, aqui está o seu gerente. Os serviços realmente já começaram a ter lucro. Além disso, na verdade, eles permaneceram órfãos, ninguém entende como eles funcionam e os gerentes de todas as maneiras possíveis negam suas tarefas.
Há outro excelente conceito - desenvolvimento partidário. Quando um departamento, em regra, é um departamento de marketing, eles querem testar uma hipótese e solicitar todo o serviço terceirizado. O tráfego começa a cair nele, eles fecham documentos, assinam atos com o contratado, entram em operação e dizem: “Cara, a gente tem um serviço aqui, ele já tem tráfego, nos traz dinheiro, nos traz dinheiro, vamos levar” Nós somos: "Oppa, como assim."
E mais uma maneira de obter um serviço órfão: quando uma equipe é subitamente carregada, a gerência diz: "Vamos transferir o serviço dessa equipe para outra equipe, ela tem menos carga". E então iremos transferir para a terceira equipe e mudaremos de gerente. E no final, novamente temos um órfão.
Qual é o problema com os órfãos?
Quem não sabe, este foi o navio da linha Wasa criada na Suécia, famosa pelo fato de ter afundado 5 minutos após o lançamento. E o rei da Suécia, aliás, não executou ninguém por isso. Foi construído por duas gerações de engenheiros que não podiam construir tais navios. O efeito natural.
A propósito, o navio poderia afundar, muito pior, por exemplo, quando o rei o montaria em algum lugar durante uma tempestade. E assim, ele se afogou imediatamente, de acordo com a prisão, é bom falhar cedo.
Se falharmos cedo, geralmente não há problemas. Por exemplo, durante a aceitação, eles enviaram para revisão. E se já falhamos na produção, quando o dinheiro é investido, pode haver problemas. As consequências, como são chamadas nos negócios.
Por que serviços órfãos perigosos:
- O serviço pode quebrar repentinamente.
- O serviço é reparado por um longo período ou não é reparado.
- Questões de segurança.
- Problemas com melhorias e atualizações.
- Se um serviço importante falha, a reputação da empresa sofre.
O que fazer com os serviços órfãos?
Mais uma vez, o que fazer. Em primeiro lugar, deve haver documentação. Durante 7 anos no Banki.ru, fui ensinado que os testadores não devem ter uma palavra para os desenvolvedores e a operação não deve ter uma palavra para todos. É necessário verificar.
Em segundo lugar, é necessário escrever esquemas de interação, porque acontece que serviços que não são bem recebidos contêm dependências sobre as quais ninguém falou. Por exemplo, os desenvolvedores colocam o serviço na chave para alguns Yandex.Maps ou Dadata. Você ficou sem um limite gratuito, tudo quebrou e não sabe o que aconteceu. Todos esses ancinhos devem ser descritos: o serviço usa Dadata, Sms, outra coisa.
Em terceiro lugar, trabalhe com a dívida técnica. Quando você faz muletas ou aceita o serviço e diz que algo precisa ser feito, você precisa garantir que eles o façam. Porque então pode acontecer que o pequeno buraco não seja tão pequeno e você caia lá.
Com tarefas de arquitetura, tivemos uma história sobre o Sphinx. Em um dos serviços, o Sphinx foi usado para inserir listas. Apenas uma lista de paginação, mas era reindexada todas as noites. Foi compilado a partir de dois índices: um foi indexado todas as noites, e ainda havia um pequeno índice aparafusado a ele. Todos os dias, com uma probabilidade de 50%, bombardeará ou não, durante o cálculo, o índice estava batendo e as notícias pararam de ser atualizadas na página principal. No início, eram 5 minutos, enquanto o índice era re-indexado, depois o índice aumentava e, em algum momento, começou a re-indexar 40 minutos. Quando cortamos, soltamos um suspiro de alívio, porque estava claro que um pouco mais de tempo passaria e nosso índice seria reindexado em tempo integral. Será um arquivo para o nosso portal, oito horas sem novidades - é isso, o negócio se levantou.
Plano de trabalho com um serviço órfão
De fato, é muito difícil, porque o devops é sobre comunicação. Quero ter boas relações com meus colegas e, quando você bate em colegas e gerentes com regulamentos na cabeça, eles podem ter sentimentos conflitantes por aquelas pessoas que fazem isso.
Além de todos esses pontos, há outra coisa importante: para cada serviço específico, para cada seção específica do procedimento de implantação, pessoas específicas devem ser responsáveis. Quando não há pessoas e você precisa atrair outras pessoas, para estudar a coisa toda, fica difícil.
Se tudo isso não ajudar, e o órfão do serviço ainda é órfão, ninguém quer levá-lo para você, a documentação não está escrita, a equipe que foi chamada para esse serviço se recusa a fazer algo, há uma maneira fácil de refazer tudo .
Ou seja, você pega os requisitos de serviço novamente e escreve um novo serviço, melhor, em uma plataforma melhor, sem soluções tecnológicas estranhas. E migre para ele na batalha.
Tivemos uma situação em que pegamos o serviço no Yii 1 e percebemos que não podíamos desenvolvê-lo mais, porque tínhamos acabado os desenvolvedores que podem escrever bem no Yii 1. Todos os desenvolvedores escrevem bem no terceiro Symfony. O que fazer Levamos um tempo, alocamos a equipe, alocamos o gerente, reescrevemos o projeto e mudamos o tráfego suavemente para ele.
Depois disso, o serviço antigo pode ser excluído. Esse é o meu procedimento favorito, quando você precisa retirar e limpar algum serviço do sistema de gerenciamento de configuração e depois verificar se todos os carros da produção foram reembolsados para que os desenvolvedores não tenham mais vestígios. O repositório no git permanece.
Isso é tudo sobre o que eu queria falar, estou pronto para discutir, o tópico é holístico, muitos flutuaram nele.
Nos slides, tratava-se de você unificar idiomas. Um exemplo foi o redimensionamento de imagens. Mas é realmente necessário ter um idioma difícil? Como redimensionar imagens em PHP, bem, você realmente pode fazer isso em Golang.De fato, isso não é necessário, como todas as práticas. Talvez, em alguns casos, até indesejável. Mas você precisa entender que, se você tem 50 pessoas no departamento técnico, 45 delas são desenvolvedores de PHP, outras 3 são devops que podem fazer Python, Ansible, Puppet e algo assim, e apenas uma delas escreve em alguns Vá ao serviço para redimensionar as fotos e, quando ele sair, o exame sairá com ele. E, ao mesmo tempo, você precisará procurar um desenvolvedor específico do mercado que conheça esse idioma, especialmente se for raro. Ou seja, do ponto de vista organizacional, isso é problemático. Do ponto de vista dos devops, você precisará não apenas clonar alguns conjuntos prontos de playbooks que você usa para implantar serviços, mas também precisará escrevê-los novamente.
Agora estamos vendo o serviço no Node.js, e ele será apenas uma plataforma próxima para cada desenvolvedor com um idioma separado. Mas ficamos pensando que o jogo valia a pena. Ou seja, a questão aqui é sentar e pensar.
Como você monitora seus serviços? Como você coleta e rastreia logs?Coletamos logs no Elasticsearch e colocamos no Kibana e, dependendo dos ambientes de produção ou teste, diferentes coletores são usados lá. Em algum lugar lenhador, em algum outro lugar, não me lembro mais. E ainda existem alguns lugares em certos serviços onde colocamos o Telegraf e o bullet em outro lugar separadamente.Como viver com o Puppet e o Ansible em um ambiente?De fato, agora temos dois ambientes, um é Puppet, o outro é Ansible. Estamos trabalhando para hibridá-los. O Ansible é um bom ambiente para a configuração inicial, o Puppet é uma coisa ruim para a configuração inicial, porque requer mãos para trabalhar diretamente com o site, e o Puppet fornece convergência de configuração. Isso significa que o site em si é mantido atualizado e, para que a máquina ansiblizada seja mantida atualizada, você precisa constantemente jogar com ele com alguma frequência. Aqui está essa diferença.Como você mantém a compatibilidade? Você tem configurações no Ansible e no Puppet?Essa é a nossa grande dor, mantemos a compatibilidade com as mãos e pensamos, como se agora, mudar tudo isso para algum lugar. Acontece que o Puppet lança pacotes e suporta alguns links lá, enquanto o Ansible, por exemplo, rola o código e direciona novas configurações de aplicativos para lá.A apresentação foi sobre diferentes versões do Ruby. Qual é a solução?Somos confrontados com isso em um só lugar, e temos que manter isso em mente o tempo todo. Acabamos de desativar a parte que trabalhava no Ruby, que era incompatível com os aplicativos, e a mantivemos separada.Este ano, a conferência DevOpsDays Moscow será realizada em 7 de dezembro em Technopolis. Até 11 de novembro, aceitamos solicitações de relatórios. Envie- nos se você quiser falar.
As inscrições para os participantes estão abertas, participe!