Hej! Jeg hedder Pasha Chernyak, jeg er hovedudvikler hos QIWI, og i dag vil jeg tale om det uundgåelige. Om Legacy.
Lad os starte med spørgsmålet: hvad er en Legacy-service? Er en Legacy-service en service, som udvikleren ikke har rørt ved i en uge/måned/år? Eller er det en service, der blev skrevet af en mindre erfaren programmør, for eksempel dig selv, men for et år siden? Og nu er du klogere og mere erfaren. Eller er en Legacy-service en service, du har besluttet dig for aldrig at committe til igen, og som du stille og rolig forbereder en erstatning til? Under alle omstændigheder er det en bombe med tidsindstilling at lade en sådan service stå uovervåget og ikke opdatere den.
Før jeg går videre til, hvordan vi hos QIWI arbejder med vores Legacy-services, vil jeg fortælle, hvordan vi har gjort orden i services i Wallet. Jeg har været ansvarlig for dets funktionalitet i to år nu. Hvis der er et problem, ringer folk altid direkte til mig. Jeg har normalt ikke modet til at ringe til nogen andre klokken 23, så jeg var nødt til at sætte mig ned og finde ud af alt om services i vores domæne.
Men jeg, ligesom enhver anden, elsker at sove om natten, så jeg prøvede at finde ud af, hvorfor de ringer til mig: "Folk, hvorfor ringer I til mig?" Til det fik jeg et ret kort svar: "Hvem ellers?" Fordi jeg reparerer services, og folkene ved simpelthen ikke, hvem de skal ringe til.
Derfor besluttede vi på et af retrospektivene med backend-teamet i Wallet, at vi skulle lave en tabel med en liste over vores services, mikrotjenester og monolitter i Wallet, samt dem, der er ansvarlige for dem. Tabel er generelt nyttige, inden for rimelige grænser.
Udover information om, hvem der er ansvarlig for hvad, var der også svar på spørgsmålene: hvem ejer servicen, hvem er ansvarlig for dens udvikling, arkitektur og livscyklus. De mennesker, der er ansvarlige for denne service, er dem, der kan reparere den i tilfælde af problemer. Servicens ejer har ret til at tillade +2 commits, de ansvarlige skal også nødvendigvis deltage i gennemgangen, før denne service modtager et nyt commit.
Tiden gik, og nye praksisser begyndte at finde anvendelse, som f.eks. migration til Kubernetes, diverse checkstyle, spotbugs, ktlint, tilgængeligheden af logs i Kibana, autodiscovery af tjenester i stedet for at angive adresser direkte og andre nyttigheder. Og overalt gjorde vores skema det muligt at opretholde aktualitet for vores tjenester. For os er det en slags tjekliste, der viser, at denne tjeneste kan gøre dette, men at det andet ikke er muligt endnu. Men vi gik videre, idet vi indså, at vi manglede information om vores tjenester, som vi holdt øje med, hvor kildekoden til tjenesten ligger, hvor opgaverne til bygning køres i TeamCity, hvordan de bliver implementeret, hvor kildekoden til end2end tests gemmes, fotos fra grooming om arkitekturen, og om de beslutninger, der er truffet. Ideelt ville vi have, at al denne information lå et sted og var lige ved hånden, når det var nødvendigt. Derfor blev vores skema et udgangspunkt for at søge information.
Men QIWI, selvom det bevarer ånden af en startup, er en stor virksomhed. Vi har eksisteret i 12 år, og teamene ændrer sig: folk forlader, folk kommer, nye teams dannes. Og vi opdagede, at vi på vores domæne havde flere tjenester, der var blevet overdraget til os. Noget kom fra udviklerne fra andre teams, noget var blot indirekte relateret til Wallet, derfor har vi nu tjenesten på vores balance. Hvorfor skulle vi finde ud af, hvad der virker og hvordan? Tjenesten fungerer, og vi har produktfunktioner, som vi absolut skal implementere.
Som det plejer at ske
Men på et tidspunkt opdager vi, at tjenesten stopper med at udføre sin funktion, at noget er gået i stykker — hvad gør man i en sådan situation? Tjenesten fungerer simpelthen ikke længere. Slet ikke. Og vi fandt ud af det, for det første, tilfældigt, og for det andet, efter seks måneder. Sådan er det. Det eneste, vi vidste, var, på hvilke virtuelle maskiner tjenesten var oprettet, hvor dens kildekode lå, og alt. Vi laver git clone og dykker ned i tankerne hos den person, der skrev dette for flere år siden, men hvad ser vi? Ingen af de velkendte Spring Boot, selvom vi er vant til det, vi har jo full stack og alt det der. Måske er der Spring Framework? Men nej.
Dren, der skrev det hele, var hård og skrev alt i ren Java. Der er ingen sædvanlige værktøjer til udviklere, og tanken opstår - det ville være godt at genopskrive det hele. Vi har jo mikroservices, og fra hver toaster hører vi den velkendte sætning: "Drengene, mikroservices er, hvad I har brug for!" Hvis der pludselig er noget galt, kan I roligt tage et hvilket som helst sprog, og alt vil være fint.
Pointen er, at vi i øjeblikket ikke har en kunde, der er ansvarlig for denne service. Hvilke forretningskrav havde han, og hvad skal denne service egentlig gøre? Tjenesten er tæt integreret i dine forretningsprocesser.
Men hvor let er det at genopskrive en service uden at kende dens forretningskrav? Tjenesten logger uklart, og der er ingen oplysninger om, hvilke metrikker der findes. Hvis de findes, er det stadig uklart, hvilke de er. Og derudover er der i tjenesten et stort antal klasser med uklar forretningslogik. Noget går ind i en database, som vi heller ikke ved noget om endnu.
Hvor skal man begynde?
Det mest logiske - at have tests. Der står normalt noget logik, og man kan drage konklusioner om, hvad der sker. I dag er TDD på mode, men vi ser, at det for fem år siden så stort set det samme ud som nu: der er næsten ingen unit-tests, og de vil ikke rigtig fortælle os noget. Bortset fra måske en eller anden kontrol af, hvordan en eller anden xml signeres med et eller andet specialcertifikat.
Vi kunne ikke forstå noget ved koden, så vi måtte kigge på, hvad der skete på virtualen. Vi åbnede logfilerne for tjenesten og fandt en fejl i http-klienten, et selvsigneret certifikat, som var indlejret i appens ressourcer, var fuldstændig udløbet. Vi kontaktede vores analytikere, de bad om et nyt certifikat, som blev udstedt, og tjenesten fungerer igen. Det kunne synes, at det var det hele. Eller nej? Tjenesten fungerer stadig, den udfører en funktion, som vores forretning har brug for. Vi har nogle standarder for udvikling af applikationer, som I sikkert også har. For eksempel at undgå at opbevare logfiler på noden i en mappe, men i en eller anden form for lager, såsom Elasticsearch, og se på dem i Kibana. Man kan også nævne de gyldne målinger. Det vil sige belastningen på tjenesten, antallet af forespørgsler til tjenesten, fungerer den eller ej, og hvordan dens HealthCheck gennemføres. I det mindste vil disse målinger hjælpe med at afgøre, hvornår den trygt kan tages ud af drift og glemmes som en dårlig drøm.
Hvad skal man gøre
Derfor tilføjer vi sådan en gammel tjeneste til tabellen, og derefter søger vi blandt udviklerne efter frivillige, der kan tage sig af tjenesten og bringe den i orden: skrive nogle oplysninger om tjenesten, tilføje links til dashboards i Grafana, til build-tasks, forstå hvordan man distribuerer applikationen, for man kan jo ikke manuelt lægge filer over via ftp.
Det vigtigste er, hvor lang tid hele denne nyttige frivillige aktivitet vil tage? Én sprint for en mere eller mindre erfaren udvikler, for eksempel under 20% teknisk gæld. Men hvor lang tid tog det at forstå hele den indgroede logik omkring interaktion med et offentlig system og opdatere det til nyere teknologier? Jeg kan ikke garantere det, måske en måned, eller måske to ugers arbejde for teamet. Det siger jeg ud fra erfaring med integration nuværende tid med et eller andet nyt system.
Samtidig er der ingen forretningsværdi at høste — overhovedet. At tage tjenesten til support og bruge lidt tid på det er normalt. Men efter vores standardprocesser med tjenesten har vi tilføjet den til tabellen, tilføjet information om den, og måske vil vi engang omskrive den. Men lige nu opfylder den vores standarder for tjenesters funktion.
Som en afslutning vil jeg gerne opsummere, hvad man skal gøre med legacy-tjenester.
At omskrive legacy fra bunden er en dårlig idé.
Tænk ikke engang over det. Det er klart, at man gerne vil, og der ses nogle fordele, men det er normalt ikke nødvendigt for nogen, inklusive jer selv.
Håndbog
Grav i kildekoderne til dine applikationer, lav en håndbog, der angiver hvad der ligger hvor, og hvordan det fungerer. Skriv også en projektbeskrivelse (en slags readme.md), så det hurtigt kan forstås, hvor logfiler og målinger ligger. Den udvikler, der arbejder med dette efter dig, vil kun sige tak.
Forstå domænet
Hvis du ejer et domæne, så prøv at holde fingeren på pulsen. Klichéen lyder, men ikke alle følger med i, at tjenesterne forbliver ensartede. At arbejde i én standard gør faktisk tingene meget lettere.
Kun registrerede brugere kan deltage i undersøgelsen. , please.
Hvad gør du med dit legacy?
31.5%Jeg skriver det fra bunden, det er mere korrekt.
52.6%Næsten det samme som jer.
10.5%Vi har ikke noget legacy, vi gør det godt.
5.2%Jeg skriver det i kommentarerne.
38 brugere har stemt. 20 brugere har undladt at stemme.
Kilde: habr.com
