Hallo!
Mein Name ist Mikhail, ich bin stellvertretender IT-Direktor bei der Firma Sportmaster. Ich möchte die Geschichte erzählen, wie wir mit den Herausforderungen umgegangen sind, die während der Pandemie entstanden sind.
In den ersten Tagen der neuen Realitäten fror das übliche Offline-Handelsformat von Sportmaster ein und die Auslastung unseres Online-Kanals, vor allem im Hinblick auf die Lieferung an die Adresse des Kunden, stieg um das Zehnfache. In nur wenigen Wochen haben wir ein riesiges Offline-Geschäft in ein Online-Geschäft umgewandelt und den Service an die Bedürfnisse unserer Kunden angepasst.
Im Grunde wurde unser eigentlicher Nebenbetrieb zu unserem Kerngeschäft. Die Bedeutung jeder Online-Bestellung hat extrem zugenommen. Es galt, jeden Rubel zu sparen, den der Kunde dem Unternehmen einbrachte.
Um schnell auf Kundenanfragen reagieren zu können, haben wir am Hauptsitz des Unternehmens ein zusätzliches Kontaktcenter eröffnet und können nun etwa 285 Anrufe pro Woche entgegennehmen. Gleichzeitig haben wir 270 Filialen auf ein neues kontaktloses und sicheres Betriebsformat umgestellt, das es den Kunden ermöglicht, Bestellungen entgegenzunehmen, und den Mitarbeitern, ihre Arbeitsplätze zu behalten.
Während des Transformationsprozesses stießen wir auf zwei Hauptprobleme. Erstens hat die Belastung unserer Online-Ressourcen erheblich zugenommen (Sergey wird Ihnen erzählen, wie wir damit umgegangen sind). Zweitens hat der Fluss seltener (Prä-COVID-)Operationen um ein Vielfaches zugenommen, was wiederum ein hohes Maß an schneller Automatisierung erforderte. Um dieses Problem zu lösen, mussten wir schnell Ressourcen aus Bereichen verlagern, die zuvor die wichtigsten waren. Elena wird Ihnen erzählen, wie wir damit umgegangen sind.
Betrieb von Online-Diensten
Kolesnikov Sergey, verantwortlich für den Betrieb des Online-Shops und der Microservices
Von dem Moment an, als unsere Einzelhandelsgeschäfte für Besucher geschlossen wurden, verzeichneten wir einen Anstieg von Kennzahlen wie der Anzahl der Benutzer, der Anzahl der in unserer Anwendung aufgegebenen Bestellungen und der Anzahl der Anfragen an Anwendungen.
Anzahl der Bestellungen vom 18. März bis 31. MärzAnzahl der Anfragen an Online-Zahlungs-MicroservicesAnzahl der auf der Website aufgegebenen Bestellungen
Im ersten Diagramm sehen wir, dass der Anstieg ungefähr das 14-fache betrug, im zweiten das 4-fache. Für uns ist die Reaktionszeitmetrik unserer Anwendungen die aussagekräftigste.
In dieser Grafik sehen wir die Reaktion der Fronten und Anwendungen und haben selbst festgestellt, dass wir kein Wachstum als solches feststellen konnten.
Dies ist vor allem darauf zurückzuführen, dass wir Ende 2019 mit den Vorbereitungsarbeiten begonnen haben. Jetzt sind unsere Dienste reserviert, die Fehlertoleranz ist auf der Ebene der physischen Server, Virtualisierungssysteme, Docker und darin enthaltenen Dienste gewährleistet. Gleichzeitig ermöglicht uns die Kapazität unserer Serverressourcen, Mehrfachbelastungen standzuhalten.
Das wichtigste Werkzeug, das uns in dieser ganzen Geschichte geholfen hat, war unser Überwachungssystem. Zwar verfügten wir bis vor Kurzem über kein einziges System, mit dem wir Kennzahlen auf allen Ebenen erfassen konnten, von der Ebene der physischen Ausrüstung und Hardware bis hin zur Ebene der Geschäftskennzahlen.
Formal gab es im Unternehmen eine Überwachung, die jedoch in der Regel verteilt war und im Verantwortungsbereich bestimmter Abteilungen lag. Tatsächlich hatten wir bei einem Vorfall fast nie ein gemeinsames Verständnis darüber, was genau passierte, es gab keine Kommunikation und das führte oft dazu, dass wir im Kreis herumliefen, um das Problem zu finden und zu isolieren, damit es behoben werden konnte.
Irgendwann dachten und entschieden wir, dass wir genug davon hatten, das durchzuhalten – wir brauchten ein einheitliches System, um das Gesamtbild vollständig zu sehen. Die wichtigsten Technologien, die in unserem Stack enthalten sind, sind Zabbix als Alarmierungs- und Metrikspeicherzentrum, Prometheus zum Sammeln und Speichern von Anwendungsmetriken, Stack ELK zum Protokollieren und Speichern von Daten aus dem gesamten Überwachungssystem sowie Grafana zur Visualisierung, Swagger und Docker und andere nützliche und Ihnen vertraute Dinge.
Dabei nutzen wir nicht nur auf dem Markt verfügbare Technologien, sondern entwickeln auch einige eigene. Wir stellen beispielsweise Dienste zur Integration von Systemen untereinander bereit, also eine Art API zum Sammeln von Metriken. Darüber hinaus arbeiten wir an unseren eigenen Überwachungssystemen – auf der Ebene der Geschäftsmetriken verwenden wir UI-Tests. Und auch ein Bot in Telegram, um Teams zu benachrichtigen.
Wir versuchen auch, das Überwachungssystem für Teams zugänglich zu machen, damit sie ihre Metriken unabhängig speichern und damit arbeiten können, einschließlich der Einrichtung von Warnungen für einige eng gefasste Metriken, die nicht weit verbreitet sind.
Im gesamten System streben wir nach Proaktivität und möglichst schneller Lokalisierung von Vorfällen. Darüber hinaus ist die Anzahl unserer Microservices und Systeme in letzter Zeit deutlich gewachsen und die Anzahl der Integrationen entsprechend gewachsen. Und im Rahmen der Optimierung des Prozesses zur Diagnose von Vorfällen auf Integrationsebene entwickeln wir ein System, mit dem Sie systemübergreifende Prüfungen durchführen und das Ergebnis anzeigen können, wodurch Sie die Hauptprobleme im Zusammenhang mit Importen und der Interaktion von Systemen mit finden können gegenseitig.
Natürlich haben wir hinsichtlich der Betriebssysteme noch Raum für Wachstum und Weiterentwicklung und daran arbeiten wir aktiv. Erfahren Sie mehr über unser Überwachungssystem .
Technische Tests
Orlov Sergey leitet das Kompetenzzentrum für Web- und Mobilentwicklung
Seit Beginn der Ladenschließungen standen wir aus entwicklungspolitischer Sicht vor verschiedenen Herausforderungen. Zunächst einmal der Laststoß als solcher. Es ist klar, dass sich das System bei hoher Belastung mit einem traurigen Knall in einen Kürbis verwandeln kann, wenn keine geeigneten Maßnahmen ergriffen werden, die Leistung völlig abnimmt oder sogar seine Funktionalität verloren geht.
Der zweite Aspekt, der etwas weniger offensichtlich ist, besteht darin, dass das System unter hoher Auslastung sehr schnell geändert werden musste, um sich an veränderte Geschäftsprozesse anzupassen. Manchmal mehrmals am Tag. In vielen Unternehmen gilt die Regel, dass bei vielen Marketingaktivitäten keine Änderungen am System erforderlich sind. Überhaupt keine, lass es funktionieren, solange es funktioniert.
Und wir hatten im Grunde einen endlosen Black Friday, in dem es notwendig war, das System zu ändern. Und jeder Fehler, jedes Problem oder jeder Ausfall im System wäre für das Unternehmen sehr kostspielig.
Mit Blick auf die Zukunft kann ich sagen, dass wir diese Tests gemeistert haben, alle Systeme der Belastung standgehalten haben, sich problemlos skalieren ließen und wir keine globalen technischen Ausfälle erlebt haben.
Es gibt vier Säulen, auf denen die Fähigkeit des Systems, hohen Stoßbelastungen standzuhalten, beruht. Die erste davon ist die Überwachung, über die Sie oben gelesen haben. Ohne ein integriertes Überwachungssystem ist es nahezu unmöglich, Systemengpässe zu finden. Ein gutes Überwachungssystem ist wie Heimkleidung: Es sollte bequem und auf Sie zugeschnitten sein.
Der zweite Aspekt ist das Testen. Wir nehmen diesen Punkt sehr ernst: Wir schreiben klassische Units, Integrationstests, Lasttests und viele andere für jedes System. Wir schreiben auch eine Teststrategie und versuchen gleichzeitig, das Testniveau so weit zu erhöhen, dass wir keine manuellen Überprüfungen mehr benötigen.
Die dritte Säule ist die CI/CD-Pipeline. Die Prozesse zum Erstellen, Testen und Bereitstellen einer Anwendung sollten so weit wie möglich automatisiert werden; es sollte kein manueller Eingriff erfolgen. Das Thema CI/CD-Pipeline ist ziemlich tiefgründig und ich werde es nur kurz ansprechen. Erwähnenswert ist lediglich, dass wir über eine CI/CD-Pipeline-Checkliste verfügen, die jedes Produktteam mithilfe von Kompetenzzentren durchläuft.
Und hier ist die Checkliste
Auf diese Weise werden viele Ziele erreicht. Dabei handelt es sich um API-Versionierung und Funktionsumschaltung, um den Release-Train zu vermeiden und eine Abdeckung verschiedener Tests auf einem solchen Niveau zu erreichen, dass die Tests vollständig automatisiert sind, Bereitstellungen nahtlos sind usw.
Die vierte Säule sind architektonische Prinzipien und technische Lösungen. Wir können noch lange viel über Architektur reden, aber ich möchte ein paar Prinzipien hervorheben, auf die ich mich konzentrieren möchte.
Zunächst müssen Sie Spezialwerkzeuge für bestimmte Aufgaben auswählen. Ja, es klingt selbstverständlich und es ist klar, dass Nägel mit einem Hammer eingeschlagen und Armbanduhren mit speziellen Schraubendrehern zerlegt werden sollten. Aber in unserer Zeit streben viele Tools nach Universalisierung, um das größtmögliche Benutzersegment abzudecken: Datenbanken, Caches, Frameworks und den Rest. Wenn Sie beispielsweise die MongoDB-Datenbank verwenden, funktioniert sie mit Transaktionen mit mehreren Dokumenten, und die Oracle-Datenbank funktioniert mit JSON. Und es scheint, dass alles für alles verwendet werden kann. Wenn wir jedoch für Produktivität stehen, müssen wir die Stärken und Schwächen jedes Tools klar verstehen und diejenigen verwenden, die wir für unsere Aufgabenklasse benötigen.
Zweitens muss bei der Gestaltung von Systemen jede Komplexitätssteigerung begründet werden. Das müssen wir uns ständig vor Augen halten, das Prinzip der Low Coupling ist jedem bekannt. Ich glaube, dass es auf der Ebene eines bestimmten Dienstes, auf der Ebene des gesamten Systems und auf der Ebene der Architekturlandschaft angewendet werden sollte. Wichtig ist auch die Möglichkeit, jede Systemkomponente entlang des Lastpfads horizontal zu skalieren. Wenn Sie über diese Fähigkeit verfügen, wird die Skalierung nicht schwierig sein.
Apropos technische Lösungen: Wir haben die Produktteams gebeten, eine Reihe neuer Empfehlungen, Ideen und Lösungen vorzubereiten, die sie als Vorbereitung auf die nächste Arbeitsbelastungswelle umsetzten.
Keshi
Es ist notwendig, die Auswahl lokaler und verteilter Caches bewusst anzugehen. Manchmal ist es sinnvoll, beides innerhalb desselben Systems zu verwenden. Wir haben beispielsweise Systeme, in denen einige der Daten im Wesentlichen ein Showcase-Cache sind, das heißt, die Quelle der Aktualisierungen befindet sich hinter dem System selbst und die Systeme ändern sich nicht diese Daten. Für diesen Ansatz verwenden wir den lokalen Caffeine Cache.
Und es gibt Daten, die das System im Betrieb aktiv verändert, und hier nutzen wir bereits einen verteilten Cache mit Hazelcast. Dieser Ansatz ermöglicht es uns, die Vorteile eines verteilten Caches dort zu nutzen, wo sie wirklich benötigt werden, und die Servicekosten für die Verbreitung von Hazelcast-Clusterdaten dort zu minimieren, wo wir darauf verzichten können. Wir haben viel über Caches geschrieben. и .
Darüber hinaus hat uns die Umstellung des Serializers auf Kryo in Hazelcast einen guten Schub gegeben. Und der Übergang von ReplicatedMap zu IMap + Near Cache in Hazelcast ermöglichte es uns, die Datenbewegung im gesamten Cluster zu minimieren.
Ein kleiner Hinweis: Im Falle einer Massen-Cache-Ungültigmachung ist manchmal die Taktik anwendbar, den zweiten Cache aufzuwärmen und dann dorthin zu wechseln. Es scheint, dass wir mit diesem Ansatz einen doppelten Speicherverbrauch erzielen sollten, aber in der Praxis sank der Speicherverbrauch in den Systemen, in denen dies praktiziert wurde.
Reaktiver Stapel
Wir nutzen den reaktiven Stack in einer Vielzahl von Systemen. In unserem Fall ist das Webflux oder Kotlin mit Coroutinen. Der reaktive Stapel ist besonders gut geeignet, wenn wir langsame Eingabe-Ausgabe-Vorgänge erwarten. Zum Beispiel Aufrufe langsamer Dienste, Arbeiten mit dem Dateisystem oder Speichersystemen.
Der wichtigste Grundsatz besteht darin, das Blockieren von Anrufen zu vermeiden. Reaktive Frameworks verfügen über eine kleine Anzahl von Live-Service-Threads, die unter der Haube laufen. Wenn wir uns unachtsam erlauben, einen direkten Blockierungsaufruf zu tätigen, beispielsweise einen JDBC-Treiberaufruf, kommt das System einfach zum Stillstand.
Versuchen Sie, Fehler in Ihre eigene Laufzeitausnahme umzuwandeln. Der eigentliche Ablauf der Programmausführung verlagert sich auf reaktive Frameworks und die Codeausführung wird nichtlinear. Daher ist es sehr schwierig, Probleme mithilfe von Stack-Traces zu diagnostizieren. Und hier wäre die Lösung, für jeden Fehler klare, objektive Laufzeitausnahmen zu schaffen.
Elasticsearch
Wählen Sie bei Verwendung von Elasticsearch keine ungenutzten Daten aus. Auch das ist im Prinzip ein ganz einfacher Ratschlag, der jedoch meist vergessen wird. Wenn Sie mehr als 10 Datensätze gleichzeitig auswählen müssen, müssen Sie Scrollen verwenden. Um eine Analogie zu verwenden: Es ist ein bisschen wie ein Cursor in einer relationalen Datenbank.
Verwenden Sie Postfilter nicht, es sei denn, dies ist erforderlich. Bei großen Datenmengen in der Hauptstichprobe belastet dieser Vorgang die Datenbank erheblich.
Verwenden Sie gegebenenfalls Massenvorgänge.
API
Berücksichtigen Sie beim Entwerfen einer API Anforderungen zur Minimierung der übertragenen Daten. Dies gilt insbesondere im Zusammenhang mit der Front: An dieser Schnittstelle gehen wir über die Kanäle unserer Rechenzentren hinaus und arbeiten bereits an dem Kanal, der uns mit dem Kunden verbindet. Wenn es auch nur das geringste Problem gibt, führt zu viel Verkehr zu einer negativen Benutzererfahrung.
Und schließlich: Werfen Sie nicht eine ganze Menge Daten weg, sondern machen Sie sich über den Vertrag zwischen Verbrauchern und Lieferanten im Klaren.
Organisatorische Transformation
Eroshkina Elena, stellvertretende Direktorin für IT
In dem Moment, als die Quarantäne verhängt wurde und die Notwendigkeit entstand, das Tempo der Online-Entwicklung deutlich zu steigern und Omnichannel-Dienste einzuführen, befanden wir uns bereits im Prozess der organisatorischen Transformation.
Ein Teil unserer Struktur wurde auf die Arbeit nach den Prinzipien und Praktiken des Produktansatzes übertragen. Es wurden Teams gebildet, die nun für den Betrieb und die Entwicklung jedes Produkts verantwortlich sind. Die Mitarbeiter in solchen Teams sind zu 100 % eingebunden und strukturieren ihre Arbeit je nach Wunsch mit Scrum oder Kanban, richten eine Deployment-Pipeline ein, implementieren technische Praktiken, Qualitätssicherungspraktiken und vieles mehr.
Glücklicherweise befand sich der Großteil unserer Produktteams im Bereich Online- und Omnichannel-Dienste. Dadurch konnten wir in kürzester Zeit (im Ernst, buchstäblich in zwei Tagen) ohne Effizienzverlust in den Remote-Arbeitsmodus wechseln. Der maßgeschneiderte Prozess ermöglichte es uns, uns schnell an neue Arbeitsbedingungen anzupassen und ein relativ hohes Tempo bei der Bereitstellung neuer Funktionen aufrechtzuerhalten.
Darüber hinaus müssen wir die Teams stärken, die an der Spitze des Online-Geschäfts stehen. In diesem Moment wurde klar, dass wir dies nur mit internen Ressourcen schaffen konnten. Und etwa 50 Menschen wechselten innerhalb von zwei Wochen den Bereich, in dem sie zuvor gearbeitet hatten, und engagierten sich für die Arbeit an einem für sie neuen Produkt.
Dafür waren keine besonderen Managementanstrengungen erforderlich, denn neben der Organisation unseres eigenen Prozesses, der technischen Verbesserung des Produkts und Qualitätssicherungspraktiken lehren wir unsere Teams, sich selbst zu organisieren – ihren eigenen Produktionsprozess zu verwalten, ohne administrative Ressourcen in Anspruch zu nehmen.
Wir konnten unsere Managementressourcen genau dort konzentrieren, wo sie gerade gebraucht wurden – auf die gemeinsame Abstimmung mit dem Unternehmen: Was ist für unseren Kunden gerade wichtig, welche Funktionalität sollte zuerst implementiert werden, was muss getan werden, um unsere Durchsatzfähigkeit zu erhöhen zur Auslieferung und Bearbeitung von Bestellungen. All dies und ein klares Vorbild haben es in dieser Zeit ermöglicht, unsere Produktionswertströme mit dem zu beladen, was wirklich wichtig und notwendig ist.
Es ist klar, dass man sich bei Remote-Arbeit und einem hohen Veränderungstempo, wenn Geschäftsindikatoren von der Beteiligung aller abhängen, nicht nur auf interne Gefühle aus der Serie „Läuft bei uns alles gut?“ verlassen kann. Ja, es scheint gut zu sein. Es werden objektive Kennzahlen des Produktionsprozesses benötigt. Wir haben diese, sie stehen jedem zur Verfügung, der sich für die Kennzahlen von Produktteams interessiert. Zuallererst das Team selbst, das Unternehmen, die Subunternehmer und das Management.
Alle zwei Wochen wird mit jedem Team ein Status gehalten, in dem 10 Minuten lang Kennzahlen analysiert, Engpässe im Produktionsprozess identifiziert und eine gemeinsame Lösung erarbeitet werden: Was kann getan werden, um diese Engpässe zu beseitigen? Hier können Sie sofort das Management um Hilfe bitten, wenn ein identifiziertes Problem außerhalb des Einflussbereichs der Teams oder der Expertise von Kollegen liegt, die möglicherweise bereits auf ein ähnliches Problem gestoßen sind.
Wir verstehen jedoch, dass wir, um um ein Vielfaches schneller zu werden (und genau dieses Ziel haben wir uns gesetzt), noch viel lernen und es in unserer täglichen Arbeit umsetzen müssen. Derzeit skalieren wir unseren Produktansatz weiterhin auf andere Teams und neue Produkte. Dazu mussten wir ein für uns neues Format meistern – eine Online-Methodenschule.
Methodologen, Menschen, die Teams dabei helfen, einen Prozess aufzubauen, Kommunikation aufzubauen und die Arbeitseffizienz zu verbessern, sind im Wesentlichen Akteure des Wandels. Derzeit arbeiten die Absolventen unseres ersten Jahrgangs in Teams und helfen ihnen, erfolgreich zu sein.
Ich denke, dass die aktuelle Situation uns Chancen und Perspektiven eröffnet, die uns vielleicht selbst noch nicht vollständig bewusst sind. Aber die Erfahrung und Praxis, die wir derzeit sammeln, bestätigt, dass wir den richtigen Entwicklungsweg gewählt haben, dass wir diese neuen Möglichkeiten auch in Zukunft nicht verpassen werden und in der Lage sein werden, genauso effektiv auf die Herausforderungen zu reagieren, denen sich Sportmaster gegenübersieht.
Befund
In dieser schwierigen Zeit haben wir die Grundprinzipien der Softwareentwicklung formuliert, die meiner Meinung nach für jedes Unternehmen, das sich damit beschäftigt, relevant sein werden.
Leute. Darauf beruht alles. Die Mitarbeiter müssen Spaß an ihrer Arbeit haben und die Ziele des Unternehmens und der Produkte, an denen sie arbeiten, verstehen. Und natürlich konnten sie sich beruflich weiterentwickeln.
Технология. Es ist notwendig, dass das Unternehmen einen ausgereiften Ansatz für die Arbeit mit seinem Technologie-Stack verfolgt und Kompetenzen dort aufbaut, wo sie wirklich benötigt werden. Es klingt sehr einfach und offensichtlich. Und sehr oft ignoriert.
Prozesse. Es ist wichtig, die Arbeit von Produktteams und Kompetenzzentren richtig zu organisieren, eine Interaktion mit dem Unternehmen herzustellen, um als Partner mit ihm zusammenzuarbeiten.
Im Großen und Ganzen haben wir so überlebt. Mit einem lauten Klicken auf die Stirn wurde die Hauptthese unserer Zeit noch einmal bestätigt
Auch wenn Sie ein großes Offline-Unternehmen mit vielen Geschäften und einer Reihe von Städten sind, in denen Sie tätig sind, sollten Sie Ihr Online-Geschäft ausbauen. Dabei handelt es sich nicht nur um einen zusätzlichen Vertriebskanal oder eine schöne Anwendung, über die man auch etwas kaufen kann (und auch weil die Konkurrenz auch schöne hat). Dies ist kein Ersatzreifen für alle Fälle, der Ihnen hilft, den Sturm zu überstehen.
Dies ist eine absolute Notwendigkeit. Darauf müssen nicht nur Ihre technischen Fähigkeiten und Ihre Infrastruktur vorbereitet sein, sondern auch Ihre Mitarbeiter und Prozesse. Schließlich können Sie innerhalb weniger Stunden schnell zusätzlichen Arbeitsspeicher und Speicherplatz kaufen, neue Instanzen bereitstellen usw. Doch darauf müssen Menschen und Prozesse im Vorfeld vorbereitet werden.
Source: habr.com