Zdravo! Moje ime je Paša Černjak, ja sam glavni razvijač u QIWI, i danas želim razgovarati o neizbežnom. O Legacy-u.
Hajde da počnemo s pitanjem: šta je to Legacy-servis? Legacy-servis je onaj koji programer nije dotakao već nedelju/mjesec/godinu? Ili je to servis koji je napisan od strane manje iskusnog programera, na primer, konkretno vas, ali pre godinu dana? A sada ste vi bolji i iskusniji. Ili, ipak, Legacy-servis je servis koji ste odlučili nikada više ne komitovati i polako mu pripremate zamenu? U svakom slučaju, ostavljati takav servis bez nadzora i ne ažurirati ga - to je bomba s odloženim delovanjem koja može eksplodirati kasnije.
Pre nego što pređemo na to kako mi u QIWI radimo sa našim Legacy-servisima, ispričaću vam kako smo sredili servise u Novčaniku. Već dve godine ja sam odgovoran za njegovu funkcionalnost. Ako postoji neki problem, uvek prvo zovu mene. Obično nemam hrabrosti da u 11 sati uveče zovem nekog drugog, pa sam morao da sednem i razjasnim sve servise našeg domena.
Ali ja, kao i svaka osoba, volim spavati noću, pa sam pokušao da se pozabavim upitima: 'Momci, zašto me zovete?'. Na šta sam dobio sasvim koncizan odgovor: 'A kome drugome?'. Zato što popravljam servise, a još jednostavno momci ne znaju kome da se jave.
Stoga smo na jednom od retrospektiva backend tima Novčanika odlučili da trebamo sastaviti tabelu u kojoj će biti spisak naših servisa, mikroservisa i monolita novčanika, kao i odgovorne osobe za njih. Tabele su zaista korisne, u razumnim granicama.
Pored informacija o tome ko je za šta odgovoran, tu su bili odgovori na pitanja: ko je vlasnik servisa, ko je odgovoran za njegov razvoj, arhitekturu i životni ciklus. Ljudi odgovorni za taj servis su ti koji ga mogu popraviti u slučaju problema. Vlasnik servisa ima pravo da ostavi +2 u komitima, odgovorni takođe moraju obavezno prisustvovati revijima pre nego što ovaj servis primi novi komit.
Čas je mineval, začele so se uporabljati nove prakse, kot so migracija v Kubernetes, različni checkstyle, spotbugs, ktlint, prisotnost logov v Kibani, autodiscovery storitev namesto neposrednega navajanja naslovov in druge koristne stvari. In povsod je naša tabela omogočila ohranjanje aktualnosti naših storitev. Zame je to nekakšen kontrolni seznam, ki govori, da ta storitev to zna, tega pa še ne. Vendar smo šli dalje, zavedajoč se, da nam primanjkuje informacij o naših storitvah, ki jih spremljamo, kje so izvorne kode storitve, kje se izvajajo naloge za sestavljanje v TeamCity, kako se distribuirajo, kje so shranjeni izvorni testi end2end, fotografije skic o arhitekturi, sprejetih odločitvah. Idealno bi bilo imeti vse te informacije nekje shranjene in pri roki, ko jih potrebujemo. Zato je naša tabela postala izhodišče za iskanje informacij.
Ampak QIWI, čeprav ohranja duh startup-a, je velika družba. Imamo že 12 let, in ekipe se spreminjajo: ljudje odhajajo, ljudje prihajajo, oblikujejo se nove ekipe. In na svojem področju smo odkrili nekaj storitev, ki so nam bile zapuščene. Nekaj je prišlo od razvijalcev iz drugih ekip, nekaj pa se je na nek način posredno nanašalo na Denarnico, zato imamo zdaj to storitev na našem računu. Zakaj bi se ukvarjali s tem, kaj in kako deluje? Storitve delujejo, imamo produktne funkcije, ki jih moramo nujno implementirati.
Tako se zgodi
Toda v nekem trenutku odkrijemo, da storitev preneha opravljati svojo funkcijo, nekaj se je pokvarilo — kaj v takšni situaciji? Storitve preprosto ne deluje. Sploh. In izvedeli smo to, najprej, po naključju, in drugič, šele po šestih mesecih. Tako se zgodi. Edina stvar, ki smo jo vedeli, je bila, na katerih virtualnih strojih je storitev nameščena, kje so njene izvorne kode, in to je vse. Naredimo git clone in se poglobimo v misli osebe, ki je to napisala pred nekaj leti, ampak kaj vidimo? Nobenega poznanega Spring Boot-a, čeprav smo se na vse navadili, imeli smo celoten kup in vse to. Morda je tam Spring Framework? A ni.
Fanta, ki je vse to pisal, je bil strogo in je vse napisal v čisti Javi. Običajnih orodij za razvijalce ni, in rodila se je ideja — vse to bi bilo treba prepisati. Imamo mikroservise, iz vsak toaster pa se sliši znano "Fantje, mikroservisi — to je tisto, kar potrebujete!". Če se kaj ne ujema, lahko mirno vzamete kateri koli jezik in vse bo super.
Težava je v tem, da trenutno nimamo naročnika, ki bi bil odgovoren za to storitev. Kakšne so njegove poslovne zahteve, kaj ta storitev sploh naj dela? Storitev je močno integrirana v vaše poslovne procese.
Zdaj pa povejte, kako enostavno je prepisati storitev, ne da bi poznali njene poslovne zahteve? Storitev je zmedeno logirana, ali obstajajo metrike — neznano. Kake so, če obstajajo — še posebej neznano. In pri tem ima storitev ogromno razredov nejasne poslovne logike. Nekaj vstopa v neko bazo podatkov, o kateri tudi me še nič ne vemo.
Kje bi torej začeli?
Z najbolj logičnega — z obstojem testov. Tam je običajno napisana kakšna logika in lahko potegnemo zaključke o tem, kar se dogaja. Danes je v modi TDD, vendar vidimo, da je bilo pred 5 leti vse praktično enako kot danes: enotnih testov skoraj ni, pa nam ne bodo povedali nič. Razen morda kakšne preveritve, kako se podpiše kakšen xml s kakšnim prilagojenim certifikatom.
S kodo nič ni jasno, zato smo šli pogledati, kaj se dogaja na virtualki. Odpremo dnevniške datoteke storitve in v njih najdemo napako http-strank, samopodpisan certifikat, ki je bil vgrajen v vire aplikacije, je nesramno potekel. Obrnili smo se na naše analitike, ki so zahtevali nov certifikat, in ta nam je bil izdana, storitev pa spet deluje. Zdi se, da je to vse. Ali pa tudi ne? Konec koncev storitev deluje, izvaja določeno funkcijo, ki jo potrebuje naše podjetje. Imamo določene standarde za razvoj aplikacij, ki jih verjetno imate tudi vi. Na primer, ne hraniti dnevnikov na vozlišču v mapi, ampak jih shraniti v nekem skladišču, kot je Elasticsearch, in jih spremljati v Kibani. Lahko se spomnimo tudi na zlate metrike. To so obremenitev storitve, število zahtevkov na storitev, ali je živa ali ne, kako poteka njen HealthCheck. Vsaj te metrike bodo pomagale ugotoviti, kdaj jo je mogoče mirno umakniti iz obratovanja in pozabiti kot slab sanje.
Kaj storiti
Zato dodamo to staro storitev v tabelo in nato začnemo iskati med razvijalci prostovoljce, ki se bodo lotili te storitve in jo spravili v red: napisali bodo vsaj kakršne koli informacije o storitvi, dodali povezave na nadzorne plošče v Grafani, naloge za gradnjo in ugotovili, kako razporediti aplikacijo, saj ne moremo na roke nalagati datotek s pomočjo FTP.
Ključno vprašanje je, koliko časa bo ta koristna prostovoljna dejavnost vzela? En sprint za bolj ali manj izkušenega razvijalca, na primer, med 20-odstotnim tehničnim dolgom. Kakšno pa je bilo število ur, ki so jih potrebovali za razumevanje zapletene logike komuniciranja z neko vladno sistem, da jo pripeljejo do novejših tehnologij? Zato ne jamčim, morda mesec, morda celo dva dela ekipe. To govorim iz izkušenj integracije v današnjem času z nekim novim servisom.
Kljub temu pa ni nobene poslovne vrednosti. Čisto nobene. Prevzeti storitev v vzdrževanje in za to porabiti nekaj časa - to je normalno. Ampak po naših standardnih plesih s storitvijo smo jo dodali v tabelo, dodatne informacije o njej in morda jo bomo nekega dne prepisali. Ampak trenutno zadostuje našim standardom dela storitev.
Na koncu bi rad povzel nek načrt, kaj storiti z legacijskimi storitvami.
Prepisovanje legacijskih storitev od nule - slaba zamisel.
Resnično, o tem ni treba niti razmišljati. Jasno je, da bi si želeli in vidijo se določene prednosti, vendar to običajno nikogar, tudi vas samih, ne zanima.
Katalog
Izkopirajte izvorne kode vaših aplikacij in naredite katalog, v katerem bo navedeno, kaj in kje se nahaja ter kako deluje. Vanj vključite tudi opis projekta (pogojni readme.md), da boste hitro razumeli, kje so dnevniki in metrike. Razvijalec, ki bo to preverjal po vas, vam bo le zahvalil.
Razumite domeno
Če imate kakšno domeno, skušajte imeti roko na pulzu. Zveni banalno, ja, vendar ne vsi skrbijo, da bi bili storitve v enotnem ključu. A dela se v enotnem standardu dejansko bistveno lažje.
Samo registrovani korisnici mogu učestvovati u anketi. , molim vas.
Kaj počnete s svojim legacy?
31.5%Prepisujem od začetka, tako je pravilneje12
52.6%Skoraj enako kot vi20
10.5%Nimamo legacy, smo dobri4
5.2%Napisal bom v komentarjih2
Glasovalo je 38 uporabnikov. 20 uporabnikov se je vzdržalo.
Izvor: habr.com
