Zdravo! Moje ime je Pasha Chernyak, vodeći sam programer u QIWI-ju i danas želim razgovarati o neizbježnom. O nasljeđu.
Počnimo s pitanjem: što je Legacy usluga? Je li naslijeđena usluga usluga koju razvojni programer nije dotaknuo tjedan/mjesec/godinu? Ili je to usluga koju je napisao manje iskusan programer, na primjer, vi posebno, ali prije godinu dana? A sad si hladniji i iskusniji. Ili je Legacy usluga usluga za koju ste odlučili da je više nikada nećete koristiti i polako pripremate zamjenu za nju? U svakom slučaju, ostavljanje takve usluge bez nadzora i neažuriranje je tempirana bomba koja bi kasnije mogla eksplodirati.
Prije nego što prijeđem na to kako mi u QIWI radimo s našim naslijeđenim uslugama, reći ću vam kako smo uveli red u usluge u novčaniku. Već dvije godine sam odgovoran za njegovu izvedbu. Ako ima problema, uvijek me prvo zovu. Inače nemam živaca zvati nekog drugog u 11 sata, pa sam morao sjesti i skužiti sve usluge na našoj domeni.
Ali ja, kao i svaka osoba, volim spavati noću, pa sam se pokušao nositi s iskorištavanjem: "Ljudi, zašto me zovete?" Na što sam dobio prilično lakonski odgovor poput "Tko drugi?" Jer ja popravljam servise, a dečki jednostavno ne znaju koga da zovu.
Stoga smo na jednoj od retrospektiva Wallet backend tima odlučili da moramo napraviti znak s popisom naših usluga, mikroservisa i wallet monolita te onih koji su za njih odgovorni. Znakovi su općenito korisni, u razumnim granicama.
Osim informacija o tome tko je za što odgovoran, bilo je i odgovora na pitanja: tko je vlasnik servisa, tko je odgovoran za njegov razvoj, arhitekturu i životni ciklus. Ljudi odgovorni za ovu uslugu su ljudi koji to mogu popraviti ako se nešto dogodi. Vlasnik servisa ima pravo ostaviti +2 u commitima, odgovorni također moraju biti prisutni na pregledu prije nego ovaj servis prihvati novi commit.
Kako je vrijeme prolazilo, počele su se primjenjivati nove prakse, na primjer, migracija na Kubernetes, sve vrste checkstyle-a, spotbugovi, ktlint, prisutnost logova u Kibani, usluge automatskog otkrivanja umjesto izravnog navođenja adresa i druge korisne stvari. I posvuda nam je naš stol omogućio da zadržimo relevantnost naših usluga. Za nas je ovo neka vrsta kontrolne liste koja kaže da ovaj servis to može, ali još ne. No, krenuli smo dalje, shvativši da nam nedostaju informacije o našim uslugama, koje pratimo, gdje se nalaze izvori usluga, gdje se pokreću zadaci sklapanja u TeamCityju, kako se raspoređuju, gdje se pohranjuju izvori end2end testova, fotografije sa sesija dotjerivanja o arhitekturi, o donesenim odlukama. U idealnom slučaju, volio bih da sve ove informacije leže negdje i da budu pri ruci kada zatrebaju. Stoga je naš znak postao polazište za traženje informacija.
Ali QIWI, iako zadržava duh startupa, velika je tvrtka. Imamo već 12 godina, a timovi se mijenjaju: ljudi odlaze, ljudi dolaze, stvaraju se novi timovi. I otkrili smo nekoliko usluga na našoj domeni koje smo naslijedili. Neki su došli od programera iz drugih timova, neki su jednostavno nekako neizravno povezani s novčanikom, tako da sada imamo uslugu u svojoj bilanci. Razumijevanje što i kako radi - zašto? Usluga radi i imamo značajke proizvoda koje svakako treba poboljšati.
Kako se događa
Ali u nekom trenutku otkrivamo da usluga prestaje obavljati svoju funkciju, nešto je pokvareno - što učiniti u takvoj situaciji? Usluga je jednostavno prestala raditi. Uopće. A za to smo saznali, prvo, slučajno, a drugo, šest mjeseci kasnije. Događa se. Jedino što smo znali je na kojim će se virtualnim strojevima usluga postaviti, gdje se nalaze njeni izvori i to je sve. Napravimo git klon i zaronimo u um osobe koja je ovo napisala prije nekoliko godina, ali što vidimo? Ništa od Spring Boota koji nam je poznat, iako smo navikli na sve, imamo punu hrpu i sve to. Možda tamo postoji Spring Framework? Ali ne.
Tip koji je sve ovo napisao bio je čvrst i sve je napisao čistom Javom. Ne postoje uobičajeni alati za programera i javlja se ideja: moramo sve ovo ponovno napisati. Imamo mikroservise, a iz svakog tostera dolazi uobičajeno "Dečki, mikroservisi su ono što vam treba!" Ako iznenada nešto pođe po zlu, možete mirno uzeti bilo koji jezik i sve će biti u redu.
Stvar je u tome što sada nemamo kupca koji je odgovoran za ovu uslugu. Kakve je poslovne zahtjeve imao, što bi ta služba trebala raditi? A usluga je usko integrirana u vaše poslovne procese.
Sada mi recite koliko je lako prepisati uslugu bez poznavanja njenih poslovnih zahtjeva? Nije jasno kako se usluga bilježi; nije poznato postoje li metrike. Što su, ako ih ima, tim je više nepoznato. A u isto vrijeme usluga sadrži ogroman broj klasa nerazumljive poslovne logike. Nešto je uključeno u nekakvu bazu podataka, o kojoj također još ništa ne znamo.
Što treba započeti?
S najlogičnije točke - dostupnost testova. Tu obično piše barem neka logika i možete izvući zaključke o tome što se događa. Sada je TDD moderan, ali vidimo da je prije 5 godina sve bilo gotovo isto kao sada: gotovo da nema jediničnih testova i oni nam neće reći ništa. Pa, osim možda neke vrste provjere, kako je neki xml potpisan nekim prilagođenim certifikatom.
Nismo mogli razumjeti ništa iz koda, pa smo otišli vidjeti što je u virtualnom stroju. Otvorili smo servisne zapisnike i u njima pronašli pogrešku http klijenta; samopotpisani certifikat koji je bio ugrađen u resurse aplikacije bio je besramno pokvaren. Kontaktirali smo naše analitičare, tražili su novi certifikat, izdali su nam ga i servis ponovno radi. Čini se da je to sve. Ili ne? Uostalom, usluga radi, obavlja neku funkciju koja je potrebna našem poslu. Imamo određene standarde za razvoj aplikacija, koje vjerojatno imate i vi. Na primjer, ne spremajte zapisnike na čvoru u mapu, već ih spremite u neku vrstu pohrane, npr. elastičnu, i gledajte ih u Kibani. Također se možete sjetiti zlatne metrike. Odnosno, opterećenje usluge, broj zahtjeva za uslugu, je li živ ili ne, kako mu ide HealthCheck. U najmanju ruku, ove će vam metrike pomoći da znate kada se može mirne savjesti isključiti iz upotrebe i zaboraviti kao loš san.
Što učiniti
Stoga takvu staru uslugu dodamo na tablicu, a zatim idemo tražiti volontere među programerima koji će se pobrinuti za uslugu i dovesti je u red: napisat će barem neke informacije o usluzi, dodati poveznice na nadzorne ploče u grafani, na zadatke sastavljanja i razumjeti kako implementirati aplikaciju, nemojte ručno učitavati datoteke pomoću ftp-a.
Glavno je koliko će trajati sva ova korisna volonterska aktivnost? Jedan sprint za više ili manje iskusnog programera, na primjer, tijekom 20% tehničkog duga. Koliko je vremena trebalo da se shvati sva ukorijenjena logika komunikacije s određenim državnim sustavom i dovede je do novijih tehnologija? Ne mogu jamčiti za ovo, možda mjesec ili možda dva rada tima. Ovo govorim iz iskustva trenutne integracije s nekom novom uslugom.
U isto vrijeme nema oslobađanja poslovne vrijednosti. Uopće. Normalno je unajmiti servis za podršku i potrošiti malo vremena na to. Ali nakon naših standardnih plesova s uslugom, dodali smo ga u tablicu, dodali informacije o njemu i možda ćemo ga jednog dana ponovno napisati. Ali sada zadovoljava naše standarde usluge.
Kao rezultat toga, želio bih osmisliti plan što učiniti s naslijeđenim uslugama.
Ponovno pisanje ostavštine ispočetka je loša ideja
Ozbiljno, ne morate ni razmišljati o tome. Jasno je da bih to volio, ima i prednosti, ali obično nikome ne treba, pa ni tebi.
Referentna knjiga
Iskopajte izvorne kodove svojih aplikacija, napravite referentnu knjigu koja će pokazati što je gdje i kako radi, unesite tamo opis projekta (uvjetno readme.md) da brzo shvatite gdje se nalaze zapisnici i metrika. Programer koji će se time pozabaviti nakon vas će samo reći hvala.
Razumjeti domenu
Ako ste vlasnik domene, pokušajte držati prst na pulsu. Zvuči trivijalno, da, ali ne brinu svi da usluge budu u jednom ključu. Ali rad u jednom standardu zapravo je znatno lakši.
U anketi mogu sudjelovati samo registrirani korisnici. , molim.
Što radite sa svojom ostavštinom?
31.5%Prepisujem ispočetka, ispravnije je 12
52.6%Skoro isto kao ti20
10.5%Nemamo nasljeđe, super smo4
5.2%Napisat ću u komentarima 2
Glasovalo je 38 korisnika. Suzdržano je bilo 20 korisnika.
Izvor: www.habr.com
