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

Pozdrav! Zovem se Pasha \u010cernjak, ja sam vode\u0107i programer u QIWI, i danas \u017eelim razgovarati o neizbe\u017enom. O Legacy-u.<\/p>\n

Zapo\u010dnimo s pitanjem: \u0161to je to Legacy servis? Legacy servis je servis kojem programer nije pristupio tjedan\/mjesec\/godinu? Ili je to servis koji je napisao manje iskusni programer, recimo, konkretno vi, ali prije godinu dana? A sada ste bolji i iskusniji. Ili, Legacy servis je ipak onaj servis kojeg ste odlu\u010dili nikada vi\u0161e ne komitovati i polako mu pripremate zamjenu? U svakom slu\u010daju, ostaviti takav servis bez nadzora i ne a\u017eurirati ga - to je bombasti\u010dna ka\u0161njenja koja mo\u017ee kasnije eksplodirati.<\/p>\n

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

Prije nego pre\u0111emo na to kako mi u QIWI radimo s na\u0161im Legacy servisima, ispri\u010dat \u0107u kako smo doveli u red servise u Nov\u010daniku. Ve\u0107 dvije godine sam odgovoran za njegovu funkcionalnost. Ako postoji neki problem, uvijek prvo zovu mene. Obi\u010dno nisam dovoljno drzak da nazovem nekoga drugog u 11 sati nave\u010der, pa sam morao sjesti i razjasniti sve servise na\u0161eg domena. <\/p>\n

Ali ja, kao i svaka osoba, volim spavati no\u0107u, pa sam poku\u0161avao razjasniti kori\u0161tenje: \"Momci, za\u0161to me zovete?\" Na \u0161to sam dobio prili\u010dno sa\u017eet odgovor poput \"Kome drugome?\". Zato \u0161to popravljam servise, a de\u010dki jednostavno ne znaju koga nazvati.<\/p>\n

Zbog toga smo na jednom od retrospektiva backend tima Nov\u010danika odlu\u010dili da trebamo sastaviti tablicu s popisom na\u0161ih servisa, mikroservisa i monolita nov\u010danika, i onih koji su za njih odgovorni. Tablice su uistinu korisne, u razumnim granicama.
\n<\/a><\/noindex>
\nOsim informacija tko za \u0161to odgovara, tu su bili i odgovori na pitanja: tko je vlasnik servisa, tko odgovara za njegov razvoj, za arhitekturu i \u017eivotni ciklus. Osobe odgovorne za ovaj servis su one koje ga mogu popraviti u slu\u010daju potrebe. Vlasnik servisa ima pravo dodati +2 u komitima, a odgovorni tako\u0111er moraju biti prisutni na reviziji prije nego \u0161to ovaj servis preuzme novi komit.<\/p>\n

Vrijeme je prolazilo, po\u010deli smo primjenjivati nove prakse, poput migracije u Kubernetes, raznih checkstyle, spotbugs, ktlint, prisutnosti logova u Kibani, autodiscovery servisa umjesto direktnog navo\u0111enja adresa i drugih korisnih alata. I svugdje je na\u0161a tablica omogu\u0107avala odr\u017eavanje a\u017eurnosti na\u0161ih servisa. Za nas je to svojevrsna kontrolna lista koja govori da taj servis to i to mo\u017ee, a to jo\u0161 ne. No, i\u0161li smo dalje, shva\u0107aju\u0107i da nam nedostaje informacija o na\u0161im servisima, na koje pazimo, gdje se nalaze izvorni kodovi servisa, gdje se pokre\u0107u zadaci za izgradnju u TeamCityju, kako se deployaju, gdje se nalaze izvorni kodovi end2end testova, fotografije s grooming sesija o arhitekturi, o donesenim odlukama. Idealno bi bilo da sve te informacije budu negdje pohranjene i lako dostupne kada je to potrebno. Stoga je na\u0161a tablica postala polazna to\u010dka za pronala\u017eenje informacija.<\/p>\n

No QIWI, iako zadr\u017eava duh startupa, postala je velika kompanija. Ve\u0107 imamo 12 godina, a timovi se mijenjaju: ljudi odlaze, ljudi dolaze, formiraju se novi timovi. Otkrili smo na na\u0161em domenu nekoliko servisa koji su nam ostavljeni u naslje\u0111e. Neki su do\u0161li od programera iz drugih timova, neki su na neki na\u010din bili povezani s nov\u010danikom, pa smo ih sad uvrstili u na\u0161 portfelj. Za\u0161to se baviti time \u0161to i kako radi? Servis radi, a imamo proizvodne zna\u010dajke koje definitivno trebamo implementirati.<\/p>\n

Kako to obi\u010dno biva<\/h2>\n

\nNo u nekom trenutku otkrivamo da servis prestaje obavljati svoju funkciju, ne\u0161to se pokvarilo \u2014 \u0161ta u\u010diniti u toj situaciji? Servis jednostavno vi\u0161e ne radi. Potpuno. A saznali smo to, prvo, slu\u010dajno, a drugo, nakon pola godine. Tako to biva. Jedino \u0161to smo znali je na kojim virtuelnim ma\u0161inama je uspostavljen servis, gdje se nalaze njegovi izvorni kodovi, i to je to. Radimo git clone i uranjamo u misli osobe koja je to napisala prije nekoliko godina, ali \u0161to vidimo? Nema onog poznatog Spring Boota, iako smo na sve navikli, imamo full stack i sve to. Mo\u017eda postoji Spring Framework? A nema ga.<\/p>\n

Mladi\u0107 koji je sve ovo napisao bio je strog i sve je pisao na \u010distom Javi. Nema uobi\u010dajenih alata za programere, i javlja se ideja \u2014 treba to sve prepisati. Imamo mikroservise, a iz svake tosterne dopire poznata poruka: \"Ljudi, mikroservisi su ono \u0161to vam treba!\". Ako ne\u0161to po\u0111e po zlu, lako mo\u017eete uzeti bilo koji jezik i sve \u0107e biti u redu.<\/p>\n

Problem je u tome \u0161to trenutno nemamo klijenta koji odgovara za ovu uslugu. Koji su bili njegovi poslovni zahtjevi, \u0161to ta\u010dno ova usluga treba raditi? A usluga je \u010dvrsto integrirana u va\u0161e poslovne procese. <\/p>\n

A sada recite mi, koliko je lako prepisati uslugu, ne znaju\u0107i njene poslovne zahtjeve? Usluga se logira na nedostupan na\u010din, postoje li metrike \u2014 ne zna se. Koje su metrike, ako postoje \u2014 jo\u0161 manje se zna. I pritom u usluzi ima ogroman broj klasa nejasne poslovne logike. Ne\u0161to ulazi u neku bazu podataka, o kojoj tako\u0111er za sada ne znamo ni\u0161ta. <\/p>\n

Odakle po\u010deti?<\/h2>\n

\nOd onog najlogi\u010dnijeg \u2014 postojanja testova. Tamo je obi\u010dno napisana neka logika i mo\u017ee se izvu\u0107i zaklju\u010dke o tome \u0161to se doga\u0111a. Sada je popularan TDD, ali vidimo da je prije 5 godina sve bilo gotovo isto kao i sada: gotovo da nema unit-testova, a oni nam ne\u0107e re\u0107i ni\u0161ta posebno. Osim mo\u017eda nekakve provjere kako se potpisuje neki xml s nekim custom certifikatom.<\/p>\n

Nismo ni\u0161ta mogli shvatiti iz koda, pa smo odlu\u010dili provjeriti \u0161to se doga\u0111a na virtualnoj ma\u0161ini. Otvorili smo logove servisa i prona\u0161li gre\u0161ku http klijenta, a samopotpisani certifikat koji je bio ugra\u0111en u resurse aplikacije je istekao. Kontaktirali smo na\u0161e analiti\u010dare, tra\u017eili su novi certifikat, dobili smo ga i servis ponovo radi. \u010cinilo bi se da je to to. Ili nije? Servis i dalje radi, obavlja neku funkciju koja je potrebna na\u0161em poslovanju. Imamo odre\u0111ene standarde za razvoj aplikacija, koje vjerojatno imate i vi. Na primjer, ne \u010duvati logove na nodu u folderu, ve\u0107 ih pohraniti u neko skladi\u0161te, poput Elastica, i pregledavati ih u Kibani. Tako\u0111er mo\u017eemo spomenuti zlatne metrike. To su optere\u0107enje servisa, broj zahtjeva na servis, je li aktivan ili ne, kako prolazi HealthCheck. U najmanju ruku, ove metrike \u0107e pomo\u0107i da saznamo kada ga mo\u017eemo bez brige izvesti iz upotrebe i zaboraviti kao lo\u0161 san.<\/p>\n

\u0160to u\u010diniti<\/h2>\n

\nStoga dodajemo taj stari servis u tablicu, a zatim idemo tra\u017eiti me\u0111u developerima volontere koji \u0107e se brinuti o servisu i dovesti ga u red: napisat \u0107e barem neke informacije o servisu, dodati linkove na nadzorne plo\u010de u Grafani, na zadatke izrade, shvatiti kako razraditi aplikaciju, ne mo\u017eemo ru\u010dno preko FTP-a dodavati datoteke. <\/p>\n

Najva\u017enije je \u2014 koliko \u0107e svo to korisno volontersko anga\u017eiranje trajati? Jedan sprint za vi\u0161e manje iskusnog developera, na primjer, tijekom 20% tehni\u010dkog duga. A koliko je vremena utro\u0161eno na razumijevanje cijele zakukuljene logike komunikacije s nekom dr\u017eavnom sistemom, dovo\u0111enje na novije tehnologije? Za to se ne bih kladio, mo\u017ee mjesec, a mo\u017ee i dva rada tima. To govorim iz iskustva integracije u trenutno vrijeme s nekim novim servisom.<\/p>\n

Pri tome, izlazna poslovna vrijednost \u2014 nikakva. Potpuno. Uzeti servis u podr\u0161ku i potro\u0161iti malo vremena na to \u2014 u redu. No, nakon na\u0161ih uobi\u010dajenih plesova sa servisom, dodali smo ga u tablicu, dodali informacije o njemu i, mo\u017eda, nekad \u0107emo ga ponovno napisati. No sada ispunjava na\u0161e standarde rada servisa.<\/p>\n

Kao zaklju\u010dak, \u017eelio bih do\u0107i do nekog plana \u0161to u\u010diniti s legacy servisima. <\/p>\n

Prepisivanje naslije\u0111enog koda od nule \u2014 lo\u0161a ideja<\/b>
\nOzbiljno, nemojte ni razmi\u0161ljati o tome. Jasno je da bi ste \u017eeljeli i vide se neki plusovi, ali to obi\u010dno nikome nije potrebno, pa ni vama samima.<\/p>\n

Katalog<\/b>
\nIstra\u017eite izvorn kod va\u0161ih aplikacija, napravite katalog u kojem \u0107e biti navedeno \u0161to i gdje le\u017ei te kako funkcionira, uklju\u010dite i opis projekta (npr. readme.md), kako biste brzo razumjeli gdje se nalaze logovi i metrike. Razvija\u010d koji \u0107e se time baviti nakon vas, bit \u0107e vam zahvalan.<\/p>\n

Shvatite domen<\/b>
\nAko imate neku domenu, nastojte biti u toku. Zvu\u010di banalno, da, ali ne prate svi da su servisi uskla\u0111eni. A zapravo je puno jednostavnije raditi u jednom standardu.<\/p>\n

Samo registrirani korisnici mogu sudjelovati u anketi. Prijavite se<\/a><\/noindex>, molimo.<\/p>\n

\u0160to radite s va\u0161im legacy-em?<\/h2>\n