Äldre tjänster i din infrastruktur

Hallå! Jag heter Pasha Chernyak, jag är en ledande utvecklare på QIWI, och idag vill jag prata om det oundvikliga. Om Legacy.

Låt oss börja med frågan: vad är Legacy-tjänst? Är en äldre 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 specifikt, men för ett år sedan? Och nu är du coolare och mer erfaren. Eller är Legacy-tjänsten en tjänst som du har bestämt dig för att aldrig använda igen och sakta förbereder en ersättare för den? Att lämna en sådan tjänst utan uppsikt och inte uppdatera är i alla fall 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 att berätta hur vi skapade ordning på tjänsterna i Plånboken. Sedan två år tillbaka har jag varit ansvarig för dess prestation. Om det är något problem så ringer de mig alltid först. Jag brukar inte ha modet att ringa någon annan klockan 11, så jag var tvungen att sätta mig ner och lista ut alla tjänster på vår domän.

Men jag, som alla andra, gillar att sova på nätterna, så jag försökte ta itu med utnyttjandet: "Gubbar, varför ringer ni mig?" På vilket jag fick ett ganska lakoniskt svar som "Vem annars?" För jag fixar tjänster, och killarna vet helt enkelt inte vem de ska ringa.

Därför, vid en av retrospektiverna av Wallet backend-teamet, bestämde vi oss för att vi behövde göra en skylt med en lista över våra tjänster, mikrotjänster och plånboksmonoliter och de ansvariga för dem. Skyltar är i allmänhet användbara, inom rimliga gränser.

Förutom information om vem som ansvarar för vad fanns svar på frågorna: vem är ägare till tjänsten, vem ansvarar för dess utveckling, arkitektur och livscykel. De ansvariga för denna tjänst är de som kan fixa det om något händer. Ägaren av tjänsten har rätt att lämna +2 i commits, ansvariga måste även vara närvarande vid granskningen innan denna tjänst accepterar en ny commit.

Allteftersom tiden gick började nya metoder tillämpas, till exempel migrering till Kubernetes, alla sorters checkstyle, spotbugs, ktlint, närvaron av loggar i Kibana, autodiscovery-tjänster istället för att direkt ange adresser och andra användbara saker. Och överallt lät vårt bord oss ​​behålla relevansen av våra tjänster. För oss är det här en sorts checklista som säger att den här tjänsten kan göra det här, men det gör den inte än. Men vi gick vidare och insåg att vi saknar information om våra tjänster, som vi övervakar, var tjänstekällorna finns , där monteringsuppgifter lanseras i TeamCity, hur de distribueras, var källorna till end2end-tester lagras, bilder från grooming-sessioner om arkitekturen, om de beslut som fattats. Helst skulle jag vilja att all denna information skulle ligga någonstans och finnas till hands när det behövs. Därför blev vår skylt startpunkten för att söka information.

Men QIWI, även om det behåller andan av en startup, är ett stort företag. Vi är redan 12 år gamla, och team förändras: folk lämnar, folk kommer, nya team bildas. Och vi upptäckte flera tjänster på vår domän som vi ärvde. En del kom från utvecklare från andra team, vissa helt enkelt på något sätt indirekt relaterade till Plånboken, så vi har nu tjänsten på vår balansräkning. Att förstå vad och hur det fungerar – varför? Tjänsten fungerar och vi har produktfunktioner som definitivt behöver förbättras.

Hur det går till

Men någon gång upptäcker vi att tjänsten slutar utföra sin funktion, något är trasigt - vad ska man göra i en sådan situation? Tjänsten slutade helt enkelt fungera. Alls. Och vi fick reda på detta, för det första av en slump, och för det andra sex månader senare. Det händer. Det enda vi visste var på vilka virtuella maskiner tjänsten skulle distribueras, var dess källor fanns, och det är allt. Vi gör en git-klon och dyker in i sinnet på personen som skrev detta för några år sedan, men vad ser vi? Inget av Spring Boot som är bekant för oss, även om vi är vana vid allt, vi har en full stack och allt det där. Kanske finns det ett Spring Framework där? Men nej.

Killen som skrev allt detta var tuff och skrev allt på ren Java. Det finns inga vanliga verktyg för en utvecklare, och en idé uppstår: vi måste skriva om allt detta. Vi har mikrotjänster, och från varje brödrost kommer det vanliga "killar, mikrotjänster är vad du behöver!" Om något plötsligt går fel kan du lugnt ta vilket språk som helst och allt blir bra.

Grejen är att nu har vi ingen kund som ansvarar för den här tjänsten. Vilka affärskrav hade han, vad ska den här tjänsten göra? Och tjänsten är tätt integrerad i dina affärsprocesser.

Berätta nu för mig, hur lätt är det att skriva om en tjänst utan att känna till dess affärskrav? Det är inte klart hur tjänsten loggas; om det finns mätvärden är okänt. Vad de är, om några, är desto mer okänt. Och samtidigt innehåller tjänsten ett stort antal klasser av obegriplig affärslogik. Något ingår i någon sorts databas, som vi inte heller vet något om ännu.

Var ska man börja?

Från den mest logiska punkten - tillgängligheten av tester. Det brukar finnas åtminstone en del logik skriven där och man kan dra slutsatser om vad som händer. Nu är TDD på modet, men vi ser att för 5 år sedan var allt nästan som det är nu: det finns nästan inga enhetstester, och de kommer inte att berätta någonting alls. Tja, förutom kanske någon form av verifiering, hur viss 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 fanns i den virtuella maskinen. Vi öppnade tjänstloggarna och hittade ett http-klientfel i dem; det självsignerade certifikatet som var inbäddat i applikationsresurserna var skamlöst ruttet. Vi kontaktade våra analytiker, de bad om ett nytt certifikat, de utfärdade det till oss och tjänsten fungerar igen. Det verkar som att det är allt. Eller inte? Tjänsten fungerar trots allt, den utför någon funktion som vår verksamhet behöver. Vi har vissa standarder för applikationsutveckling, som du med största sannolikhet också har. Lagra till exempel inte loggar på noden i en mapp, utan lagra dem i någon form av förvaring, som resår, och titta på dem i Kibana. Du kan också komma ihåg de gyllene måtten. Det vill säga belastningen på tjänsten, antalet förfrågningar om tjänsten, om han lever eller inte, hur det går med hans HealthCheck. Åtminstone kommer dessa mätvärden att hjälpa dig att veta när den kan tas ur bruk med gott samvete och glömmas bort som en ond dröm.

Vad man ska göra

Därför lägger vi till en så gammal tjänst på bordet, och sedan går vi och letar efter volontärer bland utvecklarna som ska ta hand om tjänsten och sätta i ordning den: de kommer att skriva åtminstone lite information om tjänsten, lägga till länkar till instrumentpaneler i grafana, till monteringsuppgifter och förstå hur Deploy programmet, ladda inte upp filer manuellt med ftp.

Huvudsaken är hur lång tid kommer all denna användbara volontärverksamhet att ta? En sprint för en mer eller mindre erfaren utvecklare, till exempel under en 20% teknisk skuld. Hur lång tid tog det att förstå all den invanda logiken i att kommunicera med ett visst statligt system och föra det till nyare teknologier? Jag kan inte garantera detta, kanske en månad eller kanske två av teamets arbete. Jag säger detta av erfarenhet av nuvarande integration med någon ny tjänst.

Samtidigt sker inget frisläppande av affärsvärde. Alls. Det är normalt att anlita en tjänst för support och lägga lite tid på det. Men efter våra standarddanser med tjänsten lade vi till den i tabellen, lade till information om den och kommer kanske att skriva om den någon gång. Men nu uppfyller den våra servicestandarder.

Som ett resultat skulle jag vilja komma med en plan för vad jag ska göra med äldre tjänster.

Att skriva om arv från grunden är en dålig idé
Seriöst, du behöver inte ens tänka på det. Det är klart att jag skulle gilla det, och det finns några fördelar, men vanligtvis behöver ingen det, inklusive du själv.

katalog
Gräv fram källkoderna för dina applikationer, gör en referensbok som visar vad som är var och hur det fungerar, skriv in en beskrivning av projektet där (conditional readme.md) för att snabbt förstå var loggarna och mätvärdena finns. Utvecklaren som kommer att ta itu med detta efter dig säger bara tack.

Förstå domänen
Om du äger en domän, försök att hålla fingret på pulsen. Det låter trivialt, ja, men alla ser inte till att tjänsterna finns i en enda nyckel. Men att arbeta i en standard är faktiskt betydligt enklare.

Endast registrerade användare kan delta i undersökningen. Logga in, Snälla du.

Vad gör du med ditt arv?

• 31.5%Jag skriver om från början, det är mer korrekt 12

• 52.6%Nästan samma som du 20

• 10.5%Vi har inget arv, vi är fantastiska4

• 5.2%Jag skriver i kommentarerna2

38 användare röstade. 20 användare avstod från att rösta.

Källa: will.com