Ældre tjenester i din infrastruktur

Hej! Mit navn er Pasha Chernyak, jeg er en førende udvikler hos QIWI, og i dag vil jeg tale om det uundgåelige. Om arv.

Lad os starte med spørgsmålet: hvad er Legacy service? Er en ældre service en service, som udvikleren ikke har rørt i en uge/måned/år? Eller er det en tjeneste, der er skrevet af en mindre erfaren programmør, for eksempel af dig specifikt, men for et år siden? Og nu er du sejere og mere erfaren. Eller er Legacy-tjenesten en tjeneste, som du har besluttet aldrig at forpligte dig til igen og langsomt forbereder en erstatning for den? Under alle omstændigheder er det en tidsindstillet bombe at efterlade en sådan tjeneste uden opsyn og ikke opdatere.

Inden vi går videre til, hvordan vi hos QIWI arbejder med vores Legacy-tjenester, vil jeg fortælle dig, hvordan vi bragte orden i tjenesterne i Wallet. I to år nu har jeg været ansvarlig for dens præstation. Hvis der er et problem, ringer de altid til mig først. Jeg har normalt ikke mod til at ringe til en anden kl. 11, så jeg måtte sætte mig ned og finde ud af alle tjenesterne på vores domæne.

Men jeg, som enhver person, kan lide at sove om natten, så jeg forsøgte at håndtere udnyttelsen: "Gunner, hvorfor ringer du til mig?" Hvortil jeg fik et ganske lakonisk svar som "Hvem ellers?" Fordi jeg ordner tjenester, og fyrene ved simpelthen ikke, hvem de skal ringe til.

Derfor besluttede vi ved et af retrospektiverne af Wallet-backend-teamet, at vi skulle lave et skilt med en liste over vores tjenester, mikrotjenester og tegnebogsmonoliter og de ansvarlige for dem. Skilte er generelt nyttige inden for rimelige grænser.

Ud over oplysninger om, hvem der har ansvaret for hvad, var der svar på spørgsmålene: hvem er ejer af tjenesten, hvem er ansvarlig for dens udvikling, arkitektur og livscyklus. De personer, der er ansvarlige for denne service, er dem, der kan ordne det, hvis der sker noget. Ejeren af ​​tjenesten har ret til at forlade +2 i commits, de ansvarlige skal også være til stede ved gennemgangen før denne service accepterer en ny commit.

Som tiden gik, begyndte nye praksisser at blive anvendt, for eksempel migrering til Kubernetes, alle mulige checkstyles, spotbugs, ktlint, tilstedeværelsen af ​​logs i Kibana, autodiscovery-tjenester i stedet for direkte at angive adresser og andre nyttige ting. Og overalt tillod vores bord os at bevare relevansen af ​​vores tjenester. For os er dette en slags tjekliste, der siger, at denne service kan gøre dette, men det gør den ikke endnu. Men vi gik videre og indså, at vi mangler information om vores tjenester, som vi overvåger, hvor servicekilderne er placeret, hvor montageopgaver lanceres i TeamCity, hvordan de implementeres, hvor kilderne til end2end tests gemmes, billeder fra grooming sessioner om arkitekturen, om de trufne beslutninger. Ideelt set vil jeg gerne have, at al denne information ligger et sted og er lige ved hånden, når det er nødvendigt. Derfor blev vores skilt udgangspunktet for at søge information.

Men QIWI er, selvom det bevarer ånden fra en startup, en stor virksomhed. Vi er allerede 12 år, og teams ændrer sig: folk går, folk kommer, nye teams dannes. Og vi opdagede flere tjenester på vores domæne, som vi har arvet. Nogle kom fra udviklere fra andre teams, nogle var simpelthen på en eller anden måde indirekte relateret til Wallet, så vi har nu tjenesten på vores balance. Forstå hvad og hvordan det virker - hvorfor? Tjenesten fungerer, og vi har produktfunktioner, der absolut skal forbedres.

Hvordan det sker

Men på et tidspunkt opdager vi, at tjenesten holder op med at udføre sin funktion, noget er gået i stykker - hvad skal man gøre i sådan en situation? Tjenesten holdt simpelthen op med at fungere. Overhovedet. Og vi fandt ud af dette, for det første ved et tilfælde, og for det andet seks måneder senere. Det sker. Det eneste, vi vidste, var på hvilke virtuelle maskiner tjenesten ville blive installeret, hvor dens kilder var placeret, og det er alt. Vi laver en git-klon og dykker ned i tankerne på den person, der skrev dette for et par år siden, men hvad ser vi? Ingen af ​​Spring Boot, der er bekendt for os, selvom vi er vant til alt, vi har en fuld stack og alt det der. Måske er der en Spring Framework der? Men nej.

Fyren, der skrev alt dette, var hård og skrev alt på ren Java. Der er ingen sædvanlige værktøjer for en udvikler, og en idé opstår: vi skal omskrive alt dette. Vi har mikroservices, og fra hver brødrister kommer det sædvanlige "Guys, microservices are what you need!" Hvis noget pludselig går galt, kan du roligt tage ethvert sprog, og alt vil være godt.

Sagen er den, at nu har vi ikke en kunde, der er ansvarlig for denne service. Hvilke forretningskrav havde han, hvad skulle denne service gøre? Og tjenesten er tæt integreret i dine forretningsprocesser.

Fortæl mig nu, hvor nemt er det at omskrive en tjeneste uden at kende dens forretningskrav? Det er ikke klart, hvordan tjenesten logges; om der er målinger er ukendt. Hvad de er, om nogen, er så meget desto mere ukendt. Og samtidig indeholder tjenesten et stort antal klasser af uforståelig forretningslogik. Der er noget med i en form for database, som vi heller ikke ved noget om endnu.

Hvad skal man begynde med?

Fra det mest logiske punkt - tilgængeligheden af ​​tests. Der er normalt i det mindste en vis logik skrevet der, og du kan drage konklusioner om, hvad der sker. Nu er TDD moderigtigt, men vi ser, at for 5 år siden var alt næsten det samme, som det er nu: Der er næsten ingen enhedstest, og de vil ikke fortælle os noget overhovedet. Nå, undtagen måske en form for verifikation, hvordan noget xml er signeret med et eller andet brugerdefineret certifikat.

Vi kunne ikke forstå noget fra koden, så vi gik for at se, hvad der var i den virtuelle maskine. Vi åbnede servicelogfilerne og fandt en http-klientfejl i dem; det selvsignerede certifikat, der var indlejret i applikationsressourcerne, var skamløst råddent. Vi kontaktede vores analytikere, de bad om et nyt certifikat, de udstedte det til os, og tjenesten fungerer igen. Det ser ud til, at det er alt. Eller ikke? Tjenesten virker trods alt, den udfører en eller anden funktion, som vores virksomhed har brug for. Vi har visse standarder for applikationsudvikling, som du højst sandsynligt også har. Gem for eksempel ikke logfiler på noden i en mappe, men gem dem i en form for opbevaring, såsom elastik, og se på dem i Kibana. Du kan også huske de gyldne metrikker. Det vil sige belastningen på tjenesten, antallet af anmodninger om tjenesten, om han er i live eller ej, hvordan det går med hans HealthCheck. Disse målinger vil i det mindste hjælpe dig med at vide, hvornår den kan tages ud af drift med god samvittighed og glemmes som en ond drøm.

Hvad skal man gøre

Derfor tilføjer vi sådan en gammel tjeneste til bordet, og så går vi på udkig efter frivillige blandt udviklerne, som vil tage sig af tjenesten og sætte den i stand: de vil i det mindste skrive nogle oplysninger om tjenesten, tilføje links til dashboards i grafana, til monteringsopgaver og forstå, hvordan Deploy applikationen, lad være med at uploade filer manuelt ved hjælp af ftp.

Det vigtigste er, hvor lang tid vil al denne nyttige frivillige aktivitet tage? En sprint for en mere eller mindre erfaren udvikler, for eksempel under en 20% teknisk gæld. Hvor lang tid tog det at forstå al ​​den indgroede logik i at kommunikere med et bestemt statssystem og bringe det til nyere teknologier? Jeg kan ikke stå inde for dette, måske en måned eller måske to af holdets arbejde. Jeg siger dette ud fra erfaring med nuværende integration med en ny tjeneste.

Samtidig sker der ingen frigivelse af forretningsværdi. Overhovedet. Det er normalt at hyre en service til support og bruge lidt tid på det. Men efter vores standarddanser med tjenesten, føjede vi den til bordet, tilføjede information om den og vil måske omskrive den en dag. Men nu opfylder den vores servicestandarder.

Som et resultat vil jeg gerne komme med en plan for, hvad jeg skal gøre med Legacy-tjenester.

At omskrive arv fra bunden er en dårlig idé
Seriøst, du behøver ikke engang at tænke over det. Det er klart, at jeg gerne vil have det, og der er nogle fordele, men som regel er der ingen, der har brug for det, inklusive dig selv.

Bibliotek
Udgrav kildekoderne til dine applikationer, lav en opslagsbog, der vil indikere, hvad der er, hvor og hvordan det virker, indtast en beskrivelse af projektet der (conditional readme.md) for hurtigt at forstå, hvor logfilerne og metrikken er placeret. Udvikleren, der vil håndtere dette efter dig, vil kun sige tak.

Forstå domænet
Hvis du ejer et domæne, så prøv at holde fingeren på pulsen. Det lyder trivielt, ja, men det er ikke alle, der sørger for, at tjenesterne er i en enkelt nøgle. Men at arbejde i én standard er faktisk væsentligt nemmere.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Hvad gør du med din arv?

• 31.5 %Jeg omskriver fra bunden, det er mere korrekt 12

• 52.6 %Næsten det samme som dig 20

• 10.5 %Vi har ikke arv, vi er fantastiske4

• 5.2 %Jeg skriver i kommentarerne2

38 brugere stemte. 20 brugere undlod at stemme.

Kilde: www.habr.com