🥇Shërbime të trashëguara në infrastrukturën tuaj

Përshëndetje! Emri im është Pasha Chernyak, unë jam një zhvillues kryesor në QIWI dhe sot dua të flas për të pashmangshmen. Rreth Trashëgimisë.

Le të fillojmë me pyetjen: çfarë është shërbimi i trashëguar? A është një shërbim i trashëguar një shërbim që zhvilluesi nuk e ka prekur për një javë/muaj/vit? Apo është një shërbim që është shkruar nga një programues më pak me përvojë, për shembull, nga ju konkretisht, por një vit më parë? Dhe tani ju jeni më të ftohtë dhe më me përvojë. Apo është shërbimi Legacy një shërbim që keni vendosur të mos e kryeni më kurrë dhe po përgatitni ngadalë një zëvendësim për të? Në çdo rast, lënia e një shërbimi të tillë pa mbikëqyrje dhe mospërditësimi është një bombë me sahat që mund të shpërthejë më vonë.

Përpara se të kalojmë në mënyrën se si ne në QIWI punojmë me shërbimet tona të trashëgimisë, unë do t'ju tregoj se si kemi vendosur rregull në shërbimet në Portofol. Prej dy vitesh jam përgjegjës për performancën e tij. Nëse ka ndonjë problem, ata gjithmonë më telefonojnë fillimisht. Zakonisht nuk kam nerva të telefonoj dikë tjetër në orën 11:XNUMX, kështu që më duhej të ulesha dhe të kuptoja të gjitha shërbimet në domenin tonë.

Por mua, si çdo person, më pëlqen të fle natën, kështu që u përpoqa të merrem me shfrytëzimin: "Djema, pse po më telefononi?" Për të cilën mora një përgjigje mjaft lakonike si "Kush tjetër?" Sepse unë rregulloj shërbimet, dhe djemtë thjesht nuk dinë kë të telefonojnë.

Prandaj, në një nga retrospektivat e ekipit të Backend të Portofolit, vendosëm që duhej të bënim një shenjë me një listë të shërbimeve tona, mikroshërbimeve dhe monoliteve të portofolit dhe atyre që janë përgjegjës për to. Shenjat janë përgjithësisht të dobishme, brenda kufijve të arsyeshëm.

Përveç informacionit se kush është përgjegjës për çfarë, ka pasur përgjigje për pyetjet: kush është pronari i shërbimit, kush është përgjegjës për zhvillimin, arkitekturën dhe ciklin e tij jetësor. Personat përgjegjës për këtë shërbim janë njerëzit që mund ta rregullojnë nëse ndodh diçka. Pronari i shërbimit ka të drejtë të lërë +2 në angazhime, përgjegjësit duhet të jenë gjithashtu të pranishëm në rishikim përpara se ky shërbim të pranojë një angazhim të ri.

Me kalimin e kohës, filluan të aplikohen praktika të reja, për shembull, migrimi në Kubernetes, të gjitha llojet e stileve të kontrollit, spotbugs, ktlint, prania e regjistrave në Kibana, shërbimet e zbulimit automatik në vend të specifikimit të drejtpërdrejtë të adresave dhe gjëra të tjera të dobishme. Dhe kudo tabela jonë na lejoi të ruanim rëndësinë e shërbimeve tona. Për ne, kjo është një lloj liste kontrolli që thotë se ky shërbim mund ta bëjë këtë, por nuk e bën ende, por ne vazhduam, duke kuptuar se na mungon informacioni për shërbimet tona, të cilat ne i monitorojmë, ku ndodhen burimet e shërbimit. ku nisen detyrat e montimit në TeamCity, si vendosen ato, ku ruhen burimet e testeve end2end, foto nga seancat e rregullimit në lidhje me arkitekturën, për vendimet e marra. Idealisht, unë do të doja që i gjithë ky informacion të shtrihej diku dhe të ishte pranë kur të jetë e nevojshme. Prandaj, shenja jonë u bë pika fillestare për kërkimin e informacionit.

Por QIWI, megjithëse ruan frymën e një startup, është një kompani e madhe. Ne jemi tashmë 12 vjeç dhe ekipet po ndryshojnë: njerëzit largohen, njerëzit vijnë, formohen ekipe të reja. Dhe ne zbuluam disa shërbime në domenin tonë që trashëguam. Disa erdhën nga zhvillues nga ekipe të tjera, disa thjesht të lidhura disi indirekt me Portofolin, kështu që ne tani e kemi shërbimin në bilancin tonë. Të kuptuarit se çfarë dhe si funksionon - pse? Shërbimi funksionon dhe ne kemi veçori të produktit që patjetër duhet të përmirësohen.

Si ndodh

Por në një moment në kohë zbulojmë se shërbimi ndalon së kryeri funksionin e tij, diçka është prishur - çfarë të bëjmë në një situatë të tillë? Shërbimi thjesht pushoi së punuari. fare. Dhe ne mësuam për këtë, së pari, rastësisht, dhe së dyti, gjashtë muaj më vonë. Ndodh. E vetmja gjë që dinim ishte se në cilat makina virtuale do të vendosej shërbimi, ku ndodheshin burimet e tij dhe kjo është e gjitha. Ne bëjmë një klon git dhe zhytemi në mendjen e personit që e shkroi këtë disa vjet më parë, por çfarë shohim? Asnjë nga çizmet e pranverës që na janë të njohura, megjithëse jemi mësuar me gjithçka, kemi një pirg të plotë dhe gjithçka. Ndoshta ka një Kornizë Pranvere atje? Por jo.

Djali që shkroi të gjitha këto ishte i ashpër dhe shkroi gjithçka në Java të pastër. Nuk ka mjete të zakonshme për një zhvillues dhe lind një ide: ne duhet të rishkruajmë të gjitha këto. Ne kemi mikroshërbime, dhe nga çdo thotë dolli vjen e zakonshme "Djema, mikroshërbimet janë ato që ju nevojiten!" Nëse papritmas diçka shkon keq, ju mund të merrni me qetësi çdo gjuhë dhe gjithçka do të jetë mirë.

Puna është se tani nuk kemi një klient që është përgjegjës për këtë shërbim. Çfarë kërkesash biznesi kishte ai, çfarë duhet të bënte ky shërbim? Dhe shërbimi është i integruar fort në proceset e biznesit tuaj.

Tani më thuaj, sa e lehtë është të rishkruash një shërbim pa i ditur kërkesat e tij të biznesit? Nuk është e qartë se si është regjistruar shërbimi nëse ka metrikë. Çfarë janë ato, nëse ka, është edhe më e panjohur. Dhe në të njëjtën kohë, shërbimi përmban një numër të madh të klasave të logjikës së pakuptueshme të biznesit. Diçka është përfshirë në një lloj bazë të dhënash, për të cilën ne gjithashtu nuk dimë asgjë ende.

Ku të fillojë?

Nga pika më logjike - disponueshmëria e testeve. Zakonisht ka të paktën një logjikë të shkruar atje dhe mund të nxirrni përfundime për atë që po ndodh. Tani TDD është në modë, por ne shohim që 5 vjet më parë gjithçka ishte pothuajse njësoj si tani: nuk ka pothuajse asnjë test njësi dhe ata nuk do të na thonë asgjë fare. Epo, përveç ndoshta një lloj verifikimi, se si disa xml nënshkruhen me ndonjë certifikatë me porosi.

Ne nuk mund të kuptonim asgjë nga kodi, kështu që shkuam të shihnim se çfarë kishte në makinën virtuale. Ne hapëm regjistrat e shërbimit dhe gjetëm një gabim të klientit http në to. Ne kontaktuam me analistët tanë, ata kërkuan një certifikatë të re, na e dhanë dhe shërbimi po funksionon përsëri. Duket se kjo është e gjitha. Ose jo? Në fund të fundit, shërbimi funksionon, ai kryen një funksion që i nevojitet biznesit tonë. Ne kemi disa standarde për zhvillimin e aplikacioneve, të cilat me shumë mundësi i keni edhe ju. Për shembull, mos ruani shkrimet në nyje në një dosje, por ruani ato në një lloj ruajtjeje, si p.sh. elastic, dhe shikoni ato në Kibana. Ju gjithashtu mund të mbani mend matjet e arta. Domethënë, ngarkesa në shërbim, numri i kërkesave për shërbimin, nëse ai është gjallë apo jo, si po shkon HealthCheck-u i tij. Së paku, këto matje do t'ju ndihmojnë të dini se kur mund të hiqet nga shërbimi me një ndërgjegje të pastër dhe të harrohet si një ëndërr e keqe.

Çfarë duhet të bëni

Prandaj, ne shtojmë një shërbim kaq të vjetër në tryezë, dhe më pas ne kërkojmë vullnetarë nga radhët e zhvilluesve që do të kujdesen për shërbimin dhe do ta vendosin atë në rregull: ata do të shkruajnë të paktën disa informacione rreth shërbimit, do të shtojnë lidhje me tabelat e kontrollit në grafana, për detyrat e montimit dhe për të kuptuar se si Vendosni aplikacionin, mos ngarkoni manualisht skedarë duke përdorur ftp.

Gjëja kryesore është se sa kohë do të zgjasë i gjithë ky aktivitet i dobishëm vullnetar? Një sprint për një zhvillues pak a shumë me përvojë, për shembull, gjatë një borxhi teknik prej 20%. Sa kohë u desh për të kuptuar gjithë logjikën e rrënjosur të komunikimit me një sistem të caktuar shtetëror dhe për ta sjellë atë në teknologjitë më të reja? Nuk mund të garantoj për këtë, ndoshta një muaj ose ndoshta dy nga puna e ekipit. E them këtë nga përvoja e integrimit aktual me ndonjë shërbim të ri.

Në të njëjtën kohë, nuk ka asnjë lirim të vlerës së biznesit. fare. Është normale të punësosh një shërbim për mbështetje dhe të shpenzosh pak kohë për të. Por pas vallëzimeve tona standarde me shërbimin, ne e shtuam atë në tryezë, shtuam informacione për të dhe, ndoshta, do ta rishkruajmë një ditë. Por tani ajo plotëson standardet tona të shërbimit.

Si rezultat, unë do të doja të krijoj një plan se çfarë të bëj me shërbimet e Legacy.

Rishkrimi i trashëgimisë nga e para është një ide e keqe
Seriozisht, as nuk duhet të mendoni për këtë. Është e qartë që do ta doja, dhe ka disa avantazhe, por zakonisht askush nuk ka nevojë për të, përfshirë veten.

Libri i referencës
Gjeni kodet burimore të aplikacioneve tuaja, bëni një libër referimi që do të tregojë se ku është dhe si funksionon, futni një përshkrim të projektit atje (e kushtëzuar readme.md) për të kuptuar shpejt se ku ndodhen regjistrat dhe metrikat. Zhvilluesi i cili do të merret me këtë pasi ju do të thotë vetëm faleminderit.

Kuptoni domenin
Nëse zotëroni një domen, përpiquni të mbani gishtin në pulsin. Duket e parëndësishme, po, por jo të gjithë sigurohen që shërbimet janë në një çelës të vetëm. Por puna në një standard është në fakt shumë më e lehtë.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, te lutem