Hallo! Mein Name ist Pasha Chernyak, ich bin ein führender Entwickler bei QIWI und heute möchte ich über das Unvermeidliche sprechen. Über Vermächtnis.
Beginnen wir mit der Frage: Was ist ein Legacy-Service? Ist ein Legacy-Service ein Service, den der Entwickler eine Woche / einen Monat / ein Jahr lang nicht berührt hat? Oder ist es ein Dienst, der von einem weniger erfahrenen Programmierer geschrieben wurde, zum Beispiel speziell von Ihnen, aber vor einem Jahr? Und jetzt bist du cooler und erfahrener. Oder ist ein Legacy-Service ein Service, für den Sie sich entschließen, ihn nie wieder bereitzustellen, und den Sie langsam ersetzen möchten? In jedem Fall ist es eine Zeitbombe, diesen Dienst unbeaufsichtigt zu lassen und nicht zu aktualisieren, was später explodieren kann.
Bevor wir uns mit der Arbeitsweise unserer Legacy-Services in QIWI befassen, erkläre ich Ihnen, wie wir die Services in der Brieftasche in Ordnung bringen. Seit zwei Jahren bin ich für die Leistung verantwortlich. Wenn es ein Problem gibt, rufen sie mich immer zuerst an. Normalerweise habe ich nicht die Kühnheit, um um 23:00 Uhr jemanden anzurufen, daher musste ich mich hinsetzen und alle Dienste unserer Domain verstehen.
Aber ich mag es, nachts zu schlafen, wie jeder andere auch, also versuchte ich, mich mit der Operation auseinanderzusetzen: "Leute, warum rufst du mich an?" Auf diese Frage erhielt er eine ziemlich knappe Antwort mit der Aufschrift "Wer noch?". Weil ich Reparaturdienste repariere und die Jungs einfach nicht wissen, wen sie anrufen sollen.
Aus diesem Grund haben wir in einer der Rückblicke des Wallet-Backend-Teams beschlossen, ein Kennzeichen zu erstellen, auf dem eine Liste unserer Services, Mikrodienste und Monolithen des Wallets sowie der Verantwortlichen aufgeführt ist. Tabletten sind im Allgemeinen in angemessenem Umfang nützlich.
Neben Informationen darüber, wer für was verantwortlich ist, wurden auch Fragen beantwortet: Wer ist der Eigentümer des Dienstes, wer ist für dessen Entwicklung, für die Architektur und den Lebenszyklus verantwortlich. Die Verantwortlichen für diesen Service sind Personen, die ihn reparieren können, wenn etwas passiert. Der Eigentümer des Dienstes hat das Recht, +2 in den Commits zu belassen. Die Verantwortlichen müssen ebenfalls bei der Überprüfung anwesend sein, bevor dieser Dienst das neue Commit übernimmt.
Mit der Zeit kamen neue Methoden zum Einsatz, zum Beispiel die Migration auf Kubernetes, alle Arten von Checkstyles, Spotbugs, Ktlint, die Verfügbarkeit von Protokollen in Kiban, Autodiscovery-Dienste, anstatt Adressen direkt und andere nützliche Dinge anzugeben. Und überall, wo unser Tisch es uns ermöglichte, die Relevanz unserer Dienstleistungen aufrechtzuerhalten. Für uns ist dies eine Checkliste, aus der hervorgeht, dass dieser Dienst weiß, wie dies zu tun ist, dies jedoch noch nicht. Wir sind jedoch weitergegangen und haben festgestellt, dass uns Informationen zu unseren Diensten fehlen, für die wir nachverfolgen, wo die Quellcodes des Dienstes liegen , wo die Montageaufgaben in TeamCity gestartet werden, wie sie bereitgestellt werden, wo die Quellcodes der End2end-Tests gespeichert werden, Fotos von der Architekturpflege, über getroffene Entscheidungen. Idealerweise wollte ich, dass all diese Informationen irgendwo liegen und zur Hand sind, wenn sie gebraucht werden. Aus diesem Grund ist unser Schild ein Ausgangspunkt für die Suche nach Informationen geworden.
Aber QIWI ist, obwohl es den Geist eines Startups beibehält, ein großes Unternehmen. Wir sind bereits 12 Jahre alt und die Teams ändern sich: Die Leute gehen, die Leute kommen, neue Teams werden gebildet. Und wir haben auf unserer Domain mehrere Dienste gefunden, die wir geerbt haben. Es kam etwas mit Entwicklern aus anderen Teams, etwas, das nur irgendwie indirekt mit dem Wallet zusammenhängt, sodass der Service jetzt in unserer Bilanz steht. Womit umgehen und wie es funktioniert - warum? Der Service funktioniert und wir haben Produkteigenschaften, die abgewaschen werden müssen.
Wie es passiert
Aber irgendwann stellen wir fest, dass der Dienst seine Funktion nicht mehr erfüllt, etwas ist kaputt - was ist in dieser Situation zu tun? Der Service hat einfach aufgehört zu funktionieren. Absolut. Dies erfuhren wir erstens zufällig und zweitens sechs Monate später. Es passiert Das einzige, was wir wussten, war, auf welchen virtuellen Maschinen der Service bereitgestellt wurde, wo seine Quellen liegen und das ist alles. Wir lassen git klonen und tauchen in die Gedanken der Person ein, die dies vor einigen Jahren geschrieben hat, aber was sehen wir? Wir kennen keinen Spring Boot, obwohl wir an alles gewöhnt sind, haben wir einen vollen Stack und all das. Vielleicht gibt es ein Spring Framework? Aber nein
Der Typ, der das alles schrieb, war hart und schrieb alles in reinem Java. Es gibt keine vertrauten Tools für den Entwickler, und die Idee entsteht - wir sollten das alles neu schreiben. Wir haben auch Microservices und von jedem Toaster hören wir die bekannten "Jungs, Microservices sind das, was Sie brauchen!". Wenn plötzlich etwas nicht mehr stimmt, nehmen Sie ruhig eine Sprache und alles wird gut.
Die Sache ist, dass wir jetzt keinen Kunden haben, der für diesen Service verantwortlich ist. Was waren seine geschäftlichen Anforderungen, was sollte dieser Service im Allgemeinen tun? Und der Service ist eng in Ihre Geschäftsprozesse integriert.
Sagen Sie mir jetzt, wie einfach es ist, einen Service umzuschreiben, ohne die geschäftlichen Anforderungen zu kennen. Dem Service ist nicht klar, wie er protokolliert wird, ob Metriken vorliegen, ist unbekannt. Was sie sind, wenn überhaupt, ist umso unbekannter. Und während sie im Dienst sind, gibt es eine große Anzahl von Klassen unklarer Geschäftslogik. Etwas ist in einer Art Datenbank enthalten, von der wir auch noch nichts wissen.
Wo soll ich anfangen?
Vom logischsten - mit der Verfügbarkeit von Tests. Zumindest wird dort normalerweise eine Art Logik geschrieben, und es können Schlussfolgerungen darüber gezogen werden, was passiert. Jetzt ist TDD in Mode, aber wir sehen, dass vor fünf Jahren fast alles so war wie heute: Es gibt fast keine Komponententests, und sie werden uns absolut nichts sagen. Nun, außer vielleicht einer Art von Überprüfung, wie XML mit einer Art benutzerdefiniertem Zertifikat signiert ist.
Wir konnten unter dem Code nichts verstehen und haben einen Blick darauf geworfen, wo sich die virtuelle Maschine befand. Wir haben die Serviceprotokolle geöffnet und dabei einen http-Client-Fehler festgestellt. Dabei handelt es sich um ein selbstsigniertes Zertifikat, das gewissenlos in die Ressourcen der Anwendung eingearbeitet wurde. Wir haben unsere Analysten kontaktiert, sie haben um ein neues Zertifikat gebeten, sie haben es uns ausgestellt und der Service funktioniert wieder. Das scheint alles zu sein. Oder nicht? Der Service funktioniert dennoch und erfüllt einige Funktionen, die unser Unternehmen benötigt. Wir haben einige Standards für die Anwendungsentwicklung, die Sie höchstwahrscheinlich haben. Speichern Sie die Protokolle beispielsweise nicht auf dem Knoten im Ordner, sondern in einer Art Speicher, z. B. einem Gummiband, und betrachten Sie sie im Kiban. Sie können sich an die goldenen Metriken erinnern. Das heißt, die Belastung des Dienstes, die Anzahl der Anfragen für den Dienst, ob er lebt oder nicht, wie sein HealthCheck abläuft. Zumindest helfen Ihnen diese Kennzahlen dabei, herauszufinden, wann sie wie ein böser Traum mit gutem Gewissen stillgelegt und vergessen werden können.
Was zu tun ist
Aus diesem Grund fügen wir dem Tablet einen solchen alten Dienst hinzu, und dann suchen wir unter den Entwicklern nach Freiwilligen, die sich um den Dienst kümmern und ihn in die richtige Reihenfolge bringen: Sie schreiben mindestens einige Informationen über den Dienst, fügen Verknüpfungen zu Dashboards in Graphan hinzu, führen Assemblierungsaufgaben durch und verstehen, wie Stellen Sie die Anwendung bereit, laden Sie keine Dateien mit Ihren Händen über FTP hoch.
Die Hauptsache ist, wie viel diese nützliche Freiwilligenarbeit kosten wird. Ein Sprint für einen mehr oder weniger erfahrenen Entwickler, zum Beispiel während einer 20% igen technischen Verschuldung. Und wie lange hat es gedauert, die tief verwurzelte Logik der Kommunikation mit einem bestimmten Staatssystem zu verstehen und auf neuere Technologien umzustellen? Ich kann mich nicht dafür verbürgen, vielleicht einen Monat, oder vielleicht zwei Teamworks. Dies sage ich aus der Erfahrung der Integration zum gegenwärtigen Zeitpunkt mit einigen neuen Diensten.
Gleichzeitig wird der Geschäftswert nicht ausgeschöpft. Absolut. Es ist normal, den Support-Service in Anspruch zu nehmen und ein wenig Zeit damit zu verbringen. Aber nach unseren Standard-Tänzen mit dem Service haben wir es der Tabelle hinzugefügt, Informationen hinzugefügt und vielleicht werden wir es eines Tages umschreiben. Aber jetzt erfüllt es unsere Servicestandards.
Aus diesem Grund möchte ich einen Plan erstellen, was mit Legacy-Diensten geschehen soll.
Vermächtnis von Grund auf neu zu schreiben, ist eine schlechte IdeeIm Ernst, Sie müssen nicht einmal darüber nachdenken. Es ist klar, dass wir möchten, und einige Vorteile werden gesehen, aber in der Regel ist dies für niemanden erforderlich, auch für Sie.
NachschlagewerkDurchsuchen Sie die Quellcodes Ihrer Anwendungen, erstellen Sie ein Verzeichnis, in dem angegeben wird, woran und wo es liegt und wie es funktioniert, und geben Sie dort die Projektbeschreibung (bedingte readme.md) ein, um schnell zu verstehen, wo sich die Protokolle und Metriken befinden. Ein Entwickler, der sich nach Ihnen darum kümmert, wird Ihnen nur danken.
Verstehe die DomainWenn Sie eine Domain besitzen, versuchen Sie, immer am Puls der Zeit zu bleiben. Es klingt kitschig, aber nicht jeder stellt sicher, dass sich die Dienste in einem einzigen Schlüssel befinden. Das Arbeiten in einem Standard ist jedoch wesentlich einfacher.