🥇Legacy-tjänster i din infrastruktur

Hej! Jag heter Pasha Chernyak, jag är huvudutvecklare på QIWI, och idag vill jag prata om det oundvikliga. Om Legacy.

Låt oss börja med frågan: vad är en Legacy-tjänst? Är en Legacy-tjänst en tjänst som utvecklaren inte har rört på en vecka/månad/år? Eller är det en tjänst som skrevs av en mindre erfaren programmerare, till exempel av dig för ett år sedan? Och nu är du mer kompetent och erfaren. Eller är en Legacy-tjänst en tjänst som du har beslutat att aldrig mer göra commit på och som du långsamt förbereder att ersätta? Oavsett vad, att lämna en sådan tjänst utan tillsyn och utan uppdateringar är en tidsinställd bomb som kan explodera senare.

Innan vi går vidare till hur vi på QIWI arbetar med våra Legacy-tjänster, kommer jag berätta om hur vi organiserade tjänsterna inom Plånboken. Jag har ansvarat för dess funktionalitet i två år. Om det uppstår något problem, så är det alltid mig de ringer först. Jag har vanligtvis inte modet att ringa någon annan klockan 11 på kvällen, så jag har fått sätta mig ner och reda ut alla tjänster i vårt domän.

Men jag, precis som alla människor, älskar att sova på nätterna, så jag försökte förstå situationen: "Grabbar, varför ringer ni mig?". På vilket jag fick ett ganska koncist svar av typen "Vem annars?". För jag fixar tjänster, och dessutom vet grabbarna helt enkelt inte vem de ska ringa.

Därför beslutade vi på ett av retrospektiven med backend-teamet för Plånboken att vi behövde göra en tabell med en lista över våra tjänster, mikrotjänster och monoliter i plånboken, samt ansvariga för dem. Tabeller är faktiskt användbara, inom rimliga gränser.

Förutom information om vem som ansvarar för vad, fanns det svar på frågor som: vem är ägaren av tjänsten, vem ansvarar för dess utveckling, för arkitekturen och livscykeln. De som är ansvariga för denna tjänst är personer som kan reparera den om det skulle behövas. Tjänstens ägare har rätt att lämna +2 i commits, de ansvariga ska också vara närvarande vid granskning innan tjänsten tar emot en ny commit.

Tiden gick, nya metoder började tillämpas, till exempel migrering till Kubernetes, olika checkstyle, spotbugs, ktlint, närvaron av loggar i Kibana, autodiscovery av tjänster istället för att ange adresser direkt, och andra användbara verktyg. Och överallt tillät vår tabell att upprätthålla aktualiteten för våra tjänster. För oss är detta en slags checklista som visar att denna tjänst kan göra detta, men att detta ännu inte kan göras. Men vi gick vidare och insåg att vi saknade information om våra tjänster, som vi övervakar, var källkoden till tjänsten ligger, var byggen körs i TeamCity, hur de distribueras, var källkoden för end2end-testerna finns, bilder från arkitekturgranskningar och beslut som fattats. Idealt ville vi att all denna information skulle ligga på ett ställe och vara tillgänglig när det behövdes. Därför blev vår tabell en utgångspunkt för informationssökning.

Men QIWI, även om det behåller andan av ett startup, är ett stort företag. Vi är nu 12 år gamla, och teamen förändras: människor går, människor kommer, nya team formas. Och vi upptäckte på vår domän flera tjänster som vi ärvde. Något kom med utvecklarna från andra team, något relaterade bara indirekt till plånboken, vilket gör att tjänsten nu ligger på vårt saldo. Varför ska vi ta reda på vad och hur det fungerar? Tjänsten fungerar ju, och vi har produktfunktioner som vi absolut måste implementera.

Sånt händer

Men vid något tillfälle upptäcker vi att tjänsten slutar fungera, något har gått sönder - vad ska man göra i en sådan situation? Tjänsten fungerar helt enkelt inte längre. Överhuvudtaget. Och vi fick veta detta, för det första, av en slump, och för det andra, efter ett halvår. Sånt händer. Det enda vi visste var på vilka virtuella maskiner tjänsten var distribuerad, var källkoden låg, och det var allt. Vi gör en git clone och dyker ner i tankarna hos personen som skrev detta för flera år sedan, men vad ser vi? Ingen av den Spring Boot som vi är vana vid, även om vi är förtrogna med allt, vi har ju full stack och allt sånt. Kanske finns det i alla fall Spring Framework? Men det finns inte.

Killen som skrev allt detta var hård och skrev allt i ren Java. Det finns inga vanliga verktyg för utvecklare och tanken dyker upp - vi borde skriva om allt detta. Vi har ju mikrotjänster, och från varje brödrost hörs det bekanta "Grabbar, mikrotjänster är vad ni behöver!". Om något går fel kan ni lugnt använda vilket språk som helst och allt kommer att bli bra.

Grejen är att vi just nu inte har en beställare som ansvarar för den här tjänsten. Vilka affärskrav hade den, vad ska den här tjänsten överhuvudtaget göra? Tjänsten är djupt integrerad i era affärsprocesser.

Och nu, säg mig, hur enkelt är det att skriva om en tjänst utan att veta dess affärskrav? Tjänsten loggas på ett oklart sätt, finns det några mätvärden - ingen aning. Vilka finns, om det finns några - ännu mindre vet vi. Dessutom finns det en enorm mängd klasser med otydlig affärslogik i tjänsten. Något går in i någon databas, om vilken vi också för närvarande inte vet något.

Var ska vi börja?

Med det mest logiska - med testning. Där står det vanligtvis någon form av logik och man kan dra slutsatser om vad som händer. Nu är TDD på modet, men vi ser att de senaste 5 åren har allt varit praktiskt taget likadant som nu: nästan inga enhetstester, och de kommer inte att berätta för oss något av värde. Förutom möjligtvis någon form av kontroll, som hur ett xml signeras med något anpassat certifikat.

Vi kunde inte förstå något av koden, så vi gick för att se vad som hände på virtuella maskinen. Vi öppnade loggarna för tjänsten, fann ett fel i http-klienten, det självsignerade certifikatet som var inbakat i applikationens resurser hade tyvärr gått ut. Vi kontaktade våra analytiker, de begärde ett nytt certifikat, vi fick det utfärdat och tjänsten fungerar igen. Det verkade som om allt var klart. Eller var det inte? Tjänsten fungerar fortfarande, den utför någon funktion som behövs för vår verksamhet. Vi har vissa standarder för applikationsutveckling som ni förmodligen också har. Till exempel, att inte lagra loggar på noden i en mapp, utan lagra dem i något lagringssystem, som Elasticsearch, och titta på dem i Kibana. Man kan också tänka på gyllene metrik. Det vill säga belastning på tjänsten, antal förfrågningar till tjänsten, är den aktiv eller inte, hur går HealthCheck? Åtminstone dessa mätvärden kommer att hjälpa till att förstå när man lugnt kan avveckla den och glömma den som en mardröm.

Vad gör man

Därför lägger vi till en så gammal tjänst i tabellen och går sedan för att leta efter frivilliga bland utvecklarna som vill ta hand om tjänsten och få den i ordning: skriva någon information om tjänsten, lägga till länkar till dashboards i Grafana, till bygghanteringsuppgifter, förstå hur man distribuerar applikationen, inte bara slänga upp filer manuellt med ftp.

Det viktigaste är hur mycket tid allt detta användbara frivilliga arbete kommer att ta? En sprint för en mer eller mindre erfaren utvecklare, till exempel under 20% teknisk skuld. Men hur mycket tid gick åt för att förstå hela den inarbetade logiken för att kommunicera med ett visst statligt system, och uppgradera det till nyare teknologier? Jag kan inte garantera det, kanske en månad, kanske två månaders arbete för teamet. Det säger jag baserat på erfarenheten av integrationer med en ny tjänst just nu.

Samtidigt finns det ingen affärsnytta alls. Inga. Att ta tjästen i drift och lägga lite tid på det är normalt. Men efter våra standarddansrörelser med tjänsten lade vi till den i tabellen, la till information om den och, kanske, så småningom kommer vi att skriva om den. Men just nu uppfyller den våra standarder för tjänstehantering.

Som en slutsats skulle jag vilja sammanfatta en viss plan för vad man ska göra med legacy-tjänster.

Att skriva om legacy från grunden är en dålig idé.
Det är verkligen inget att tänka på. Det är klart att man skulle vilja ha det, och vissa fördelar syns, men vanligtvis behövs det inte av någon, inklusive er själva.

Handbok
Gräv fram källkoden till dina applikationer, skapa en handbok där det anges vad som finns var och hur det fungerar, skriv också en beskrivning av projektet (en slags readme.md), så att du snabbt kan förstå var loggarna och metrikerna ligger. Utvecklaren som tar över efter er kommer bara att tacka.

Förstå domänen
Om du äger en domän, försök att ha koll. Det låter banalt, visst, men inte alla ser till att tjänsterna är i enhetlig stil. Att arbeta i en och samma standard är faktiskt mycket enklare.

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Vad gör du med din legacy?

31.5%Jag skriver om allt från grunden, det är korrekt.
52.6%Något i stil med vad du gör.
10.5%Vi har ingen legacy, vi är duktiga.
5.2%Jag skriver det i kommentarerna.

38 användare röstade. 20 användare avstod.

Källa: habr.com