Të gjithë flasin për proceset e zhvillimit dhe testimit, trajnimin e stafit, rritjen e motivimit, por këto procese nuk mjaftojnë kur një minutë ndërprerje shërbimi kushton shuma të mëdha parash. Çfarë duhet të bëni kur kryeni transaksione financiare sipas një SLA strikte? Si të rrisni besueshmërinë dhe tolerancën ndaj gabimeve të sistemeve tuaja, duke nxjerrë zhvillimin dhe testimin jashtë ekuacionit?
Konferenca e radhës HighLoad++ do të mbahet më 6 dhe 7 prill 2020 në Shën Petersburg. Detajet dhe biletat për . 9 nëntor ora 18:00. HighLoad++ Moskë 2018, Delhi + sallë Kolkata. Tezat dhe .
Evgeniy Kuzovlev (në tekstin e mëtejmë - KE): - Miq, përshëndetje! Emri im është Kuzovlev Evgeniy. Unë jam nga kompania EcommPay, një divizion specifik është EcommPay IT, divizioni IT i grupit të kompanive. Dhe sot do të flasim për kohët e ndërprerjes - për mënyrën se si t'i shmangni ato, se si të minimizoni pasojat e tyre nëse nuk mund të shmangen. Tema shprehet si më poshtë: “Çfarë duhet bërë kur një minutë pushim kushton 100 dollarë”? Duke parë përpara, numrat tanë janë të krahasueshëm.
Çfarë bën EcommPay IT?
Kush jemi ne? Pse po qëndroj këtu përballë jush? Pse kam të drejtë t'ju them diçka këtu? Dhe për çfarë do të flasim këtu në më shumë detaje?
Grupi i kompanive EcommPay është një blerës ndërkombëtar. Ne përpunojmë pagesa në të gjithë botën - në Rusi, Evropë, Azinë Juglindore (Në të gjithë botën). Kemi 9 zyra, gjithsej 500 punonjës dhe afërsisht pak më pak se gjysma e tyre janë specialistë të IT. Çdo gjë që bëjmë, çdo gjë nga e cila fitojmë para, e kemi bërë vetë.
Ne i kemi shkruar të gjitha produktet tona (dhe kemi mjaft prej tyre - në linjën tonë të produkteve të mëdha të TI-së kemi rreth 16 komponentë të ndryshëm) vetë; Ne shkruajmë vetë, zhvillojmë veten. Dhe për momentin ne kryejmë rreth një milion transaksione në ditë (miliona është ndoshta mënyra e duhur për ta thënë). Ne jemi një kompani mjaft e re - jemi vetëm rreth gjashtë vjeç.
6 vjet më parë ishte një startup i tillë kur djemtë erdhën së bashku me biznesin. Ata i bashkoi një ide (nuk kishte asgjë tjetër veç një ideje), dhe ne vrapuam. Si çdo startup, ne vrapuam më shpejt... Për ne, shpejtësia ishte më e rëndësishme se cilësia.
Në një moment u ndalëm: kuptuam se nuk mund të jetonim më në një farë mënyre me atë shpejtësi dhe me atë cilësi dhe duhej të fokusoheshim në cilësinë e parë. Në këtë moment, ne vendosëm të shkruanim një platformë të re që do të ishte e saktë, e shkallëzueshme dhe e besueshme. Ata filluan të shkruanin këtë platformë (ata filluan të investojnë, zhvillojnë zhvillimin, testimin), por në një moment e kuptuan se zhvillimi dhe testimi nuk na lejuan të arrijmë një nivel të ri të cilësisë së shërbimit.
Ju bëni një produkt të ri, e vendosni në prodhim, por gjithsesi diçka do të shkojë keq diku. Dhe sot do të flasim se si të arrijmë një nivel të ri cilësie (si ia dolëm, për përvojën tonë), duke nxjerrë zhvillimin dhe testimin nga ekuacioni; ne do të flasim për atë që është në dispozicion për funksionimin - çfarë operacioni mund të bëjë vetë, çfarë mund t'i ofrojë testimit për të ndikuar në cilësi.
Kohët e ndërprerjes. Urdhërimet e operimit.
Gjithmonë gurthemeli kryesor, ajo për të cilën do të flasim në të vërtetë sot është koha e pushimit. Një fjalë e tmerrshme. Nëse kemi pushim, gjithçka është e keqe për ne. Po vrapojmë ta ngremë, administratorët po e mbajnë serverin - mos të bjerë Zoti, siç thonë në atë këngë. Kjo është ajo për të cilën do të flasim sot.
Kur filluam të ndryshonim qasjet tona, ne formuam 4 urdhërime. Unë i kam të paraqitura në sllajde:
Këto urdhërime janë mjaft të thjeshta:
- Identifikoni shpejt problemin.
- Hiqni qafe atë edhe më shpejt.
- Ndihmoni për të kuptuar arsyen (më vonë, për zhvilluesit).
- Dhe standardizoni qasjet.
Dua të tërhiqja vëmendjen te pika nr. 2. Po e heqim qafe problemin, jo po e zgjidhim. Vendimi është dytësor. Për ne, gjëja kryesore është që përdoruesi të jetë i mbrojtur nga ky problem. Do të ekzistojë në një mjedis të izoluar, por ky mjedis nuk do të ketë asnjë kontakt me të. Në fakt, ne do t'i kalojmë këto katër grupe problemesh (disa më në detaje, disa më pak), unë do t'ju tregoj se çfarë përdorim ne, çfarë përvojë relevante kemi në zgjidhje.
Zgjidhja e problemeve: Kur ndodhin dhe çfarë të bëni për ta?
Por ne do të fillojmë jashtë rregullit, do të fillojmë me pikën nr. 2 - si të shpëtojmë shpejt nga problemi? Ka një problem - duhet ta rregullojmë. "Çfarë duhet të bëjmë për këtë?" - pyetja kryesore. Dhe kur filluam të mendonim se si ta rregullonim problemin, zhvilluam për vete disa kërkesa që duhet të ndiqen zgjidhja e problemeve.
Për të formuluar këto kërkesa, vendosëm t'i bëjmë vetes pyetjen: "Kur kemi probleme"? Dhe problemet, siç doli, ndodhin në katër raste:
- Dështimi i harduerit.
- Shërbimet e jashtme dështuan.
- Ndryshimi i versionit të softuerit (i njëjti vendosje).
- Rritja e ngarkesës shpërthyese.
Nuk do të flasim për dy të parat. Një mosfunksionim i harduerit mund të zgjidhet mjaft thjesht: duhet të keni gjithçka të dyfishuar. Nëse këto janë disqe, disqet duhet të montohen në RAID; nëse ky është një server, serveri duhet të dublikohet; nëse keni një infrastrukturë rrjeti, duhet të siguroni një kopje të dytë të infrastrukturës së rrjetit, domethënë, ta merrni dhe dublikojeni atë. Dhe nëse diçka dështon, kaloni në fuqinë rezervë. Është e vështirë të thuash diçka më shumë këtu.
E dyta është dështimi i shërbimeve të jashtme. Për shumicën, sistemi nuk është aspak problem, por jo për ne. Duke qenë se ne përpunojmë pagesat, ne jemi një grumbullues që qëndron midis përdoruesit (që fut të dhënat e kartës së tij) dhe bankave, sistemeve të pagesave (Visa, MasterCard, Mira, etj.). Shërbimet tona të jashtme (sistemet e pagesave, bankat) priren të dështojnë. As ne dhe as ju (nëse keni shërbime të tilla) nuk mund të ndikojmë në këtë.
Çfarë duhet bërë atëherë? Këtu ka dy opsione. Së pari, nëse mundeni, duhet ta kopjoni këtë shërbim në një farë mënyre. Për shembull, nëse mundemi, ne transferojmë trafikun nga një shërbim në tjetrin: për shembull, kartat u përpunuan përmes Sberbank, Sberbank ka probleme - ne transferojmë trafikun [me kusht] te Raiffeisen. Gjëja e dytë që mund të bëjmë është të vërejmë shumë shpejt dështimin e shërbimeve të jashtme, dhe për këtë arsye do të flasim për shpejtësinë e përgjigjes në pjesën tjetër të raportit.
Në fakt, nga këto katër, ne mund të ndikojmë në mënyrë specifike në ndryshimin e versioneve të softuerit - të ndërmarrim veprime që do të çojnë në një përmirësim të situatës në kontekstin e vendosjeve dhe në kontekstin e rritjes shpërthyese të ngarkesës. Në fakt, kjo është ajo që ne bëmë. Këtu, përsëri, një shënim i vogël ...
Nga këto katër probleme, disa zgjidhen menjëherë nëse keni një re. Nëse jeni në Microsoft Azhur, retë e Ozonit ose përdorni retë tona, nga Yandex ose Mail, atëherë të paktën një mosfunksionim harduerik bëhet problemi i tyre dhe gjithçka bëhet menjëherë mirë për ju në kontekstin e një mosfunksionimi harduer.
Ne jemi një kompani paksa jokonvencionale. Këtu të gjithë po flasin për "Kubernets", për retë - ne nuk kemi as "Kubernets" as re. Por ne kemi rafte harduerësh në shumë qendra të dhënash, dhe ne jemi të detyruar të jetojmë me këtë pajisje, ne jemi të detyruar të jemi përgjegjës për të gjitha. Prandaj, ne do të flasim në këtë kontekst. Pra, për problemet. Dy të parat u hoqën nga kllapat.
Ndryshimi i versionit të softuerit. Bazat
Zhvilluesit tanë nuk kanë qasje në prodhim. Pse eshte ajo? Thjesht ne jemi të certifikuar PCI DSS dhe zhvilluesit tanë thjesht nuk kanë të drejtë të hyjnë në "produkt". Kjo është ajo, pika. fare. Prandaj, përgjegjësia e zhvillimit përfundon pikërisht në momentin kur zhvillimi dorëzon ndërtimin për lëshim.
Baza jonë e dytë që kemi, e cila gjithashtu na ndihmon shumë, është mungesa e njohurive unike të padokumentuara. Shpresoj që të jetë e njëjta gjë për ju. Sepse nëse nuk është kështu, do të keni probleme. Problemet do të lindin kur kjo njohuri unike, e padokumentuar nuk është e pranishme në kohën e duhur në vendin e duhur. Le të themi se keni një person që di të vendosë një komponent specifik - personi nuk është aty, ai është me pushime ose i sëmurë - kjo është e gjitha, ju keni probleme.
Dhe baza e tretë në të cilën kemi ardhur. E arritëm me dhimbje, gjak, lot - arritëm në përfundimin se ndonjë prej ndërtimeve tona përmban gabime, edhe nëse është pa gabime. Ne vendosëm këtë për veten tonë: kur vendosim diçka, kur hedhim diçka në prodhim, kemi një ndërtim me gabime. Ne kemi formuar kërkesat që sistemi ynë duhet të plotësojë.
Kërkesat për ndryshimin e versionit të softuerit
Ka tre kërkesa:
- Ne duhet të kthejmë shpejt vendosjen.
- Ne duhet të minimizojmë ndikimin e një vendosjeje të pasuksesshme.
- Dhe ne duhet të jemi në gjendje të vendosemi shpejt paralelisht.
Pikërisht në atë rend! Pse? Sepse, para së gjithash, kur vendosni një version të ri, shpejtësia nuk është e rëndësishme, por është e rëndësishme që ju, nëse diçka nuk shkon, të riktheheni shpejt dhe të keni ndikim minimal. Por nëse keni një grup versionesh në prodhim, për të cilat rezulton se ka një gabim (nga blu, nuk ka pasur vendosje, por ka një gabim) - shpejtësia e vendosjes së mëvonshme është e rëndësishme për ju. Çfarë kemi bërë për të përmbushur këto kërkesa? Ne iu drejtuam metodologjisë së mëposhtme:
Është mjaft e njohur, ne kurrë nuk e kemi shpikur - kjo është vendosja Blu/Green. Cfare eshte? Duhet të keni një kopje për çdo grup serverësh në të cilët janë instaluar aplikacionet tuaja. Kopja është "e ngrohtë": nuk ka trafik në të, por në çdo moment ky trafik mund të dërgohet në këtë kopje. Kjo kopje përmban versionin e mëparshëm. Dhe në kohën e vendosjes, ju vendosni 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ë atë të ri, duhet të bëni vetëm një veprim: duhet të ndryshoni balancuesin në rrjedhën e sipërme, të ndryshoni drejtimin - nga një rrjedhë në tjetrën. Kjo është shumë e përshtatshme dhe zgjidh problemin e ndërrimit të shpejtë dhe rikthimit të shpejtë.Këtu zgjidhja për pyetjen e dytë është minimizimi: ju mund të dërgoni vetëm një pjesë të trafikut tuaj në një linjë të re, në një linjë me një kod të ri (le të jetë, për shembull, 2%). Dhe këto 2% nuk janë 100%! Nëse keni humbur 100% të trafikut tuaj për shkak të një vendosjeje të pasuksesshme, kjo është e frikshme; nëse keni humbur 2% të trafikut tuaj, kjo është e pakëndshme, por nuk është e frikshme. Për më tepër, përdoruesit ka shumë të ngjarë as që ta vënë re këtë, sepse në disa raste (jo në të gjitha) i njëjti përdorues, duke shtypur F5, do të dërgohet në një version tjetër funksional.
Vendosja blu/jeshile. Drejtimi
Megjithatë, jo gjithçka është kaq e thjeshtë "Shpërndarja blu/jeshile"... Të gjithë komponentët tanë mund të ndahen në tre grupe:
- ky është frontend (faqet e pagesave që shohin klientët tanë);
- bërthama përpunuese;
- përshtatës për të punuar me sistemet e pagesave (banka, MasterCard, Visa...).
Dhe këtu ka një nuancë - nuanca qëndron në drejtimin midis linjave. Nëse thjesht kaloni 100% të trafikut, nuk i keni këto probleme. Por nëse doni të ndryshoni 2%, ju filloni të bëni pyetje: "Si ta bëni këtë?" Gjëja më e thjeshtë është e drejtpërdrejtë: ju mund të konfiguroni Round Robin në nginx me zgjedhje të rastësishme dhe keni 2% në të majtë, 98% në të djathtë. Por kjo nuk është gjithmonë e përshtatshme.
Për shembull, në rastin tonë, një përdorues ndërvepron me sistemin me më shumë se një kërkesë. Kjo është normale: 2, 3, 4, 5 kërkesa - sistemet tuaja mund të jenë të njëjta. Dhe nëse është e rëndësishme për ju që të gjitha kërkesat e përdoruesit të vijnë në të njëjtën linjë në të cilën erdhi kërkesa e parë, ose (pika e dytë) të gjitha kërkesat e përdoruesit të vijnë në linjën e re pas ndërrimit (ai mund të kishte filluar të punonte më herët me sistemi, para kalimit), - atëherë kjo shpërndarje e rastësishme nuk është e përshtatshme për ju. Pastaj ka opsionet e mëposhtme:
Opsioni i parë, më i thjeshti, bazohet në parametrat bazë të klientit (IP Hash). Ju keni një IP dhe e ndani atë nga e djathta në të majtë me adresën IP. Atëherë rasti i dytë që përshkrova do të funksionojë për ju, kur ndodhi vendosja, përdoruesi tashmë mund të fillojë të punojë me sistemin tuaj, dhe që nga momenti i vendosjes të gjitha kërkesat do të shkojnë në një linjë të re (në të njëjtën, le të themi).Nëse për ndonjë arsye kjo nuk ju përshtatet dhe duhet të dërgoni kërkesa në linjën ku ka ardhur kërkesa fillestare, fillestare e përdoruesit, atëherë keni dy mundësi...
Opsioni i parë: mund të blini nginx+ me pagesë. Ekziston një mekanizëm i sesioneve Sticky, i cili, me kërkesën fillestare të përdoruesit, i cakton një sesion përdoruesit dhe e lidh atë me një ose një tjetër në rrjedhën e sipërme. Të gjitha kërkesat e mëvonshme të përdoruesve brenda jetëgjatësisë së sesionit do të dërgohen në të njëjtën rrjedhë ku është postuar sesioni.Kjo nuk na përshtatej sepse ne kishim tashmë nginx të rregullt. Kalimi në nginx+ nuk është se është i shtrenjtë, thjesht se ishte disi e dhimbshme për ne dhe jo shumë e drejtë. "Sticks Sessions", për shembull, nuk funksionoi për ne për arsyen e thjeshtë se "Sticks Sessions" nuk lejojnë kursimin bazuar në "Ose-ose". Aty mund të specifikoni se çfarë bëjmë ne "Sticks Sessions", për shembull, nga adresa IP ose nga adresa IP dhe skedarët e skedarëve ose me parametra postar, por "Ose-ose" është më e ndërlikuar atje.
Prandaj, arritëm në opsionin e katërt. Ne morëm nginx në steroid (ky është openresty) - ky është i njëjti nginx, i cili gjithashtu mbështet përfshirjen e skripteve të fundit. Mund të shkruani një skript të fundit, t'i jepni një "pushim të hapur" dhe ky skript i fundit do të ekzekutohet kur të vijë kërkesa e përdoruesit.
Dhe ne kemi shkruar, në fakt, një skenar të tillë, i kemi vendosur vetes "openresti" dhe në këtë skenar ne renditim 6 parametra të ndryshëm sipas lidhjes "Ose". Në varësi të pranisë së një ose një parametri tjetër, ne e dimë që përdoruesi erdhi në një faqe ose në një tjetër, në një rresht ose në një tjetër.
Vendosja blu/jeshile. Avantazhet dhe disavantazhet
Sigurisht, ndoshta ishte e mundur ta bënim pak më të thjeshtë (përdorni të njëjtat "Sticky Sessions"), por ne kemi gjithashtu një nuancë të tillë që jo vetëm përdoruesi ndërvepron me ne brenda kornizës së një përpunimi të një transaksioni ... Por sistemet e pagesave ndërveprojnë gjithashtu me ne: Pasi të përpunojmë transaksionin (duke dërguar një kërkesë në sistemin e pagesave), marrim një kthim ftohës.
Dhe le të themi, nëse brenda qarkut tonë ne mund të përcjellim adresën IP të përdoruesit në të gjitha kërkesat dhe t'i ndajmë përdoruesit në bazë të adresës IP, atëherë nuk do t'i themi të njëjtës "Visa": "Duke, ne jemi një kompani kaq retro, na duket të jetë ndërkombëtar (në faqen e internetit dhe në Rusi)... Ju lutemi na jepni adresën IP të përdoruesit në një fushë shtesë, protokolli juaj është i standardizuar”! Është e qartë se ata nuk do të pajtohen.
Prandaj, kjo nuk funksionoi për ne - ne bëmë openresty. Prandaj, me rrugëzimin kemi marrë diçka të tillë:Vendosja Blu/Green ka, në përputhje me rrethanat, avantazhet që përmenda dhe disavantazhet.
Dy disavantazhe:
- ju duhet të shqetësoheni me rrugëzimin;
- disavantazhi i dytë kryesor është shpenzimi.
Ju duhen dy herë më shumë serverë, keni nevojë për dy herë më shumë burime operacionale, duhet të shpenzoni dy herë më shumë përpjekje për të mirëmbajtur të gjithë këtë kopsht zoologjik.
Nga rruga, midis avantazheve ka edhe një gjë që nuk e kam përmendur më parë: ju keni një rezervë në rast të rritjes së ngarkesës. Nëse keni një rritje shpërthyese në ngarkesë, keni një numër të madh përdoruesish, atëherë thjesht përfshini rreshtin e dytë në shpërndarjen 50 deri në 50 - dhe menjëherë keni serverë x2 në grupin tuaj derisa të zgjidhni problemin e të pasurit më shumë serverë.
Si të bëni një vendosje të shpejtë?
Ne folëm se si të zgjidhim problemin e minimizimit dhe rikthimit të shpejtë, por pyetja mbetet: "Si të vendosemi shpejt?"
Këtu është e shkurtër dhe e thjeshtë.- Ju duhet të keni një sistem CD (Dorëzimi i vazhdueshëm) - nuk mund të jetoni pa të. Nëse keni një server, mund ta vendosni manualisht. Ne kemi rreth një mijë e gjysmë serverë dhe një mijë e gjysmë doreza, natyrisht - ne mund të vendosim një departament me madhësinë e kësaj dhome vetëm për t'u vendosur.
- Vendosja duhet të jetë paralele. Nëse vendosja juaj është sekuenciale, atëherë gjithçka është e keqe. Një server është normal, ju do të vendosni një mijë e gjysmë serverë gjatë gjithë ditës.
- Përsëri, për përshpejtimin, kjo ndoshta nuk është më e nevojshme. Gjatë vendosjes, projekti zakonisht ndërtohet. Ju keni një projekt në internet, ka një pjesë të përparme (ju bëni një paketë ueb atje, përpiloni npm - diçka e tillë), dhe ky proces është, në parim, jetëshkurtër - 5 minuta, por këto 5 minuta mund të të jetë kritik. Kjo është arsyeja pse, për shembull, ne nuk e bëjmë këtë: i hoqëm këto 5 minuta, ne vendosim objekte.
Çfarë është një objekt? Një objekt është një ndërtim i montuar në të cilin të gjitha pjesët e montimit janë përfunduar tashmë. Ne e ruajmë këtë objekt në ruajtjen e objekteve. Në një kohë kemi përdorur dy memorie të tilla - ishte Nexus dhe tani jFrog Artifactory) Fillimisht përdorëm "Nexus" sepse filluam ta praktikonim këtë qasje në aplikacionet java (i përshtatej mirë). Pastaj vendosin disa nga aplikacionet e shkruara në PHP atje; dhe "Nexus" nuk ishte më i përshtatshëm, dhe për këtë arsye ne zgjodhëm jFrog Artefactory, i cili mund të artifaktorizojë pothuajse gjithçka. Madje kemi arritur deri në pikën që në këtë depo të objekteve ne ruajmë paketat tona binare që mbledhim për serverët.
Rritja e ngarkesës shpërthyese
Ne folëm për ndryshimin e versionit të softuerit. Gjëja tjetër që kemi është një rritje shpërthyese e ngarkesës. Këtu, me siguri nënkuptoj me rritjen shpërthyese të ngarkesës jo fare gjënë e duhur ...
Ne kemi shkruar një sistem të ri - është i orientuar drejt shërbimit, në modë, i bukur, punëtorë kudo, radhë kudo, asinkroni kudo. Dhe në sisteme të tilla, të dhënat mund të rrjedhin nëpër rrjedha të ndryshme. Për transaksionin e parë, mund të përdoret punëtori i parë, i tretë, i 1-të, për transaksionin e dytë - i dyti, i 3-ti, i 10-ti. Dhe sot, le të themi, në mëngjes keni një rrjedhë të dhënash që përdor tre punëtorët e parë, dhe në mbrëmje ndryshon në mënyrë dramatike, dhe gjithçka përdor tre punëtorët e tjerë.
Dhe këtu rezulton se ju duhet të shkallëzoni disi punëtorët, duhet të shkallëzoni disi shërbimet tuaja, por në të njëjtën kohë të parandaloni fryrjen e burimeve.
Ne i kemi përcaktuar kërkesat tona. Këto kërkesa janë mjaft të thjeshta: të ketë zbulim shërbimi, parametrizim - gjithçka është standarde për ndërtimin e sistemeve të tilla të shkallëzueshme, përveç një pike - amortizimi i burimeve. Ne thamë që nuk jemi gati të amortizojmë burimet në mënyrë që serverët të ngrohin ajrin. Morëm “Konsullin”, morëm “Nomad”, që menaxhon punëtorët tanë.Pse është ky problem për ne? Le të kthehemi pak prapa. Tani kemi rreth 70 sisteme pagese pas nesh. Në mëngjes, trafiku kalon përmes Sberbank, pastaj Sberbank ra, për shembull, dhe ne e kalojmë atë në një sistem tjetër pagese. Ne kishim 100 punëtorë para Sberbank, dhe pas kësaj duhet të rrisim ndjeshëm 100 punëtorë për një sistem tjetër pagese. Dhe është e dëshirueshme që e gjithë kjo të ndodhë pa pjesëmarrjen njerëzore. Sepse nëse ka pjesëmarrje njerëzore, duhet të jetë një inxhinier i ulur 24/7, i cili duhet të bëjë vetëm këtë, sepse dështime të tilla, kur janë 70 sisteme pas teje, ndodhin rregullisht.
Prandaj, ne shikuam Nomad-in, i cili ka një IP të hapur, dhe shkruajmë gjënë tonë, Scale-Nomad - ScaleNo, i cili bën afërsisht sa vijon: monitoron rritjen e radhës dhe zvogëlon ose rrit numrin e punëtorëve në varësi të dinamikës. të radhës. Kur e bëmë, menduam: "Ndoshta mund ta hapim burimin?" Pastaj ata e shikuan atë - ajo ishte aq e thjeshtë sa dy kopekë.
Deri më tani nuk e kemi me burim të hapur, por nëse papritmas pas raportimit, pasi kuptove se ke nevojë për një gjë të tillë, të duhet, kontaktet e mia janë në rrëshqitjen e fundit - ju lutem më shkruani. Nëse janë të paktën 3-5 persona, ne do ta sponsorizojmë.
Si punon? Le t'i hedhim një sy! Duke parë përpara: në anën e majtë është një pjesë e monitorimit tonë: kjo është një rresht, në krye është koha e përpunimit të ngjarjes, në mes është numri i transaksioneve, në fund është numri i punëtorëve.Nëse shikoni, ka një defekt në këtë foto. Në grafikun më të lartë, një nga grafikët u rrëzua në 45 sekonda - një nga sistemet e pagesave u rrëzua. Menjëherë, trafiku u fut në 2 minuta dhe radha filloi të rritet në një sistem tjetër pagese, ku nuk kishte punëtorë (ne nuk i shfrytëzuam burimet - përkundrazi, e hodhëm burimin në mënyrë korrekte). Ne nuk donim të ngroheshim - kishte një numër minimal, rreth 5-10 punëtorë, por ata nuk mund të përballonin.
Grafiku i fundit tregon një "gungë", që do të thotë thjesht se "Skaleno" dyfishoi këtë shumë. Dhe pastaj, kur grafiku ra pak, ai e zvogëloi pak - numri i punëtorëve u ndryshua automatikisht. Kështu funksionon kjo gjë. Ne folëm për pikën numër 2 - "Si të shpëtojmë shpejt nga arsyet".
Monitorimi. Si ta identifikoni shpejt problemin?
Tani pika e parë është "Si ta identifikojmë shpejt problemin?" Monitorimi! Duhet të kuptojmë shpejt disa gjëra. Cilat gjëra duhet të kuptojmë shpejt?
Tre gjera!- Ne duhet të kuptojmë dhe kuptojmë shpejt performancën e burimeve tona.
- Ne duhet të kuptojmë shpejt dështimet dhe të monitorojmë performancën e sistemeve që janë të jashtme për ne.
- Pika e tretë është identifikimi i gabimeve logjike. Kjo është kur sistemi funksionon për ju, gjithçka është normale sipas të gjithë treguesve, por diçka nuk shkon.
Ndoshta nuk do t'ju them asgjë kaq interesante këtu. Unë do të jem kapiten i qartë. Ne kërkuam atë që ishte në treg. Ne kemi një "kopsht zoologjik argëtues". Ky është lloji i kopshtit zoologjik që kemi tani:
Ne përdorim Zabbix për të monitoruar harduerin, për të monitoruar treguesit kryesorë të serverëve. Ne përdorim Okmeter për bazat e të dhënave. Ne përdorim "Grafana" dhe "Prometheus" për të gjithë treguesit e tjerë që nuk përshtaten me dy të parët, disa me "Grafana" dhe "Prometheus", dhe disa me "Grafana" me "Influx" dhe Telegraf.Një vit më parë ne donim të përdornim New Relic. Gjë e bukur, mund të bëjë gjithçka. Por për aq sa mund të bëjë gjithçka, ajo është aq e shtrenjtë. Kur u rritëm në një vëllim prej 1,5 mijë serverësh, një shitës erdhi tek ne dhe tha: "Le të lidhim një marrëveshje për vitin e ardhshëm." Ne shikuam çmimin dhe thamë jo, ne nuk do ta bëjmë këtë. Tani po braktisim New Relic, kemi rreth 15 serverë të mbetur nën monitorimin e New Relic. Çmimi doli të ishte absolutisht i egër.
Dhe ekziston një mjet që ne e kemi zbatuar vetë - ky është Debugger. Në fillim e quajtëm "Bagger", por më pas kaloi një mësues i anglishtes, qeshi egërsisht dhe e quajti "Debagger". Cfare eshte? Ky është një mjet që, në fakt, në 15-30 sekonda në çdo komponent, si një "kuti e zezë" e sistemit, kryen teste mbi performancën e përgjithshme të komponentit.
Për shembull, nëse ka një faqe të jashtme (faqe pagese), ai thjesht e hap atë dhe shikon se si duhet të duket. Nëse ky është përpunues, ai dërgon një "transaksion" testues dhe sigurohet që ky "transaksion" të arrijë. Nëse kjo është një lidhje me sistemet e pagesave, ne lëshojmë një kërkesë testimi në përputhje me rrethanat, ku mundemi, dhe shohim që gjithçka është në rregull me ne.
Cilët tregues janë të rëndësishëm për monitorimin?
Çfarë monitorojmë kryesisht? Cilët tregues janë të rëndësishëm për ne?
- Koha e reagimit / RPS në fronte është një tregues shumë i rëndësishëm. Ai menjëherë përgjigjet se diçka nuk shkon me ju.
- Numri i mesazheve të përpunuara në të gjitha radhët.
- Numri i punëtorëve.
- Metrikat bazë të korrektësisë.
Pika e fundit është metrika "biznes", "biznes". Nëse dëshironi të monitoroni të njëjtën gjë, duhet të përcaktoni një ose dy metrikë që janë treguesit kryesorë për ju. Metrika jonë është xhiroja (ky është raporti i numrit të transaksioneve të suksesshme me rrjedhën totale të transaksionit). Nëse diçka ndryshon në të në një interval prej 5-10-15 minutash, do të thotë se kemi probleme (nëse ndryshon rrënjësisht).
Ajo që duket për ne është një shembull i një prej bordeve tona:
Në anën e majtë ka 6 grafikë, kjo është sipas rreshtave - numri i punëtorëve dhe numri i mesazheve në radhë. Në anën e djathtë - RPS, RTS. Më poshtë është e njëjta metrikë "biznesi". Dhe në metrikën e "biznesit" mund të shohim menjëherë se diçka shkoi keq në dy grafikët e mesit... Ky është vetëm një sistem tjetër që qëndron pas nesh që ka rënë.Gjëja e dytë që duhej të bënim ishte të monitoronim rënien e sistemeve të pagesave të jashtme. Këtu morëm OpenTracing - një mekanizëm, standard, paradigmë që ju lejon të gjurmoni sistemet e shpërndara; dhe u ndryshua pak. Paradigma standarde OpenTracing thotë se ne ndërtojmë një gjurmë për çdo kërkesë individuale. Ne nuk kishim nevojë për këtë dhe e mbështjellëm me një gjurmë përmbledhjeje. Ne bëmë një mjet që na lejon të gjurmojmë shpejtësinë e sistemeve pas nesh.
Grafiku na tregon se një nga sistemet e pagesave filloi të përgjigjet në 3 sekonda - kemi probleme. Për më tepër, kjo gjë do të reagojë kur të fillojnë problemet, në një interval prej 20-30 sekondash.Dhe klasa e tretë e gabimeve të monitorimit që ekzistojnë është monitorimi logjik.
Të them të drejtën, nuk dija çfarë të vizatoja në këtë rrëshqitje, sepse kishim kohë që kërkonim në treg diçka që do të na përshtatej. Nuk gjetëm asgjë, ndaj duhej ta bënim vetë.
Çfarë nënkuptoj me monitorim logjik? Epo, imagjinoni: ju i bëni vetes një sistem (për shembull, një klon Tinder); e bëre, e nise. Menaxheri i suksesshëm Vasya Pupkin e vuri në telefonin e tij, sheh një vajzë atje, e pëlqen atë ... dhe të ngjashme nuk i shkojnë vajzës - e ngjashme shkon te rojtari i sigurisë Mikhalych nga e njëjta qendër biznesi. Menaxheri zbret poshtë dhe më pas pyet veten: "Pse ky roje sigurie Mikhalych i buzëqesh kaq këndshëm?"Në situata të tilla... Për ne kjo situatë tingëllon pak më ndryshe, sepse (kam shkruar) kjo është një humbje reputacioni që indirekt çon në humbje financiare. Situata jonë është e kundërta: ne mund të pësojmë humbje direkte financiare - për shembull, nëse kemi kryer një transaksion si të suksesshëm, por ai ka qenë i pasuksesshëm (ose anasjelltas). Më duhej të shkruaja mjetin tim që gjurmon numrin e transaksioneve të suksesshme me kalimin e kohës duke përdorur treguesit e biznesit. Nuk gjeta asgjë në treg! Kjo është pikërisht ideja që doja të përcillja. Nuk ka asgjë në treg për të zgjidhur këtë lloj problemi.
Kjo kishte të bënte me mënyrën se si të identifikohej shpejt problemi.
Si të përcaktohen arsyet e vendosjes
Grupi i tretë i problemeve që zgjidhim është pasi të kemi identifikuar problemin, pasi të kemi hequr qafe atë, do të ishte mirë të kuptonim arsyen e zhvillimit, të testimit dhe të bënim diçka për të. Prandaj, ne duhet të hetojmë, ne duhet të ngremë shkrimet.
Nëse po flasim për regjistrat (arsyeja kryesore janë shkrimet), pjesa më e madhe e regjistrave tanë janë në ELK Stack - pothuajse të gjithë kanë të njëjtën gjë. Për disa, mund të mos jetë në ELK, por nëse shkruani regjistrat në gigabajt, atëherë herët a vonë do të vini në ELK. Ne i shkruajmë ato në terabajt.
Këtu ka një problem. Ne e rregulluam atë, korrigjuam gabimin për përdoruesin, filluam të gërmojmë atë që kishte, u ngjitëm në Kibana, futëm ID-në e transaksionit atje dhe morëm një mbulesë këmbësh si kjo (tregon shumë). Dhe absolutisht asgjë nuk është e qartë në këtë mbulesë këmbësh. Pse? Po, sepse nuk është e qartë se cila pjesë i përket cilit punëtor, cila pjesë i përket cilës komponentë. Dhe në atë moment kuptuam se kishim nevojë për gjurmim - i njëjti OpenTracing për të cilin fola.Ne e menduam këtë një vit më parë, e kthyem vëmendjen tonë drejt tregut dhe aty ishin dy vegla - "Zipkin" dhe "Jaeger". "Jager" është në fakt një trashëgimtar i tillë ideologjik, një pasardhës ideologjik i "Zipkin". Gjithçka është e mirë në Zipkin, përveç se nuk di të grumbullojë, nuk di të përfshijë shkrimet në gjurmë, vetëm gjurmë kohore. Dhe "Jager" e mbështeti këtë.
Ne shikuam "Jager": ju mund të instrumentoni aplikacionet, mund të shkruani në Api (standardi Api për PHP në atë kohë, megjithatë, nuk ishte miratuar - kjo ishte një vit më parë, por tani është miratuar tashmë), por atje nuk ishte absolutisht asnjë klient. "Mirë," menduam dhe i shkruam klientit tonë. Çfarë morëm? Kjo është përafërsisht se si duket:
Në Jaeger, hapësirat krijohen për çdo mesazh. Kjo do të thotë, kur një përdorues hap sistemin, ai sheh një ose dy blloqe për secilën kërkesë hyrëse (1-2-3 - numri i kërkesave hyrëse nga përdoruesi, numri i blloqeve). Për ta bërë më të lehtë për përdoruesit, ne shtuam etiketa në regjistrat dhe gjurmët kohore. Prandaj, në rast të një gabimi, aplikacioni ynë do të shënojë regjistrin me etiketën e duhur të Gabimit. Mund të filtrosh sipas etiketës së gabimit dhe do të shfaqen vetëm hapësirat që përmbajnë këtë bllok me një gabim. Kjo është se si duket nëse zgjerojmë hapësirën:
Brenda hapësirës ka një sërë gjurmësh. Në këtë rast, këto janë tre gjurmë testimi, dhe gjurma e tretë na tregon se ka ndodhur një gabim. Në të njëjtën kohë, këtu shohim një gjurmë kohore: ne kemi një shkallë kohore në krye dhe shohim se në çfarë intervali kohor është regjistruar ky apo ai regjistër.Prandaj, gjërat shkuan mirë për ne. Ne kemi shkruar zgjerimin tonë dhe e kemi burim të hapur. Nëse dëshironi të punoni me gjurmimin, nëse dëshironi të punoni me "Jager" në PHP, ekziston zgjerimi ynë, i mirëpritur ta përdorni, siç thonë ata:
Ne kemi këtë shtesë - është një klient për OpenTracing Api, është bërë si shtrirje php, domethënë, do t'ju duhet ta montoni dhe ta instaloni në sistem. Një vit më parë nuk kishte asgjë ndryshe. Tani ka klientë të tjerë që janë si komponentë. Këtu varet nga ju: ose do t'i nxirrni komponentët me një kompozitor, ose do të përdorni zgjerimin sipas jush.Standardet e korporatës
Ne folëm për tre urdhërimet. Urdhërimi i katërt është standardizimi i qasjeve. Për çfarë bëhet fjalë? Bëhet fjalë për këtë:
Pse është fjala "korporatë" këtu? Jo sepse jemi kompani e madhe apo burokratike, jo! Doja të përdorja fjalën "korporatë" këtu në kontekstin që çdo kompani, çdo produkt duhet të ketë standardet e veta, duke përfshirë edhe ju. Çfarë standardesh kemi?
- Ne kemi rregullore për vendosjen. Ne nuk lëvizim askund pa të, nuk mundemi. Ne vendosemi rreth 60 herë në javë, domethënë vendosemi pothuajse vazhdimisht. Në të njëjtën kohë, ne kemi, për shembull, në rregulloret e vendosjes një tabu për vendosjet të premten - në parim, ne nuk vendosemi.
- Kërkojmë dokumentacion. Asnjë komponent i vetëm i ri nuk hyn në prodhim nëse nuk ka dokumentacion për të, edhe nëse ka lindur nën stilolapsin e specialistëve tanë të RnD. Ne kërkojmë prej tyre udhëzime për vendosjen, një hartë monitorimi dhe një përshkrim të përafërt (siç mund të shkruajnë programuesit) se si funksionon ky komponent, si ta zgjidhim atë.
- Ne nuk zgjidhim shkakun e problemit, por problemin - atë që thashë tashmë. Është e rëndësishme për ne të mbrojmë përdoruesin nga problemet.
- Ne kemi leje. Për shembull, ne nuk e konsiderojmë atë joproduktive nëse kemi humbur 2% të trafikut brenda dy minutave. Kjo në thelb nuk përfshihet në statistikat tona. Nëse është më shumë në përqindje ose e përkohshme, ne tashmë llogarisim.
- Dhe ne gjithmonë shkruajmë postmortem. Çfarëdo që të ndodhë me ne, çdo situatë ku dikush është sjellë në mënyrë jonormale në prodhim do të pasqyrohet në postmortem. Një postmortem është një dokument në të cilin shkruani atë që ju ka ndodhur, një kohë të detajuar, çfarë keni bërë për ta korrigjuar atë dhe (ky është një bllok i detyrueshëm!) çfarë do të bëni për të parandaluar që kjo të ndodhë në të ardhmen. Kjo është e detyrueshme dhe e nevojshme për analizat e mëvonshme.
Çfarë konsiderohet joproduktive?
Në çfarë çoi e gjithë kjo?Kjo çoi në faktin se (ne kishim disa probleme me stabilitetin, kjo nuk u përshtatet as klientëve dhe as neve) gjatë 6 muajve të fundit treguesi ynë i stabilitetit ishte 99,97. Mund të themi se kjo nuk është shumë. Po, kemi diçka për të cilën të përpiqemi. Nga ky tregues, rreth gjysma është stabiliteti, si të thuash, jo i yni, por i firewall-it të aplikacionit tonë në ueb, i cili qëndron përballë nesh dhe përdoret si shërbim, por klientëve nuk u intereson kjo.
Mësuam të flemë natën. Më në fund! Gjashtë muaj më parë nuk mundëm. Dhe në këtë shënim me rezultatet, do të doja të bëja një shënim. Mbrëmë pati një raport të mrekullueshëm për sistemin e kontrollit për një reaktor bërthamor. Nëse njerëzit që kanë shkruar këtë sistem mund të më dëgjojnë, ju lutemi harroni atë që thashë për "2% nuk është kohë joproduktive". Për ju, 2% është pushim, qoftë edhe për dy minuta!
Kjo eshte e gjitha! Pyetjet tuaja.
Rreth balancuesve dhe migrimit të bazës së të dhënave
Pyetje nga auditori (në tekstin e mëtejmë – B): – Mirëmbrëma. Faleminderit shumë për një raport të tillë admin! Një pyetje e shkurtër për balancuesit tuaj. Ju përmendët që keni një WAF, domethënë, siç e kuptoj unë, ju përdorni një lloj balancuesi të jashtëm...
EK: – Jo, ne përdorim shërbimet tona si balancues. Në këtë rast, WAF është ekskluzivisht një mjet mbrojtës DDoS për ne.
NË: – Mund të thoni disa fjalë për balancuesit?
EK: – Siç e thashë tashmë, ky është një grup serverësh në openresty. Tani kemi 5 grupe rezervë që përgjigjen ekskluzivisht... domethënë, një server që drejton ekskluzivisht openresty, ai vetëm proxon trafikun. Prandaj, për të kuptuar se sa kemi: tani kemi një fluks të rregullt trafiku prej disa qindra megabitësh. Ata përballen, ndihen mirë, nuk e sforcojnë as veten.
NË: – Edhe një pyetje e thjeshtë. Këtu është vendosja Blu/Green. Çfarë bëni, për shembull, me migrimet e bazës së të dhënave?
EK: - Pyetje e mirë! Shikoni, në vendosjen Blu/Green ne kemi radhë të veçanta për secilën linjë. Kjo do të thotë, nëse flasim për radhë ngjarjesh që transmetohen nga punëtori në punëtor, ka radhë të veçanta për vijën blu dhe për vijën e gjelbër. Nëse po flasim për vetë bazën e të dhënave, atëherë qëllimisht e ngushtuam sa më shumë që mundëm, zhvendosëm gjithçka praktikisht në radhë; në bazën e të dhënave ne ruajmë vetëm një pirg transaksionesh. Dhe grupi ynë i transaksioneve është i njëjtë për të gjitha linjat. Me bazën e të dhënave në këtë kontekst: ne nuk e ndajmë atë në blu dhe jeshile, sepse të dy versionet e kodit duhet të dinë se çfarë po ndodh me transaksionin.
Miq, kam edhe një çmim të vogël për t'ju nxitur - një libër. Dhe unë duhet të shpërblehem për pyetjen më të mirë.
NË: - Përshëndetje. Faleminderit për raportin. Pyetja është kjo. Ju monitoroni pagesat, monitoroni shërbimet me të cilat komunikoni... Por si monitoroni që një person të vinte disi në faqen tuaj të pagesës, të kryente një pagesë dhe projekti t'i kreditonte paratë? Kjo do të thotë, si e monitoroni që marshuesi është i disponueshëm dhe ka pranuar thirrjen tuaj?
EK: – “Tregtar” për ne në këtë rast është saktësisht i njëjti shërbim i jashtëm si sistemi i pagesave. Ne monitorojmë shpejtësinë e përgjigjes së tregtarit.
Rreth kriptimit të bazës së të dhënave
NË: - Përshëndetje. Unë kam një pyetje pak të lidhur. Ju keni të dhëna të ndjeshme PCI DSS. Doja të dija se si i ruani PAN-et në radhët në të cilat duhet të transferoni? A përdorni ndonjë enkriptim? Dhe kjo çon në pyetjen e dytë: sipas PCI DSS, është e nevojshme që periodikisht të rikriptohet baza e të dhënave në rast të ndryshimeve (shkarkimi i administratorëve, etj.) - çfarë ndodh me aksesueshmërinë në këtë rast?
EK: - Pyetje e mrekullueshme! Së pari, ne nuk i ruajmë PAN-et në radhë. Ne nuk kemi të drejtë të ruajmë PAN askund në një formë të qartë, në parim, kështu që ne përdorim një shërbim të veçantë (ne e quajmë atë "Kademon") - ky është një shërbim që bën vetëm një gjë: merr një mesazh si hyrje dhe dërgon nxjerr një mesazh të koduar. Dhe ne ruajmë gjithçka me këtë mesazh të koduar. Prandaj, gjatësia jonë kryesore është nën një kilobajt, kështu që kjo është serioze dhe e besueshme.NË: – Të duhen 2 kilobajt tani?
EK: – Duket sikur dje ishte 256... Epo, ku tjetër?!
Prandaj, kjo është e para. Dhe së dyti, zgjidhja që ekziston, ajo mbështet procedurën e rikriptimit - ka dy palë "keks" (çelësat), të cilët japin "kuvertë" që enkriptojnë (çelës janë çelësat, dek janë derivate të çelësave që enkriptojnë) . Dhe nëse procedura fillon (kjo ndodh rregullisht, nga 3 muaj në ± disa), ne shkarkojmë një palë "torte" të reja dhe i rikriptojmë të dhënat. Ne kemi shërbime të veçanta që heqin të gjitha të dhënat dhe i kodojnë ato në një mënyrë të re; Të dhënat ruhen pranë identifikuesit të çelësit me të cilin janë të koduara. Prandaj, sapo i kodojmë të dhënat me çelësa të rinj, fshijmë çelësin e vjetër.
Ndonjëherë pagesat duhet të bëhen me dorë...
NË: – Kjo do të thotë, nëse ka ardhur një rimbursim për ndonjë operacion, a do ta deshifroni akoma me çelësin e vjetër?
EK: - Po.
NË: – Pastaj edhe një pyetje të vogël. Kur ndodh një lloj dështimi, rrëzimi ose incidenti, është e nevojshme të shtyhet transaksioni me dorë. Ekziston një situatë e tillë.
EK: - Po ndonjehere.
NË: – Nga i merrni këto të dhëna? Apo shkoni vetë në këtë depo?
EK: – Jo, mirë, sigurisht, ne kemi një lloj sistemi back-office që përmban një ndërfaqe për mbështetjen tonë. Nëse nuk e dimë se në çfarë statusi është transaksioni (për shembull, derisa sistemi i pagesave të përgjigjet me një afat kohor), nuk e dimë apriori, domethënë ne caktojmë statusin përfundimtar vetëm me besim të plotë. Në këtë rast, ne e caktojmë transaksionin në një status të veçantë për përpunim manual. Në mëngjes, të nesërmen, sapo mbështetja merr informacione se transaksionet e tilla mbeten në sistemin e pagesave, ata i përpunojnë ato manualisht në këtë ndërfaqe.
NË: – Kam nja dy pyetje. Një prej tyre është vazhdimi i zonës PCI DSS: si e regjistroni qarkun e tyre? Kjo pyetje është sepse zhvilluesi mund të kishte vendosur çdo gjë në regjistrat! Pyetja e dytë: si i hapni korrigjimet e shpejta? Trajtimi në bazën e të dhënave është një opsion, por mund të ketë rregullime të nxehta falas - cila është procedura atje? Dhe pyetja e tretë ndoshta lidhet me RTO, RPO. Disponueshmëria juaj ishte 99,97, pothuajse katër nëntë, por siç e kuptoj unë, ju keni një qendër të dytë të dhënash, një qendër të tretë të të dhënave dhe një qendër të pestë të të dhënave... Si i sinkronizoni, replikoni ato dhe gjithçka tjetër?EK: - Le të fillojmë me të parën. A ishte pyetja e parë në lidhje me shkrimet? Kur shkruajmë regjistrat, kemi një shtresë që maskon të gjitha të dhënat e ndjeshme. Ajo shikon maskën dhe fushat shtesë. Prandaj, regjistrat tanë dalin me të dhëna tashmë të maskuara dhe një qark PCI DSS. Kjo është një nga detyrat e rregullta që i caktohen departamentit të testimit. Atyre u kërkohet të kontrollojnë çdo detyrë, duke përfshirë regjistrat që shkruajnë, dhe kjo është një nga detyrat e zakonshme gjatë rishikimeve të kodit, në mënyrë që të kontrollojnë që zhvilluesi të mos ketë shkruar diçka. Kontrollet e mëvonshme të kësaj kryhen rregullisht nga departamenti i sigurisë së informacionit rreth një herë në javë: regjistrat për ditën e fundit merren në mënyrë selektive dhe ato drejtohen përmes një skaner-analizuesi të veçantë nga serverët e testimit për të kontrolluar gjithçka.
Rreth rregullimeve të nxehta. Kjo përfshihet në rregulloret tona të vendosjes. Ne kemi një klauzolë të veçantë për korrigjimet e shpejta. Ne besojmë se vendosim rregullime të shpejta gjatë gjithë kohës kur na duhen. Sapo montohet versioni, sapo ekzekutohet, sapo kemi një objekt, kemi një administrator sistemi në detyrë në një telefonatë nga mbështetja dhe ai e vendos atë në momentin kur është e nevojshme.Rreth "katër nëntë". Shifra që kemi tani është arritur me të vërtetë dhe ne u përpoqëm për të në një qendër tjetër të dhënash. Tani ne kemi një qendër të dytë të të dhënave, dhe ne po fillojmë të kalojmë ndërmjet tyre, dhe çështja e replikimit të qendrave të të dhënave të kryqëzuara është vërtet një pyetje jo e parëndësishme. Ne u përpoqëm ta zgjidhnim njëherësh duke përdorur mjete të ndryshme: u përpoqëm të përdorim të njëjtën "Tarantula" - nuk na funksionoi, do t'ju them menjëherë. Kjo është arsyeja pse ne përfunduam duke porositur "sens" me dorë. Në fakt, çdo aplikacion në sistemin tonë kryen sinkronizimin e nevojshëm "ndryshim - bërë" midis qendrave të të dhënave në mënyrë asinkrone.
NË: – Nëse keni një të dytë, pse nuk keni marrë një të tretë? Sepse askush ende nuk e ka ndarë trurin...
EK: – Por ne nuk kemi tru të ndarë. Për shkak të faktit se çdo aplikacion drejtohet nga një multimaster, për ne nuk ka rëndësi se në cilën qendër erdhi kërkesa. Ne jemi gati për faktin se nëse një nga qendrat tona të të dhënave dështon (ne mbështetemi në këtë) dhe në mes të një kërkese të përdoruesit kalon në qendrën e dytë të të dhënave, ne jemi gati ta humbim këtë përdorues, me të vërtetë; por këto do të jenë njësi, njësi absolute.
NË: - Mirembrema. Faleminderit për raportin. Ju folët për korrigjuesin tuaj, i cili kryen disa transaksione provë në prodhim. Por na tregoni për transaksionet testuese! Sa thellë shkon?
EK: – Ai kalon në ciklin e plotë të të gjithë komponentit. Për një komponent, nuk ka asnjë ndryshim midis një transaksioni testues dhe një transaksioni prodhimi. Por nga pikëpamja logjike, ky është thjesht një projekt i veçantë në sistem, mbi të cilin kryhen vetëm transaksione testuese.
NË: -Ku e ke prerë? Këtu Core dërgoi ...
EK: – Ne jemi prapa “Kor” në këtë rast për transaksione testuese... Kemi një gjë të tillë si rutimi: “Kor” e di se në cilin sistem pagese të dërgojë - dërgojmë në një sistem pagese false, i cili thjesht jep një sinjal http dhe kjo eshte e gjitha.
NË: – Më tregoni, ju lutem, a është shkruar aplikacioni juaj në një monolit të madh, apo e keni prerë në disa shërbime apo edhe mikroshërbime?
EK: – Ne nuk kemi një monolit, sigurisht, kemi një aplikacion të orientuar drejt shërbimit. Ne bëjmë shaka se shërbimi ynë është bërë nga monolite - ato janë vërtet mjaft të mëdha. Është e vështirë ta quash mikroshërbime, por këto janë shërbime brenda të cilave operojnë punëtorët e makinerive të shpërndara.
Nëse shërbimi në server është i komprometuar...
NË: – Atëherë kam pyetjen tjetër. Edhe nëse do të ishte një monolit, ju përsëri thatë se keni shumë nga këta serverë të menjëhershëm, ata të gjithë përpunojnë të dhëna dhe pyetja është: "Në rast kompromisi të një prej serverëve të çastit ose një aplikacioni, ndonjë lidhje individuale , a kanë ata një lloj kontrolli aksesi? Cili prej tyre mund të bëjë çfarë? Me kë duhet të kontaktoj për çfarë informacioni?
EK: - Po, patjetër. Kërkesat e sigurisë janë mjaft serioze. Së pari, ne kemi lëvizje të hapura të të dhënave, dhe portet janë vetëm ato përmes të cilave ne parashikojmë lëvizjen e trafikut paraprakisht. Nëse një komponent komunikon me bazën e të dhënave (të themi, me Muskul) përmes 5-4-3-2, vetëm 5-4-3-2 do të jetë i hapur për të dhe portet e tjera dhe drejtimet e tjera të trafikut nuk do të jenë të disponueshme. Për më tepër, duhet të kuptoni se në prodhimin tonë ka rreth 10 sythe të ndryshme sigurie. Dhe edhe nëse aplikacioni është komprometuar disi, Zoti na ruajt, sulmuesi nuk do të jetë në gjendje të hyjë në tastierën e menaxhimit të serverit, sepse kjo është një zonë tjetër e sigurisë së rrjetit.NË: – Dhe në këtë kontekst, ajo që është më interesante për mua është se ju keni kontrata të caktuara me shërbime – çfarë mund të bëjnë, përmes çfarë “veprimesh” mund të kontaktojnë njëri-tjetrin... Dhe në një rrjedhë normale, disa shërbime specifike kërkojnë disa rresht, një listë "veprimesh" nga ana tjetër. Ata nuk duket se u drejtohen të tjerëve në një situatë normale dhe kanë fusha të tjera përgjegjësie. Nëse njëra prej tyre komprometohet, a do të jetë në gjendje të prishë “veprimet” e atij shërbimi?..
EK: - E kuptoj. Nëse në një situatë normale me një server tjetër komunikimi lejohej fare, atëherë po. Sipas kontratës SLA, ne nuk monitorojmë që ju lejohen vetëm 3 “veprimet” e para dhe nuk ju lejohen 4 “veprimet”. Kjo ndoshta është e tepërt për ne, sepse ne kemi tashmë një sistem mbrojtjeje me 4 nivele, në parim, për qarqet. Ne preferojmë të mbrohemi me konturet, sesa në nivelin e të brendshmeve.
Si funksionojnë Visa, MasterCard dhe Sberbank
NË: – Dua të sqaroj një pikë në lidhje me kalimin e një përdoruesi nga një qendër të dhënash në tjetrën. Me sa di unë, Visa dhe MasterCard funksionojnë duke përdorur protokollin sinkron binar 8583, dhe atje ka përzierje. Dhe doja të dija, tani nënkuptojmë ndërrimin – a është direkt “Visa” dhe “MasterCard” apo para sistemeve të pagesave, përpara procesimit?
EK: - Kjo është para përzierjeve. Përzierjet tona janë të vendosura në të njëjtën qendër të të dhënave.
NË: – Përafërsisht, keni një pikë lidhjeje?
EK: – “Visa” dhe “MasterCard” - po. Thjesht sepse Visa dhe MasterCard kërkojnë investime mjaft serioze në infrastrukturë për të lidhur kontrata të veçanta për të marrë, për shembull, një palë të dytë përzierjesh. Ato janë të rezervuara brenda një qendre të dhënash, por nëse, Zoti na ruajt, qendra jonë e të dhënave, ku ka përzierje për t'u lidhur me Visa dhe MasterCard, vdes, atëherë do të kemi një lidhje me Visa dhe MasterCard të humbur...
NË: – Si mund të rezervohen? Unë e di që Visa lejon vetëm një lidhje në parim!
EK: – Pajisjet i furnizojnë vetë. Në çdo rast, kemi marrë pajisje që janë plotësisht të tepërta brenda.
NË: – Pra, stenda është nga Connects Orange e tyre?..
EK: - Po.
NË: – Por çfarë ndodh me këtë rast: nëse qendra juaj e të dhënave zhduket, si mund të vazhdoni ta përdorni atë? Apo thjesht ndalon trafiku?
EK: - Jo. Në këtë rast, ne thjesht do të kalojmë trafikun në një kanal tjetër, i cili, natyrisht, do të jetë më i shtrenjtë për ne dhe më i shtrenjtë për klientët tanë. Por trafiku nuk do të kalojë përmes lidhjes sonë të drejtpërdrejtë me Visa, MasterCard, por përmes Sberbank të kushtëzuar (shumë e ekzagjeruar).
Kërkoj falje të egër nëse ofendova punonjësit e Sberbank. Por sipas statistikave tona, midis bankave ruse, Sberbank bie më shpesh. Nuk kalon asnjë muaj pa rënë diçka në Sberbank.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - nga 99 dollarë! Lexoni rreth
Burimi: www.habr.com