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

Hej! Jag heter Pasha Chernyak, jag \u00e4r huvudutvecklare p\u00e5 QIWI, och idag vill jag prata om det oundvikliga. Om Legacy.<\/p>\n

L\u00e5t oss b\u00f6rja med fr\u00e5gan: vad \u00e4r en Legacy-tj\u00e4nst? \u00c4r en Legacy-tj\u00e4nst en tj\u00e4nst som utvecklaren inte har r\u00f6rt p\u00e5 en vecka\/m\u00e5nad\/\u00e5r? Eller \u00e4r det en tj\u00e4nst som skrevs av en mindre erfaren programmerare, till exempel av dig f\u00f6r ett \u00e5r sedan? Och nu \u00e4r du mer kompetent och erfaren. Eller \u00e4r en Legacy-tj\u00e4nst en tj\u00e4nst som du har beslutat att aldrig mer g\u00f6ra commit p\u00e5 och som du l\u00e5ngsamt f\u00f6rbereder att ers\u00e4tta? Oavsett vad, att l\u00e4mna en s\u00e5dan tj\u00e4nst utan tillsyn och utan uppdateringar \u00e4r en tidsinst\u00e4lld bomb som kan explodera senare.<\/p>\n

\"Legacy-tj\u00e4nster<\/a><\/noindex><\/p>\n

Innan vi g\u00e5r vidare till hur vi p\u00e5 QIWI arbetar med v\u00e5ra Legacy-tj\u00e4nster, kommer jag ber\u00e4tta om hur vi organiserade tj\u00e4nsterna inom Pl\u00e5nboken. Jag har ansvarat f\u00f6r dess funktionalitet i tv\u00e5 \u00e5r. Om det uppst\u00e5r n\u00e5got problem, s\u00e5 \u00e4r det alltid mig de ringer f\u00f6rst. Jag har vanligtvis inte modet att ringa n\u00e5gon annan klockan 11 p\u00e5 kv\u00e4llen, s\u00e5 jag har f\u00e5tt s\u00e4tta mig ner och reda ut alla tj\u00e4nster i v\u00e5rt dom\u00e4n. <\/p>\n

Men jag, precis som alla m\u00e4nniskor, \u00e4lskar att sova p\u00e5 n\u00e4tterna, s\u00e5 jag f\u00f6rs\u00f6kte f\u00f6rst\u00e5 situationen: \"Grabbar, varf\u00f6r ringer ni mig?\". P\u00e5 vilket jag fick ett ganska koncist svar av typen \"Vem annars?\". F\u00f6r jag fixar tj\u00e4nster, och dessutom vet grabbarna helt enkelt inte vem de ska ringa.<\/p>\n

D\u00e4rf\u00f6r beslutade vi p\u00e5 ett av retrospektiven med backend-teamet f\u00f6r Pl\u00e5nboken att vi beh\u00f6vde g\u00f6ra en tabell med en lista \u00f6ver v\u00e5ra tj\u00e4nster, mikrotj\u00e4nster och monoliter i pl\u00e5nboken, samt ansvariga f\u00f6r dem. Tabeller \u00e4r faktiskt anv\u00e4ndbara, inom rimliga gr\u00e4nser.
\n<\/a><\/noindex>
\nF\u00f6rutom information om vem som ansvarar f\u00f6r vad, fanns det svar p\u00e5 fr\u00e5gor som: vem \u00e4r \u00e4garen av tj\u00e4nsten, vem ansvarar f\u00f6r dess utveckling, f\u00f6r arkitekturen och livscykeln. De som \u00e4r ansvariga f\u00f6r denna tj\u00e4nst \u00e4r personer som kan reparera den om det skulle beh\u00f6vas. Tj\u00e4nstens \u00e4gare har r\u00e4tt att l\u00e4mna +2 i commits, de ansvariga ska ocks\u00e5 vara n\u00e4rvarande vid granskning innan tj\u00e4nsten tar emot en ny commit.<\/p>\n

Tiden gick, nya metoder b\u00f6rjade till\u00e4mpas, till exempel migrering till Kubernetes, olika checkstyle, spotbugs, ktlint, n\u00e4rvaron av loggar i Kibana, autodiscovery av tj\u00e4nster ist\u00e4llet f\u00f6r att ange adresser direkt, och andra anv\u00e4ndbara verktyg. Och \u00f6verallt till\u00e4t v\u00e5r tabell att uppr\u00e4tth\u00e5lla aktualiteten f\u00f6r v\u00e5ra tj\u00e4nster. F\u00f6r oss \u00e4r detta en slags checklista som visar att denna tj\u00e4nst kan g\u00f6ra detta, men att detta \u00e4nnu inte kan g\u00f6ras. Men vi gick vidare och ins\u00e5g att vi saknade information om v\u00e5ra tj\u00e4nster, som vi \u00f6vervakar, var k\u00e4llkoden till tj\u00e4nsten ligger, var byggen k\u00f6rs i TeamCity, hur de distribueras, var k\u00e4llkoden f\u00f6r end2end-testerna finns, bilder fr\u00e5n arkitekturgranskningar och beslut som fattats. Idealt ville vi att all denna information skulle ligga p\u00e5 ett st\u00e4lle och vara tillg\u00e4nglig n\u00e4r det beh\u00f6vdes. D\u00e4rf\u00f6r blev v\u00e5r tabell en utg\u00e5ngspunkt f\u00f6r informationss\u00f6kning.<\/p>\n

Men QIWI, \u00e4ven om det beh\u00e5ller andan av ett startup, \u00e4r ett stort f\u00f6retag. Vi \u00e4r nu 12 \u00e5r gamla, och teamen f\u00f6r\u00e4ndras: m\u00e4nniskor g\u00e5r, m\u00e4nniskor kommer, nya team formas. Och vi uppt\u00e4ckte p\u00e5 v\u00e5r dom\u00e4n flera tj\u00e4nster som vi \u00e4rvde. N\u00e5got kom med utvecklarna fr\u00e5n andra team, n\u00e5got relaterade bara indirekt till pl\u00e5nboken, vilket g\u00f6r att tj\u00e4nsten nu ligger p\u00e5 v\u00e5rt saldo. Varf\u00f6r ska vi ta reda p\u00e5 vad och hur det fungerar? Tj\u00e4nsten fungerar ju, och vi har produktfunktioner som vi absolut m\u00e5ste implementera.<\/p>\n

S\u00e5nt h\u00e4nder<\/h2>\n

\nMen vid n\u00e5got tillf\u00e4lle uppt\u00e4cker vi att tj\u00e4nsten slutar fungera, n\u00e5got har g\u00e5tt s\u00f6nder - vad ska man g\u00f6ra i en s\u00e5dan situation? Tj\u00e4nsten fungerar helt enkelt inte l\u00e4ngre. \u00d6verhuvudtaget. Och vi fick veta detta, f\u00f6r det f\u00f6rsta, av en slump, och f\u00f6r det andra, efter ett halv\u00e5r. S\u00e5nt h\u00e4nder. Det enda vi visste var p\u00e5 vilka virtuella maskiner tj\u00e4nsten var distribuerad, var k\u00e4llkoden l\u00e5g, och det var allt. Vi g\u00f6r en git clone och dyker ner i tankarna hos personen som skrev detta f\u00f6r flera \u00e5r sedan, men vad ser vi? Ingen av den Spring Boot som vi \u00e4r vana vid, \u00e4ven om vi \u00e4r f\u00f6rtrogna med allt, vi har ju full stack och allt s\u00e5nt. Kanske finns det i alla fall Spring Framework? Men det finns inte.<\/p>\n

Killen som skrev allt detta var h\u00e5rd och skrev allt i ren Java. Det finns inga vanliga verktyg f\u00f6r utvecklare och tanken dyker upp - vi borde skriva om allt detta. Vi har ju mikrotj\u00e4nster, och fr\u00e5n varje br\u00f6drost h\u00f6rs det bekanta \"Grabbar, mikrotj\u00e4nster \u00e4r vad ni beh\u00f6ver!\". Om n\u00e5got g\u00e5r fel kan ni lugnt anv\u00e4nda vilket spr\u00e5k som helst och allt kommer att bli bra.<\/p>\n

Grejen \u00e4r att vi just nu inte har en best\u00e4llare som ansvarar f\u00f6r den h\u00e4r tj\u00e4nsten. Vilka aff\u00e4rskrav hade den, vad ska den h\u00e4r tj\u00e4nsten \u00f6verhuvudtaget g\u00f6ra? Tj\u00e4nsten \u00e4r djupt integrerad i era aff\u00e4rsprocesser. <\/p>\n

Och nu, s\u00e4g mig, hur enkelt \u00e4r det att skriva om en tj\u00e4nst utan att veta dess aff\u00e4rskrav? Tj\u00e4nsten loggas p\u00e5 ett oklart s\u00e4tt, finns det n\u00e5gra m\u00e4tv\u00e4rden - ingen aning. Vilka finns, om det finns n\u00e5gra - \u00e4nnu mindre vet vi. Dessutom finns det en enorm m\u00e4ngd klasser med otydlig aff\u00e4rslogik i tj\u00e4nsten. N\u00e5got g\u00e5r in i n\u00e5gon databas, om vilken vi ocks\u00e5 f\u00f6r n\u00e4rvarande inte vet n\u00e5got. <\/p>\n

Var ska vi b\u00f6rja?<\/h2>\n

\nMed det mest logiska - med testning. D\u00e4r st\u00e5r det vanligtvis n\u00e5gon form av logik och man kan dra slutsatser om vad som h\u00e4nder. Nu \u00e4r TDD p\u00e5 modet, men vi ser att de senaste 5 \u00e5ren har allt varit praktiskt taget likadant som nu: n\u00e4stan inga enhetstester, och de kommer inte att ber\u00e4tta f\u00f6r oss n\u00e5got av v\u00e4rde. F\u00f6rutom m\u00f6jligtvis n\u00e5gon form av kontroll, som hur ett xml signeras med n\u00e5got anpassat certifikat.<\/p>\n

Vi kunde inte f\u00f6rst\u00e5 n\u00e5got av koden, s\u00e5 vi gick f\u00f6r att se vad som h\u00e4nde p\u00e5 virtuella maskinen. Vi \u00f6ppnade loggarna f\u00f6r tj\u00e4nsten, fann ett fel i http-klienten, det sj\u00e4lvsignerade certifikatet som var inbakat i applikationens resurser hade tyv\u00e4rr g\u00e5tt ut. Vi kontaktade v\u00e5ra analytiker, de beg\u00e4rde ett nytt certifikat, vi fick det utf\u00e4rdat och tj\u00e4nsten fungerar igen. Det verkade som om allt var klart. Eller var det inte? Tj\u00e4nsten fungerar fortfarande, den utf\u00f6r n\u00e5gon funktion som beh\u00f6vs f\u00f6r v\u00e5r verksamhet. Vi har vissa standarder f\u00f6r applikationsutveckling som ni f\u00f6rmodligen ocks\u00e5 har. Till exempel, att inte lagra loggar p\u00e5 noden i en mapp, utan lagra dem i n\u00e5got lagringssystem, som Elasticsearch, och titta p\u00e5 dem i Kibana. Man kan ocks\u00e5 t\u00e4nka p\u00e5 gyllene metrik. Det vill s\u00e4ga belastning p\u00e5 tj\u00e4nsten, antal f\u00f6rfr\u00e5gningar till tj\u00e4nsten, \u00e4r den aktiv eller inte, hur g\u00e5r HealthCheck? \u00c5tminstone dessa m\u00e4tv\u00e4rden kommer att hj\u00e4lpa till att f\u00f6rst\u00e5 n\u00e4r man lugnt kan avveckla den och gl\u00f6mma den som en mardr\u00f6m.<\/p>\n

Vad g\u00f6r man<\/h2>\n

\nD\u00e4rf\u00f6r l\u00e4gger vi till en s\u00e5 gammal tj\u00e4nst i tabellen och g\u00e5r sedan f\u00f6r att leta efter frivilliga bland utvecklarna som vill ta hand om tj\u00e4nsten och f\u00e5 den i ordning: skriva n\u00e5gon information om tj\u00e4nsten, l\u00e4gga till l\u00e4nkar till dashboards i Grafana, till bygghanteringsuppgifter, f\u00f6rst\u00e5 hur man distribuerar applikationen, inte bara sl\u00e4nga upp filer manuellt med ftp. <\/p>\n

Det viktigaste \u00e4r hur mycket tid allt detta anv\u00e4ndbara frivilliga arbete kommer att ta? En sprint f\u00f6r en mer eller mindre erfaren utvecklare, till exempel under 20% teknisk skuld. Men hur mycket tid gick \u00e5t f\u00f6r att f\u00f6rst\u00e5 hela den inarbetade logiken f\u00f6r att kommunicera med ett visst statligt system, och uppgradera det till nyare teknologier? Jag kan inte garantera det, kanske en m\u00e5nad, kanske tv\u00e5 m\u00e5naders arbete f\u00f6r teamet. Det s\u00e4ger jag baserat p\u00e5 erfarenheten av integrationer med en ny tj\u00e4nst just nu.<\/p>\n

Samtidigt finns det ingen aff\u00e4rsnytta alls. Inga. Att ta tj\u00e4sten i drift och l\u00e4gga lite tid p\u00e5 det \u00e4r normalt. Men efter v\u00e5ra standarddansr\u00f6relser med tj\u00e4nsten lade vi till den i tabellen, la till information om den och, kanske, s\u00e5 sm\u00e5ningom kommer vi att skriva om den. Men just nu uppfyller den v\u00e5ra standarder f\u00f6r tj\u00e4nstehantering.<\/p>\n

Som en slutsats skulle jag vilja sammanfatta en viss plan f\u00f6r vad man ska g\u00f6ra med legacy-tj\u00e4nster. <\/p>\n

Att skriva om legacy fr\u00e5n grunden \u00e4r en d\u00e5lig id\u00e9.<\/b>
\nDet \u00e4r verkligen inget att t\u00e4nka p\u00e5. Det \u00e4r klart att man skulle vilja ha det, och vissa f\u00f6rdelar syns, men vanligtvis beh\u00f6vs det inte av n\u00e5gon, inklusive er sj\u00e4lva.<\/p>\n

Handbok<\/b>
\nGr\u00e4v fram k\u00e4llkoden till dina applikationer, skapa en handbok d\u00e4r det anges vad som finns var och hur det fungerar, skriv ocks\u00e5 en beskrivning av projektet (en slags readme.md), s\u00e5 att du snabbt kan f\u00f6rst\u00e5 var loggarna och metrikerna ligger. Utvecklaren som tar \u00f6ver efter er kommer bara att tacka.<\/p>\n

F\u00f6rst\u00e5 dom\u00e4nen<\/b>
\nOm du \u00e4ger en dom\u00e4n, f\u00f6rs\u00f6k att ha koll. Det l\u00e5ter banalt, visst, men inte alla ser till att tj\u00e4nsterna \u00e4r i enhetlig stil. Att arbeta i en och samma standard \u00e4r faktiskt mycket enklare.<\/p>\n

Endast registrerade anv\u00e4ndare kan delta i omr\u00f6stningen. Logga in<\/a><\/noindex>, tack.<\/p>\n

Vad g\u00f6r du med din legacy?<\/h2>\n