{"id":53442,"date":"2019-12-02T00:00:00","date_gmt":"2019-12-01T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/legacy-servisy-v-vashej-infrastrukture"},"modified":"2020-02-18T14:01:20","modified_gmt":"2020-02-18T11:01:20","slug":"legacy-servisy-v-vashej-infrastrukture","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Legacy-Services in Ihrer Infrastruktur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo! Ich hei\u00dfe Pasha Tschernjak, ich bin leitender Entwickler bei QIWI, und heute m\u00f6chte ich \u00fcber das Unvermeidliche sprechen. \u00dcber Legacy.<\/p>\n

Fangen wir mit der Frage an: Was ist ein Legacy-Service? Ein Legacy-Service ist ein Dienst, mit dem der Entwickler seit einer Woche\/Monat\/Jahr nichts mehr zu tun hatte? Oder ist es ein Dienst, der von einem weniger erfahrenen Programmierer, zum Beispiel von Ihnen, vor einem Jahr geschrieben wurde? Aber mittlerweile sind Sie besser und erfahrener. Oder bedeutet Legacy-Service, dass Sie beschlossen haben, diesen Dienst nie wieder zu committen und langsam eine Abl\u00f6sung daf\u00fcr vorbereiten? In jedem Fall ist es eine Zeitbombe, einen solchen Dienst unbeaufsichtigt zu lassen und nicht zu aktualisieren.<\/p>\n

\"Legacy-Services<\/a><\/noindex><\/p>\n

Bevor ich dazu \u00fcbergehe, wie wir bei QIWI mit unseren Legacy-Services arbeiten, m\u00f6chte ich erkl\u00e4ren, wie wir Ordnung bei den Diensten im Wallet geschaffen haben. Seit zwei Jahren bin ich f\u00fcr die Funktionalit\u00e4t verantwortlich. Wenn es ein Problem gibt, rufen sie immer zuerst mich an. Ich habe normalerweise nicht die Dreistigkeit, um 23 Uhr jemanden anders anzurufen, also musste ich mich setzen und mich mit allen Diensten in unserem Bereich befassen. <\/p>\n

Aber ich, wie jeder andere Mensch, liebe es, nachts zu schlafen, also habe ich versucht, das Betriebsklima zu kl\u00e4ren: \u201eLeute, warum ruft ihr mich an?\u201c. Darauf bekam ich eine recht knappe Antwort: \u201eWen sonst?\u201c. Denn ich repariere die Dienste, und die Leute wissen schlichtweg nicht, an wen sie sich wenden sollen.<\/p>\n

Deshalb haben wir auf einer der Retrospektiven des Backend-Teams des Wallets beschlossen, eine Tabelle zu erstellen, auf der eine Liste unserer Dienste, Mikrodienste und Monolithen des Wallets sowie die Verantwortlichen daf\u00fcr vermerkt sind. Tabellen sind im Allgemeinen n\u00fctzlich, in einem vern\u00fcnftigen Rahmen.
\n<\/a><\/noindex>
\nNeben den Informationen dar\u00fcber, wer wof\u00fcr verantwortlich ist, gab es auch Antworten auf Fragen: Wer ist der Besitzer des Dienstes, wer ist f\u00fcr dessen Entwicklung, Architektur und Lebenszyklus verantwortlich. Die Personen, die f\u00fcr diesen Dienst verantwortlich sind, sind die, die ihn im Bedarfsfall reparieren k\u00f6nnen. Der Dienstbesitzer hat das Recht, +2 in den Commits zu lassen, die Verantwortlichen m\u00fcssen ebenfalls unbedingt beim Review anwesend sein, bevor dieser Dienst einen neuen Commit \u00fcbernimmt.<\/p>\n

Die Zeit verging, neue Praktiken wurden angewendet, wie zum Beispiel die Migration zu Kubernetes, verschiedene checkstyle, spotbugs, ktlint, das Vorhandensein von Logs in Kibana, die autodiscovery von Diensten anstelle der direkten Angabe von Adressen und andere n\u00fctzliche Dinge. Und \u00fcberall erm\u00f6glichte unsere Tabelle es, die Aktualit\u00e4t unserer Dienste aufrechtzuerhalten. F\u00fcr uns ist das eine Art Checkliste, die besagt, dass dieser Dienst das kann, und das noch nicht. Aber wir gingen weiter, erkannten, dass uns Informationen \u00fcber unsere Dienste fehlten, die wir \u00fcberwachten, wo die Quellcodes des Dienstes lagen, wo die Aufgaben zum Bauen in TeamCity gestartet werden, wie sie deployt werden, wo die Quellcodes der End-to-End-Tests gespeichert sind, Fotos von Grooming \u00fcber die Architektur und \u00fcber getroffene Entscheidungen. Ideal w\u00e4re es, wenn all diese Informationen irgendwo hinterlegt w\u00e4ren und zur Hand, wenn man sie braucht. Deshalb wurde unsere Tabelle zum Ausgangspunkt f\u00fcr die Suche nach Informationen.<\/p>\n

Aber QIWI, obwohl es den Geist eines Startups bewahrt, ist ein gro\u00dfes Unternehmen. Wir sind bereits 12 Jahre alt und die Teams \u00e4ndern sich: Menschen gehen, Menschen kommen, es bilden sich neue Teams. Und wir fanden auf unserer Domain mehrere Dienste, die uns vererbt wurden. Einige kamen von Entwicklern aus anderen Teams, andere hatten einfach indirekt mit dem Wallet zu tun, deshalb wird dieser Dienst jetzt in unserem Portfolio gef\u00fchrt. Warum sollten wir uns darum k\u00fcmmern, was und wie funktioniert? Der Dienst funktioniert ja, und wir haben Produktfeatures, die unbedingt umgesetzt werden m\u00fcssen.<\/p>\n

Wie es manchmal der Fall ist.<\/h2>\n

\nAber irgendwann entdecken wir, dass der Dienst seine Funktion nicht mehr erf\u00fcllt, dass etwas kaputt ist \u2013 was tun wir in so einer Situation? Der Dienst funktioniert einfach nicht mehr. Gar nicht. Und erfahren haben wir das, erstens zuf\u00e4llig und zweitens nach sechs Monaten. So ist es. Das einzige, was wir wussten \u2013 auf welchen virtuellen Maschinen der Dienst l\u00e4uft, wo seine Quellcodes liegen, und das war's. Wir machen ein git clone und tauchen ein in die Gedanken einer Person, die das vor ein paar Jahren geschrieben hat, aber was sehen wir? Nichts von dem gewohnten Spring Boot, auch wenn wir an alles gew\u00f6hnt sind, schlie\u00dflich sind wir full stack und so weiter. Vielleicht gibt es dort Spring Framework? Aber das gibt es nicht.<\/p>\n

Der Junge, der all dies geschrieben hat, war streng und hat alles in reinem Java geschrieben. Gew\u00f6hnliche Entwicklerwerkzeuge gibt es nicht, und die Idee kommt auf \u2013 das Ganze m\u00fcsste man umschreiben. Wir haben schlie\u00dflich Mikrodienste, und aus jedem Toaster dringt das vertraute \"Leute, Mikrodienste sind das, was ihr braucht!\". Wenn irgendetwas nicht stimmt, k\u00f6nnt ihr in Ruhe jede Sprache w\u00e4hlen und alles wird gut.<\/p>\n

Die Sache ist die, dass wir derzeit keinen Auftraggeber haben, der f\u00fcr diesen Dienst verantwortlich ist. Welche Gesch\u00e4ftsanforderungen hatte er, was soll dieser Dienst \u00fcberhaupt tun? Der Dienst ist eng in eure Gesch\u00e4ftsprozesse integriert. <\/p>\n

Und jetzt sagt mir, wie einfach es ist, einen Dienst neu zu schreiben, ohne seine Gesch\u00e4ftsanforderungen zu kennen? Es ist unklar, wie der Dienst protokolliert wird, ob es Metriken gibt \u2013 unbekannt. Welche sie sind, falls es sie gibt \u2013 erst recht unbekannt. Und dabei gibt es im Dienst eine riesige Anzahl von Klassen mit unklarer Gesch\u00e4ftslogik. Etwas gelangt in eine Datenbank, \u00fcber die wir auch bisher nichts wissen. <\/p>\n

Wo soll man anfangen?<\/h2>\n

\nMit dem naheliegendsten \u2014 der Verf\u00fcgbarkeit von Tests. Dort ist normalerweise zumindest eine gewisse Logik geschrieben und man kann Schl\u00fcsse dar\u00fcber ziehen, was vor sich geht. Momentan ist TDD in Mode, aber wir sehen, dass es vor 5 Jahren fast genau so war wie jetzt: es gibt kaum Unit-Tests, und die sagen uns \u00fcberhaupt nichts. Nun, au\u00dfer vielleicht einer \u00dcberpr\u00fcfung, wie man irgendein XML mit einem benutzerdefinierten Zertifikat signiert.<\/p>\n

Wir konnten aus dem Code nichts herauslesen, und wir schickten jemanden, um zu sehen, was dort auf der virtuellen Maschine los ist. Wir \u00f6ffneten die Dienstprotokolle und fanden darin den Fehler des HTTP-Clients, das selbstsignierte Zertifikat, das in die Anwendungsressourcen integriert war, war v\u00f6llig veraltet. Wir nahmen Kontakt mit unseren Analysten auf, sie baten um ein neues Zertifikat, das uns ausgestellt wurde, und der Dienst funktioniert wieder. Man k\u00f6nnte denken, dass es damit erledigt ist. Oder nicht? Der Dienst funktioniert schlie\u00dflich und erf\u00fcllt eine Funktion, die f\u00fcr unser Gesch\u00e4ft notwendig ist. Wir haben bestimmte Standards f\u00fcr die Entwicklung von Anwendungen, die vermutlich auch bei Ihnen bestehen. Zum Beispiel sollten Protokolle nicht auf der Node im Ordner gespeichert werden, sondern in einem Speicher, wie zum Beispiel Elastic, und wir sollten sie in Kibana betrachten. Man k\u00f6nnte auch von den wichtigsten Metriken sprechen. Das hei\u00dft, die Belastung des Dienstes, die Anzahl der Anfragen an den Dienst, ob er lebt oder nicht, wie es mit seinem HealthCheck aussieht. Zumindest helfen diese Metriken zu entschl\u00fcsseln, wann man ihn mit ruhigem Gewissen au\u00dfer Betrieb nehmen und als schlechten Traum vergessen kann.<\/p>\n

Was tun<\/h2>\n

\nDeshalb f\u00fcgen wir diesen alten Dienst in die Tabelle ein, und dann suchen wir aus den Entwicklern Freiwillige, die sich um den Dienst k\u00fcmmern und ihn in Ordnung bringen: Sie schreiben wenigstens ein paar Informationen \u00fcber den Dienst, f\u00fcgen Links zu den Dashboards in Grafana, zu den Build-Tasks hinzu und verstehen, wie die Anwendung bereitgestellt wird; man kann die Dateien nicht einfach per FTP zusammensammeln. <\/p>\n

Das Wichtigste ist, wie viel Zeit all diese n\u00fctzlichen freiwilligen Aktivit\u00e4ten in Anspruch nehmen wird? Ein Sprint f\u00fcr einen mehr oder weniger erfahrenen Entwickler, zum Beispiel w\u00e4hrend 20 % der technischen Schulden. Und wie viel Zeit wurde darauf verwendet, die verfestigte Logik im Umgang mit einem gewissen Regierungssystem zu verstehen und auf aktuellere Technologien umzustellen? Davon kann ich nicht garantieren, vielleicht ein Monat, vielleicht auch zwei Monate Teamarbeit. Das sage ich aus Erfahrung mit der aktuellen Integration eines neuen Dienstes.<\/p>\n

Dabei gibt es keinen gesch\u00e4ftlichen Nutzen. Gar keinen. Es ist in Ordnung, einen Dienst zu unterst\u00fctzen und daf\u00fcr etwas Zeit zu investieren. Aber nach unseren \u00fcblichen Tanzrunden mit dem Dienst haben wir ihn in die Tabelle aufgenommen, Informationen \u00fcber ihn hinzugef\u00fcgt und m\u00f6glicherweise werden wir ihn irgendwann neu schreiben. Aber im Moment erf\u00fcllt er unsere Standards f\u00fcr die Arbeit mit Diensten.<\/p>\n

Zusammenfassend m\u00f6chte ich zu einem gewissen Plan kommen, was mit Legacy-Diensten zu tun ist. <\/p>\n

Legacy vollst\u00e4ndig neu zu schreiben, ist eine schlechte Idee.<\/b>
\nIm Ernst, dar\u00fcber muss man sich nicht einmal Gedanken machen. Es ist klar, dass es w\u00fcnschenswert w\u00e4re und einige Vorteile sichtbar sind, aber in der Regel ist das f\u00fcr niemanden notwendig, einschlie\u00dflich Ihnen selbst.<\/p>\n

Verzeichnis<\/b>
\nGraben Sie die Quellcodes Ihrer Anwendungen aus, erstellen Sie ein Verzeichnis, in dem steht, was wo liegt und wie es funktioniert, und f\u00fcgen Sie auch eine Projektbeschreibung (eine Art readme.md) hinzu, um schnell zu verstehen, wo die Logs und Metriken liegen. Der Entwickler, der damit nach Ihnen arbeitet, wird Ihnen nur danken.<\/p>\n

Verstehen Sie die Domain<\/b>
\nWenn Ihnen eine Domain geh\u00f6rt, versuchen Sie, den \u00dcberblick zu behalten. Das klingt banal, ja, aber nicht jeder achtet darauf, dass die Dienste einheitlich sind. Tats\u00e4chlich ist es viel einfacher, nach einem einheitlichen Standard zu arbeiten.<\/p>\n

Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte einloggen<\/a><\/noindex>.<\/p>\n

Was machen Sie mit Ihrem Legacy?<\/h2>\n