{"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\/sl\/blog\/administrirovanie\/legacy-servisy-v-vashej-infrastrukture","title":{"rendered":"Legacy storitve v va\u0161i infrastrukturi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Zdravo! Moje ime je Pa\u0161a \u010cernjak, ja sam glavni razvija\u010d u QIWI, i danas \u017eelim razgovarati o neizbe\u017enom. O Legacy-u.<\/p>\n

Hajde da po\u010dnemo s pitanjem: \u0161ta je to Legacy-servis? Legacy-servis je onaj koji programer nije dotakao ve\u0107 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\u010dili nikada vi\u0161e ne komitovati i polako mu pripremate zamenu? U svakom slu\u010daju, ostavljati takav servis bez nadzora i ne a\u017eurirati ga - to je bomba s odlo\u017eenim delovanjem koja mo\u017ee eksplodirati kasnije.<\/p>\n

\"Legacy<\/a><\/noindex><\/p>\n

Pre nego \u0161to pre\u0111emo na to kako mi u QIWI radimo sa na\u0161im Legacy-servisima, ispri\u010da\u0107u vam kako smo sredili servise u Nov\u010daniku. Ve\u0107 dve godine ja sam odgovoran za njegovu funkcionalnost. Ako postoji neki problem, uvek prvo zovu mene. Obi\u010dno nemam hrabrosti da u 11 sati uve\u010de zovem nekog drugog, pa sam morao da sednem i razjasnim sve servise na\u0161eg domena. <\/p>\n

Ali ja, kao i svaka osoba, volim spavati no\u0107u, pa sam poku\u0161ao da se pozabavim upitima: 'Momci, za\u0161to me zovete?'. Na \u0161ta sam dobio sasvim koncizan odgovor: 'A kome drugome?'. Zato \u0161to popravljam servise, a jo\u0161 jednostavno momci ne znaju kome da se jave.<\/p>\n

Stoga smo na jednom od retrospektiva backend tima Nov\u010danika odlu\u010dili da trebamo sastaviti tabelu u kojoj \u0107e biti spisak na\u0161ih servisa, mikroservisa i monolita nov\u010danika, kao i odgovorne osobe za njih. Tabele su zaista korisne, u razumnim granicama.
\n<\/a><\/noindex>
\nPored informacija o tome ko je za \u0161ta odgovoran, tu su bili odgovori na pitanja: ko je vlasnik servisa, ko je odgovoran za njegov razvoj, arhitekturu i \u017eivotni ciklus. Ljudi odgovorni za taj servis su ti koji ga mogu popraviti u slu\u010daju problema. Vlasnik servisa ima pravo da ostavi +2 u komitima, odgovorni tako\u0111e moraju obavezno prisustvovati revijima pre nego \u0161to ovaj servis primi novi komit.<\/p>\n

\u010cas je mineval, za\u010dele so se uporabljati nove prakse, kot so migracija v Kubernetes, razli\u010dni checkstyle, spotbugs, ktlint, prisotnost logov v Kibani, autodiscovery storitev namesto neposrednega navajanja naslovov in druge koristne stvari. In povsod je na\u0161a tabela omogo\u010dila ohranjanje aktualnosti na\u0161ih storitev. Zame je to nekak\u0161en kontrolni seznam, ki govori, da ta storitev to zna, tega pa \u0161e ne. Vendar smo \u0161li dalje, zavedajo\u010d se, da nam primanjkuje informacij o na\u0161ih 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\u010ditvah. Idealno bi bilo imeti vse te informacije nekje shranjene in pri roki, ko jih potrebujemo. Zato je na\u0161a tabela postala izhodi\u0161\u010de za iskanje informacij.<\/p>\n

Ampak QIWI, \u010deprav ohranja duh startup-a, je velika dru\u017eba. Imamo \u017ee 12 let, in ekipe se spreminjajo: ljudje odhajajo, ljudje prihajajo, oblikujejo se nove ekipe. In na svojem podro\u010dju smo odkrili nekaj storitev, ki so nam bile zapu\u0161\u010dene. Nekaj je pri\u0161lo od razvijalcev iz drugih ekip, nekaj pa se je na nek na\u010din posredno nana\u0161alo na Denarnico, zato imamo zdaj to storitev na na\u0161em ra\u010dunu. Zakaj bi se ukvarjali s tem, kaj in kako deluje? Storitve delujejo, imamo produktne funkcije, ki jih moramo nujno implementirati.<\/p>\n

Tako se zgodi<\/h2>\n

\nToda v nekem trenutku odkrijemo, da storitev preneha opravljati svojo funkcijo, nekaj se je pokvarilo \u2014 kaj v tak\u0161ni situaciji? Storitve preprosto ne deluje. Sploh. In izvedeli smo to, najprej, po naklju\u010dju, in drugi\u010d, \u0161ele po \u0161estih mesecih. Tako se zgodi. Edina stvar, ki smo jo vedeli, je bila, na katerih virtualnih strojih je storitev name\u0161\u010dena, 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, \u010deprav smo se na vse navadili, imeli smo celoten kup in vse to. Morda je tam Spring Framework? A ni.<\/p>\n

Fanta, ki je vse to pisal, je bil strogo in je vse napisal v \u010disti Javi. Obi\u010dajnih orodij za razvijalce ni, in rodila se je ideja \u2014 vse to bi bilo treba prepisati. Imamo mikroservise, iz vsak toaster pa se sli\u0161i znano \"Fantje, mikroservisi \u2014 to je tisto, kar potrebujete!\". \u010ce se kaj ne ujema, lahko mirno vzamete kateri koli jezik in vse bo super.<\/p>\n

Te\u017eava je v tem, da trenutno nimamo naro\u010dnika, ki bi bil odgovoren za to storitev. Kak\u0161ne so njegove poslovne zahteve, kaj ta storitev sploh naj dela? Storitev je mo\u010dno integrirana v va\u0161e poslovne procese. <\/p>\n

Zdaj pa povejte, kako enostavno je prepisati storitev, ne da bi poznali njene poslovne zahteve? Storitev je zmedeno logirana, ali obstajajo metrike \u2014 neznano. Kake so, \u010de obstajajo \u2014 \u0161e posebej neznano. In pri tem ima storitev ogromno razredov nejasne poslovne logike. Nekaj vstopa v neko bazo podatkov, o kateri tudi me \u0161e ni\u010d ne vemo. <\/p>\n

Kje bi torej za\u010deli?<\/h2>\n

\nZ najbolj logi\u010dnega \u2014 z obstojem testov. Tam je obi\u010dajno napisana kak\u0161na logika in lahko potegnemo zaklju\u010dke o tem, kar se dogaja. Danes je v modi TDD, vendar vidimo, da je bilo pred 5 leti vse prakti\u010dno enako kot danes: enotnih testov skoraj ni, pa nam ne bodo povedali ni\u010d. Razen morda kak\u0161ne preveritve, kako se podpi\u0161e kak\u0161en xml s kak\u0161nim prilagojenim certifikatom.<\/p>\n

S kodo ni\u010d ni jasno, zato smo \u0161li pogledati, kaj se dogaja na virtualki. Odpremo dnevni\u0161ke 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\u0161e 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\u010deno funkcijo, ki jo potrebuje na\u0161e podjetje. Imamo dolo\u010dene standarde za razvoj aplikacij, ki jih verjetno imate tudi vi. Na primer, ne hraniti dnevnikov na vozli\u0161\u010du v mapi, ampak jih shraniti v nekem skladi\u0161\u010du, kot je Elasticsearch, in jih spremljati v Kibani. Lahko se spomnimo tudi na zlate metrike. To so obremenitev storitve, \u0161tevilo zahtevkov na storitev, ali je \u017eiva ali ne, kako poteka njen HealthCheck. Vsaj te metrike bodo pomagale ugotoviti, kdaj jo je mogo\u010de mirno umakniti iz obratovanja in pozabiti kot slab sanje.<\/p>\n

Kaj storiti<\/h2>\n

\nZato dodamo to staro storitev v tabelo in nato za\u010dnemo iskati med razvijalci prostovoljce, ki se bodo lotili te storitve in jo spravili v red: napisali bodo vsaj kakr\u0161ne koli informacije o storitvi, dodali povezave na nadzorne plo\u0161\u010de v Grafani, naloge za gradnjo in ugotovili, kako razporediti aplikacijo, saj ne moremo na roke nalagati datotek s pomo\u010djo FTP. <\/p>\n

Klju\u010dno vpra\u0161anje je, koliko \u010dasa bo ta koristna prostovoljna dejavnost vzela? En sprint za bolj ali manj izku\u0161enega razvijalca, na primer, med 20-odstotnim tehni\u010dnim dolgom. Kak\u0161no pa je bilo \u0161tevilo ur, ki so jih potrebovali za razumevanje zapletene logike komuniciranja z neko vladno sistem, da jo pripeljejo do novej\u0161ih tehnologij? Zato ne jam\u010dim, morda mesec, morda celo dva dela ekipe. To govorim iz izku\u0161enj integracije v dana\u0161njem \u010dasu z nekim novim servisom.<\/p>\n

Kljub temu pa ni nobene poslovne vrednosti. \u010cisto nobene. Prevzeti storitev v vzdr\u017eevanje in za to porabiti nekaj \u010dasa - to je normalno. Ampak po na\u0161ih standardnih plesih s storitvijo smo jo dodali v tabelo, dodatne informacije o njej in morda jo bomo nekega dne prepisali. Ampak trenutno zadostuje na\u0161im standardom dela storitev.<\/p>\n

Na koncu bi rad povzel nek na\u010drt, kaj storiti z legacijskimi storitvami. <\/p>\n

Prepisovanje legacijskih storitev od nule - slaba zamisel.<\/b>
\nResni\u010dno, o tem ni treba niti razmi\u0161ljati. Jasno je, da bi si \u017eeleli in vidijo se dolo\u010dene prednosti, vendar to obi\u010dajno nikogar, tudi vas samih, ne zanima.<\/p>\n

Katalog<\/b>
\nIzkopirajte izvorne kode va\u0161ih aplikacij in naredite katalog, v katerem bo navedeno, kaj in kje se nahaja ter kako deluje. Vanj vklju\u010dite 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.<\/p>\n

Razumite domeno<\/b>
\n\u010ce imate kak\u0161no domeno, sku\u0161ajte imeti roko na pulzu. Zveni banalno, ja, vendar ne vsi skrbijo, da bi bili storitve v enotnem klju\u010du. A dela se v enotnem standardu dejansko bistveno la\u017eje.<\/p>\n

Samo registrovani korisnici mogu u\u010destvovati u anketi. Prijavite se<\/a><\/noindex>, molim vas.<\/p>\n

Kaj po\u010dnete s svojim legacy?<\/h2>\n