Wie wir die IT bei Leroy Merlin entwickelt haben: Umbau eines Motors für unterwegs

Vor vier Jahren wurde in jedem Geschäft ein separater Kundenstamm sowie ein weiterer vor Ort gepflegt.

In der vorherigen Serie: Vor drei Jahren haben wir beschlossen, dass wir unsere Entwicklung in Russland durchführen müssen. Vor zwei Jahren begannen sie, ihren eigenen Code zu schreiben, anstatt den Gabelcode der Muttergesellschaft zu ändern. In der heutigen Geschichte geht es darum, wie wir von einem großen Legacy-Monolithen zu einer Reihe kleiner Mikrodienste gewechselt sind, die durch eine Art Bus (Orchestrator) verbunden sind.

Der einfachste Benutzerfall: Bestellen Sie über die Website und holen Sie sie im Leroy Merlin Real Store in Russland ab. Bisher wurden Online-Shop-Bestellungen in einer anderen Anwendung im Allgemeinen und nach einem anderen Schema verarbeitet. Jetzt brauchten wir ein Omnichannel-Schaufenster, damit jede Bestellung in eine Benutzeroberfläche unterteilt wurde: eine Kassiererin in einem Geschäft, eine mobile Anwendung, ein Terminal in einem Geschäft, eine Website - was auch immer. Wenn Sie Linux in die Mikrowelle stellen, lassen Sie die Mikrowelle sein. Die Hauptsache ist, dass einige Schnittstellen die API nach hinten klopfen und sagen können, dass Sie hier so und so eine Bestellung aufgeben müssen. Und darauf erhielten sie eine klare Antwort. Die zweite Geschichte war mit Anfragen nach Verfügbarkeit und Eigenschaften der Waren von seiner Karte.

Auf der Vorderseite (wir werden bald darüber schreiben) haben wir ein Monster - AEM, und dahinter hinten waren zwei große Anwendungen: OPUS und MoVe. Die erste ist eine Datenbank mit den Eigenschaften jedes Produkts (von den Abmessungen bis zu den Beschreibungen), die zweite ist für die Kaufabwicklung verantwortlich, dh für den Monolithen an der Kasse. Wenn stark vereinfacht.

Was war los mit Opus?

OPUS ist eine große verteilte Basis. Genauer gesagt handelt es sich um eine Software, die eine Schnittstelle für den Zugriff auf die Datenbank bereitstellt, dh auf die Datenbank zugreift und beispielsweise die API durchsucht oder einfach so einstellt, dass Clients nicht direkt zur Datenbank wechseln. Diese Software funktioniert und wird in Frankreich unterstützt. Das zweite Merkmal ist, wie wir bereits gesagt haben , dass die Reihe der Verbesserungen sehr lang ist und wir im Vergleich zum Geschäftsbereich Frankreich nicht die höchste Priorität haben.

Mit großen Schwierigkeiten konnten wir verstehen, wie Entwickler ohne ein Team aus Frankreich Änderungen vornehmen konnten, und es fanden sehr lange Genehmigungen statt. Feature für sechs Monate veröffentlicht. Eigentlich wollten wir zuerst unsere eigene Entwicklung und deren Überprüfung durchführen, und dann kamen wir zu unserer eigenen Entwicklung, unserer Infrastruktur, unseren Tests und im Allgemeinen unserer eigenen. Gleichzeitig warf er fast ein Drittel des Legacy-Codes aus.

Aber zurück zu OPUS. Da das System relevante Informationen über Verfügbarkeit, Merkmale, Transaktionen und andere Dinge speichert, haben wir aus irgendeinem Grund darauf geklopft. Speziell für die Site bedeutete dies, dass Sie, wenn der Benutzer drei Produkte im Warenkorb hat, von jeder Seite aus auf die Datenbank klicken müssen, da die Relevanz überprüft wird. Selbst wenn Sie einmal für den Cache klopfen und ihn dann intelligent aktualisieren, gab es immer noch Funktionen. Wenn Sie die Katalogseite im Allgemeinen öffnen, wurden alle Produktspezifikationen von OPUS übernommen.

Der logische nächste Schritt ist, dass wir weniger häufig mit OPUS begonnen haben und unsere Basis erstellt haben (genauer gesagt, Microservices mit Basen). Das gesamte System wurde als russisches PUB bezeichnet.

Dann haben sie ein Orchester geschaffen, in dem bereits Aggregate gespeichert werden können, dh die gesammelten Daten für die Erstellung von Seiten. In dem Sinne, dass wenn der Benutzer die Seitenansicht von Karten zu Listen wechselt, es immer noch dasselbe Aggregat ist, nur die Vorderseite unterschiedlich ist.

Das heißt, wir haben das Original-OPUS verlassen (es befindet sich noch in Frankreich), aber unser fast vollständiger Spiegel „saugt“ es, wodurch die Basis in Stücke geschnitten wird und für die Montage in einem Orchester bereit ist. Und der Orchestrator sammelt und speichert die Aggregate (oder empfängt sie schnell und beginnt sie zu speichern), die andere Systeme benötigen. Infolgedessen funktioniert dieser Teil wie es sollte. Von der ursprünglichen Funktionalität des französischen OPUS sind noch etwa fünf Prozent übrig. Bald werden wir es komplett ersetzen.

Was war los mit MoVe?

Nichts Besonderes, außer der Tatsache, dass wir beschlossen haben, den gesamten Code wegzuwerfen, weil es:

1. War uralt auf einem alten Stapel.
2. Er berücksichtigte die Merkmale jeder Region "Leroy Merlin" in der Kette der IFs.
3. Es war so schwierig zu lesen und zu pflegen, dass die beste Refactoring-Methode darin bestand, "erneut zu schreiben und sofort normal zu dokumentieren".

Was wir getan haben. Nur haben wir es nicht als Monolith umgeschrieben, sondern damit begonnen, Microservices für jede einzelne Funktion zu erstellen. Und dann wurde ein Teil der Funktionalität von MoVe mit der Umstellung auf Microservice reibungslos weggenommen. Und so - eins nach dem anderen, bis die Funktionalität von MoVe vollständig beendet war. Das heißt, es funktioniert immer noch, aber irgendwo im luftleeren Raum und ohne Datenströme.

Da wir die Plattform aus Stücken gebaut haben, wurde das Projekt Lego genannt.

Lego hat diese Mitte komplett verändert. Ja, lassen Sie uns klarstellen: Ein echtes Backend ist ein Legacy-Bus, Dateisysteme, Datenbanken und andere fast infrastrukturelle Ebenen. Große Anwendungen rund um diese und Mikrodienste der Logik sind mittelgroß. Präsentation ist schon die Front.

Warum mussten Sie das alles neu schreiben?

Weil wir 15 Jahre nach der Eröffnung in Russland für jeden Fall mit einem separaten Kundenstamm zusammenlebten, und dies passte niemandem. Es gab auch keine Synchronisation. In anderen Ländern leben sie immer noch so.

Die Muttergesellschaft aus Frankreich hat die allgemeine Logistik übernommen, wir haben das Pixis-System wiederverwendet - dies ist ein einzelnes Geschäft mit Belegen, dh Kundenbestellungen: Ein Geschäft sieht die Bestellungen eines anderen Geschäfts. Dies löste jedoch das Omnichannel-Ordnungsproblem nicht vollständig. Daher war es notwendig, die Basis zu konsolidieren und die allgemeine Verarbeitung durchzuführen. Das ist wichtig.

Der zweite Grund war das Bundeskassengesetz: Mit unseren Entwicklungsfristen für ein gemeinsames System (und Tests) für alle Länder hätten wir Geldstrafen verhängt.

Eine ungefähr ähnliche Option wurde in Brasilien eingeführt: Dort wurde Leroy Merlin ohne Software der Muttergesellschaft gestartet, und es gelang ihnen. Das war vor der getrennten Entscheidung. Übrigens, sie engagieren sich sehr für Innersoren , sie haben eine sehr schnelle Entwicklung.

Pixis durfte tatsächlich nur an der Registrierkasse bestellen. Wir haben die Situation in drei Schritten geändert:

1. Zuerst haben wir eine mobile Anwendung für den Mitarbeiter erstellt, die sein Leben erheblich vereinfacht. Auf dieser Grundlage begannen sie, ein Ökosystem aufzubauen, in dem Schnittstellen mit Logik getrennt sind.
2. Während alles eingerichtet war, wurden Internetbestellungen von Hand an die Kasse getrieben.
3. Sie stellten der Reihe nach Microservices auf, die alles in der Mitte ersetzten.

Warum mussten Sie mit der Store-App beginnen? Weil wir im Vergleich zu Frankreich wieder einzigartige Prozesse haben. Zum Beispiel entschied sich eine Person, sechs Meter zehn Zentimeter einer Kette in einem Geschäft zu kaufen. Der Verkäufer schnitt ihn ab, gab ein Dokument, wie lange es ist und wie viel es kostet. Sie gehen mit diesem Stück Papier zur Kasse, Sie bezahlen dort. Aus logischer Sicht sollte der Verkauf nicht an der Abendkasse stattfinden, sondern der Verkäufer sollte ihn haben, aber tatsächlich beginnt an der Abendkasse das Interessanteste: Sie müssen sowohl die Ware als auch das Papier haben.

Am Ende werden wir eine Plattform für die Auftragserteilung sein: Jetzt wurden zum Beispiel zusätzlich zu unserem Hauptsystem Dienstleistungen für den Kauf von Dienstleistungen von Meistern hinzugefügt (ich habe eine Küche gekauft - ich habe die Installation bei einem externen Meister bestellt, aber wir haben sie gefunden und eine Garantie von uns selbst gegeben), Marktplatz ( direkter Kauf von einem Lieferanten über ein breiteres Spektrum), und bald muss es einen Partner geben, damit unsere Blöcke überall platziert werden können. So etwas wie das Einbetten von Amazon-Shops in Blogs, nur vielseitiger.

Wie wurde die Ersatzentscheidung getroffen?

Ich trete. Verfeinern Sie das Geschäftsmodell.

Wir haben geprüft, und zwar: Das Modell wie in Russland - jeden Tag niedrige Preise - ist erfolgreich. Leroy Merlin in Europa ist deutlich teurer, aber in Russland ist dies unsere Nische: ein Baugeschäft, in dem Sie definitiv Waren zum besten Preis finden können.

II Schritt. Erstellen Sie ein Client-Skript.

Das heißt, Prozesse so aufzubauen, wie wir möchten, dass sie aus Sicht des Kunden mit uns interagieren. Das heißt, eine einzige Vision davon, wer wir in ein paar Jahren sein wollen und wie es aus architektonischer Sicht aussieht.

III Schritt. Baue eine Architektur.

Teilen Sie diese Vision in spezifische TK und Architektur mit höheren Details auf. Es entstanden 110 Projekte, die wir fünf Jahre lang in fünf Kategorien unterteilt haben.

Dann bildeten sie spezialisierte Teams. Meistens sind dies ihre Mitarbeiter und ein Auftragnehmer. Anfangs litten sie sehr darunter: Als sie zum Produkt gingen, verstanden sie nicht wirklich, wie man so viele Veränderungen verdaut. Dann begannen sie, einen gemeinsamen Ansatz für Aufgaben zu entwickeln und den Anteil ihrer Entwicklung schrittweise zu erhöhen.

An den Stellen, an denen der Fehler kritisch war, arbeiteten sie nach NASA-Schemata, wo der Fehler nicht akzeptabel ist und überhaupt keine Option darstellt. Hier dreht sich alles um Geldtransaktionen.

Und wo es möglich war zu fallen, war die Hauptsache, schnell aufzustehen. Wir verwendeten einen Ansatz in der Nähe von Googles SRE. Iterativ mit Pfosten, aber Projekte könnten so schnell wie möglich umgesetzt werden. Und jetzt machen wir so viel und es ist sehr cool, sich zu entwickeln.

Der dritte Ansatz ist Innovation. Wir haben eine Sandbox mit Ideen entwickelt, um schnell die ersten MVPs mit unseren internen Ressourcen zu erstellen, mit denen wir schnell und kostengünstig testen können. Dies ist das wahre "schnell versuchen, schnell scheitern". Auf diese Weise konnten Sie ein Budget und eine Autorität für diejenigen erhalten, die ein cooles Projekt entwickelt haben.

Der zweite wichtige Schwerpunkt lag in der Geo-Entwicklung. Dann eröffneten 20 Geschäfte pro Jahr (jetzt etwas langsamer). Sechstausend Mitarbeiter. Viele Regionen. Es war notwendig, die gesamte Lieferkette neu zu schreiben, um schnell Prozesse zur Erhöhung der Infrastruktur der Geschäfte zu entwickeln.

2017 haben wir uns entschlossen, eine Plattform für Bauaufträge zu werden: Dies ist eine vielversprechende Strategie für die kommenden Jahre.

Für die Geografie brauchten wir ein großes IT-Backoffice für das Wachstum des Unternehmens und das Wachstum der Lieferkette. Für Omnichannel (allgemeine Reihenfolge) - eine andere SLA-Ebene für interne Systeme, Echtzeit, Mikrodienste und Synchronisation zwischen Hunderten von Subsystemen. Dies ist im Allgemeinen ein anderer IT-Reifegrad. Für die Plattform ist auch die Geschwindigkeit der Änderung wichtig.

Als es gerade anfing, dachten alle, dass Agilität die Welt retten würde. Bei Auftragnehmern ist Agilität möglicherweise nicht so effektiv. Daher der Wunsch , 200 Mitarbeiter in der IT-Abteilung zu rekrutieren .

Wir haben beobachtet, wie schnell wir alles ohne Verlust für die Marke umsetzen können. Etwas konnte schnell geschrieben werden, hatte aber keine Zeit, den Service vorzubereiten. Wenn beispielsweise keine Bestandsinformationen vorhanden sind, können Sie nicht online bezahlen, ohne die Garantie zu haben, dass die Waren reserviert werden. Wir haben die Kette der Abhängigkeiten in mehrere zerlegt. Jetzt wissen wir bereits, dass wir die Zyklen verkürzen müssen, weil die Kompetenzen des Teams immer noch wichtig sind. Jetzt sägen wir Features in kleinen Stücken, wir sammeln eine Verbindung, jetzt ist nur noch das aktuelle Jahr in Planung. Eine langfristige Strategie, jedoch nach Merkmalen, beträgt maximal ein Jahr und viele separate Produktteams.