Legacy-teenused teie infrastruktuuris

Tere! Minu nimi on Pasha Chernyak, olen QIWI peaarendaja ja täna tahan rääkida millestki vältimatust. Legacy.

Alustame küsimusega: mis on Legacy-teenus? Kas see on teenus, millega arendaja ei ole viimase nädala/kuu/aasta jooksul kokku puutunud? Või on see teenus, mille kirjutas vähem kogenud programmeerija, näiteks teie, kuid aasta tagasi? Ja nüüd olete te juba osavam ja kogenum. Või on Legacy-teenus hoopis see teenus, mida olete otsustanud enam mitte uuendama ja mille jaoks valmistate tasapisi asendust? Igatahes, sellise teenuse tähelepanuta jätmine ja mitte uuendamine on nagu aeglaselt tikkuv pomm, mis võib hiljem plahvatada.

Enne kui räägin, kuidas me QIWI-s oma Legacy-teenustega töötlust teeme, jagan, kuidas me korda saime teenustele Rahakotis. Olen juba kaks aastat vastutanud selle töökindluse eest. Kui tekib probleem, kutsutakse mind alati esimesena. Mul on tavaliselt puudu julgust helistada kellelegi muule kell 11 õhtul, nii et olen pidanud istuma ja uurima kõiki meie domeeni teenuseid.

Aga mina, nagu iga inimene, armastan öösiti magada, seetõttu püüdsin aru saada, kuidas asjad käivad: «Kutse, miks te mulle helistate?». Millele sain üsna lakoonilise vastuse: «Aga kellele veel?». Sest ma parandasin teenuseid, ja poisid lihtsalt ei tea, kellele helistada.

Seetõttu otsustasime ühel meie Koti tagasiside koosolekul, et peame koostama tabeli, kus on loetletud meie teenused, mikroteenused ja Koti monoliidid ning vastutavad isikud. Tabelid on tegelikult kasulikud, mõistlike piirideni.

Lisaks teabele selle kohta, kes mille eest vastutab, olid seal vastused ka küsimustele: kes on teenuse omanik, kes vastutab selle arendamise, arhitektuuri ja eluiga. Inimesed, kes on selle teenuse eest vastutavad — need on inimesed, kes saavad seda vajaduse korral parandada. Teenuse omanikul on õigus jätta +2 commitidesse, vastutavad peavad samuti kindlasti olema kohal ülevaatusel, enne kui see teenus uue commit'i vastu võtab.

Aeg kulges, uutest praktikadest hakkasid sisse tulema näiteks migratsioon Kubernetesesse, erinevad checkstyle, spotbugs, ktlint, logide olemasolu Kibanas, teenuste autodiscovery asemel otse aadresside määramine ja muud kasulikud asjad. Ja igal pool võimaldas meie tabel hoida meie teenuste aktuaalsust. Meie jaoks on see nagu kontrollnimekiri, mis ütleb, et see teenus oskab seda teha, aga seda veel ei oska. Kuid me liikusime edasi, mõistes, et meil on puudulik teave meie teenuste kohta, mida me jälgime, kus asuvad teenuse lähtekoodid, kus käivitatakse ülesanded ehituses TeamCitys, kuidas neid juurutatakse, kus säilitatakse end2end testide lähtekoodid, fotod arhitektuuriga seonduvatest grooming'utest ja tehtud otsustest. Ideaalis sooviksime, et kogu see teave oleks kuskil olemas ja kergesti käeulatuses, kui seda vajame. Seetõttu sai meie tabelist teabeotsingu lähtekoht.

Kuid QIWI, kuigi säilitab start-up'i vaimu, on suur ettevõte. Meie oleme juba 12 aastat tegutsenud ja meeskonnad vahetuvad: inimesed lahkuvad, inimesed tulevad, moodustuvad uued meeskonnad. Oleme avastanud oma domeenis mitu teenust, mis on meile pärandiks jäänud. Mõned tulid teiste meeskondade arendajatelt, mõned olid lihtsalt kuidagi seotud Koti teenusega, seetõttu on teenus nüüd meie bilansis. Miks uurida, mis ja kuidas töötab? Teenus ju töötab ning meil on toote funktsioonid, mida peab kindlasti väljatöötama.

Nagu ikka

Aga mingil hetkel avastame, et teenus lõpetab oma funktsiooni, midagi on katki — kuidas sellises olukorras käituda? Teenus lihtsalt ei tööta. Üldse. Ja me saime sellest teada, esiteks juhuslikult ja teiseks, poole aasta pärast. Nii juhtub. Ainus, mida me teadsime, oli see, millistel virtuaalmasinatel teenus töötab, kus on selle lähtekood ja kõik. Teeme git clone'i ja sukeldume inimese mõtetesse, kes kirjutas seda paar aastat tagasi, aga mida me näeme? Ühtegi tuttavat Spring Boot'i, kuigi oleme kõigega harjunud, meil on ju full stack ja kõik selline. Võib-olla seal on Spring Framework? Aga ei ole.

Poiss, kes kõike seda kirjutas, oli karm ja kirjutas kõik puhtas Java's. Arendaja tuttavaid tööriistu ei ole ja viskub mõte — peaksime selle kõik ümber kirjutama. Meil on ju mikroteenused ja igaelt röstsaiast kostab tuttav „Poisid, mikroteenused on see, mida te vajate!”. Kui midagi läheb valesti, võite rahulikult võtta mis tahes keele ja kõik läheb suurepäraselt.

Küsimus on selles, et praegu pole meil tellijat, kes vastutab selle teenuse eest. Millised olid tema äri nõuded, mida see teenus peaks üldse tegema? Ja teenus on tihedalt integreeritud teie äri protsessidesse.

Ja nüüd ütlege, kui lihtne oleks teenust ümber kirjutada, teadmata selle äri nõudeid? Teenuse logimine on arusaamatu, kas mõõdikud on olemas — pole teada. Millised need on, kui olemas — veelgi vähem on teada. Ja samas on teenuses tohutu hulk arusaamatut äri loogikat. Midagi siseneb andmebaasi, millest me samuti praegu midagi ei tea.

Kust alustada?

Kõige loogilisemast — testide olemasolust. Seal on tavaliselt kirjas vähemalt mingi loogika ja saab teha järeldusi selle kohta, mis toimub. Praegu on moes TDD, kuid me näeme, et viis aastat tagasi oli kõik peaaegu sama, mis nüüd: üksuste teste on peaaegu mitte ja need ei ütle meile tegelikult midagi. No, välja arvatud ehk mõne kontrolli kohta, kuidas mingi xml millegagi kinnitatud sertifikaadiga allkirjastatakse.

Koodi põhjal ei olnud midagi aru saada, ja me pidime minema vaatama, mis seal virtuaalkeskkonnas toimub. Avastasime teenuse logidest http-klienti puudutava vea, ise allkirjastatud sertifikaadi, mis oli rakenduse ressurssidesse sisse kodeeritud, oli häbi pärast aegunud. Võtsime ühendust meie analüütikutega, nad palusid uut sertifikaati, mis väljastati ja teenus töötab jälle. Tundub, et sellega on kõik. Või siiski? Teenus töötab, täidab mingit funktsiooni, mis on meie äri jaoks vajalik. Meil on teatud rakenduste arendamise standardid, mis tõenäoliselt on ka teil. Näiteks ei tohiks logisid node’is kaustas hoida, vaid mingis ladustamises, nagu näiteks Elasticsearchis, ja vaadata neid Kibana kaudu. Saame meenutada ka kuldsete mõõdikute olemust. See tähendab teenusele avaldatud koormust, teenusele tehtud päringute arvu, kas see on elujõuline, ja kuidas tervisekontrollid läbivad. Igatahes aitavad need mõõdikud teada saada, millal saab selle rahulikult kasutusest välja võtta ja unustada kui halva une.

Mida teha

Seetõttu lisame sellise vana teenuse tabelisse ja seejärel otsime arendajate seast vabatahtlikke, kes teenuse korda teevad: kirjutavad teenuse kohta vähemalt mingid andmed, lisavad lingid Grafana armatuurlaudadele, ehitusülesannetele, selgitavad, kuidas rakendust käivitada, ei ole ju mõtet FTP kaudu faile käsitsi üles laadida.

Oluline on, kui palju aega see kogu kasulik vabatahtlik tegevus võtab? Üks sprind kogenud arendajale, näiteks 20% tehnilise võlaga. Aga kui palju aega kulus kogu sügava loogika mõistmiseks, et suhelda mingi riikliku süsteemiga ja tuua see uuemate tehnoloogiate juurde? Ma ei garanteeri, võib-olla läheb kuu, võib-olla isegi kaks meeskonna tööd. Seda räägin ma praeguse aja integratsiooni kogemuse põhjal mõne uue teenusega.

Kuid äriväärtuse väljund on null. Absoluutselt. Teenuse toetamine ja sellele natuke aega kulutamine on normaalne. Kuid pärast meie tavalisi teenuseprotseduure lisasime selle tabelisse, täiendasime teavet selle kohta ja võib-olla kirjutame kunagi uuesti. Praegu vastab see meie teenuse tööstandarditele.

Kokkuvõtteks tahaksin välja tuua plaani, mida teha pärandteenustega.

Pärandi nullist ümberkirjutamine on halb idee.
Tõsiselt, sellele ei tasu isegi mõelda. On selge, et seda tahaks ja mõned plussid paistavad silma, kuid tavaliselt ei ole see kellelegi vajalik, sealhulgas teile endale.

Käsitegevus
Kaevake välja oma rakenduste lähtekoodid, koostage käsiraamat, milles on kirjas, mis ja kus asub ning kuidas see töötab; sinna kirjutage ka projekti kirjeldus (tingimuslik readme.md), et kiiresti aru saada, kus on logid ja mõõdikud. Arendaja, kes teiega pärast seda tegelema hakkab, ütleb aitäh.

Mõistke domeeni
Kui teil on mõni domeen, siis püüdke hoida end kursis. See kõlab banaalselt, kuid mitte kõik ei jälgi, et teenused oleksid ühte moodi. Olles ühes standardis, on tõepoolest palju lihtsam töötada.

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Mida te teete oma legacy'ga?

• 31.5%Kirjutan nullist ümber, nii on õigesti12

• 52.6%Peaaegu sama, mis teie20

• 10.5%Meil pole legacy't, me oleme tublid4

• 5.2%Kirjutan kommentaaridesse2

Hääletas 38 kasutajat. Olid erapooletud 20 kasutajat.

Allikas: habr.com