Eldre tjenester i infrastrukturen din

Hallo! Jeg heter Pasha Chernyak, jeg er en ledende utvikler hos QIWI, og i dag vil jeg snakke om det uunngåelige. Om arv.

La oss starte med spørsmålet: hva er Legacy-tjenesten? Er en eldre tjeneste en tjeneste som utvikleren ikke har rørt på en uke/måned/år? Eller er det en tjeneste som ble skrevet av en mindre erfaren programmerer, for eksempel av deg spesifikt, men for et år siden? Og nå er du kulere og mer erfaren. Eller er Legacy-tjenesten en tjeneste du har bestemt deg for aldri å forplikte deg til igjen og sakte forbereder en erstatning for den? Uansett, å la en slik tjeneste stå uten tilsyn og ikke oppdatere er en tidsinnstilt bombe som kan eksplodere senere.

Før jeg går videre til hvordan vi i QIWI jobber med våre eldre tjenester, vil jeg fortelle deg hvordan vi fikk orden på tjenestene i lommeboken. I to år nå har jeg vært ansvarlig for ytelsen. Hvis det er noe problem, ringer de meg alltid først. Jeg orker vanligvis ikke å ringe noen andre klokken 11, så jeg måtte sette meg ned og finne ut alle tjenestene på domenet vårt.

Men jeg, som enhver person, liker å sove om natten, så jeg prøvde å takle utnyttelsen: "Gutter, hvorfor ringer dere meg?" Som jeg fikk et ganske lakonisk svar som "Hvem ellers?" Fordi jeg fikser tjenester, og gutta vet rett og slett ikke hvem de skal ringe.

Derfor, på et av retrospektivene til Wallet-backend-teamet, bestemte vi oss for at vi måtte lage et skilt med en liste over våre tjenester, mikrotjenester og lommebokmonolitter, og de som er ansvarlige for dem. Skilt er generelt nyttige, innenfor rimelighetens grenser.

I tillegg til informasjon om hvem som har ansvar for hva, var det svar på spørsmålene: hvem er eier av tjenesten, hvem har ansvar for utvikling, arkitektur og livsløp. De som er ansvarlige for denne tjenesten er de som kan fikse det hvis noe skjer. Eieren av tjenesten har rett til å legge igjen +2 i commits, de ansvarlige må også være tilstede ved gjennomgangen før denne tjenesten godtar en ny commit.

Etter hvert som tiden gikk begynte ny praksis å bli brukt, for eksempel migrering til Kubernetes, alle slags checkstyle, spotbugs, ktlint, tilstedeværelsen av logger i Kibana, autodiscovery-tjenester i stedet for direkte å spesifisere adresser og andre nyttige ting. Og overalt tillot bordet oss å opprettholde relevansen til tjenestene våre. For oss er dette en slags sjekkliste som sier at denne tjenesten kan gjøre dette, men den gjør det ikke ennå. Men vi gikk videre, og innså at vi mangler informasjon om tjenestene våre, som vi overvåker, hvor tjenestekildene befinner seg , hvor monteringsoppgaver lanseres i TeamCity, hvordan de distribueres, hvor kildene til end2end-tester er lagret, bilder fra grooming-økter om arkitekturen, om beslutningene som er tatt. Ideelt sett vil jeg at all denne informasjonen skal ligge et sted og være for hånden når det trengs. Derfor ble skiltet vårt utgangspunktet for å søke informasjon.

Men QIWI, selv om det beholder ånden til en oppstart, er et stort selskap. Vi er allerede 12 år, og lagene endrer seg: folk drar, folk kommer, nye lag dannes. Og vi oppdaget flere tjenester på domenet vårt som vi har arvet. Noen kom fra utviklere fra andre team, noen rett og slett indirekte relatert til Wallet, så vi har nå tjenesten på balansen vår. Forstå hva og hvordan det fungerer – hvorfor? Tjenesten fungerer, og vi har produktfunksjoner som definitivt må forbedres.

Hvordan det skjer

Men på et tidspunkt oppdager vi at tjenesten slutter å utføre sin funksjon, noe er ødelagt - hva skal man gjøre i en slik situasjon? Tjenesten sluttet rett og slett å fungere. I det hele tatt. Og vi fant ut om dette, for det første ved et uhell, og for det andre seks måneder senere. Det skjer. Det eneste vi visste var på hvilke virtuelle maskiner tjenesten ville bli distribuert, hvor kildene var plassert, og det er alt. Vi gjør en git-kloning og dykker ned i tankene til personen som skrev dette for noen år siden, men hva ser vi? Ingen av Spring Boot som er kjent for oss, selv om vi er vant til alt, har vi full stack og alt det der. Kanskje det er et Spring Framework der? Men nei.

Fyren som skrev alt dette var tøff og skrev alt på ren Java. Det er ingen vanlige verktøy for en utvikler, og en idé oppstår: vi må skrive om alt dette. Vi har mikrotjenester, og fra hver brødrister kommer det vanlige "Gutta, mikrotjenester er det du trenger!" Hvis noe plutselig går galt, kan du rolig ta hvilket som helst språk, og alt blir bra.

Saken er den at nå har vi ikke en kunde som er ansvarlig for denne tjenesten. Hvilke forretningskrav hadde han, hva skulle denne tjenesten gjøre? Og tjenesten er tett integrert i forretningsprosessene dine.

Fortell meg nå, hvor enkelt er det å omskrive en tjeneste uten å kjenne dens forretningskrav? Det er ikke klart hvordan tjenesten er logget; om det er beregninger er ukjent. Hva de er, om noen, er desto mer ukjent. Og samtidig inneholder tjenesten et stort antall klasser av uforståelig forretningslogikk. Noe er inkludert i en slags database, som vi heller ikke vet noe om ennå.

Med hva skal du begynne?

Fra det mest logiske punktet - tilgjengeligheten av tester. Det er vanligvis i det minste noe logikk skrevet der, og du kan trekke konklusjoner om hva som skjer. Nå er TDD moteriktig, men vi ser at for 5 år siden var alt nesten det samme som det er nå: det er nesten ingen enhetstester, og de vil ikke fortelle oss noe i det hele tatt. Vel, bortsett fra kanskje en form for bekreftelse, hvordan noe xml er signert med et tilpasset sertifikat.

Vi kunne ikke forstå noe av koden, så vi gikk for å se hva som var i den virtuelle maskinen. Vi åpnet tjenesteloggene og fant en http-klientfeil i dem; det selvsignerte sertifikatet som var innebygd i applikasjonsressursene var skamløst råttent. Vi kontaktet analytikerne våre, de ba om et nytt sertifikat, de utstedte det til oss og tjenesten fungerer igjen. Det ser ut til at det er alt. Eller ikke? Tross alt fungerer tjenesten, den utfører en funksjon som virksomheten vår trenger. Vi har visse standarder for applikasjonsutvikling, som mest sannsynlig har du også. For eksempel, ikke lagre logger på noden i en mappe, men lagre dem i en slags lagring, for eksempel strikk, og se på dem i Kibana. Du kan også huske de gylne beregningene. Det vil si belastningen på tjenesten, antall forespørsler om tjenesten, om han er i live eller ikke, hvordan det går med HealthCheck. I det minste vil disse beregningene hjelpe deg å vite når den kan tas ut av drift med god samvittighet og glemmes som en vond drøm.

Hva du skal gjøre

Derfor legger vi en så gammel tjeneste på bordet, og så går vi på jakt etter frivillige blant utviklerne som vil ta seg av tjenesten og sette den i stand: de skal i det minste skrive litt informasjon om tjenesten, legge til lenker til dashboards i grafana, til monteringsoppgaver, og forstå hvordan Deploy applikasjonen, ikke last opp filer manuelt ved hjelp av ftp.

Hovedsaken er hvor lang tid vil all denne nyttige frivillige aktiviteten ta? En sprint for en mer eller mindre erfaren utvikler, for eksempel under en 20% teknisk gjeld. Hvor lang tid tok det å forstå all den inngrodde logikken i å kommunisere med et bestemt statssystem og bringe det til nyere teknologier? Jeg kan ikke gå god for dette, kanskje en måned eller kanskje to av teamets arbeid. Jeg sier dette fra erfaring med nåværende integrasjon med en ny tjeneste.

Samtidig er det ingen frigjøring av forretningsverdi. I det hele tatt. Det er normalt å leie en tjeneste for støtte og bruke litt tid på det. Men etter standarddansene våre med tjenesten, la vi den til bordet, la til informasjon om den og vil kanskje skrive den om en dag. Men nå oppfyller den våre servicestandarder.

Som et resultat vil jeg gjerne komme med en plan for hva jeg skal gjøre med Legacy-tjenester.

Å omskrive arv fra bunnen av er en dårlig idé
Seriøst, du trenger ikke engang tenke på det. Det er klart at jeg vil like det, og det er noen fordeler, men vanligvis trenger ingen det, inkludert deg selv.

Katalog
Grav ut kildekodene til applikasjonene dine, lag en oppslagsbok som vil indikere hva som er hvor og hvordan det fungerer, skriv inn en beskrivelse av prosjektet der (conditional readme.md) for raskt å forstå hvor loggene og metrikkene er plassert. Utvikleren som skal håndtere dette etter deg vil bare si takk.

Forstå domenet
Hvis du eier et domene, prøv å holde fingeren på pulsen. Det høres trivielt ut, ja, men ikke alle sørger for at tjenestene er i en enkelt nøkkel. Men å jobbe i én standard er faktisk betydelig enklere.

Kun registrerte brukere kan delta i undersøkelsen. Logg inn, vær så snill.

Hva gjør du med arven din?

• 31.5%Jeg skriver om fra bunnen av, det er mer riktig 12

• 52.6%Nesten det samme som deg20

• 10.5%Vi har ikke arv, vi er gode4

• 5.2%Jeg skal skrive i kommentarfeltet2

38 brukere stemte. 20 brukere avsto.

Kilde: www.habr.com