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
