Il y a quatre ans, une clientèle était maintenue séparément dans chaque magasin, plus une autre sur le site.
Dans la série précédente: il y a trois ans, nous avions décidé que nous devions faire notre développement en Russie. Il y a deux ans, ils ont commencé à écrire leur propre code au lieu de modifier le code fork de la société mère. L'histoire d'aujourd'hui portera sur la façon dont nous sommes passés d'un grand monolithe hérité à un tas de petits microservices connectés par une sorte de bus (orchestrateur).
Le cas d'utilisation le plus simple: passez une commande sur le site et récupérez-la dans la boutique réelle Leroy Merlin en Russie. Auparavant, les commandes des boutiques en ligne étaient traitées dans une autre application en général et selon un schéma différent. Désormais, nous avions besoin d'une vitrine omnicanal pour que toute commande soit décomposée en interface: un caissier dans un magasin, une application mobile, un terminal dans un magasin, un site web - peu importe. Si vous mettez Linux au micro-ondes, laissez le micro-ondes être. L'essentiel est que certaines interfaces puissent frapper l'API à l'arrière et dire qu'ici vous devez passer telle ou telle commande. Et ils ont reçu une réponse claire à cela. La deuxième histoire était avec des demandes de disponibilité et de propriétés des marchandises de sa carte.
À l'avant (nous écrirons à ce sujet bientôt), nous avons un monstre - AEM, et derrière lui à l'arrière se trouvaient deux grandes applications: OPUS et MoVe. La première est une base de données des propriétés de chaque produit (des dimensions aux descriptions), la seconde est responsable de la caisse, c'est-à-dire du monolithe de caisse. Si grandement simplifié.
Quel était le problème avec Opus?
OPUS est une grande base distribuée. Plus précisément, il s'agit d'un logiciel qui fournit une interface pour accéder à la base de données, c'est-à-dire qu'il accède à la base de données et, par exemple, recherche ou expose simplement l'API afin que les clients ne se rendent pas directement dans la base de données. Ce logiciel fonctionne et est supporté en France. La deuxième caractéristique,
comme nous l'avons déjà dit , est que la ligne d'améliorations est très longue, et nous ne sommes pas en priorité par rapport à la business unit de la France.
Avec beaucoup de difficulté, nous avons pu comprendre comment les développeurs pouvaient apporter des changements sans une équipe de France; de très longues approbations ont eu lieu. Fonctionnalité publiée pendant six mois. En fait, au début, nous voulions faire notre propre développement et leur examen, puis nous sommes arrivés à notre propre développement, à notre infrastructure, à nos tests et en général au nôtre. Et en même temps a jeté près d'un tiers du code hérité.
Mais revenons à OPUS. Étant donné que le système stocke des informations pertinentes sur la disponibilité, les caractéristiques, les transactions et d'autres choses, nous y avons touché pour une raison quelconque. Spécifiquement pour le site, cela signifie que si l'utilisateur a trois produits dans le panier, vous devez frapper sur la base de données à partir de chaque page, car la pertinence est vérifiée. Même si vous frappez une fois pour le cache, puis le mettez à jour intelligemment, il y avait encore des fonctionnalités. Lorsque vous ouvrez la page du catalogue en général, toutes les spécifications du produit ont été extraites d'OPUS.
La prochaine étape logique est que nous avons commencé à tirer OPUS moins souvent et à faire notre base (plus précisément, des microservices avec des bases). Le système dans son ensemble s'appelait PUB russe.
Ensuite, ils ont fait un orchestre, qui peut déjà stocker des agrégats, c'est-à-dire en fait - les données collectées pour les pages de construction. En ce sens que lorsque l'utilisateur bascule l'affichage des pages des cartes vers les listes, il s'agit toujours du même agrégat, seul le recto est différent.
Autrement dit, nous avons quitté l'OPUS d'origine (il est toujours en France), mais notre miroir presque complet le «suce», ce qui coupe la base en morceaux, prêt pour l'assemblage dans un orchestre. Et l'orchestrateur collecte et stocke les agrégats (ou les reçoit rapidement et commence à les stocker), dont d'autres systèmes ont besoin. En conséquence, cette partie fonctionne comme il se doit. De la fonctionnalité d'origine de l'OPUS français, il reste environ 5%. Bientôt, nous le remplacerons complètement.
Quel était le problème avec MoVe?
Rien de spécial, sauf que nous avons décidé de jeter tout le code, car il:
- Était ancien sur une vieille pile.
- Il a pris en compte les caractéristiques de chaque région "Leroy Merlin" dans la chaîne des FI.
- Il était si difficile à lire et à maintenir que la meilleure méthode de refactorisation était de «réécrire et documenter immédiatement normalement».
Ce que nous avons fait. Seulement, nous ne l'avons pas réécrit comme un monolithe, mais nous avons commencé à faire des microservices pour chaque fonction individuelle autour. Et puis, une partie des fonctionnalités de MoVe avec le passage au microservice a été supprimée en douceur. Et ainsi - un par un, jusqu'à ce que la fonctionnalité de MoVe se termine complètement. Autrement dit, cela fonctionne toujours, mais quelque part dans le vide et sans flux de données.
Depuis que nous avons construit la plate-forme à partir de morceaux, le projet a été nommé Lego.
Lego a complètement changé ce milieu. Oui, clarifions: un vrai backend est un bus hérité, des systèmes de fichiers, des bases de données et d'autres niveaux d'infrastructure. Les grandes applications autour de cela et les microservices de logique sont intermédiaires. La présentation est déjà à l'avant.
Pourquoi aviez-vous besoin de réécrire tout cela?
Parce que nous vivions avec des clients différents pour chaque instance 15 ans après l'ouverture en Russie, et cela ne convenait à personne. Il n'y a pas eu non plus de synchronisation. Dans d'autres pays, ils vivent toujours comme ça.
La société mère française a fait la logistique générale, nous avons réutilisé le système Pixis - c'est un seul magasin de reçus, c'est-à-dire les commandes des clients: un magasin voit les commandes d'un autre magasin. Mais cela n'a pas complètement résolu le problème de l'ordre omnicanal. Il a donc fallu consolider la base et effectuer le traitement général. C'est l'essentiel.
La deuxième raison était la loi fédérale sur le box-office: avec nos délais de développement pour un système commun (et des tests) pour tous les pays, nous aurions dû payer des amendes.
Une option à peu près similaire a été lancée au Brésil: ils ont commencé Leroy Merlin là-bas sans aucun logiciel de la société mère, et ils ont réussi. C'était avant la décision partagée. Soit dit en passant, ils s'engagent beaucoup envers les
innersors , ils ont un développement très rapide.
Pixis permettait de passer une commande uniquement à partir de la caisse enregistreuse, en fait. Nous avons changé la situation en trois étapes:
- Nous avons d'abord fait une application mobile pour l'employé, ce qui simplifie grandement sa vie. Sur cette base, ils ont commencé à construire un écosystème où les interfaces sont séparées par la logique.
- Pendant que tout était mis en place, les commandes Internet étaient acheminées manuellement à la caisse.
- Ils ont mis des microservices à leur tour, qui ont tout remplacé au milieu.
Pourquoi aviez-vous besoin de commencer avec l'application Store? Parce que nous avons encore des procédés uniques par rapport à la France. Par exemple, une personne a décidé d'acheter six mètres dix centimètres d'une chaîne dans un magasin. Le vendeur l'a coupé, a donné un document sur la durée et le coût. Vous allez au caissier avec ce papier, vous payez là-bas. Du point de vue de la logique, la vente ne devrait pas être au box-office, mais le vendeur devrait l'avoir, mais en fait c'est au box-office que la chose la plus intéressante commence: vous devez avoir à la fois la marchandise et le papier.
En fin de compte, nous allons être une plate-forme pour passer des commandes: maintenant, par exemple, en plus de notre système principal, des services d'achat de services de maîtres ont été ajoutés (j'ai acheté une cuisine - j'ai commandé l'installation à un maître externe, mais nous l'avons trouvée et nous avons donné une garantie de nous-mêmes),
place de marché ( achat direct auprès d'un fournisseur sur une gamme plus large), et bientôt il doit y avoir une filiale pour que nos blocs puissent être placés n'importe où. Quelque chose comme l'intégration de magasins Amazon dans des blogs, mais plus polyvalents.
Comment la décision de remplacement a-t-elle été prise?
Je marche. Affinez le modèle d'entreprise.Nous avons vérifié, et en effet: le modèle, comme en Russie - des prix bas tous les jours - est un succès. Leroy Merlin en Europe est beaucoup plus cher, mais c'est en Russie que c'est notre créneau: un magasin de construction où vous pouvez certainement trouver des marchandises au meilleur prix.
II étape. Créez un script client.Autrement dit, pour construire des processus comme nous voulons qu'ils interagissent avec nous du point de vue du client. Autrement dit, une vision unique de qui nous voulons être dans quelques années et à quoi cela ressemble du point de vue de l'architecture.
Étape III. Construisez une architecture.Décomposez cette vision en savoirs traditionnels et en architecture avec plus de détails. Il s'est avéré 110 projets, que nous avons répartis en cinq catégories pendant cinq ans.
Ils ont ensuite formé des équipes spécialisées. Le plus souvent, ce sont leurs employés et un entrepreneur. Au début, ils en ont beaucoup souffert: lorsqu'ils sont allés au prod, ils n'ont pas vraiment compris comment digérer un si grand volume de changements. Puis ils ont commencé à faire une approche commune des tâches et à augmenter progressivement la part de leur développement.
Dans les endroits où l'erreur était critique, ils ont travaillé selon les plans de la NASA, où l'erreur est inacceptable, pas une option du tout. Il s'agit de transactions d'argent.
Et là où il était possible de tomber, l'essentiel était de se lever rapidement, nous avons utilisé une approche proche du SRE de Google. Itérativement, avec des montants, mais les projets pourraient être mis en œuvre dès que possible. Et maintenant, nous faisons tellement, et c'est très cool de se développer.
La troisième approche est l'innovation. Nous avons développé un bac à sable d'idées pour réaliser rapidement les premiers MVP avec nos ressources internes, ce qui nous permet de tester rapidement et à moindre coût. C'est le vrai «essayez vite, échouez vite». Cela vous a permis d'obtenir un budget et une autorité pour ceux qui ont proposé un projet sympa.
Le deuxième axe important était le géo-développement. Puis a ouvert 20 magasins par an (maintenant un peu plus lentement). Six mille employés. De nombreuses régions. Il a fallu réécrire toute la chaîne d'approvisionnement, pour développer rapidement des processus de rehaussement de l'infrastructure des magasins.
En 2017, nous avons décidé de devenir une plateforme de commandes de construction: c'est une stratégie prometteuse pour plusieurs années à venir.
Pour la géographie, nous avions besoin d'un grand back office informatique pour la croissance de l'entreprise et la croissance de la chaîne d'approvisionnement. Pour l'omnicanal (ordre général) - un niveau différent de SLA pour les systèmes internes, en temps réel, les microservices et la synchronisation entre des centaines de sous-systèmes. Il s'agit généralement d'un niveau de maturité informatique différent. Pour la plateforme, la vitesse du changement est également importante.
Au début, tout le monde pensait que l'agilité sauverait le monde. Avec les entrepreneurs, l'agilité peut ne pas être aussi efficace. D'où la volonté de
recruter 200 personnes dans le service informatique.
Nous avons observé la rapidité avec laquelle nous pouvons tout mettre en œuvre sans perte pour la marque. Quelque chose a pu être écrit rapidement, mais n'a pas eu le temps de préparer le service. Par exemple, s'il n'y a pas d'informations sur le stock, il n'y a aucun moyen de payer en ligne sans garantie que les marchandises seront réservées. Nous avons décomposé la chaîne des interdépendances en plusieurs. Maintenant, nous savons déjà que nous devons raccourcir les cycles, car les compétences de l'équipe sont toujours importantes. Maintenant, nous scions des éléments en petits morceaux, nous collectons une connexion, maintenant seule l'année en cours est dans les plans. Une stratégie à long terme, mais par fonctionnalités, est d'un an maximum, et de nombreuses équipes produit distinctes.