Revisão da conferência de impacto CMG 2016

Este artigo é dedicado à conferência, realizada quase 2 anos atrás. Por que escrever sobre eventos tão antigos? Em primeiro lugar, na minha opinião, muitas pessoas não conhecem esta conferência. Em segundo lugar, minhas impressões pessoais sobre ela são tão fortes mesmo depois de dois anos que simplesmente não consigo deixar de compartilhá-las. Em terceiro lugar, eu realmente queria escrever, mas não estava muito claro como fazê-lo, já que nunca havia escrito críticas antes, esta é a minha terceira tentativa de escrever sobre esta conferência. E, é claro, quero agradecer à empresa Distillery, na qual trabalhei na época, e ao meu supervisor Sergei Meshcheryakov pela oportunidade de participar desta conferência.



A conferência internacional de impacto do CMG é realizada anualmente pela Associação Americana de Especialistas na área de melhoria do desempenho de sistemas de TI. A conferência anual do CMG é realizada desde 1980.

A conferência é dedicada à engenharia de desempenho e planejamento de capacidade. Os organizadores, palestrantes e participantes da conferência são especialistas altamente qualificados em TI ou no campo de planejamento de capacidade, muitos dos quais começaram a trabalhar em mainframes, depois foram para sistemas distribuídos e atualmente continuam trabalhando em empresas líderes do setor. A qualificação de muitos deles é incrível. Havia empresas ou seus representantes na conferência relacionados ao monitoramento ou teste do desempenho de Dynatrace, NewRelic, Soasta, Jmeter, BMC, Moviri, BezNext e muitos outros.

Na conferência, foram apresentados 120 relatórios de mais de 15 países do mundo, principalmente dos EUA, Canadá e países europeus. Foi realizado por cinco dias, de 7 a 11 de novembro de 2016. O modo de operação foi o seguinte: os relatórios na sessão plenária começaram a partir das 8:00 da manhã e continuaram com os relatórios seccionais em 8 salas até as 19:00 da noite, com uma pequena pausa para o almoço ao meio-dia. Cada dia útil da conferência terminava com um buffet geral, durante o qual era possível se comunicar pessoalmente com todos os palestrantes e discutir os relatórios apresentados. Foi bastante difícil escolher qual relatório assistir, pois em sessões paralelas os relatórios de interesse estavam simultaneamente em salas diferentes.

Neste artigo, descreverei brevemente os relatórios que mais gostei.

A Associação Americana de Especialistas em Melhoria do Desempenho do Grupo de Gerenciamento de Computadores de Sistemas de TI, em 1974, estabeleceu o Prêmio Abraham Michelson anual por sua contribuição profissional na avaliação do desempenho do sistema. Este prêmio é tradicionalmente concedido na conferência de impacto do CMG.

Abertura e apresentação do Michelson Award AA

A conferência foi aberta com o Prêmio Andrei Bondi AA Michelson, consultor independente, autor de Fundamentos de Engenharia de Software e Desempenho de Sistemas: Processo, Modelagem de Desempenho, Requisitos, Testes, Escalabilidade e Prática.
A primeira sessão plenária começou com um relatório de Andre Bondi. A idéia principal do relatório era que o ajuste nunca levaria a melhorias de desempenho às vezes. Segundo o autor do relatório, o maior aumento de produtividade pode ser obtido com a eliminação de erros de arquitetura no sistema. Eu acho que muitos de vocês sabem disso por experiência pessoal. Ao longo da minha carreira, cheguei à mesma conclusão. Por exemplo, mudar de um sistema aparentemente mais produtivo para um sistema de código-fonte mais modesto pode aumentar o desempenho se, durante a transferência, a equipe eliminar os erros de arquitetura da versão anterior do sistema.

Alcançando escalabilidade e desempenho> 1 milhão de usuários simultâneos ao mesmo tempo
Lukas Sliwka, Grindr

A próxima apresentação interessante para mim foi o relatório deles. Diretor da Grindr, Lucas Cream. Grindr é um aplicativo de namoro online. Lukash falou simultaneamente sobre a transformação da empresa e a cultura de desenvolvimento (eles mudaram para o scrum) e sobre a transformação técnica do sistema. A Grindr possui mais de 2,5 milhões de usuários, dos quais 1 milhão está ativo. Os principais usuários antes da conversão estavam nos EUA e no Canadá. Ao se afastarem dos EUA, o número de usuários diminuiu.



Servidores e data warehouses também estavam localizados principalmente nos EUA. Além disso, o aplicativo já foi movido para o servidor mais poderoso possível na hospedagem e a empresa enfrenta o grave problema de otimização e dimensionamento. O problema de otimização e dimensionamento foi resolvido radicalmente - a equipe reescreveu completamente o projeto inteiro, do Ruby on Rails ao Scala, levou seis meses. O Scala foi escolhido por dois motivos: primeiro, foi possível escrever código limpo com bom desempenho; em segundo lugar, os desenvolvedores Java estavam mais disponíveis para contratação, ao contrário dos desenvolvedores do Node.js. que eram caros e trabalhavam no Facebook.

A experiência interessante do Grindr prova que, para o desenvolvimento bem-sucedido, às vezes você precisa de uma nova arquitetura. Em seguida, foi feita uma análise da duração da resposta no contexto de cada país e verificou-se que quanto mais longa a resposta, menos usuários nesse país. A equipe de desenvolvimento otimizou o tempo de resposta, reduzindo-o significativamente usando a CDN e distribuindo o data warehouse em servidores em nuvem com centros na Europa, Ásia e América Latina. Depois que os problemas de desempenho foram resolvidos, o número de usuários do aplicativo aumentou em todo o mundo. Este exemplo prova uma relação direta entre tempos de resposta curtos e o número de usuários.

A segunda parte do relatório foi dedicada ao gerenciamento de equipes. Grindr trabalha no Scrum. A separação das equipes é feita por produto, ou seja, cada equipe é totalmente responsável por algum serviço ou produto para o usuário e pelo valor comercial que o usuário recebe. A empresa é uma empresa orientada por métricas e cada equipe tem suas próprias métricas e KPIs que devem atingir. O gerenciamento de nível intermediário está completamente ausente. A empresa possui uma estrutura plana e a equipe decide o que precisa ser feito e como atingir seus objetivos. Os relatórios de Lukash estão no YouTube . A entrevista de Lucas está disponível aqui .

Sua capacidade está disponível?
Igor Trubin, Capital One Bank

É interessante que o autor tenha iniciado seu relatório com informações de que o banco Capital One decidiu se tornar uma empresa informada e aberta. É sabido que os bancos geralmente não falam sobre tecnologias e processos. Utilizado em seu trabalho, considerando essas informações confidenciais. No entanto, no mundo moderno, para concorrer com os principais especialistas e seus talentos, que geralmente funcionam no Google e no Facebook, os bancos precisam ser mais abertos.

O relatório foi dedicado a avaliar a combinação de disponibilidade do sistema e sua margem de desempenho. Como ninguém precisa de largura de banda que não pode ser usada.

Igor descreve uma forma específica de como você pode medir sua capacidade e sua disponibilidade. Ele possui métricas como o tempo médio entre quedas, o tempo médio de recuperação, o tempo de inatividade por um ano e outros. O Igor fornece uma fórmula com a qual você pode calcular a disponibilidade de toda a sua infraestrutura para os usuários. Você pode ver o relatório dele em mais detalhes.

Planejamento da capacidade da experiência digital
Amy Spellmann e Richard Gimark

Palestra sobre planejamento para métricas de negócios da IoT, métricas de TI e métricas de instalações.

Um relatório sobre o fato de que muitas infraestruturas agora estão trabalhando perto do limite de sua largura de banda e o que acontecerá quando a IoT funcionar em qualquer lugar. Para mim, o mais interessante no relatório foi sua escala. Ou seja, existem profissionais que planejam o site, a organização e esse é um setor inteiro. Quantas vezes chegamos a uma visão em larga escala?

Garantia de desempenho empresarial com base na análise BigData
Boris Zibitsker

Boris fala sobre o BigData e aborda o trabalho com big data. Ele identifica os seguintes estágios do trabalho com dados. Análise preditiva, como uma empresa deve tomar decisões com base nos dados atuais. Tempo é dinheiro e nada mudou ao longo dos anos, exceto que o tempo se tornou ainda mais caro agora. A informação é cara se for relevante.
Trabalhar com clusters de big data permite que você forneça as análises necessárias dentro do prazo. Boris então descreve os passos. Duas abordagens principais são a análise de dados em tempo real em um fluxo ou a coleta no DataLake.

O relatório descreve a abordagem do uso de algoritmos de processamento de big data e aprendizado de máquina para conduzir RCA em caso de falhas, além de criar previsões baseadas nesses relatórios sobre o comportamento adicional do sistema.

Um ponto importante é verificar a confiabilidade dos resultados, comparando o comportamento real com o previsto.

Os 10 principais defeitos de desempenho que custam milhões às organizações on-line
Craig Hyde, Rigor e Rigor

Craig descreve os 10 erros mais caros que afetam o desempenho do site. Craig cita números de que, em média, uma empresa perde US $ 102 milhões em potencial por 1 segundo de espera do usuário. Interessante, hein? A empresa fez uma análise de cerca de 500 sites e compilou os 10 principais problemas que levam a um desempenho ruim. As recomendações de Craig sobre o uso de caches, CDNs, configuração da resolução de imagem correta, usando compactação. Mas o principal é testar o que aconteceu, como se viu, muitas pessoas pensam que usam o cache, mas cerca de 70% do conteúdo pode não ser armazenado em cache devido a configurações incorretas. Craig recomenda definir uma linha de base de desempenho e cumpri-la, definindo uma meta de desempenho para atingir, testar e otimizar gargalos. Teste ferramentas teste de página da web, google analytics, velocidade da página, relatório sem rigor. As mais divertidas para mim foram as imagens em sites em uma grande extensão, enquanto o tamanho não me permite avaliar isso; portanto, uma diminuição na resolução não leva a uma deterioração na qualidade.

Não consegui encontrar os slides de Craig, mas aqui está um relatório sobre o mesmo tópico de um dos funcionários da empresa.

Negócio arriscado
Jeff Buzen

Algumas palavras sobre Jeff - ele é professor de Harvard, autor de 3 livros, o primeiro foi publicado em 71 e o último em 2015 - Repensando a aleatoriedade: uma nova fundação para modelagem estocástica, artigo da wiki , Entrevista com Jeff .

Relatório sobre modelagem e desempenho de previsão. Jeff descreve os riscos que surgem ao modelar um sistema - risco do modelo, risco dos parâmetros de carga do sistema, risco previsto, risco do aplicativo, risco de uso - no trabalho. Jeff descreve detalhadamente todos os riscos possíveis que surgem ao modelar o sistema e tenta prever quantos recursos serão necessários e que tipo de disponibilidade do sistema é necessário. Opções, pois não é necessário gravar o SLA - 90% das solicitações são executadas em 0,5 segundos. Menos arriscado - a duração da fila é inferior a 33x90% do tempo. O livro dele é sobre isso. A previsão que usamos da matemática clássica nem sempre fornece os resultados corretos aplicáveis, embora as fórmulas possam estar corretas. As previsões são muito dependentes das suposições do modelo. É mais preferível usar uma previsão baseada em uma análise de alternativas (AoA, Analysis of Alternatives).

Eu sentei e pensei - até que ponto isso está da minha experiência - oh, ainda temos uma margem de produtividade em duas vezes, o que? Como você descobriu? Bem, houve um pico e as filas já estavam se acumulando no sistema, vamos pegar um servidor maior. O que dizer Bem, quais são as linhas? Bem, antes de começarmos a usá-los, o sistema simplesmente caiu. Aqui está uma abordagem de planejamento de desempenho que começa com um modelo de sistema - em algum outro planeta.

Como obter valor do BigData?
Renato Bonomini, Stefano Doni, Moviri

Em seguida foi uma oficina da Moviri . A Moviri é uma empresa fundada por um professor da Universidade Politécnica de Milão, com escritórios em Milão e Boston, especializada em análise de desempenho e produtividade. Sobre o quão importante é não apenas coletar muitos dados, mas também se beneficiar deles. Fio da pilha, HDFS, porco, colmeia, faísca, tratador, Cassandra, Cloudera, Kubernetes. O relatório mostrou o quanto mais conveniente se tornou trabalhar com a mudança de desempenho com sistemas em execução em contêineres.

Moviri me convidou para o meu escritório, do qual aproveitei, pois cerca de um mês depois fui para a Itália. Foi ótimo conhecer Stefano Doni e conhecer Luca Forni, ver o escritório e conversar sobre tudo relacionado à análise de desempenho, começando com a análise de desempenho e terminando com os problemas que os consultores encontram ao se comunicar com a equipe do cliente.

Moviri Blog .

Desempenho ou capacidade? Abordagens diferentes para tarefas diferentes
Alexander Gilgur, Facebook

O relatório será útil para aqueles que estão envolvidos na previsão de desempenho e planejamento de largura de banda. Alexander dá exemplos e abordagens que devem ser usados ​​para cada um dos casos. Em geral, embora os conceitos de capacidade e desempenho sejam próximos, métodos diferentes devem ser usados ​​para previsões, com ênfase no objetivo final do trabalho. Por que estamos fazendo isso? Queremos entender a quantidade de equipamentos que precisamos e qual largura de banda queremos fornecer ou queremos prever o desempenho do sistema.

Aqui você pode ler o artigo de Alexander .
Slides .

Como começar quando você não sabe por onde começar.
Justin Martin, Cerner

Sobre por que, em geral, é necessário fazer o monitoramento de desempenho. Mas a verdade é! Muitos vivem sem monitoramento e tudo parece estar bem com eles. De fato, muitos não precisam disso. Até que eles publiquem um artigo sobre seu site maravilhoso no hub, e as pessoas não vão até eles para ver o que está lá. Ou até que algo mais não leve a muitos, muitos usuários.



No relatório, Justin diz simplesmente o que pode ser feito para começar. Gerenciamento de capacidade em 90 dias

Passos

1. Determinar horários de pico para o seu sistema
2. Examine os limites de desempenho do seu projeto (o momento em que o sistema já interrompe o processamento de solicitações e o desempenho começa a diminuir)
3. Reduza as perdas de produtividade
4. Equilibre a necessidade - talvez você possa transferir algumas cargas do horário de pico para os menos ocupados.

Linkedin Justin . Os slides podem ser vistos no artigo sobre a conferência, que publicarei no final.

Balanceamento de carga dinâmico e entrega contínua de serviços em uma grande infraestrutura de nuvem
Yuri Ardulov, RingCentral

Yuri descreve a transição do RingCentral de um monólito, com um código legado para microsserviços. Os problemas com o código monolítico eram que era difícil alterar a configuração, não era possível fazer entrega contínua, dificuldades em atingir os indicadores de disponibilidade necessários, não havia como fazer o teste A \ B, a capacidade de aplicar novas funcionalidades apenas para alguns usuários. O sistema foi redesenhado e contêineres e microsserviços foram utilizados no novo design, tornou-se possível redimensionar o sistema on-line, a capacidade de alterar a versão do serviço sem alterar a configuração. Na arquitetura de microsserviço, uma camada de roteamento de aplicativo, uma camada de balanceamento e uma camada de serviço (não armazena o estado) foram alocadas. Após fazer alterações nas operações, as equipes puderam realizar entregas contínuas em tempo real, a disponibilidade do sistema aumentou de 4 para 99.998. O tempo necessário para aumentar o sistema e implantar novos servidores foi reduzido para 4 horas.

Evitando custos, atrasos e liberações com falha com o Lifecycle Virtualization
Todd DeCapua, serviços de marca digital da CSC

O relatório de Tod concentra-se em como reduzir os problemas de versão e a idéia principal é que, ao testar um programa, é importante considerar todo o ciclo de vida do programa.

4 componentes principais:

1. Usuários - virtualização de usuários simulando o comportamento dos usuários reais do sistema.
2. Serviços - deve haver uma virtualização de serviços para que você possa verificar a operação de todo o processo do início ao fim.
3. Rede - emulação das condições operacionais da rede.
4. Dados - virtualização de dados com uma venda para simular chamadas de aplicativos próximas ao que acontecerá na realidade.

Com base na minha experiência, uma grande porcentagem de erros durante a implantação se deve ao fato de poucas pessoas cumprirem todas as quatro condições, e o produto sempre tem algo que ninguém esperava ver, e isso interrompe o lançamento. É muito importante usar diferentes casos de uso com vendas de acordo com dados e comportamento do usuário.

Aqui está um exemplo da apresentação de Tod:





Tod - Autor de um livro sobre otimização de desempenho, testes de desempenho e sua interpretação.

O livro mostra o quão importante é a cultura de teste de desempenho em uma organização, como ela pode ser trazida se ninguém estiver fazendo isso agora. Vários exemplos da prática são dados com uma descrição da tarefa que a equipe enfrenta, opções para resolvê-la, qual abordagem a equipe escolheu e quais foram as consequências no sistema real. Na minha opinião, muitas vezes essas histórias mostram como é difícil prever o comportamento do usuário final e como é importante criar um pequeno grupo de foco com um número finito de usuários e ver como sua previsão corresponde ao comportamento do grupo de foco.

Implementando DevOps orientado a métricas: por que e como!
Andreas Grabner, Dynatrace

Relatório de Andreas Grabner sobre as práticas de DevOps em diferentes empresas e por que o curto espaço de tempo no mercado é importante. Andreas usou uma metáfora muito interessante sobre fotografia. Muitas pessoas se lembram de fotos de filmes - você tira uma foto, desenvolve, imprime e vê que não tem êxito, mas você não tem a oportunidade de tirar a foto novamente, já que está no momento errado.

Agora tudo está diferente - você tira uma foto, coloca no Instagram e obtém feedback imediatamente e pode terminar algo do que seus assinantes pedem. Você ainda está no momento e obtém uma reação em tempo real.

Agora, voltando ao software - como era antes - novos recursos de software foram planejados, implementados, testados e realizados, por exemplo, 1 versão por ano. E eles entenderam que a funcionalidade que gastava muito dinheiro e esforço era necessária para dois dos milhões de usuários. Isso aconteceu com você?

Como está agora? O Agile e a capacidade de fazer lançamentos pelo menos todos os dias, como o Facebook, é a capacidade de avaliar imediatamente o quanto essa funcionalidade é demandada pelos usuários, se ela precisa ser ponderada com riachos ou se é melhor jogá-la fora imediatamente e não perder tempo e energia.

, Scrum Agile! enterprise 3 ,



, , DevOps, . , . , , . performance advocate .
.

Performance Testing in New Contexts
(Eric Proegler), Soasta

2000, , . , TV , . , 20 , 50 . BlazeMeter (Jmeter), Selenium, Gatling, Grinder. , . (Tableau) , , . , . .

Os slides de Eric podem ser visualizados no compartilhamento de slides.

Eric é o autor do blog .

Além dos relatórios apresentados na conferência, várias discussões também foram organizadas na forma de uma “Mesa Redonda”. Vários especialistas condenaram o tópico no formato de um diálogo ativo e animado com o público. Na minha opinião, este é um formato muito interessante, pois os participantes da conferência podem compartilhar sua experiência muitas vezes impressionante, e pode-se conversar com cada especialista e participante, discutindo questões de interesse.

Conversas offtopic e nos bastidores

Uma parte especial das minhas impressões sobre a conferência é a comunicação informal com palestrantes e participantes. Graças ao formato de discussões, jantares, mesas redondas e recepções, você pode conhecer pessoas de todo o mundo de diferentes empresas e trocar experiências. Muita comunicação dentro da conferência. As pessoas são muito abertas e dispostas a compartilhar experiências.

Eu também gostaria de mencionar Debbie Sheetz. Debbie trabalhou na BMC e começou sua análise de desempenho em mainframes. Então ela mudou para sistemas distribuídos. Sua experiência em monitoramento é vasta e muito interessante.

Também tive a sorte de conversar com Anush Najarian, do MathWorks, cuja experiência também merece atenção.

Infelizmente, o número de relatórios não permite a visita de todos eles e os relatórios não são mantidos, ou seja, não há como analisá-los em casa. Os organizadores usam os artigos para selecionar palestrantes, e esses artigos são repassados ​​aos participantes da conferência, mas não há materiais dos palestrantes convidados na coleção.

Aqui está o artigo de Anush sobre a conferência .

O impacto do CMG é uma conferência muito útil e interessante, com uma atmosfera fantástica de compartilhamento de experiências, que eu recomendo participar.