O Diretor de Operações do portal Banki.ru, Andrey Nikolsky, falou na conferência do ano passado sobre serviços órfãos: como identificar um órfão na infra-estrutura, por que os serviços órfãos são ruins, o que fazer com eles e o que fazer se nada ajudar.
Abaixo do corte está uma versão em texto do relatório.
Olá colegas! Meu nome é Andrey, chefio as operações do Banki.ru.
Temos serviços grandes, estes são serviços monolíticos, existem serviços num sentido mais clássico e existem outros muito pequenos. Na minha terminologia operário-camponesa, digo que se um serviço é simples e pequeno, então é micro, e se não for muito simples e pequeno, então é apenas um serviço.
Prós de serviços
Examinarei rapidamente as vantagens dos serviços.
O primeiro é o dimensionamento. Você pode fazer algo rapidamente no serviço e iniciar a produção. Você recebeu tráfego, clonou o serviço. Você tem mais tráfego, clonou-o e convive com ele. Este é um bom bônus e, em princípio, quando começamos, era considerado o mais importante para nós o motivo pelo qual estamos fazendo tudo isso.
Em segundo lugar, desenvolvimento isolado, quando você tem diversas equipes de desenvolvimento, vários desenvolvedores diferentes em cada equipe, e cada equipe desenvolve seu próprio serviço.
Com as equipes há uma nuance. Os desenvolvedores são diferentes. E há, por exemplo, . Vi isso pela primeira vez com Maxim Dorofeev. Às vezes, as pessoas do floco de neve estão em algumas equipes e não em outras. Isso torna os diferentes serviços usados em toda a empresa um pouco desiguais.
Olha a foto: esse é um bom desenvolvedor, tem mãos grandes, pode fazer muita coisa. O principal problema é de onde vêm essas mãos.
Os serviços permitem utilizar diferentes linguagens de programação mais adequadas para diferentes tarefas. Alguns serviços estão em Go, alguns estão em Erlang, alguns estão em Ruby, alguns estão em PHP, alguns estão em Python. Em geral, você pode expandir amplamente. Existem nuances aqui também.
A arquitetura orientada a serviços trata principalmente de devops. Ou seja, se você não tem automação, não tem processo de implantação, se você configura manualmente, suas configurações podem mudar de instância de serviço para instância, e você tem que ir lá fazer alguma coisa, aí você está no inferno.
Por exemplo, você tem 20 serviços e precisa implantar manualmente, você tem 20 consoles e pressiona “enter” simultaneamente como um ninja. Não é muito bom.
Se você tem um serviço após testes (se houver testes, claro), e ainda precisa finalizá-lo com um arquivo para que funcione em produção, também tenho uma má notícia para você.
Se você confia em serviços específicos da Amazon e trabalha na Rússia, há dois meses você também tinha “Tudo ao redor está pegando fogo, estou bem, está tudo bem”.
Usamos Ansible para automatizar a implantação, Puppet para convergência, Bamboo para automatizar a implantação e Confluence para descrever tudo de alguma forma.
Não vou me alongar neste assunto, porque o relatório trata mais de práticas de interação e não de implementação técnica.
Por exemplo, tivemos problemas onde o Puppet no servidor funciona com Ruby 2, mas alguns aplicativos são escritos para Ruby 1.8 e eles não funcionam juntos. Algo dá errado aí. E quando você precisa rodar múltiplas versões de Ruby em uma máquina, normalmente você começa a ter problemas.
Por exemplo, damos a cada desenvolvedor uma plataforma onde está aproximadamente tudo o que temos, todos os serviços que podem ser desenvolvidos, para que ele tenha um ambiente isolado, possa quebrá-lo e construí-lo como quiser.
Acontece que você precisa de algum pacote especialmente compilado com suporte para algo ali. É muito difícil. Ouvi um relatório onde a imagem do Docker pesa 45 GB. No Linux, claro, é mais simples, tudo é menor lá, mas ainda assim não vai ter espaço suficiente.
Bem, existem dependências conflitantes, quando uma parte do projeto depende de uma biblioteca de uma versão, outra parte do projeto depende de outra versão e as bibliotecas não são instaladas juntas.
Temos sites e serviços em PHP 5.6, temos vergonha deles, mas o que podemos fazer? Este é o nosso único site. Existem sites e serviços em PHP 7, existem mais, não temos vergonha deles. E cada desenvolvedor tem sua própria base onde vê com alegria.
Se você escreve em uma empresa em um idioma, três máquinas virtuais por desenvolvedor parecem normais. Se você tiver linguagens de programação diferentes, a situação piorará.
Você tem sites e serviços nisso, depois outro site para Go, um site para Ruby e alguns outros Redis adicionais. Como resultado, tudo isso se transforma em um grande campo de apoio, e sempre parte dele pode quebrar.
Portanto, substituímos os benefícios da linguagem de programação pelo uso de diferentes frameworks, uma vez que os frameworks PHP são bastante diferentes, possuem capacidades diferentes, comunidades diferentes e suportes diferentes. E você pode escrever um serviço para que já tenha algo pronto para ele.
Cada serviço tem sua própria equipe
A nossa principal vantagem, que se cristalizou ao longo de vários anos, é que cada serviço tem a sua equipa. Isso é conveniente para um projeto grande, você pode economizar tempo na documentação, os gerentes conhecem bem seu projeto.
Você pode enviar tarefas facilmente do suporte. Por exemplo, o serviço de seguros quebrou. E imediatamente a equipe que trata do seguro vai consertar.
Novos recursos estão sendo criados rapidamente, porque quando você tem um serviço atômico, você pode rapidamente inserir algo nele.
E quando você quebra seu serviço, e isso acontece inevitavelmente, você não afeta os serviços de outras pessoas, e os desenvolvedores de outras equipes não vêm correndo até você com pedaços e dizem: “Sim, não faça isso”.
Como sempre, existem nuances. Temos equipes estáveis, os dirigentes estão pregados na equipe. Existem documentos claros, os gestores acompanham tudo de perto. Cada equipe com gestor possui diversos serviços, existindo um ponto de competência específico.
Se as equipes estiverem flutuando (às vezes também usamos isso), existe um bom método chamado “mapa estelar”.
Você tem uma lista de serviços e pessoas. Um asterisco significa que a pessoa é especialista neste serviço, um livro significa que a pessoa está estudando este serviço. A tarefa da pessoa é trocar a caderneta por um asterisco. E se nada estiver escrito na frente do serviço, começam os problemas, dos quais falarei mais adiante.
Como aparecem os serviços órfãos?
O primeiro problema, a primeira forma de conseguir um serviço órfão na sua infraestrutura é demitir pessoas. Alguém já fez uma empresa cumprir prazos antes de as tarefas serem avaliadas? Às vezes acontece que os prazos são apertados e simplesmente não há tempo suficiente para a documentação. “Precisamos entregar o serviço para produção, depois vamos adicioná-lo.”
Se a equipe for pequena, acontece que tem um desenvolvedor que escreve tudo, os demais ficam nos bastidores. “Eu escrevi a arquitetura básica, vamos adicionar as interfaces.” Aí, em algum momento, o gestor, por exemplo, vai embora. E nesse período, quando o gerente sai e ainda não foi nomeado um novo, os próprios desenvolvedores decidem para onde vai o serviço e o que acontece lá. E como sabemos (vamos voltar alguns slides), em algumas equipes há pessoas do floco de neve, às vezes um líder da equipe do floco de neve. Então ele se demite e conseguimos um serviço para órfãos.
Ao mesmo tempo, as tarefas de suporte e de negócios não desaparecem; elas acabam no backlog. Se houve algum erro de arquitetura durante o desenvolvimento do serviço, ele também vai parar no backlog. O serviço está se deteriorando lentamente.
Como identificar um órfão?
Esta lista descreve bem a situação. Quem aprendeu alguma coisa sobre sua infraestrutura?
Sobre soluções alternativas documentadas: existe um serviço e, em geral, funciona, tem um manual de duas páginas de como trabalhar, mas ninguém sabe como funciona por dentro.
Ou, por exemplo, existe algum tipo de encurtador de link. Por exemplo, atualmente temos três encurtadores de links em uso para finalidades diferentes em serviços diferentes. Estas são apenas as consequências.
Agora serei o capitão do óbvio. O que deveria ser feito? Primeiro precisamos transferir o serviço para outro gestor, outra equipe. Se o líder da sua equipe ainda não desistiu, então nessa outra equipe, ao entender que o serviço é como um órfão, você precisa incluir alguém que entenda pelo menos alguma coisa sobre ele.
O principal: você deve ter os procedimentos de transferência escritos com sangue. No nosso caso, costumo monitorar isso, pois preciso que tudo funcione. Os gerentes precisam que isso seja entregue rapidamente, e o que acontece depois não é mais tão importante para eles.
A próxima maneira de tornar um órfão é “Faremos terceirizado, será mais rápido e depois entregaremos para a equipe”. É claro que todos têm alguns planos na equipe, por sua vez. Muitas vezes um cliente empresarial pensa que o terceirizado fará a mesma coisa que o departamento técnico da empresa. Embora seus motivadores sejam diferentes. Existem soluções tecnológicas estranhas e soluções algorítmicas estranhas na terceirização.
Por exemplo, tínhamos um serviço que colocava o Sphinx em vários lugares inesperados. Depois conto o que tive que fazer.
Os terceirizados têm estruturas autoescritas. Isso é apenas PHP simples com copiar e colar de um projeto anterior, onde você pode encontrar todo tipo de coisa. Os scripts de implantação são uma grande desvantagem quando você precisa usar alguns scripts Bash complexos para alterar várias linhas em algum arquivo, e 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, mas seu serviço não funciona. Porque aí foi necessário colocar mais 8 links entre pastas diferentes. Ou acontece que mil registros funcionam, mas cem mil não funcionam mais.
Continuarei como capitão. Aceitar um serviço terceirizado é um procedimento obrigatório. Alguém já teve um serviço terceirizado que chegou e não foi aceito em lugar nenhum? É claro que isso não é tão popular quanto um serviço órfão, mas ainda assim.
O serviço precisa ser verificado, o serviço precisa ser revisado, as senhas precisam ser alteradas. Tivemos um caso em que nos prestaram um serviço, existe um painel de administração “if login == 'admin' && password == 'admin'...”, está escrito direto no código. Sentamos e pensamos, e as pessoas escrevem isso em 2018?
Testar a capacidade de armazenamento também é necessário. Você precisa ver o que acontecerá em cem mil registros, mesmo antes de colocar esse serviço em produção em algum lugar.
Não deve haver vergonha em enviar um serviço para melhoria. Quando você fala: “Não vamos aceitar esse serviço, temos 20 tarefas, faça, então aceitaremos”, isso é normal. Sua consciência não deve ser prejudicada pelo fato de você estar montando um gerente ou de a empresa estar desperdiçando dinheiro. A empresa gastará mais.
Tivemos um caso em que decidimos terceirizar um projeto piloto.
Foi entregue no prazo e esse foi o único critério de qualidade. Por isso fizemos outro projeto piloto, que nem era mais piloto. Esses serviços foram aceitos, e por via administrativa eles disseram, aqui está o seu código, aqui está a equipe, aqui está o seu gerente. Na verdade, os serviços já começaram a gerar lucro. Ao mesmo tempo, de fato, ainda são órfãos, ninguém entende como trabalham e os gestores fazem o possível para renunciar às suas tarefas.
Existe outro grande conceito – o desenvolvimento de guerrilha. Quando algum departamento, geralmente o departamento de marketing, quer testar uma hipótese e encomenda todo o serviço terceirizado. Começa a entrar muito trânsito, eles fecham os documentos, assinam documentos com a empreiteira, entram em operação e falam: “Gente, a gente tem um serviço aqui, já tem trânsito, traz dinheiro pra gente, vamos aceitar”. Nós pensamos: “Oppa, como pode ser isso?”
E outra forma de conseguir um serviço órfão: quando alguma equipe de repente fica sobrecarregada, a gestão diz: “Vamos transferir o serviço dessa equipe para outra equipe, ela tem uma carga menor”. E então vamos transferi-lo para um terceiro time e trocar o técnico. E no final temos um órfão novamente.
Qual é o problema dos órfãos?
Quem não sabe, este é o encouraçado Wasa erguido na Suécia, famoso por 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 sabiam construir tais navios. Efeito natural.
O navio poderia ter afundado, aliás, de uma forma muito pior, por exemplo, quando o rei já estava navegando nele em algum lugar durante uma tempestade. E então ele se afogou na hora, de acordo com o Agile é bom falhar cedo.
Se falharmos cedo, geralmente não haverá problemas. Por exemplo, durante a aceitação foi enviado para revisão. Mas se já falharmos na produção, quando o dinheiro for investido, então poderá haver problemas. Consequências, como são chamadas nos negócios.
Por que os serviços órfãos são perigosos:
- O serviço pode falhar repentinamente.
- O serviço leva muito tempo para ser reparado ou nem é reparado.
- Problemas de segurança.
- Problemas com melhorias e atualizações.
- Se um serviço importante falhar, a reputação da empresa será prejudicada.
O que fazer com os serviços órfãos?
Vou repetir o que fazer novamente. Primeiro, deve haver documentação. 7 anos no Banki.ru me ensinaram que os testadores não devem acreditar na palavra dos desenvolvedores e que as operações não devem acreditar na palavra de todos. Precisamos verificar.
Em segundo lugar, é necessário escrever diagramas de interação, porque acontece que serviços que não são muito bem recebidos contêm dependências que ninguém falou. Por exemplo, os desenvolvedores instalaram o serviço em sua chave para alguns Yandex.Maps ou Dadata. Você esgotou o limite gratuito, tudo está quebrado e você não sabe o que aconteceu. Todos esses rakes devem ser descritos: o serviço usa Dadata, SMS, algo mais.
Terceiro, trabalhar com dívida técnica. Quando você faz algum tipo de muleta ou aceita um serviço e diz que algo precisa ser feito, você precisa ter certeza de que isso será feito. Porque então pode acontecer que o pequeno buraco não seja tão pequeno e você caia nele.
Com tarefas arquitetônicas, tivemos uma história sobre a Esfinge. Um dos serviços usou o Sphinx para inserir listas. Apenas uma lista paginada, mas era reindexada todas as noites. Foi montado a partir de dois índices: um grande era indexado todas as noites, e também havia um pequeno índice que era aparafusado nele. Todos os dias, com 50% de probabilidade de bombardeio ou não, o índice travava durante o cálculo e nossas notícias paravam de ser atualizadas na página principal. No início demorava 5 minutos para o índice ser reindexado, depois o índice cresceu e, em algum momento, começou a demorar 40 minutos para reindexar. Quando eliminamos isso, respiramos aliviados, pois ficou claro que passaria um pouco mais de tempo e nosso índice seria reindexado em tempo integral. Isso vai ser um fracasso para o nosso portal, não há novidades há oito horas - é isso, o negócio parou.
Planeje trabalhar com um serviço órfão
Na verdade, isso é muito difícil de fazer, porque devops trata de comunicação. Você deseja ter boas relações com seus colegas e, quando bate na cabeça de seus colegas e gerentes com regulamentos, eles podem ter sentimentos conflitantes em relação às pessoas que fazem isso.
Além de todos esses pontos, há outra coisa importante: pessoas específicas devem ser responsáveis por cada serviço específico, por cada seção específica do procedimento de implantação. Quando não tem gente e você tem que atrair outras pessoas para estudar todo esse assunto, fica difícil.
Se tudo isso não ajudou, e o seu serviço órfão ainda é órfão, ninguém quer assumi-lo, a documentação não está escrita, a equipe que foi chamada para este serviço se recusa a fazer qualquer coisa, existe uma maneira simples - refazer tudo.
Ou seja, você retoma os requisitos do serviço e escreve um novo serviço, melhor, em uma plataforma melhor, sem soluções tecnológicas estranhas. E você migra para ele na batalha.
Tivemos uma situação em que pegamos um serviço no Yii 1 e percebemos que não poderíamos desenvolvê-lo ainda mais, porque ficamos sem desenvolvedores que pudessem escrever bem no Yii 1. Todos os desenvolvedores escrevem bem no Symfony XNUMX. O que fazer? Alocamos tempo, alocamos uma equipe, alocamos um gerente, reescrevemos o projeto e transferimos suavemente o tráfego para ele.
Depois disso, o serviço antigo pode ser excluído. Este é o meu procedimento preferido, quando você precisa retirar e limpar algum serviço do sistema de gerenciamento de configuração e depois verificar se todos os carros em produção foram desabilitados, para que os desenvolvedores não tenham mais rastros. O repositório permanece no Git.
Isso é tudo que eu queria falar, estou pronto para discutir, o assunto é holivar, muitos nadaram nele.
Os slides diziam que vocês unificaram os idiomas. Um exemplo foi o redimensionamento de fotos. É realmente necessário limitá-lo estritamente a um idioma? Porque o redimensionamento de imagens em PHP, bem, poderia ser feito em Golang.
Na verdade, é opcional, como todas as práticas. Talvez, em alguns casos, seja até indesejável. Mas você precisa entender que se você tem um departamento técnico em uma empresa de 50 pessoas, 45 delas são especialistas em PHP, outros 3 são devops que conhecem Python, Ansible, Puppet e algo assim, e apenas um deles escreve em algum tipo de linguagem. algum serviço de redimensionamento de imagem Go, então, quando ele sai, a experiência vai junto. E ao mesmo tempo, você precisará procurar um desenvolvedor específico do mercado que conheça essa linguagem, principalmente se ela for rara. Ou seja, do ponto de vista organizacional, isso é problemático. Do ponto de vista do DevOps, você não precisará apenas clonar algum conjunto pronto de manuais que você usa para implantar serviços, mas também terá que escrevê-los novamente.
Atualmente estamos construindo um serviço em Node.js, e esta será apenas uma plataforma próxima para cada desenvolvedor com uma linguagem separada. Mas sentamos e pensamos que o jogo valia a pena. Ou seja, esta é uma questão para você sentar e pensar.
Como você monitora seus serviços? Como você coleta e monitora logs?
Coletamos logs no Elasticsearch e os colocamos no Kibana, e dependendo se são ambientes de produção ou de teste, diferentes coletores são usados lá. Em algum lugar Lenhador, em outro lugar alguma outra coisa, não me lembro. E ainda existem alguns locais em determinados serviços onde instalamos o Telegraf e filmamos em outro lugar separadamente.
Como conviver com Puppet e Ansible no mesmo ambiente?
Na verdade, agora temos dois ambientes, um é o Puppet e o outro é o Ansible. Estamos trabalhando para hibridizá-los. Ansible é uma boa estrutura para configuração inicial, Puppet é uma estrutura ruim para configuração inicial porque requer trabalho prático diretamente na plataforma e Puppet garante convergência de configuração. Isso significa que a plataforma se mantém atualizada e, para que a máquina ansibilizada se mantenha atualizada, é necessário executar playbooks nela o tempo todo e com alguma frequência. Essa é a 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 em como sair de tudo isso em algum lugar agora. Acontece que o Puppet lança pacotes e mantém alguns links lá, e o Ansible, por exemplo, lança o código e ajusta as configurações mais recentes do aplicativo lá.
A apresentação foi sobre diferentes versões do Ruby. Que solução?
Encontramos isso em um lugar e temos que mantê-lo em mente o tempo todo. Simplesmente desligamos a parte que rodava no Ruby que era incompatível com as aplicações e a mantivemos separada.
A conferência deste ano acontecerá no dia 7 de dezembro em Technopolis. Aceitamos inscrições para relatórios até 11 de novembro. nós se você quiser falar.
As inscrições para participantes estão abertas, junte-se a nós!
Fonte: habr.com