TĂ« gjithĂ« flasin pĂ«r proceset e zhvillimit dhe testimit, trajnimet e stafit, rritjen e motivimit, por kĂ«to procese janĂ« tĂ« pakta kur njĂ« minutĂ« pezullimi i shĂ«rbimit kushton para tĂ« mĂ«dha. ĂfarĂ« tĂ« bĂ«ni kur kryeni transaksione financiare nĂ«n njĂ« SLA tĂ« rreptĂ«? Si tĂ« rrisni besueshmĂ«rinĂ« dhe qĂ«ndrueshmĂ«rinĂ« e sistemeve tuaja, duke lĂ«nĂ« mĂ«njanĂ« zhvillimin dhe testimin?
Konferenca e ardhshme HighLoad++ do tĂ« mbahet mĂ« 6 dhe 7 prill 2020 nĂ« ShĂ«n Peterburg. Detajet dhe biletat nĂ« . 9 nĂ«ntor, ora 18:00. HighLoad++ MoskĂ« 2018, salla âDeli + Kalkutaâ. Tezat dhe .
Evgeny Kuzovlev (mĂ« pas â EK): â Miq, pĂ«rshĂ«ndetje! MĂ« quajnĂ« Kuzovlev Evgeny. UnĂ« jam nga kompania EcommPay, konkretisht nga divizioni â EcommPay IT, divizioni IT i grupit tĂ« kompanive. Sot do tĂ« flasim pĂ«r pezullimet â si t'i shmangim ato, dhe si tĂ« minimizojmĂ« pasojat e tyre nĂ«se nuk arrijmĂ« t'i pĂ«rjashtojmĂ«. Tema Ă«shtĂ« e njĂ«jtĂ«: âĂfarĂ« tĂ« bĂ«sh kur minuta e pezullimit kushton 100,000 dollarĂ«â? Ne, duke u pĂ«rmendur mĂ« parĂ«, kemi numra tĂ« pĂ«rkatshĂ«m.
ĂfarĂ« bĂ«n EcommPay IT?
Kush jemi ne? Pse po qëndroj këtu para jush? Pse kam të drejtë të flas me ju? Dhe për çfarë do të flasim këtu më detajisht?
Grupi i kompanive EcommPay Ă«shtĂ« njĂ« ekuajer ndĂ«rkombĂ«tar. Ne procesojmĂ« pagesat nĂ« tĂ« gjithĂ« botĂ«n â nĂ« Rusi, EvropĂ«, dhe nĂ« Azi tĂ« Jugut-PerĂ«ndim. Kemi 9 zyra, 500 punonjĂ«s gjithsej, dhe rreth gjysma e tyre janĂ« specialistĂ« IT. Ădo gjĂ« qĂ« bĂ«jmĂ«, gjithçka nga e cila fitojmĂ« para, e kemi bĂ«rĂ« ne vetĂ«.
TĂ« gjitha produktet tona (dhe kemi njĂ« mori â nĂ« linjĂ«n tonĂ« tĂ« produkteve tĂ« mĂ«dha IT kemi rreth 16 komponentĂ« tĂ« ndryshĂ«m) i kemi shkruar vetĂ«; i shkruajmĂ« vetĂ«, i zhvillojmĂ« vetĂ«. Dhe nĂ« momentin aktual ne procesojmĂ« rreth njĂ« milion transaksione nĂ« ditĂ« (mijĂ«ra â ndoshta kĂ«shtu do tĂ« ishte e saktĂ« tĂ« thuash). Ne jemi njĂ« kompani mjaft e re â kemi rreth gjashtĂ« vjet.
6 vjet më parë ishte një startup i tillë, kur erdhi një grup rinor me biznesin e tyre. Ata u bashkuan për një ide (nuk kishte asgjë tjetër përveç ideve), dhe ne u nisa. Si çdo startup, ne vrapuam më shpejt⊠Për ne ishte më e rëndësishme shpejtësia, jo cilësia.
Në ndonjë moment u ndalëm: e kuptuam se nuk mund të vazhdojmë me atë shpejtësi dhe cilësi dhe na duhej t'i kushtonim prioritet të parë cilësisë. Në atë moment, morëm vendimin për të shkruar një platformë të re, që do të ishte e saktë, e shkallëzueshme, dhe e besueshme. Kjo platformë filloi të shkruhej (filluam të investonim, zhvillonim zhvillimin, testimin), por në një moment e kuptuam se zhvillimi, testimi nuk na lejonin të arrinim një nivel të ri cilësie shërbimi.
Ju krijoni njĂ« produkt tĂ« ri, e nxirrni atĂ« nĂ« prodhim, por gjithsesi diku diçka do tĂ« shkojĂ« keq. Dhe sot do tĂ« flasim pĂ«r se si tĂ« arrijmĂ« njĂ« nivel tĂ« ri cilĂ«sor (si arritĂ«m ne kĂ«tĂ«, pĂ«r pĂ«rvojĂ«n tonĂ«), duke lĂ«nĂ« jashtĂ« zhvillimin dhe testimin; do tĂ« flasim se çfarĂ« Ă«shtĂ« nĂ« dispozicion pĂ«r operimin â çfarĂ« mund tĂ« bĂ«jĂ« operimi vetĂ«, çfarĂ« mund tĂ« ofrojĂ« testimit pĂ«r tĂ« ndikuar nĂ« cilĂ«si.
Pezullimet. TĂ« drejtat e operimit.
Always the main cornerstone of what we are going to talk about today â downtime. A terrible word. If we have downtime â everything else is bad. We run to fix it, server admins are holding â God forbid it doesnât fall, as it is sung in that song. This is what we will talk about today.
Kur filluam të ndryshojmë qasjet tona, ne formuam 4 të drejta. Ato janë të pranishme në diapozitivët e mi:
Këto të drejta janë mjaft të thjeshta:
- Shpejt të identifikoni problemin.
- Akoma më shpejt të eliminojmë atë.
- Të ndihmojmë në kuptimin e shkakut (pas, për zhvilluesit).
- Dhe të standardizojmë qasjet.
Do tĂ« kushtoj vĂ«mendje pikĂ«s â 2. Ne eliminuam problemin, por nuk e zgjidhim atĂ«. Zgjidhja Ă«shtĂ« e dyta. PĂ«r ne e para Ă«shtĂ« qĂ« pĂ«rdoruesi tĂ« jetĂ« i mbrojtur nga ky problem. Ai do tĂ« ekzistojĂ« nĂ« njĂ«farĂ« ambienti tĂ« izoluar, por ky ambient nuk do tĂ« ketĂ« asnjĂ« kontakt me tĂ«. NĂ« fakt, ne do tĂ« kalojmĂ« pĂ«rmes kĂ«tyre katĂ«r grupeve problematike (pĂ«r disa mĂ« nĂ« detaje, pĂ«r disa mĂ« pak) dhe do tĂ« tregoj se çfarĂ« pĂ«rdorim, çfarĂ« kemi pĂ«rvojĂ« pĂ«rkatĂ«se nĂ« zgjidhje.
Eliminimi i problemeve: kur ndodhin dhe çfarë të bëjmë me to?
Por do tĂ« fillojmĂ« jo nga radhitja, do tĂ« fillojmĂ« nga pika â 2 â si tĂ« shpĂ«tojmĂ« shpejt nga problemi? Ka njĂ« problem â na duhet ta eliminojmĂ«. âĂfarĂ« tĂ« bĂ«jmĂ« me kĂ«tĂ«?â â Ă«shtĂ« pyetja kryesore. Dhe kur filluam tĂ« mendojmĂ« se si tĂ« eliminojmĂ« problemin, ne zhvilluam disa kĂ«rkesa qĂ« eliminimi i problemeve duhet tĂ« ndjekĂ«.
Për të formuluar këto kërkesa, ne vendosëm të pyesim veten: «Kur na ndodhin problemi?» Dhe problemet, siç u zbuluan, ndodhin në katër raste:
- Defekt i harduerit.
- Dështimi i shërbimeve të jashtme.
- Ndryshimi i versionit të softuerit (ai deploy-i i famshëm).
- Rritja eksplozive e ngarkesës.
PĂ«r dy tĂ« parat nuk do tĂ« flasim. Defekti i harduerit zgjidhet mjaft lehtĂ«: ju duhet tĂ« keni gjithçka tĂ« dyfishuar. NĂ«se janĂ« disku â disku duhet tĂ« jetĂ« i organizuar nĂ« RAID, nĂ«se Ă«shtĂ« server â serveri duhet tĂ« Ă«shtĂ« i dyfishuar, nĂ«se keni infrastrukturĂ« rrjetĂ« â duhet tĂ« vendosni njĂ« kopje tĂ« dytĂ« tĂ« infrastrukturĂ«s rrjetĂ«, domethĂ«nĂ« merrni dhe dyfishoni. Dhe nĂ«se diçka dĂ«shton, kaloni nĂ« kapacitetet rezervĂ«. KĂ«tu mĂ« shumĂ« tĂ« flasĂ«sh Ă«shtĂ« e vĂ«shtirĂ«.
E dyta â Ă«shtĂ« dĂ«shtimi i shĂ«rbimeve tĂ« jashtme. PĂ«r shumicĂ«n e sistemeve, kjo nĂ« fakt nuk Ă«shtĂ« njĂ« problem, por jo pĂ«r ne. Duke qenĂ« se ne procesojmĂ« pagesat, ne jemi njĂ« agregator qĂ« qĂ«ndron midis pĂ«rdoruesit (i cili fut tĂ« dhĂ«nat e tij tĂ« kartĂ«s) dhe bankave, sistemeve tĂ« pagesĂ«s («Visa», «MasterCard», «Mira» etj.). ShĂ«rbimeve tona tĂ« jashtme (sistemet e pagesĂ«s, bankat) u pĂ«lqen tĂ« dĂ«shtojnĂ«. As ne, as ju (nĂ«se keni shĂ«rbime tĂ« tilla) nuk mund tĂ« ndikoni nĂ« kĂ«tĂ«.
ĂfarĂ« tĂ« bĂ«jmĂ« atĂ«herĂ«? Ka dy mundĂ«si. E para, nĂ«se mundeni, duhet qĂ« ta dyfishoni kĂ«tĂ« shĂ«rbim nĂ« njĂ«farĂ« mĂ«nyre. PĂ«r shembull, ne, nĂ«se Ă«shtĂ« e mundur, ridrejtojmĂ« trafikun nga njĂ« shĂ«rbim nĂ« tjetrin: nĂ«se procesojmĂ«, pĂ«r shembull, karta pĂ«rmes «Sberbank», nĂ«se «Sberbank» ka probleme â ne e transferojmĂ« trafikun [nĂ« mĂ«nyrĂ« tĂ« kushtĂ«zuar] nĂ« «Raiffeisen». E dyta, ajo 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 reagimit nĂ« pjesĂ«n tjetĂ«r tĂ« raportit.
Faktikisht, nga kĂ«to katĂ«r, ne mund tĂ« ndikojmĂ« konkretisht nĂ« ndryshimin e versioneve tĂ« softuerit â tĂ« bĂ«jmĂ« veprime qĂ« do tĂ« çojnĂ« nĂ« pĂ«rmirĂ«simin e situatĂ«s nĂ« kontekstin e deploy-eve dhe nĂ« kontekstin e rritjes eksplozive tĂ« ngarkesĂ«s. NĂ« fakt, ne e bĂ«mĂ« kĂ«tĂ«. KĂ«tu, pĂ«rsĂ«ri, njĂ« shĂ«nim i vogĂ«lâŠ
Nga këto katër probleme, disa zgjidhen menjëherë, nëse keni cloud. Nëse jeni në cloud e «Microsoft Azure», «Ozon», përdorni cloud-et tona nga «Yandex» ose «Mail», atëherë të paktën defekti i harduerit bëhet problemi i tyre dhe ju menjëherë jeni mirë në kontekstin e defektit të harduerit.
Ne jemi njĂ« kompani pak sa jashtĂ«zakonisht. TĂ« gjithĂ« flasin pĂ«r «Kubernetes», pĂ«r cloud-et â ne nuk kemi as «Kubernetes», as cloud-e. Ne megjithatĂ« kemi raftet me harduer nĂ« shumĂ« qendra tĂ« tĂ« dhĂ«nave, dhe mbi kĂ«tĂ« harduer jemi tĂ« detyruar tĂ« jetojmĂ«, jemi tĂ« detyruar tĂ« pĂ«rgjigjemi pĂ«r tĂ« gjithĂ« kĂ«tĂ«. Prandaj nĂ« kĂ«tĂ« kontekst do tĂ« flasim. Pra, pĂ«r problemet. Dy tĂ« parat i kemi lĂ«nĂ« mĂ«njanĂ«.
Ndryshimi i versionit të softuerit. Baza
Ne zhvilluesit nuk kemi qasje në prodhimin. Pse kështu? Sepse ne jemi të certifikuar sipas PCI DSS, dhe zhvilluesit tanë nuk kanë të drejtë të futen në «prod». Të gjitha, pikë. Krejtësisht. Prandaj, përgjegjësia e zhvillimit përfundon në momentin kur zhvillimi transferon ndërtimin në lëshim.
Baza jonĂ« e dytĂ«, qĂ« kemi dhe qĂ« gjithashtu na ndihmon shumĂ« â Ă«shtĂ« se nuk ka njohur tĂ« veçanta tĂ« papĂ«rmendura. Shpresoj se e keni edhe ju. Sepse, nĂ«se nuk Ă«shtĂ« kĂ«shtu â do tĂ« keni probleme. Problemet do tĂ« ndodhin kur kĂ«to njohuri tĂ« veçanta tĂ« papĂ«rmendura nuk do tĂ« jenĂ« tĂ« pranishme nĂ« kohĂ«n e duhur dhe nĂ« vendin e duhur. Supozoni se njĂ« person di si tĂ« deployjĂ« njĂ« komponent tĂ« caktuar â personi nuk Ă«shtĂ«, ai Ă«shtĂ« nĂ« pushime ose Ă«shtĂ« i sĂ«murĂ« â gjithçka, keni probleme.
Dhe baza e tretĂ«, nĂ« tĂ« cilĂ«n arrivum. Ne e arritĂ«m atĂ« pĂ«rmes dhimbjes, gjakut, lotĂ«ve â ne e arritĂ«m atĂ« qĂ« çdo ndĂ«rtim ynĂ« pĂ«rmban gabime, madje edhe nĂ«se Ă«shtĂ« pa gabime. Ne pĂ«r vete e kemi vendosur: kur ne deplojmĂ« diçka, kur ne lĂ«shojmĂ« diçka nĂ« prod â ndĂ«rtimi ynĂ« ka gabime. Ne formuluam kĂ«rkesat qĂ« sistemi ynĂ« duhet tĂ« plotĂ«sojĂ«.
Kërkesat për ndërrimin e versionit të softuerit
Këto kërkesa janë tri:
- Duhet të jemi në gjendje të kthejmë shpejt deploy-in.
- Duhet të minimizojmë ndikimin e një deploy-i të pasuksesshëm.
- Dhe duhet të kemi mundësi të deplojmë paralelisht shpejt.
SaktĂ«sisht nĂ« kĂ«tĂ« rend! Pse? Sepse, nĂ« radhĂ« tĂ« parĂ«, nĂ« momentin e deploimit tĂ« njĂ« versioni tĂ« ri, shpejtĂ«sia nuk ka rĂ«ndĂ«si, por Ă«shtĂ« e rĂ«ndĂ«sishme, nĂ«se diçka shkon keq, tĂ« ktheheni shpejt dhe tĂ« ndikoni sa mĂ« pak. Por, nĂ«se keni njĂ« grup versionesh nĂ« prodhimin, pĂ«r tĂ« cilat Ă«shtĂ« zbuluar se ka njĂ« gabim (si bora mbi kokĂ«, nuk ka pasur deploy, por gabimi Ă«shtĂ« aty) â pĂ«r ju Ă«shtĂ« e rĂ«ndĂ«sishme shpejtĂ«sia e deploy-it pasues. ĂfarĂ« kemi bĂ«rĂ« pĂ«r tĂ« pĂ«rmbushur kĂ«to kĂ«rkesa? Ne e kemi pĂ«rdorur njĂ« metodologji tĂ« tillĂ«:
Ajo Ă«shtĂ« mjaft e njohur, ne nuk e kemi shpikur kurrĂ« â ky Ă«shtĂ« Blue/Green deploy. ĂfarĂ« Ă«shtĂ« kjo? Ju duhet tĂ« keni njĂ« kopje pĂ«r secilĂ«n grup serverĂ«sh, ku qĂ«ndrojnĂ« aplikacionet tuaja. Kjo kopje Ă«shtĂ« "e ngrohtĂ«": nuk ka trafik, por nĂ« çdo moment ky trafik mund tĂ« dĂ«rgohet atje. Kjo kopje pĂ«rmban versionin e mĂ«parshĂ«m. NĂ« momentin e deploimit, ju e nxirrni kodin nĂ« kopjen joaktive. Pastaj, ndĂ«rroni njĂ« pjesĂ« tĂ« trafikut (ose tĂ« gjithĂ«) nĂ« versionin e ri. Pra, pĂ«r tĂ« ndryshuar rrjedhĂ«n e trafikut nga versioni i vjetĂ«r nĂ« versionin e ri, ju duhet tĂ« bĂ«ni vetĂ«m njĂ« veprim: duhet tĂ« ndryshoni balancuesin nĂ« upstream, tĂ« ndryshoni drejtimin â nga njĂ« upstream nĂ« tjetrin. Kjo Ă«shtĂ« shumĂ« e pĂ«rshtatshme dhe zgjidh problemin e ndĂ«rprerjes sĂ« shpejtĂ«, kthimit tĂ« shpejtĂ«.KĂ«tu Ă«shtĂ« zgjidhja e pyetjes sĂ« dytĂ« â minimizimi: ju mund tĂ« dĂ«rgoni vetĂ«m njĂ« pjesĂ« tĂ« trafikut tuaj nĂ« linjĂ«n e re, nĂ« linjĂ«n me kodin e ri (le tĂ« themi, pĂ«r shembull, 2%). Dhe kĂ«to 2% â nuk janĂ« 100%! NĂ«se ju humbni 100% tĂ« trafikut gjatĂ« njĂ« deploimi tĂ« dĂ«shtuar - kjo Ă«shtĂ« tmerrshme, nĂ«se ju humbni 2% tĂ« trafikut - kjo Ă«shtĂ« e pakĂ«ndshme, por nuk Ă«shtĂ« e tmerrshme. PĂ«r mĂ« tepĂ«r, pĂ«rdoruesit ndoshta as qĂ« do ta vĂ«rejnĂ« kĂ«tĂ«, sepse nĂ« disa raste (jo nĂ« tĂ« gjitha) njĂ« pĂ«rdorues i njĂ«jtĂ«, duke shtypur F5, ai do tĂ« kalojĂ« nĂ« njĂ« version tjetĂ«r qĂ« funksionon.
Blue/Green deploy. Rrugëzimi
Megjithatë, nuk është gjithçka kaq e thjeshtë "Blyu/Grin deploy"... Të gjithë komponentët tanë mund të ndahen në tri grupe:
- ky është frontend (faqet e pagesave që shohin klientët tanë);
- në bërthamën e përpunimit;
- adapter pĂ«r tĂ« punuar me sistemet e pagesave (bankat, "MasterCard", "Visa"âŠ).
Dhe kĂ«tu ka njĂ« nuancĂ« â nuanca qĂ«ndron nĂ« rrugĂ«timin midis linjave. NĂ«se thjesht ndĂ«rroni 100% tĂ« trafikut, nuk keni kĂ«to probleme. Por nĂ«se dĂ«shiron tĂ« kalosh 2%, fillon pyetja: "Si ta bĂ«j kĂ«tĂ«?" MĂ« e thjeshta, nĂ« mĂ«nyrĂ« tĂ« drejtpĂ«rdrejtĂ«: ju mund tĂ« pĂ«rdorni njĂ« rastim tĂ« rastĂ«sishĂ«m, Round Robin nĂ« Nginx dhe ju keni 2% â nĂ« tĂ« majtĂ«, 98% â nĂ« tĂ« djathtĂ«. Por kjo nuk Ă«shtĂ« gjithmonĂ« e pĂ«rshtatshme.
PĂ«r ne, pĂ«r shembull, pĂ«rdoruesi ndĂ«rvepron me sistemin jo me njĂ« kĂ«rkesĂ«. Kjo Ă«shtĂ« normale: 2, 3, 4, 5 kĂ«rkesa â sistemi juaj mund tĂ« jetĂ« njĂ«lloj. Dhe nĂ«se Ă«shtĂ« e rĂ«ndĂ«sishme qĂ« tĂ« gjitha kĂ«rkesat e pĂ«rdoruesit tĂ« shkojnĂ« 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Ă« shkojnĂ« nĂ« linjĂ«n e re pas kalimit (ai mund tĂ« kishte filluar tĂ« punonte mĂ« parĂ« me sistemin, para kalimit) â atĂ«herĂ« ndarja rastĂ«sore nuk ju pĂ«rshtatet. Ndaj ka mundĂ«si tĂ« tjera:
MundĂ«sia e parĂ«, mĂ« e thjeshtĂ« â mbi bazĂ«n e parametrave bazĂ« tĂ« klientit (IP Hash). Ju keni IP-nĂ«, dhe ju e ndani nĂ« tĂ« djathtĂ«- nĂ« tĂ« majtĂ«. KĂ«shtu, do tĂ« funksionojĂ« rasti i dytĂ« i pĂ«rshkruar nga unĂ«, kur ndodhi deploimi, pĂ«rdoruesi mund tĂ« kishte filluar tĂ« punonte me sistemin tuaj, dhe nga momenti i deploimit tĂ« gjitha kĂ«rkesat do tĂ« shkojnĂ« nĂ« linjĂ«n e re (nĂ« tĂ« njĂ«jtĂ«n, tĂ« themi).NĂ«se pĂ«r ndonjĂ« arsye kjo nuk ju pĂ«rshtatet dhe ju duhet me patjetĂ«r tĂ« dĂ«rgoni kĂ«rkesat nĂ« linjĂ«n, ku erdhi kĂ«rkesa e parĂ«, atĂ«herĂ« keni dy mundĂ«si...
MundĂ«sia e parĂ«: ju mund tĂ« merrni Nginx+. Atje ka njĂ« mekanizĂ«m Sticky sessions, i cili gjatĂ« kĂ«rkesĂ«s fillestare tĂ« pĂ«rdoruesit vendos njĂ« sesion pĂ«r pĂ«rdoruesin dhe e lidh atĂ« me upstream-in e caktuar. TĂ« gjitha kĂ«rkesat e mĂ«tejshme tĂ« pĂ«rdoruesit nĂ« kuadĂ«r tĂ« jetĂ«s sĂ« sesionit do tĂ« dĂ«rgohen nĂ« tĂ« njĂ«jtin upstream, ku u vendos sesioni.Kjo nuk na pĂ«rshtati, sepse ne kishim Nginx tĂ« zakonshĂ«m. Kalimi nĂ« Nginx+ â nuk Ă«shtĂ« se Ă«shtĂ« i shtrenjtĂ«, thjesht pĂ«r ne ishte disi i dhimbshĂ«m dhe jo shumĂ« i drejtĂ«. "Sticky sessions" pĂ«r ne, pĂ«r shembull, nuk funksionuan pĂ«r shkakun e thjeshtĂ« se "Sticky sessions" nuk japin mundĂ«sinĂ« e rrugĂ«timit sipas kriterit "Ose-Ose". Atje mund tĂ« caktoni se ne bĂ«jmĂ« "Sticky sessions", pĂ«r shembull, sipas IP adresĂ«s ose sipas IP adresĂ«s dhe cookie-Ă«ve ose parametrave tĂ« postĂ«s, por "Ose-Ose" - atje Ă«shtĂ« mĂ« e komplikuar.
Prandaj, arritĂ«m nĂ« mundĂ«sinĂ« e katĂ«rt. Ne morĂ«m Nginx nĂ« "steroide" (kjo Ă«shtĂ« OpenResty) â ky Ă«shtĂ« Nginx i njĂ«jtĂ«, i cili mbĂ«shtet gjithashtu pĂ«rfshirjen e skripteve last. Ju mund tĂ« shkruani njĂ« skript last, t'ia jepni kĂ«tij "oprenresti", dhe ky skript last do tĂ« ekzekutohet kur tĂ« ardhĂ« kĂ«rkesa e pĂ«rdoruesit.
Dhe ne shkruam, në fakt, një skript të tillë, instaluam "openresty" dhe në këtë skript kalojmë përmes 6 parametrave të ndryshëm mbi bashkimin "Ose". Në varësi të disponimit të atij ose atij parametri, ne e dimë nëse përdoruesi erdhi në një faqe ose një tjetër, në një linjë ose në një tjetër.
Blue/Green deploy. Avantazhet dhe disavantazhet
Sigurisht, do të kishim mundur ta bënim ndoshta pak më thjesht (të përdornim ata "Sticky sessions"), por kemi edhe një aspekt tjetër, që me ne nuk interakton vetëm një përdorues në kuadër të një procesi një transaksioni⊠Por edhe me ne interaktojnë sistemet e pagesave: ne, pasi procesojmë transaksionin (duke dërguar një kërkesë në sistemin e pagesës), marrim një callback.
Le tĂ« themi se, brenda konturit tonĂ« mund tĂ« kalojmĂ« IP-nĂ« e pĂ«rdoruesit nĂ« tĂ« gjitha kĂ«rkesat dhe nĂ« bazĂ« tĂ« IP-sĂ« sĂ« pĂ«rdoruesve tĂ« ndajmĂ«, nuk do tâi themi tĂ« njĂ«jtĂ«s "Visa": "Djem, ne jemi njĂ« kompani retro, duket qĂ« jemi ndĂ«rkombĂ«tarĂ« (nĂ« faqe dhe nĂ« Rusi)⊠A mund tĂ« na dĂ«rgoni, ju lutem, IP-nĂ« e pĂ«rdoruesit si njĂ« fushĂ« shtesĂ«, protokolli juaj Ă«shtĂ« standardizuar"! E qartĂ«, ata nuk do tĂ« pranojnĂ«.
Prandaj pĂ«r ne kjo nuk ishte e pĂ«rshtatshme â ne bĂ«mĂ« openresty. Si rezultat, me routing na doli kĂ«shtu:BashkĂ«ngjitja "Blue/Green deploy" ka, pĂ«rkatĂ«sisht, pĂ«rfitime, pĂ«r tĂ« cilat flas, dhe disavantazhe.
Ka dy disavantazhe:
- duhet të shqetësoheni për routing;
- disavantazhi i dytë kryesor është shpenzimet.
Ju nevojiten dy herë më shumë serverë, ju nevojiten dy herë më shumë burime operacionale, ju nevojitet të investoni dy herë më shumë përpjekje për të mbështetur gjith këtë kafaz.
PĂ«r mĂ« tepĂ«r, midis pĂ«rfitimeve â ka edhe njĂ« gjĂ«, pĂ«r tĂ« cilĂ«n nuk kam folur mĂ« parĂ«: keni rezervĂ« nĂ« rastin e rritjes sĂ« ngarkesĂ«s. NĂ«se keni njĂ« rritje eksplozive tĂ« ngarkesĂ«s, nĂ«se ju sulmojnĂ« njĂ« numĂ«r i madh pĂ«rdoruesish, thjesht aktivizoni njĂ« linjĂ« tjetĂ«r nĂ« shpĂ«rndarjen 50 me 50 â dhe menjĂ«herĂ« keni dyfish serverĂ« nĂ« klasterin tuaj, derisa tĂ« zgjidhni problemin me disponueshmĂ«rinĂ« e serverĂ«ve.
Si të bëni një deploy të shpejtë?
Folem për si të zgjidhim problemin e minimizimit dhe rikthimit të shpejtë, por pyetja mbetet: "Si të bëjmë deploy shpejt"?
KĂ«tu Ă«shtĂ« shkurtimisht dhe gjithçka Ă«shtĂ« e thjeshtĂ«.- Duhet tĂ« keni njĂ« sistem CD (Continuous Delivery) â pa tĂ« nuk ka ku tĂ« shkojĂ«. NĂ«se keni njĂ« server, mund tĂ« bĂ«ni deploy manualisht. Ne kemi rreth njĂ« mijĂ« e pesĂ«qind serverĂ« dhe duke bĂ«rĂ« manualisht njĂ« mijĂ« e pesĂ«qind, natyrisht â mund tĂ« angazhojmĂ« njĂ« departament me madhĂ«si si kjo sallĂ«, vetĂ«m pĂ«r tĂ« bĂ«rĂ« deploy.
- Deploy duhet tĂ« jetĂ« paralel. NĂ«se deploy Ă«shtĂ« sekondar, atĂ«herĂ« gjithçka Ă«shtĂ« keq. NjĂ« server â Ă«shtĂ« nĂ« rregull, njĂ« mijĂ« e pesĂ«qind serverĂ« do tâi bĂ«ni deploy gjithĂ« ditĂ«n.
- PĂ«rsĂ«ri, pĂ«r tĂ« pĂ«rshpejtuar, kjo Ă«shtĂ« ndoshta e tepĂ«rt. GjatĂ« deploy-it zakonisht bĂ«het ndĂ«rtimi i projektit. Keni njĂ« projekt web, keni njĂ« pjesĂ« frontend (e bĂ«ni webpack, bĂ«ni npm build â diçka e tillĂ«), dhe ky proces Ă«shtĂ« zakonisht i shkurtĂ«r â rreth 5 minuta, por kĂ«to 5 minuta mund tĂ« jenĂ« kritike. Prandaj ne, pĂ«r shembull, nuk e bĂ«jmĂ« kĂ«shtu: ato 5 minuta i heqim, ne bĂ«jmĂ« deploy tĂ« artefakteve.
ĂfarĂ« Ă«shtĂ« njĂ« artefakt? Artefakti Ă«shtĂ« ndĂ«rtimi i pĂ«rfunduar, nĂ« tĂ« cilin Ă«shtĂ« bĂ«rĂ« gjithĂ« procesi i ndĂ«rtimit. Ky artefakt e ruajmĂ« nĂ« njĂ« depo artefaktesh. Ne kemi pĂ«rdorur dy depo tĂ« tilla nĂ« kohĂ«n tonĂ« â ishte Nexus dhe tani jFrog Artifactory). "Nexus" e kemi pĂ«rdorur fillimisht sepse filluam tĂ« praktikojmĂ« kĂ«tĂ« qasje nĂ« aplikacionet java (ai ishte i pĂ«rshtatshĂ«m pĂ«r tĂ«). Pastaj aty vendosĂ«m disa aplikacione qĂ« ishin shkruar nĂ« PHP; dhe "Nexus" tashmĂ« nuk ishte i pĂ«rshtatshĂ«m, prandaj zgjodhĂ«m jFrog Artifactory, i cili Ă«shtĂ« nĂ« gjendje tĂ« ruajĂ« praktikisht gjithçka. ArritĂ«m madje nĂ« atĂ« pikĂ«, sa nĂ« kĂ«tĂ« depo artefaktesh ruajmĂ« paketat tona binare, tĂ« cilat i ndĂ«rtojmĂ« pĂ«r serverĂ«t.
Rritje eksplozive e ngarkesës
Folem pĂ«r ndĂ«rrimin e versionit tĂ« softuerit. E ardhshmja qĂ« kemi Ă«shtĂ« njĂ« rritje eksplozive e ngarkesĂ«s. KĂ«tu ndoshta e kuptoj nĂ«n rritje eksplozive tĂ« ngarkesĂ«s njĂ« gjĂ« qĂ« nuk Ă«shtĂ« plotĂ«sisht e saktĂ«âŠ
Kemi shkruar njĂ« sistem tĂ« ri â ai Ă«shtĂ« me shĂ«rbim, modern dhe i bukur, gjithandej ka punonjĂ«s, gjithandej ka radhĂ«, gjithandej ka asinkronitet. Dhe nĂ« kĂ«to sisteme tĂ« dhĂ«nat mund tĂ« kalojnĂ« nĂ« rrugĂ« tĂ« ndryshme. PĂ«r transaksionin e parĂ« mund tĂ« pĂ«rdoren punonjĂ«sit 1, 3, 10; pĂ«r transaksionin e dytĂ« â 2, 4, 5. Dhe sot, pĂ«r shembull, nĂ« mĂ«ngjes keni njĂ« rrjedhĂ« tĂ« tĂ« dhĂ«nave qĂ« aktivizon tre punonjĂ«sit e parĂ«, ndĂ«rsa nĂ« mbrĂ«mje papritur ndryshon dhe gjithçka aktivizon tre punonjĂ«s tĂ« tjerĂ«.
Dhe këtu del se ju nevojitet të skaloni punonjësit në një mënyrë, ju nevojitet të skaloni shërbimet tuaja, por pa lejuar zbardhjen e burimeve.
Ne definuam kĂ«rkesat pĂ«r veten. KĂ«to kĂ«rkesa janĂ« mjaft tĂ« thjeshta: qĂ« tĂ« ketĂ« zbuluar shĂ«rbim, parametrizim â gjithçka standarde pĂ«r ndĂ«rtimin e sistemeve tĂ« tilla tĂ« shkallĂ«zuara, pĂ«rveç njĂ« pike â amortizimi i burimeve. Ne thamĂ« se nuk jemi tĂ« gatshĂ«m tĂ« amortizojmĂ« burimet, pĂ«r tĂ« lĂ«nĂ« serverĂ«t qĂ« tĂ« ngrohin ajrin. MorĂ«m "Consul", morĂ«m "Nomad", i cili menaxhon punonjĂ«sit tanĂ«.Pse pĂ«r ne Ă«shtĂ« njĂ« problem? Le tĂ« kthehemi pak prapa. Tani na mbĂ«shtetet rreth 70 sisteme pagese. NĂ« mĂ«ngjes, trafiku kalon pĂ«rmes "Sberbank", pastaj "Sberbank" ka rĂ«nĂ«, pĂ«r shembull, dhe ne e kalojmĂ« nĂ« njĂ« sistem tjetĂ«r pagese. Kishim 100 punĂ«torĂ« pĂ«rpara "Sberbank", dhe pas kĂ«saj duhet tĂ« rrisim menjĂ«herĂ« 100 punĂ«torĂ« pĂ«r sistemin tjetĂ«r tĂ« pagesĂ«s. Dhe gjithçka ka dĂ«shirĂ« tĂ« ndodhĂ« pa pjesĂ«marrje njerĂ«zore. Sepse, nĂ«se ka pjesĂ«marrje njerĂ«zore â njĂ« inxhinier duhet tĂ« ulet 24/7 dhe tĂ« merret vetĂ«m me kĂ«tĂ«, sepse dĂ«shtime tĂ« tilla ndodhin rregullisht kur ke 70 sisteme prapa teje.
Prandaj ne shikojmĂ« nĂ« "Nomad", i cili ka njĂ« IP tĂ« hapur dhe shkruam gjĂ«rĂ«n tonĂ« Scale-Nomad â ScaleNo, e cila bĂ«n mĂ« ose mĂ« pak gjĂ«ra tĂ« tilla: monitoron rritjen e radhĂ«s dhe zvogĂ«lon ose rrit numrin e punĂ«torĂ«ve nĂ« varĂ«si tĂ« dinamikĂ«s sĂ« ndryshimit tĂ« radhĂ«s. Kur e pĂ«rfunduam, menduam: "Ndoshta ta hapim kĂ«tĂ«?" Pastaj e shikuam atĂ« â Ă«shtĂ« e thjeshtĂ« si dy qindarka.
PĂ«r momentin nuk e kemi hapur, por nĂ«se ndoshta pas prezantimit tuaj, pas kuptimit se keni nevojĂ« pĂ«r njĂ« gjĂ« tĂ« tillĂ«, do tĂ« keni nevojĂ« pĂ«r tĂ«, nĂ« slajdin e fundit janĂ« kontaktet e mia â mĂ« shkruani, ju lutem. NĂ«se mbledhim tĂ« paktĂ«n 3-5 persona â ne do ta hapim atĂ«.
Si funksionon kjo? Le tĂ« shohim! NĂ« mĂ«nyrĂ« tĂ« shpejtĂ«: nĂ« anĂ«n e majtĂ« Ă«shtĂ« njĂ« pjesĂ« e monitorimit tonĂ«: kjo Ă«shtĂ« njĂ« linjĂ«, nĂ« krye â koha e pĂ«rpunimit tĂ« ngjarjeve, nĂ« mes â numri i transaksioneve, nĂ« fund â numri i punĂ«torĂ«ve.NĂ«se shikoni, nĂ« kĂ«tĂ« pamje ka njĂ« dĂ«shtim. NĂ« grafikĂ«n e sipĂ«rme, njĂ« nga grafikĂ«t dĂ«shtoi pĂ«r 45 sekonda â njĂ« nga sistemet e pagesave ra. MenjĂ«herĂ« u paraqit trafiku pĂ«r 2 minuta dhe filloi rritja e radhĂ«s nĂ« njĂ« sistem tjetĂ«r pagese, ku nuk kishte punĂ«torĂ« (ne nuk po shfrytĂ«zonim burimet â pĂ«rkundrazi, po shfrytĂ«zonim burimin nĂ« mĂ«nyrĂ« tĂ« saktĂ«). Nuk donim tĂ« ngroheshim â aty ishte njĂ« numĂ«r minimal, rreth 5-10 punĂ«torĂ«, por ata nuk e pĂ«rballuan.
NĂ« grafikĂ«n e fundit duket "kumbari", i cili tregon se "Sskaleno" e ngriti kĂ«tĂ« numĂ«r dyfish. Dhe pastaj, kur grafiku paksa u ul, ai e zvogĂ«loi pak â numri i punĂ«torĂ«ve u ndryshua nĂ« mĂ«nyrĂ« automatike. KĂ«shtu funksionon kjo gjĂ«. Diskutuam mbi pikĂ«n e dytĂ« â "Si tĂ« shpĂ«tojmĂ« shpejt nga shkaktarĂ«t?"
Monitorimi. Si të identifikojmë shpejt problemin?
Tani pika e parĂ« â "Si tĂ« identifikojmĂ« shpejt problemin?" Monitorimi! Ne duhet tĂ« kuptojmĂ« shpejt disa gjĂ«ra. Cilat gjĂ«ra duhet tĂ« kuptojmĂ« shpejt?
Tre gjëra!- Ne duhet të kuptojmë shpejt dhe në mënyrë të qartë funksionimin e burimeve tona.
- Ne duhet të kuptojmë shpejt dështimet, të monitorojmë funksionimin e sistemeve që janë të jashtme për ne.
- Pika e tretĂ« â identifikimi i gabimeve logjike. Kjo Ă«shtĂ« kur sistemi funksionon pĂ«r ju, sipas tĂ« gjitha treguesve gjithçka Ă«shtĂ« nĂ« rregull, por ndodh diçka jo siç duhet.
Këtu ndoshta nuk do të them shumë gjëra interesante. Do të jem kapiteni i Shkallës. Ne kërkuam se çfarë ka në treg. Na rezultoi një "zoo e gëzueshme". Këtu është zoo e tillë që kemi tani:
Ne pĂ«rdorim "Zabbix" pĂ«r monitorimin e "harduerit", pĂ«r monitorimin e treguesve kryesorĂ« tĂ« serverĂ«ve. "Okmeter" e pĂ«rdorim pĂ«r bazat e tĂ« dhĂ«nave. "Grafana" dhe "Prometheus" i pĂ«rdorim pĂ«r tĂ« gjitha treguesit e tjerĂ«, qĂ« nuk i pĂ«rputhen dy tĂ« parĂ«ve, dhe njĂ« pjesĂ« â me "GrafanĂ«n" dhe "Prometheusin", njĂ« pjesĂ« â "Grafana" me "Influx" dhe Telegraf.NjĂ« vit mĂ« parĂ« ne donim tĂ« pĂ«rdornim New Relic. NjĂ« gjĂ« e shkĂ«lqyer, ajo di çdo gjĂ«. Por sa mĂ« shumĂ« di, aq mĂ« e shtrenjtĂ« Ă«shtĂ«. Kur u rritĂ«m nĂ« 1,500 serverĂ«, na erdhi njĂ« shitĂ«s dhe tha: "Le tĂ« nĂ«nshkruajmĂ« njĂ« marrĂ«veshje pĂ«r vitin tjetĂ«r". Ne shikuam çmimin dhe u thamĂ« se jo, nuk do ta bĂ«jmĂ« atĂ«. Tani po heqim dorĂ« nga "New Relic", kemi rreth 15 serverĂ« qĂ« kanĂ« mbetur nĂ«n monitorimin e "New Relic". Ămimi doli tĂ« ishte krejtĂ«sisht i çmendur.
Dhe ka njĂ« mjet qĂ« ne e realizuam vetĂ« â Ă«shtĂ« Debugger. Fillimisht e quajtĂ«m "Bagger", por pastaj na kaloi njĂ« mĂ«sues anglishte dhe qeshi shumĂ«, dhe e ndryshuam emrin nĂ« "Debugger". ĂfarĂ« Ă«shtĂ« kjo? Ky Ă«shtĂ« njĂ« instrument, i cili nĂ« fakt nĂ« 15-30 sekonda nĂ« çdo komponent, si "kutia e zezĂ«" e sistemit, ekzekuton teste pĂ«r funksionimin e pĂ«rgjithshĂ«m tĂ« komponentĂ«s.
PĂ«r shembull, nĂ«se Ă«shtĂ« njĂ« faqe e jashtme (faqja e pagesĂ«s) â thjesht e hap dhe sheh si duhet tĂ« duket. NĂ«se Ă«shtĂ« procesimi, ai dĂ«rgon njĂ« "transak" testues â sheh qĂ« kjo "transak" Ă«shtĂ« dorĂ«zuar. NĂ«se Ă«shtĂ« lidhja me sistemet e pagesĂ«s â ne pĂ«rkatĂ«sisht dĂ«rgojmĂ« njĂ« kĂ«rkesĂ« testuese, ku mundemi, dhe shohim qĂ« gjithçka Ă«shtĂ« mirĂ«.
Cilat janë treguesit e rëndësishëm për monitorim?
ĂfarĂ« monitorojmĂ« kryesisht? Cilat tregues janĂ« tĂ« rĂ«ndĂ«sishĂ«m pĂ«r ne?
- Koha e përgjigjes / RPS në fronte - është një tregues shumë i rëndësishëm. Ai tregon menjëherë nëse diçka nuk shkon si duhet.
- Numri i mesazheve të procesuar në të gjitha radhët.
- Numri i punëtorëve.
- Treguesit kryesorë të saktësisë.
Pika e fundit - është treguesi 'biznesor'. Nëse dëshironi të monitoroni të njëjtin informacion, duhet të përcaktoni një deri në dy tregues që janë thelbësorë për ju. Për ne, ky tregues është kalueshmëria (raporti i numrit të transaksioneve të suksesshme ndaj totalit të fluksit të transaksioneve). Nëse ndodhin ndryshime në intervale prej 5-10-15 minutash - do të thotë se kemi probleme (nëse ndodhin ndryshime të rëndësishme).
Si duket kjo për ne - shembulli i një nga bordet tona:
Në anën e majtë - 6 grafikë, përkatësisht në lidhje me linjat - numri i punëtorëve dhe numri i mesazheve në radhë. Në anën e djathtë - RPS, RTS. Në fund - ai tregues 'biznesor'. Dhe në treguesin 'biznesor' ne menjëherë shohim se diçka nuk po shkon mirë në dy grafikët e mesëm... Kjo është ndryshe, sistemi i radhës që qëndron prapa nesh ra.E dyta, që na duhej të bënim - ishte të monitoronim rënien e sistemeve të pagesave të jashtme. Këtu morëm OpenTracing - mekanizmi, standardi, paradigma që lejon të monitorosh sistemet e shpërndara; dhe e kemi modifikuar pak. Parimi standard i OpenTracing thotë se ne ndërtojmë një gjurmim për secilën kërkesë të veçantë. Kështu që për ne nuk ishte e nevojshme, dhe e kemi kthyer në një gjurmim të përbashkët, agregues. Krijuam një mjet që na lejon të ndjekim shpejtësinë e sistemeve që qëndrojnë pas nesh.
Grafiku na tregon se një nga sistemet e pagesave filloi të përgjigjet pas 3 sekondash - kemi ndonjë problem. Në të njëjtën kohë, ky mjet reagon kur problemet fillojnë, në një interval prej 20-30 sekondash.Dhe klasa e tretë e gabimeve të monitorimit që ekziston - është monitorimi logjik.
Sinqerisht, nuk e dija çfarë të vizatoja në këtë slaid, sepse kërkuam gjatë në treg për atë që do të na përshtatej. Nuk gjetëm asgjë, prandaj na duhej të bënim vetë.
ĂfarĂ« kuptoj me monitorimin logjik? Imagjinoni se krijoni njĂ« sistem pĂ«r veten tuaj (pĂ«r shembull, njĂ« klon tĂ« 'Tinderit'); e keni realizuar dhe e keni lançuar. Menaxheri i suksesshĂ«m Vasya Pupkin e instalon nĂ« telefonin e tij, sheh njĂ« vajzĂ«, e like-on⊠por like-i shkon tek roji Mikhaili nga i njĂ«jti qendĂ«r biznesi. Menaxheri zbret poshtĂ«, dhe pastaj habitĂ«t: 'Pse ky roji Mikhail mĂ« buzĂ«qesh kaq shumĂ«'?NĂ« situata tĂ« tilla... PĂ«r ne kjo situatĂ« tingĂ«llon disi ndryshe, sepse (siç kam shkruar) Ă«shtĂ« njĂ« humbje reputacioni, qĂ« qoftĂ« drejtpĂ«rdrejt çon nĂ« humbje financiare. NĂ« rastin tonĂ«, situata Ă«shtĂ« e kundĂ«rt: ne mund tĂ« pĂ«sojmĂ« humbje financiare tĂ« drejtpĂ«rdrejta - pĂ«r shembull, nĂ«se e kemi kryer njĂ« transaksion si tĂ« suksesshĂ«m, por ishte dĂ«shtim (ose anasjelltas). Duhej tĂ« shkruaja njĂ« mjet tĂ« vetin, qĂ« monitoron numrin e transaksioneve tĂ« suksesshme nĂ« dinamikĂ« mbi njĂ« interval kohor. Nuk gjetĂ«m asgjĂ« nĂ« treg! Kjo Ă«shtĂ« pikĂ«risht ideja qĂ« doja tĂ« shprehja. PĂ«r zgjidhjen e kĂ«tij lloji problemesh, nĂ« treg nuk ka asgjĂ«.
Kjo ishte për pyetjen se si të identifikoni shpejt problemin.
Si të përcaktoni shkaqet e depolimit
Grupi i tretë i detyrave që ne zgjidhim - është pasi kemi identifikuar problemin, pasi e kemi eliminur, do të ishte mirë të kuptonim shkakun për zhvillimin, testimin dhe të bëjmë diçka në lidhje me këtë. Prandaj, na nevojitet të studiojmë, të ngremë logjet.
Nëse flasim për logjet (shkaku kryesor - logjet), pjesa më e madhe e logjeve tona janë në ELK Stack - pothuajse të gjithë e kanë kështu. Disa ndoshta jo në ELK, por nëse shkruani logje me gigabajt, përherë do të arrini te ELK. Ne i shkruajmë ato me terabajt.
KĂ«tu ka njĂ« problem. Ne e rregulluam, e korrigjuam gabimin pĂ«r pĂ«rdoruesin, filluam tĂ« thellohemi nĂ« atĂ« qĂ« ndodhi, hyjmĂ« nĂ« 'Kibana', shkruajmĂ« id-nĂ« e transaksionit dhe marrim njĂ« raport tĂ« tillĂ« (tregon shumĂ«). Dhe nĂ« kĂ«tĂ« raport nuk kuptohet asgjĂ«. Pse? Sepse nuk Ă«shtĂ« e qartĂ« se cila pjesĂ« i pĂ«rket cilit punĂ«tor, cila pjesĂ« i pĂ«rket cilit komponent. Dhe nĂ« atĂ« moment kuptuam se na duhej gjurmimi - i njĂ«jti OpenTracing, pĂ«r tĂ« cilin flas.Menduam se pĂ«r kĂ«tĂ« vit mĂ« parĂ«, i kthyem sytĂ« nga tregu, dhe atje u shfaqĂ«n dy mjete â «Zipkin» dhe «Jaeger». «Jaeger» Ă«shtĂ« nĂ« fakt njĂ« trashĂ«gimtar ideologjik, njĂ« vazhdimĂ«si ideologjike e «Zipkin». NĂ« «Zipkin» gjithçka Ă«shtĂ« mirĂ«, pĂ«rveç se ai nuk di tĂ« grubulojĂ«, nuk di tĂ« pĂ«rfshijĂ« log-et nĂ« gjurmim, vetĂ«m gjurmim kohor. NdĂ«rsa «Jaeger» e mbĂ«shtet kĂ«tĂ«.
ShikojmĂ« nĂ« «Jaeger»: mund tĂ« instrumentojmĂ« aplikacionet, mund tĂ« shkruajmĂ« nĂ« Api (standardi Api pĂ«r PHP nĂ« atĂ« kohĂ«, megjithatĂ«, nuk ishte miratuar â ishte njĂ« vit mĂ« parĂ«, tani Ă«shtĂ« miratuar), asnjĂ« klient nuk kishte ekzistuar. «Mirë», menduam, dhe shkruam klientin tonĂ« tĂ« vet. ĂfarĂ« kemi arritur? KĂ«shtu duket nĂ« pĂ«rgjithĂ«si:
NĂ« «Jaeger» pĂ«r çdo mesazh krijohen spanâe. Pra, kur pĂ«rdoruesi hap sistemin, ai sheh njĂ« ose dy blloqe pĂ«r çdo kĂ«rkesĂ« hyrĂ«se (1-2-3 â sa mĂ« shumĂ« janĂ« kĂ«rkesat hyrĂ«se nga pĂ«rdoruesi, aq mĂ« shumĂ« blloqe). PĂ«r ta bĂ«rĂ« mĂ« tĂ« lehtĂ« pĂ«r pĂ«rdoruesit, nĂ« log-e dhe gjurmimin kohor kemi shtuar etiketa. NĂ« rast tĂ« njĂ« gabimi, aplikacioni ynĂ« do ta etiketojĂ« log-un me etiketĂ«n pĂ«rkatĂ«se Error. Mund tĂ« filtroni sipas etiketĂ«s Error dhe do tĂ« shfaqen vetĂ«m spanâĂ«t qĂ« pĂ«rmbajnĂ« kĂ«tĂ« blok me gabim. KĂ«shtu duket, nĂ«se ne zhvillojmĂ« span:
Brenda spanit ka njĂ« grup trajtesh. NĂ« kĂ«tĂ« rast janĂ« tri trajta testuese, dhe trajta e tretĂ« na tregon se ka ndodhur njĂ« gabim. NĂ« tĂ« njĂ«jtĂ«n kohĂ« kĂ«tu ne shohim gjurmimin kohor: lart â njĂ« shkallĂ« kohore, dhe ne shohim se nĂ« cilin interval kohor Ă«shtĂ« regjistruar log-u pĂ«rkatĂ«s.PĂ«rkatĂ«sisht, na shkoi shumĂ« mirĂ«. Kemi shkruar njĂ« shtesĂ« tonĂ«, dhe e kemi bĂ«rĂ« open source. NĂ«se dĂ«shironi tĂ« punoni me gjurmimin, nĂ«se dĂ«shironi tĂ« punoni me «Jaeger» nĂ« gjuhĂ«n PHP â kemi shtesĂ«n tonĂ«, mirĂ« se vini ta pĂ«rdorni, siç thonĂ«:
Kjo shtesĂ« jonĂ« Ă«shtĂ« njĂ« klient pĂ«r tĂ« punuar me OpenTracing Api, Ă«shtĂ« bĂ«rĂ« si php-extention, pra ju do ta duhet ta ndĂ«rroni dhe ta shtoni nĂ« sistem. NjĂ« vit mĂ« parĂ« nuk kishte asgjĂ« tjetĂ«r. Tani kanĂ« dalĂ« edhe klientĂ« tĂ« tjerĂ«, tĂ« cilĂ«t janĂ« si komponentĂ«. ĂĂ«shtja Ă«shtĂ« e juat: ose i shkarkoni komponentĂ«t me composer, ose pĂ«rdorni extenshion â zgjedhja juaj.Standartet korporative
Flasim pĂ«r tre urtĂ«si. UrtĂ«sia e katĂ«rt â Ă«shtĂ« tĂ« standardizoni qasjet. ĂfarĂ« do tĂ« thotĂ« kjo? ĂshtĂ« pĂ«rafĂ«rsisht kĂ«shtu:
Pse kĂ«tu Ă«shtĂ« fjala «korporative»? Jo sepse jemi njĂ« kompani e madhe ose burokratike, jo! Fjala «korporative» doja ta pĂ«rdorja nĂ« kontekstin qĂ« çdo kompani, çdo produkt ka standartet e saj, dhe gjithashtu edhe ju. ĂfarĂ« standartesh kemi ne?- Ne kemi njĂ« rregullore pĂ«r deploye. Ne nuk mund tĂ« lĂ«vizim pa tĂ«, nuk mundemi. Ne deployojmĂ« rreth 60 herĂ« nĂ« javĂ«, pra deployet ndodhin pothuajse vazhdimisht. MegjithatĂ«, kemi, pĂ«r shembull, nĂ« rregulloren e deployeve njĂ« tabu pĂ«r deployet tĂ« premteve â nĂ« parim, ne nuk bĂ«jmĂ« deploy.
- Dokumentimi është i detyrueshëm për ne. Asnjë komponent i ri nuk hyn në prodhukim nëse nuk ka dokumentacion, madje edhe nëse është krijuar nga shkrimtarët tanë të RnD. Ne kërkojmë prej tyre një udhëzues për deployimin, një hartë monitorimi dhe një përshkrim përafërsisht (siç mund të shkruajnë programuesit) se si funksionon ky komponent, si ta diagnostikoni atë.
- Ne zgjidhim jo shkakun e problemit, por problemin â atĂ« qĂ« kam thĂ«nĂ« tashmĂ«. PĂ«r ne Ă«shtĂ« e rĂ«ndĂ«sishme tĂ« mbrojmĂ« pĂ«rdoruesin nga problemet.
- Kemi leje. Për shembull, ne nuk e konsiderojmë si downtime nëse për dy minuta humbëm 2 % të trafikut. Në parim, kjo nuk hyn në statistikën tonë. Nëse është më shumë në përqindje ose kohë, atëherë e konsiderojmë.
- Dhe ne gjithmonĂ« shkruajmĂ« postmortem. ĂfarĂ«do qĂ« ndodhi, çdo situatĂ« kur u zhvillua ndryshe nĂ« prodhim, do tĂ« reflektohet nĂ« postmortem. Postmortem Ă«shtĂ« njĂ« dokument, nĂ« tĂ« cilin shkruani se çfarĂ« ndodhi, njĂ« kohĂ« tĂ« detajuar, çfarĂ« bĂ«tĂ« pĂ«r tĂ« korrigjuar dhe (kjo Ă«shtĂ« njĂ« bllok i detyrueshĂ«m!) çfarĂ« do tĂ« bĂ«ni pĂ«r tĂ« parandaluar qĂ« kjo tĂ« ndodhĂ« pĂ«rsĂ«ri nĂ« tĂ« ardhmen. Kjo Ă«shtĂ« e detyrueshme, e nevojshme pĂ«r analizĂ«n e mĂ«passhme.
ĂfarĂ« tĂ« llogaritĂ«sh si downtime?
Ku e çoi kjo gjithçka?Kjo e çoi në faktin se (kemi pasur disa probleme me stabilitetin, që nuk kënaqte as klientët, as ne) në gjashtë muajt e fundit, treguesi ynë i stabilitetit ishte 99,97. Mund të thuhet se kjo nuk është shumë. Po, kemi për çfarë të synojmë. Nga ky tregues, rreth gjysma është stabilitet i tipit që nuk është tonë, por i firewall-it tonë të aplikacionit web, i cili ndodhet para nesh dhe përdoret si një shërbim, por për klientët kjo është njëlloj.
Ne jemi mĂ«suar tĂ« flijmĂ« natĂ«n. SĂ« fundmi! GjashtĂ« muaj mĂ« parĂ« nuk dinim. Dhe nĂ« kĂ«tĂ« notĂ« pĂ«r rezultatet dua tĂ« bĂ«j njĂ« vĂ«rejtje. MbrĂ«mjen e djeshme kishte njĂ« paraqitje tĂ« shkĂ«lqyer mbi sistemin e menaxhimit tĂ« reaktorĂ«ve bĂ«rthamorĂ«. NĂ«se mĂ« dĂ«gjojnĂ« ata qĂ« e kanĂ« shkruar kĂ«tĂ« sistem â ju lutem, harroni atĂ« qĂ« thashĂ« pĂ«r "2% â nuk Ă«shtĂ« kohĂ« e humbur". PĂ«r ju 2% Ă«shtĂ« kohĂ« e humbur, edhe nĂ«se Ă«shtĂ« pĂ«r dy minuta!
Kjo është gjithçka! Pyetjet tuaja.
Për balancuesit dhe migrimin nga baza e të dhënave
Pyetje nga publiku (mĂ« tutje â P): â MirĂ«mĂ«ngjes. Faleminderit shumĂ« pĂ«r njĂ« paraqitje kaq tĂ« shkĂ«lqyer! Pyetja Ă«shtĂ« e shkurtĂ«r, nĂ« lidhje me balancuesit tuaj. Ju thatĂ« se keni njĂ« WAF, pra, siç e kuptoj unĂ«, nĂ« cilĂ«sinĂ« e balancuesit pĂ«rdorni ndonjĂ« tĂ« jashtĂ«mâŠ
EK: â Jo, nĂ« kapacitetin e balancuesit pĂ«rdorim shĂ«rbimet tona. NĂ« kĂ«tĂ« rast, WAF Ă«shtĂ« pĂ«r ne njĂ« mjet mbrojtjeje nga DDoS.
M: â A mund tĂ« thuash disa fjalĂ« rreth balancuesve?
EK: â Siç e thashĂ«, kjo Ă«shtĂ« njĂ« grup serverash nĂ« openresty. Aktualisht kemi 5 grupe rezervash, tĂ« cilat pĂ«rgjigjen ekskluzivisht⊠pra, serveri, nĂ« tĂ« cilin Ă«shtĂ« instaluar ekskluzivisht openresty, vetĂ«m e ndihmon trafik. PĂ«r ta kuptuar sa mbajnĂ«: tani ka njĂ« fluks standard tĂ« trafikut â disa qindra megabit. Ata i menaxhojnĂ« mirĂ«, madje nuk stresohen.
M: â NjĂ« pyetje e thjeshtĂ«. Ka njĂ« Blue/Green deployment. CfarĂ« bĂ«ni, pĂ«r shembull, me migrimet nga baza e tĂ« dhĂ«nave?
EK: â Pyetje e mirĂ«! Shihni, nĂ« Blue/Green deployment-in tonĂ« kemi radhĂ« tĂ« veçanta pĂ«r secilĂ«n linjĂ«. Pra, nĂ«se flasim pĂ«r radhĂ«t e ngjarjeve qĂ« kalojnĂ« nga punĂ«tori nĂ« punĂ«tor, ka radhĂ« tĂ« veçanta pĂ«r linjĂ«n blu dhe pĂ«r linjĂ«n jeshile. NĂ«se flasim pĂ«r bazĂ«n e tĂ« dhĂ«nave, ne e kemi zvogĂ«luar qĂ«llimisht, siç mundĂ«m, kemi kaluar gjithçka nĂ« radhĂ«, nĂ« bazĂ«n e tĂ« dhĂ«nave kemi vetĂ«m njĂ« stak transaksionesh. Dhe staku i transaksioneve Ă«shtĂ« i njĂ«jtĂ« pĂ«r tĂ« gjitha linjat. NĂ« kĂ«tĂ« kontekst pĂ«r bazĂ«n e tĂ« dhĂ«nave: ne nuk e ndajmĂ« atĂ« nĂ« blu dhe jeshile, sepse tĂ« dyja variantet e kodit duhet tĂ« dinĂ« se çfarĂ« ndodh me transaksionin.
Miq, kam njĂ« dhuratĂ« tĂ« vogĂ«l pĂ«r t'ju inkurajuar â njĂ« libĂ«r. Dhe duhet ta jap pĂ«r pyetjen mĂ« tĂ« mirĂ«.
M: â PĂ«rshĂ«ndetje. Faleminderit pĂ«r paraqitjen. Pyetja Ă«shtĂ« kjo. Ju monitoroni pagesat, ju monitoroni shĂ«rbimet me tĂ« cilat komunikoni⊠Si monitoroni qĂ« ndonjĂ« njeri ndonjĂ«herĂ« ka arritur nĂ« faqen tuaj tĂ« pagesĂ«s, ka kryer pagesĂ«n, dhe projekti i ka akredituar paratĂ«? Pra, si monitoroni qĂ« merchant Ă«shtĂ« i qasshĂ«m dhe ka pranuar callback-un tuaj?
EK: â "Merchant" pĂ«r ne nĂ« kĂ«tĂ« rast Ă«shtĂ« njĂ« shĂ«rbim i jashtĂ«m, siç Ă«shtĂ« sistemi i pagesave. Ne monitorojmĂ« shpejtĂ«sinĂ« e pĂ«rgjigjes sĂ« "merchant".
Për enkriptimin e bazës së të dhënave
M: â PĂ«rshĂ«ndetje. Kam njĂ« pyetje tĂ« ngjashme. Ju keni tĂ« dhĂ«na tĂ« ndjeshme sipas PCI DSS. DĂ«shiroja tĂ« dija, si i mbani PAN-tĂ« nĂ« radhĂ«, tĂ« cilat duhet t'i kaloni? PĂ«rdorni ndonjĂ« enkriptim? Dhe pyetja e dytĂ« qĂ« rrjedh: sipas PCI DSS duhet pĂ«rsĂ«ri tĂ« enkriptohet baza nĂ« rast ndryshimesh (largimi i administratorĂ«ve dhe kĂ«shtu me radhĂ«) â si ndodh kjo nĂ« rast tĂ« disponueshmĂ«risĂ«?
EK: â Pyetje e shkĂ«lqyer! SĂ« pari, ne nuk i mbajmĂ« PAN-tĂ« nĂ« radhĂ«. Ne nuk kemi tĂ« drejtĂ« ta ruajmĂ« PAN askund nĂ« mĂ«nyrĂ« tĂ« hapur, prandaj ne pĂ«rdorim njĂ« shĂ«rbim tĂ« veçantĂ« (e quajmĂ« "Keidemon") â ky Ă«shtĂ« njĂ« shĂ«rbim qĂ« bĂ«n vetĂ«m njĂ« gjĂ«: merr nĂ« hyrje njĂ« mesazh dhe jep njĂ« mesazh tĂ« enkriptuar. Dhe ne ruajmĂ« gjithçka me kĂ«tĂ« mesazh tĂ« enkriptuar. Prandaj, gjatĂ«sia e çelĂ«sit Ă«shtĂ« poshtĂ« njĂ« kilobajt, qĂ« tĂ« jetĂ« serioze dhe e sigurt.M: â Tani duhet 2 kilobajtĂ«?
EK: â Duket se dje ishte 256⊠Po ku tjetĂ«r?!
Pra, kjo Ă«shtĂ« e para. Dhe sĂ« dyti, zgjidhja qĂ« kemi mbĂ«shtet procedurĂ«n e reenkriptimit â atje ka dy palĂ« "cekash" (çelĂ«sa) qĂ« japin "dek"-et, qĂ« enkriptojnĂ« (key â janĂ« çelĂ«sa, dek â janĂ« derivatet e çelĂ«save qĂ« enkriptojnĂ«). Dhe nĂ« rastin e nisjes sĂ« procedurĂ«s (kjo ndodh rregullisht, çdo 3 muaj deri nĂ« ± diçka) ne ngarkojmĂ« njĂ« çift tĂ« ri "cekash", dhe ne kalojmĂ« nĂ« reenkriptimin e tĂ« dhĂ«nave. Ne kemi shĂ«rbime tĂ« veçanta qĂ« nxjerrin tĂ« dhĂ«nat, i enkriptojnĂ« pĂ«rsĂ«ri; nĂ« tĂ« dhĂ«na ruhet njĂ« identifikues i çelĂ«sit, me tĂ« cilin janĂ« enkriptuar. Prandaj, sapo tĂ« dhĂ«nat tĂ« jenĂ« tĂ« enkriptuara me çelĂ«sa tĂ« rinj, ne fshijmĂ« çelĂ«sat e vjetĂ«r.
Ndonjëherë pagesat duhet të kryhen ruaj.
M: â Pra, nĂ«se ka njĂ« kthim pĂ«r ndonjĂ« operacion, atĂ«herĂ« e dekriptoni me çelĂ«sin e vjetĂ«r?
EK: - Po.
M: â AtĂ«herĂ« njĂ« pyetje tjetĂ«r e vogĂ«l. Kur ndodh ndonjĂ« dĂ«shtim, rĂ«nie, incident, Ă«shtĂ« e nevojshme tĂ« shtyhet transaksioni manualisht. Ka raste tĂ« tilla.
EK: â Po, ndodhin.
M: â Nga i merrni kĂ«to tĂ« dhĂ«na? A e bĂ«ni vetĂ« kĂ«tĂ« manualisht nĂ« kĂ«tĂ« depo?
EK: â Jo, Ă«shtĂ« e qartĂ« â kemi njĂ« sistem pas skenĂ«s, i cili pĂ«rmban njĂ« ndĂ«rfaqe pĂ«r mbĂ«shtetje. NĂ«se nuk e dimĂ« se cila Ă«shtĂ« gjendja e transaksionit (p.sh., deri sa sistemi i pagesave nuk ka kthyer njĂ« pĂ«rgjigje), nuk e dimĂ«, pra ne e caktojmĂ« statusin pĂ«rfundimtar vetĂ«m kur jemi tĂ« sigurt. NĂ« kĂ«tĂ« rast, ne e zhvendosim transaksionin nĂ« njĂ« status tĂ« veçantĂ« pĂ«r pĂ«rpunim manual. NĂ« mĂ«ngjes, ditĂ«n tjetĂ«r, sapo mbĂ«shtetje tĂ« marrĂ« informacionin se nĂ« sistemin e pagesave kanĂ« mbetur kĂ«to transaksione, ato i pĂ«rpunojnĂ« manualisht nĂ« kĂ«tĂ« ndĂ«rfaqe.
M: â Kam disa pyetje. NjĂ« prej tyre Ă«shtĂ« vazhdimi i zonĂ«s PCI DSS: si i nxirrni log-et nga konturi i tyre? Ky pyetje ardh nga fakti se zhvilluesi mund tĂ« ketĂ« vendosur çdo gjĂ« nĂ« log-e! Pyetje e dytĂ«: si i nxirrni hotfix-et? Manualisht nĂ« bazĂ« â Ă«shtĂ« njĂ« opsion, por mund tĂ« ketĂ« hotfix-e falas â çfarĂ« procedure ndjekni? Dhe pyetja e tretĂ«, ndoshta e lidhur me RTO, RPO. Ju keni njĂ« disponibilitet prej 99,97, pothuajse katĂ«r nĂ«ntĂ«, por kuptoj se keni edhe qendrĂ«n e dytĂ« tĂ« tĂ« dhĂ«nave, qendrĂ«n e tretĂ« dhe tĂ« pestë⊠Si merremi me sinchronizimin, replikimin, gjithçka tjetĂ«r?EK: â Le tĂ« fillojmĂ« me tĂ« parĂ«n. Pyetja e parĂ« ishte pĂ«r log-et, apo jo? Kur shkruhen log-et, kemi njĂ« ndĂ«rmjetĂ«s qĂ« maskon tĂ« gjitha tĂ« dhĂ«nat sensitive. Ai shikon sipas maskĂ«s dhe polikave shtesĂ«. Si rezultat, log-et tona dalin me tĂ« dhĂ«na tĂ« maskuara dhe kontur tĂ« PCI DSS. Kjo Ă«shtĂ« njĂ« nga detyrat e rregullta, e cila i Ă«shtĂ« caktuar departamentit tĂ« testimit. Ata duhet tĂ« kontrollojnĂ« çdo detyrĂ«, pĂ«rfshirĂ« log-et qĂ« ata shkruajnĂ«, dhe kjo Ă«shtĂ« njĂ« nga detyrat e rregullta gjatĂ« rishikimit tĂ« kodit, qĂ« tĂ« kontrollojnĂ« qĂ« zhvilluesi nuk ka shkruar diçka. Kontrollimi i mĂ«tejshĂ«m bĂ«het rregullisht nga departamenti i sigurisĂ« informative rreth njĂ« herĂ« nĂ« javĂ«: merren pĂ«rzgjedhĂ«sive log-et pĂ«r ditĂ«n e fundit dhe ato kalohen pĂ«rmes njĂ« skaneri-analizatori nga serverĂ«t provues, pĂ«r tĂ« kontrolluar gjithçka.
PĂ«r hotfix-et. Kjo Ă«shtĂ« pĂ«rfshirĂ« nĂ« rregulloren tonĂ« tĂ« depolimit. Ne kemi njĂ« nen tĂ« veçantĂ« pĂ«r hotfix-et. Ne besojmĂ« se ne bĂ«jmĂ« hotfix-et 24 orĂ« nĂ« ditĂ« kur na nevojitet. Sa herĂ« qĂ« versioni pĂ«rfundon, sa herĂ« qĂ« Ă«shtĂ« testuar, sa herĂ« qĂ« kemi artefaktin â ne e ngrisim administratorin e sistemit nĂ« detyrĂ« nĂ«pĂ«rmjet telefonit nga mbĂ«shtetje, dhe ai e depolon atĂ« nĂ« momentin kur Ă«shtĂ« e nevojshme.PĂ«r 'katĂ«r nĂ«ntĂ«'. Numri qĂ« kemi tani Ă«shtĂ« arritur me tĂ« vĂ«rtetĂ«, dhe çelĂ«si ynĂ« ishte qĂ« ne e synuam atĂ« nĂ« njĂ« qendĂ«r tĂ« dytĂ« tĂ« tĂ« dhĂ«nave. Tani kemi njĂ« qendĂ«r tĂ« dytĂ« tĂ« tĂ« dhĂ«nave, dhe fillojmĂ« tĂ« radhisim mes tyre; dhe pyetje e replikimit ndĂ«rmjet qendrave tĂ« tĂ« dhĂ«nave Ă«shtĂ« me tĂ« vĂ«rtetĂ« njĂ« çështje e ndĂ«rlikuar. Ne kemi provuar ta zgjidhim atĂ« me mĂ«nyra tĂ« ndryshme: kemi provuar tĂ« pĂ«rdorim tĂ« njĂ«jtin 'Tarantul' â nuk na funksionoi, e them menjĂ«herĂ«. Prandaj, arritĂ«m nĂ« pĂ«rfundimin se bĂ«jmĂ« porosi pĂ«r 'senza' manualisht. Ădo aplikacion nĂ« tĂ« vĂ«rtetĂ« Ă«shtĂ« nĂ« njĂ« mĂ«nyrĂ« asinkrone pĂ«r sinchronizimin e nevojshĂ«m 'change â done' qĂ« kalon mes qendrave tĂ« tĂ« dhĂ«nave.
M: â NĂ«se ju keni njĂ« tĂ« dytĂ«, atĂ«herĂ« pse nuk keni njĂ« tĂ« tretĂ«? Sepse Split-brain ende nuk e kanĂ« zgjidhur askush...
EK: â Nuk kemi 'Split-brain'. PĂ«r shkak se çdo aplikacion nga ne kalon me multimashtĂ«, nuk na intereson nĂ« cilĂ«n qendĂ«r ka mbĂ«rritur kĂ«rkesa. Ne jemi tĂ« gatshĂ«m qĂ«, nĂ« rast se njĂ« qendĂ«r e tĂ« dhĂ«nave Ă«shtĂ« rĂ«nĂ« (ne e planifikojmĂ« kĂ«tĂ«) dhe nĂ« mes tĂ« kĂ«rkesĂ«s sĂ« pĂ«rdoruesit kthejmĂ« nĂ« qendrĂ«n e dytĂ«, jemi tĂ« gatshĂ«m tĂ« humbim atĂ« pĂ«rdorues, me tĂ« vĂ«rtetĂ«; por ato do tĂ« jenĂ« njĂ«si, absolutisht njĂ«si.
M: â MirĂ«mĂ«ngjes. Faleminderit pĂ«r prezantimin. Ju folĂ«t pĂ«r debagger-in tuaj, i cili ekzekuton disa transaksione testuese nĂ« prodhim. Tani, na tregoni pĂ«r transaksionet testuese! Sa thellĂ« shkon ky proces?
EK: â Ai kalon njĂ« cikĂ«l tĂ« plotĂ« tĂ« gjithĂ« komponentit. PĂ«r komponentin nuk ka dallime midis transaksionit testues dhe atij tĂ« produksionit. Dhe nga pikĂ«pamja e logjikĂ«s, kjo Ă«shtĂ« thjesht njĂ« projekt i veçantĂ« nĂ« sistem, ku kalojnĂ« vetĂ«m transaksionet testuese.
M: â Ku e ndaloni atĂ«? KĂ«shtu, Core dĂ«rgoiâŠ
EK: â Ne pasojmĂ« 'Kor' nĂ« kĂ«tĂ« rast pĂ«r transaksionet testuese... Kemi njĂ« koncept tĂ« tillĂ«, si routing: 'Kor' di nĂ« cilin sistem pagese duhet tĂ« dĂ«rgojmĂ« â ne dĂ«rgojmĂ« nĂ« njĂ« sistem pagese tĂ« rremĂ«, i cili thjesht jep njĂ« pĂ«rgjigje http dhe gjithçka.
M: â MĂ« thoni, ju lutem, a Ă«shtĂ« aplikacioni juaj shkruar si njĂ« monolit i madh, apo e keni ndarĂ« atĂ« nĂ« disa shĂ«rbime apo madje mikroshĂ«rbime?
EK: â Natyrisht qĂ« nuk kemi njĂ« monolit, kemi njĂ« aplikacion tĂ« orientuar nga shĂ«rbimet. Kemi njĂ« shaka qĂ« shĂ«rbimi ynĂ« Ă«shtĂ« nga monolitĂ« â ata janĂ« me tĂ« vĂ«rtetĂ« mjaft tĂ« mĂ«dhenj. Nuk do ta quaja kĂ«tĂ« si mikroshĂ«rbime, por nĂ« tĂ« vĂ«rtetĂ« janĂ« shĂ«rbime brenda tĂ« cilave punojnĂ« punĂ«torĂ«t e makinave tĂ« shpĂ«rndara.
NĂ«se shĂ«rbimi nĂ« server Ă«shtĂ« i kompromentuarâŠ
M: â AtĂ«herĂ« kam njĂ« pyetje tjetĂ«r. Edhe sikur tĂ« ishte njĂ« monolit, ju vazhdoni tĂ« thoni se keni shumĂ« nga kĂ«ta serverĂ« instant, tĂ« gjithĂ« ata nĂ« thelb shqyrtojnĂ« tĂ« dhĂ«nat, dhe pyetja Ă«shtĂ« kjo: "NĂ« rastin e kompromiseve tĂ« njĂ«rit prej serverĂ«ve instant ose ndonjĂ« aplikacioni, ndonjĂ« elementi tĂ« veçantĂ«, a kanĂ« ata ndonjĂ« kontroll akses? Kush mund tĂ« bĂ«jĂ« çfarĂ«? Kush duhet tĂ« kontaktohet, pĂ«r cilat tĂ« dhĂ«na?
EK: â Po, padyshim. KĂ«rkesat pĂ«r siguri janĂ« mjaft serioze. SĂ« pari, ne kemi lĂ«vizje tĂ« hapura tĂ« tĂ« dhĂ«nave, dhe portat janĂ« vetĂ«m ato pĂ«r tĂ« cilat ne paraprakisht presim lĂ«vizjen e trafikut. NĂ«se njĂ« komponent komunikon me bazĂ«n e tĂ« dhĂ«nave (le tĂ« themi, me "MySQL") pĂ«rmes 5-4-3-2, ai do tĂ« ketĂ« hapur vetĂ«m 5-4-3-2, dhe portat e tjera, drejtimet e tjera tĂ« lĂ«vizjes sĂ« trafikut nuk do tĂ« jenĂ« tĂ« aksesueshme. PĂ«r mĂ« tepĂ«r, duhet tĂ« kuptohet se nĂ« prodhim kemi rreth 10 konture tĂ« ndryshme sigurie. Dhe edhe nĂ«se ndonjĂ« aplikacion Ă«shtĂ« kompromentuar ndonjĂ« mĂ«nyrĂ«, Zoti na ruajttĂ«, hakeri nuk do tĂ« ketĂ« akses nĂ« konsolĂ«n e menaxhimit tĂ« serverit, sepse kjo Ă«shtĂ« njĂ« zonĂ« tjetĂ«r e sigurisĂ« nĂ« rrjet.M: â Mua nĂ« kĂ«tĂ« kontekst mĂ« intereson shumĂ« fakti se ju keni disa kontrata me shĂ«rbimet â çfarĂ« mund tĂ« bĂ«jnĂ« ato, pĂ«rmes cilave "veprime" mund tĂ« komunikojnĂ« me njĂ«ra-tjetrĂ«n⊠Dhe nĂ« fluksin normal disa shĂ«rbime tĂ« caktuara kĂ«rkojnĂ« njĂ« radhĂ« tĂ« caktuar "veprimesh" nga tjetri. Ata nuk i drejtohen tĂ« tjerĂ«ve nĂ« situata normale dhe kanĂ« zona tĂ« ndryshme pĂ«rgjegjĂ«sie. NĂ«se njĂ« nga ata do tĂ« jetĂ« kompromentuar, do tĂ« mund tĂ« tĂ«rheqĂ« "veprimet" e atij shĂ«rbimi?..
EK: â E kuptoj. NĂ«se nĂ« njĂ« situatĂ« normale komunikimi me serverin tjetĂ«r ishte lejuar, atĂ«herĂ« â po. Sipas kontratĂ«s SLA ne nuk monitorojmĂ« se ju janĂ« lejuar vetĂ«m 3 "veprime" tĂ« para, ndĂ«rsa 4 "veprimi" nuk ju janĂ« lejuar. Kjo ndoshta Ă«shtĂ« tepĂ«r pĂ«r ne, sepse ne kemi njĂ« sistem mbrojtĂ«s 4-niveli pĂ«r konturet. Ne preferojmĂ« tĂ« mbrohemi me konture, jo nĂ« nivelin e brendshĂ«m.
Si funksionojnë Visa, MasterCard dhe "Sberbank"
M: â Dua tĂ« sqaroj momentin pĂ«r kalimin e pĂ«rdoruesit nga njĂ« qendĂ«r tĂ« dhĂ«nash nĂ« njĂ« tjetĂ«r. Sipas sa di, "Visa" dhe "MasterCard" punojnĂ« me protokollin binar sinkron 8583, aty janĂ« mikse. Dhe doja tĂ« dija, tani Ă«shtĂ« fjala pĂ«r kalimin â a Ă«shtĂ« drejtpĂ«rdrejt "Visa" dhe "MasterCard" apo deri te sistemet pagesore, deri te procesorĂ«t?
EK: â KĂ«to janĂ« deri te mikset. Mikset tona ndodhen nĂ« njĂ« qendĂ«r tĂ« dhĂ«nash.
M: â NĂ« terma tĂ« thjeshtĂ«, a keni njĂ« pikĂ« lidhjeje?
EK: â PĂ«r "Visa" dhe "MasterCard" â po. Thjesht sepse "Visa" dhe "MasterCard" kĂ«rkojnĂ« investime tĂ« konsiderueshme nĂ« infrastrukturĂ« pĂ«r lidhjen e kontratave tĂ« veçanta pĂ«r tĂ« marrĂ« njĂ« palĂ« mikse tĂ« dytĂ«, pĂ«r shembull. Ato janĂ« rezervuar brenda njĂ« qendre tĂ« dhĂ«nash, por nĂ«se, Zot na ruajtĂ«, ndodhi qĂ« qendra e dhĂ«nash tĂ« vdesĂ« ku janĂ« mikset pĂ«r lidhjen me "Visa" dhe "MasterCard", atĂ«herĂ« lidhja me "Visa" dhe "MasterCard" do tĂ« humbasĂ«âŠ
M: â Si mund tĂ« jenĂ« rezervuar? E di qĂ« "Visa" lejon tĂ« mbajĂ« vetĂ«m njĂ« lidhje nĂ« parim!
EK: â Ata vetĂ« sjellin pajisjet. NĂ« çdo rast, na erdhi pajisja qĂ« brenda Ă«shtĂ« rrjetĂ« rezervuar.
M: â Pra, Ă«shtĂ« stazi nga Connects Orange tuaj?
EK: - Po.
M: â Si Ă«shtĂ« nĂ« kĂ«tĂ« rast: nĂ«se qendra e dhĂ«nash tuaj humbet, si do tĂ« vazhdoni ta pĂ«rdorni? Apo thjesht ndalon trafikun?
EK: â Jo. Ne nĂ« kĂ«tĂ« rast do tĂ« kalojmĂ« trafikun nĂ« njĂ« kanal tjetĂ«r, i cili, natyrisht, do tĂ« jetĂ« mĂ« i shtrenjtĂ« pĂ«r ne, mĂ« i shtrenjtĂ« pĂ«r klientĂ«t. Por trafiku nuk do tĂ« kalojĂ« pĂ«rmes lidhjes sonĂ« tĂ« drejtpĂ«rdrejtĂ« me "Visa", "MasterCard", por pĂ«rmes njĂ« "Sberbank" hipotetik (pĂ«r tĂ« thĂ«nĂ« shumĂ« thjesht).
Më falni nëse preka ndonjë punonjës të "Sberbank". Por sipas statistikave tona nga bankat ruse, "Sberbank" dështon më shpesh. Nuk kalon një muaj pa u ndodhur ndonjë gjë te "Sberbank".
Pak reklamĂ« đ
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish mĂ« i 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! Lexoni rreth
Burimi: habr.com
