🥇Legacy-services in uw infrastructuur

Hallo! Mijn naam is Pasha Chernyak, ik ben lead developer bij QIWI en vandaag wil ik het hebben over het onvermijdelijke. Over Legacy.

Laten we beginnen met de vraag: wat is een legacy service? Een legacy service is een service waar de ontwikkelaar een week/maand/jaar niet aan heeft gewerkt? Of is het een service die een jaar geleden is geschreven door een minder ervaren programmeur, bijvoorbeeld jij? En nu ben je cooler en meer ervaren. Of is een legacy service een service die je hebt besloten nooit meer te implementeren en waar je langzaam een vervanging voor aan het voorbereiden bent? Hoe dan ook, het onbeheerd achterlaten en niet updaten van zo'n service is een tijdbom die later kan ontploffen.

Voordat we ingaan op hoe we bij QIWI met onze Legacy-services werken, vertel ik je hoe we onze Wallet-services op orde hebben gekregen. Ik ben nu twee jaar verantwoordelijk voor de functionaliteit ervan. Als er een probleem is, ben ik altijd de eerste die ze bellen. Normaal gesproken durf ik om 11 uur niet iemand anders te bellen, dus moest ik eerst even gaan zitten om alle services binnen ons domein te doorgronden.

Maar ik slaap, net als ieder ander, graag 's nachts, dus ik probeerde de logica te doorgronden: "Jongens, waarom bellen jullie mij?" Waarop ik een heel laconiek antwoord kreeg in de trant van: "Wie anders?" Omdat ik diensten repareer, en de jongens gewoon niet weten wie ze moeten bellen.

Tijdens een van de retrospectieven van het Wallet-backendteam besloten we dat we een tabel moesten maken met een lijst van onze services, microservices en wallet-monolieten, en wie daarvoor verantwoordelijk is. Tabellen zijn over het algemeen nuttig, binnen redelijke grenzen.

Naast informatie over wie waarvoor verantwoordelijk is, werden ook vragen beantwoord: wie is de eigenaar van de service, wie is verantwoordelijk voor de ontwikkeling, architectuur en levenscyclus? De mensen die verantwoordelijk zijn voor deze service zijn degenen die deze kunnen repareren als er iets misgaat. De eigenaar van de service heeft het recht om +2 in commits te laten staan, en de verantwoordelijken moeten ook aanwezig zijn bij de review voordat deze service een nieuwe commit accepteert.

Na verloop van tijd werden nieuwe werkwijzen toegepast, zoals migratie naar Kubernetes, allerlei checkstyles, spotbugs, ktlint, de aanwezigheid van logs in kibana, automatische detectie van services in plaats van het direct specificeren van adressen en andere nuttige zaken. En overal stelde onze tabel ons in staat om onze services up-to-date te houden. Voor ons is dit een soort checklist die aangeeft dat deze service dit kan, maar dit nog niet. Maar we gingen verder en realiseerden ons dat we informatie misten over de services die we monitoren, waar de servicebronnen zich bevinden, waar de taken voor assembly in TeamCity worden gestart, hoe ze worden geïmplementeerd, waar de end2end-testbronnen worden opgeslagen, foto's van grooming over architectuur, over genomen beslissingen. Idealiter wilden we dat al deze informatie ergens en bij de hand was wanneer nodig. Daarom werd onze tabel het startpunt voor het zoeken naar informatie.

Maar QIWI, hoewel het de geest van een startup behoudt, is een groot bedrijf. We bestaan al twaalf jaar en teams veranderen: mensen vertrekken, mensen komen erbij, nieuwe teams worden gevormd. En we vonden verschillende diensten op ons domein die we hadden overgenomen. Sommige kwamen van ontwikkelaars van andere teams, andere waren op de een of andere manier indirect gerelateerd aan de Wallet, dus de dienst staat nu op onze balans. Waarom zouden we uitzoeken wat en hoe het werkt? De dienst werkt, en we hebben productfuncties die we absoluut moeten implementeren.

Zoals het gebeurt

Maar op een gegeven moment ontdekken we dat de service niet meer functioneert, dat er iets kapot is – wat moeten we in zo'n situatie doen? De service werkte gewoon niet meer. Helemaal niet. En we kwamen er ten eerste per ongeluk achter, en ten tweede zes maanden later. Het gebeurt. Het enige wat we wisten, was op welke virtuele machines de service was geïmplementeerd, waar de bronnen zich bevonden, en dat was alles. We maken een git-kloon en duiken in de gedachten van de persoon die dit een paar jaar geleden schreef, maar wat zien we? Niets van de Spring Boot waaraan we gewend zijn, hoewel we wel aan alles gewend zijn, we hebben een volledige stack en zo. Misschien is er wel Spring Framework? Nee, dat is het niet.

De man die dit allemaal schreef, was streng en schreef alles in pure Java. Er zijn geen gebruikelijke tools voor een ontwikkelaar, en er ontstaat een idee: we moeten dit allemaal herschrijven. We hebben microservices, en uit elke broodrooster komt de gebruikelijke "Jongens, microservices zijn wat jullie nodig hebben!" Als er plotseling iets misgaat, kun je rustig elke programmeertaal gebruiken en komt alles goed.

Het probleem is dat we nu geen klant hebben die verantwoordelijk is voor deze service. Wat waren zijn zakelijke vereisten, wat moet deze service in het algemeen doen? En de service is nauw geïntegreerd in uw bedrijfsprocessen.

En vertel eens, hoe makkelijk is het om een service te herschrijven zonder de bedrijfsvereisten te kennen? Het is onduidelijk hoe de service wordt gelogd, het is onbekend of er metrics zijn. Welke dat zijn, als die er zijn, is nog onbekender. En tegelijkertijd bevat de service een enorm aantal klassen van onbegrijpelijke bedrijfslogica. Er staat iets in een database, maar daar weten we nog niets over.

Waarmee te beginnen?

De meest logische is de aanwezigheid van tests. Meestal staat er wel wat logica in en kun je conclusies trekken over wat er gebeurt. TDD is nu in de mode, maar we zien dat vijf jaar geleden alles vrijwel hetzelfde was als nu: er zijn bijna geen unittests en ze vertellen ons helemaal niets. Nou ja, behalve een soort controle, hoe XML wordt ondertekend met een aangepast certificaat.

We konden niets uit de code opmaken, dus gingen we kijken wat er in de virtuele machine gebeurde. We openden de servicelogs en ontdekten een http-clientfout: het zelfondertekende certificaat dat in de applicatiebronnen was ingebouwd, was schaamteloos defect geraakt. We namen contact op met onze analisten, ze vroegen om een nieuw certificaat, gaven het aan ons uit en de service werkte weer. Het leek erop dat dat alles was. Of toch niet? De service werkt immers, hij voert een functie uit die onze business nodig heeft. We hebben een aantal standaarden voor applicatieontwikkeling die u waarschijnlijk ook hebt. Bijvoorbeeld: logs niet in een map op het knooppunt opslaan, maar in een opslagmedium, zoals Elastic, en ze bekijken in Kibana. U kunt ook de gouden statistieken onthouden. Dat wil zeggen de belasting van de service, het aantal verzoeken voor de service, of deze actief is of niet, en hoe deze HealthCheck doorstaat. Deze statistieken helpen u op zijn minst om te bepalen wanneer u de service veilig kunt deactiveren en vergeten als een nachtmerrie.

Wat te doen

Daarom voegen we zo'n oude service toe aan de tabel en gaan we vervolgens op zoek naar vrijwilligers onder de ontwikkelaars die de service gaan beheren en op orde gaan brengen: ze schrijven in ieder geval wat informatie over de service, voegen links toe naar dashboards in Grafana, bouwen taken, leren hoe de applicatie geïmplementeerd moet worden en gooien niet handmatig bestanden in de database via FTP.

De belangrijkste vraag is hoeveel tijd al deze nuttige vrijwilligersactiviteiten in beslag zullen nemen? Eén sprint voor een min of meer ervaren ontwikkelaar, bijvoorbeeld, tijdens een technische schuld van 20%. En hoeveel tijd kostte het om de ingebakken logica van de communicatie met een bepaald statussysteem te doorgronden en te implementeren in nieuwere technologieën? Ik kan hier geen garanties voor geven, misschien een maand, of misschien zelfs twee maanden van het werk van het team. Ik zeg dit op basis van de huidige ervaring met de integratie van een nieuwe dienst.

Tegelijkertijd is er geen output die bedrijfswaarde oplevert. Helemaal niet. Een service voor ondersteuning aannemen en er wat tijd aan besteden is normaal. Maar na onze standaardtests met de service hebben we deze aan de tabel toegevoegd, er informatie over toegevoegd en zullen we hem misschien ooit herschrijven. Maar nu voldoet hij aan onze normen voor de werking van services.

Daarom wil ik een plan bedenken voor wat we met de Legacy-services moeten doen.

Het is een slecht idee om een legacy-systeem vanaf nul te herschrijven
Echt, je hoeft er niet eens over na te denken. Het is begrijpelijk dat je dat wilt, en er zijn voordelen, maar meestal heeft niemand er behoefte aan, ook jij niet.

Naslagwerk
Graaf de broncodes van je applicaties op, maak een naslagwerk waarin staat wat waar staat en hoe het werkt, en schrijf daar ook een beschrijving van het project (conditionele readme.md), zodat je snel kunt zien waar de logs en metrics zich bevinden. De ontwikkelaar die dit na jou gaat afhandelen, zal je alleen maar bedanken.

Begrijp het domein
Als je een domein bezit, probeer dan de vinger aan de pols te houden. Het klinkt misschien triviaal, maar niet iedereen zorgt ervoor dat de diensten op dezelfde manier werken. Maar werken volgens één standaard is eigenlijk merkbaar makkelijker.

Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. Inloggen, Alsjeblieft.