🥇Legacy-shërbimet në infrastrukturën tuaj

Përshëndetje! Emri im është Pasha Chernyak, unë jam zhvillues kryesor në QIWI, dhe sot dëshiroj të flas për diçka të pashmangshme. Rreth Legacy.

Le të fillojmë me një pyetje: çfarë është një shërbim Legacy? A është një shërbim që zhvilluesi nuk e ka prekur për një javë/muaj/vit? Apo është një shërbim që u shkrua nga një programues më pak të eksperiencës, siç ishit ju, por një vit më parë? Tani, ju jeni më të mirë dhe më të përvojshëm. Apo ndoshta, shërbimi Legacy është ai që keni vendosur ta lini pa e prekur më dhe po përgatiteni për ta zëvendësuar ngadalë? Në çdo rast, lënia e një shërbimi të tillë pa mbikëqyrje dhe pa e përditësuar — është një bombë me kohëzgjatje, e cila mund të shpërthejë më vonë.

Para se të kalojmë tek mënyra se si ne në QIWI punojmë me shërbimet tona Legacy, do t'ju tregoj se si e rregulluam situatën me shërbimet në Portofolin. Ka dy vjet që unë përgjigjem për funksionimin e tij. Nëse ka ndonjë problem, gjithmonë më telefonojnë mua së pari. Më mungon zakonisht guximi për t'i telefonuar dikujt tjetër në orën 11 të mbrëmjes, prandaj kam qenë i detyruar të ulem dhe të kuptoj të gjitha shërbimet e domainit tonë.

Por ndonjë arsye, si çdo njeri tjetër, unë e dua të flenë natën, prandaj përpiqesha të kuptoja situatën: "Djem, pse më telefononi?". Përgjigjja ishte e thjeshtë: "Kënd tjetër?". Sepse unë marrë në dorë shërbimet, ndërsa ata thjesht nuk dinë se kujt t'i drejtohen.

Prandaj, në një nga retrospektivat e ekipit të back-end të Portofolit, vendosëm që të përgatitim një tabelë me listën e shërbimeve tona, mikroshërbimeve dhe monoliteve të portofolit, së bashku me përgjegjësit për to. Tabelat janë gjithmonë të dobishme, në kufij të arsyeshëm.

Përveç informacionit se kush është përgjegjës për çfarë, aty kishte përgjigje për pyetje si: kush është pronari i shërbimit, kush është përgjegjës për zhvillimin e tij, për arkitekturën dhe ciklin e jetës. Njerëzit përgjegjës për këtë shërbim janë ata që mund ta riparojnë atë në rast nevoje. Pronari i shërbimit ka të drejtë të lërë +2 në komitet, ndërsa përgjegjësit duhet gjithmonë të jenë të pranishëm në rishikim përpara se ky shërbim të marrë një komitet të ri.

Koha kalonte, filluan të aplikoheshin praktika të reja, si migrimi në Kubernetes, kontrollet checkstyle, spotbugs, ktlint, pranimi i logeve në Kibana, autodiscovery e shërbimeve në vend të tregimit të adresave direkt dhe shumë të tjera. Dhe kudo tabela jonë lejonte të mbante aktualitetin e shërbimeve tona. Për ne, kjo është një lloj liste kontrolli që tregon që kjo shërbim di të bëjë këtë, por për këtë ende nuk është. Por ne shkuam më tej, duke kuptuar se na mungonte informacioni mbi shërbimet tona, për të cilat ne mbajmë nën vëzhgim, ku ndodhen kodet burimore të shërbimit, ku startohen detyrat për ndërtim në TeamCity, si shërbehen ato, ku ruhen kodet burimor të testeve end2end, fotografitë e arkitekturës, për vendimet e marra. Në mënyrë ideale, do të doja që gjithë ky informacion të ishte diku i ruajtur dhe i thjeshtë për t'u gjetur kur është e nevojshme. Prandaj, tabela jonë u bë pika e nisjes për të kërkuar informacion.

Por QIWI, ndonëse ruan frymën e një startupi, është një kompani e madhe. Ne jemi tashmë 12 vjeç, dhe ekipet ndryshojnë: njerëzit largohen, njerëzit vijnë, formohen ekipe të reja. Dhe ne kemi zbuluar në domenin tonë disa shërbime, që na janë trashëguar. Disa erdhën me zhvilluesit nga ekipe të tjera, disa thjesht ndërlidheshin në një mënyrë me Portofolin, prandaj shërbimi tani është në bilancin tonë. Pse të merremi me ato që funksionojnë dhe si funksionojnë? Shërbimi po punon dhe ne kemi karakteristika produktesh që duhet patjetër të realizojmë.

Si ndodh

Por një moment të caktuar, e kuptojmë se shërbimi ka ndalur së funksionuari, diçka është prishur — çfarë të bëjmë në një situatë të tillë? Shërbimi ndaloi së funksionuari. Plotësisht. Dhe e mësuam për këtë, në radhë të parë, rastësisht, dhe në radhë të dytë, pas gjashtë muajsh. Kështu ndodh. E vetmja gjë që dinim ishte se në cilat virtualka ishte vendosur shërbimi, ku ndodheshin kodet e tij burimore dhe asgjë më tepër. Ne bëjmë git clone dhe zhytim në mendimet e atij që e shkroi këtë disa vite më parë, por çfarë shohim? Asnjë Spring Boot të zakonshëm për ne, pavarësisht se jemi mësuar me gjithçka, ne jemi full stack dhe diçka të tillë. Ndërsa, ndoshta, është aty Spring Framework? Por ja që nuk është.

Djali që shkruante gjithçka ishte i ashpër dhe shkruante gjithçka në Java të pastër. Nuk ka mjete të zakonshme për zhvilluesit, dhe lind ideja — duhet të rikodojmë gjithçka. Ne kemi mikroshërbime, dhe nga çdo tostierë vjen deklarata e zakonshme "Djem, mikroshërbimet janë ato që ju duhen!". Nëse ndodhi ndonjë gjë e keqe, do të merrni qetësisht çfarëdo gjuhe dhe gjithçka do të shkojë për mrekulli.

Problemi është se tani nuk kemi një klient që përgjigjet për këtë shërbim. Çfarë kërkesash biznesi kishte ai, çfarë duhet të bëjë ky shërbim? Ky shërbim është ngushtësisht i integruar në proceset tuaja biznesore.

Dhe tani, sa e lehtë është të riprogramosh shërbimin pa e ditur kërkesat e tij biznesore? Si logaritet shërbimi, ka metrika - kjo është e panjohur. Cilat janë ato, nëse ekzistojnë - kjo është gjithashtu e panjohur. Dhe për më tepër, në shërbim ka një numër të madh klasash me logjikë biznesi të paqartë. Diçka hyn në një bazë të dhënash, për të cilën ne gjithashtu nuk dimë asgjë akoma.

Nga të fillojmë?

Nga gjëja më logjike - prania e testeve. Aty zakonisht është shkruar ndonjë logjikë dhe mund të nxirren përfundime mbi atë që po ndodh. Tani është në modë TDD, por ne shohim që edhe 5 vjet më parë ishte pothuajse ashtu si tani: testet unit janë gati të pa ekzistueshme, dhe ato nuk do t'na tregojnë asgjë në mënyrë të saktë. Të paktën, përveç ndonjë kontrolli, si nënshkruhet një xml me ndonjë certifikatë të personalizuar.

Nga kodi nuk arritëm të kuptonim asgjë, dhe ne e shikuam virtualen. Hapëm logjet e shërbimit dhe gjetëm një gabim të HTTP klientit, një certificat vetë-nënshkruar që ishte inkorporuar në burimet e aplikacionit, ishte shkatërruar pa mëshirë. Kemi kontaktuar analistët tanë, ata kërkuan një certificat të ri, ne e morëm atë dhe shërbimi përsëri funksionon. Mund të duket sikur kjo është e gjitha. Apo jo? Megjithatë, shërbimi funksionon, ai realizon një funksion të caktuar që i nevojitet biznesit tonë. Kemi disa standarde për zhvillimin e aplikacioneve, të cilat me siguri i keni edhe ju. Për shembull, të mos ruajmë logjet në nodë në një dosje, por t'i ruajmë në një depo, si elastic, për t'i parë ato në Kibana. Mund të përmendim edhe metrikat e arta. Kështu, ngarkesa mbi shërbim, numri i kërkesave mbi shërbim, nëse është aktiv apo jo, si kalon kontrollin shëndetësor. Të paktën, këto metrika do të ndihmojnë të kuptojmë kur mund ta çelim atë me një ndërgjegje të qetë dhe ta harrojmë si një makth të keq.

Çfarë të bëjmë

Prandaj ne e shtojmë një shërbim kaq të vjetër në tabelë, dhe pastaj shkojmë të kërkojmë nga zhvilluesit vullnetarë që të merren me shërbimin dhe ta sjellin atë në formë: të shkruajnë ndonjë informacion për shërbimin, të shtojnë lidhje për tabelat në Grafana, për detyrat e ndërtimit, të kuptojnë se si të çelni aplikacionin, nuk është e arsyeshme të ngarkoni skedarët me dorë përmes FTP-së.

E rëndësishme është sa kohë do të marrë e gjithë kjo aktivitet vullnetar i dobishëm? Një sprint për një zhvillues më shumë ose më pak të aftë, për shembull, gjatë 20%-it të borxhit teknik. Dhe sa kohë u desh për të kuptuar gjithë logjikën e thellë lidhur me komunikimin me ndonjë sistem shtetëror, për ta çuar atë në teknologji më të reja? Nuk jam i sigurt, ndoshta një muaj, ndoshta edhe dy punë ekipore. Këtë e them sipas përvojës së integrimit aktual me ndonjë shërbim të ri.

Megjithatë, nuk ka ndonjë vlerë për biznesin - asnjë. Fare. Të marrësh shërbimin në mbështetje dhe të shpenzosh pak kohë për të është normale. Por pas standardeve tona të shërbimit, e kemi shtuar atë në tabelë, kemi shtuar informacion për të dhe ndoshta një ditë do ta rindërtojmë. Por tani, ai përmbush standardet tona për punën e shërbimeve.

Si pasojë, do doja të çoja në një plan se çfarë të bëjmë me shërbimet Legacy.

Rindërtimi i legacy nga fillimi është një ide e keqe.
Seriozisht, madje as nuk duhet ta mendoni këtë. E qartë që do të dëshironit dhe duken disa përfitime, por zakonisht askush nuk ka nevojë për të, duke përfshirë veten tuaj.

Katalogu
Gjeni kodet burimore të aplikacioneve tuaja, bëni një katalog në të cilin do të tregoni se çfarë dhe ku ndodhet dhe si funksionon, gjithashtu shkruani përshkrimin e projektit (si një readme.md) për të kuptuar shpejt se ku ndodhen log-et dhe metrikat. Programuesi që do të merret me këtë pas jush do t'i thotë faleminderit.

Kuptoni domenin
Nëse keni ndonjë domen, përpiquni ta mbani dorën mbi puls. Duket klishe, por jo të gjithë i kushtojnë vëmendje që shërbimet të jenë në një linjë. Dhe në të vërtetë, të punosh në një standard është ndjeshëm më e lehtë.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutemi.