Oudere services in uw infrastructuur

Hallo! Mijn naam is Pasha Chernyak, ik ben een toonaangevende ontwikkelaar bij QIWI, en vandaag wil ik het hebben over het onvermijdelijke. Over erfenis.

Laten we beginnen met de vraag: wat is Legacy-service? Is een verouderde service een service waar de ontwikkelaar al een week/maand/jaar niets aan heeft gedaan? Of is het een dienst die door een minder ervaren programmeur is geschreven, bijvoorbeeld door jou specifiek, maar dan een jaar geleden? En nu ben je cooler en meer ervaren. Of is de Legacy-service een service waarvan u hebt besloten deze nooit meer te plegen en bent u langzaam bezig met het voorbereiden van een vervanging ervoor? Hoe dan ook is het onbeheerd achterlaten van een dergelijke dienst en het niet updaten ervan een tijdbom die later kan ontploffen.

Voordat ik verder ga met hoe wij bij QIWI met onze Legacy-diensten werken, zal ik u vertellen hoe we orde hebben gebracht in de diensten in de Wallet. Sinds twee jaar ben ik verantwoordelijk voor de uitvoering ervan. Als er een probleem is, bellen ze mij altijd eerst. Normaal heb ik niet het lef om om 11 uur iemand anders te bellen, dus ik moest even gaan zitten en alle diensten op ons domein uitzoeken.

Maar ik slaap, net als ieder ander, graag 's nachts, dus ik probeerde met de uitbuiting om te gaan: "Jongens, waarom bellen jullie mij?" Waarop ik een nogal laconiek antwoord kreeg als “Wie anders?” Omdat ik diensten repareer en de jongens gewoon niet weten wie ze moeten bellen.

Daarom besloten we tijdens een van de retrospectives van het Wallet-backend-team dat we een bord moesten maken met een lijst van onze services, microservices en portemonnee-monolieten, en degenen die daarvoor verantwoordelijk zijn. Tekenen zijn over het algemeen nuttig, binnen redelijke grenzen.

Naast informatie over wie waarvoor verantwoordelijk is, waren er antwoorden op de vragen: wie is de eigenaar van de dienst, wie is verantwoordelijk voor de ontwikkeling, de architectuur en de levenscyclus ervan. De mensen die verantwoordelijk zijn voor deze service zijn de mensen die het kunnen repareren als er iets gebeurt. De eigenaar van de dienst heeft het recht om +2 in commits achter te laten, de verantwoordelijken moeten ook aanwezig zijn bij de beoordeling voordat deze dienst een nieuwe commit accepteert.

Naarmate de tijd verstreek, begonnen er nieuwe praktijken te worden toegepast, bijvoorbeeld migratie naar Kubernetes, allerlei soorten checkstyle, spotbugs, ktlint, de aanwezigheid van logs in Kibana, autodiscovery-services in plaats van het direct specificeren van adressen en andere nuttige dingen. En overal dankzij onze tafel konden we de relevantie van onze diensten behouden. Voor ons is dit een soort checklist die zegt dat deze dienst dit kan doen, maar dat nog niet doet. Maar we zijn verder gegaan, in het besef dat we informatie missen over onze diensten, die we monitoren, waar de servicebronnen zich bevinden, waar assemblagetaken worden gelanceerd in TeamCity, hoe ze worden ingezet, waar de bronnen van end2end-tests worden opgeslagen, foto's van verzorgingssessies over de architectuur, over de genomen beslissingen. Idealiter zou ik willen dat al deze informatie ergens ligt en bij de hand is als dat nodig is. Daarom werd ons bord het startpunt voor het zoeken naar informatie.

Maar QIWI is, hoewel het de geest van een startup behoudt, een groot bedrijf. We zijn al 12 jaar oud en teams veranderen: mensen gaan weg, mensen komen, er worden nieuwe teams gevormd. En we ontdekten verschillende services op ons domein die we hebben geërfd. Sommige kwamen van ontwikkelaars van andere teams, sommige waren eenvoudigweg indirect gerelateerd aan de Wallet, dus we hebben de service nu op onze balans staan. Begrijpen wat en hoe het werkt - waarom? De service werkt en we hebben productfuncties die absoluut verbeterd moeten worden.

Hoe het gebeurt

Maar op een gegeven moment ontdekken we dat de dienst zijn functie niet meer vervult, er is iets kapot - wat te doen in zo'n situatie? De service stopte gewoon met werken. Helemaal niet. En we kwamen hier ten eerste per ongeluk achter, en ten tweede zes maanden later. Het gebeurt. Het enige dat we wisten was op welke virtuele machines de service zou worden ingezet, waar de bronnen zich bevonden, en dat is alles. We doen een git-kloon en duiken in de geest van de persoon die dit een paar jaar geleden heeft geschreven, maar wat zien we? Geen van de Spring Boot die ons bekend is, hoewel we aan alles gewend zijn, we hebben een volledige stapel en zo. Misschien is daar een Spring Framework? Maar nee.

De man die dit allemaal schreef was stoer en schreef alles in puur 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 het gebruikelijke "Jongens, microservices is wat je nodig hebt!" Als er plotseling iets misgaat, kun je rustig elke taal gebruiken en alles komt goed.

Het punt is dat we nu geen klant hebben die verantwoordelijk is voor deze service. Welke zakelijke vereisten had hij, wat moest deze dienst doen? En de service is nauw geïntegreerd in uw bedrijfsprocessen.

Vertel me nu eens: hoe gemakkelijk is het om een ​​dienst te herschrijven zonder de zakelijke vereisten te kennen? Het is niet duidelijk hoe de dienst wordt gelogd; of er statistieken zijn, is onbekend. Wat ze zijn, als ze er al zijn, is des te onbekender. En tegelijkertijd bevat de service een groot aantal klassen onbegrijpelijke bedrijfslogica. Er zit iets in een soort database, waar we ook nog niets van weten.

Waarmee te beginnen?

Vanuit het meest logische punt: de beschikbaarheid van tests. Meestal staat daar op zijn minst enige logica geschreven en kun je conclusies trekken over wat er gebeurt. Nu is TDD in de mode, maar we zien dat 5 jaar geleden alles bijna hetzelfde was als nu: er zijn bijna geen unit-tests en ze willen ons helemaal niets vertellen. Nou ja, behalve misschien een soort verificatie, hoe sommige XML wordt ondertekend met een aangepast certificaat.

We konden niets van de code begrijpen, dus gingen we kijken wat er in de virtuele machine zat. We openden de servicelogboeken en vonden daarin een http-clientfout; het zelfondertekende certificaat dat was ingebed in de applicatiebronnen was schaamteloos verrot. We hebben contact opgenomen met onze analisten, zij hebben om een ​​nieuw certificaat gevraagd, zij hebben dit aan ons verstrekt en de service werkt weer. Het lijkt erop dat dat alles is. Of niet? De service werkt tenslotte, hij vervult een functie die ons bedrijf nodig heeft. Wij hanteren bepaalde standaarden voor de ontwikkeling van applicaties, die u waarschijnlijk ook heeft. Bewaar logboeken bijvoorbeeld niet op het knooppunt in een map, maar bewaar ze in een soort opslag, zoals Elastic, en bekijk ze in Kibana. Je kunt ook de gouden maatstaven onthouden. Dat wil zeggen: de belasting van de dienst, het aantal aanvragen voor de dienst, of hij nog leeft of niet, hoe zijn HealthCheck verloopt. Op zijn minst zullen deze statistieken u helpen te weten wanneer het met een gerust geweten buiten gebruik kan worden gesteld en als een nare droom kan worden vergeten.

Wat te doen

Daarom voegen we zo'n oude service toe aan de tafel, en dan gaan we op zoek naar vrijwilligers onder de ontwikkelaars die voor de service zullen zorgen en deze op orde zullen brengen: ze zullen op zijn minst wat informatie over de service schrijven, links toevoegen naar dashboards in grafana, tot assemblagetaken, en begrijpen hoe Implementeer de applicatie, upload geen bestanden handmatig met behulp van ftp.

Het belangrijkste is: hoe lang zal al deze nuttige vrijwilligersactiviteit duren? Eén sprint voor een min of meer ervaren ontwikkelaar bijvoorbeeld tijdens een technische schuld van 20%. Hoe lang duurde het om alle diepgewortelde logica van de communicatie met een bepaald staatssysteem te begrijpen en dit naar nieuwere technologieën te brengen? Ik kan hier niet voor instaan, misschien een maand of misschien twee van het werk van het team. Ik zeg dit uit ervaring met de huidige integratie met een nieuwe dienst.

Tegelijkertijd komt er geen bedrijfswaarde vrij. Helemaal niet. Het is normaal om een ​​dienst in te huren voor ondersteuning en er wat tijd aan te besteden. Maar na onze standaarddansen met de dienst hebben we het aan de tafel toegevoegd, er informatie over toegevoegd en misschien zullen we het ooit herschrijven. Maar nu voldoet het aan onze servicenormen.

Daarom zou ik graag een plan willen bedenken voor wat te doen met Legacy-services.

Het is een slecht idee om de erfenis helemaal opnieuw te schrijven
Serieus, je hoeft er niet eens over na te denken. Het is duidelijk dat ik het leuk zou vinden, en er zijn enkele voordelen, maar meestal heeft niemand het nodig, ook jij niet.

Naslagwerk
Graaf de broncodes van uw applicaties op, maak een naslagwerk dat aangeeft wat waar is en hoe het werkt, voer daar een beschrijving van het project in (conditional readme.md) om snel te begrijpen waar de logs en statistieken zich bevinden. De ontwikkelaar die dit na jou afhandelt, zegt alleen maar dankjewel.

Begrijp het domein
Als u eigenaar bent van een domein, probeer dan de vinger aan de pols te houden. Het klinkt triviaal, ja, maar niet iedereen zorgt ervoor dat de services in één sleutel zitten. Maar werken in één standaard is eigenlijk een stuk eenvoudiger.

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

Wat doet u met uw nalatenschap?

• 31.5%Ik herschrijf het helemaal opnieuw, het is correcter 12

• 52.6%Bijna hetzelfde als jij20

• 10.5%We hebben geen erfenis, we zijn geweldig4

• 5.2%Ik schrijf het in de reacties2

38 gebruikers hebben gestemd. 20 gebruikers onthielden zich van stemming.

Bron: www.habr.com