TĂ« gjithĂ« flasin pĂ«r proceset e zhvillimit dhe testimit, trajnimin e stafit, rritjen e motivimit, por kĂ«to procese janĂ« tĂ« pakta kur njĂ« minutĂ« ndalesĂ« e shĂ«rbimit kushton njĂ« shumĂ« marramendĂ«se. ĂfarĂ« tĂ« bĂ«ni kur bĂ«ni transaksione financiare nĂ«n njĂ« SLA tĂ« rreptĂ«? Si tĂ« rrisni besueshmĂ«rinĂ« dhe qĂ«ndrueshmĂ«rinĂ« e sistemeve tuaja, duke lĂ«nĂ« pas zhvillimin dhe testimin?
Konferenca e ardhshme HighLoad++ do të mbahet më 6 dhe 7 prill 2020 në Shën Petersburg. Detajet dhe biletat në . 9 nëntor, 18:00. HighLoad++ Moskë 2018, salla "Deli + Kalkuta". Tekstet dhe .
Evgeny Kuzovlev (mĂ« tutje â EK): â Miq, pĂ«rshĂ«ndetje! Quhem Kuzovlev Evgeny. UnĂ« vija nga kompania EcommPay, konkretisht nga njĂ«sia â EcommPay IT, njĂ«sia IT e grupit tĂ« kompanive. Dhe sot do tĂ« flasim pĂ«r ndalesat â pĂ«r si tâi shmangim ato, pĂ«r si tâi minimizojmĂ« pasojat e tyre, nĂ«se nuk arrijmĂ« tâi shmangim. Tematika e shpallur Ă«shtĂ«: "ĂfarĂ« tĂ« bĂ«jmĂ« kur njĂ« minutĂ« ndalesĂ« kushton 100,000 dollarĂ«"? Sipas parashikimeve tona, shifrat janĂ« tĂ« ngjashme.
ĂfarĂ« bĂ«n EcommPay IT?
Kush jemi ne? Pse jam këtu para jush? Pse kam të drejta të flas më këtë? Dhe për çfarë do të flasim këtu më në detaje?
Grupi i kompanive EcommPay Ă«shtĂ« njĂ« ekvayer ndĂ«rkombĂ«tar. Ne procesojmĂ« pagesa anembanĂ« botĂ«s â nĂ« Rusi, EuropĂ«, nĂ« Juglindjen e AzisĂ« (All Around the World). Ne kemi 9 zyra, 500 punonjĂ«s nĂ« total dhe rreth pak mĂ« pak se gjysma e tyre janĂ« specialistĂ« IT. Ădo gjĂ« qĂ« bĂ«jmĂ«, çdo gjĂ« nga e cila fituam para, e bĂ«mĂ« vetĂ«.
Ne kemi zhvilluar vetĂ« tĂ« gjitha produktet tona (dhe kemi mjaft â nĂ« linjĂ«n tonĂ« tĂ« produkteve tĂ« mĂ«dha IT, kemi rreth 16 komponentĂ« tĂ« ndryshĂ«m); ne i shkruajmĂ« vetĂ«, ne i zhvillojmĂ« vetĂ«. Dhe aktualisht, ne procesojmĂ« rreth njĂ« milion transaksione nĂ« ditĂ« (miliona, ndoshta kjo do tĂ« ishte e saktĂ« tĂ« themi). Kemi qenĂ« njĂ« kompani e re pĂ«r sa i pĂ«rket, rreth gjashtĂ« vjet.
6 vjet më parë ishte një fillim i tillë, kur erdhën disa djem bashkë me biznesin. Ata ishin të bashkuar nga ideja (nuk kishte asgjë tjetër, përveç ideve), dhe ne filluam. Ashtu si çdo start-up, ne vraponim më shpejt⊠Për ne ishte më e rëndësishme shpejtësia, jo cilësia.
Në një moment të caktuar ne u ndalëm: kuptuam se nuk mund të jetonim me atë shpejtësi dhe cilësi dhe duhej të fokusohemi në cilësinë para së gjithash. Në këtë moment morëm vendimin të shkruajmë një platformë të re, e cila do të ishte e duhur, e shkallëzueshme dhe e besueshme. Kjo platformë filloi të zhvillohej (filluam investimet, zhvillimin, testimin), por në një moment kuptuam se zhvillimi dhe testimi nuk lejojnë daljen në një nivel të ri cilësie të shërbimit.
Ju po krijoni njĂ« produkt tĂ« ri, e ekspozoni atĂ« nĂ« prodhim, por prapĂ« diçka do tĂ« shkojĂ« keq diku. Dhe sot ne do tĂ« flasim pĂ«r mĂ«nyrat se si tĂ« arrijmĂ« njĂ« nivel tĂ« ri cilĂ«sor (si kemi arritur kĂ«tĂ«, pĂ«rvojĂ«n tonĂ«), duke lĂ«nĂ« jashtĂ« zhvillimin dhe testimin; do tĂ« flasim pĂ«r atĂ« qĂ« Ă«shtĂ« e disponueshme pĂ«r operimin â çfarĂ« mund tĂ« bĂ«jĂ« operimi vetĂ«, çfarĂ« mund tĂ« ofrojĂ« pĂ«r testimin pĂ«r tĂ« ndikuar nĂ« cilĂ«si.
Koha e papunësisë. Porositë e operimit.
GjithmonĂ« guri kryesor mbi tĂ« cilin do tĂ« flasim sot â koha e papunĂ«sisĂ«. NjĂ« fjalĂ« e tmerrshme. NĂ«se na ndodh koha e papunĂ«sisĂ« â gjithçka shkon keq. Ne nxitojmĂ« ta ngremĂ«, administratorĂ«t mbajnĂ« serverin â shpresojmĂ« qĂ« tĂ« mos bjerĂ«, siç kĂ«ndohet nĂ« atĂ« kĂ«ngĂ«. KĂ«shtu qĂ« do tĂ« flasim pĂ«r kĂ«tĂ« sot.
Kur filluam të ndryshonim qasjet tona, ne formuam 4 porosi. Ato janë paraqitur në prezantime:
Këto porosi janë mjaft të thjeshta:
- TĂ« identifikosh shpejt problemin.
- Të eleminosh atë edhe më shpejt.
- Të ndihmosh në kuptimin e shkakut (pastaj, për zhvilluesit).
- Dhe të standardizosh qasjet.
Do të vë theksin në pikën nr. 2. Ne eliminojmë problemin, jo e zgjidhim atë. Zgjidhja është dytësore. Për ne, e paraqitshme është që përdoruesi është i mbrojtur nga ky problem. Ai do të ekzistojë në një ambient të caktuar të izoluar, por ky ambient nuk do të kontaktojë në asnjë mënyrë me të. Në fakt, do të kalojmë përmes këtyre katër grupeve të problemeve (disa më në detaje, disa më pak), do t'ju tregoj se çfarë përdorim, cila është përvoja jonë përkatëse në zgjidhje.
Eliminimi i problemeve: kur ndodhin dhe çfarë duhet të bëjmë me to?
Por tĂ« fillojmĂ«, nuk do tĂ« shkojmĂ« sipas rendit, do tĂ« fillojmĂ« me pikĂ«n nr. 2 â si tĂ« shpejtojmĂ« zgjidhjen e problemeve? Ka njĂ« problem â na nevojitet ta zgjidhim atĂ«. "ĂfarĂ« duhet tĂ« bĂ«jmĂ« me kĂ«tĂ«?" â Ă«shtĂ« pyetja kryesore. NĂ« momentin qĂ« filluam tĂ« mendonim se si tĂ« zgjidhim problemin, pĂ«rpunuam disa kĂ«rkesa qĂ« zgjidhja e problemeve duhet tĂ« ndjekĂ«.
Për të formulua këto kërkesa, vendosëm të bëjmë një pyetje: "Kur na ndodhin problemet?" Dhe problemet, siç rezultoi, shfaqen në katër raste:
- Defekt i harduerit.
- Dështimi i shërbimeve të jashtme.
- Ndryshimi i versionit të softuerit (ai deploy-i që e përmendëm).
- Rritje eksplozive e ngarkesës.
PĂ«r dy tĂ« parat nuk do tĂ« flasim. Defekti i harduerit zgjidhet mjaft lehtĂ«: ju duhet tĂ« keni gjithçka tĂ« dyfishuar. NĂ«se janĂ« disqet â disqet duhet tĂ« jenĂ« tĂ« organizuara nĂ« RAID, nĂ«se Ă«shtĂ« serveri â serveri duhet tĂ« jetĂ« i dyfishuar, nĂ«se keni infrastrukturĂ« rrjetit â duhet tĂ« vendosni njĂ« kopje tĂ« dytĂ« tĂ« infrastrukturĂ«s rrjetike, dmth merrni dhe e dyfishoni. Dhe nĂ«se diçka dĂ«shtojnĂ«, kaloni nĂ« burimet rezervĂ«. KĂ«tu Ă«shtĂ« e vĂ«shtirĂ« tĂ« themi diçka mĂ« shumĂ«.
E dyta â Ă«shtĂ« dĂ«shtimi i shĂ«rbimeve tĂ« jashtme. PĂ«r shumicĂ«n e sistemit, kjo nuk Ă«shtĂ« vĂ«rtet njĂ« problem, por jo pĂ«r ne. Duke qenĂ« se ne pĂ«rpunojmĂ« pagesa, ne jemi njĂ« agregator i cili qĂ«ndron mes pĂ«rdoruesit (i cili fut tĂ« dhĂ«nat e tij tĂ« kartĂ«s) dhe bankave, sistemeve tĂ« pagesave ("Visa", "MasterCard", "Mira" etj.). ShĂ«rbimeve tona tĂ« jashtme (sistemet e pagesĂ«s, bankat) u ndodhin dĂ«shtime. Ne dhe ju (nĂ«se keni kĂ«to shĂ«rbime) nuk mund tĂ« ndikoni nĂ« kĂ«tĂ«.
ĂfarĂ« tĂ« bĂ«jmĂ« atĂ«herĂ«? KĂ«tu ka dy mundĂ«si. E para, nĂ«se mundeni, duhet ta dyfishoni kĂ«tĂ« shĂ«rbim nĂ« ndonjĂ« mĂ«nyrĂ«. PĂ«r shembull, ne, nĂ«se mundemi, e drejtojmĂ« trafikun nga njĂ« shĂ«rbim nĂ« njĂ« tjetĂ«r: pĂ«rpunojmĂ«, pĂ«r shembull, kartat pĂ«rmes "Sberbank", nĂ«se "Sberbank" ka probleme â e çojmĂ« trafikun [duke thĂ«nĂ«] te "Raiffeisen". E dyta, qĂ« mund tĂ« bĂ«jmĂ« â Ă«shtĂ« tĂ« vĂ«rejmĂ« shumĂ« shpejt dĂ«shtimin e shĂ«rbimeve tĂ« jashtme, dhe prandaj do tĂ« flasim pĂ«r shpejtĂ«sinĂ« e reagimit nĂ« pjesĂ«n tjetĂ«r tĂ« raportit.
NĂ« thelb, nga kĂ«to katĂ«r, ne mund tĂ« ndikojmĂ« nĂ« ndĂ«rrimin e versioneve tĂ« softuerit - tĂ« bĂ«jmĂ« veprime qĂ« do tĂ« çonin nĂ« pĂ«rmirĂ«simin e situatĂ«s nĂ« kontekstin e shpĂ«rndarjeve dhe rritjes eksplozive tĂ« ngarkesĂ«s. NĂ« fakt, ne e bĂ«mĂ« kĂ«tĂ«. KĂ«tu, pĂ«rsĂ«ri, njĂ« vĂ«rejtje e vogĂ«lâŠ
Nga këto katër probleme, disa zgjidhen menjëherë nëse keni një cloud. Nëse jeni në cloud-t e 'Microsoft Azure', 'Ozon', duke përdorur cloud-et tona nga 'Yandex' ose 'Mail', atëherë së paku çështja e defekteve të pajisjeve bëhet probleme e tyre dhe ju menjëherë ndiheni mirë në kontekstin e defekteve të pajisjeve.
Ne jemi një kompani pak të pazakontë. Të gjithë këtu flasin për 'Kubernetes', për cloud-et - ne nuk kemi 'Kubernetes' as cloud. Por kemi raftet me pajisje në shumë qendra të të dhënave, dhe mbi këtë pajisje ne jemi të detyruar të jetojmë, jemi të detyruar të marrim përsipër gjithçka. Kështu që në këtë kontekst do të flasim. Pra, për problemet. Dy të parat i kemi lënë jashtë.
Ndërrimi i versionit të softuerit. Bazat
Ne kemi zhvillues që nuk kanë akses në prodhim. Pse është kështu? Sepse ne jemi të certifikuar sipas PCI DSS dhe zhvilluesit tanë thjesht nuk kanë të drejtë të hyjnë në 'prod'. Mjafton. Pikë. Prandaj, përgjegjësia e zhvillimit përfundon në momentin që zhvillimi transferon build-in për lirimin.
Baza jonë e dytë, që gjithashtu na ndihmon shumë - janë mungesat e njohurive unike të pa dokumentuara. Shpresoj që edhe ju të keni po ashtu. Sepse, nëse nuk është kështu - do t'ju dalin probleme. Problemet shfaqen kur këto njohuri unike të pa dokumentuara nuk janë të pranishme në kohën e duhur në vendin e duhur. Le të themi se një person di si të shpërndajë një komponent konkret - personi nuk është, është në pushim ose i sëmurë - atëherë, keni probleme.
Dhe baza e tretë, në të cilën arritëm. Ne arritëm në të përmes dhimbjes, gjakut, lotëve - ne arritëm në atë që çdo build i ynë përmban gabime, edhe nëse është pa gabime. Ne vendosëm për veten tonë: kur shpërndajmë diçka, kur nxjerrim diçka në prodhim - build-i ynë ka gabime. Kemi formuluar kërkesat që sistemi ynë duhet të përmbushë.
Kërkesat për ndërrimin e versionit të softuerit
Këto kërkesa janë tre:
- Duhet të jemi në gjendje të rikthejmë shpërndarjen shpejt.
- Duhet të minimizojmë ndikimin e një shpërndarje të dështuar.
- Dhe nevojitet të jemi në gjendje të deploy-ojmë shpejt në mënyrë paralele.
NĂ« kĂ«tĂ« rend! Pse? Sepse, nĂ« radhĂ« tĂ« parĂ«, gjatĂ« deploy-it tĂ« njĂ« versioni tĂ« ri, shpejtĂ«sia nuk Ă«shtĂ« e rĂ«ndĂ«sishme, por Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r ju tĂ« riktheni shpejt dhe tĂ« keni ndikim minimal, nĂ«se diçka shkon keq. Por nĂ«se keni njĂ« grup versionesh nĂ« prodhim, qĂ« rezulton se ka njĂ« gabim (nĂ« mĂ«nyrĂ« tĂ« papritur, nuk ka pasur deploy, por gabimi Ă«shtĂ« aty) â ju dua shpejtĂ«sinĂ« e deploy-it tĂ« mĂ«vonshĂ«m. ĂfarĂ« bĂ«mĂ« pĂ«r tĂ« pĂ«rmbushur kĂ«to kĂ«rkesa? Ne pĂ«rdorĂ«m njĂ« metodologji tĂ« tillĂ«:
Ajo Ă«shtĂ« mjaft e njohur, nuk kemi shpikur asgjĂ« tĂ« re â Ă«shtĂ« Blue/Green deploy. ĂfarĂ« Ă«shtĂ« kjo? PĂ«r secilĂ«n grup serverash, ku janĂ« aplikacionet tuaja, duhet tĂ« ketĂ« njĂ« kopje. NjĂ« kopje 'tĂ« ngrohtĂ«': nuk ka trafik mbi tĂ«, por nĂ« çdo moment ky trafik mund tĂ« dĂ«rgohet aty. Kjo kopje pĂ«rmban versionin e mĂ«parshĂ«m. Dhe nĂ« momentin e deploy-it, ju nxirrni kodin nĂ« njĂ« kopje joaktive. Pastaj, kaloni njĂ« pjesĂ« tĂ« trafikut (ose tĂ« gjithĂ«) nĂ« versionin e ri. KĂ«shtu, pĂ«r tĂ« ndryshuar rrjedhĂ«n e trafikut nga versioni i vjetĂ«r nĂ« tĂ« riun, ju nevojitet tĂ« bĂ«ni vetĂ«m njĂ« veprim: duhet tĂ« ndryshoni balancuesin nĂ« upstream, tĂ« ndryshoni drejtimin â nga njĂ« upstream nĂ« tjetĂ«r. Kjo Ă«shtĂ« shumĂ« e pĂ«rshtatshme dhe zgjidh problemin e kalimit tĂ« shpejtĂ« dhe rikthimit tĂ« shpejtĂ«.KĂ«tu Ă«shtĂ« zgjidhja e pyetjes sĂ« dytĂ« â minimizimi: mund tĂ« dĂ«rgoni vetĂ«m njĂ« pjesĂ« tĂ« trafikut tuaj nĂ« linjĂ«n e re, nĂ« linjĂ«n me kodin e ri (pĂ«r shembull, 2%). Dhe kĂ«to 2% â nuk janĂ« 100%! NĂ«se humbni 100% tĂ« trafikut gjatĂ« njĂ« deployi tĂ« dĂ«shtuar â kjo Ă«shtĂ« e tmerrshme, nĂ«se humbni 2% tĂ« trafikut â kjo Ă«shtĂ« e pakĂ«ndshme, por nuk Ă«shtĂ« e tmerrshme. MĂ« shumĂ«, pĂ«rdoruesit ndoshta as nuk do ta vĂ«rejnĂ«, sepse nĂ« disa raste (jo nĂ« tĂ« gjitha) po ai pĂ«rdorues, duke shtypur F5, ai do tĂ« kalojĂ« nĂ« njĂ« version tjetĂ«r, qĂ« funksionon.
Blue/Green deploy. Rrjedhja
Por, nuk është gjithçka kaq e thjeshtë 'Blue/Green deploy'... Të gjithë komponentët tanë mund të ndahen në tre grupe:
- kjo është frontend (faqet e pagesave, që i shohin klientët tanë);
- në bërthamë të procesimit;
- adapteri pĂ«r tĂ« punuar me sistemet e pagesave (bankat, 'MasterCard', 'Visa'âŠ).
Dhe kĂ«tu ka njĂ« nuancĂ« â nuanca Ă«shtĂ« nĂ« routing midis linjave. NĂ«se po ndĂ«rroni thjesht 100% tĂ« trafikut, nuk keni kĂ«to probleme. Por nĂ«se dĂ«shironi tĂ« ndĂ«rroni 2%, filloni tĂ« keni pyetje: "Si ta bĂ«j kĂ«tĂ«?" MĂ« e thjeshta, hapur: mund tĂ« konfiguroni njĂ« ndarje tĂ« rastĂ«sishme, Round Robin nĂ« nginx, dhe do keni 2% â nĂ« tĂ« majtĂ«, 98% â nĂ« tĂ« djathtĂ«. Por kjo nuk Ă«shtĂ« gjithmonĂ« e pĂ«rshtatshme.
NĂ« rastin tonĂ«, pĂ«r shembull, pĂ«rdoruesi ndĂ«rvepron me sistemin jo me njĂ« kĂ«rkesĂ«. Kjo Ă«shtĂ« normale: 2, 3, 4, 5 kĂ«rkesa â sistemet tuaja mund tĂ« jenĂ« njĂ«soj. Dhe nĂ«se Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r ju qĂ« tĂ« gjitha kĂ«rkesat e pĂ«rdoruesit tĂ« shkojnĂ« nĂ« tĂ« njĂ«jtĂ«n linjĂ«, nĂ« tĂ« cilĂ«n ka ardhur kĂ«rkesa e parĂ«, ose (nĂ« momentin e dytĂ«) tĂ« gjitha kĂ«rkesat e pĂ«rdoruesit tĂ« shkojnĂ« nĂ« njĂ« linjĂ« tĂ« re pas ndĂ«rrimit (ai mund tĂ« kishte filluar tĂ« punojĂ« mĂ« herĂ«t me sistemin, para ndĂ«rrimit), â atĂ«herĂ« kjo ndarje e rastĂ«sishme nuk ju pĂ«rshtatet. KĂ«shtu, ka disa mundĂ«si:
MundĂ«sia e parĂ«, mĂ« e thjeshtĂ« â nĂ« bazĂ« tĂ« parametrave bazĂ« tĂ« klientit (IP Hash). Keni njĂ« IP dhe e ndani sipas IP-sĂ« nĂ« tĂ« djathtĂ« e tĂ« majtĂ«. KĂ«tu do tĂ« aplikohet rasti i dytĂ« i pĂ«rshkruar prej meje, kur ndodhi deploy, pĂ«rdoruesi mund tĂ« kishte filluar tĂ« punojĂ« me sistemin tuaj, dhe nga momenti i deploy-it, tĂ« gjitha kĂ«rkesat do tĂ« shkojnĂ« nĂ« linjĂ«n e re (nĂ« tĂ« njĂ«jtĂ«n, pĂ«r shembull).NĂ«se pĂ«r ndonjĂ« arsye kjo nuk ju pĂ«rshtatet dhe ju duhet patjetĂ«r tĂ« dĂ«rgoni kĂ«rkesat nĂ« atĂ« linjĂ«, nĂ« tĂ« cilĂ«n erdhi kĂ«rkesa fillestare, atĂ«herĂ« keni dy mundĂ«si...
MundĂ«sia e parĂ«: mund tĂ« merrni njĂ« nginx+ tĂ« paguar. Atje ka njĂ« mekanizĂ«m tĂ« sesioneve Sticky, i cili nĂ« kĂ«rkesĂ«n fillestare tĂ« pĂ«rdoruesit vendos njĂ« sesion pĂ«r pĂ«rdoruesin dhe e lidh atĂ« me njĂ« upstream tĂ« caktuar. TĂ« gjitha kĂ«rkesat e mĂ«tejshme tĂ« pĂ«rdoruesit brenda jetĂ«s sĂ« sesionit do tĂ« dĂ«rgohen nĂ« tĂ« njĂ«jtin upstream, nĂ« tĂ« cilin ishte vendosur sesioni.Kjo nuk na pĂ«rshtati, sepse ne kishim tashmĂ« njĂ« nginx tĂ« zakonshĂ«m. Kalimi nĂ« nginx+ â nuk Ă«shtĂ« se Ă«shtĂ« shumĂ« i shtrenjtĂ«, por ishte disi e dhimbshme pĂ«r ne dhe jo shumĂ« e drejtĂ«. "Sticky sessions" pĂ«r ne, pĂ«r shembull, nuk funksionuan pĂ«r shkakun e thjeshtĂ« se "Sticky sessions" nuk japin mundĂ«sinĂ« pĂ«r tĂ« bĂ«rĂ« routing sipas kriterit "Ose-ose". Atje mund tĂ« pĂ«rcaktoni se po bĂ«jmĂ« "Sticky sessions", pĂ«r shembull, sipas IP-sĂ« ose sipas IP-sĂ« dhe cookies ose sipas post-parametrave, por "Ose-ose" â atje Ă«shtĂ« mĂ« e komplikuar.
Prandaj arritĂ«m nĂ« opsionin e katĂ«rt. Ne morĂ«m nginx nĂ« "steroide" (kjo Ă«shtĂ« openresty) â Ă«shtĂ« sikur tĂ« ishte nginx, por me mbĂ«shtetje tĂ« shtuar pĂ«r pĂ«rfshirjen e skripteve last. Mund tĂ« shkruani njĂ« skript last, t'ia jepni kĂ«tij "opernest", dhe ky skript last do tĂ« ekzekutohet kur tĂ« vijĂ« njĂ« kĂ«rkesĂ« nga pĂ«rdoruesi.
Dhe ne shkruam, në thelb, një skript të tillë, vendosëm "opernest" dhe në këtë skript përzgjidhim 6 parametra të ndryshëm përmes konkatenimit "ose". Në varësi të pranisë së njërit apo tjetrit, ne e dimë se përdoruesi ka ardhur në një faqe ose në një tjetër, në një linjë ose në një tjetër.
Blue/Green deploy. Avantazhet dhe disavantazhet
Sigurisht, ndoshta ishte e mundur ta bënim pak më të thjeshtë (të përdornim të njëjtat "Sticky sessions"), por kemi edhe një nuancë të tillë, që ne jo vetëm që ndërveprojmë me përdoruesin brenda një procesi të vetëm transaksioni⊠Por po ashtu ndodhin ndërveprime edhe nga sistemi të pagesave: ne, pasi procesojmë transaksionin (duke dërguar një kërkesë në sistemin e pagesave), marrim një callback.
Dhe supozoni se, brenda konturit tonë, ne mund të kalojmë IP-në e përdoruesit në të gjitha kërkesat dhe bazuar në IP-në e përdoruesve të ndajmë, atëherë nuk do t'i themi "Viza": "O çunat, jemi një kompani retro, duket sikur jemi ndërkombëtare (në faqe dhe në Russinë)⊠A mund të na kaloni, ju lutem, IP-në e përdoruesit në një fushë shtesë, protokolli juaj i standardizuar"! E kuptoni, ata nuk do të bien dakord.
Prandaj, pĂ«r ne kjo nuk funksionoi â ne bĂ«mĂ« openresty. PĂ«r pasojĂ«, me routingun na doli kĂ«shtu:"Blue/Green deploy" ka, pĂ«rkatĂ«sisht, avantazhe, tĂ« cilat pĂ«rmenda, dhe disavantazhe.
Ka dy disavantazhe:
- duhet të merret me routingun;
- disavantazhi i dytë kryesor është shpenzimet.
Ju nevojitet dyfish serverësh, ju nevojiten dyfish burime operative, ju nevojitet të shpenzoni dyfish forcë për të mbështetur gjithë këtë kafaz.
Në të vërtetë, mes avantazheve - ka edhe një gjë tjetër, për të cilën nuk kam përmendur më parë: ju keni një rezervë në rast se rritet ngarkesa. Nëse keni një rritje të madhe ngarkese, dhe një numër i madh përdoruesish ju bombardojnë, ju thjesht aktivizoni linjën e dytë në shpërndarje 50 me 50 - dhe menjëherë keni dyfish servera në klasterin tuaj, derisa të zgjidhni problemin e numrit të serverave më shumë.
Si të bëni një implementim të shpejtë?
Kemi folur se si të zgjidhim problemin e minimizimit dhe kthimit të shpejtë, por pyetja mbetet: "Si të implementohemi shpejt"?
Këtu është shkurtimisht dhe gjithçka është e thjeshtë.- Duhet të keni një sistem CD (Dërgesa e Vazhdueshme) - pa të nuk ka tjetër. Nëse keni një server, mund të implementoni manualisht. Ne kemi rreth një mijë e pesëqind servera dhe me dorë një mijë e pesëqind, është e qartë - mund të formojmë një departament me madhësinë e kësaj salle, vetëm për të implementuar.
- Implementimi duhet të jetë paralel. Nëse implementimi juaj është sekondar, atëherë gjithçka është keq. Një server - është në rregull, një mijë e pesëqind servera do t'i implementoni gjithë ditën.
- Përsëri, për të përshpejtuar, kjo ndoshta nuk është e nevojshme. Gjatë implementimit zakonisht bëhet ndërtimi i projektit. Nëse keni një projekt web, ka pjesën e frontit (në të cilën bëni paketimin web, mbledh-ni npm - diçka e tillë), dhe ky proces në parim nuk zgjat shumë - rreth 5 minuta, por këto 5 minuta mund të jenë kritike. Kështu që, për shembull, ne nuk e bëjmë kështu: ne i kemi hequr këto 5 minuta, ne implementojmë artefaktet.
ĂfarĂ« Ă«shtĂ« njĂ« artefakt? Artefakti Ă«shtĂ« njĂ« ndĂ«rtim i mbledhur, nĂ« tĂ« cilin Ă«shtĂ« bĂ«rĂ« e gjithĂ« pjesa e ndĂ«rtimit. Ky artefakt e ruajmĂ« nĂ« njĂ« depo artefaktesh. Ne nĂ« njĂ« kohĂ« kemi pĂ«rdorur dy tĂ« tillĂ« - ishte Nexus dhe tani jFrog Artifactory. 'Nexusi' ne e kemi pĂ«rdorur fillimisht sepse filluam ta praktikojmĂ« kĂ«tĂ« qasje nĂ« aplikacionet java (ai ishte shumĂ« i pĂ«rshtatshĂ«m pĂ«r kĂ«tĂ«). MĂ« pas aty vendosĂ«m njĂ« pjesĂ« aplikacionesh tĂ« shkruara nĂ« PHP; dhe 'Nexusi' nuk ishte mĂ« i pĂ«rshtatshĂ«m, dhe pĂ«r kĂ«tĂ« arsye zgjodhĂ«m jFrog Artifactory, i cili mund tĂ« bĂ«jĂ« artefaktin e pothuajse çdo gjĂ«je. ArritĂ«m madje nĂ« atĂ« pikĂ«, qĂ« nĂ« kĂ«tĂ« depo artefaktesh ruajmĂ« paketat tona binare qĂ« ne i krijojmĂ« pĂ«r serverat.
Rritje eksplozive e ngarkesës
Folëm për ndërrimin e versionit të softuerit. E mira e ardhshme që kemi - është rritja eksplozive e ngarkesës. Këtu ndoshta e kuptoj rritjen eksplozive të ngarkesës në një mënyrë jo krejt të saktë...
Ne kemi shkruar njĂ« sistem tĂ« ri â Ă«shtĂ« me shĂ«rbime, modern dhe i bukur, plot me punĂ«torĂ«, radhĂ« dhe asinkronizim. NĂ« sisteme tĂ« tilla, tĂ« dhĂ«nat mund tĂ« lĂ«vizin pĂ«rmes rrugĂ«ve tĂ« ndryshme. PĂ«r transaksionin e parĂ« mund tĂ« pĂ«rfshihen punĂ«tori 1, 3, 10, pĂ«r transaksionin e dytĂ« â punĂ«tori 2, 4, 5. Dhe sot, le tĂ« themi, nĂ« mĂ«ngjes keni njĂ« rrjedhĂ« tĂ« dhĂ«nash qĂ« angazhon tre punĂ«torĂ«t e parĂ«, ndĂ«rsa nĂ« mbrĂ«mje ndryshohet papritur dhe gjithçka angazhon tre punĂ«torĂ«t e tjerĂ«.
Prandaj, ndodh që ju duhet ta shkalloni punëtorët, duhet të shkalloni shërbimet tuaja, por në të njëjtën kohë të mos lejoni që burimet të inflatohen.
Ne kemi pĂ«rcaktuar kĂ«rkesat tona. KĂ«to kĂ«rkesa janĂ« mjaft tĂ« thjeshta: tĂ« ketĂ« zbulim shĂ«rbimesh, parametrizim â gjithçka Ă«shtĂ« standard pĂ«r ndĂ«rtimin e sistemeve tĂ« tilla tĂ« shkallueshme, pĂ«rveç njĂ« pike â amortizimi i burimeve. Ne thamĂ« se nuk jemi tĂ« gatshĂ«m tĂ« amortizojmĂ« burimet, qĂ« serverĂ«t tĂ« ngrohin ajrin. Ne morĂ«m "Consul", morĂ«m "Nomad", i cili menaxhon punĂ«torĂ«t tanĂ«.Pse Ă«shtĂ« kjo njĂ« problem pĂ«r ne? Le tĂ« kthehemi pak prapa. Tani pas nesh janĂ« rreth 70 sisteme pagesash. NĂ« mĂ«ngjes, trafiku kalon pĂ«r "Sberbank", pastaj "Sberbank" ra, pĂ«r shembull, dhe ne e çojmĂ« atĂ« nĂ« njĂ« sistem pagese tjetĂ«r. Ne kishim 100 punĂ«torĂ« deri nĂ« "Sberbank", dhe pas kĂ«saj na duhet tĂ« ngremĂ« menjĂ«herĂ« 100 punĂ«torĂ« pĂ«r sistemin tjetĂ«r tĂ« pagesĂ«s. Dhe kjo gjithçka Ă«shtĂ« e dĂ«shirueshme tĂ« ndodhĂ« pa ndĂ«rhyrje njerĂ«zore. Sepse, nĂ«se ka ndĂ«rhyrje njerĂ«zore â njĂ« inxhinier duhet tĂ« jetĂ« 24/7 aty, i cili do tĂ« merret vetĂ«m me kĂ«tĂ«, sepse njĂ«kohĂ«sisht ndodhin shpesh probleme kur 70 sisteme janĂ« prapa jush.
Prandaj, ne e shqyrtuam "Nomad", i cili ka njĂ« IP tĂ« hapur dhe krijuam njĂ« gjĂ« tonĂ«n Scale-Nomad â ScaleNo, e cila bĂ«n pĂ«rafĂ«rsisht kĂ«tĂ«: monitoron rritjen e radhĂ«s dhe zvogĂ«lohet ose rritet numri i punĂ«torĂ«ve nĂ« varĂ«si tĂ« dinamikĂ«s sĂ« ndryshimit tĂ« radhĂ«s. Kur e bĂ«mĂ«, menduam: "Mos ndoshta ta hapim me kod tĂ« hapur?" MĂ« pas e shqyrtuam atĂ« â ishte e thjeshtĂ« si dy qindarka.
Ende nuk e kemi hapur me kod tĂ« hapur, por nĂ«se ndonjĂ«herĂ« pas prezantimit, pas kuptimit se ju nevojitet njĂ« gjĂ« e tillĂ«, ndjeni nevojĂ«n pĂ«r tĂ«, nĂ« slajdin e fundit ka kontaktet e mia â mĂ« shkruani, ju lutem. NĂ«se mblidhen tĂ« paktĂ«n 3-5 persona â ne do ta hapim atĂ« me kod tĂ« hapur.
Si eÌŁshte e mundur kjo? Le tĂ« shohim! Pa e tepruar: nĂ« anĂ«n e majtĂ« ka njĂ« pjesĂ« tĂ« monitorimit tonĂ«: kjo Ă«shtĂ« njĂ« linjĂ«, lart â koha e pĂ«rpunimit tĂ« ngjarjeve, nĂ« mes â numri i transaksioneve, poshtĂ« â numri i punĂ«torĂ«ve.NĂ«se shikojmĂ«, nĂ« kĂ«tĂ« imazh ka njĂ« defekt. NĂ« grafikĂ«n e sipĂ«rme, njĂ« nga grafikat doli jashtĂ« pĂ«r 45 sekonda â njĂ« nga sistemet e pagesave ra. MenjĂ«herĂ« u paraqit trafiku pĂ«r 2 minuta dhe filloi rritja e radhĂ«s nĂ« njĂ« tjetĂ«r sistem pagesash, ku nuk kishte punĂ«torĂ« (ne nuk i shfrytĂ«zuam burimet â pĂ«rkundrazi, shfrytĂ«zuam burimin nĂ« mĂ«nyrĂ« korrekte). Nuk donim tĂ« nxehemi â kishte njĂ« numĂ«r minimal, rreth 5-10 punĂ«torĂ«, por ata nuk po e pĂ«rballonin.
NĂ« grafikĂ«n e fundit Ă«shtĂ« e dukshme njĂ« âdeformimâ, i cili tregon se âSkalenâ e ngriti kĂ«tĂ« numĂ«r dyfish. Dhe pastaj, kur grafiku paksa ra, ai paksa e reduktoi â numri i punĂ«torĂ«ve u ndryshua nĂ« mĂ«nyrĂ« automatike. KĂ«shtu funksionon kjo gjĂ«. Diskutuam pĂ«r pikĂ«n nr. 2 â âSi tĂ« heqim shpejt shkaktarĂ«tâ.
Monitorimi. Si të zbulojmë shpejt një problem?
Tani pika e parĂ« â âSi tĂ« zbulojmĂ« shpejt njĂ« problem?â Monitorimi! Ne duhet tĂ« kuptojmĂ« shpejt disa gjĂ«ra. ĂfarĂ« gjĂ«rash duhet tĂ« kuptojmĂ« shpejt?
Tri gjëra!- Ne duhet të kuptojmë shpejt dhe të kuptojmë funksionalitetin e burimeve tona.
- Ne duhet të kuptojmë shpejt daljen nga funksioni, të monitorojmë performancën e sistemeve që për ne janë të jashtme.
- Pika e tretĂ« â identifikimi i gabimeve logjike. Kjo ndodh kur sistemi punon pĂ«r ju, sipas tĂ« gjitha treguesve gjithçka Ă«shtĂ« normale, por ndodh diçka qĂ« nuk shkon.
KĂ«tu ndoshta, nuk do tĂ« tregoj ndonjĂ« gjĂ« shumĂ« tĂ« veçantĂ«. Do tĂ« jem kapiteni i QartĂ«sisĂ«. Ne po kĂ«rkojmĂ« se çfarĂ« ka nĂ« treg. Kemi krijuar njĂ« âzoo tĂ« gĂ«zuarâ. KĂ«shtu Ă«shtĂ« krijuar zooja jonĂ« tani:
Ne pĂ«rdorim âZabbixâ pĂ«r monitorimin e âhardueritâ, pĂ«r monitorimin e treguesve kryesorĂ« tĂ« serverĂ«ve. âOkmeterâ e pĂ«rdorim pĂ«r bazat e tĂ« dhĂ«nave. âGrafanaâ dhe âPrometheusâ i pĂ«rdorim pĂ«r tĂ« gjitha treguesit tjerĂ« qĂ« nuk u pĂ«rshtaten dy tĂ« parĂ«ve, disa â me âGrafanĂ«nâ dhe âPrometheusinâ, disa â âGrafanaâ me âInfluxâ dhe Telegraf.NjĂ« vit mĂ« parĂ« dĂ«shironim tĂ« pĂ«rdornim New Relic. NjĂ« mjet i shkĂ«lqyer, bĂ«n gjithçka. Por sa mĂ« shumĂ« bĂ«n, aq i shtrenjtĂ« Ă«shtĂ«. Kur u rritĂ«m nĂ« 1,5 mijĂ« servera, u paraqit njĂ« shitĂ«s dhe tha: "Le tĂ« nĂ«nshkruajmĂ« njĂ« marrĂ«veshje pĂ«r vitin e ardhshĂ«m." Ne e shikuam çmimin dhe thamĂ«: jo, nuk do ta bĂ«jmĂ« kĂ«tĂ«. Tani po e braktisim "New Relic", na kanĂ« mbetur rreth 15 serverĂ« nĂ«n monitorimin e "New Relic". Ămimi doli tĂ« ishte krejtĂ«sisht i çmendur.
Dhe ka njĂ« mjet qĂ« e kemi realizuar vetĂ« â Ă«shtĂ« Debugger. Fillimisht e quajtĂ«m "Bagger", por pastaj kaloi mĂ«suesi ynĂ« i anglishtes, dhe u qesh shumĂ«, kĂ«shtu qĂ« e ndĂ«rrova nĂ« "Debugger". ĂfarĂ« Ă«shtĂ«? Ky Ă«shtĂ« njĂ« instrument qĂ« nĂ« pĂ«rfundim, brenda 15-30 sekondave nĂ« çdo komponent, si njĂ« "kutia e zezĂ«" e sistemit, Đ·Đ°ĐżŃŃĐșĐ° ŃĐ”ŃŃŃ ĐœĐ° ĐŸĐ±ŃŃŃ ŃĐ°Đ±ĐŸŃĐŸŃĐżĐŸŃĐŸĐ±ĐœĐŸŃŃŃ ĐșĐŸĐŒĐżĐŸĐœĐ”ĐœŃĐ°.
PĂ«r shembull, nĂ«se kemi njĂ« faqe tĂ« jashtme (faqe pagese) â thjesht e hap dhe shikon se si duhet tĂ« duket. NĂ«se Ă«shtĂ« njĂ« procesim, lĂ«shon njĂ« test "tranzak" â sheh qĂ« kjo "tranzak" tĂ« arrijĂ«. NĂ«se kemi lidhje me sistemet e pagesave â pĂ«rkatĂ«sisht lĂ«shojmĂ« njĂ« kĂ«rkesĂ« testuese, ku mundemi, dhe shikojmĂ« qĂ« gjithçka Ă«shtĂ« nĂ« rregull.
Cilat janë treguesit e rëndësishëm për monitorim?
ĂfarĂ« monitorojmĂ« kryesisht? Cilat janĂ« treguesit e rĂ«ndĂ«sishĂ«m pĂ«r ne?
- Koha e pĂ«rgjigjes / RPS nĂ« frontet â njĂ« tregues shumĂ« i rĂ«ndĂ«sishĂ«m. Ai pĂ«rgjigjet menjĂ«herĂ« qĂ« diçka nuk Ă«shtĂ« nĂ« rregull.
- Numri i mesazheve të përpunuara në të gjitha radhët.
- Numri i punëtorëve.
- Treguesit kryesorë të saktësisë.
Pika e fundit â njĂ« tregues "biznesi". NĂ«se dĂ«shiron tĂ« monitorosh tĂ« njĂ«jtat gjĂ«ra, duhet tĂ« pĂ«rcaktosh njĂ« ose dy tregues qĂ« janĂ« treguesit e tu kryesorĂ«. Treguesi ynĂ« Ă«shtĂ« pĂ«rçueshmĂ«ria (raporti i numrit tĂ« transaksioneve tĂ« suksesshme me rrjedhĂ«n e pĂ«rgjithshme tĂ« transaksioneve). NĂ«se ndodhin ndryshime nĂ« intervalin 5-10-15 minuta â atĂ«herĂ« kemi probleme (nĂ«se ndryshon ndjeshĂ«m).
Si duket kjo te ne â njĂ« shembull i njĂ« prej bordeve tona:
NĂ« anĂ«n e majtĂ« â 6 grafikĂ«, kĂ«shtu qĂ« pĂ«r linjat â numri i punonjĂ«sve dhe numri i mesazheve nĂ« radhĂ«. NĂ« anĂ«n e djathtĂ« â RPS, RTS. PoshtĂ« â ajo metrikĂ« e "biznesit". Dhe nĂ« metrikĂ«n "biznesore" ne menjĂ«herĂ« shohim se diçka ka shkuar keq nĂ« dy grafiket e mesme... Kjo Ă«shtĂ« pikĂ«risht kur ra njĂ« sistem tjetĂ«r, i cili na mbĂ«shtet.E dyta, ajo qĂ« na duheshin tĂ« bĂ«nim â ishte tĂ« vçfangnerem pĂ«r rĂ«nien e sistemeve tĂ« pagesave tĂ« jashtme. KĂ«tu morĂ«m OpenTracing â mekanizmi, standardi, paradigma qĂ« lejon tĂ« ndjekĂ«sh sistemet e shpĂ«rndara; dhe e ndryshuam pak. Paradigma standarde e OpenTracing thotĂ« se ne ndĂ«rtojmĂ« ndjekjen e çdo kĂ«rkese tĂ« veçantĂ«. Na nevojitej ndryshe, kĂ«shtu qĂ« e kthyen atĂ« nĂ« njĂ« ndjekje totale, agreguese. Krijuam njĂ« mjet qĂ« na lejon tĂ« ndjekim shpejtĂ«sinĂ« e sistemeve qĂ« qĂ«ndrojnĂ« pas nesh.
Grafiku na tregon se njĂ« nga sistemet e pagesave filloi tĂ« pĂ«rgjigjet pas 3 sekondash â patĂ«m probleme. NdĂ«rkohĂ«, kjo gjĂ« do tĂ« reagojĂ« kur problemet filluan, nĂ« njĂ« interval tĂ« 20-30 sekondave.Dhe klasa e tretĂ« e gabimeve tĂ« monitorimit, qĂ« ekziston â Ă«shtĂ« monitorimi logjik.
Sinqerisht, nuk dija se çfarë të vizatoja në këtë slajd, sepse kërkuam për një kohë të gjatë në treg për atë që do të na përshtatej. Nuk gjetëm asgjë, kështu që na duhej ta bënim vetë.
ĂfarĂ« nĂ«nkuptoj me monitorimin logjik? Imagjinoni se: krijoni njĂ« sistem pĂ«r veten (pĂ«r shembull, njĂ« klon tĂ« "Tinderit"); e keni bĂ«rĂ«, e keni nisur. Menaxheri i suksesshĂ«m Vasja Pupkin e ka instaluar atĂ« nĂ« telefonin e tij, sheh njĂ« vajzĂ«, e pĂ«lqen... dhe pĂ«lqimi nuk shkon tek vajza â pĂ«lqimi shkon te roje Mikhaliç nga e njĂ«jta qendĂ«r biznesi. Menaxheri zbret poshtĂ«, pastaj çuditet: "Pse ky roje Mikhaliç po mĂ« buzĂ«qesh kaq ndjeshĂ«m?"NĂ« situata tĂ« tilla⊠PĂ«r ne, kjo situatĂ« tingĂ«llon pak ndryshe, sepse (kam shkruar) Ă«shtĂ« njĂ« humbje reputacioni qĂ« nĂ« mĂ«nyrĂ« tĂ« tĂ«rthortĂ« çon nĂ« humbje financiare. Ne kemi situatĂ«n e kundĂ«rt: ne mund tĂ« pĂ«sojmĂ« humbje financiare direkte â pĂ«r shembull, nĂ«se e kemi kryer njĂ« transaksion si tĂ« suksesshĂ«m, kur nĂ« tĂ« vĂ«rtetĂ« ka qenĂ« dĂ«shtak (apo anasjelltas). RrĂ«fimi pĂ«r tĂ« krijuar njĂ« mjet tĂ« vetin qĂ« ndjek, sipas treguesve tĂ« biznesit, numrin e transaksioneve tĂ« suksesshme nĂ« dinamikĂ« brenda njĂ« intervali kohor. Nuk gjetĂ«m asgjĂ« nĂ« treg! Kjo ishte pikĂ« e cila doja tĂ« pĂ«rcillja. PĂ«r zgjidhjen e kĂ«tij lloji problemesh, nĂ« treg nuk ka asgjĂ«.
Kjo ishte në lidhje me pyetjen se si të identifikojmë shpejt një problem.
Si të përcaktojmë arsyet e deploy-it
Grupi i tretĂ« i problemeve qĂ« ne zgjidhim Ă«shtĂ« â pasi e kemi identifikuar problemin, dhe pasi e kemi eliminuar atĂ«, do tĂ« ishte mirĂ« tĂ« kuptonim shkakun pĂ«r zhvillimin, pĂ«r testimin dhe tĂ« bĂ«nim diçka me tĂ«. Prandaj, na nevojitet tĂ« hulumtojmĂ«, na duhen log-et.
NĂ«se flasim pĂ«r log-et (arsyja kryesore â log-et), pjesa mĂ« e madhe e log-eve Ă«shtĂ« nĂ« ELK Stack â pothuajse tĂ« gjithĂ« e kanĂ« kĂ«shtu. Disa, ndoshta, jo nĂ« ELK, por nĂ«se shkruani log-e nĂ« gigabit, me kohĂ« do tĂ« arrini nĂ« ELK. Ne i shkruajmĂ« ato nĂ« terabite.
KĂ«tu ka njĂ« problem. Ne e kemi rregulluar, e kemi korrigjuar gabimin pĂ«r pĂ«rdoruesin, filluam tĂ« zbulojmĂ« çfarĂ« ndodhi, shkuam nĂ« 'Kibana', futĂ«m atje id-nĂ« e transaksionit dhe morĂ«m njĂ« tĂ« tillĂ« pĂ«rmbledhje (shfaq shumĂ«). Dhe nĂ« kĂ«tĂ« pĂ«rmbledhje nuk kuptohet asgjĂ«. Pse? Sepse nuk Ă«shtĂ« e qartĂ« se cila pjesĂ« i pĂ«rket cilit punĂ«tor, cila pjesĂ« i pĂ«rket cilit komponent. Dhe nĂ« kĂ«tĂ« moment kuptuam qĂ« na nevojitej ndjekja â ajo OpenTracing qĂ« pĂ«rmenda.E menduam kĂ«tĂ« njĂ« vit mĂ« parĂ«, shikuan nĂ« drejtimin e tregut dhe aty u gjetĂ«n dy mjete â 'Zipkin' dhe 'Jaeger'. 'Jaeger' Ă«shtĂ« nĂ« fakt njĂ« trashĂ«gimtar ideologjik, njĂ« vazhdues ideologjik i 'Zipkin'. NĂ« 'Zipkin' gjithçka Ă«shtĂ« mirĂ«, pĂ«rveç faktit se ai nuk di tĂ« agregojĂ«, nuk di tĂ« pĂ«rfshijĂ« log-et nĂ« ndjekje, vetĂ«m ndjekjen e kohĂ«s. 'Jaeger' e mbĂ«shteti kĂ«tĂ«.
Përdorëm "Eger"-in: mund të instrumentojmë aplikacione, mund të shkruajmë në Api (standardi Api për PHP në atë kohë, megjithatë, nuk ishte miratuar - kjo ishte një vit më parë, dhe tani është miratuar), nuk kishte asnjë klient. "Mirë", menduam dhe shkruam vetë një klient. Si është dukur kjo? Kështu duket:
Në "Eger" për çdo mesazh krijohen span'e. Kështu, kur përdoruesi hap sistemin, ai sheh një ose dy blloqe për çdo kërkesë të ardhur (1-2-3 - sa më shumë kërkesa nga përdoruesi, aq më shumë blloqe). Për ta bërë më të lehtë për përdoruesit, kemi shtuar etiketat në log dhe mbikëqyrjen e përkohshme. Në përputhje me këtë, në rast gabimi, aplikacioni ynë do të markojë logun me etiketën përkatëse "Error". Mund të filtrohet sipas etiketës "Error" dhe do të shfaqen vetëm span'ët që përmbajnë këtë bllok me gabim. Kështu duket nëse e zgjerojmë spanin:
Brenda spanit ka një grup tregimesh. Në këtë rast, janë tre tregime testuese, dhe tregimi i tretë na tregon se ka ndodhur një gabim. Në këtë rast, gjithashtu shohim mbikëqyrjen përkohore: në krye kemi një horizont temporal dhe shohim se në cilin interval temporal është regjistruar logu ynë.Prandaj, na doli mjaft mirë. Kemi shkruajtur një zgjerim të vetin dhe e kemi open-source. Nëse dëshironi të punoni me mbikëqyrjen, nëse dëshironi të punoni me "Eger" në gjuhën PHP - ekziston zgjerimi ynë, mirë se vini ta përdorni, siç është thënë:
Ky zgjerim është një klient për të punuar me OpenTracing Api, bërë si php-extention, që do të thotë se do t'ju duhet ta ndërtoni dhe ta vendosni në sistem. Një vit më parë nuk kishte asgjë tjetër. Tani kanë dalë edhe klientë të tjerë, që janë si komponentë. Këtu është çështja juaj: ose ngarkoni komponentët me composer, ose përdorni zgjerimin, sipas dëshires tuaj.Standarde korporative
Diskutuam pĂ«r tri urtĂ«si. UrtĂ«sia e katĂ«rt â Ă«shtĂ« standardizimi i qasjeve. ĂfarĂ« Ă«shtĂ« kjo? ĂshtĂ« paksa kĂ«shtu:
Pse Ă«shtĂ« kĂ«tu fjala "korporative"? Jo sepse ne jemi njĂ« kompani e madhe ose burokratike, jo! Fjala "korporative" e pĂ«rdor nĂ« kontekstin qĂ« çdo kompani, çdo produkt duhet tĂ« ketĂ« standardet e veta, dhe ashtu Ă«shtĂ« edhe pĂ«r ju. Cilat janĂ« standardet qĂ« kemi ne?- Ne kemi njĂ« rregullore pĂ«r deploy-t. Pa tĂ« nuk lĂ«vizim asnjĂ«herĂ«, nuk mundemi. Ne deploy-ojmĂ« rreth 60 herĂ« nĂ« javĂ«, pra nĂ« fakt, deploy-t ndodhin vazhdimisht. NĂ« kĂ«tĂ« rregullore pĂ«r deploy-t, pĂ«r shembull, kemi njĂ« tabu pĂ«r deploy-t tĂ« premteve â nĂ« parim, nuk deploy-ojmĂ«.
- Dokumentacioni është i detyrueshëm për ne. Asnjë komponent i ri nuk kalon në prodhim nëse nuk ka dokumentacion, edhe nëse është krijuar nga ekipet tona RnD. Ne kërkojmë nga ta një udhëzues për deploy, një hartë monitorimi dhe një përshkrim të përafërt (siç mund ta shkruajnë programuesit) të asaj se si funksionon ky komponent, si ta zgjidhim çështjet.
- Ne zgjidhim jo arsye tĂ« problemit, por problemin â atĂ« qĂ« kam pĂ«rmendur tashmĂ«. ĂshtĂ« e rĂ«ndĂ«sishme pĂ«r ne tĂ« mbrojmĂ« pĂ«rdoruesin nga problemet.
- Kemi disa leje. Për shembull, ne nuk e shqyrtojmë si periudhë pa shërbim nëse humbasim 2% të trafikut për dy minuta. Kjo në fakt nuk hyn në statistikat tona. Nëse është më shumë në përqindje ose kohë, atëherë e marrim parasysh.
- Dhe ne gjithmonĂ« shkruajmĂ« postmortem. ĂfarĂ«do qĂ« ndodh, çdo situatĂ« qĂ« sillet ndryshe nĂ« prodhim do tĂ« pasqyrohet nĂ« postmortem. Postmortem Ă«shtĂ« njĂ« dokument nĂ« tĂ« cilin shkruani se çfarĂ« ndodhi, njĂ« kohĂ« e detajuar, çfarĂ« bĂ«tĂ« pĂ«r ta rregulluar dhe (ky Ă«shtĂ« njĂ« seksion i detyrueshĂ«m!) çfarĂ« do tĂ« bĂ«ni pĂ«r tĂ« mos lejuar qĂ« kjo tĂ« ndodhĂ« nĂ« tĂ« ardhmen. Kjo Ă«shtĂ« e nevojshme pĂ«r analizĂ«n e mĂ«vonshme.
ĂfarĂ« konsiderohet periudhĂ« pa shĂ«rbim?
NĂ« çfarĂ« pĂ«rfundimi tĂ« gjithĂ« kjo erdhi?Kjo solli qĂ« (kemi pasur disa probleme me stabilitetin, qĂ« nuk kĂ«naqnin as klientĂ«t dhe as ne) nĂ« gjashtĂ« muajt e fundit, shkalla jonĂ« e stabilitetit tĂ« jetĂ« 99,97. Mund tĂ« thuhet se kjo nuk Ă«shtĂ« shumĂ«. Po, kemi ende pĂ«r tĂ« arritur mĂ« shumĂ«. Prej kĂ«tij treguesi, mjaft gjysma â Ă«shtĂ« stabiliteti qĂ« nuk Ă«shtĂ« nĂ« pĂ«rgjithĂ«si ynĂ«, por i shkarkuesit tĂ« aplikacionit tonĂ« web, i cili Ă«shtĂ« para nesh dhe pĂ«rdoret si shĂ«rbim, por pĂ«r klientĂ«t kjo nuk ka rĂ«ndĂ«si.
Kemi mĂ«suar tĂ« flijmĂ« nĂ« natĂ«. PĂ«rfundimisht! GjysmĂ« viti mĂ« parĂ« nuk dinim. Dhe nĂ« kĂ«tĂ« notĂ« me pĂ«rfundimet, dua tĂ« bĂ«j njĂ« shĂ«nim tĂ« vogĂ«l. MbrĂ«mĂ« kishte njĂ« prezantim tĂ« shkĂ«lqyer mbi sistemin e menaxhimit tĂ« reaktorĂ«ve bĂ«rthamorĂ«. NĂ«se mĂ« dĂ«gjoni njerĂ«z qĂ« keni shkruar kĂ«tĂ« sistem â ju lutem, harroni atĂ« qĂ« thashĂ« pĂ«r '2% â kjo nuk Ă«shtĂ« periudhĂ« pa shĂ«rbim'. PĂ«r ju 2% Ă«shtĂ« periudhĂ« pa shĂ«rbim, edhe nĂ«se Ă«shtĂ« pĂ«r dy minuta!
Kjo është gjithçka! Pyetjet tuaja.
PĂ«r balancuesit dhe migrimin nga databaza
Pyetja nga audienca (nga kĂ«tu â P): â MirĂ«mĂ«ngjes. Faleminderit shumĂ« pĂ«r kĂ«tĂ« referat administrativ! Pyetja Ă«shtĂ« e shkurtĂ«r, nĂ« lidhje me balancuesit tuaj. E pĂ«rmendĂ«t se keni WAF, pra, siç e kuptoj unĂ«, si balancues pĂ«rdorni ndonjĂ«âŠ
EK: â Jo, si balancues ne pĂ«rdorim shĂ«rbimet tona. NĂ« kĂ«tĂ« rast, WAF Ă«shtĂ« pĂ«r ne vetĂ«m njĂ« instrument mbrojtjeje nga DDoS.
P: â A mund tĂ« thoni disa fjalĂ« pĂ«r balancuesit?
EK: â Siç e thashĂ«, kjo Ă«shtĂ« njĂ« grup serverĂ«sh nĂ« openresty. Tani pĂ«r tani kemi 5 grupe rezervarĂ«sh, tĂ« cilat pĂ«rgjigjen ekskluzivisht... pra, serveri, mbi tĂ« cilin qĂ«ndron vetĂ«m openresty, ai vetĂ«m proksionon trafik. Pra, pĂ«r tĂ« kuptuar se sa mbajmĂ«: aktualisht fluksi ynĂ« i zakonshĂ«m Ă«shtĂ« disa qindra megabit. Ata e pĂ«rballojnĂ«, janĂ« tĂ« mirĂ«, madje nuk shqetĂ«sohen.
P: â Po njĂ« pyetje e thjeshtĂ«. Ka Blue/Green deployment. ĂfarĂ« bĂ«ni, pĂ«r shembull, me migrimet nga databaza?
EK: â Pyetje e mirĂ«! Shihni, nĂ« Blue/Green deployment kemi radhĂ« tĂ« veçanta pĂ«r çdo linjĂ«. Pra, nĂ«se flasim pĂ«r radhĂ«t e ngjarjeve qĂ« kalojnĂ« nga punĂ«tor nĂ« punĂ«tor, ka radhĂ« tĂ« veçanta pĂ«r linjĂ«n blu dhe linjĂ«n e gjelbĂ«r. NĂ«se flasim pĂ«r vetĂ« databazĂ«n, ne e kemi ngushtuar me dashje, siç munda, e kemi transferuar gjithçka praktikisht nĂ« radhĂ«, nĂ« databazĂ« mbajmĂ« vetĂ«m stack-un e transaksioneve. Dhe stack-u i transaksioneve Ă«shtĂ« i njĂ«jtĂ« pĂ«r tĂ« gjitha linjat. Me databazĂ«n nĂ« kĂ«tĂ« kontekst: ne nuk e ndajmĂ« atĂ« nĂ« blu dhe gjelbĂ«r, sepse tĂ« dyja variantet e kodit duhet tĂ« dinĂ« çfarĂ« po ndodh me transaksionin.
MiqtĂ«, kam njĂ« çmim tĂ« vogĂ«l pĂ«r ju, pĂ«r t'ju nxitur â njĂ« libĂ«r. Dhe mĂ« duhet ta dorĂ«zoj pĂ«r pyetjen mĂ« tĂ« mirĂ«.
P: â PĂ«rshĂ«ndetje. Faleminderit pĂ«r referatin. Pyetja Ă«shtĂ« kĂ«shtu. Ju monitoroni pagesat, ju monitoroni shĂ«rbimet me tĂ« cilat komunikoni⊠Por si monitoroni qĂ« njeriu nĂ« njĂ« farĂ« mĂ«nyre erdhi nĂ« faqen tuaj tĂ« pagesĂ«s, realizoi pagesĂ«n, dhe projekti i kreditoi paratĂ«? Pra, si e monitoroni se marchant-i Ă«shtĂ« nĂ« dispozicion dhe pranoi callback-un tuaj?
EK: â «Merchant» pĂ«r ne nĂ« kĂ«tĂ« rast Ă«shtĂ« njĂ« shĂ«rbim i jashtĂ«m si dhe sistemi i pagesave. Ne monitorojmĂ« shpejtĂ«sinĂ« e pĂ«rgjigjes sĂ« marchant-it.
Për enkriptimin e databazës
P: â PĂ«rshĂ«ndetje. Kam njĂ« pyetje tĂ« vogĂ«l nĂ« kĂ«tĂ« kontekst. A keni tĂ« dhĂ«na tĂ« ndjeshme sipas PCI DSS? DĂ«shiroja tĂ« dija, si i ruani PAN-tĂ« nĂ« radhĂ« qĂ« duhet t'i kaloni? A pĂ«rdorni ndonjĂ« enkriptim? Dhe pyetja e dytĂ« qĂ« lind nga kjo: sipas PCI DSS, Ă«shtĂ« e nevojshme tĂ« riparoheni periodikisht bazĂ«n nĂ« rast ndryshimesh (ndĂ«rprerja e administratorĂ«ve, etj.) â si ndodhi me disponueshmĂ«rinĂ« nĂ« kĂ«tĂ« rast?
EK: â NjĂ« pyetje e shkĂ«lqyer! SĂ« pari, ne nuk ruajmĂ« PAN-tĂ« nĂ« radhĂ«. Ne nuk kemi tĂ« drejtĂ« tĂ« ruajmĂ« PAN nĂ« asnjĂ« formĂ« tĂ« hapur, prandaj ne pĂ«rdorim njĂ« shĂ«rbim tĂ« veçantĂ« (ne e quajmĂ« «Keidemon») â ky Ă«shtĂ« njĂ« shĂ«rbim qĂ« bĂ«n vetĂ«m njĂ« gjĂ«: merr nĂ« hyrje njĂ« mesazh dhe kthen njĂ« mesazh tĂ« enkriptuar. Dhe ne e ruajmĂ« tĂ« gjithĂ« atĂ« mesazh tĂ« enkriptuar. Kyçet tona janĂ« nĂ«n njĂ« kilobajt, kĂ«shtu qĂ« Ă«shtĂ« serioze dhe e besueshme.P: â Tani duhen 2 kilobajta?
EK: â Duket se dje ishin 256⊠Po ku shkonte mĂ«?!
Pra, kjo Ă«shtĂ« e para. Dhe sĂ« dyti, zgjidhja qĂ« kemi mbĂ«shtet procedurĂ«n e riparhimit â ka dy grupe «cek» (çelĂ«sh), tĂ« cilat japin «dek» qĂ« enkriptojnĂ« (key â janĂ« çelĂ«sh, dek â janĂ« derivatet e çelĂ«sh qĂ« enkriptojnĂ«). NĂ« rastin e fillimit tĂ« procedurĂ«s (ato ndodhin rregullisht, çdo 3 muaj deri nĂ« ± disa) ne ngarkojmĂ« njĂ« grup tĂ« ri «cek» dhe ndodh riparhimi i tĂ« dhĂ«nave. Ne kemi shĂ«rbime tĂ« veçanta qĂ« nxjerrin tĂ« dhĂ«nat, i enkriptojnĂ« pĂ«rsĂ«ri; pĂ«r tĂ« dhĂ«nat Ă«shtĂ« ruajtur njĂ« identifikues i çelĂ«sit me tĂ« cilin janĂ« enkriptuar. Pra, sapo tĂ« dhĂ«nat janĂ« enkriptuar me çelĂ«sa tĂ« rinj, ne fshijmĂ« çelĂ«sat e vjetĂ«r.
NdonjĂ«herĂ« Ă«shtĂ« e nevojshme tĂ« kryhen pagesat manualishtâŠ
P: â KĂ«shtu qĂ« nĂ«se ka ardhur njĂ« kthim pĂ«r ndonjĂ« operacion, do ta enkriptoni akoma me çelĂ«sin e vjetĂ«r?
EK: â Po.
P: â AtĂ«herĂ« njĂ« pyetje tĂ« vogĂ«l. Kur ndodh njĂ« gabim, rĂ«nie, incident, Ă«shtĂ« e nevojshme tĂ« kaloni transaksionin nĂ« mĂ«nyrĂ« manuale. NdonjĂ«herĂ« ndodhin situata tĂ« tilla.
EK: â Po, ndodhin.
P: â Nga i merrni kĂ«to tĂ« dhĂ«na? Apo e bĂ«ni vetĂ« dorazi nĂ« atĂ« depo?
EK: â Jo, e kuptueshme â kemi njĂ« sistem back-office qĂ« pĂ«rmban njĂ« ndĂ«rfaqe pĂ«r mbĂ«shtetje. NĂ«se nuk e dimĂ« se çfarĂ« statusi ka transaksioni (p.sh., derisa sistemi i pagesave tĂ« mos pĂ«rgjigjet me skadimin e kohĂ«s) â ne nĂ« parim nuk e dimĂ«, domethĂ«nĂ« ne e caktojmĂ« statusin pĂ«rfundimtar vetĂ«m kur jemi plotĂ«sisht tĂ« sigurt. NĂ« kĂ«tĂ« rast, ne e vendosim transaksionin nĂ« njĂ« status tĂ« veçantĂ« pĂ«r pĂ«rpunim manual. NĂ« mĂ«ngjesin e ditĂ«s tjetĂ«r, sa herĂ« qĂ« mbĂ«shtetja merr informacionin se nĂ« sistemin e pagesave kanĂ« mbetur disa transaksione, ata i pĂ«rpunojnĂ« ato manualisht nĂ« kĂ«tĂ« ndĂ«rfaqe.
P: â Kam disa pyetje. NjĂ«ra prej tyre Ă«shtĂ« lidhur me vazhdimin e zonĂ«s PCI DSS: si i nxirrni log-et nga konturi? Ky pyetje bĂ«het sepse zhvilluesi mund tĂ« ketĂ« vendosur çdo gjĂ« nĂ« log-e! Pyetja tjetĂ«r: si realizoni hotfix-et? Manualisht nĂ« bazĂ« â Ă«shtĂ« njĂ« variant, por mund tĂ« ketĂ« hot-fix-a falas â cila Ă«shtĂ« procedura atje? Dhe pyetja e tretĂ«, ndoshta, Ă«shtĂ« lidhur me RTO, RPO. Ju keni patur njĂ« disponueshmĂ«ri prej 99,97, pothuajse katĂ«r nĂ«ntĂ«, por kuptoj se keni edhe qendrĂ«n e dytĂ« tĂ« tĂ« dhĂ«nave, qendrĂ«n e tretĂ« tĂ« tĂ« dhĂ«nave, dhe qendrĂ«n e pestĂ« tĂ« tĂ« dhĂ«nave⊠Si merret me sinkronizimin e tyre, replikimin, gjithçka tjetĂ«r?EK: â Le tĂ« fillojmĂ« me tĂ« parin. Pyetja e parĂ« ishte pĂ«r log-et? Kur shkruhen log-e, kemi njĂ« ndĂ«rmjetĂ«s qĂ« maskon tĂ« gjitha tĂ« dhĂ«nat e ndjeshme. Ajo shikon pĂ«rmes maskĂ«s dhe fushave tĂ« tjera shtesĂ«. MĂ«nyra, ne log-et dalin me tĂ« dhĂ«na tĂ« maskuara dhe kontur tĂ« PCI DSS. Kjo Ă«shtĂ« njĂ« nga detyrat e rregullta qĂ« i Ă«shtĂ« caktuar departamentit tĂ« testimit. Ata janĂ« tĂ« detyruar tĂ« kontrollojnĂ« çdo detyrĂ«, pĂ«rfshirĂ« ato log-e qĂ« shkruajnĂ«, dhe kjo Ă«shtĂ« njĂ« nga detyrat e rregullta gjatĂ« rishikimit tĂ« kodit, pĂ«r tĂ« kontrolluar qĂ« zhvilluesi nuk ka regjistruar diçka. Kontrolli i mĂ«vonshĂ«m bĂ«het rregullisht nga departamenti i sigurisĂ« sĂ« informacionit, afĂ«rsisht njĂ« herĂ« nĂ« javĂ«: log-et e fundit nga dita e fundit merren rastĂ«sisht dhe kalohen pĂ«rmes njĂ« skaner-analizuesi nga serverĂ«t testues pĂ«r tĂ« kontrolluar gjithçka.
Rreth hot-fixâave. Kjo Ă«shtĂ« pĂ«rfshirĂ« nĂ« rregullat tona tĂ« lançimeve. Ne kemi njĂ« nen tĂ« veçantĂ« pĂ«r hot-fixâat. Ne mendojmĂ« se i lançojmĂ« hot-fixâat nĂ« çdo moment qĂ« na nevojitet. Sa herĂ« qĂ« versioni Ă«shtĂ« ndĂ«rtuar, sa herĂ« qĂ« ai Ă«shtĂ« testuar, sa herĂ« qĂ« kemi artefaktin â njĂ« administrator sistemi i gatshĂ«m do tĂ« ngrihet nĂ« telefonatĂ«n nga mbĂ«shtetje dhe ai do ta lançojĂ« atĂ« nĂ« momentin kur Ă«shtĂ« e nevojshme.Rreth âkatĂ«r nĂ«ntĂ«veâ. Numri qĂ« kemi tani, realisht Ă«shtĂ« arritur dhe ne synonim ta arrijmĂ« atĂ« edhe nĂ« njĂ« qendĂ«r tjetĂ«r tĂ« tĂ« dhĂ«nave. Tani kemi njĂ« qendĂ«r tĂ« dytĂ« tĂ« tĂ« dhĂ«nave dhe fillojmĂ« tĂ« bĂ«jmĂ« routing ndĂ«rmjet tyre, dhe çështja e replikimit ndĂ«r-qendror tĂ« tĂ« dhĂ«nave â Ă«shtĂ« vĂ«rtet njĂ« çështje jo triviale. Ne pĂ«rpiqeshim ta zgjidhim atĂ« nĂ« kohĂ«n tonĂ« me mjete tĂ« ndryshme: provuam tĂ« pĂ«rdornim edhe âTarantulâ â nuk na funksionoi, ua them menjĂ«herĂ«. Prandaj arritĂ«m nĂ« pĂ«rfundimin se bĂ«jmĂ« porosi pĂ«r âsensaâ manualisht. Ădo aplikacion nĂ« tĂ« vĂ«rtetĂ« nĂ« mĂ«nyrĂ« asinkrone kthen sinjalet e nevojshme ândrysho - e kryerâ ndĂ«rmjet qendrave tĂ« tĂ« dhĂ«nave.
P: â NĂ«se ju erdhi njĂ« e dyta, pĂ«rse nuk u bĂ« njĂ« e treta? Sepse Split-brain askushâŠ
EK: â Ne nuk kemi âSplit-brainâ. PĂ«r shkak se çdo aplikacion nĂ« ne zhvillon multimaster, pĂ«r ne nuk ka rĂ«ndĂ«si nĂ« cilĂ«n qendĂ«r erdhi kĂ«rkesa. Ne jemi tĂ« gatshĂ«m pĂ«r faktin se, nĂ«se njĂ« qendĂ«r e tĂ« dhĂ«nave dĂ«shtoi (ne e kemi parashikuar kĂ«tĂ«) dhe gjatĂ« mesit tĂ« kĂ«rkesĂ«s sĂ« pĂ«rdoruesit kalon nĂ« qendrĂ«n e dytĂ«, ne jemi gati ta humbasim kĂ«tĂ« pĂ«rdorues, nĂ« tĂ« vĂ«rtetĂ«; por kjo do tĂ« jetĂ« njĂ« numĂ«r shumĂ« i vogĂ«l, numra absolutĂ«.
P: â MirĂ«mĂ«ngjes. Faleminderit pĂ«r raportin. Ju treguat pĂ«r debaggerin tuaj, i cili nĂ« prodhim zhvillon disa transaksione testuese. Po, na tregoni pĂ«r transaksionet testuese! Sa thellĂ« shkon ajo?
EK: â Ajo kalon ciklin e plotĂ« tĂ« gjithĂ« komponentit. PĂ«r komponentin nuk ka dallime ndĂ«rmjet njĂ« transaksioni testues dhe njĂ« operativ. Nga kĂ«ndvĂ«shtrimi logjik, Ă«shtĂ« thjesht njĂ« projekt i veçantĂ« nĂ« sistem, ku vetĂ«m zhvillohen transaksione testuese.
P: â Po ku e ndaloni atĂ«? Pra, Core dĂ«rgoiâŠ
EK: â Ne jemi pas âKoritâ nĂ« kĂ«tĂ« rast pĂ«r transaksionet testuese⊠Ne kemi njĂ« koncept tĂ« tillĂ« si routing: âKoriâ di nĂ« cilĂ«n sistem pagesash duhet tĂ« dĂ«rgojmĂ« â ne dĂ«rgojmĂ« nĂ« njĂ« sistem pagesash fals, i cili jep thjesht njĂ« pĂ«rgjigje http dhe mbaroi.
P: â Ju lutem, a keni njĂ« aplikacion tĂ« shkruar si njĂ« monolit i madh, apo e keni ndarĂ« atĂ« nĂ« ndonjĂ« shĂ«rbim ose madje mikroshĂ«rbime?
EK: â Nuk Ă«shtĂ« njĂ« monolit, sigurisht, kemi njĂ« aplikacion tĂ« orientuar rreth shĂ«rbimeve. Kemi njĂ« shaka qĂ« thonĂ« se kemi shĂ«rbim nga monolitĂ«t â ata janĂ« nĂ« tĂ« vĂ«rtetĂ« mjaft tĂ« mĂ«dhenj. TĂ« quajmĂ« ato mikroshĂ«rbime, gjuha nuk na kthjellon fare, por janĂ« shĂ«rbime brenda tĂ« cilave punojnĂ« punĂ«torĂ«t e makinave tĂ« shpĂ«rndara.
Nëse shërbimi në server është i komprometuar...
P: â AtĂ«herĂ« kam pyetje tjetĂ«r. Edhe nĂ«se do tĂ« ishte njĂ« monolit, ju akoma thatĂ« se keni shumĂ« nga kĂ«to servera instant, tĂ« gjithĂ« ato nĂ« parim pĂ«rpunojnĂ« tĂ« dhĂ«nat, dhe pyetja Ă«shtĂ« kjo: «NĂ« rastin e njĂ« komprometimi tĂ« njĂ« prej serverave instant ose aplikacionit, ndonjĂ« elementi tĂ« veçantĂ«, a kanĂ« ata ndonjĂ« kontroll aksesi? Kush mund tĂ« bĂ«jĂ« çfarĂ«? Te cilĂ«t mund tĂ« adresohen, pĂ«r cilat tĂ« dhĂ«na?
EK: â Po, padyshim. KĂ«rkesat pĂ«r siguri janĂ« mjaft serioze. SĂ« pari, kemi lĂ«vizje tĂ« hapura tĂ« tĂ« dhĂ«nave, dhe portat janĂ« vetĂ«m ato qĂ« ne parashikojmĂ« paraprakisht pĂ«r lĂ«vizjen e trafikut. NĂ«se njĂ« komponent komunikon me bazĂ«n e tĂ« dhĂ«nave (le tĂ« themi, me 'MySQL') pĂ«rmes 5-4-3-2, do t'i hapen vetĂ«m 5-4-3-2, dhe portat e tjera, drejtimet e tjera tĂ« lĂ«vizjes sĂ« trafikut nuk do tĂ« jenĂ« tĂ« aksesueshme. PĂ«rveç kĂ«saj, duhet tĂ« kuptoni se nĂ« prodhim ekzistojnĂ« rreth 10 skema tĂ« ndryshme sigurie. Edhe nĂ«se aplikacioni Ă«shtĂ« komprometuar nĂ« njĂ« farĂ« mĂ«nyre, mos e bĂ«ftĂ« Zoti, atĂ«herĂ« sulmuesi nuk do tĂ« ketĂ« qasje nĂ« konsolĂ«n e menaxhimit tĂ« serverit, sepse kjo Ă«shtĂ« njĂ« zonĂ« tjetĂ«r e sigurisĂ«.P: â NĂ« kĂ«tĂ« kontekst mĂ« intereson mĂ« shumĂ« momenti se keni disa kontrata me shĂ«rbimet â çfarĂ« mund tĂ« bĂ«jnĂ« ato, pĂ«rmes cilave «veprime» mund tĂ« lidhen mes tyre... Dhe nĂ« njĂ« fluks normal, disa shĂ«rbime tĂ« caktuara kĂ«rkojnĂ« njĂ« sĂ«rĂ« tĂ« caktuar «veprimesh» nga tjetri. Ata zakonisht nuk lidhen me tĂ« tjerĂ«t nĂ« njĂ« situatĂ« normale, dhe kanĂ« zona pĂ«rgjegjĂ«sie tĂ« tjera. NĂ«se, megjithatĂ«, njĂ«ri nga ata komprometohet, a mund tĂ« tĂ«rheqĂ« «veprimet» e atij shĂ«rbimi?..
EK: â E kuptoj. NĂ«se nĂ« situatĂ«n normale me njĂ« server tjetĂ«r komunikimi ishte i lejuar, atĂ«herĂ« â po. Sipas kontratĂ«s SLA, ne nuk monitorojmĂ« qĂ« ju janĂ« lejuar vetĂ«m tri "aksione" tĂ« para, ndĂ«rsa aksioni i katĂ«rt nuk Ă«shtĂ« i lejuar pĂ«r ju. Kjo, ndoshta, Ă«shtĂ« tepĂ«r pĂ«r ne, sepse ne tashmĂ« kemi njĂ« sistem mbrojtjeje me katĂ«r nivele pĂ«r shkak se kaq shumĂ« kufij. Ne preferojmĂ« tĂ« mbrohemi me kufij, jo nĂ« nivelin e brendĂ«sisĂ«.
Si funksionojnë Visa, MasterCard dhe "Sberbank"
P: â Dua tĂ« sqaroj njĂ« moment nĂ« lidhje me kalimin e pĂ«rdoruesit nga njĂ« qendĂ«r tĂ« dhĂ«nash nĂ« njĂ« tjetĂ«r. Sa di unĂ«, "Visa" dhe "MasterCard" punojnĂ« me protokollin binar sinkron 8583, aty janĂ« pĂ«rzierjet. DĂ«shiroja tĂ« dija, a ka tĂ« bĂ«jĂ« kalimiâ me "Visa" dhe "MasterCard" pĂ«rkatĂ«sisht, ose deri te sistemet e pagesave, deri te procesorĂ«t?
EK: â Kjo Ă«shtĂ« deri te pĂ«rzierjet. PĂ«rzierjet tona janĂ« nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash.
P: â ThĂ«nĂ« ndryshe, a keni njĂ« pikĂ« lidhjeje?
EK: â PĂ«r "Visa" dhe "MasterCard" â po. Thjesht pĂ«r shkak se "Visa" dhe "MasterCard" kĂ«rkojnĂ« investime mjaft tĂ« rĂ«ndĂ«sishme nĂ« infrastrukturĂ«n pĂ«r tĂ« lidhur kontrata tĂ« veçanta pĂ«r tĂ« marrĂ« njĂ« çift tĂ« dytĂ« pĂ«rzierjesh, pĂ«r shembull. Ato janĂ« rezervuar brenda njĂ« qendre tĂ« dhĂ«nash, por nĂ«se ndodh qĂ« qendra e dhĂ«nash, ku ndodhen pĂ«rzierjet pĂ«r lidhjen me "Visa" dhe "MasterCard", ndalon tĂ« funksionojĂ«, atĂ«herĂ« lidhja me "Visa" dhe "MasterCard" do tĂ« humbasĂ«...
P: â Si mund tĂ« jenĂ« ato tĂ« rezervuara? UnĂ« e di qĂ« "Visa" lejon tĂ« ruhet vetĂ«m njĂ« lidhje nĂ« thelb!
EK: â Ata vetĂ« furnizojnĂ« pajisjet. NĂ« çdo rast, na ka ardhur pajisja, e cila brenda Ă«shtĂ« rezervuar fort.
P: â Pra, Ă«shtĂ« rafti nga lidhjet e tyre Orange..?
EK: â Po.
P: â Si Ă«shtĂ« nĂ« kĂ«tĂ« rast: nĂ«se qendra e dhĂ«nash juaj shkon, si do tĂ« vazhdojmĂ« ta pĂ«rdorim? Ose thjesht trafiku ndalon?
EK: â Jo. Ne nĂ« kĂ«tĂ« rast thjesht do ta kalojmĂ« trafikun nĂ« njĂ« kanal tjetĂ«r, i cili, sigurisht, do tĂ« na kushtojĂ« mĂ« shumĂ«, mĂ« shumĂ« klientĂ«ve. Por trafiku do tĂ« kalojĂ« jo nĂ«pĂ«r lidhjen tonĂ« direkte me "Visa", "MasterCard", por pĂ«rmes njĂ« "Sberbank" hipotetikisht (shumĂ« e thjeshtuar).
Më vjen shumë keq nëse kam ofenduar stafin e "Sberbank". Por sipas statistikave tona, nga bankat ruse, "Sberbank" ndalon më shpesh. Nuk kalon një muaj që "Sberbank" të mos ketë ndonjë problem.
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
