🥇Pärandi teenused teie infrastruktuuris

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

Alustame küsimusest: mis on Legacy-teenus? Legacy-teenus on teenus, mida arendaja pole puudutanud nädalat/kuid/ aastat? Või on see teenus, mille kirjutas vähem kogenud programmeerija, näiteks teie ise, kuid aasta tagasi? Ja nüüd olete palju oskuslikum. Või siis Legacy-teenus on see, mille otsustasite enam mitte komiteerida ja järk-järgult valmistate talle asendust? Igatahes, sellise teenuse jätmine järelevalveta ja mitte uuendamine on aeglane pomm, mis võib hiljem plahvatada.

Enne kui liigun edasi selle juurde, kuidas me QIWI-s oma Legacy-teenustega töötame, räägin, kuidas me korrastasime teenuseid Rahakotis. Olen juba kaks aastat vastutanud selle töökindluse eest. Kui tekib mingi probleem, siis helistatakse alati esimesena mulle. Mul tavaliselt ei jätku julgust kell 11 õhtul kellelegi teisele helistada, seega olen pidanud istuma ja uurima meie domeeni kõiki teenuseid.

Aga nagu iga inimene, armastan ma öösel magada, seega püüdsin aru saada, miks mulle helistatakse: "Kutt, miks te mulle helistate?". Mispeale sain üsna lakoonilise vastuse: "Kellele mujale?". Sest ma parandada teenuseid, ja veel ei tea kutid lihtsalt, kellele helistada.

Seega otsustasime ühe Rahakoti tagasivaate koosoleku jooksul, et tuleb koostada tabel, kus on kirjas meie teenuste, mikroteenuste ja monoliitide nimekiri ning nende eest vastutavad isikud. Tabelid on palju kasulikud, mõistlike piiride piires.

Lisaks sellele, kelle eest vastutab, oli seal ka vastused küsimustele: kes on teenuse omanik, kes vastutab selle arengu, arhitektuuri ja elutsükli eest. Teenuse eest vastutavad isikud on need, kes saavad vajadusel teenust parandada. Teenuse omanikul on õigus jätta +2 komiteerimisse, vastutavad peavad samuti kindlasti olema kohal ülevaatusel, enne kui teenus selle uue komiteerimise vastu võtab.

Aeg läks, hakati kasutama uusi praktikaid, nagu näiteks migreerimine Kubernetesesse, erinevad checkstyle, spotbugs, ktlint, logide olemasolu Kibanas, teenuste autodetektsioon otse aadresside määramise asemel ja muid kasulikke funktsioone. Ning igal pool võimaldas meie tabel toetada meie teenuste ajakohasust. Meie jaoks on see teatud kontrollnimekiri, mis näitab, et see teenus oskab seda teha, aga seda ei oska veel. Kuid me läksime edasi, mõistes, et meil on puudu teave meie teenuste kohta, mille üle me jälgime, kus asuvad teenuse lähtekoodid, kus käivitatakse ülesandeid TeamCitys, kuidas need tõstetakse üles, kus hoitakse end2end testide lähtekoodid, arhitektuuri fotod, tehtud otsused. Ideaalis tahaks, et kogu see teave oleks kusagil olemas ja käepärane, kui seda on vaja. Seetõttu sai meie tabel punktiks, kust alustada teabe otsimist.

Kuid QIWI, kuigi säilitab idufirma vaimu, on suur ettevõte. Meil on juba 12 aastat, ja meeskonnad vahetuvad: inimesed lahkuvad, inimesed tulevad, moodustuvad uued meeskonnad. Ja me avastasime oma domeenil mitmeid teenuseid, mis on meile pärandiks jäänud. Midagi tuli arendajatelt teistest meeskondadest, midagi seostus lihtsalt Kottiga kaudselt, seega on see teenus nüüd meie bilansis. Miks vaevata end sellega, mida ja kuidas see töötab? Teenus töötab ju, ja meil on toote omadusi, mida on kindlasti vaja ellu viia.

Nagu ikka juhtub

Kuid mingil hetkel avastame, et teenus enam ei täida oma funktsiooni, midagi on katki — kuidas sellises olukorras käituda? Teenus on lihtsalt lakanud töötamast. Täielikult. Ja me said sellest teada, esiteks, juhuslikult ja teiseks, kuue kuu pärast. Nii juhtub. Ainus, mida me teadisime — millistel virtuaalmasinatel teenus töötab, kus asuvad tema lähtekoodid, ja kõik. Me teeme git clone ja sukeldume selle inimese mõtetesse, kes kirjutab seda paar aastat tagasi, aga mida me näeme? Mitte mingit tuttavat Spring Booti, kuigi oleme kõik selleks harjunud, meil on ju full stack ja kõik see. Võib-olla on seal Spring Framework? Aga ei ole.

Poiss, kes seda kõike kirjutas, oli karm ja kirjutas kõik puhtal Java keeles. Arendajale tuttavaid tööriistu pole ning tekib idee — võiksime selle kõik ümber kirjutada. Meil on ju mikroteenused olemas, ja igast rösterist kostab tuttav "Poisid, mikroteenused on see, mida vajate!". Kui midagi peaks valesti olema, saate rahulikult võtta mis tahes keele ja kõik läheb hästi.

Asi on selles, et meil ei ole praegu tellijat, kes vastutab selle teenuse eest. Millised olid tema ärilised nõudmised, mida see teenus peaks üldse tegema? Ja teenus on tihedalt integreeritud teie äriprotsessidega.

Ja nüüd öelge, kui lihtne on teenust ümber kirjutada, teadmata selle äri nõudeid? Teenuse logimine on segane, kas mõõdikud on olemas — teadmata. Millised need on, kui need on — seda veelgi vähem teame. Ja samal ajal on teenuses tohutult klasside segast äri loogikat. Midagi siseneb mingisse andmebaasi, millest me ka hetkel mitte midagi ei tea.

Kust alustada?

Kõige loogilisemast — testide olemasolust. Seal on tavaliselt kirjutatud vähemalt mingisugune loogika ja saab teha järeldusi selle kohta, mis toimub. Praegu on moes TDD, kuid näeme, et samad 5 aastat tagasi oli kõik peaaegu sama nagu praegu: unit-testide arvu on peaaegu mitte ja need ei ütle meile ju päris midagi. No välja arvatud võib-olla mingisugune kontroll, kuidas allkirjastatakse mingit xml-i mingiga custom sertifikaadiga.

Koodi põhjal ei saanud me midagi aru, ja me pidime vaatama, mis toimub virtuaalkeskkonnas. Avastasime teenuse logides http-klientide vea, milleks oli enesepädev sertifikaat, mis oli rakenduse ressurssidest sisse pandud ja oli juba aegunud. Võtsime ühendust meie analüütikutega, nad palusid uut sertifikaati, see anti meile ja teenus hakkas jälle tööle. Tundus, et sellega on kõik. Või siiski? Teenus töötab, ta täidab teatud funktsiooni, mis on meie äri jaoks vajalik. Meil on olemas teatud rakenduste arendusstandardid, mis on kindlasti ka teil. Näiteks, et logisid ei hoita node'is kaustas, vaid hoitakse kuskil andmehoidlas, näiteks elasticas, ja lähtestame neid Kibanas. Võime meenutada ka kuldseid meetmeid. St teenuse koormus, teenusele esitatud päringute arv, kas ta on elus või mitte, kuidas tal HealthCheck läheb. Igatahes aitavad need mõõdikud teada, millal on ta rahumeelselt käitamisest kõrvale tõsta ja unustada nagu halb unenägu.

Mida teha

Seetõttu lisame sellise vana teenuse tabelisse ja seejärel hakkame otsima vabatahtlikke arendajate hulgast, kes teenusega tegeleksid ja selle korda looksid: kirjutaksid teenuse kohta mingit teavet, lisaksid linke Grafanas olevatele armatuurlaudadele, ehitustöödele, mõistaksid, kuidas rakendust üles seada, ei saa ju kätega FTP kaudu faile lisada.

Peamine on see — kui kaua kogu see kasulik vabatahtlik tegevus aega võtab? Üks sprind enam-vähem kogenud arendajale, näiteks 20%-lise tehnilise võlgade ajal. Ja kui palju aega kulus selleks, et mõista kõiki keerukaid loogikaid suhtlemiseks mingi riikliku süsteemiga ja tuua see uuemate tehnoloogiate juurde? Ma ei saa selle eest käsi anda, võibolla kuu, võibolla kahe meeskonna töö. Räägin oma kogemusest, kui integreeritakse mõni uus teenus.

Samas ei ole äriväärtust. Üldse mitte. Teenuse toetamiseks ja selle peale natuke aega kulutada — see on normaalne. Kuid pärast meie tavalisi tantsu teenuse ümber, lisasime selle tabelisse, lisasime teavet temast ja võib-olla kunagi kirjutame selle uuesti. Kuid praegu vastab see meie teenuste töö standarditele.

Kokkuvõtteks sooviks tuua välja plaani, mida teha Legacy-teenustega.

Legacy süsteemi nullist ümber kirjutamine — halb mõte.
Tõsiselt, selle üle ei saa isegi mõelda. On selge, et soovitakse ja mingid plussid tunduvad, kuid tavaliselt ei ole selleks kellelgi vajadust, sh ka iseendale.

Käsiraamat
Kaevake välja oma rakenduste lähtekoodid, tehke käsiraamat, kus on näidatud, mis ja kus asub ning kuidas see töötab. Kirjake sinna ka projekti kirjeldus (tinglik readme.md), et kiiresti aru saada, kus asuvad logid ja mõõdikud. Arendaja, kes pärast teid sellega tegelema hakkab, tänab teid.

Mõista domeeni
Kui teil on mõni domeen, püüdke hoida käsi pulsil. See kõlab trivina, jah, kuid mitte kõik ei jälgi, et teenused oleksid ühesuguses võtmes. Ühes standardis töötamine on tegelikult oluliselt lihtsam.

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