Ola!
Chámome Mikhail, son o subdirector de TI da empresa Sportmaster. Quero compartir a historia de como afrontamos os retos que xurdiron durante a pandemia.
Nos primeiros días das novas realidades, o formato habitual de negociación fóra de liña de Sportmaster conxelouse e a carga na nosa canle en liña, principalmente en termos de entrega ao enderezo do cliente, aumentou 10 veces. En só unhas semanas, transformamos un xigantesco negocio offline nun negocio online e adaptamos o servizo ás necesidades dos nosos clientes.
Basicamente, o que era esencialmente a nosa operación paralela converteuse no noso negocio principal. A importancia de cada pedido en liña aumentou moito. Era necesario gardar cada rublo que o cliente trouxo á empresa.
Para responder rapidamente ás solicitudes dos clientes, abrimos un centro de contacto adicional na oficina principal da empresa e agora podemos recibir unhas 285 mil chamadas á semana. Ao mesmo tempo, trasladamos 270 tendas a un novo formato operativo sen contacto e seguro, que permitiu aos clientes recibir pedidos e aos empregados manter os seus postos de traballo.
Durante o proceso de transformación, atopamos dous problemas principais. En primeiro lugar, a carga dos nosos recursos en liña aumentou significativamente (Sergey dirá como tratamos isto). En segundo lugar, o fluxo de operacións raras (pre-COVID) aumentou moitas veces, o que á súa vez requiriu unha gran cantidade de automatización rápida. Para solucionar este problema, tivemos que trasladar rapidamente recursos desde áreas que antes eran as principais. Elena contaráche como tratamos isto.
Funcionamento de servizos en liña
Kolesnikov Sergey, responsable do funcionamento da tenda en liña e dos microservizos
Desde o momento no que as nosas tendas de venda polo miúdo comezaron a pechar aos visitantes, comezamos a rexistrar un aumento de métricas como o número de usuarios, o número de pedidos realizados na nosa aplicación e o número de solicitudes ás aplicacións.
Número de pedidos do 18 ao 31 de marzoNúmero de solicitudes a microservizos de pago en liñaNúmero de pedidos realizados na páxina web
No primeiro gráfico vemos que o aumento foi de aproximadamente 14 veces, no segundo - 4 veces. Consideramos que a métrica do tempo de resposta das nosas aplicacións é a máis indicativa.
Neste gráfico vemos a resposta de frontes e aplicacións, e por nós mesmos determinamos que non notamos ningún crecemento como tal.
Isto débese principalmente ao feito de que comezamos os traballos preparatorios a finais de 2019. Agora os nosos servizos están reservados, a tolerancia a fallos está garantida a nivel de servidores físicos, sistemas de virtualización, dockers e servizos neles. Ao mesmo tempo, a capacidade dos recursos do noso servidor permítenos soportar múltiples cargas.
A principal ferramenta que nos axudou en toda esta historia foi o noso sistema de seguimento. É certo que ata hai pouco non tiñamos un único sistema que nos permitise recoller métricas en todas as capas, desde o nivel de equipamento físico e hardware ata o nivel de métricas comerciais.
Formalmente, había un seguimento na empresa, pero como regra xeral estaba disperso e estaba na área de responsabilidade de departamentos específicos. De feito, cando se producía un incidente, case nunca tiñamos unha comprensión común do que pasou exactamente, non había comunicación, e moitas veces isto levaba a correr en círculos para atopar e illar o problema para que puidese solucionarse.
Nalgún momento, pensamos e decidimos que xa tiñamos suficientes con soportar isto: necesitabamos un sistema unificado para ver a imaxe completa. As principais tecnoloxías que se inclúen na nosa pila son Zabbix como centro de almacenamento de alertas e métricas, Prometheus para recoller e almacenar métricas de aplicacións, Stack ELK para rexistrar e almacenar datos de todo o sistema de monitorización, así como Grafana para visualización, Swagger, Docker e outras cousas útiles e que che sexan familiares.
Ao mesmo tempo, non só utilizamos tecnoloxías dispoñibles no mercado, senón que tamén desenvolvemos algunhas das nosas. Por exemplo, facemos servizos para integrar sistemas entre si, é dicir, algún tipo de API para recoller métricas. Ademais, estamos a traballar nos nosos propios sistemas de vixilancia: a nivel de métricas empresariais usamos probas de IU. E tamén un bot en Telegram para avisar aos equipos.
Tamén estamos tentando que o sistema de seguimento sexa accesible aos equipos para que poidan almacenar e traballar de forma independente coas súas métricas, incluída a configuración de alertas para algunhas métricas limitadas que non se usan moito.
Durante todo o sistema, esforzámonos pola proactividade e a localización dos incidentes o máis rápido posible. Ademais, o número dos nosos microservizos e sistemas creceu significativamente recentemente e, en consecuencia, o número de integracións creceu. E como parte da optimización do proceso de diagnóstico de incidencias a nivel de integración, estamos a desenvolver un sistema que permite realizar comprobacións entre sistemas e mostrar o resultado, o que permite atopar os principais problemas asociados ás importacións e interacción dos sistemas con entre si.
Por suposto, aínda temos marxe para crecer e desenvolvernos en termos de sistemas operativos, e estamos traballando activamente nisto. Podes ler máis sobre o noso sistema de seguimento .
Probas técnicas
Orlov Sergey, dirixe o centro de competencias para o desenvolvemento web e móbil
Desde que comezaron os peches das tendas físicas, enfrontámonos a varios desafíos desde a perspectiva do desenvolvemento. En primeiro lugar, o aumento da carga como tal. Está claro que se non se toman as medidas adecuadas, cando se aplica unha carga elevada ao sistema, pode converterse nunha cabaza cun golpe triste, degradar completamente o seu rendemento ou incluso perder a súa funcionalidade.
O segundo aspecto, un pouco menos evidente, é que o sistema con alta carga tivo que ser cambiado moi rapidamente, adaptándose aos cambios nos procesos empresariais. Ás veces varias veces ao día. Moitas empresas teñen a regra de que se hai moita actividade de mercadotecnia, non hai que facer ningún cambio no sistema. Ningunha, deixa que funcione mentres funcione.
E tivemos esencialmente un Black Friday interminable, durante o que foi necesario cambiar o sistema. E calquera erro, problema ou falla no sistema sería moi custoso para a empresa.
De cara ao futuro, direi que conseguimos facer fronte a estas probas, todos os sistemas soportaron a carga, escalaron facilmente e non experimentamos ningún fallo técnico global.
Hai catro piares nos que se apoia a capacidade do sistema para soportar altas cargas de sobretensión. O primeiro deles é a vixilancia, sobre o que les xusto arriba. Sen un sistema de monitorización incorporado, é case imposible atopar pescozos de botella do sistema. Un bo sistema de vixilancia é como a roupa de casa; debe ser cómodo e adaptado para ti.
O segundo aspecto é a proba. Tomámolo moi en serio: escribimos unidades clásicas, probas de integración, probas de carga e moitas outras para cada sistema. Tamén estamos escribindo unha estratexia de proba e, ao mesmo tempo, intentamos aumentar o nivel de probas ata o punto de que xa non necesitamos verificacións manuais.
O terceiro piar é CI/CD Pipeline. Os procesos de construción, proba e implantación dunha aplicación deben automatizarse na medida do posible; non debería haber intervención manual. O tema de CI/CD Pipeline é bastante profundo, e só o tocarei brevemente. Só paga a pena mencionar que temos unha lista de verificación CI/CD Pipeline, que cada equipo de produto pasa coa axuda dos centros de competencia.
E aquí está a lista de verificación
Deste xeito, conséguense moitos obxectivos. Trátase de versións da API e alternar de funcións para evitar o tren de lanzamento e conseguir a cobertura de varias probas a un nivel tal que as probas estean totalmente automatizadas, as implementacións sexan perfectas, etc.
O cuarto piar son os principios arquitectónicos e as solucións técnicas. Podemos falar moito de arquitectura durante moito tempo, pero quero salientar un par de principios nos que me gustaría incidir.
En primeiro lugar, cómpre escoller ferramentas especializadas para tarefas específicas. Si, parece obvio, e está claro que os cravos deben ser introducidos cun martelo e os reloxos de pulso deben desmontarse con desaparafusadores especiais. Pero na nosa era, moitas ferramentas loitan pola universalización para cubrir o máximo segmento de usuarios: bases de datos, cachés, frameworks e demais. Por exemplo, se toma a base de datos MongoDB, funciona con transaccións de varios documentos e a base de datos Oracle funciona con json. E parece que todo se pode usar para todo. Pero se defendemos a produtividade, entón necesitamos comprender claramente os puntos fortes e débiles de cada ferramenta e usar as que necesitamos para a nosa clase de tarefas.
En segundo lugar, á hora de deseñar sistemas, debe xustificarse cada aumento da complexidade. Debemos telo presente constantemente; o principio de acoplamento baixo é coñecido por todos. Creo que debería aplicarse a nivel dun servizo concreto, e a nivel de todo o sistema, e a nivel da paisaxe arquitectónica. Tamén é importante a capacidade de escalar horizontalmente cada compoñente do sistema ao longo da ruta de carga. Se tes esta habilidade, escalar non será difícil.
Falando de solucións técnicas, pedimos aos equipos de produtos que prepararan un novo conxunto de recomendacións, ideas e solucións, que implementaron para preparar a seguinte onda de carga de traballo.
Keshi
É necesario abordar conscientemente a elección de cachés locais e distribuídos. Ás veces ten sentido usar ambos no mesmo sistema.Por exemplo, temos sistemas nos que parte dos datos son esencialmente un caché de escaparate, é dicir, a fonte das actualizacións está situada detrás do propio sistema e os sistemas non cambian. este dato. Para este enfoque usamos Caffeine Cache local.
E hai datos de que o sistema cambia activamente durante o funcionamento, e aquí xa estamos usando unha caché distribuída con Hazelcast. Este enfoque permítenos utilizar os beneficios dunha caché distribuída onde son realmente necesarios e minimizar os custos do servizo de circular os datos do clúster de Hazelcast onde podemos prescindir del. Escribimos moito sobre cachés. и .
Ademais, cambiar o serializador a Kryo en Hazelcast deunos un bo impulso. E a transición de ReplicatedMap a IMap + Near Cache en Hazelcast permitiunos minimizar o movemento de datos no clúster.
Un pequeno consello: en caso de invalidación masiva da caché, ás veces é aplicable a táctica de quentar a segunda caché e despois cambiar a ela. Parece que con este enfoque deberíamos conseguir o dobre consumo de memoria, pero na práctica, naqueles sistemas onde se practicaba, o consumo de memoria diminuíu.
Pila reactiva
Usamos a pila reactiva nun número bastante grande de sistemas. No noso caso, trátase de Webflux ou Kotlin con coroutines. A pila reactiva é especialmente boa onde esperamos operacións de entrada-saída lentas. Por exemplo, chamadas a servizos lentos, traballo co sistema de ficheiros ou sistemas de almacenamento.
O principio máis importante é evitar o bloqueo de chamadas. Os cadros reactivos teñen un pequeno número de fíos de servizo en directo que se executan baixo o capó. Se nos permitimos sen coidado facer unha chamada de bloqueo directo, como unha chamada de controlador JDBC, o sistema simplemente pararase.
Tenta converter os erros na túa propia excepción de tempo de execución. O fluxo real de execución do programa cambia a marcos reactivos e a execución do código faise non lineal. Como resultado, é moi difícil diagnosticar problemas usando rastrexos de pila. E a solución aquí sería crear excepcións de execución claras e obxectivas para cada erro.
Elasticsearch
Cando use Elasticsearch, non seleccione os datos non utilizados. Este, en principio, tamén é un consello moi sinxelo, pero a maioría das veces é o que se esquece. Se precisa seleccionar máis de 10 mil rexistros á vez, debe usar o Desprazamento. Para usar unha analoxía, é un pouco como un cursor nunha base de datos relacional.
Non use postfiltro a menos que sexa necesario. Con grandes datos na mostra principal, esta operación carga moito a base de datos.
Use operacións masivas se é o caso.
API
Ao deseñar unha API, inclúa requisitos para minimizar os datos transmitidos. Isto é especialmente certo en relación coa fronte: é neste cruce onde imos máis aló das canles dos nosos centros de datos e xa estamos traballando na canle que nos conecta co cliente. Se ten o máis mínimo problema, demasiado tráfico provoca unha experiencia de usuario negativa.
E para rematar, non tires un montón de datos, ten claro o contrato entre consumidores e provedores.
Transformación organizativa
Eroshkina Elena, subdirectora de TI
No momento en que se produciu a corentena, e xurdiu a necesidade de aumentar drasticamente o ritmo de desenvolvemento en liña e introducir servizos omnicanal, xa estabamos no proceso de transformación organizativa.
Parte da nosa estrutura foi transferida para traballar segundo os principios e prácticas do enfoque do produto. Formáronse equipos que agora se encargan do funcionamento e desenvolvemento de cada produto. Os empregados destes equipos están 100 % implicados e estruturan o seu traballo mediante Scrum ou Kanban, dependendo do que lles sexa preferible, configurando unha canalización de implantación, implementando prácticas técnicas, prácticas de garantía de calidade e moito máis.
Por sorte, a maior parte dos nosos equipos de produtos estaban na área de servizos en liña e omnicanal. Isto permitiunos cambiar ao modo de traballo remoto no menor tempo posible (en serio, literalmente en dous días) sen perda de eficiencia. O proceso personalizado permitiunos adaptarnos rapidamente ás novas condicións de traballo e manter un ritmo bastante elevado de entrega de novas funcionalidades.
Ademais, temos a necesidade de reforzar aqueles equipos que están na fronteira do negocio en liña. Nese momento quedou claro que só podíamos facelo utilizando recursos internos. E unhas 50 persoas en dúas semanas cambiaron a zona na que traballaban antes e implicáronse para traballar nun produto que era novo para eles.
Isto non requiriu ningún esforzo de xestión especial, porque xunto coa organización do noso propio proceso, a mellora técnica do produto e as prácticas de garantía de calidade, ensinamos aos nosos equipos a autoorganizarse, a xestionar o seu propio proceso de produción sen implicar recursos administrativos.
Puidemos enfocar os nosos recursos de xestión exactamente onde era necesario nese momento: na coordinación xunto coa empresa: o que é importante para o noso cliente agora mesmo, que funcións deberían implementarse primeiro, que hai que facer para aumentar a nosa capacidade de rendemento. para entregar e procesar pedidos. Todo isto e un claro modelo a seguir fixeron posible durante este período cargar os nosos fluxos de valor da produción co que é realmente importante e necesario.
Está claro que co traballo a distancia e un alto ritmo de cambio, cando os indicadores empresariais dependen da participación de todos, non se pode confiar só nos sentimentos internos da serie “Vai todo ben con nós? Si, parece ben". Necesítanse métricas obxectivas do proceso de produción. Temos estes, están dispoñibles para calquera que estea interesado nas métricas dos equipos de produtos. En primeiro lugar, o propio equipo, a empresa, as subcontratas e a dirección.
Unha vez cada dúas semanas realízase un estado con cada equipo, onde se analizan as métricas durante 10 minutos, se identifican os embotellamentos no proceso de produción e se desenvolve unha solución conxunta: que se pode facer para eliminar estes embotellamentos. Aquí pode solicitar inmediatamente axuda á dirección se algún problema identificado está fóra da zona de influencia dos equipos, ou a experiencia de compañeiros que xa se atoparon cun problema similar.
Porén, entendemos que para acelerar varias veces (e este é exactamente o obxectivo que nos marcamos), aínda temos que aprender moito e implementalo no noso traballo diario. Nestes momentos seguimos ampliando o noso enfoque de produtos a outros equipos e produtos novos. Para iso, tivemos que dominar un novo formato para nós: unha escola en liña de metodoloxías.
Os metodolóxicos, persoas que axudan aos equipos a construír un proceso, establecer comunicacións e mellorar a eficiencia do traballo, son esencialmente axentes de cambio. Agora mesmo, os graduados da nosa primeira cohorte están traballando con equipos e axudándoos a ter éxito.
Creo que a situación actual ábrenos oportunidades e perspectivas que quizais nós mesmos aínda non somos plenamente conscientes. Pero a experiencia e a práctica que estamos acumulando agora mesmo confirma que escollemos o camiño correcto de desenvolvemento, non perderemos estas novas oportunidades no futuro e poderemos responder con igual eficacia aos retos aos que se enfrontará Sportmaster.
Descubrimentos
Durante este momento difícil, formulamos os principais principios nos que se basea o desenvolvemento de software, que, creo, serán relevantes para todas as empresas que se ocupen diso.
Persoas. Nisto é no que descansa todo. Os empregados deben gozar do seu traballo e comprender os obxectivos da empresa e os obxectivos dos produtos nos que traballan. E, por suposto, poderían desenvolverse profesionalmente.
Технология. É necesario que a empresa adopte un enfoque maduro para traballar coa súa pila de tecnoloxía e constrúe competencias onde realmente sexa necesario. Parece moi sinxelo e obvio. E moitas veces ignorado.
Os procesos. É importante organizar adecuadamente o traballo dos equipos de produto e dos centros de competencia, para establecer a interacción coa empresa para traballar con ela como socio.
En xeral, así sobrevivimos. A tese principal do noso tempo foi confirmada unha vez máis, cun rotundo clic na testa
Aínda que sexas un gran negocio fóra de liña con moitas tendas e unha morea de cidades onde operas, desenvolve o teu negocio en liña. Esta non é só unha canle de vendas adicional ou unha fermosa aplicación a través da que tamén podes mercar algo (e tamén porque os competidores tamén teñen outras fermosas). Este non é un pneumático de reposto por si acaso para axudarche a capear a tormenta.
Esta é unha necesidade absoluta. Para o que hai que preparar non só as túas capacidades técnicas e infraestruturas, senón tamén as túas persoas e procesos. Despois de todo, podes mercar rapidamente memoria adicional, espazo, implementar novas instancias, etc. nun par de horas. Pero as persoas e os procesos deben estar preparados para iso con antelación.
Fonte: www.habr.com