Ce qui nous a aidé à nous adapter rapidement au trading en ligne dans les nouvelles conditions

Salut!

Je m'appelle Mikhail, je suis directeur adjoint de l'informatique de la société Sportmaster. Je souhaite raconter comment nous avons fait face aux défis apparus pendant la pandémie.

Dans les premiers jours des nouvelles réalités, le format de trading hors ligne habituel de Sportmaster s'est figé et la charge sur notre canal en ligne, principalement en termes de livraison à l'adresse du client, a été multipliée par 10. En quelques semaines seulement, nous avons transformé une gigantesque entreprise hors ligne en une entreprise en ligne et adapté le service aux besoins de nos clients.

Fondamentalement, ce qui était essentiellement notre activité secondaire est devenu notre cœur de métier. L'importance de chaque commande en ligne a considérablement augmenté. Il était nécessaire d'économiser chaque rouble que le client apportait à l'entreprise. 

Pour répondre rapidement aux demandes des clients, nous avons ouvert un centre de contact supplémentaire au siège social de l'entreprise et pouvons désormais recevoir environ 285 270 appels par semaine. Parallèlement, nous avons transféré XNUMX magasins vers un nouveau format de fonctionnement sans contact et sécurisé, qui a permis aux clients de recevoir des commandes et aux salariés de conserver leur emploi.

Au cours du processus de transformation, nous avons rencontré deux problèmes principaux. Premièrement, la charge sur nos ressources en ligne a considérablement augmenté (Sergey vous expliquera comment nous avons géré ce problème). Deuxièmement, le flux d’opérations rares (pré-COVID) a augmenté à plusieurs reprises, ce qui a nécessité une automatisation rapide et importante. Pour résoudre ce problème, nous avons dû transférer rapidement des ressources des domaines qui étaient auparavant les principaux. Elena vous expliquera comment nous avons géré cela.

Exploitation de services en ligne

Kolesnikov Sergey, responsable du fonctionnement de la boutique en ligne et des microservices

À partir du moment où nos magasins de détail ont commencé à fermer leurs portes aux visiteurs, nous avons commencé à enregistrer une augmentation de mesures telles que le nombre d'utilisateurs, le nombre de commandes passées dans notre application et le nombre de demandes adressées aux applications. 

Nombre de commandes du 18 mars au 31 marsNombre de requêtes vers les microservices de paiement en ligneNombre de commandes passées sur le site

Dans le premier graphique, nous voyons que l'augmentation était d'environ 14 fois, dans le second, de 4 fois. Nous considérons que la mesure du temps de réponse de nos applications est la plus indicative. 

Dans ce graphique, nous voyons la réponse des fronts et des applications, et nous avons déterminé nous-mêmes que nous n'avons remarqué aucune croissance en tant que telle.

Cela est principalement dû au fait que nous avons commencé les travaux préparatoires fin 2019. Désormais nos services sont réservés, la tolérance aux pannes est assurée au niveau des serveurs physiques, des systèmes de virtualisation, des dockers et des services qu'ils contiennent. Dans le même temps, la capacité de nos ressources serveur nous permet de résister à de multiples charges.

Le principal outil qui nous a aidé dans toute cette histoire était notre système de surveillance. Certes, jusqu'à tout récemment, nous ne disposions pas d'un système unique qui nous permettrait de collecter des métriques à tous les niveaux, du niveau de l'équipement physique et du matériel jusqu'au niveau des métriques commerciales. 

Formellement, il y avait un contrôle dans l'entreprise, mais en règle générale, il était dispersé et relevait de la responsabilité de départements spécifiques. En fait, lorsqu’un incident survenait, nous n’avions presque jamais une compréhension commune de ce qui s’était exactement passé, il n’y avait aucune communication, ce qui nous conduisait souvent à tourner en rond pour trouver et isoler le problème afin de pouvoir le résoudre.

À un moment donné, nous avons pensé et décidé que nous en avions assez de supporter cela : nous avions besoin d'un système unifié pour avoir une vue d'ensemble dans son intégralité. Les principales technologies incluses dans notre pile sont Zabbix en tant que centre de stockage d'alertes et de métriques, Prometheus pour la collecte et le stockage des métriques d'application, Stack ELK pour la journalisation et le stockage des données de l'ensemble du système de surveillance, ainsi que Grafana pour la visualisation, Swagger, Docker. et d'autres choses utiles et qui vous sont familières.

Parallèlement, nous utilisons non seulement les technologies disponibles sur le marché, mais nous développons également certaines des nôtres. Par exemple, nous créons des services pour intégrer les systèmes les uns aux autres, c'est-à-dire une sorte d'API pour collecter des métriques. De plus, nous travaillons sur nos propres systèmes de surveillance : au niveau des indicateurs commerciaux, nous utilisons des tests d'interface utilisateur. Et aussi un bot dans Telegram pour notifier les équipes.

Nous essayons également de rendre le système de surveillance accessible aux équipes afin qu'elles puissent stocker et travailler de manière indépendante avec leurs métriques, notamment en configurant des alertes pour certaines métriques restreintes qui ne sont pas largement utilisées. 

Dans l’ensemble du système, nous nous efforçons d’être proactifs et de localiser les incidents le plus rapidement possible. De plus, le nombre de nos microservices et systèmes a considérablement augmenté récemment, et le nombre d'intégrations a augmenté en conséquence. Et dans le cadre de l'optimisation du processus de diagnostic des incidents au niveau de l'intégration, nous développons un système qui permet d'effectuer des contrôles inter-systèmes et d'afficher le résultat, ce qui permet de retrouver les principaux problèmes liés aux importations et à l'interaction des systèmes avec l'un l'autre. 

Bien entendu, nous avons encore de la marge pour grandir et nous développer en termes de systèmes d’exploitation, et nous y travaillons activement. Vous pouvez en savoir plus sur notre système de surveillance ici. 

Essais techniques 

Orlov Sergey, dirige le centre de compétences pour le développement Web et mobile

Depuis le début des fermetures physiques de magasins, nous avons été confrontés à divers défis du point de vue du développement. Tout d’abord, la montée en charge en tant que telle. Il est clair que si des mesures appropriées ne sont pas prises, lorsqu'une charge élevée est appliquée au système, celui-ci peut se transformer en citrouille avec un triste bruit, ou se dégrader complètement en performances, voire perdre sa fonctionnalité.

Le deuxième aspect, un peu moins évident, est que le système soumis à une forte charge a dû être modifié très rapidement, en s'adaptant aux évolutions des processus métiers. Parfois plusieurs fois par jour. De nombreuses entreprises ont pour règle que s’il y a beaucoup d’activités de marketing, il n’est pas nécessaire d’apporter des modifications au système. Aucun, laissez-le fonctionner tant que cela fonctionne.

Et nous avons eu essentiellement un Black Friday interminable, durant lequel il a fallu changer de système. Et toute erreur, problème ou panne dans le système coûterait très cher à l’entreprise.

Pour l'avenir, je dirai que nous avons réussi à faire face à ces tests, que tous les systèmes ont résisté à la charge, ont été facilement mis à l'échelle et que nous n'avons rencontré aucune panne technique globale.

Il existe quatre piliers sur lesquels repose la capacité du système à résister à des surcharges élevées. Le premier d’entre eux est la surveillance, dont vous avez parlé juste au-dessus. Sans système de surveillance intégré, il est presque impossible de détecter les goulots d'étranglement du système. Un bon système de surveillance, c'est comme des vêtements de maison : il doit être confortable et adapté à vous.

Le deuxième aspect concerne les tests. Nous prenons ce point très au sérieux : nous écrivons des unités classiques, des tests d'intégration, des tests de charge et bien d'autres pour chaque système. Nous rédigeons également une stratégie de test et essayons en même temps d'augmenter le niveau de test au point que nous n'ayons plus besoin de contrôles manuels.

Le troisième pilier est le pipeline CI/CD. Les processus de création, de test et de déploiement d’une application doivent être automatisés autant que possible ; il ne doit y avoir aucune intervention manuelle. Le sujet du pipeline CI/CD est assez profond et je ne l'aborderai que brièvement. Il convient seulement de mentionner que nous disposons d’une liste de contrôle du pipeline CI/CD, que chaque équipe produit parcourt avec l’aide des centres de compétences.

Et voici la liste de contrôle

De cette manière, de nombreux objectifs sont atteints. Il s'agit de la gestion des versions de l'API et du basculement des fonctionnalités pour éviter le train de versions et atteindre une couverture de divers tests à un niveau tel que les tests sont entièrement automatisés, les déploiements sont transparents, etc.

Le quatrième pilier concerne les principes architecturaux et les solutions techniques. Nous pouvons parler beaucoup d'architecture pendant longtemps, mais je tiens à souligner quelques principes sur lesquels j'aimerais me concentrer.

Tout d’abord, vous devez choisir des outils spécialisés pour des tâches spécifiques. Oui, cela semble évident, et il est clair que les clous doivent être enfoncés avec un marteau et que les montres-bracelets doivent être démontées avec des tournevis spéciaux. Mais à notre époque, de nombreux outils aspirent à l'universalisation afin de couvrir le segment maximum d'utilisateurs : bases de données, caches, frameworks et le reste. Par exemple, si vous prenez la base de données MongoDB, elle fonctionne avec des transactions multi-documents et la base de données Oracle fonctionne avec json. Et il semblerait que tout puisse servir à tout. Mais si nous défendons la productivité, nous devons alors comprendre clairement les forces et les faiblesses de chaque outil et utiliser ceux dont nous avons besoin pour notre classe de tâches. 

Deuxièmement, lors de la conception des systèmes, chaque augmentation de complexité doit être justifiée. Il faut constamment garder cela à l’esprit, le principe du faible couplage est connu de tous. Je crois qu'il faut l'appliquer au niveau d'un service spécifique, au niveau de l'ensemble du système et au niveau du paysage architectural. La possibilité de mettre à l'échelle horizontalement chaque composant du système le long du chemin de charge est également importante. Si vous avez cette capacité, la mise à l’échelle ne sera pas difficile.

En parlant de solutions techniques, nous avons demandé aux équipes produit de préparer un nouvel ensemble de recommandations, d'idées et de solutions, qu'elles ont mises en œuvre en vue de la prochaine vague de charge de travail.

Keshi

Il est nécessaire d'aborder consciemment le choix des caches locaux et distribués. Parfois, il est judicieux d'utiliser les deux au sein du même système. Par exemple, nous avons des systèmes dans lesquels certaines données sont essentiellement un cache de vitrine, c'est-à-dire que la source des mises à jour est située derrière le système lui-même et que les systèmes ne changent pas. ces données. Pour cette approche, nous utilisons le Caffeine Cache local. 

Et il y a des données que le système modifie activement pendant le fonctionnement, et ici nous utilisons déjà un cache distribué avec Hazelcast. Cette approche nous permet d'utiliser les avantages d'un cache distribué là où ils sont vraiment nécessaires, et de minimiser les coûts de service liés à la circulation des données du cluster Hazelcast là où nous pouvons nous en passer. Nous avons beaucoup écrit sur les caches. ici и ici.

De plus, le changement du sérialiseur en Kryo dans Hazelcast nous a donné un bon coup de pouce. Et la transition de ReplicatedMap vers IMap + Near Cache dans Hazelcast nous a permis de minimiser le mouvement des données à travers le cluster. 

Un petit conseil : en cas d'invalidation massive du cache, la tactique consistant à réchauffer le deuxième cache puis à y basculer est parfois applicable. Il semblerait qu'avec cette approche, nous devrions obtenir une double consommation de mémoire, mais en pratique, dans les systèmes où cela était pratiqué, la consommation de mémoire a diminué.

Pile réactive

Nous utilisons la pile réactive dans un assez grand nombre de systèmes. Dans notre cas, il s'agit de Webflux ou Kotlin avec des coroutines. La pile réactive est particulièrement efficace là où nous nous attendons à des opérations d'entrée-sortie lentes. Par exemple, les appels à des services lents, l'utilisation du système de fichiers ou des systèmes de stockage.

Le principe le plus important est d’éviter de bloquer les appels. Les frameworks réactifs ont un petit nombre de threads de service en direct exécutés sous le capot. Si nous nous permettons par inadvertance de faire un appel de blocage direct, tel qu'un appel du pilote JDBC, le système s'arrêtera tout simplement. 

Essayez de transformer les erreurs en votre propre exception d'exécution. Le flux réel d’exécution du programme passe à des frameworks réactifs et l’exécution du code devient non linéaire. Par conséquent, il est très difficile de diagnostiquer les problèmes à l’aide des traces de pile. Et la solution ici serait de créer des exceptions d’exécution claires et objectives pour chaque erreur.

ElasticSearch

Lorsque vous utilisez Elasticsearch, ne sélectionnez pas les données inutilisées. Ceci, en principe, est aussi un conseil très simple, mais le plus souvent c'est ce qui est oublié. Si vous devez sélectionner plus de 10 XNUMX enregistrements à la fois, vous devez utiliser Scroll. Pour utiliser une analogie, c'est un peu comme un curseur dans une base de données relationnelle. 

N'utilisez pas de post-filtre sauf si nécessaire. Avec des données volumineuses dans l'échantillon principal, cette opération charge considérablement la base de données. 

Utilisez des opérations groupées le cas échéant.

API

Lors de la conception d'une API, incluez des exigences visant à minimiser les données transmises. Cela est particulièrement vrai en ce qui concerne le front : c'est à ce carrefour que nous dépassons les canaux de nos datacenters et travaillons déjà sur le canal qui nous relie au client. Au moindre problème, un trafic trop important entraîne une expérience utilisateur négative.

Et enfin, ne jetez pas tout un tas de données, soyez clair sur le contrat entre consommateurs et fournisseurs.

Transformation organisationnelle

Eroshkina Elena, directrice adjointe de l'informatique

Au moment où la quarantaine est survenue et où s’est fait sentir le besoin d’accélérer considérablement le rythme de développement en ligne et d’introduire des services omnicanaux, nous étions déjà en train de transformer notre organisation. 

Une partie de notre structure a été transférée au travail selon les principes et pratiques de l'approche produit. Des équipes ont été constituées et sont désormais responsables de l'exploitation et du développement de chaque produit. Les employés de ces équipes sont impliqués à 100 % et structurent leur travail en utilisant Scrum ou Kanban, selon ce qui leur convient, en mettant en place un pipeline de déploiement, en mettant en œuvre des pratiques techniques, des pratiques d'assurance qualité et bien plus encore.

Par chance, la majeure partie de nos équipes produits se trouvaient dans le domaine des services en ligne et omnicanaux. Cela nous a permis de passer en mode travail à distance dans les plus brefs délais (sérieusement, littéralement en deux jours) sans perte d'efficacité. Le processus personnalisé nous a permis de nous adapter rapidement aux nouvelles conditions de travail et de maintenir un rythme de livraison de nouvelles fonctionnalités assez élevé.

En outre, nous devons renforcer les équipes qui se trouvent à la frontière du commerce en ligne. À ce moment-là, il est devenu évident que nous ne pouvions y parvenir qu’en utilisant nos ressources internes. Et environ 50 personnes en deux semaines ont changé de domaine où elles travaillaient auparavant et se sont impliquées dans le travail sur un produit qui était nouveau pour elles. 

Cela n'a nécessité aucun effort de gestion particulier, car en plus d'organiser notre propre processus, d'améliorer techniquement le produit et de pratiques d'assurance qualité, nous apprenons à nos équipes à s'auto-organiser - à gérer leur propre processus de production sans impliquer de ressources administratives.

Nous avons pu concentrer nos ressources de gestion exactement là où elles étaient nécessaires à ce moment-là : sur la coordination avec l'entreprise : ce qui est important pour notre client en ce moment, quelle fonctionnalité doit être implémentée en premier, ce qui doit être fait pour augmenter notre capacité de débit. pour livrer et traiter les commandes. Tout cela et un modèle clair ont permis pendant cette période de charger nos flux de valeur de production de ce qui est vraiment important et nécessaire. 

Force est de constater qu'avec le travail à distance et un rythme de changement élevé, lorsque les indicateurs économiques dépendent de la participation de chacun, on ne peut pas se fier uniquement aux ressentis internes de la série « Est-ce que tout va bien chez nous ? Oui, ça a l'air bien." Des mesures objectives du processus de production sont nécessaires. Nous les avons, ils sont accessibles à toute personne intéressée par les métriques des équipes produit. Tout d’abord l’équipe elle-même, l’entreprise, les sous-traitants et la direction.

Une fois toutes les deux semaines, un statut est tenu avec chaque équipe, où les métriques sont analysées pendant 10 minutes, les goulots d'étranglement dans le processus de production sont identifiés et une solution commune est développée : que peut-on faire pour éliminer ces goulots d'étranglement. Ici, vous pouvez immédiatement demander l'aide de la direction si un problème identifié se situe en dehors de la zone d'influence des équipes, ou de l'expertise de collègues qui auraient déjà rencontré un problème similaire.

Cependant, nous comprenons que pour accélérer plusieurs fois (et c'est exactement l'objectif que nous nous sommes fixés), nous devons encore beaucoup apprendre et les mettre en œuvre dans notre travail quotidien. À l’heure actuelle, nous continuons d’étendre notre approche produit à d’autres équipes et à de nouveaux produits. Pour ce faire, nous avons dû maîtriser un nouveau format : une école de méthodologistes en ligne.

Les méthodologistes, les personnes qui aident les équipes à construire un processus, à établir des communications et à améliorer l'efficacité du travail, sont essentiellement des agents de changement. À l’heure actuelle, les diplômés de notre première cohorte travaillent avec des équipes et les aident à réussir. 

Je pense que la situation actuelle nous ouvre des opportunités et des perspectives dont nous n’avons peut-être pas encore pleinement conscience. Mais l'expérience et la pratique que nous acquérons actuellement confirment que nous avons choisi la bonne voie de développement, nous ne manquerons pas ces nouvelles opportunités à l'avenir et serons en mesure de répondre tout aussi efficacement aux défis auxquels Sportmaster sera confronté.

résultats

Pendant cette période difficile, nous avons formulé les grands principes sur lesquels repose le développement de logiciels, qui, je pense, seront pertinents pour toute entreprise confrontée à ce sujet.

personnes. C'est sur cela que tout repose. Les employés doivent apprécier leur travail et comprendre les objectifs de l'entreprise et ceux des produits sur lesquels ils travaillent. Et bien sûr, ils pourraient se développer professionnellement. 

Technologie. Il est nécessaire que l’entreprise adopte une approche mature pour travailler avec sa pile technologique et développe les compétences là où elles sont réellement nécessaires. Cela semble très simple et évident. Et très souvent ignoré.

Processus. Il est important de bien organiser le travail des équipes produits et des centres de compétences, d'établir une interaction avec l'entreprise afin de travailler avec elle en tant que partenaire.

En général, c’est à peu près ainsi que nous avons survécu. La thèse principale de notre époque s’est confirmée une fois de plus, avec un clic retentissant sur le front

Même si vous êtes une énorme entreprise hors ligne avec de nombreux magasins et un certain nombre de villes où vous opérez, développez votre activité en ligne. Il ne s'agit pas seulement d'un canal de vente supplémentaire ou d'une belle application grâce à laquelle vous pouvez également acheter quelque chose (et aussi parce que les concurrents en ont aussi de belles). Il ne s’agit pas d’une roue de secours juste au cas où pour vous aider à affronter la tempête.

C'est une nécessité absolue. Pour cela, non seulement vos capacités techniques et votre infrastructure doivent être préparées, mais également vos collaborateurs et vos processus. Après tout, vous pouvez rapidement acheter de la mémoire supplémentaire, de l'espace, déployer de nouvelles instances, etc. en quelques heures. Mais les personnes et les processus doivent s’y préparer à l’avance.

Source: habr.com