{"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-Dienste in Ihrer Infrastruktur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Lassen Sie uns mit der Frage anfangen: Was ist ein Legacy-Service? Ist es ein Service, den der Entwickler seit einer Woche\/Monat\/Jahr nicht mehr angefasst hat? Oder ist es ein Service, der von einem weniger erfahrenen Programmierer, vielleicht von Ihnen selbst, vor einem Jahr geschrieben wurde? Und jetzt sind Sie viel erfahrener. Oder ist ein Legacy-Service etwas, das Sie nie wieder committen wollten und langsam durch etwas Neues ersetzen? In jedem Fall ist es eine tickende Zeitbombe, einen solchen Service unbeaufsichtigt zu lassen und nicht zu aktualisieren.<\/p>\n

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

Bevor ich erkl\u00e4re, wie wir bei QIWI mit unseren Legacy-Services umgehen, m\u00f6chte ich erz\u00e4hlen, wie wir Ordnung in die Dienste in Wallet gebracht haben. Seit zwei Jahren bin ich f\u00fcr die Funktionsf\u00e4higkeit verantwortlich. Wenn es ein Problem gibt, werde ich immer zuerst kontaktiert. Normalerweise habe ich nicht den Mut, um 23 Uhr jemanden anzurufen, also musste ich mich hinsetzen und alle Dienste in unserer Domain durchgehen. <\/p>\n

Aber ich, wie jeder andere Mensch, liebe es, nachts zu schlafen, also versuchte ich, die Nutzung zu kl\u00e4ren: \u201eLeute, warum ruft ihr mich an?\u201c. Darauf erhielt ich eine recht knappe Antwort wie: \u201eUnd wer sonst?\u201c Denn ich repariere die Dienste, und die Jungs wissen einfach nicht, wen sie anrufen sollen.<\/p>\n

Deshalb haben wir bei einem der Retrospektiven des Backend-Teams von Wallet beschlossen, eine Tabelle zu erstellen, auf der unsere Dienste, Mikrodienste und Monolithen des Wallets sowie die daf\u00fcr Verantwortlichen aufgef\u00fchrt sind. Tabellen sind insgesamt n\u00fctzlich, in einem vern\u00fcnftigen Rahmen.
\n<\/a><\/noindex>
\nNeben Informationen dar\u00fcber, wer wof\u00fcr verantwortlich ist, gab es dort auch Antworten auf Fragen: Wer ist der Besitzer des Dienstes, wer ist f\u00fcr dessen Weiterentwicklung, Architektur und Lebenszyklus verantwortlich? Die Personen, die f\u00fcr diesen Dienst zust\u00e4ndig sind, sind die, die ihn im Bedarfsfall reparieren k\u00f6nnen. Der Besitzer des Dienstes hat das Recht, +2 in den Commits zu hinterlassen, und die Verantwortlichen m\u00fcssen unbedingt an der Pr\u00fcfung teilnehmen, bevor dieser Dienst einen neuen Commit \u00fcbernimmt.<\/p>\n

Die Zeit verging, und es wurden neue Praktiken eingef\u00fchrt, wie zum Beispiel die Migration zu Kubernetes, verschiedene Tools wie Checkstyle, Spotbugs, Ktlint, das Vorhandensein von Logs in Kibana, Autodiscovery von Services anstelle der direkten Angabe von Adressen und andere n\u00fctzliche Funktionen. Und \u00fcberall erm\u00f6glichte unsere Tabelle die Aktualit\u00e4t unserer Services. F\u00fcr uns fungiert sie als eine Art Checkliste, die zeigt, dass dieser Service das kann und jenes noch nicht. Aber wir gingen weiter und erkannten, dass uns Informationen \u00fcber unsere Services fehlten, die wir \u00fcberwachen \u2013 wo sich der Source-Code des Services befindet, wo die Builds in TeamCity gestartet werden, wie sie deployt werden, wo die Source-Codes der End-to-End-Tests gespeichert sind, Fotos von Groomings \u00fcber die Architektur und die getroffenen Entscheidungen. Ideal w\u00e4re es, wenn all diese Informationen irgendwo gespeichert w\u00e4ren und griffbereit sind, wenn sie gebraucht werden. Daher wurde unsere Tabelle zum Ausgangspunkt f\u00fcr die Informationssuche.<\/p>\n

QIWI bewahrt trotz seines Start-up-Geists den Charakter eines gro\u00dfen Unternehmens. Wir sind bereits 12 Jahre alt, und die Teams wechseln: Menschen gehen und kommen, es entstehen neue Gruppen. Auf unserer Domain haben wir einige Dienste gefunden, die uns im Laufe der Zeit geblieben sind. Einige stammen von Entwicklern anderer Teams, andere hatten nur indirekt mit dem Wallet zu tun, weshalb wir den Service nun auf unserem Konto haben. Warum sollen wir uns mit der Funktionsweise besch\u00e4ftigen? Der Service funktioniert, und wir haben Produktfunktionen, die unbedingt umgesetzt werden m\u00fcssen.<\/p>\n

Wie es manchmal vorkommt<\/h2>\n

\nDoch irgendwann stellen wir fest, dass der Dienst seine Funktion nicht mehr erf\u00fcllt, etwas kaputt ist \u2013 was tun wir in so einer Situation? Der Dienst funktioniert einfach nicht mehr. \u00dcberhaupt nicht. Und wir haben davon erfahren, erstens zuf\u00e4llig und zweitens nach sechs Monaten. So l\u00e4uft das eben. Das Einzige, was wir wussten, war, auf welchen virtuellen Maschinen der Dienst l\u00e4uft und wo sich der Quellcode befindet. Wir machen ein git clone und tauchen ein in die Gedanken des Entwicklers, der das vor einigen Jahren geschrieben hat, aber was sehen wir? Kein gewohntes Spring Boot, obwohl wir an alles gew\u00f6hnt sind, schlie\u00dflich sind wir Full Stack und dergleichen. Gibt es da etwa ein Spring Framework? Aber nein.<\/p>\n

Der Typ, der das alles geschrieben hat, war strikt und schrieb alles in reinem Java. Die gewohnten Entwicklungswerkzeuge fehlen, und es kommt die Idee auf \u2013 das m\u00fcsste alles neu geschrieben werden. Wir haben schlie\u00dflich Mikroservices, und aus jedem Toaster ert\u00f6nt das vertraute \u201eLeute, Mikroservices sind genau das, was ihr braucht!\u201c. Wenn etwas nicht stimmen sollte, k\u00f6nnt ihr locker jede beliebige Sprache nehmen und es wird alles hervorragend funktionieren.<\/p>\n

Das Problem ist, dass wir derzeit keinen Auftraggeber haben, der f\u00fcr diesen Service verantwortlich ist. Was sind seine gesch\u00e4ftlichen Anforderungen und was sollte dieser Service \u00fcberhaupt leisten? Und der Service ist eng in Ihre Gesch\u00e4ftsprozesse integriert. <\/p>\n

Und jetzt sagen Sie mir, wie einfach es ist, einen Service neu zu programmieren, ohne seine gesch\u00e4ftlichen Anforderungen zu kennen? Es ist unklar, wie der Service geloggt wird, ob es Metriken gibt \u2013 das ist unbekannt. Welche es gibt, falls vorhanden \u2013 das ist umso weniger bekannt. Zudem gibt es im Service eine Vielzahl von Klassen mit unklarer Gesch\u00e4ftslogik. Etwas wird in eine Datenbank eingegeben, \u00fcber die wir ebenfalls noch nichts wissen. <\/p>\n

Womit fangen wir an?<\/h2>\n

\nAm logischsten ist der Beginn mit vorhandenen Tests. Dort ist normalerweise wenigstens eine gewisse Logik festgehalten, und man kann R\u00fcckschl\u00fcsse darauf ziehen, was passiert. Momentan ist TDD in Mode, aber wir sehen, dass es vor 5 Jahren kaum anders war als heute: Es gibt fast keine Unit-Tests, und sie werden uns auch genau genommen \u00fcberhaupt nichts sagen. Nun, abgesehen vielleicht von einer irgendwie gearteten Pr\u00fcfung, wie ein XML mit einem bestimmten Zertifikat unterschrieben wird.<\/p>\n

Der Code war nicht verst\u00e4ndlich und wir mussten genauer hinschauen, was in der virtuellen Maschine vor sich ging. Wir \u00f6ffneten die Service-Logs und fanden einen Fehler im HTTP-Client: Ein selbstsigniertes Zertifikat, das in die Ressourcen der Anwendung eingebettet war, war abgelaufen. Wir kontaktierten unsere Analysten, die uns um ein neues Zertifikat baten, welches dann ausgestellt wurde, und der Service funktioniert wieder. Man k\u00f6nnte denken, das w\u00e4re alles. Oder doch nicht? Der Service l\u00e4uft, er erf\u00fcllt eine Funktion, die f\u00fcr unser Gesch\u00e4ft notwendig ist. Wir haben bestimmte Standards f\u00fcr die Anwendungsentwicklung, die wahrscheinlich auch bei Ihnen gelten. Zum Beispiel sollten Logs nicht direkt auf der Node gespeichert werden, sondern in einem Speichersystem wie Elasticsearch, und man sollte sie in Kibana ansehen. Man kann auch die goldenen Metriken erw\u00e4hnen. Das bedeutet, die Auslastung des Services, die Anzahl der Anfragen, ob er online ist oder nicht, und wie er den HealthCheck besteht. Diese Metriken k\u00f6nnen zumindest helfen zu erkennen, wann man ihn mit gutem Gewissen au\u00dfer Betrieb nehmen und vergessen kann wie einen Albtraum.<\/p>\n

Was tun?<\/h2>\n

\nDaher f\u00fcgen wir diesen alten Dienst in die Tabelle ein und suchen dann nach Freiwilligen unter den Entwicklern, die sich um den Dienst k\u00fcmmern und ihn in Ordnung bringen: sie sollten zumindest einige Informationen \u00fcber den Dienst verfassen, Links zu Dashboards in Grafana hinzuf\u00fcgen, die Aufgaben f\u00fcr den Aufbau verstehen und herausfinden, wie man die Anwendung bereitstellt. Schlie\u00dflich kann man die Dateien nicht einfach h\u00e4ndisch per FTP hochladen. <\/p>\n

Das Wichtigste dabei ist: Wie viel Zeit wird all diese n\u00fctzliche freiwillige Aktivit\u00e4t in Anspruch nehmen? Ein Sprint f\u00fcr einen halbwegs erfahrenen Entwickler, beispielsweise w\u00e4hrend 20 % der technischen Schulden. Und wie viel Zeit wurde ben\u00f6tigt, um die fest verwurzelte Logik im Umgang mit einem bestimmten Regierungssystem zu verstehen und es auf modernere Technologien zu bringen? Daf\u00fcr kann ich keine Garantie geben; es k\u00f6nnte einen Monat, vielleicht sogar zwei Monate Teamarbeit in Anspruch nehmen. Ich spreche hier aus Erfahrung bei der Integration mit einem neuen Dienst.<\/p>\n

In diesem Zusammenhang gibt es keinen gesch\u00e4ftlichen Mehrwert \u2014 \u00fcberhaupt keinen. Es ist v\u00f6llig normal, einen Service zu unterst\u00fctzen und daf\u00fcr etwas Zeit aufzuwenden. Nach unseren \u00fcblichen Schwierigkeiten mit dem Service haben wir ihn in die Tabelle aufgenommen, Informationen dar\u00fcber hinzugef\u00fcgt, und vielleicht werden wir ihn irgendwann umschreiben. Aber im Moment entspricht er unseren Service-Standards.<\/p>\n

Zusammenfassend m\u00f6chte ich einen gewissen Plan skizzieren, was mit Legacy-Services zu tun ist. <\/p>\n

Das Legacy-System von Grund auf neu zu schreiben, ist eine schlechte Idee.<\/b>
\nEhrlich gesagt, dar\u00fcber braucht man gar nicht erst nachzudenken. Es ist klar, dass es w\u00fcnschenswert w\u00e4re und gewisse Vorteile sieht, aber normalerweise ist das f\u00fcr niemanden n\u00f6tig, auch nicht f\u00fcr Sie selbst.<\/p>\n

Verzeichnis<\/b>
\nHolen Sie den Quellcode Ihrer Anwendungen hervor, erstellen Sie ein Verzeichnis, in dem festgehalten wird, was wo liegt und wie es funktioniert. F\u00fcgen Sie auch eine Projektbeschreibung (sozusagen ein readme.md) hinzu, damit man schnell versteht, wo sich die Logs und Metriken befinden. Der Entwickler, der nach Ihnen damit arbeitet, wird Ihnen nur dankbar sein.<\/p>\n

Verstehen Sie die Domain<\/b>
\nWenn Sie eine Domain besitzen, sollten Sie stets auf dem Laufenden bleiben. Es mag banal klingen, aber nicht jeder sorgt daf\u00fcr, dass die Dienste einheitlich sind. Dabei ist es tats\u00e4chlich viel einfacher, in einem einheitlichen Standard zu arbeiten.<\/p>\n

Nur registrierte Benutzer k\u00f6nnen an der Umfrage teilnehmen. Bitte melden Sie sich an.<\/a><\/noindex>Sind Sie an Contour interessiert?<\/p>\n

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