"E se você não atirar, eu serei mimado"
Até recentemente, acreditava-se que o serviço deveria funcionar. Eles desenharam, inventaram, escreveram scripts - tudo parece estar bem, você pode colocá-lo no prod.
Mas os concorrentes não estão dormindo, então a corrida começa não apenas por novos recursos, mas também por velocidade. Qualquer congelamento do aplicativo ou uma resposta longa do servidor (para não mencionar os erros pop-up do 500º) estraga a impressão do serviço e força o usuário a sair para outro lugar. Certamente, todos enfrentaram situações em que, em vez de comprar uma passagem para um avião, trem ou concerto, “Erro interno do servidor” foi exibido na tela e você ficou furioso por quebrar o monitor.
Sou Victor Bodrov, trabalho na Yandex.Money na equipe de pesquisa em produtividade e quero falar sobre como é útil estudar a produtividade diretamente na produção.
Cada minuto de inatividade é desastroso para as empresas, especialmente para as envolvidas em transações financeiras, como transferências e pagamentos, pagamento de mercadorias nas lojas. Cada pagamento pendente não é apenas perdas monetárias, mas também perdas de reputação. Nessas condições, é necessário um alto tempo de atividade, para o qual é necessário manter um toque no pulso do sistema de pagamentos e monitorar constantemente todos os seus indicadores, prestando especial atenção ao desempenho.
Por que pesquisar?
Em primeiro lugar, conhecer o desempenho do seu próprio serviço ajuda você a se preparar para o lançamento de novos recursos, várias promoções e vendas. O conhecimento de indicadores confiáveis ajudará, no momento certo, a atender o fluxo de novos usuários, não com um pequeno portão com catraca, mas com amplas portas e braços abertos.
Em segundo lugar, um bom serviço deve saber o limite de seu desempenho a qualquer momento, portanto, as medições devem ser regulares. Se você fizer isso com bastante frequência, mantendo a relevância dos dados, não perca a degradação em seu serviço e poderá restaurar rapidamente os indicadores necessários.
Em terceiro lugar, contando com dados de desempenho atualizados, é mais fácil para uma empresa planejar o desenvolvimento de um serviço e escolher direções de crescimento.
Para aqueles que estão intrigados com esse problema pela primeira vez, surge a pergunta: onde e como medir a produtividade? Freqüentemente, um banco é usado para tais experimentos. Em empresas individuais, existe uma posição especial para pesquisa de desempenho. Se você tiver - ótimo! Se 1 em 1 corresponde ao produto, tudo está bem com você. Mas na maioria das vezes é muito caro manter uma posição que corresponda totalmente ao produto. Como ser Acontece que o único lugar que corresponde totalmente ao produto é o próprio produto?
Para muitos, a proposta de medir e verificar algo diretamente no produto parece herética. Não se assuste se tudo for feito com cuidado, nada de ruim vai acontecer. Por exemplo, pré-calculamos possíveis riscos e determinamos o que em nosso sistema pode sofrer com o experimento. Junto com isso, planejamos como reduzir o perigo e monitoramos constantemente o status do sistema.
A pesquisa no produto não cancela o uso do estande. Ele pode realizar verificações de liberação e experimentos especiais para estudar o desempenho de microsserviços, incluindo-os individualmente ou em várias combinações.
A principal e inegável vantagem dos resultados obtidos no produto - eles são as mais honestas de todas as opções e o mais próximo possível do processamento real do tráfego do usuário. Não importa o quão perto o suporte esteja do produto em termos de características - ele não será capaz de pegá-lo, como a tartaruga de Aquiles. Ao pesquisar sobre o produto, você usará os mesmos bancos de dados que usuários reais, a mesma rede, o mesmo ambiente. Não há necessidade de criar nada, tudo já foi construído antes de você e está funcionando corretamente.
Os dados de tais experimentos serão de interesse de todos os engenheiros, independentemente da função atribuída a eles: desenvolvedores, testadores, administradores. Os indicadores de desempenho garantidos também interessam aos negócios - para clientes em potencial, eles serão um anúncio convincente do serviço.
Seleção de cenário e padrões de fluxo de carga
Para a organização segura e adequada de tais experimentos, várias etapas obrigatórias devem ser concluídas.
Seleção de cenário
O primeiro passo, o mais importante, é selecionar os cenários em estudo. Podem ser solicitações únicas (por exemplo, verificação do saldo) ou cenários com lógica complexa, em que cada solicitação subsequente depende dos resultados da solicitação anterior (pagamento de mercadorias na loja, transferência de carteira para carteira). Fazemos regularmente uma lista de todos os processos de negócios que existem no sistema. Temos mais de 400 desses processos. Com base nos objetivos do negócio, coordenaremos as prioridades do cenário.
Quais cenários devem ser incluídos no grupo de prioridades?
- Aqueles para os quais é esperado um aumento na atividade do usuário em um futuro próximo.
- Aqueles para os quais existem restrições rígidas constantes (por vários motivos) que não permitem que você fique abaixo do SLA.
Assim, é possível formar um conjunto de cenários prioritários para verificações regulares do produto. Em nossa empresa, realizamos disparos contra eles pelo menos uma vez por trimestre.
Um conjunto de técnicas e ferramentas é selecionado dependendo da lógica do script. No nosso caso, cenários prioritários têm lógica ramificada. Por exemplo, ao efetuar pagamentos com cartão, várias verificações são realizadas, dependendo do script em sua própria ramificação, portanto, usamos o JMeter para implementá-las. É conveniente apenas para cenários tão complexos, onde cada solicitação subsequente depende do resultado da anterior. Se você precisar fazer solicitações únicas, recomendo usar o Phantom de alto desempenho.
Para pesquisar cenários de usuários, podem ser necessários usuários especiais, em nome de quais solicitações serão feitas. Se você usar um usuário ou um pequeno número deles, poderá encontrar o cache de dados, o que distorcerá os resultados. Quanto mais usuários diferentes, mais precisos os dados da pesquisa.
Circuito de carga
Na segunda etapa, selecionamos o circuito de alimentação de intensidade de entrada.
Por exemplo, antes de uma venda, determinamos quais são as principais formas de pagamento dos usuários. Para ajustar e rastrear gargalos, executamos disparos em certos tipos de pagamento. Como regra, a atividade do usuário durante várias promoções tende a favorecer um ou outro cenário. Ao verificá-lo, você obtém uma imagem clara do comportamento dele sob carga.
Mas os negócios também podem estar interessados na imagem geral do desempenho. Nesse caso, você pode combinar os cenários comerciais mais populares proporcionalmente ao uso por usuários reais e ativar a carga cumulativa. Vale considerar que, neste caso, podem surgir dificuldades com a avaliação quantitativa. Em vez de um número de desempenho específico, você obterá uma série de números, que, por sua vez, podem variar dependendo das proporções de um cenário específico no fluxo geral.
A oferta de intensidade também pode ser diferente. Vou me concentrar nos dois perfis mais comuns. Este é um teste com um teste de fluxo de intensidade e estabilidade fornecido linearmente (ou por etapas), no qual a operação de longo prazo do serviço é verificada sob um fluxo de intensidade estável. A segunda opção requer um longo tempo de pesquisa, o que nem sempre é possível em um ambiente de combate; além disso, o nível de intensidade fornecida já deve ser conhecido.
Eixo X - tempo, eixo Y - intensidade de carga (solicitações por segundo)
É bom quando existe um SLA específico com base no qual você pode realizar verificações, monitorando o desempenho, o tempo de resposta e o comportamento dos componentes. Uma situação mais comum é quando o nível de desempenho é desconhecido e você precisa determiná-lo. Para fazer isso, usamos a primeira opção - medição com aumento da intensidade fornecida. Ativamos o fluxo de entrada, aumentamos de forma linear ou gradual, observamos o comportamento do serviço. Uma carga aplicada linearmente pode rastrear com mais precisão o ponto de saturação e o ponto de ruptura. Isso foi descrito em mais detalhes em nosso artigo . Mas a intensidade fornecida passo a passo combina até pequenos testes de estabilidade, especialmente se as etapas forem demoradas. Não é recomendável aplicar imediatamente um grande fluxo de carga à entrada; é melhor “aquecer” o serviço, aumentando gradualmente o fluxo de entrada.
Você também pode realizar uma série de dois experimentos. Primeiro meça o ponto de saturação com uma carga e parada linearmente aplicadas. Você não deve continuar alimentando o fluxo mais longe do colapso, ele ainda é um estímulo, não um suporte. O segundo experimento é examinar o comportamento do serviço sob uma carga de etapa, selecionando várias etapas perto do ponto de saturação. E, em seguida, execute o teste de estabilidade na medida do tempo, escolhendo uma carga 15-20% abaixo do ponto de saturação (ou um colapso se você o tiver feito antes da saturação). Subir mais alto é perigoso.
Tempo
Em seguida, você deve determinar o tempo do experimento. Uma das condições mais importantes para a realização de medições de desempenho no produto é a segurança de todos os usuários reais. É extremamente raro haver uma oportunidade de interromper o serviço por um tempo para prevenção e bombardeá-lo com calma. Como regra, os serviços online são ajustados para funcionarem 24 horas por dia, 7 dias por semana, portanto, você precisa se encaixar no modo de uso do serviço.
É lógico que, quanto maior a atividade real do usuário, maiores os riscos que as filmagens podem levar a tempo de inatividade e perda financeira. Por outro lado, quanto menos tráfego de usuários, menor erro de medição. Portanto, para minimizar o impacto das experiências, recomenda-se que elas sejam realizadas em períodos de atividade reduzida do usuário.
Como mostra a prática, a atividade mínima de nossos usuários cai no período de duas a sete da manhã. Obviamente, cada serviço tem suas próprias características e seu próprio público, por isso determinamos o tempo de filmagem monitorando o comportamento dos usuários. Nem sempre é possível organizar experimentos no período ideal selecionado. Para disparar contra o prod, especialmente no estágio inicial de sua conexão, é necessário um controle maior. Isso causará dificuldades, pois seus colegas também são pessoas e podem nem sempre ir trabalhar à noite. Esta situação exigirá um compromisso. Você precisa escolher um horário adequado para todos e, ao mesmo tempo, satisfazer a condição de baixa atividade do usuário.
Dificuldades em trabalhar com contrapartes
Se o serviço estiver vinculado não apenas aos cálculos internos, mas também à interação com serviços de terceiros (contrapartes), você precisará escolher como conduzirá a demissão: junto com a contraparte ou usando o stub do serviço. Naturalmente, se você planeja filmar nos servidores da contraparte, você deve primeiro concordar com tudo. Isso complicará bastante a preparação para o disparo, mas acrescentará vantagens à veracidade dos resultados obtidos como resultado.
E vice-versa: se você substituir o serviço da contraparte por um plugue, a preparação para fotografar será bastante simplificada, mas a honestidade dos resultados diminuirá. Deve-se ter em mente que o esboço deve imitar o máximo possível o comportamento da contraparte, e não apenas dar 200 OK.
As contrapartes são diferentes. Alguns passam facilmente para verificações conjuntas, enquanto outros executam todas as etapas em várias instâncias. Determinar o momento das experiências também pode causar controvérsia. Por exemplo, alguns escritórios estaduais concordam em trabalhar apenas de 9 a 18 horas.
Verificando o acesso e a coordenação com o Conselho de Segurança, departamentos financeiros, administradores
Nesta parte, focaremos nos acessos e aprovações com todas as pessoas responsáveis - o serviço de segurança, os departamentos financeiros e os administradores de sistema.
Você precisa verificar os acessos necessários . Certifique-se de que nada interfira com a pesquisa e, se necessário, solicite acessos aos administradores da rede, tanto do seu próprio quanto de suas contrapartes, se você trabalhar com eles. Os administradores de rede ajudarão nas configurações de balanceamento. Certa vez, trocamos o balanceador de round-robin para ip-hash. Como resultado, todas as nossas consultas caíram na mesma frente, selecionadas pelo novo algoritmo de balanceamento.
Depois de obter acesso, você precisa depurar e verificar o script no menor fluxo de unidades.
Os próximos passos são aprovações . Primeiro, entre em contato com o serviço de segurança para que seu experimento não seja cortado na decolagem devido a "atividades suspeitas". Para avaliar todos os riscos possíveis do Conselho de Segurança, é necessário um plano detalhado de tiro - quem, o quê e em que quantidades ele está envolvido.
Em seguida, você precisa coordenar o plano de queima com os departamentos financeiro e comercial. Se o serviço estiver associado a atividades financeiras, será necessária uma coordenação com o departamento financeiro e a contabilidade. Qualquer atividade financeira adicional pode afetar as demonstrações financeiras ou até causar mau funcionamento na formação de uma variedade de resumos contábeis. Isso deve ser evitado, portanto vale a pena avisar os colegas, tendo elaborado a configuração ideal dos experimentos.
Se você tiver um departamento de estatística que acumule informações sobre a operação do serviço, precisará coordenar a filmagem com eles. O fato é que o fluxo de carga causará uma onda adicional de estatísticas. Concorde se eles levarão os testes em consideração nos relatórios ou não. Caso contrário, decida como os dados de usuários reais serão separados dos de teste.
Ao planejar, você também precisa coordenar a data e a hora dos testes com o departamento comercial, independentemente de terem anúncios ou promoções planejados para esse horário ou em torno dele. Não se esqueça de informar os líderes de equipe sobre todas as atividades planejadas e não planejadas no produto. Naturalmente, você precisa avisar e concordar com os administradores, pois durante as filmagens sua participação pode ser necessária. Além disso, são os administradores no curso sobre todas as ações no prod. Talvez na hora que você escolher, a troca de data center, a substituição do servidor ou outro trabalho esteja planejada.
Disparo e análise dos resultados
Por fim, discutimos a realização de disparos com o monitoramento. Determinamos para onde olhar durante os experimentos, sob quais condições parar e a quais sensores responder? Isso deve ser feito "em terra", antes do início das filmagens.
Existem várias razões para parar.
1) Em um sinal de monitoramento. Nesse caso, não importa se a funcionalidade envolvida no experimento é interrompida ou se ocorre uma emergência na outra extremidade do serviço. Você precisa interromper os testes e entender os motivos, porque o bom funcionamento do serviço é uma das principais prioridades.
2) Com o crescimento de erros de rede ou HTTP. Esta é uma situação de emergência que requer intervenção.
3) Se a saturação for atingida, o desempenho não aumenta mais, mas o tempo de resposta aumenta. Não há necessidade de esperar pelo colapso e colocar o prod. O resultado da análise já está lá, você pode interromper o experimento com segurança.
Após o experimento, você pode entender que não há logs e resultados suficientes e precisa repetir o experimento com o log de depuração ativado. Isso tornará o log e a gravação no disco mais pesados, mas agora você sabe o nível da carga necessária, o que significa que, em vez de um teste longo, você pode fazê-lo reduzido.
Análise de Resultados
No final, resta analisar os resultados e fornecer os dados obtidos às partes interessadas. Você pode começar a fazer isso já durante os experimentos. Utilizamos os pacotes Zabbix e Elastic com Grafana e Kibana para análise. Monitoramos as características de tempo de todas as chamadas externas e internas envolvidas em nosso experimento, monitoramos os pools de conectores, filas e o monitor de banco de dados. Para rastreamento on-line de métricas na lateral do gerador de tráfego - serviço Yandex Lunapark (existe um analógico aberto - overload.yandex.net).
A apresentação dos resultados varia de acordo com quem precisa deles. Para o desenvolvimento, administradores e testadores precisam de um relatório detalhado com métricas precisas, gráficos, logs, traços de pilha. Para os negócios, as previsões de resultados e desenvolvimento são importantes. Nesse caso, a concretude e a ênfase dos números são melhores e mais visuais. Para isso, você pode usar o princípio dos semáforos. A zona vermelha é ruim, é urgente otimizar. Amarelo - notamos uma degradação dos indicadores, você deve prestar atenção nisso. Verde - está tudo bem, siga em frente. Uma visão clara e acessível dos resultados da pesquisa ajudará a remover perguntas sobre a importância e a utilidade da medição de desempenho.
Pesquisa bem-sucedida e lembre-se da segurança do usuário!