{"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\/da\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Legacy-tjenester i din infrastruktur","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hej! Jeg hedder Pasha Chernyak, jeg er hovedudvikler hos QIWI, og i dag vil jeg tale om det uundg\u00e5elige. Om Legacy.<\/p>\n

Lad os starte med sp\u00f8rgsm\u00e5let: hvad er en Legacy-service? Er en Legacy-service en service, som udvikleren ikke har r\u00f8rt ved i en uge\/m\u00e5ned\/\u00e5r? Eller er det en service, der blev skrevet af en mindre erfaren programm\u00f8r, for eksempel dig selv, men for et \u00e5r 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\u00e6ndigheder er det en bombe med tidsindstilling at lade en s\u00e5dan service st\u00e5 uoverv\u00e5get og ikke opdatere den.<\/p>\n

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

F\u00f8r jeg g\u00e5r videre til, hvordan vi hos QIWI arbejder med vores Legacy-services, vil jeg fort\u00e6lle, hvordan vi har gjort orden i services i Wallet. Jeg har v\u00e6ret ansvarlig for dets funktionalitet i to \u00e5r 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\u00e5 jeg var n\u00f8dt til at s\u00e6tte mig ned og finde ud af alt om services i vores dom\u00e6ne. <\/p>\n

Men jeg, ligesom enhver anden, elsker at sove om natten, s\u00e5 jeg pr\u00f8vede 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.<\/p>\n

Derfor besluttede vi p\u00e5 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\u00e6nser.
\n<\/a><\/noindex>
\nUdover information om, hvem der er ansvarlig for hvad, var der ogs\u00e5 svar p\u00e5 sp\u00f8rgsm\u00e5lene: 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\u00e6lde af problemer. Servicens ejer har ret til at tillade +2 commits, de ansvarlige skal ogs\u00e5 n\u00f8dvendigvis deltage i gennemgangen, f\u00f8r denne service modtager et nyt commit.<\/p>\n

Tiden gik, og nye praksisser begyndte at finde anvendelse, som f.eks. migration til Kubernetes, diverse checkstyle, spotbugs, ktlint, tilg\u00e6ngeligheden 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\u00f8re dette, men at det andet ikke er muligt endnu. Men vi gik videre, idet vi inds\u00e5, at vi manglede information om vores tjenester, som vi holdt \u00f8je med, hvor kildekoden til tjenesten ligger, hvor opgaverne til bygning k\u00f8res 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\u00e5 et sted og var lige ved h\u00e5nden, n\u00e5r det var n\u00f8dvendigt. Derfor blev vores skema et udgangspunkt for at s\u00f8ge information.<\/p>\n

Men QIWI, selvom det bevarer \u00e5nden af en startup, er en stor virksomhed. Vi har eksisteret i 12 \u00e5r, og teamene \u00e6ndrer sig: folk forlader, folk kommer, nye teams dannes. Og vi opdagede, at vi p\u00e5 vores dom\u00e6ne 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\u00e5 vores balance. Hvorfor skulle vi finde ud af, hvad der virker og hvordan? Tjenesten fungerer, og vi har produktfunktioner, som vi absolut skal implementere.<\/p>\n

Som det plejer at ske<\/h2>\n

\nMen p\u00e5 et tidspunkt opdager vi, at tjenesten stopper med at udf\u00f8re sin funktion, at noget er g\u00e5et i stykker \u2014 hvad g\u00f8r man i en s\u00e5dan situation? Tjenesten fungerer simpelthen ikke l\u00e6ngere. Slet ikke. Og vi fandt ud af det, for det f\u00f8rste, tilf\u00e6ldigt, og for det andet, efter seks m\u00e5neder. S\u00e5dan er det. Det eneste, vi vidste, var, p\u00e5 hvilke virtuelle maskiner tjenesten var oprettet, hvor dens kildekode l\u00e5, og alt. Vi laver git clone og dykker ned i tankerne hos den person, der skrev dette for flere \u00e5r 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\u00e5ske er der Spring Framework? Men nej.<\/p>\n

Dren, der skrev det hele, var h\u00e5rd og skrev alt i ren Java. Der er ingen s\u00e6dvanlige v\u00e6rkt\u00f8jer til udviklere, og tanken opst\u00e5r - det ville v\u00e6re godt at genopskrive det hele. Vi har jo mikroservices, og fra hver toaster h\u00f8rer vi den velkendte s\u00e6tning: \"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\u00e6re fint.<\/p>\n

Pointen er, at vi i \u00f8jeblikket ikke har en kunde, der er ansvarlig for denne service. Hvilke forretningskrav havde han, og hvad skal denne service egentlig g\u00f8re? Tjenesten er t\u00e6t integreret i dine forretningsprocesser. <\/p>\n

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\u00e5r ind i en database, som vi heller ikke ved noget om endnu. <\/p>\n

Hvor skal man begynde?<\/h2>\n

\nDet mest logiske - at have tests. Der st\u00e5r normalt noget logik, og man kan drage konklusioner om, hvad der sker. I dag er TDD p\u00e5 mode, men vi ser, at det for fem \u00e5r siden s\u00e5 stort set det samme ud som nu: der er n\u00e6sten ingen unit-tests, og de vil ikke rigtig fort\u00e6lle os noget. Bortset fra m\u00e5ske en eller anden kontrol af, hvordan en eller anden xml signeres med et eller andet specialcertifikat.<\/p>\n

Vi kunne ikke forst\u00e5 noget ved koden, s\u00e5 vi m\u00e5tte kigge p\u00e5, hvad der skete p\u00e5 virtualen. Vi \u00e5bnede logfilerne for tjenesten og fandt en fejl i http-klienten, et selvsigneret certifikat, som var indlejret i appens ressourcer, var fuldst\u00e6ndig udl\u00f8bet. 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\u00f8rer en funktion, som vores forretning har brug for. Vi har nogle standarder for udvikling af applikationer, som I sikkert ogs\u00e5 har. For eksempel at undg\u00e5 at opbevare logfiler p\u00e5 noden i en mappe, men i en eller anden form for lager, s\u00e5som Elasticsearch, og se p\u00e5 dem i Kibana. Man kan ogs\u00e5 n\u00e6vne de gyldne m\u00e5linger. Det vil sige belastningen p\u00e5 tjenesten, antallet af foresp\u00f8rgsler til tjenesten, fungerer den eller ej, og hvordan dens HealthCheck gennemf\u00f8res. I det mindste vil disse m\u00e5linger hj\u00e6lpe med at afg\u00f8re, hvorn\u00e5r den trygt kan tages ud af drift og glemmes som en d\u00e5rlig dr\u00f8m.<\/p>\n

Hvad skal man g\u00f8re<\/h2>\n

\nDerfor tilf\u00f8jer vi s\u00e5dan en gammel tjeneste til tabellen, og derefter s\u00f8ger vi blandt udviklerne efter frivillige, der kan tage sig af tjenesten og bringe den i orden: skrive nogle oplysninger om tjenesten, tilf\u00f8je links til dashboards i Grafana, til build-tasks, forst\u00e5 hvordan man distribuerer applikationen, for man kan jo ikke manuelt l\u00e6gge filer over via ftp. <\/p>\n

Det vigtigste er, hvor lang tid hele denne nyttige frivillige aktivitet vil tage? \u00c9n sprint for en mere eller mindre erfaren udvikler, for eksempel under 20% teknisk g\u00e6ld. Men hvor lang tid tog det at forst\u00e5 hele den indgroede logik omkring interaktion med et offentlig system og opdatere det til nyere teknologier? Jeg kan ikke garantere det, m\u00e5ske en m\u00e5ned, eller m\u00e5ske to ugers arbejde for teamet. Det siger jeg ud fra erfaring med integration nuv\u00e6rende tid med et eller andet nyt system.<\/p>\n

Samtidig er der ingen forretningsv\u00e6rdi at h\u00f8ste \u2014 overhovedet. At tage tjenesten til support og bruge lidt tid p\u00e5 det er normalt. Men efter vores standardprocesser med tjenesten har vi tilf\u00f8jet den til tabellen, tilf\u00f8jet information om den, og m\u00e5ske vil vi engang omskrive den. Men lige nu opfylder den vores standarder for tjenesters funktion.<\/p>\n

Som en afslutning vil jeg gerne opsummere, hvad man skal g\u00f8re med legacy-tjenester. <\/p>\n

At omskrive legacy fra bunden er en d\u00e5rlig id\u00e9.<\/b>
\nT\u00e6nk ikke engang over det. Det er klart, at man gerne vil, og der ses nogle fordele, men det er normalt ikke n\u00f8dvendigt for nogen, inklusive jer selv.<\/p>\n

H\u00e5ndbog<\/b>
\nGrav i kildekoderne til dine applikationer, lav en h\u00e5ndbog, der angiver hvad der ligger hvor, og hvordan det fungerer. Skriv ogs\u00e5 en projektbeskrivelse (en slags readme.md), s\u00e5 det hurtigt kan forst\u00e5s, hvor logfiler og m\u00e5linger ligger. Den udvikler, der arbejder med dette efter dig, vil kun sige tak.<\/p>\n

Forst\u00e5 dom\u00e6net<\/b>
\nHvis du ejer et dom\u00e6ne, s\u00e5 pr\u00f8v at holde fingeren p\u00e5 pulsen. Klich\u00e9en lyder, men ikke alle f\u00f8lger med i, at tjenesterne forbliver ensartede. At arbejde i \u00e9n standard g\u00f8r faktisk tingene meget lettere.<\/p>\n

Kun registrerede brugere kan deltage i unders\u00f8gelsen. Log ind<\/a><\/noindex>, please.<\/p>\n

Hvad g\u00f8r du med dit legacy?<\/h2>\n