🥇Legacy-servisi u vašoj infrastrukturi

Pozdrav! Zovem se Pasha Černjak, ja sam vodeći programer u QIWI, i danas želim razgovarati o neizbežnom. O Legacy-u.

Započnimo s pitanjem: što 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čili nikada više ne komitovati i polako mu pripremate zamjenu? U svakom slučaju, ostaviti takav servis bez nadzora i ne ažurirati ga - to je bombastična kašnjenja koja može kasnije eksplodirati.

Prije nego pređemo na to kako mi u QIWI radimo s našim Legacy servisima, ispričat ću kako smo doveli u red servise u Novčaniku. Već dvije godine sam odgovoran za njegovu funkcionalnost. Ako postoji neki problem, uvijek prvo zovu mene. Obično nisam dovoljno drzak da nazovem nekoga drugog u 11 sati navečer, pa sam morao sjesti i razjasniti sve servise našeg domena.

Ali ja, kao i svaka osoba, volim spavati noću, pa sam pokušavao razjasniti korištenje: "Momci, zašto me zovete?" Na što sam dobio prilično sažet odgovor poput "Kome drugome?". Zato što popravljam servise, a dečki jednostavno ne znaju koga nazvati.

Zbog toga smo na jednom od retrospektiva backend tima Novčanika odlučili da trebamo sastaviti tablicu s popisom naših servisa, mikroservisa i monolita novčanika, i onih koji su za njih odgovorni. Tablice su uistinu korisne, u razumnim granicama.

Osim informacija tko za što odgovara, tu su bili i odgovori na pitanja: tko je vlasnik servisa, tko odgovara za njegov razvoj, za arhitekturu i životni ciklus. Osobe odgovorne za ovaj servis su one koje ga mogu popraviti u slučaju potrebe. Vlasnik servisa ima pravo dodati +2 u komitima, a odgovorni također moraju biti prisutni na reviziji prije nego što ovaj servis preuzme novi komit.

Vrijeme je prolazilo, počeli smo primjenjivati nove prakse, poput migracije u Kubernetes, raznih checkstyle, spotbugs, ktlint, prisutnosti logova u Kibani, autodiscovery servisa umjesto direktnog navođenja adresa i drugih korisnih alata. I svugdje je naša tablica omogućavala održavanje ažurnosti naših servisa. Za nas je to svojevrsna kontrolna lista koja govori da taj servis to i to može, a to još ne. No, išli smo dalje, shvaćajući da nam nedostaje informacija o našim servisima, na koje pazimo, gdje se nalaze izvorni kodovi servisa, gdje se pokreću 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ša tablica postala polazna točka za pronalaženje informacija.

No QIWI, iako zadržava duh startupa, postala je velika kompanija. Već imamo 12 godina, a timovi se mijenjaju: ljudi odlaze, ljudi dolaze, formiraju se novi timovi. Otkrili smo na našem domenu nekoliko servisa koji su nam ostavljeni u nasljeđe. Neki su došli od programera iz drugih timova, neki su na neki način bili povezani s novčanikom, pa smo ih sad uvrstili u naš portfelj. Zašto se baviti time što i kako radi? Servis radi, a imamo proizvodne značajke koje definitivno trebamo implementirati.

Kako to obično biva

No u nekom trenutku otkrivamo da servis prestaje obavljati svoju funkciju, nešto se pokvarilo — šta učiniti u toj situaciji? Servis jednostavno više ne radi. Potpuno. A saznali smo to, prvo, slučajno, a drugo, nakon pola godine. Tako to biva. Jedino što smo znali je na kojim virtuelnim mašinama 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 što vidimo? Nema onog poznatog Spring Boota, iako smo na sve navikli, imamo full stack i sve to. Možda postoji Spring Framework? A nema ga.

Mladić koji je sve ovo napisao bio je strog i sve je pisao na čistom Javi. Nema uobičajenih alata za programere, i javlja se ideja — treba to sve prepisati. Imamo mikroservise, a iz svake tosterne dopire poznata poruka: "Ljudi, mikroservisi su ono što vam treba!". Ako nešto pođe po zlu, lako možete uzeti bilo koji jezik i sve će biti u redu.

Problem je u tome što trenutno nemamo klijenta koji odgovara za ovu uslugu. Koji su bili njegovi poslovni zahtjevi, što tačno ova usluga treba raditi? A usluga je čvrsto integrirana u vaše poslovne procese.

A sada recite mi, koliko je lako prepisati uslugu, ne znajući njene poslovne zahtjeve? Usluga se logira na nedostupan način, postoje li metrike — ne zna se. Koje su metrike, ako postoje — još manje se zna. I pritom u usluzi ima ogroman broj klasa nejasne poslovne logike. Nešto ulazi u neku bazu podataka, o kojoj također za sada ne znamo ništa.

Odakle početi?

Od onog najlogičnijeg — postojanja testova. Tamo je obično napisana neka logika i može se izvući zaključke o tome što se događa. 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će reći ništa posebno. Osim možda nekakve provjere kako se potpisuje neki xml s nekim custom certifikatom.

Nismo ništa mogli shvatiti iz koda, pa smo odlučili provjeriti što se događa na virtualnoj mašini. Otvorili smo logove servisa i pronašli grešku http klijenta, a samopotpisani certifikat koji je bio ugrađen u resurse aplikacije je istekao. Kontaktirali smo naše analitičare, tražili su novi certifikat, dobili smo ga i servis ponovo radi. Činilo bi se da je to to. Ili nije? Servis i dalje radi, obavlja neku funkciju koja je potrebna našem poslovanju. Imamo određene standarde za razvoj aplikacija, koje vjerojatno imate i vi. Na primjer, ne čuvati logove na nodu u folderu, već ih pohraniti u neko skladište, poput Elastica, i pregledavati ih u Kibani. Također možemo spomenuti zlatne metrike. To su opterećenje servisa, broj zahtjeva na servis, je li aktivan ili ne, kako prolazi HealthCheck. U najmanju ruku, ove metrike će pomoći da saznamo kada ga možemo bez brige izvesti iz upotrebe i zaboraviti kao loš san.

Što učiniti

Stoga dodajemo taj stari servis u tablicu, a zatim idemo tražiti među developerima volontere koji će se brinuti o servisu i dovesti ga u red: napisat će barem neke informacije o servisu, dodati linkove na nadzorne ploče u Grafani, na zadatke izrade, shvatiti kako razraditi aplikaciju, ne možemo ručno preko FTP-a dodavati datoteke.

Najvažnije je — koliko će svo to korisno volontersko angažiranje trajati? Jedan sprint za više manje iskusnog developera, na primjer, tijekom 20% tehničkog duga. A koliko je vremena utrošeno na razumijevanje cijele zakukuljene logike komunikacije s nekom državnom sistemom, dovođenje na novije tehnologije? Za to se ne bih kladio, može mjesec, a može i dva rada tima. To govorim iz iskustva integracije u trenutno vrijeme s nekim novim servisom.

Pri tome, izlazna poslovna vrijednost — nikakva. Potpuno. Uzeti servis u podršku i potrošiti malo vremena na to — u redu. No, nakon naših uobičajenih plesova sa servisom, dodali smo ga u tablicu, dodali informacije o njemu i, možda, nekad ćemo ga ponovno napisati. No sada ispunjava naše standarde rada servisa.

Kao zaključak, želio bih doći do nekog plana što učiniti s legacy servisima.

Prepisivanje naslijeđenog koda od nule — loša ideja
Ozbiljno, nemojte ni razmišljati o tome. Jasno je da bi ste željeli i vide se neki plusovi, ali to obično nikome nije potrebno, pa ni vama samima.

Katalog
Istražite izvorn kod vaših aplikacija, napravite katalog u kojem će biti navedeno što i gdje leži te kako funkcionira, uključite i opis projekta (npr. readme.md), kako biste brzo razumjeli gdje se nalaze logovi i metrike. Razvijač koji će se time baviti nakon vas, bit će vam zahvalan.

Shvatite domen
Ako imate neku domenu, nastojte biti u toku. Zvuči banalno, da, ali ne prate svi da su servisi usklađeni. A zapravo je puno jednostavnije raditi u jednom standardu.

Samo registrirani korisnici mogu sudjelovati u anketi. Prijavite se, molimo.