Përshëndetje! Unë quhem Pasha Chernyak, jam zhvilluesi kryesor në QIWI, dhe sot dua të flas për të pashmangshmen. Rreth Legacy.
Të fillojmë me një pyetje: çfarë është një shërbim Legacy? A është një shërbim, të cilin zhvilluesi nuk e ka prekur për një javë/muaj/vit? Apo është një shërbim, që është shkruar nga një programues më pak me përvojë, për shembull, konkretisht nga ju, por një vit më parë? Dhe tani ju jeni më të zotë dhe më të përvojë. Apo ndoshta, shërbimi Legacy është një shërbim që ju vendosët të mos e angazhoni më dhe po e përgatitni ngadalë për zëvendësim? Çfarëdo qoftë, lënia e këtij shërbimi pa mbikëqyrje dhe mos e përditësimi i tij — është një bombë me sahat që mund të shpërthejë më vonë.
Para se të kalojmë te mënyra se si ne në QIWI punojmë me shërbimet tona Legacy, do të flas për mënyrën se si ne rregulluam shërbimet në Portofolin. Që dy vjet, unë kam përgjegjësinë për funksionimin e tij. Nëse ndonjëherë ka një problem, gjithmonë më telefonojnë për herë të parë. Më zakonisht, nuk kam guximin të telefonoj dikë tjetër në 11 të natës, kështu që më duhet të ulem dhe të merrem me të gjitha shërbimet e domain-it tonë.
Por unë, si çdo njeri tjetër, më pëlqen të fle natën, prandaj përpiqesha të kuptoja ekspluatimin: "Djem, pse më telefononi mua?" Për të cilin mora një përgjigje mjaft të shkurtër si: "Kujt tjetër?". Sepse unë riparoj shërbimet, dhe djemtë thjesht nuk dinë se kush duhet të telefonojnë.
Prandaj, në një nga retrospektivat e ekipit të backend-it të Portofolit ne vendosëm se duhej të krijonim një tabelë, në të cilën do të ishte lista e shërbimeve tona, mikroshërbimeve dhe monoliteve të portofolit, dhe ata që janë përgjegjës për to. Tabelat janë të dobishme, brenda arsyeshmërive.
Përveç informacionit se kush përgjigjet për çfarë, aty ishin përgjigjet për pyetje: 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. Njërit përgjegjës për këtë shërbim — njerëzit që mund ta rregullojnë atë në rast nevoje. Pronari i shërbimit ka të drejtë të lërë +2 në komitetet, përgjegjësit gjithashtu duhet të jenë patjetër prezentë në rishikim, përpara se ky shërbim të pranojë një komitet të ri.
Koha kalonte, filluan të aplikoheshin praktika të reja, për shembull, migrimi në Kubernetes, kontrolli i stilit, spotbugs, ktlint, pranimi i log-eve në Kibana, autodiscovery të shërbimeve në vend të caktimit direkt të adresave dhe tjera dobishmëri. Dhe kudo, tabela jonë na lejonte të mbajmë aktualitetin e shërbimeve tona. Për ne, kjo është një lloj liste kontrolli që tregon se ky shërbim di ta bëjë këtë, por këtë tjetër ende jo. Por ne shkuam përpara, duke kuptuar se na mungonte informacioni mbi shërbimet tona, për të cilat ne mbikqyrim, ku ndodhen burimet e shërbimit, ku nisen detyrat për ndërtim në TeamCity, si depozitojnë, ku ruhen burimet e testeve end2end, fotografitë për arkitekturën, për vendimet e marra. Në mënyrë ideale do të donim që të gjithë ky informacion të ishte diku dhe të ishte në dispozicion kur të nevojitej. Prandaj, tabelën tonë e bëmë fillimin për kërkimin e informacionit.
Por QIWI, ndonëse ruan shpirtin e një startup-i, është një kompani e madhe. Ne jemi tashmë 12 vjet dhe ekipet po ndryshojnë: njerëzit ikin, njerëzit vijnë, formohen ekipe të reja. Dhe zbuluam në domenin tonë disa shërbime që na kishin mbetur trashëgim. Disa erdhën nga zhvilluesit e ekipeve të tjera, disa lidheshin në mënyrë indirekte me Portofolin, prandaj shërbimi tani është në bilancin tonë. Pse të merremi me atë se çfarë punon dhe si? Shërbimi funksionon, dhe kemi veçori produkti që duhet t'i zbatojmë patjetër.
Si ndodh zakonisht
Por në një moment të caktuar, zbulojmë se shërbimi ndalon së funksionuari, diçka është prishur — çfarë të bëjmë në këtë situatë? Shërbimi thjesht ka pushuar së funksionuari. Plotësisht. Dhe e mësuam këtë, së pari, rastësisht, dhe së dyti, pas gjashtë muajsh. Kështu ndodh. E vetmja gjë që dinim ishte në cilat virtualka është instaluar shërbimi, ku ndodhen burimet e tij, dhe gjithçka tjetër. Ne bëjmë git clone dhe përfshihemi në mendimet e personit që e kishte shkruar këtë disa vjet më parë, por çfarë shohim? Asnjë gjë e njohur për ne si Spring Boot, megjithëse jemi mësuar me gjithçka, na duhen full stack dhe të gjitha ato. Ndoshta ka Spring Framework? Por jo.
Djali që e shkruajti këtë ishte i ashpër dhe shkruante gjithçka në Java të pastër. Nuk ka asnjë mjet të njohur për zhvilluesit, dhe lind ideja - duhet ta rishkruajmë të gjithë këtë. Ne kemi mikroshërbime, dhe nga secili toster dëgjohet e njohura "Djem, mikroshërbimet janë ato që ju duhen!". Nëse ndodhi ndonjë gjë e keqe, ju do të mund të merrni çdo gjuhë dhe gjithçka do të shkojë mirë.
Problemi është se momentalisht 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.
Tani, sa e lehtë është të rishkruash një shërbim, pa e ditur kërkesat e tij biznesore? Shërbimi nuk dihet si logaritet, a ka metrika - nuk dihet. Cilat janë ato, nëse ka - akoma më shumë nuk dihet. Dhe gjithashtu, në shërbim ka një numër të madh klasash me logjikë biznesi të paqartë. Disa gjëra futen në një bazë të dhënash, për të cilën ne për momentin nuk dimë asgjë.
Nga e duhet të fillosh?
Nga gjëja më logjike - nga prania e testeve. Atje zakonisht shkruhet ndonjë logjikë dhe mund të nxirren konkluzione për atë që po ndodh. Tani është modë TDD, por ne shohim se atëherë 5 vjet më parë gjithçka ishte praktikisht në të njëjtën gjëndje si tani: nuk ka pothuajse asnjë test unit, dhe ato nuk do të na thonë asgjë. Ndoshta vetëm për ndonjë kontroll, si nënshkruhet ndonjë xml me ndonjë certifikatë të personalizuar.
Me kodin nuk kemi arritur të kuptojmë asgjë, dhe ne duhet të shohim çfarë ndodh në virtualizim. Hapëm log-et e shërbimit, gjetëm në to një gabim të klientit http, një certifikatë e vetë-nënshkruar, e cila ishte e përfshirë në burimet e aplikacionit, kishte skaduar pa turp. Contact me analistët tanë, ata kërkuan një certifikatë të re, na e lëshuan dhe shërbimi tani funksionon përsëri. Mund të dukej se kjo është e gjitha. Apo jo? Në fund të fundit shërbimi funksionon, ai kryen një funksion të caktuar që i nevojitet biznesit tonë. Ne kemi disa standarde për zhvillimin e aplikacioneve, që me siguri i keni edhe ju. Për shembull, mos i ruani log-et në nod në dosje, por ruajini në një magazinë, si Elasticsearch, dhe shikoni ato në Kibana. Mund të kujtojmë edhe metrikat e arta. Kështu, ngarkesa në shërbim, numri i kërkesave në shërbim, a është ai aktiv apo jo, si kalon HealthCheck-un. Të paktën këto metrika do të ndihmojnë të kuptoni se kur mund ta nxirrni atë me një ndërgjegje të qetë nga eksploatimi dhe ta harroni si një ëndërr të keqe.
Çfarë të bëjmë
Prandaj, ne e shtojmë këtë shërbim të vjetër në tabelë, dhe më pas shkojmë të kërkojmë mes zhvilluesve vullnetarë që do të merren me shërbimin dhe do ta sjellin atë në rend: do të shkruajnë ndonjë informacion për shërbimin, do të shtojnë lidhje në dashboard-et në Grafana, në task-et e ndërtimit, do të kuptojnë si të zhvillojnë aplikacionin, nuk duhet ta bëjnë atë manualisht duke hedhur skedarë përmes FTP.
E rëndësishme është — sa kohë do të marrë kjo aktivitet i dobishëm vullnetar? Një sprint për një zhvillues mjaft të përvojshëm, për shembull, gjatë 20%-të e borxhit teknik. Dhe sa kohë është kërkuar për të kuptuar gjithë logjikën e ngulitur për komunikimin me ndonjë sistem shtetëror, për ta sjellë atë në teknologji më të reja? Nuk mund të jap një garanci për këtë, ndoshta një muaj, ndoshta edhe dy punë ekipesh. Këtë e them nga përvoja e integrimit në kohën aktuale me ndonjë shërbim të ri.
Megjithatë, nuk ka ndonjë vlerë biznesi nga kjo. Aspak. Të merrni shërbimin për mbështetje dhe të shpenzoni pak kohë për këtë — është normale. Por pas standardeve tona të zakonshme me shërbimin e shtuam atë në tabelë, shtuam informacion për të dhe, ndoshta, një ditë do ta riprogramojmë. Por tani ai përmbush standardet tona të punës me shërbimet.
Si përfundim, do të doja të arrija në një plan për atë çfarë të bëjmë me shërbimet Legacy.
Të riprogramosh heritage-n nga e para — është një ide e keqe
Seriozisht, mund të mos mendoni fare për këtë. Është e qartë që do të donim, dhe duket se ka disa përfitime, por zakonisht askujt nuk i nevojitet, përfshirë veten tuaj.
Katalog
Gërmoni kodet burimore të aplikacioneve tuaja, krijoni një katalog ku do të shpjegoni se çfarë dhe ku ndodhet dhe si funksionon, gjithashtu përfshini përshkrimin e projektit (e thënë ndryshe readme.md), për ta kuptuar shpejt se ku ndodhen log-ët dhe metrikat. Programuesi që do të merret me këtë pas jush, vetëm do t'ju falenderojë.
Kuptoni domainin
Nëse keni ndonjë domain, përpiquni të qëndroni mbi pulsin. Tingëllon banal, po, por jo të gjithë kujdesen që shërbimet të jenë në një njësi të vetme. Punimi në një standard në të vërtetë është më i lehtë.
Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. , ju lutem.
Çfarë po bëni me legacy tuaj?
31.5%Po e ri-shkruaj nga e para, kështu është më e saktë
52.6%Pothuajse të njëjtën gjë që bëni ju
10.5%Nuk kemi legacy, jemi të mrekullueshëm
5.2%Do ta shkruaj në komentet
Votuan 38 përdorues. U përmbajtën 20 përdorues.
Burimi: habr.com
