Podedovane storitve v vaši infrastrukturi

Zdravo! Moje ime je Pasha Chernyak, sem vodilni razvijalec pri QIWI in danes želim govoriti o neizogibnem. O Legacyju.

Začnimo z vprašanjem: kaj je storitev Legacy? Ali je podedovana storitev storitev, ki se je razvijalec ni dotaknil teden/mesec/leto? Ali pa gre za storitev, ki jo je napisal manj izkušen programer, na primer posebej vi, vendar pred enim letom? In zdaj si hladnejši in bolj izkušen. Ali pa je storitev Legacy tista storitev, za katero ste se odločili, da je ne boste nikoli več izvajali in počasi pripravljate zamenjavo zanjo? V vsakem primeru je pustite takšno storitev brez nadzora in ne posodabljajte tempirana bomba, ki lahko pozneje eksplodira.

Preden preidem na to, kako pri QIWI delamo z našimi podedovanimi storitvami, vam bom povedal, kako smo naredili red v storitvah v denarnici. Že dve leti sem odgovoren za njegovo delovanje. Če je kakšna težava, vedno najprej pokličejo mene. Običajno nimam živcev, da bi ob 11. uri klical koga drugega, zato sem se moral usesti in ugotoviti vse storitve na naši domeni.

Ampak jaz, kot vsak človek, rad ponoči spim, zato sem se poskušal spopasti z izkoriščanjem: "Fantje, zakaj me kličete?" Na kar sem prejel precej lakoničen odgovor kot "Kdo drug?" Ker popravljam servise, fantje pa preprosto ne vedo, koga poklicati.

Zato smo se na eni od retrospektiv ekipe Wallet backend odločili, da moramo narediti znak s seznamom naših storitev, mikrostoritev in monolitov denarnic ter odgovornih zanje. Znaki so na splošno uporabni, v razumnih mejah.

Poleg informacij o tem, kdo je za kaj odgovoren, so bili odgovori na vprašanja: kdo je lastnik storitve, kdo je odgovoren za njen razvoj, arhitekturo in življenjski cikel. Ljudje, odgovorni za to storitev, so ljudje, ki lahko to popravijo, če se kaj zgodi. Lastnik servisa ima pravico pustiti +2 v commitih, odgovorni morajo biti prisotni tudi pri pregledu, preden ta servis sprejme nov commit.

Sčasoma so se začele uporabljati nove prakse, na primer selitev na Kubernetes, vse vrste checkstyle, spotbugs, ktlint, prisotnost dnevnikov v Kibani, storitve samodejnega odkrivanja namesto neposrednega določanja naslovov in druge uporabne stvari. In povsod nam je naša miza omogočila ohraniti ustreznost naših storitev. Za nas je to nekakšen kontrolni seznam, ki pravi, da ta storitev to zmore, vendar še ne. Vendar smo šli naprej, saj smo ugotovili, da nam manjka informacij o naših storitvah, katere spremljamo, kje se nahajajo viri storitev, kje se v TeamCityju zaženejo naloge sestavljanja, kako se razmestijo, kje so shranjeni viri testov end2end, fotografije iz sej urejanja o arhitekturi, o sprejetih odločitvah. V idealnem primeru bi rad, da vse te informacije ležijo nekje in so pri roki, ko jih potrebujete. Zato je naš znak postal izhodišče za iskanje informacij.

Toda QIWI, čeprav ohranja duh startupa, je veliko podjetje. Stari smo že 12 let in ekipe se spreminjajo: ljudje odhajajo, prihajajo, nastajajo nove ekipe. Na naši domeni smo odkrili več storitev, ki smo jih podedovali. Nekateri so prišli od razvijalcev iz drugih ekip, nekateri so preprosto nekako posredno povezani z denarnico, tako da imamo zdaj storitev v naši bilanci stanja. Razumevanje, kaj in kako deluje – zakaj? Storitev deluje in imamo funkcije izdelka, ki jih je vsekakor treba izboljšati.

Kako se zgodi

Toda v nekem trenutku ugotovimo, da storitev preneha opravljati svojo funkcijo, nekaj je pokvarjeno - kaj storiti v takšni situaciji? Storitev je preprosto prenehala delovati. Nasploh. In za to smo izvedeli, prvič, po naključju, drugič, šest mesecev kasneje. Zgodi se. Edino, kar smo vedeli, je bilo, na katerih virtualnih strojih bo storitev nameščena, kje so njeni viri in to je vse. Naredimo git klon in se potopimo v misli osebe, ki je to napisala pred nekaj leti, toda kaj vidimo? Nič od Spring Boota, ki nam je poznan, čeprav smo navajeni vsega, imamo poln kup in vse to. Mogoče je tam Spring Framework? Vendar ne.

Tip, ki je vse to napisal, je bil trden in je vse napisal v čisti Javi. Za razvijalca ni običajnih orodij in porodi se ideja: vse to moramo prepisati. Imamo mikrostoritve in iz vsakega opekača kruha prihaja običajno "Fantje, mikrostoritve so tisto, kar potrebujete!" Če gre nenadoma kaj narobe, lahko mirno vzamete kateri koli jezik in vse bo v redu.

Stvar je v tem, da zdaj nimamo stranke, ki bi bila odgovorna za to storitev. Kakšne poslovne zahteve je imel, kaj naj ta služba dela? In storitev je tesno integrirana v vaše poslovne procese.

Zdaj pa mi povejte, kako enostavno je prepisati storitev, ne da bi poznali njene poslovne zahteve? Ni jasno, kako se storitev beleži; ni znano, ali obstajajo meritve. Kaj so, če sploh, je toliko bolj neznanka. In hkrati storitev vsebuje ogromno število razredov nerazumljive poslovne logike. Nekaj ​​je vključeno v nekakšno bazo podatkov, o kateri prav tako še nič ne vemo.

Kje začeti?

Z najbolj logične točke - razpoložljivost testov. Tam je običajno vsaj nekaj logike zapisane in lahko sklepaš o tem, kaj se dogaja. Zdaj je TDD moden, vendar vidimo, da je bilo pred 5 leti vse skoraj enako kot zdaj: testov enot skoraj ni in nam ne bodo povedali ničesar. No, razen morda kakšnega preverjanja, kako je nek xml podpisan z nekim lastnim certifikatom.

Iz kode nismo mogli razumeti ničesar, zato smo šli pogledat, kaj je v virtualnem stroju. Odprli smo servisne dnevnike in v njih našli napako odjemalca http; samopodpisano potrdilo, ki je bilo vdelano v vire aplikacije, je bilo nesramno pokvarjeno. Kontaktirali smo naše analitike, prosili so za nov certifikat, izdali so nam ga in storitev spet deluje. Zdi se, da je to vse. ali ne? Navsezadnje storitev deluje, opravlja neko funkcijo, ki jo potrebuje naše podjetje. Imamo določene standarde za razvoj aplikacij, ki jih najverjetneje imate tudi vi. Na primer, ne shranjujte dnevnikov na vozlišču v mapi, ampak jih shranite v nekakšno shrambo, kot je elastika, in si jih oglejte v Kibani. Lahko se spomnite tudi zlate metrike. Se pravi obremenitev storitve, število zahtevkov za storitev, ali je živ ali ne, kako poteka njegov HealthCheck. Vsaj te meritve vam bodo pomagale vedeti, kdaj ga lahko mirne vesti umaknete iz uporabe in pozabite kot slabe sanje.

Kaj storiti

Zato dodamo tako staro storitev na mizo, nato pa gremo iskat prostovoljce med razvijalci, ki bodo skrbeli za storitev in jo spravili v red: napisali bodo vsaj nekaj informacij o storitvi, dodali povezave do nadzorne plošče v grafani, do nalog sestavljanja in razumeti, kako Razmestite aplikacijo, ne nalagajte datotek ročno prek ftp.

Glavno je, koliko časa bo trajala vsa ta koristna prostovoljska dejavnost? En sprint za bolj ali manj izkušenega razvijalca, na primer med 20-odstotnim tehničnim dolgom. Koliko časa je trajalo, da smo razumeli vso zakoreninjeno logiko komuniciranja z nekim državnim sistemom in jo pripeljali do novejših tehnologij? Ne morem jamčiti za to, morda mesec ali morda dva dela ekipe. To pravim iz izkušenj trenutne integracije z neko novo storitvijo.

Hkrati ni sprostitve poslovne vrednosti. Nasploh. Običajno je, da najamete storitev za podporo in za to porabite malo časa. Toda po naših standardnih plesih s storitvijo smo ga dodali v tabelo, dodali informacije o njem in ga morda kdaj prepisali. Zdaj pa izpolnjuje naše standarde storitev.

Posledično bi rad pripravil načrt, kaj storiti s podedovanimi storitvami.

Ponovno pisanje zapuščine iz nič je slaba ideja
Resno, sploh vam ni treba razmišljati o tem. Jasno je, da bi si ga želel, in nekaj prednosti je, vendar ga običajno nihče ne potrebuje, vključno z vami.

Imenik
Poiščite izvorne kode svojih aplikacij, naredite referenčno knjigo, ki bo navajala, kaj je kje in kako deluje, tja vnesite opis projekta (pogojno readme.md), da boste hitro razumeli, kje se nahajajo dnevniki in metrike. Razvijalec, ki se bo s tem ukvarjal po vas, se bo samo zahvalil.

Razumeti domeno
Če ste lastnik domene, poskušajte držati prst na utripu. Sliši se trivialno, ja, vendar ne poskrbijo vsi, da so storitve v enem ključu. Toda delo v enem standardu je dejansko bistveno lažje.

V anketi lahko sodelujejo samo registrirani uporabniki. Prijaviti se, prosim.

Kaj počnete s svojo zapuščino?

• 31.5%Prepisujem iz nič, pravilneje je 12

• 52.6%Skoraj enako kot ti20

• 10.5%Nimamo dediščine, super smo4

• 5.2%Napisal bom v komentarjih 2

Glasovalo je 38 uporabnikov. 20 uporabnikov se je vzdržalo.

Vir: www.habr.com