HighLoad++, Evgeniy Kuzovlev (EcommPay IT): zer egin minutu bat geldialdi bat 100000 $ balio duenean

Denek hitz egiten dute garatzeko eta probatzeko prozesuez, langileak trebatzeaz, motibazioa areagotzeaz, baina prozesu hauek ez dira nahikoak zerbitzuaren geldialdi minutu batek diru kopuru izugarria balio duenean. Zer egin finantza-eragiketak SLA zorrotz baten arabera egiten dituzunean? Nola handitu zure sistemen fidagarritasuna eta akatsen tolerantzia, garapena eta probak ekuaziotik ateraz?

Hurrengo HighLoad++ konferentzia 6ko apirilaren 7an eta 2020an ospatuko da San Petersburgon. Xehetasunak eta sarrerak helbidean link. Azaroak 9, 18:00. HighLoad++ Mosku 2018, Delhi + Kolkata aretoa. Tesiak eta Aurkezpen.

Evgeniy Kuzovlev (aurrerantzean - EC): - Lagunak, kaixo! Nire izena Kuzovlev Evgeniy da. EcommPay konpainiakoa naiz, dibisio zehatz bat EcommPay IT da, enpresen taldeko informatika dibisioa. Eta gaur etenaldiei buruz hitz egingo dugu: nola saihestu, nola saihestu ezin bada haien ondorioak minimizatu. Gaia honela azaltzen da: "Zer egin minutu bat geldialdi bat 100 $ balio duenean"? Aurrera begira, gure zenbakiak konparagarriak dira.

Zer egiten du EcommPay IT?

Nor gara gu? Zergatik nago hemen zure aurrean? Zergatik daukat hemen zerbait esateko eskubidea? Eta zertaz hitz egingo dugu hemen zehatzago?

EcommPay enpresa-taldea nazioarteko eskuratzailea da. Ordainketak mundu osoan prozesatzen ditugu - Errusian, Europan, Asiako hego-ekialdean (Mundu osoan zehar). 9 bulego ditugu, 500 langile guztira, eta horien erdia baino pixka bat gutxiago informatika espezialistak dira. Egiten dugun guztia, dirua irabazten dugun guztia, geuk egin dugu.

Gure produktu guztiak (eta dezente ditugu - gure IT produktu handien lerroan 16 osagai desberdin inguru ditugu) guk geuk idatzi ditugu; Geure burua idazten dugu, geure burua garatzen dugu. Eta une honetan milioi bat transakzio egiten ditugu egunean (milioi da ziurrenik esateko modu egokia). Enpresa nahiko gaztea gara, sei bat urte baino ez ditugu.

Duela 6 urte halako startup bat zen mutilak negozioarekin batera etorri zirenean. Ideia batek batzen zituen (ideia bat besterik ez zegoen), eta korrika egin genuen. Edozein startup bezala, azkarrago ibiltzen ginen... Guretzat abiadura kalitatea baino garrantzitsuagoa zen.

Noizbait gelditu ginen: konturatu ginen jada ezin ginela nolabait abiadura horretan eta kalitate horrekin bizi eta lehen kalitatean zentratu behar genuela. Momentu honetan, zuzena, eskalagarria eta fidagarria izango zen plataforma berri bat idaztea erabaki genuen. Plataforma hau idazten hasi ziren (inbertitzen, garatzen, probatzen hasi ziren), baina noizbait konturatu ziren garapenak eta probak ez zigula zerbitzu kalitate maila berri batera iristen.

Produktu berri bat egiten duzu, produkzioan jartzen duzu, baina hala ere zerbait gaizki joango da nonbait. Eta gaur kalitate maila berri batera nola iritsi (nola egin genuen, gure esperientziaz), garapena eta probak ekuaziotik ateratzeaz hitz egingo dugu; funtzionamendurako erabilgarri dagoenari buruz hitz egingo dugu: funtzionamenduak berak egin dezakeenari buruz, kalitatean eragiteko probak eskain ditzakeenari buruz.

Etenaldiak. Funtzionamendu aginduak.

Beti oinarri nagusia, gaur benetan hitz egingo duguna geldialdi denbora da. Hitz ikaragarria. Atsedenaldia badugu, dena txarra da guretzat. Korrika egiten ari gara hura altxatzeko, administratzaileak zerbitzariari eusten diote - Jainkoak ez dezala erori, abesti horretan esaten duten bezala. Honetaz hitz egingo dugu gaur.

Gure ikuspegiak aldatzen hasi ginenean, 4 agindu osatu genituen. Diapositibetan aurkezten ditut:

Agindu hauek nahiko sinpleak dira:

• Azkar identifikatu arazoa.
• Kendu are azkarrago.
• Lagundu arrazoia ulertzen (geroago, garatzaileentzat).
• Eta estandarizatu planteamenduak.

Zure arreta erakarri nahi dizut 2. puntuan. Arazoa kentzen ari gara, ez konpontzen. Erabakitzea bigarren mailakoa da. Guretzat, gauza nagusia erabiltzailea arazo honetatik babestuta egotea da. Ingurune isolatu batzuetan existituko da, baina ingurune horrek ez du inolako harremanik izango harekin. Egia esan, lau arazo-multzo hauek aztertuko ditugu (batzuk zehatzago, beste batzuk xehetasun gutxiagorekin), esango dizut zer erabiltzen dugun, zer esperientzia garrantzitsua dugun konponbideetan.

Arazoak konpontzea: noiz gertatzen dira eta zer egin haiekin?

Baina ordenaz kanpo hasiko gara, 2. zenbakiarekin hasiko gara - nola azkar kendu arazoa? Arazo bat dago: konpondu behar dugu. "Zer egin behar dugu honen aurrean?" - galdera nagusia. Eta arazoa nola konpondu pentsatzen hasi ginenean, arazoen konponketak bete behar dituen baldintza batzuk garatu genituen.

Baldintza hauek formulatzeko, gure buruari galdera egitea erabaki genuen: “Noiz izaten ditugu arazoak”? Eta arazoak, ondorioz, lau kasutan gertatzen dira:

• Hardware akatsa.
• Kanpoko zerbitzuek huts egin dute.
• Softwarearen bertsioa aldatzea (hedapen bera).
• Karga lehergarriaren hazkundea.

Ez dugu lehenengo biei buruz hitz egingo. Hardwarearen matxura bat nahiko erraz konpondu daiteke: dena bikoiztuta eduki behar duzu. Hauek diskoak badira, diskoak RAIDean muntatu behar dira; hau zerbitzaria bada, zerbitzaria bikoiztu egin behar da; sareko azpiegitura bat baduzu, sareko azpiegituraren bigarren kopia bat eman behar duzu, hau da, hartu eta bikoiztu. Eta zerbaitek huts egiten badu, boterea erreserbatzera aldatzen duzu. Zaila da hemen ezer gehiago esatea.

Bigarrena kanpoko zerbitzuen porrota da. Gehienentzat, sistema ez da batere arazo bat, baina ez guretzat. Ordainketak prozesatzen ditugunez, erabiltzailearen (bere txartelaren datuak sartzen dituena) eta bankuen, ordainketa sistemak (Visa, MasterCard, Mira, etab.) artean dagoen agregatzailea gara. Gure kanpoko zerbitzuek (ordainketa sistemak, bankuak) huts egiten dute. Ez guk eta ez zuk (holako zerbitzuak badituzu) ezin dugu horretan eragin.

Zer egin orduan? Hemen bi aukera daude. Lehenik eta behin, ahal baduzu, zerbitzu hau nolabait bikoiztu beharko zenuke. Adibidez, ahal badugu, trafikoa zerbitzu batetik bestera transferitzen dugu: adibidez, txartelak Sberbank bidez prozesatu ziren, Sberbank arazoak izaten ari da - trafikoa [baldintzaz] transferitzen dugu Raiffeisenera. Egin dezakegun bigarren gauza kanpoko zerbitzuen porrota oso azkar antzematea da, eta horregatik erantzun-abiaduraz hitz egingo dugu txostenaren hurrengo zatian.

Izan ere, lau hauetatik, berariaz eragin dezakegu software-bertsioen aldaketan - inplementazioen testuinguruan eta kargaren hazkunde lehergarriaren testuinguruan egoera hobetzea ekarriko duten ekintzak egitea. Egia esan, horixe egin genuen. Hemen, berriz, ohar txiki bat...

Lau arazo horietatik, hainbat berehala konpontzen dira hodei bat baduzu. Microsoft Azhur, Ozono hodeietan bazaude edo gure hodeiak erabiltzen badituzu, Yandex edo Mail-en, orduan gutxienez hardware-matxura bat haien arazoa bihurtzen da eta dena berehala ondo egongo da hardware-matxura baten testuinguruan.

Apur bat ez-ohiko enpresa bat gara. Hemen denak "Kubernets"-i buruz ari dira, hodeiei buruz - ez dugu ez "Kubernets" ez hodeirik. Baina datu-zentro askotan hardware-rack-ak ditugu, eta hardware honetaz bizitzera behartuta gaude, guztiaren erantzule izatera behartuta gaude. Horregatik, testuinguru honetan hitz egingo dugu. Beraz, arazoei buruz. Lehenengo biak parentesi artean atera ziren.

Softwarearen bertsioa aldatzea. Oinarriak

Gure garatzaileek ez dute produkziorako sarbiderik. Zergatik da hori? Besterik da, PCI DSS ziurtagiria dugula eta gure garatzaileek ez dutela "produktuan" sartzeko eskubiderik. Hori da, puntua. Batere. Hori dela eta, garapenaren erantzukizuna garapenak eraikitzea askatzeko bidaltzen duen unean amaitzen da.

Daukagun bigarren oinarria, eta horrek ere asko laguntzen diguna, dokumenturik gabeko ezagutza berezirik ez izatea da. Zuretzat berdina izatea espero dut. Hori horrela ez bada, arazoak izango dituzulako. Arazoak sortuko dira dokumenturik gabeko ezagutza berezi hori une egokian leku egokian ez dagoenean. Demagun osagai zehatz bat zabaltzen dakien pertsona bat duzula -pertsona ez dago, oporretan edo gaixorik dago- hori da, arazoak dituzu.

Eta heldu garen hirugarren oinarria. Minaren, odolaren, malkoen bidez iritsi ginen - gure eraikuntzaren batek akatsak dituela ondorioztatu genuen, akatsik gabekoa bada ere. Guk geuk erabaki genuen: zerbait zabaltzen dugunean, zerbait produkzioan sartzen dugunean, akatsak dituen eraikuntza bat dugu. Gure sistemak bete behar dituen baldintzak osatu ditugu.

Softwarearen bertsioa aldatzeko baldintzak

Hiru baldintza daude:

• Azkar atzera bota behar dugu hedapena.
• Arrakastarik gabeko hedapen baten eragina gutxitu behar dugu.
• Eta paraleloan azkar hedatzeko gai izan behar dugu.
  Zehazki ordena horretan! Zergatik? Zeren eta, lehenik eta behin, bertsio berri bat zabaltzean, abiadura ez da garrantzitsua, baina garrantzitsua da zuretzat, zerbait gaizki ateratzen bada, azkar atzera egitea eta eragin minimoa izatea. Baina produkzioan bertsio-multzo bat baduzu, eta, horretarako, akats bat dagoela ikusten da (berdin, ez zen inplementaziorik izan, baina errore bat dago) - ondorengo hedapenaren abiadura garrantzitsua da zuretzat. Zer egin dugu eskaera horiei erantzuteko? Metodologia honetara jo dugu:

  
  
  Nahiko ezaguna da, ez dugu inoiz asmatu - hau Blue/Green deploy da. Zer da hau? Zure aplikazioak instalatuta dauden zerbitzari talde bakoitzeko kopia bat izan behar duzu. Kopia “beroa” da: ez dago trafikorik, baina edozein momentutan trafiko hori kopia honetara bidali daiteke. Kopia honek aurreko bertsioa dauka. Eta zabaltzen den unean, kodea kopia inaktibo batera zabaltzen duzu. Ondoren, trafikoaren zati bat (edo guztia) bertsio berrira aldatzen duzu. Hortaz, bertsio zaharretik berrira trafiko-fluxua aldatzeko, ekintza bakarra egin behar duzu: orekaria aldatu behar duzu ibaian gora, norabidea aldatu - upstream batetik bestera. Hau oso erosoa da eta azkar aldatzeko eta atzera egiteko arazoa konpontzen du.

  Hemen bigarren galderaren irtenbidea minimizazioa da: zure trafikoaren zati bat bakarrik bidal dezakezu lerro berri batera, kode berri bat duen lerro batera (izan bedi, adibidez, %2). Eta %2 hauek ez dira %100! Arrakastarik ez duen hedapen baten ondorioz trafikoaren % 100 galdu baduzu, hori beldurgarria da; trafikoaren % 2 galdu baduzu, hori desatsegina da, baina ez da beldurgarria. Gainera, ziurrenik, erabiltzaileak ez dira horretaz ohartuko, kasu batzuetan (ez guztietan) erabiltzaile bera, F5 sakatuz, beste bertsio batera eramango baita.

  Hedapena urdina/berdea. Bideratzea

  Dena den, dena ez da hain sinplea “Blue/Green deploy”... Gure osagai guztiak hiru taldetan bana daitezke:

  • hau da frontend-a (gure bezeroek ikusten dituzten ordainketa-orriak);
  • prozesatzeko muina;
  • Ordainketa sistemekin lan egiteko egokitzailea (bankuak, MasterCard, Visa...).

  Eta ñabardura bat dago hemen - ñabardura lerroen arteko bideratzean dago. Trafikoaren % 100 aldatzen baduzu, ez dituzu arazo hauek izango. Baina %2 aldatu nahi baduzu, galderak egiten hasten zara: "Nola egin hau?" Gauza sinpleena zuzena da: Round Robin nginx-en konfigura dezakezu ausazko aukeraren bidez, eta % 2 ezkerrera, % 98 eskuinera. Baina hau ez da beti egokia.

  Adibidez, gure kasuan, erabiltzaile batek sistemarekin elkarreragin egiten du eskaera bat baino gehiagorekin. Hau normala da: 2, 3, 4, 5 eskaera - zure sistemak berdinak izan daitezke. Eta zuretzat garrantzitsua bada erabiltzailearen eskaera guztiak lehen eskaera egin zuen lerro berean etortzea, edo (bigarren puntua) erabiltzailearen eskaera guztiak lerro berrira etortzea aldaketaren ondoren (lehenago hasi zitekeen lanean sistema, aldatu aurretik), - orduan ausazko banaketa hau ez da egokia zuretzat. Ondoren, aukera hauek daude:

  
  
  Lehenengo aukera, sinpleena, bezeroaren oinarrizko parametroetan oinarritzen da (IP Hash). IP bat duzu, eta eskuinetik ezkerrera banatzen duzu IP helbidearen arabera. Orduan, deskribatu dudan bigarren kasua zuretzat funtzionatuko du, hedapena gertatu zenean, erabiltzailea dagoeneko zure sistemarekin lanean has zitekeen, eta hedapen unetik eskaera guztiak lerro berri batera joango dira (berera, esate baterako).

  Arrazoiren batengatik hau ez bazaizu egokitzen eta eskaerak erabiltzailearen hasierako, hasierako eskaera iritsi den lerrora bidali behar badituzu, bi aukera dituzu...
  Lehen aukera: ordainpeko nginx+ erosi dezakezu. Sticky sessions mekanismo bat dago, eta, erabiltzailearen hasierako eskaeraren arabera, erabiltzaileari saio bat esleitzen dio eta upstream batera edo bestera lotzen du. Saioaren iraupenaren barruan ondorengo erabiltzaileen eskaera guztiak saioa argitaratu zen goranzko berera bidaliko dira.

  Hau ez zitzaigun egokitu jada nginx erregularra geneukalako. Nginx+-ra aldatzea ez da garestia denik, guretzat mingarri samarra izan zela eta ez oso zuzena da. "Sticks Sessions"-ek, adibidez, ez zigun funtzionatu "Sticks Sessions"-ek "Eather-or"-en oinarritutako bideratzea onartzen ez duelako. Bertan "Sticks Sessions"-ek egiten duguna zehaztu dezakezu, adibidez, IP helbidearen arabera edo IP helbidearen eta cookieen arabera edo postparametroaren arabera, baina "Edo-edo" konplikatuagoa da hor.

  Horregatik, laugarren aukerara heldu gara. Nginx esteroideetan hartu dugu (hau openresty da) - hau nginx bera da, azken script-ak sartzea onartzen duena gainera. Azken script bat idatz dezakezu, "atseden irekia" eman, eta azken script hau erabiltzailearen eskaera datorrenean exekutatuko da.

  Eta, hain zuzen ere, halako gidoi bat idatzi genuen, “openresti” ezarri genuen eta gidoi honetan 6 parametro ezberdin ordenatzen ditugu “Edo” kateamenduz. Parametro baten edo besteren presentziaren arabera, badakigu erabiltzailea orrialde batera edo bestera, lerro batera edo bestera iritsi zela.

  Hedapena urdina/berdea. Abantailak eta desabantailak

  Jakina, ziurrenik apur bat errazago egitea posible izango zen (erabili "Saio itsaskorrak"), baina ñabardura bat ere badugu, erabiltzaileak gurekin elkarreragin ez ezik transakzio baten prozesamendu baten esparruan... Baina ordainketa-sistemek ere elkarreragin egiten dute gurekin: transakzioa prozesatu ondoren (ordainketa-sistemari eskaera bat bidaliz), coolback bat jasotzen dugu.
  Eta demagun, gure zirkuituaren barruan erabiltzailearen IP helbidea eskaera guztietan birbidaltzen badugu eta erabiltzaileak IP helbidearen arabera banatzen baditugu, orduan ez dugu "Visa" bera esango: "Tide, hain enpresa retro bat gara, badirudi. nazioartekoa izateko (webgunean eta Errusian)... Mesedez, eman iezaguzu erabiltzailearen IP helbidea eremu gehigarri batean, zure protokoloa estandarizatuta dago”! Argi dago ez direla ados jarriko.

  
  
  Hori dela eta, honek ez zigun funtzionatu - openresty egin genuen. Horren arabera, bideratzearekin honelako zerbait lortu dugu:

  Blue/Green Deployment-ek, horren arabera, aipatu ditudan abantailak eta desabantailak ditu.

  Bi desabantaila:

  • bideratzearekin traba egin behar duzu;
  • bigarren desabantaila nagusia gastua da.

  Bikoitza zerbitzari gehiago behar dituzu, bikoitza baliabide operatibo behar dituzu, bi aldiz ahalegin handiagoa egin behar duzu zoo osoa mantentzeko.

  Bide batez, abantailen artean lehen aipatu ez dudan beste gauza bat dago: erreserba bat duzu karga haziz gero. Kargaren hazkunde lehergarria badaukazu, erabiltzaile kopuru handia baduzu, 50etik 50era arteko banaketan bigarren lerroa sartu besterik ez duzu - eta berehala x2 zerbitzariak dituzu zure klusterrean zerbitzari gehiago edukitzearen arazoa konpondu arte.

  Nola egin inplementazio azkarra?

  Minimizazioaren eta atzerapen azkarraren arazoa nola konpondu hitz egin genuen, baina galderak jarraitzen du: "Nola zabaldu azkar?"

  
  
  Hemen laburra eta sinplea da.

  • CD sistema bat izan behar duzu (Etengabeko entrega) - ezin zara hura gabe bizi. Zerbitzari bat baduzu, eskuz zabaldu dezakezu. Mila eta erdi zerbitzari inguru eta mila eta erdi helduleku ditugu, noski; gela honen tamainako sail bat ezarri dezakegu zabaltzeko.
  • Hedapena paraleloa izan behar da. Zure hedapena sekuentziala bada, dena txarra da. Zerbitzari bat normala da, egun osoan mila eta erdi zerbitzari zabalduko dituzu.
  • Berriz ere, azeleraziorako, ziurrenik ez da beharrezkoa. Zabaltzean, proiektua eraiki ohi da. Web-proiektu bat duzu, front-end zati bat dago (web pakete bat egiten duzu bertan, npm konpilatzen duzu - horrelako zerbait), eta prozesu hau, printzipioz, iraupen laburra da - 5 minutu, baina 5 minutu hauek izan daitezke. izan kritikoa. Horregatik, adibidez, ez dugu horrelakorik egiten: 5 minutu hauek kendu ditugu, artefaktuak zabaltzen ditugu.

    Zer da artefaktu bat? Artefaktu bat muntatutako eraikuntza bat da, zeinetan muntaketa-pieza guztiak dagoeneko osatuta dauden. Artefaktu hau artefaktu biltegian gordetzen dugu. Garai batean halako bi biltegiratze erabiltzen genituen: Nexus zen eta orain jFrog Artifactory).Hasieran “Nexus” erabili genuen, ikuspegi hori java aplikazioetan lantzen hasi ginelako (ondo egokitzen zitzaigun). Gero PHPn idatzitako aplikazio batzuk jarri zituzten bertan; eta "Nexus" jada ez zen egokia, eta, horregatik, jFrog Artefactory aukeratu genuen, ia dena artifactoriza dezakeena. Artefaktu-biltegi honetan zerbitzarietarako biltzen ditugun gure pakete bitarrak gordetzen ditugula ere iritsi gara.

  Karga lehergarriaren hazkundea

  Softwarearen bertsioa aldatzeari buruz hitz egin dugu. Daukagun hurrengo gauza kargaren igoera leherkorra da. Hemen, ziurrenik, kargaren hazkunde leherkorrarekin esan nahi dut ez dela gauza egokia...

  Sistema berri bat idatzi genuen: zerbitzuetara bideratuta dago, modan, ederra da, langileak nonahi, ilarak nonahi, asinkronia nonahi. Eta halako sistemetan, datuak fluxu ezberdinetatik igaro daitezke. Lehenengo transakziorako, 1., 3., 10. langilea erabil daiteke, bigarren transakziorako - 2., 4., 5.a. Eta gaur, demagun, goizean lehen hiru langileak erabiltzen dituen datu-fluxua duzu, eta arratsaldean izugarri aldatzen da, eta denak erabiltzen ditu beste hiru langileak.

  Eta hemen ikusten da langileak nolabait eskalatu behar dituzula, zure zerbitzuak nolabait eskalatu behar dituzula, baina, aldi berean, baliabideen bloat saihestu.

  
  
  Gure eskakizunak zehaztu ditugu. Baldintza hauek nahiko sinpleak dira: Zerbitzuaren aurkikuntza, parametrizazioa egotea - dena estandarra da horrelako sistema eskalagarriak eraikitzeko, puntu bat izan ezik - baliabideen amortizazioa. Esan genuen ez gaudela prest baliabideak amortizatzeko zerbitzariek airea berotu dezaten. “Kontsul” hartu genuen, gure langileak kudeatzen dituen “Nomada” hartu genuen.

  Zergatik da arazo hau guretzat? Atzera egin dezagun pixka bat. Orain 70 ordainketa sistema inguru ditugu atzean. Goizean, trafikoa Sberbanketik igarotzen da, gero Sberbank erori egin zen, adibidez, eta beste ordainketa sistema batera aldatzen dugu. Sberbanken aurretik 100 langile genituen, eta horren ostean 100 langile handitu behar ditugu beste ordainketa sistema baterako. Eta hori guztia gizakien parte-hartzerik gabe gertatzea desiragarria da. Gizakiaren parte-hartzea baldin badago, 24/7 ingeniari bat egon beharko luke bertan eserita, hau bakarrik egin beharko lukeena, horrelako hutsegiteak, 70 sistema atzean daudenean, aldizka gertatzen direlako.

  Hori dela eta, IP irekia duen Nomad-i begiratu diogu eta gure gauza idatzi dugu, Scale-Nomad - ScaleNo, gutxi gorabehera honako hau egiten duena: ilararen hazkundea kontrolatzen du eta langile kopurua murrizten edo handitzen du dinamikaren arabera. ilararen. Egin genuenean, pentsatu genuen: "Agian iturburu irekiko dugu?" Orduan begiratu zioten: bi kopek bezain sinplea zen.

  Orain arte ez dugu iturri irekirik, baina bat-batean txostenaren ondoren, halakorik behar duzula konturatu ondoren, behar baduzu, nire kontaktuak azken diapositiban daude - mesedez idatzi iezadazu. Gutxienez 3-5 pertsona baldin badaude, babestuko dugu.

  
  
  Nola dabil? Ikus dezagun! Aurrera begira: ezkerreko aldean gure jarraipenaren zati bat dago: hau lerro bat da, goian gertaeren prozesatzeko ordua dago, erdian transakzio kopurua, behean langile kopurua.

  Begiratzen baduzu, argazki honetan akats bat dago. Goiko taulan, zerrendetako bat 45 segundotan erori zen - ordainketa-sistemetako batek behera egin zuen. Berehala, trafikoa 2 minututan sartu zen eta ilara beste ordainketa sistema batean hazten hasi zen, non langilerik ez zegoen (ez genituen baliabideak erabili; aitzitik, baliabidea behar bezala bota genuen). Ez genuen berotu nahi - gutxieneko kopuru bat zegoen, 5-10 langile inguru, baina ezin izan zuten aurre egin.

  Azken grafikoak "konkor bat" erakusten du, eta horrek esan nahi du "Skaleno"k kopuru hori bikoiztu zuela. Eta gero, grafikoa pixka bat jaisten zenean, pixka bat murriztu zuen - langile kopurua automatikoki aldatzen zen. Horrela funtzionatzen du gauza honek. 2. puntuari buruz hitz egin dugu - "Nola azkar kendu arrazoiak".

  Jarraipena. Nola identifikatu arazoa azkar?

  Orain lehen puntua da "Nola azkar identifikatu arazoa?" Jarraipena! Gauza batzuk azkar ulertu behar ditugu. Zer gauza ulertu behar ditugu azkar?

  
  
  Hiru gauza!

  • Gure baliabideen errendimendua azkar ulertu eta ulertu behar dugu.
  • Hutsegiteak azkar ulertu behar ditugu eta guregandik kanpoko sistemen errendimendua kontrolatu behar dugu.
  • Hirugarren puntua akats logikoak identifikatzea da. Hau da sistema zuretzako lanean ari denean, dena normala da adierazle guztien arabera, baina zerbait gaizki doa.

  Ziurrenik ez dizut hemen horren polita den ezer esango. Obvious kapitaina izango naiz. Merkatuan zegoena bilatu genuen. "Zoo dibertigarria" dugu. Hau da orain daukagun zoo mota:

  
  
  Zabbix hardwarea kontrolatzeko erabiltzen dugu, zerbitzarien adierazle nagusiak kontrolatzeko. Okmeter erabiltzen dugu datu-baseetarako. "Grafana" eta "Prometheus" erabiltzen ditugu lehen bietara egokitzen ez diren beste adierazle guztietarako, batzuk "Grafana" eta "Prometheus"ekin, eta beste batzuk "Grafana"rekin "Influx" eta Telegrafekin.

  Duela urtebete Erlikia Berria erabili nahi genuen. Gauza polita, dena egin dezake. Baina dena egin dezakeen neurrian, oso garestia da. 1,5 mila zerbitzariko bolumena izatera iritsi ginenean, saltzaile bat etorri zitzaigun eta esan zuen: "Lor dezagun datorren urterako akordioa". Prezioari begiratu eta ezetz esan genion, ez dugula hori egingo. Orain New Relic abandonatzen ari gara, 15 zerbitzari inguru geratzen zaizkigu New Relic-en monitorizaziopean. Prezioa erabat basatia izan zen.

  Eta guk geuk inplementatu dugun tresna bat dago: Debugger da. Hasieran "Bagger" deitzen genion, baina gero ingeleseko irakasle bat pasatu zen, barre algaraka egin zuen eta "Debagger" izena jarri zion. Zer da hau? Izan ere, osagai bakoitzean 15-30 segundotan, sistemaren "kutxa beltza" bezala, osagaiaren errendimendu orokorraren probak egiten dituen tresna da.

  Esaterako, kanpoko orri bat badago (ordainketa orria), ireki besterik ez du eta nola begiratu behar duen begiratzen du. Hau prozesatzen ari bada, "transakzio" proba bat bidaltzen du eta "transakzio" hori iristen dela ziurtatzen du. Ordainketa sistemekin konexioa bada, horren arabera proba eskaera bat botako dugu, ahal dugun lekuan, eta dena ondo dagoela ikusten dugu.

  Zein adierazle dira garrantzitsuak jarraipena egiteko?

  Zer kontrolatzen dugu batez ere? Zein adierazle dira garrantzitsuak guretzat?

  
  

  • Erantzun denbora / RPS fronteetan oso adierazle garrantzitsua da. Berehala erantzuten dizu zerbait gaizki dagoela.
  • Ilara guztietan prozesatutako mezuen kopurua.
  • Langile kopurua.
  • Oinarrizko zuzentasun-neurriak.

  Azken puntua "negozioa", "enpresa" metrika da. Gauza bera kontrolatu nahi baduzu, zuretzat adierazle nagusiak diren metrika bat edo bi definitu behar dituzu. Gure metrika errendimendua da (hau da transakzio arrakastatsuen kopuruaren eta transakzio-fluxu osoaren arteko erlazioa). 5-10-15 minutuko tartean zerbait aldatzen bada, arazoak ditugula esan nahi du (errotik aldatzen bada).

  Guretzat ematen duguna gure taula baten adibidea da:

  
  
  Ezkerreko aldean 6 grafiko daude, hau lerroen araberakoa da: langile kopurua eta ilaretan dauden mezu kopurua. Eskuineko aldean - RPS, RTS. Jarraian, "negozio" metrika bera dago. Eta "negozio" metrikan berehala ikus dezakegu zerbait gaizki joan dela erdiko bi grafikoetan... Hau gure atzean dagoen beste sistema bat da, erori dena.

  Egin behar genuen bigarren gauza kanpoko ordainketa sistemen erorketa kontrolatzea zen. Hemen OpenTracing hartu dugu - sistema banatuak trazatzeko aukera ematen duen mekanismoa, estandarra, paradigma; eta pixka bat aldatu zen. OpenTracing paradigma estandarrak dio eskaera bakoitzarentzat arrasto bat eraikitzen dugula. Ez genuen hau behar, eta laburpen batean bildu genuen, agregazio arrasto batean. Atzean ditugun sistemen abiaduraren jarraipena egiteko aukera ematen duen tresna bat egin dugu.

  
  
  Grafikoak erakusten digu ordainketa-sistemaren bat 3 segundotan erantzuten hasi zela - arazoak ditugu. Gainera, arazoak hasten direnean erreakzionatuko du gauza honek, 20-30 segundoko tartean.

  Eta dauden monitorizazio akatsen hirugarren klasea monitorizazio logikoa da.

  Egia esateko, ez nekien zer marraztu diapositiba honetan, aspaldian gabiltzalako merkatuan guri egokituko zitzaigun zerbaiten bila. Ez genuen ezer aurkitu, beraz, guk geuk egin behar izan genuen.

  
  
  Zer esan nahi dut jarraipen logikoarekin? Bada, imajinatu: zuk zeuk egiten duzu sistema bat (adibidez, Tinder klon bat); egin duzu, martxan jarri duzu. Vasya Pupkin kudeatzaile arrakastatsuak bere telefonoan jarri zuen, neska bat ikusten du han, gustatzen zaio... eta antzekoak ez zaizkio neskari joaten; antzekoa negozio zentro bereko Mikhalych segurtasun zaindariari dagokio. Zuzendaria behera jaisten da, eta orduan galdetzen dio: "Zergatik egiten dio irribarre atsegin Mikhalych segurtasun zaindari honek?"

  Horrelako egoeretan... Guretzat, egoera hau apur bat ezberdina da, zeren (idatzi nuen) zeharka finantza-galerak dakarren ospe galera delako. Gure egoera alderantzizkoa da: finantza-galera zuzenak jasan ditzakegu, adibidez, transakzio bat arrakastatsu bezala egin bagenu, baina ez zuen arrakasta izan (edo alderantziz). Negozio-adierazleak erabiliz denboran zehar transakzio arrakastatsuen kopuruaren jarraipena egiten duen nire tresna idatzi behar nuen. Ez dut ezer aurkitu merkatuan! Hauxe da, hain zuzen, helarazi nahi nuen ideia. Merkatuan ez dago ezer mota hori konpontzeko.

  Hau arazoa azkar nola identifikatu zen.

  Nola zehaztu hedapenaren arrazoiak

  Ebazten dugun hirugarren arazo-multzoa arazoa identifikatu ondoren, kendu ondoren, ondo legoke garapenaren, probaren arrazoia ulertzea eta zerbait egitea. Horren arabera, ikertu behar dugu, enborrak igo behar ditugu.

  
  
  Erregistroei buruz ari bagara (arrazoi nagusia erregistroak dira), gure erregistro gehienak ELK Stack-en daude - ia denek berdina dute. Batzuentzat, baliteke ELKn ez egotea, baina erregistroak gigabytetan idazten badituzu, lehenago edo beranduago ELKra etorriko zara. Terabytetan idazten ditugu.

  
  
  Hemen arazo bat dago. Konpondu genuen, erabiltzailearentzat errorea zuzendu, zegoena ateratzen hasi ginen, Kibanara igo, han transakzio IDa sartu eta honelako oinetako bat lortu genuen (asko erakusten du). Eta ez dago ezer argi oin-oin honetan. Zergatik? Bai, ez baitago argi zein zati den zein langileri, zein zati zein osagairi. Eta momentu horretan konturatu ginen trazadura behar genuela - hitz egin nuen OpenTracing bera.

  Duela urtebete pentsatu genuen, gure arreta merkatura bideratu genuen, eta bi tresna zeuden bertan: "Zipkin" eta "Jaeger". "Jager" hain oinordeko ideologikoa da, "Zipkin"-en oinordeko ideologikoa. Dena ona da Zipkin-en, ez dakiela nola agregatu ezik, ez dakiela erregistroak nola sartzen trazan, denboraren arrastoa bakarrik. Eta "Jager"-ek hori onartzen zuen.

  "Jager" aztertu dugu: aplikazioak instrumentatu ditzakezu, Api-n idatzi dezakezu (orduan PHPrako Api estandarra, ordea, ez zen onartu - duela urtebete izan zen, baina orain dagoeneko onartua dago), baina hor ez zen erabat bezeroa. "Ongi", pentsatu genuen, eta gure bezeroari idatzi genuen. Zer lortu dugu? Hau da gutxi gorabehera nolakoa den:

  
  
  Jaeger-en, mezu bakoitzerako tarteak sortzen dira. Hau da, erabiltzaile batek sistema irekitzen duenean, sarrerako eskaera bakoitzeko bloke bat edo bi ikusten ditu (1-2-3 - erabiltzaileak jasotako eskaera kopurua, bloke kopurua). Erabiltzaileei errazago egiteko, etiketak gehitu ditugu erregistroetan eta denbora-aztarnetan. Horren arabera, akatsen bat izanez gero, gure aplikazioak erregistroa markatuko du Errore etiketa egokiarekin. Errore-etiketaren arabera iragaz dezakezu eta bloke hau errore bat duten tarteak soilik bistaratuko dira. Hau da tartea zabaltzen badugu:

  
  
  Tartearen barruan arrasto multzo bat dago. Kasu honetan, hiru proba-arrastoak dira, eta hirugarren arrastoak errore bat gertatu dela esaten digu. Aldi berean, hemen denbora-traza bat ikusten dugu: denbora-eskala dugu goian, eta ikusten dugu zer denbora-tartetan erregistratu den erregistro hau edo hura.

  Horren arabera, gauzak ondo atera zitzaizkigun. Geure luzapena idatzi dugu eta kode irekia dugu. Trazadurarekin lan egin nahi baduzu, PHPn "Jager"-ekin lan egin nahi baduzu, hor dago gure luzapena, ongi etorria erabiltzera, esaten duten moduan:

  
  
  Luzapen hau dugu: OpenTracing Apirako bezeroa da, php-extension gisa egina dago, hau da, muntatu eta sisteman instalatu beharko duzu. Duela urtebete ez zegoen ezer desberdina. Orain osagai bezalakoak diren beste bezero batzuk daude. Hemen zure esku dago: osagaiak konpositore batekin ponpatzen dituzu, edo zure esku dagoen luzapena erabiltzen duzu.

  Estandar korporatiboak

  Hiru aginduei buruz hitz egin dugu. Laugarren agindua planteamenduak estandarizatzea da. Zeri buruz da hau? Honi buruz da:

  
  
  Zergatik dago hemen "korporazio" hitza? Ez enpresa handi edo burokratiko bat garelako, ez! Hemen "korporazio" hitza erabili nahi nuen, enpresa bakoitzak, produktu bakoitzak bere estandarrak izan behar dituela, zu barne. Zein estandar ditugu?

  
  

  • Inplementazio araudia dugu. Bera gabe ez gara inora mugitzen, ezin dugu. Astean 60 bat aldiz zabaltzen dugu, hau da, ia etengabe zabaltzen dugu. Aldi berean, inplementazio araudian, adibidez, ostiraleko hedapenen tabu bat dugu -printzipioz, ez dugu zabaltzen-.
  • Dokumentazioa eskatzen dugu. Osagai berri bakar bat ere ez da produkzioan sartzen horren dokumentaziorik ez badago, gure RnD espezialisten lumapean jaio bada ere. Haiei eskatzen diegu hedapen-argibideak, jarraipen-mapa bat eta osagai honek nola funtzionatzen duen eta nola konpondu den deskribapen laburra (beno, programatzaileek idatzi dezaketen moduan).
  • Ez dugu arazoaren kausa konpontzen, arazoa baizik, lehen esan dudana. Guretzat garrantzitsua da erabiltzailea arazoetatik babestea.
  • Baditugu baimenak. Esaterako, ez dugu kontuan hartzen geldialdi-denbora bi minututan trafikoaren %2 galtzen badugu. Hau funtsean ez dago gure estatistiketan sartzen. Gehiago bada ehunekotan edo aldi baterako baldin bada, dagoeneko zenbatzen dugu.
  • Eta autopsiak idazten ditugu beti. Gertatzen zaiguna gertatzen zaigula, ekoizpenean norbaitek portaera anormala izan duen edozein egoera autopsian islatuko da. Postmortem-a dokumentu bat da, non zer gertatu zaizun idazten duzun, denbora zehatza, hura zuzentzeko zer egin duzun eta (hau nahitaezko blokea da!) zer egingo duzun etorkizunean hori gerta ez dadin. Hau derrigorrezkoa eta beharrezkoa da ondorengo analisietarako.

  Zer jotzen da geldialdi-denbora?

  
  
  Zer ekarri zuen honek guztiak?

  Horrek (egonkortasunarekin zenbait arazo izan genituen, hau ez zitzaigun ez bezeroei ez guri egokitu) azken 6 hilabeteetan gure egonkortasun-adierazlea 99,97koa izan zen. Hau ez dela asko esan dezakegu. Bai, badugu zer ahalegintzeko. Adierazle honen erdia inguru egonkortasuna da, nolabait esateko, ez gurea, gure web aplikazioen suebakiarena baizik, gure aurrean dagoena eta zerbitzu gisa erabiltzen dena, baina bezeroei ez zaie hori axola.

  Gauez lo egiten ikasi genuen. Azkenean! Duela sei hilabete ezin genuen. Eta emaitzekin ohar honetan, ohar bat egin nahiko nuke. Atzo gauean erreaktore nuklear baten kontrol sistemari buruzko erreportaje zoragarria izan zen. Sistema hau idatzi dutenek entzuten badidate, mesedez ahaztu "% 2 ez da geldialdi-denbora" buruz esan dudanaz. Zuretzat, % 2 geldialdia da, bi minutuz bada ere!

  Hori da dena! Zure galderak.

  
  

  Balantzatzaileei eta datu-baseen migrazioari buruz

  Entzuleen galdera (aurrerantzean – B): – Arratsalde on. Mila esker administratzaileen txostenagatik! Zure orekatzaileei buruzko galdera labur bat. WAF bat duzula aipatu duzu, hau da, nik ulertzen dudanez, kanpoko orekatzaile moduko bat erabiltzen duzula...

  EK: – Ez, gure zerbitzuak orekatzaile gisa erabiltzen ditugu. Kasu honetan, WAF DDoS babeserako tresna bat da soilik guretzat.

  V: – Esan al ditzakezu hitz batzuk orekariei buruz?

  EK: – Lehen esan dudan bezala, hau openresty-ko zerbitzari talde bat da. Orain esklusiboki erantzuten duten 5 erreserba-talde ditugu... hau da, openresty esklusiboki exekutatzen duen zerbitzari bat, trafikoa proxy baino ez du egiten. Horren arabera, zenbat eusten dugun ulertzeko: ehunka megabiteko ohiko trafiko-fluxua dugu orain. Aurre egiten dute, ondo sentitzen dira, ez dira estutu ere egiten.

  V: – Galdera sinple bat ere bai. Hona hemen Blue/Green hedapena. Zer egiten duzu, adibidez, datu-baseen migrazioekin?

  EK: - Galdera ona! Begira, Blue/Green inplementazioan lerro bakoitzeko ilara bereiziak ditugu. Hau da, langiletik langilera transmititzen diren gertaeren ilarez ari bagara, lerro urdinerako eta marra berderako ilara bereiziak daude. Datu-baseari buruz hitz egiten ari bagara, orduan nahita ahal genuen neurrian murriztu genuen, ia guztia ilaretara eraman genuen; datu-basean transakzio pila bat baino ez dugu gordetzen. Eta gure transakzio-pila berdina da lerro guztietan. Datu-basea testuinguru honetan: ez dugu urdina eta berdea zatitzen, kodearen bi bertsioek transakzioarekin zer gertatzen den jakin behar dutelako.

  Lagunak, sari txiki bat ere badut zuek bultzatzeko: liburu bat. Eta galdera onenaren saria eman beharko lidateke.

  V: - Kaixo. Eskerrik asko erreportajeagatik. Galdera hau da. Ordainketak kontrolatzen dituzu, komunikatzen dituzun zerbitzuak kontrolatzen dituzu... Baina nola kontrolatzen duzu pertsona bat nolabait zure ordainketa-orrira etorri, ordainketa egin eta proiektuak dirua kreditatu dion? Hau da, nola kontrolatzen duzu merkataria eskuragarri dagoela eta zure deia onartu duela?

  EK: – Guretzat "merkataria" kasu honetan ordainketa-sistemaren kanpoko zerbitzu bera da. Merkatariaren erantzun-abiadura kontrolatzen dugu.

  Datu-baseen enkriptatzeari buruz

  V: - Kaixo. Zertxobait erlazionatuta dagoen galdera bat daukat. PCI DSS datu sentikorrak dituzu. Jakin nahi nuen nola gordetzen dituzun PANak transferitu behar dituzun ilaretan? Zifratzerik erabiltzen al duzu? Eta horrek bigarren galderara eramaten du: PCI DSS-en arabera, beharrezkoa da datu-basea aldian-aldian berriro enkriptatzea aldaketak gertatuz gero (administratzaileak kaleratzea, etab.) - zer gertatzen da irisgarritasunarekin kasu honetan?

  
  
  EK: - Galdera zoragarria! Lehenik eta behin, ez ditugu PANak ilaretan gordetzen. Ez dugu eskubiderik inon PAN forma argian gordetzeko, printzipioz, beraz, zerbitzu berezi bat erabiltzen dugu ("Kademon" deitzen diogu) - gauza bakarra egiten duen zerbitzua da: mezu bat jasotzen du sarrera gisa eta bidaltzen du. enkriptatutako mezu bat atera. Eta dena gordetzen dugu enkriptatutako mezu honekin. Horren arabera, gure gakoaren luzera kilobytetik beherakoa da, hau serioa eta fidagarria izan dadin.

  V: – 2 kilobyte behar dituzu orain?

  EK: – Badirudi atzo 256 izan zirela... Tira, non bestela?!

  Horren arabera, hau da lehenengoa. Eta bigarrenik, dagoen irtenbidea, berriro enkriptatzeko prozedura onartzen du - bi "kek" (gakoak) bikote daude, "barrukiak" enkriptatzen dituztenak (gakoak gakoak dira, dek enkriptatutako gakoen eratorriak dira) . Eta prozedura hasten bada (aldiro gertatzen da, 3 hilabetetik ± batzuetara), "opil pare" berri bat deskargatzen dugu eta datuak berriro enkriptatzen ditugu. Datu guztiak erauzi eta modu berri batean enkriptatzen dituzten zerbitzu bereiziak ditugu; Datuak enkriptatutako gakoaren identifikatzailearen ondoan gordetzen dira. Horren arabera, datuak gako berriekin zifratzen ditugun bezain laster, gako zaharra ezabatzen dugu.

  Batzuetan ordainketak eskuz egin behar dira...

  V: – Hau da, eragiketaren batengatik itzulketa iritsi bada, oraindik deszifratuko al duzu gako zaharrarekin?

  EK: - Bai.

  V: – Orduan beste galdera txiki bat. Porrot, erorketa edo gorabehera motaren bat gertatzen denean, transakzioa eskuz egin behar da. Bada halako egoera bat.

  EK: - Bai, batzuetan.

  V: – Nondik ateratzen dituzu datu hauek? Edo zuk zeuk joaten zara biltegiratze honetara?

  EK: – Ez, beno, noski, gure laguntzarako interfaze bat daukan back-office sistemaren bat daukagu. Transakzioa zein egoeratan dagoen ez badakigu (adibidez, ordainketa-sistemak denbora-muga batekin erantzun arte), ez dakigu a priori, hau da, azken egoera konfiantza osoz esleitzen dugu. Kasu honetan, transakzioa egoera berezi bat esleitzen dugu eskuz prozesatzeko. Goizean, hurrengo egunean, laguntzak halako eta halako transakzioak ordainketa-sisteman geratzen direlako informazioa jasotzen duen bezain laster, eskuz prozesatzen ditu interfaze honetan.

  
  
  V: – Galdera pare bat ditut. Horietako bat PCI DSS zonaren jarraipena da: nola erregistratzen duzu haien zirkuitua? Galdera hau garatzaileak ezer ipini zezakeelako erregistroetan! Bigarren galdera: nola zabaltzen dituzu konponketak? Datu-basean heldulekuak erabiltzea da aukera bat, baina doako konponketak egon daitezke - zein da prozedura bertan? Eta hirugarren galdera ziurrenik RTO, RPOrekin lotuta dago. Zure erabilgarritasuna 99,97 zen, ia lau bederatzi, baina nik ulertzen dudanez, bigarren datu-zentro bat, hirugarren datu-zentro bat eta bosgarren datu-zentro bat dituzu... Nola sinkronizatu, errepikatu eta beste guztia?

  EK: - Has gaitezen lehenengoarekin. Lehenengo galdera erregistroei buruzkoa izan zen? Erregistroak idazten ditugunean, datu sentikor guztiak ezkutatzen dituen geruza bat dugu. Maskara eta eremu osagarriei begiratzen die. Horren arabera, gure erregistroak dagoeneko estalitako datuekin eta PCI DSS zirkuitu batekin ateratzen dira. Proba sailari esleitutako ohiko zereginetako bat da. Zeregin bakoitza egiaztatu behar dute, idazten dituzten erregistroak barne, eta hau kodeen berrikuspenetan ohiko zereginetako bat da, garatzaileak ezer idatzi ez duela kontrolatzeko. Honen ondorengo egiaztapenak aldian-aldian egiten ditu informazio-segurtasun sailak astean behin gutxi gorabehera: azken eguneko erregistroak selektiboki hartzen dira eta proba-zerbitzarietatik eskaner-analizatzaile berezi baten bidez exekutatzen dira dena egiaztatzeko.
  Konponketa beroei buruz. Hau gure hedapen-araudian sartzen da. Konponketari buruzko klausula bereizia dugu. Uste dugu konponketak behar dugunean zabaltzen ditugula erloju osoan. Bertsioa muntatu bezain laster, exekutatu bezain laster, artefaktu bat izan bezain laster, sistema-administratzaile bat daukagu ​​laguntza-dei batean, eta beharrezkoa den momentuan zabaltzen du.

  "Lau bederatzi" inguru. Orain dugun zifra benetan lortu da, eta beste datu-zentro batean ahalegindu gara. Orain bigarren datu-zentro bat dugu, eta haien artean bideratzen hasi gara, eta datu-zentroen arteko erreplikazioaren arazoa galdera ez hutsala da benetan. Momentu ezberdinetan saiatu ginen konpontzen aldi berean: "Tarantula" bera erabiltzen saiatu ginen - ez zitzaigun ondo atera, berehala esango dizut. Horregatik azkenean “sens”-ak eskuz aginduz. Izan ere, gure sistemako aplikazio bakoitzak datu-zentroen arteko beharrezkoa den "aldaketa - egindako" sinkronizazioa exekutatzen du modu asinkronoan.

  V: - Bigarren bat lortu baduzu, zergatik ez duzu hirugarren bat lortu? Oraindik inork ez duelako garun zatitua...

  EK: – Baina ez dugu Split Brain. Aplikazio bakoitza multimaster batek gidatzen duenez, ez zaigu axola zein zentrotara iritsi den eskaera. Prest gaude gure datu-zentroren batek huts egiten badu (horretan oinarritzen gara) eta erabiltzaileen eskaera baten erdian bigarren datu-zentrora aldatzen bada, prest gaude erabiltzaile hau galtzeko, hain zuzen ere; baina hauek unitateak izango dira, unitate absolutuak.

  V: - Arratsalde on. Eskerrik asko erreportajeagatik. Produkzioan probako transakzio batzuk exekutatzen dituen zure araztagailuari buruz hitz egin duzu. Baina konta iezaguzu proba-transakzioei buruz! Zenbat sakonera doa?

  EK: – Osagai osoaren ziklo osoa zeharkatzen du. Osagai baten kasuan, ez dago desberdintasunik proba-transakzio baten eta ekoizpen-transakzio baten artean. Baina ikuspuntu logikotik, hau sisteman aparteko proiektu bat da, proba-transakzioak soilik exekutatzen dituena.

  V: -Non mozten duzu? Hona Core bidali...

  EK: – Kasu honetan “Kor” atzean gaude probako transakzioetarako... Bideraketa bezalako gauza bat dugu: “Kor”-ek badaki zein ordainketa-sistematara bidali behar den - ordainketa-sistema faltsu batera bidaltzen dugu, eta horrek http seinalea besterik ez du ematen eta hori da dena.

  V: – Esadazu, mesedez, zure aplikazioa monolito handi batean idatzita zegoen, ala zerbitzu edo mikrozerbitzu batzuetan moztu duzu?

  EK: – Ez dugu monolitorik, noski, zerbitzuetara bideratutako aplikazioa dugu. Txantxetan dugu gure zerbitzua monolitoz egina dagoela; benetan handiak dira. Zaila da mikrozerbitzuak deitzea, baina banatutako makinetako langileek lan egiten duten zerbitzuak dira.

  Zerbitzariko zerbitzua arriskuan badago...

  V: – Orduan hurrengo galdera daukat. Monolito bat bazen ere, berehalako zerbitzari horietako asko dituzula esan duzu, funtsean denek prozesatzen dituzte datuak, eta galdera hauxe da: “Istanteko zerbitzarietako bat edo aplikazioren bat arriskuan jartzen bada, edozein esteka indibiduala. , ba al dute nolabaiteko sarbide-kontrolik? Horietako zeinek egin dezake zer? Norekin jarri behar dut harremanetan zein informazio lortzeko?

  
  
  EK: - Bai, zalantzarik gabe. Segurtasun baldintzak nahiko larriak dira. Lehenik eta behin, datu irekien mugimenduak ditugu, eta portuak trafikoaren mugimendua aurreikusten ditugunak baino ez dira. Osagai bat datu-basearekin komunikatzen bada (esaterako, Muskul-ekin) 5-4-3-2 bidez, 5-4-3-2 bakarrik egongo da irekita, eta beste portu eta beste trafiko-norabide batzuk ez dira erabilgarri egongo. Horrez gain, ulertu behar duzu gure ekoizpenean 10 segurtasun-begizta desberdin inguru daudela. Eta nahiz eta aplikazioa nolabait arriskuan egon, Jainkoak ez dezala, erasotzaileak ezin izango du zerbitzariaren kudeaketa kontsolara sartu, hau sareko segurtasun-eremu ezberdin bat delako.

  V: – Eta testuinguru honetan, niretzat interesgarriagoa dena da zerbitzuekin zenbait kontratu dituzula -zer egin dezaketen, zein “ekintzen” bidez harremanetan jar daitezkeen elkarren artean... Eta fluxu normal batean, zerbitzu zehatz batzuek eskatzen dute batzuk. errenkada, "ekintzen" zerrenda bestetik. Ez omen dira besteengana jotzen egoera normal batean, eta beste ardura-eremu batzuk dituzte. Horietako bat arriskuan jartzen bada, zerbitzu horren "ekintzak" eteteko gai izango al da?...

  EK: - Ulertzen dut. Egoera normal batean beste zerbitzari batekin komunikazioa onartzen bazen, orduan bai. SLA kontratuaren arabera, ez dugu kontrolatzen lehen 3 "ekintzak" bakarrik onartzen dituzula, eta 4 "ekintzak" ez dituzula onartzen. Hau seguruenik erredundantea da guretzat, dagoeneko 4 mailatako babes sistema bat baitugu, printzipioz, zirkuituetarako. Guk nahiago dugu ingeradarekin defenditu, barruen mailan baino.

  Visa, MasterCard eta Sberbank-ek nola funtzionatzen duten

  V: – Erabiltzaile bat datu-zentro batetik bestera aldatzeari buruzko puntu bat argitu nahi dut. Nik dakidala, Visa eta MasterCard-ek 8583 protokolo sinkrono bitarra erabiliz funtzionatzen dute, eta hor nahasketak daude. Eta jakin nahi nuen, orain aldatzea esan nahi dugu: zuzenean "Visa" eta "MasterCard" edo ordainketa-sistemaren aurretik, prozesatu aurretik?

  EK: - Hau nahasketak baino lehen. Gure nahasketak datu-zentro berean daude.

  V: – Gutxi gorabehera, ba al duzu konexio punturik?

  EK: – “Visa” eta “MasterCard” - bai. Besterik gabe, Visa eta MasterCard-ek azpiegituretan nahiko inbertsio serioak behar dituztelako kontratu bereiziak egiteko bigarren nahasketa pare bat lortzeko, adibidez. Datu-zentro baten barruan gordeta daude, baina, Jainkoak ez dezala, gure datu-zentroa, non Visa eta MasterCard-ekin konektatzeko nahasketak daudenean, hiltzen bada, Visa eta MasterCard-ekin konexioa galduko dugu...

  V: – Nola erreserbatu daitezke? Badakit Visak printzipioz konexio bakarra onartzen duela!

  EK: – Beraiek hornitzen dituzte ekipoak. Nolanahi ere, barruan guztiz erredundanteak diren ekipoak jaso ditugu.

  V: – Beraz, standa euren Connects Orangekoa da?...

  EK: - Bai.

  V: – Baina zer gertatzen da kasu honetan: zure datu-zentroa desagertzen bada, nola jarraitu dezakezu erabiltzen? Edo trafikoa gelditzen da?

  EK: - Ez. Kasu honetan, trafikoa beste kanal batera aldatuko dugu, eta hori, jakina, garestiagoa izango da guretzat eta gure bezeroentzat garestiagoa izango da. Baina trafikoa ez da Visa-rekin, MasterCard-ekin dugun konexio zuzenetik igaroko, Sberbank baldintzapekotik baizik (oso gehiegizkoa).

  Barkamena eskatzen dut Sberbankeko langileak iraintzen baditut. Baina gure estatistiken arabera, Errusiako bankuen artean, Sberbank erortzen da gehien. Ez da hilabete bat Sberbanken ezer erori gabe.

  
  
  

  Iragarki batzuk 🙂

  Eskerrik asko gurekin geratzeagatik. Gustuko dituzu gure artikuluak? Eduki interesgarri gehiago ikusi nahi? Lagun iezaguzu eskaera bat eginez edo lagunei gomendatuz, Garatzaileentzako hodeiko VPS 4.99 $-tik aurrera, sarrera-mailako zerbitzarien analogo paregabea, guk zuretzat asmatu duguna: VPS (KVM) E5-2697 v3 (6 Nukleoak) 10GB DDR4 480GB SSD 1Gbps 19Gbps-ri buruzko egia osoa XNUMX $-tik edo zerbitzari bat nola partekatu? (RAID1 eta RAID10-ekin erabilgarri, 24 nukleoraino eta 40 GB DDR4 arte).

  Dell R730xd 2 aldiz merkeagoa Amsterdameko Equinix Tier IV datu-zentroan? Hemen bakarrik 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 telebista 199 $-tik aurrera Herbehereetan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 $-tik aurrera! Irakurri buruz Nola eraiki azpiegitura korporazioa. klasea Dell R730xd E5-2650 v4 zerbitzarien erabilerarekin 9000 euroko balioa duten zentimo baten truke?

Iturria: www.habr.com