Pärandteenused teie infrastruktuuris

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

Alustame küsimusega: mis on pärandteenus? Kas pärandteenus on teenus, mida arendaja pole nädala/kuu/aasta jooksul puudutanud? Või on see teenus, mille kirjutas näiteks vähemkogenud programmeerija teie konkreetselt, aga aasta tagasi? Ja nüüd olete lahedam ja kogenum. Või on pärandteenus teenus, mida olete otsustanud enam mitte kunagi kasutada ja valmistate sellele aeglaselt ette asendust? Igal juhul on sellise teenuse järelevalveta jätmine ja uuendamata jätmine viitsütikuga pomm, mis võib hiljem plahvatada.

Enne kui läheme edasi selle juurde, kuidas me QIWI-s oma pärandteenustega töötame, räägin teile, kuidas me Walletis teenustes korda tegime. Olen selle toimimise eest vastutanud juba kaks aastat. Kui on probleeme, helistatakse mulle alati esimesena. Tavaliselt ei julge ma kell 11 kellelegi teisele helistada, nii et pidin maha istuma ja kõik meie domeeni teenused välja mõtlema.

Kuid mulle, nagu igale inimesele, meeldib öösel magada, nii et ma proovisin ärakasutamisega toime tulla: "Poisid, miks te mulle helistate?" Millele sain üsna lakoonilise vastuse nagu "Kes veel?" Sest ma parandan teenuseid ja poisid lihtsalt ei tea, kellele helistada.

Seetõttu otsustasime ühel Walleti taustatiimi tagasivaatel, et peame koostama sildi oma teenuste, mikroteenuste ja rahakoti monoliitide ning nende eest vastutavate isikute loendiga. Märgid on üldiselt kasulikud, mõistlikes piirides.

Lisaks infole, kes mille eest vastutab, said vastused küsimustele: kes on teenuse omanik, kes vastutab selle arenduse, arhitektuuri ja elutsükli eest. Selle teenuse eest vastutavad inimesed, kes saavad selle parandada, kui midagi juhtub. Teenuse omanikul on õigus jätta kohustustesse +2, samuti peavad vastutajad kohal olema ülevaatuse juures, enne kui see teenus uue kohustuse vastu võtab.

Aja möödudes hakati rakendama uusi praktikaid, näiteks migreerumine Kubernetesesse, kõikvõimalikud kontrollstiilid, spotbugs, ktlint, logide olemasolu Kibanas, automaattuvastusteenused aadresside otsemääramise asemel ja muu kasulik. Ja kõikjal, kus meie laud võimaldas meil säilitada oma teenuste asjakohasust. Meie jaoks on see omamoodi kontrollnimekiri, mis ütleb, et see teenus saab seda teha, kuid veel ei tee. Kuid liikusime edasi, mõistes, et meil puudub teave meie teenuste kohta, mida jälgime, kus teenuste allikad asuvad, kus TeamCitys koosteülesandeid käivitatakse, kuidas neid juurutatakse, kus on salvestatud end2end testide allikad, fotod hooldusseanssidest arhitektuuri ja tehtud otsuste kohta. Ideaalis tahaks, et kogu see info kuskil lebaks ja vajadusel käepärast oleks. Seetõttu sai meie märgist info otsimise lähtepunkt.

Kuid QIWI on suur ettevõte, kuigi see säilitab idufirma vaimu. Oleme juba 12-aastased ja meeskonnad vahetuvad: inimesed lahkuvad, inimesed tulevad, tekivad uued meeskonnad. Ja avastasime oma domeenist mitu teenust, mille me pärisime. Mõned neist tulid teiste meeskondade arendajatelt, mõned olid lihtsalt kuidagi kaudselt Walletiga seotud, nii et teenus on nüüd meie bilansis. Arusaamine, mis ja kuidas see toimib – miks? Teenus töötab ja meil on tooteomadusi, mis vajavad kindlasti täiustamist.

Kuidas see juhtub

Kuid ühel hetkel avastame, et teenus lakkab oma funktsiooni täitmast, midagi on katki – mida sellises olukorras teha? Teenus lihtsalt lakkas töötamast. Üleüldse. Ja me saime sellest teada esiteks juhuslikult ja teiseks kuus kuud hiljem. Juhtub. Ainus asi, mida teadsime, oli see, millistes virtuaalmasinates teenust juurutatakse, kus selle allikad asuvad ja see on kõik. Teeme git-klooni ja sukeldume selle inimese mõtetesse, kes selle paar aastat tagasi kirjutas, aga mida me näeme? Mitte ükski meile tuttav Spring Boot, kuigi oleme kõigega harjunud, meil on stäkk täis ja kõik muu. Võib-olla on seal kevadine raamistik? Kuid mitte.

Mees, kes seda kõike kirjutas, oli kõva ja kirjutas kõik puhtas Java keeles. Arendaja jaoks pole tavapäraseid tööriistu ja tekib mõte: me peame selle kõik ümber kirjutama. Meil on mikroteenused ja igast rösterist tuleb tavaline "Poisid, mikroteenused on see, mida vajate!" Kui äkki midagi viltu läheb, võid rahulikult võtta suvalise keele ja kõik läheb hästi.

Asi on selles, et nüüd pole meil klienti, kes selle teenuse eest vastutaks. Millised ärinõuded tal olid, mida see teenus tegema peaks? Ja teenus on tihedalt integreeritud teie äriprotsessidesse.

Öelge nüüd, kui lihtne on teenust ümber kirjutada, teadmata selle ärinõudeid? Pole selge, kuidas teenust logitakse; kas mõõdikuid on, pole teada. Mis need on, kui üldse, on seda enam teadmata. Ja samal ajal sisaldab teenus tohutul hulgal arusaamatu äriloogika klasse. Mingisse andmebaasi on lisatud midagi, millest me samuti veel midagi ei tea.

Kust alustada?

Kõige loogilisemast punktist - testide kättesaadavus. Seal on tavaliselt vähemalt mingi loogika kirjas ja saab toimuva kohta järeldusi teha. Nüüd on TDD moes, kuid näeme, et 5 aastat tagasi oli kõik peaaegu sama, mis praegu: ühikuteste peaaegu pole ja need ei ütle meile üldse midagi. Noh, välja arvatud võib-olla mingi kontrollimine, kuidas mõni xml on allkirjastatud mõne kohandatud sertifikaadiga.

Me ei saanud koodist midagi aru, seega läksime vaatama, mis virtuaalmasinas on. Avasime teenuselogid ja leidsime neis http-kliendi vea, rakendusressurssidesse põimitud iseallkirjastatud sertifikaat oli häbematult mäda. Võtsime ühendust oma analüütikutega, nad küsisid uut sertifikaati, nad väljastasid selle meile ja teenus töötab taas. Näib, et see on kõik. Või mitte? Teenus ju töötab, täidab mingit funktsiooni, mida meie äri vajab. Meil on rakenduste arendamiseks teatud standardid, mis tõenäoliselt on teil ka. Näiteks ärge salvestage sõlme logisid kausta, vaid salvestage need mingisse salvestusruumi, näiteks elastsesse, ja vaadake neid Kibanas. Samuti võite meeles pidada kuldseid mõõdikuid. See tähendab teenuse koormust, teenuse taotluste arvu, olenemata sellest, kas ta on elus või mitte, kuidas tema HealthCheckil läheb. Need mõõdikud aitavad teil vähemalt aru saada, millal saab selle puhta südametunnistusega teenistusest kõrvaldada ja unustada nagu halb unenägu.

Mida teha

Seetõttu lisame tabelisse sellise vana teenuse ja siis otsime arendajate hulgast vabatahtlikke, kes teenuse eest hoolitsevad ja korda teevad: kirjutavad vähemalt natukene teenuse kohta infot, lisavad lingid grafana armatuurlauad, monteerimisülesannete täitmiseks ja mõistmiseks, kuidas rakendust juurutada, ärge laadige faile ftp abil käsitsi üles.

Peaasi, kui kaua kogu see kasulik vabatahtlik tegevus aega võtab? Üks sprint enam-vähem kogenud arendajale näiteks 20% tehnilise võla ajal. Kui kaua võttis aega teatud riigisüsteemiga suhtlemise kogu juurdunud loogika mõistmine ja selle viimine uuemate tehnoloogiateni? Ma ei saa selle eest garanteerida, võib-olla kuu või kahe meeskonna töö. Ütlen seda mõne uue teenusega integreerimise kogemuse põhjal.

Samal ajal ei vabane ärilisest väärtusest. Üleüldse. Tavaline on palgata tugiteenus ja kulutada sellele veidi aega. Aga peale meie standardtantse koos serviisiga lisasime selle tabelisse, lisasime selle kohta info ja ehk kirjutame kunagi ümber. Kuid nüüd vastab see meie teenindusstandarditele.

Sellest tulenevalt tahaksin välja mõelda plaani, mida Legacy teenustega peale hakata.

Pärandi nullist ümberkirjutamine on halb mõte
Tõsiselt, sa ei pea isegi sellele mõtlema. On selge, et see mulle meeldiks, ja sellel on mõned eelised, kuid tavaliselt pole seda kellelgi vaja, kaasa arvatud teie ise.

Kataloog
Kaevake välja oma rakenduste lähtekoodid, tehke teatmeteos, mis näitab, kus ja kuidas see töötab, sisestage sinna projekti kirjeldus (tingimuslik readme.md), et kiiresti aru saada, kus logid ja mõõdikud asuvad. Arendaja, kes pärast teie tegemist sellega tegeleb, ütleb ainult aitäh.

Mõistke domeeni
Kui teil on domeen, proovige hoida kätt pulsil. See kõlab jah triviaalselt, kuid mitte kõik ei taga, et teenused oleksid ühes võtmes. Kuid ühes standardis töötamine on tegelikult oluliselt lihtsam.

Küsitluses saavad osaleda ainult registreerunud kasutajad. Logi sissepalun.

Mida sa oma pärandiga teed?

• 31.5%Ma kirjutan nullist ümber, see on õigem 12

• 52.6%Peaaegu sama, mis sina 20

• 10.5%Meil pole pärandit, oleme suurepärased4

• 5.2%Kirjutan kommentaaridesse 2

38 kasutajat hääletas. 20 kasutajat jäi erapooletuks.

Allikas: www.habr.com