Oi!
Meu nome é Mikhail, sou vice-diretor de TI da empresa Sportmaster. Quero compartilhar a história de como lidamos com os desafios que surgiram durante a pandemia.
Nos primeiros dias da nova realidade, o habitual formato de negociação offline do Sportmaster congelou e a carga no nosso canal online, principalmente em termos de entrega na morada do cliente, aumentou 10 vezes. Em apenas algumas semanas, transformamos um gigantesco negócio offline em online e adaptamos o serviço às necessidades dos nossos clientes.
Basicamente, o que era essencialmente a nossa operação paralela tornou-se o nosso negócio principal. A importância de cada pedido online aumentou extremamente. Foi preciso economizar cada rublo que o cliente trouxe para a empresa.
Para responder rapidamente às solicitações dos clientes, abrimos um contact center adicional na sede da empresa, que agora pode receber cerca de 285 mil ligações por semana. Ao mesmo tempo, migramos 270 lojas para um novo formato de operação sem contato e seguro, que permitiu aos clientes receberem pedidos e aos funcionários manterem seus empregos.
Durante o processo de transformação, encontramos dois problemas principais. Em primeiro lugar, a carga sobre os nossos recursos online aumentou significativamente (Sergey lhe contará como lidamos com isso). Em segundo lugar, o fluxo de operações raras (pré-COVID) aumentou muitas vezes, o que, por sua vez, exigiu uma grande automação rápida. Para resolver esse problema, tivemos que transferir rapidamente recursos de áreas que antes eram as principais. Elena lhe contará como lidamos com isso.
Operação de serviços online
Kolesnikov Sergey, responsável pela operação da loja online e microsserviços
A partir do momento em que nossas lojas de varejo começaram a fechar para visitantes, começamos a registrar um aumento em métricas como o número de usuários, o número de pedidos feitos em nosso aplicativo e o número de solicitações aos aplicativos.
Número de pedidos de 18 a 31 de marçoNúmero de solicitações para microsserviços de pagamento onlineNúmero de pedidos feitos no site
No primeiro gráfico vemos que o aumento foi de aproximadamente 14 vezes, no segundo - 4 vezes. Consideramos a métrica de tempo de resposta de nossas aplicações a mais indicativa.
Neste gráfico vemos a resposta das frentes e aplicações, e para nós mesmos determinamos que não notamos nenhum crescimento propriamente dito.
Isto deve-se principalmente ao facto de termos iniciado os trabalhos preparatórios no final de 2019. Agora que os nossos serviços estão reservados, a tolerância a falhas é garantida ao nível dos servidores físicos, sistemas de virtualização, dockers e serviços neles contidos. Ao mesmo tempo, a capacidade dos recursos do nosso servidor nos permite suportar múltiplas cargas.
A principal ferramenta que nos ajudou nessa história toda foi o nosso sistema de monitoramento. É verdade que até muito recentemente não tínhamos um sistema único que nos permitisse recolher métricas em todas as camadas, desde o nível de equipamento físico e hardware até ao nível das métricas de negócio.
Formalmente, havia acompanhamento na empresa, mas via de regra era disperso e ficava na área de responsabilidade de departamentos específicos. Na verdade, quando ocorria um incidente, quase nunca tínhamos um entendimento comum sobre o que exatamente aconteceu, não havia comunicação e muitas vezes isso levava a correr em círculos para encontrar e isolar o problema para que pudesse ser resolvido.
Em algum momento, pensamos e decidimos que já estávamos fartos de suportar isso - precisávamos de um sistema unificado para ver o quadro completo. As principais tecnologias incluídas em nossa pilha são Zabbix como centro de alertas e armazenamento de métricas, Prometheus para coleta e armazenamento de métricas de aplicativos, Stack ELK para registro e armazenamento de dados de todo o sistema de monitoramento, bem como Grafana para visualização, Swagger, Docker e outras coisas úteis e familiares para você.
Ao mesmo tempo, utilizamos não apenas tecnologias disponíveis no mercado, mas também desenvolvemos algumas próprias. Por exemplo, fazemos serviços de integração de sistemas entre si, ou seja, algum tipo de API para coleta de métricas. Além disso, estamos trabalhando em nossos próprios sistemas de monitoramento - no nível das métricas de negócios, usamos testes de UI. E também um bot no Telegram para avisar as equipes.
Também estamos tentando tornar o sistema de monitoramento acessível às equipes para que possam armazenar e trabalhar de forma independente com suas métricas, incluindo a configuração de alertas para algumas métricas restritas que não são amplamente utilizadas.
Em todo o sistema, buscamos a proatividade e a localização de incidentes o mais rápido possível. Além disso, o número de nossos microsserviços e sistemas cresceu significativamente recentemente e o número de integrações também cresceu. E no âmbito da otimização do processo de diagnóstico de incidentes ao nível da integração, estamos a desenvolver um sistema que permite realizar verificações intersistemas e visualizar o resultado, o que permite encontrar os principais problemas associados à importação e interação de sistemas com uns aos outros.
É claro que ainda temos espaço para crescer e desenvolver em termos de sistemas operacionais, e estamos trabalhando ativamente nisso. Você pode ler mais sobre nosso sistema de monitoramento .
Testes técnicos
Orlov Sergey, dirige o centro de competência para desenvolvimento web e móvel
Desde o início do encerramento das lojas físicas, enfrentámos vários desafios do ponto de vista do desenvolvimento. Em primeiro lugar, o aumento da carga como tal. É claro que se as medidas adequadas não forem tomadas, quando uma carga elevada é aplicada ao sistema, ele pode se transformar em uma abóbora com um estrondo triste, ou degradar completamente o desempenho, ou até mesmo perder sua funcionalidade.
O segundo aspecto, um pouco menos óbvio, é que o sistema sob alta carga teve que ser alterado muito rapidamente, adaptando-se às mudanças nos processos de negócio. Às vezes, várias vezes ao dia. Muitas empresas têm como regra que, se houver muita atividade de marketing, não há necessidade de fazer alterações no sistema. Nenhum, deixe funcionar enquanto funcionar.
E tivemos essencialmente uma Black Friday interminável, durante a qual foi necessário mudar o sistema. E qualquer erro, problema ou falha no sistema custaria muito caro para o negócio.
Olhando para o futuro, direi que conseguimos lidar com esses testes, todos os sistemas resistiram à carga, foram facilmente dimensionados e não tivemos nenhuma falha técnica global.
Existem quatro pilares sobre os quais repousa a capacidade do sistema de suportar altas cargas de sobretensões. O primeiro deles é o monitoramento, sobre o qual você leu acima. Sem um sistema de monitoramento integrado, é quase impossível encontrar gargalos no sistema. Um bom sistema de monitoramento é como a roupa de casa: deve ser confortável e feito sob medida para você.
O segundo aspecto é o teste. Levamos esse ponto muito a sério: escrevemos unidades clássicas, testes de integração, testes de carga e muitos outros para cada sistema. Também estamos escrevendo uma estratégia de testes e, ao mesmo tempo, tentando aumentar o nível de testes a ponto de não precisarmos mais de verificações manuais.
O terceiro pilar é o Pipeline CI/CD. Os processos de construção, teste e implantação de um aplicativo devem ser automatizados tanto quanto possível; não deve haver intervenção manual. O tópico CI/CD Pipeline é bastante profundo e irei abordá-lo apenas brevemente. Vale apenas ressaltar que possuímos um checklist de Pipeline de CI/CD, que cada equipe de produto passa com o auxílio de centros de competência.
E aqui está a lista de verificação
Dessa forma, muitos objetivos são alcançados. Este é o controle de versão da API e a alternância de recursos para evitar o trem de lançamento e alcançar a cobertura de vários testes em um nível tal que os testes sejam totalmente automatizados, as implantações sejam perfeitas e assim por diante.
O quarto pilar são princípios arquitetônicos e soluções técnicas. Podemos falar muito sobre arquitetura por muito tempo, mas quero enfatizar alguns princípios nos quais gostaria de focar.
Primeiro, você precisa escolher ferramentas especializadas para tarefas específicas. Sim, parece óbvio e é claro que os pregos devem ser cravados com um martelo e os relógios de pulso devem ser desmontados com chaves de fenda especiais. Mas em nossa época, muitas ferramentas buscam a universalização para cobrir o segmento máximo de usuários: bancos de dados, caches, frameworks e o resto. Por exemplo, se você usar o banco de dados MongoDB, ele funcionará com transações de vários documentos, e o banco de dados Oracle funcionará com JSON. E parece que tudo pode servir para tudo. Mas se defendemos a produtividade, então precisamos compreender claramente os pontos fortes e fracos de cada ferramenta e usar as que precisamos para a nossa classe de tarefas.
Em segundo lugar, ao conceber sistemas, cada aumento de complexidade deve ser justificado. Devemos ter isso constantemente em mente; o princípio do baixo acoplamento é conhecido por todos. Acredito que deve ser aplicado ao nível de um serviço específico, e ao nível de todo o sistema, e ao nível da paisagem arquitectónica. A capacidade de dimensionar horizontalmente cada componente do sistema ao longo do caminho de carga também é importante. Se você tiver essa habilidade, o dimensionamento não será difícil.
Falando em soluções técnicas, pedimos às equipes de produto que preparassem um novo conjunto de recomendações, ideias e soluções, que implementaram em preparação para a próxima onda de carga de trabalho.
Keshi
É necessário abordar conscientemente a escolha de caches locais e distribuídos. Às vezes faz sentido usar ambos dentro do mesmo sistema. Por exemplo, temos sistemas em que alguns dos dados são essencialmente um cache de demonstração, ou seja, a fonte de atualizações está localizada atrás do próprio sistema e os sistemas não mudam. esses dados. Para esta abordagem usamos Caffeine Cache local.
E há dados que o sistema altera ativamente durante a operação, e aqui já estamos usando um cache distribuído com Hazelcast. Essa abordagem nos permite usar os benefícios de um cache distribuído onde eles são realmente necessários e minimizar os custos de serviço de circulação de dados do cluster Hazelcast onde podemos passar sem eles. Escrevemos muito sobre caches. и .
Além disso, mudar o serializador para Kryo no Hazelcast nos deu um bom impulso. E a transição do ReplicatedMap para o IMap + Near Cache no Hazelcast nos permitiu minimizar a movimentação de dados no cluster.
Um pequeno conselho: no caso de invalidação do cache em massa, às vezes é aplicável a tática de aquecer o segundo cache e depois mudar para ele. Parece que com esta abordagem deveríamos obter o dobro do consumo de memória, mas na prática, nos sistemas onde isso foi praticado, o consumo de memória diminuiu.
Pilha reativa
Usamos a pilha reativa em um grande número de sistemas. No nosso caso, é Webflux ou Kotlin com corrotinas. A pilha reativa é especialmente boa onde esperamos operações lentas de entrada-saída. Por exemplo, chamadas para serviços lentos, trabalhando com o sistema de arquivos ou sistemas de armazenamento.
O princípio mais importante é evitar o bloqueio de chamadas. As estruturas reativas têm um pequeno número de threads de serviço ativos em execução nos bastidores. Se nos permitirmos descuidadamente fazer uma chamada de bloqueio direta, como uma chamada de driver JDBC, o sistema simplesmente parará.
Tente transformar erros em sua própria exceção de tempo de execução. O fluxo real de execução do programa muda para estruturas reativas e a execução do código torna-se não linear. Como resultado, é muito difícil diagnosticar problemas usando rastreamentos de pilha. E a solução aqui seria criar exceções de tempo de execução claras e objetivas para cada erro.
ElasticSearch
Ao usar o Elasticsearch, não selecione dados não utilizados. Este, em princípio, também é um conselho muito simples, mas na maioria das vezes é isso que é esquecido. Se precisar selecionar mais de 10 mil registros por vez, você precisará usar Scroll. Para usar uma analogia, é um pouco como um cursor em um banco de dados relacional.
Não use o postfilter, a menos que seja necessário. Com grandes dados na amostra principal, esta operação carrega bastante o banco de dados.
Use operações em massa quando aplicável.
API
Ao projetar uma API, inclua requisitos para minimizar os dados transmitidos. Isto é especialmente verdade no que diz respeito à frente: é nesta junção que vamos além dos canais dos nossos data centers e já estamos trabalhando no canal que nos conecta ao cliente. Se houver o menor problema, muito tráfego causará uma experiência negativa ao usuário.
E por último, não jogue fora um monte de dados, seja claro sobre o contrato entre consumidores e fornecedores.
Transformação organizacional
Eroshkina Elena, vice-diretora de TI
No momento em que aconteceu a quarentena e surgiu a necessidade de aumentar drasticamente o ritmo de desenvolvimento online e introduzir serviços omnicanal, já estávamos em processo de transformação organizacional.
Parte da nossa estrutura foi transferida para funcionar de acordo com os princípios e práticas da abordagem de produto. Foram formadas equipes que agora são responsáveis pela operação e desenvolvimento de cada produto. Os funcionários dessas equipes estão 100% envolvidos e estruturam seu trabalho usando Scrum ou Kanban, dependendo do que lhes for preferível, configurando um pipeline de implantação, implementando práticas técnicas, práticas de garantia de qualidade e muito mais.
Por sorte, a maior parte de nossas equipes de produtos estava na área de serviços online e omnicanal. Isso nos permitiu mudar para o modo de trabalho remoto no menor tempo possível (sério, literalmente em dois dias) sem perda de eficiência. O processo personalizado permitiu-nos adaptar-nos rapidamente às novas condições de trabalho e manter um ritmo bastante elevado de entrega de novas funcionalidades.
Além disso, precisamos fortalecer as equipes que estão na fronteira dos negócios online. Naquele momento ficou claro que só poderíamos fazer isso com recursos internos. E cerca de 50 pessoas em duas semanas mudaram a área onde trabalhavam antes e se envolveram no trabalho de um produto que era novo para elas.
Isso não exigiu nenhum esforço especial de gestão, pois além da organização do nosso próprio processo, do aprimoramento técnico do produto e das práticas de garantia de qualidade, ensinamos nossas equipes a se auto-organizarem - a gerenciar seu próprio processo produtivo sem envolver recursos administrativos.
Conseguimos concentrar os nossos recursos de gestão exatamente onde eram necessários naquele momento - na coordenação em conjunto com o negócio: O que é importante para o nosso cliente neste momento, que funcionalidades devem ser implementadas primeiro, o que precisa de ser feito para aumentar a nossa capacidade de produção para entregar e processar pedidos. Tudo isto e um modelo claro permitiram durante este período carregar os nossos fluxos de valor de produção com o que é realmente importante e necessário.
É claro que com o trabalho remoto e o ritmo acelerado de mudanças, quando os indicadores do negócio dependem da participação de todos, não se pode confiar apenas nos sentimentos internos da série “Está tudo indo bem conosco? Sim, parece bom. São necessárias métricas objetivas do processo de produção. Nós os temos, estão à disposição para qualquer pessoa interessada nas métricas das equipes de produto. Em primeiro lugar, a própria equipa, o negócio, os subcontratados e a gestão.
Quinzenalmente é feito um status com cada equipe, onde são analisadas métricas durante 10 minutos, são identificados gargalos no processo produtivo e desenvolvida uma solução conjunta: o que pode ser feito para eliminar esses gargalos. Aqui você pode pedir imediatamente ajuda à gestão caso algum problema identificado esteja fora da zona de influência das equipes, ou da expertise de colegas que já tenham encontrado um problema semelhante.
Porém, entendemos que para acelerar múltiplas vezes (e é exatamente essa a meta que estabelecemos para nós mesmos), ainda precisamos aprender muito e implementá-la no nosso dia a dia. No momento, continuamos a expandir nossa abordagem de produto para outras equipes e novos produtos. Para fazer isso, tivemos que dominar um novo formato para nós - uma escola online de metodologistas.
Os metodologistas, pessoas que ajudam as equipes a construir um processo, estabelecer comunicações e melhorar a eficiência do trabalho, são essencialmente agentes de mudança. No momento, os formandos do nosso primeiro grupo estão trabalhando com equipes e ajudando-as a ter sucesso.
Penso que a situação actual nos abre oportunidades e perspectivas das quais talvez nós próprios ainda não tenhamos plena consciência. Mas a experiência e a prática que estamos a adquirir neste momento confirmam que escolhemos o caminho certo de desenvolvimento, não perderemos estas novas oportunidades no futuro e seremos capazes de responder com a mesma eficácia aos desafios que a Sportmaster irá enfrentar.
Descobertas
Durante este período difícil, formulamos os princípios básicos sobre os quais se baseia o desenvolvimento de software, que, creio, serão relevantes para todas as empresas que lidam com este assunto.
Pessoas. É nisso que tudo se baseia. Os funcionários devem gostar do seu trabalho e compreender os objetivos da empresa e os objetivos dos produtos nos quais trabalham. E, claro, poderiam se desenvolver profissionalmente.
Технология. É necessário que a empresa adote uma abordagem madura para trabalhar com sua pilha de tecnologia e construa competências onde elas são realmente necessárias. Parece muito simples e óbvio. E muitas vezes ignorado.
Процессы. É importante organizar adequadamente o trabalho das equipes de produto e centros de competência, para estabelecer interação com o negócio para trabalhar com ele como parceiro.
Em geral, foi assim que sobrevivemos. A tese principal do nosso tempo foi confirmada mais uma vez, com um retumbante clique na testa
Mesmo que você tenha um grande negócio offline com muitas lojas e várias cidades onde opera, desenvolva seu negócio online. Este não é apenas um canal de vendas adicional ou um lindo aplicativo através do qual você também pode comprar algo (e também porque os concorrentes também têm lindos). Este não é um pneu sobressalente para ajudá-lo a enfrentar a tempestade.
Esta é uma necessidade absoluta. Para o qual devem estar preparadas não só as suas capacidades técnicas e infra-estruturas, mas também as suas pessoas e processos. Afinal, você pode comprar rapidamente memória adicional, espaço, implantar novas instâncias, etc. em algumas horas. Mas as pessoas e os processos precisam estar preparados para isso com antecedência.
Fonte: habr.com