Almal praat oor ontwikkelings- en toetsprosesse, personeelopleiding, toenemende motivering, maar hierdie prosesse is nie genoeg wanneer 'n minuut van diensstilstand spasiegeld kos nie. Wat om te doen wanneer jy finansiële transaksies onder 'n streng SLA uitvoer? Hoe om die betroubaarheid en fouttoleransie van u stelsels te verhoog, deur ontwikkeling en toetsing uit die hakies te neem?
Die volgende HighLoad++-konferensie sal op 6 en 7 April 2020 in St. Petersburg plaasvind. Besonderhede en kaartjies . 9 November, 18:00. HighLoad++ Moskou 2018, Delhi + Kolkata-saal. Opsommings en .
Evgeny Kuzovlev (hierna verwys as EC): - Vriende, hallo! My naam is Evgeny Kuzovlev. Ek is van EcommPay, 'n spesifieke afdeling is EcommPay IT, die IT-afdeling van die groep maatskappye. En vandag gaan ons oor stilstand praat – oor hoe om dit te vermy, oor hoe om die gevolge daarvan te verminder as jy dit nie kan vermy nie. Die onderwerp word soos volg gestel: "Wat om te doen wanneer 'n minuut van stilstand $100 000 kos"? As ons vorentoe kyk, is ons getalle vergelykbaar.
Wat doen EcommPay IT?
Wie is ons? Hoekom staan ek hier voor jou? Hoekom het ek die reg om jou iets hier te vertel? En waaroor sal ons hier in meer besonderhede praat?
Die EkommPay-groep van maatskappye is 'n internasionale verkryger. Ons verwerk betalings regoor die wêreld - in Rusland, Europa, Suidoos-Asië (oor die hele wêreld). Ons het 9 kantore, 500 werknemers in totaal, en omtrent 'n bietjie minder as die helfte van hulle is IT-spesialiste. Alles wat ons doen, alles waarop ons geld verdien, het ons self gedoen.
Ons het al ons produkte (en ons het nogal baie daarvan - in die reeks groot IT-produkte het ons ongeveer 16 verskillende komponente) wat ons self geskryf het; ons skryf onsself, ons ontwikkel onsself. En op die oomblik doen ons ongeveer 'n miljoen transaksies per dag (miljoene - waarskynlik sou dit korrek wees om so te sê). Ons is 'n redelik jong maatskappy – ons is net so ses jaar oud.
6 jaar gelede was dit so 'n begin, toe die ouens saam met die besigheid gekom het. Hulle was verenig deur 'n idee (daar was niks anders as 'n idee nie) en ons het gehardloop. Soos enige opstart, het ons vinniger gehardloop ... Vir ons was spoed belangriker as kwaliteit.
Op 'n stadium het ons opgehou: ons het besef dat ons nie meer op een of ander manier met daardie spoed en met daardie kwaliteit kan leef nie, en ons moet eerstens kwaliteit doen. Op daardie oomblik het ons besluit om 'n nuwe platform te skryf wat korrek, skaalbaar, betroubaar sou wees. Hulle het hierdie platform begin skryf (hulle het begin belê, ontwikkeling ontwikkel, toets), maar op 'n stadium het hulle besef dat ontwikkeling en toetsing nie toelaat dat 'n nuwe vlak van diensgehalte bereik word nie.
Jy maak 'n nuwe produk, jy sit dit uit vir produksie, maar steeds loop iets iewers verkeerd. En vandag sal ons praat oor hoe om 'n nuwe kwalitatiewe vlak te bereik (hoe ons dit gedoen het, oor ons ervaring), neem ontwikkeling en toetsing uit die hakies; ons sal praat oor wat beskikbaar is vir uitbuiting - wat uitbuiting self kan doen, wat dit aan toetsing kan bied om kwaliteit te beïnvloed.
Staantyd. Bedryfsopdragte.
Altyd die belangrikste hoeksteen, waaroor ons eintlik vandag sal praat - stilstand. Verskriklike woord. As ons 'n stilstand het, is alles sleg vir ons. Ons hardloop om te verhoog, die admins hou die bediener vas – God verhoed dit dat dit nie val nie, soos in daardie liedjie dit gesing word. Dit is waaroor ons vandag sal praat.
Toe ons ons benaderings begin verander het, het ons 4 gebooie gevorm. Hulle word op die skyfies aangebied:
Hierdie gebooie is redelik eenvoudig:
- Identifiseer die probleem vinnig.
- Raak nog vinniger daarvan ontslae.
- Help om die rede te verstaan (later, vir ontwikkelaars).
- en benaderings te standaardiseer.
Laat ek jou aandag vestig op punt nommer 2. Ons raak ontslae van die probleem, nie los dit op nie. Besluit is sekondêr. Vir ons is dit primêr dat die gebruiker teen hierdie probleem beskerm word. Dit sal in een of ander geïsoleerde omgewing bestaan, maar hierdie omgewing sal dit op geen manier kontak nie. Eintlik sal ons deur hierdie vier groepe probleme gaan (vir sommige in meer besonderhede, vir sommige in minder detail), ek sal jou vertel wat ons gebruik, watter soort ervaring ons in oplossings het.
Probleemoplossing: wanneer gebeur dit en wat om daaraan te doen?
Maar ons sal buite werking begin, ons begin met punt nommer 2 - hoe om vinnig van die probleem ontslae te raak? Daar is 'n probleem - ons moet dit regstel. "Wat maak ons daarmee?" - die hoofvraag. En toe ons begin dink het oor hoe om die probleem op te los, het ons 'n paar vereistes vir onsself ontwikkel wat die probleemoplossing moet volg.
Om hierdie vereistes te formuleer, het ons besluit om onsself die vraag af te vra: “Wanneer het ons probleme”? En probleme, soos dit geblyk het, kom in vier gevalle voor:
- Hardeware mislukking.
- Mislukking van eksterne dienste.
- Verandering van sagteware weergawe (dieselfde ontplooiing).
- Plofbare werklading.
Ons gaan nie oor die eerste twee praat nie. 'n Hardewarefout word eenvoudig opgelos: jy moet alles laat dupliseer. As dit skywe is - die skywe moet in 'n RAID saamgestel word, as dit 'n bediener is - die bediener moet gedupliseer word, as jy 'n netwerkinfrastruktuur het - jy moet 'n tweede kopie van die netwerkinfrastruktuur plaas, dit wil sê, jy neem en dupliseer. En as iets jou in die steek laat, skakel jy oor na reserwevermoëns. Dit is moeilik om meer hier te sê.
Die tweede is die mislukking van eksterne dienste. Vir die meeste is die stelsel glad nie 'n probleem nie, maar nie vir ons nie. Aangesien ons betalings verwerk, is ons so 'n aggregator wat tussen die gebruiker (wat sy kaartdata invoer) en banke, betaalstelsels (Visa, MasterCard, Mira) staan. Ons eksterne dienste (betalingstelsels, banke) is geneig om te misluk. Nie ons of jy (as jy sulke dienste het) kan dit beïnvloed nie.
Wat om dan te doen? Daar is twee opsies hier. Eerstens, as jy kan, moet jy hierdie diens op een of ander manier dupliseer. Byvoorbeeld, as ons kan, dra ons verkeer oor van een diens na 'n ander: ons verwerk byvoorbeeld kaarte deur Sberbank, Sberbank het probleme - ons dra verkeer [voorwaardelik] oor na Raiffeisen. Die tweede ding wat ons kan doen, is om die mislukking van eksterne dienste baie vinnig op te let, en daarom sal ons in die volgende deel van die verslag oor die spoed van reaksie praat.
Trouens, uit hierdie vier kan ons spesifiek die verandering van sagteware-weergawes beïnvloed - neem aksies wat sal lei tot 'n verbetering in die situasie in die konteks van ontplooiings en in die konteks van 'n plofbare toename in vrag. Eintlik het ons dit gedoen. Hier weer 'n klein opmerking ...
Van hierdie vier probleme word verskeie onmiddellik opgelos as jy 'n wolk het. As jy in die Microsoft Azhur, Ozone wolke is, gebruik ons wolke, van Yandex of Mail, dan word ten minste 'n hardeware wanfunksie hul probleem en alles word dadelik reg in die konteks van 'n hardeware wanfunksie.
Ons is 'n effens nie-standaard maatskappy. Almal hier praat oor Kubernetes, oor wolke – ons het nie Kubernets of wolke nie. Aan die ander kant het ons rakke met yster in baie datasentrums, en ons word gedwing om op hierdie yster te leef, ons word gedwing om verantwoordelik te wees vir dit alles. Daarom, in hierdie konteks, sal ons praat. So, oor probleme. Die eerste twee is tussen hakies.
Verandering van sagteware weergawe. basisse
Ons ontwikkelaars het nie toegang tot produksie nie. Hoekom is dit? Maar ons is bloot PCI DSS-gesertifiseer, en ons ontwikkelaars het eenvoudig nie die reg om in die “prod” te klim nie. Alles punt. Enigsins. Daarom eindig die verantwoordelikheid van ontwikkeling presies op die oomblik wanneer die ontwikkeling die bou vir vrystelling oorhandig het.
Ons tweede basis, wat ons het, wat ons ook baie help, is die afwesigheid van unieke ongedokumenteerde kennis. Ek hoop jy doen dieselfde. Want as dit nie is nie, is jy in die moeilikheid. Probleme ontstaan wanneer hierdie unieke, ongedokumenteerde kennis nie op die regte tyd op die regte plek teenwoordig is nie. Kom ons sê jy het een persoon wat weet hoe om 'n spesifieke komponent te ontplooi - daar is geen persoon nie, hy is met vakansie of siek - dit is dit, jy het probleme.
En die derde basis, waartoe ons gekom het. Ons het daartoe gekom deur pyn, bloed, trane – ons het tot die gevolgtrekking gekom dat enige van ons bouwerk foute bevat, al is dit sonder foute. Ons het dit self besluit: wanneer ons iets ontplooi, wanneer ons iets in produksie rol, het ons 'n bou met foute. Ons het die vereistes gevorm waaraan ons stelsel moet voldoen.
Sagteware opgradering vereistes
Daar is drie van hierdie vereistes:
- Ons moet die ontplooiing vinnig terugrol.
- Ons moet die impak van 'n onsuksesvolle ontplooiing tot die minimum beperk.
- En ons behoort vinnig in parallel te kan ontplooi.
Dit is in daardie volgorde! Hoekom? Omdat, eerstens, wanneer 'n nuwe weergawe ontplooi word, is spoed nie belangrik nie, maar dit is belangrik dat jy, as iets verkeerd geloop het, vinnig terugrol en minimale impak hê. Maar as jy 'n stel produksieweergawes het waarvoor dit geblyk het dat daar 'n fout is (soos uit die bloute, daar was geen ontplooiing nie, maar die fout is vervat) - die spoed van die daaropvolgende ontplooiing is vir jou belangrik. Wat het ons gedoen om aan hierdie vereistes te voldoen? Ons het gebruik gemaak van die volgende metodologie:
Dit is welbekend, ons het dit nog nooit uitgevind nie - dit is Blou/Groen ontplooiing. Wat dit is? Jy moet 'n kopie hê vir elke groep bedieners waarop jou toepassings geleë is. Die kopie is "warm": daar is geen verkeer daarop nie, maar hierdie verkeer kan enige tyd na hierdie kopie gestuur word. Hierdie kopie bevat die vorige weergawe. En ten tyde van ontplooiing rol jy die kode uit na 'n onaktiewe kopie. Skakel dan 'n deel van die verkeer (of alles) oor na die nuwe weergawe. Dus, om die verkeersvloei van die ou weergawe na die nuwe een te verander, hoef jy net een aksie te doen: jy moet die balanseerder in die stroomop verander, die rigting verander - van een stroomop na 'n ander. Dit is baie gerieflik en los die probleem van vinnige oorskakeling, vinnige terugrol op.Hier is die oplossing vir die tweede vraag minimalisering: jy kan net 'n deel van jou verkeer op 'n nuwe lyn plaas, op 'n lyn met 'n nuwe kode (laat dit wees, byvoorbeeld, 2%). En hierdie 2% is nie 100% nie! As jy 100% van jou verkeer verloor het tydens 'n onsuksesvolle ontplooiing, is dit skrikwekkend, as jy 2% van jou verkeer verloor het, is dit onaangenaam, maar dit is nie skrikwekkend nie. Boonop sal gebruikers dit heel waarskynlik nie eers agterkom nie, want in sommige gevalle (nie in almal nie) sal dieselfde gebruiker, deur F5 te druk, na 'n ander, werkende weergawe gaan.
Blou/Groen ontplooi. Roetering
Terselfdertyd is alles nie so eenvoudig nie "Blue / Green Deploy" ... Al ons komponente kan in drie groepe verdeel word:
- dit is 'n front-end (betaalbladsye wat ons kliënte sien);
- verwerkingskern;
- adapter om met betalingstelsels te werk (banke, MasterCard, Visa ...).
En hier is daar 'n nuanse - die nuanse lê in die roetering tussen die lyne. As jy net 100% van die verkeer oorskakel, het jy nie hierdie probleme nie. Maar as jy 2% wil verander, begin jy vrae vra: "Hoe om dit te doen?" Die eenvoudigste, in die voorkop: jy kan, deur ewekansige keuse, Round Robin in nginx opstel, en jy het 2% na links, 98% na regs. Maar dit werk nie altyd nie.
In ons land, byvoorbeeld, die gebruiker interaksie met die stelsel met meer as een versoek. Dit is normaal: 2, 3, 4, 5 versoeke - jou stelsels kan dieselfde wees. En as dit vir jou belangrik is dat alle gebruikersversoeke na dieselfde lyn kom as waartoe die eerste versoek gekom het, of (tweede oomblik) alle gebruikersversoeke na die oorskakeling na 'n nuwe lyn kom (hy kan vroeër met die stelsel begin werk, voor die skakelaar), - dan is hierdie ewekansige verspreiding nie geskik vir jou nie. Dan is daar die volgende opsies:
Die eerste opsie, die eenvoudigste een, is gebaseer op die basiese parameters van die kliënt (IP Hash). Jy het 'n IP, en jy skei dit volgens IP-adres van regs na links. Dan sal die tweede geval wat ek beskryf vir jou werk, wanneer 'n ontplooiing plaasgevind het, kan die gebruiker reeds met jou stelsel begin werk, en vanaf die oomblik van ontplooiing sal alle versoeke na 'n nuwe lyn gaan (na dieselfde een, sê maar) .As dit om een of ander rede jou nie pas nie en jy moet versoeke stuur na die lyn waar die gebruiker se aanvanklike, init-versoek gekom het, dan het jy twee opsies ...
Eerste opsie: jy kan betaalde nginx+ neem. Daar is 'n Sticky-sessie-meganisme, wat, op die aanvanklike versoek van die gebruiker, die gebruiker blootstel aan 'n sessie en dit aan een of ander stroomop bind. Alle daaropvolgende gebruikerversoeke binne die sessieleeftyd sal na dieselfde stroomop gaan waar die sessie blootgestel is.Dit het ons nie gepas nie, want ons het reeds 'n gewone nginx gehad. Om oor te skakel na nginx+ is nie so duur nie, dit was net 'n bietjie pynlik vir ons en nie baie korrek nie. “Sticks Sessions”, byvoorbeeld, het nie vir ons gewerk nie om die eenvoudige rede dat “Sticks Sessions” nie roetering op grond van “Of-of” toelaat nie. Daar kan jy spesifiseer wat ons doen “Stick Sessions”, byvoorbeeld deur IP-adres of IP-adres en deur koekies of deur post-parameter, maar “Of-of” is reeds moeiliker daar.
Daarom het ons by die vierde opsie gekom. Ons het nginx op steroïede geneem (dit is openresty) - dit is dieselfde nginx, wat ook die insluiting van laaste skrifte ondersteun. Jy kan 'n laaste skrif skryf, 'n "openrest" daarin plaas, en daardie laaste script sal uitgevoer word wanneer die gebruiker se versoek inkom.
En ons het eintlik so 'n skrif geskryf, vir onsself 'n "openrest" gestel en in hierdie script sorteer ons deur 6 verskillende parameters deur "Of" aaneen te skakel. Afhangende van die teenwoordigheid van een of ander parameter, weet ons dat die gebruiker na een of ander bladsy, na een lyn of na 'n ander gekom het.
Blou/Groen ontplooi. Voordele en nadele
Natuurlik was dit waarskynlik moontlik om dit 'n bietjie eenvoudiger te maak (gebruik dieselfde "Stick Sessions"), maar ons het steeds so 'n nuanse dat nie net die gebruiker met ons interaksie het binne die raamwerk van een verwerking van een transaksie nie ... Maar betalingstelsels het ook interaksie met ons: ons, nadat ons die transaksie verwerk het (deur 'n versoek na die betalingstelsel te stuur), kry ons 'n terugkoeling.
En veronderstel, as ons binne ons kontoer die gebruiker se IP-adres in alle versoeke kan gooi en gebruikers kan afsonderlik op grond van die IP-adres, dan sal ons nie vir dieselfde "Visa" sê nie: "Dudes, ons is so 'n retro-maatskappy, ons is soort van internasionale (op die webwerf en in Rusland) ... En stuur asseblief vir ons die gebruiker se IP-adres in 'n addisionele veld, jou protokol is gestandaardiseer! Natuurlik sal hulle nie saamstem nie.
Daarom het dit ons nie gepas nie – ons het openresty gemaak. Gevolglik, met roetering, het ons dit soos volg gekry:Blue / Green Deploy het onderskeidelik die voordele wat ek genoem het, en die nadele.
Nadeel twee:
- jy moet moeite doen met roetering;
- Die tweede grootste nadeel is die koste.
Jy het twee keer soveel bedieners nodig, jy het twee keer soveel operasionele hulpbronne nodig, jy moet twee keer soveel moeite spandeer om hierdie hele dieretuin in stand te hou.
Terloops, onder die voordele - nog een ding wat ek nie voorheen genoem het nie: jy het 'n reserwe in die geval van 'n toename in vrag. As jy 'n plofbare lasgroei het, het 'n groot aantal gebruikers op jou geval, dan sluit jy eenvoudig die tweede reël by die 50 tot 50 verspreiding in - en jy het dadelik x2 bedieners in jou groep totdat jy die probleem oplos om meer bedieners te hê .
Hoe om 'n vinnige ontplooiing te maak?
Ons het gepraat oor hoe om die probleem van minimalisering en vinnige terugrol op te los, maar die vraag bly: "Hoe om vinnig te ontplooi"?
Dit is kort en eenvoudig.- Jy moet 'n CD-stelsel (Continuous Delivery) hê - daarsonder, nêrens nie. As jy een bediener het, kan jy handvatsels ontplooi. Ons het natuurlik ongeveer een en 'n half duisend bedieners en een en 'n half duisend handvatsels - ons kan 'n afdeling plant so groot soos hierdie kamer, net om te ontplooi.
- Die ontplooiing moet parallel wees. As u 'n opeenvolgende ontplooiing het, is alles sleg. Een bediener is goed, jy sal die hele dag een en 'n half duisend bedieners ontplooi.
- Weereens, vir versnelling is dit nie meer nodig nie, dink ek. Deploy bou gewoonlik die projek. Jy het 'n webprojek, daar is 'n front-end deel (jy maak 'n webpack daar, npm collect - so iets), en hierdie proses is in beginsel van korte duur - 5 minute, maar hierdie 5 minute kan krities wees . Daarom doen ons dit byvoorbeeld nie: ons het hierdie 5 minute verwyder, ons ontplooi artefakte.
Wat is 'n artefak? 'n Artefak is 'n saamgestelde gebou waarin die hele monteerdeel reeds voltooi is. Ons stoor hierdie artefak in die artefakbewaarplek. Ons het twee sulke bewaarplekke op een slag gebruik – dit was Nexus en nou jFrog Artifactory).Ons het aanvanklik Nexus gebruik omdat ons hierdie benadering in java-toepassings begin beoefen het (dit was baie geskik hiervoor). Toe is van die toepassings wat in PHP geskryf is daar geplaas; en die Nexus was nie meer geskik nie, en daarom het ons jFrog Artefactory gekies, wat byna alles kan artifactor. Ons het selfs tot die gevolgtrekking gekom dat ons ons eie binêre pakkette in hierdie artefakbewaarplek stoor, wat ons vir bedieners versamel.
Plofbare vraggroei
Ons het gepraat oor die verandering van die sagteware weergawe. Die volgende ding wat ons het, is 'n plofbare toename in vrag. Hier verstaan ek waarskynlik dat die plofbare groei van die vrag nie heeltemal die regte ding is nie ...
Ons het 'n nuwe stelsel geskryf - dit is diensgerig, modieus mooi, werkers is oral, toue is oral, asinchronie is oral. En in sulke stelsels kan data in verskillende vloeie verloop. Vir die eerste transaksie kan die 1ste, 3de, 10de werker betrokke wees, vir die tweede transaksie - die 2de, 4de, 5de. En vandag, kom ons sê, in die oggend het jy 'n datastroom wat die eerste drie werkers gebruik, en in die aand verander dit dramaties, en alles gebruik die ander drie werkers.
En hier blyk dit dat jy op een of ander manier die werkers moet skaal, jy moet op een of ander manier jou dienste skaal, maar terselfdertyd nie toelaat dat hulpbronne opblaas nie.
Ons het ons vereistes gestel. Hierdie vereistes is redelik eenvoudig: om diensontdekking, parameterisering te hê - alles is standaard vir die bou van sulke skaalbare stelsels, behalwe vir een punt - dit is hulpbronwaardevermindering. Ons het gesê dat ons nie gereed is om hulpbronne te depresieer sodat die bedieners die lug warm maak nie. Ons het vir Konsul gevat, ons het Nomad geneem, wat ons werkers bestuur.Hoekom is dit vir ons 'n probleem? Kom ons trek 'n bietjie terug. Daar is nou sowat 70 betaalstelsels agter ons. In die oggend gaan verkeer deur Sberbank, dan het Sberbank byvoorbeeld geval, en ons skakel dit oor na 'n ander betaalstelsel. Ons het 100 werkers gehad voor Sberbank, en daarna moet ons 100 werkers dramaties insamel vir 'n ander betalingstelsel. En dit alles is wenslik om sonder menslike deelname te gebeur. Want as daar menslike deelname is, moet 'n ingenieur 24/7 daar sit, wat dit net moet doen, want sulke mislukkings, wanneer 70 stelsels agter jou is, kom gereeld voor.
Daarom het ons na Nomad, wat 'n openbare IP het, gekyk en ons eie Scale-Nomad-ding geskryf - ScaleNo, wat iets soos volg doen: dit monitor die groei van die tou en verminder of vermeerder die aantal werkers, afhangende van die dinamika van die tou. Toe ons dit gedoen het, het ons gedink: "Miskien moet dit oopbron verkry word?" Toe kyk hulle na haar – sy is eenvoudig, soos twee pennies.
Tot dusver het ons dit nie oopbronverkry nie, maar as jy dit na die berig, nadat jy besef het dat jy so iets nodig het, dit skielik nodig het, is daar my kontakte in die laaste skyfie - skryf asseblief vir my. As daar ten minste 3-5 mense is, sal ons dit open source.
Hoe dit werk? Kom ons kyk! As ons vorentoe kyk: aan die linkerkant is daar 'n stukkie van ons monitering: dit is een reël, bo is die tyd vir die verwerking van gebeure, in die middel is die aantal transaksies, aan die onderkant is die aantal werkers.As jy kyk, is daar 'n fout in hierdie prentjie. Op die boonste grafiek het een van die kaarte binne 45 sekondes neergestort - een van die betaalstelsels het afgegaan. Dadelik is verkeer binne 2 minute gebring en die tou het begin groei op 'n ander betaalstelsel waar daar geen werkers was nie (ons het nie die hulpbronne benut nie - inteendeel, ons het die hulpbron korrek benut). Ons wou nie verhit nie - daar was 'n minimum aantal, so 5-10 werkers, maar hulle kon nie klaarkom nie.
Op die laaste grafiek kan jy die "bult" sien wat net sê dat "Scaleno" hierdie bedrag verdubbel het. En toe, toe die grafiek 'n bietjie gedaal het, het hy dit 'n bietjie verminder - die aantal werkers is outomaties verander. Dis hoe hierdie ding werk. Ons het gepraat oor punt nommer 2 - "Hoe om vinnig ontslae te raak van die redes."
Monitering. Hoe om die probleem vinnig te identifiseer?
Nou die eerste punt - "Hoe om die probleem vinnig te identifiseer?" Monitering! Ons moet sekere dinge vinnig verstaan. Wat is die dinge wat ons vinnig moet verstaan?
Drie dinge!- Ons moet die gesondheid van ons eie hulpbronne vinnig verstaan en vinnig verstaan.
- Ons moet vinnig die mislukking verstaan, die werkverrigting monitor van stelsels wat buite ons is.
- Die derde punt is die identifisering van logiese foute. Dit is wanneer die stelsel vir jou werk, volgens alle aanwysers is alles in orde, maar iets loop verkeerd.
Hier, ek sal jou seker nie veel vertel wat so cool is nie. Ek sal Captain Obvious wees. Ons het gesoek na wat op die mark is. Ons het 'n prettige dieretuin. Dit is die dieretuin wat ons nou het:
Ons gebruik Zabbix om hardeware te monitor, om die hoofaanwysers van bedieners te monitor. "Okmeter" gebruik ons vir databasisse. Ons gebruik "Grafana" en "Prometheus" vir alle ander aanwysers wat nie by die eerste twee pas nie, en sommige van hulle - met "Grafana" en "Prometheus", sommige - "Grafana" met "Influx" en Telegraf.'n Jaar gelede wou ons New Relic gebruik. Cool ding, sy kan alles doen. Maar sover sy alles weet, is sy so duur. Toe ons tot 'n volume van 1,5 duisend bedieners gegroei het, het 'n verkoper na ons toe gekom en gesê: "Kom ons sluit 'n ooreenkoms vir die volgende jaar." Ons het gekyk na die prys, dat nee, ons sal dit nie doen nie. Nou gee ons New Relic prys, ons het ongeveer 15 bedieners oor onder New Relic-monitering. Die prys was absoluut verregaande.
En daar is een instrument wat ons self geïmplementeer het - dit is Debugger. Ons het hom eers “Bagger” genoem, maar toe het ons Engels-onderwyser ons verbygesteek, wild gelag en hom herdoop tot “Debugger”. Wat dit is? Dit is 'n instrument wat in werklikheid binne 15-30 sekondes op elke komponent, soos 'n "swart boks" van die stelsel, toetse begin vir die algehele werkverrigting van die komponent.
Byvoorbeeld, as die eksterne bladsy (betaling bladsy) - hy maak dit net oop en sien hoe dit moet lyk. As dit besig is om te verwerk, vuur dit 'n toets "transaksie" af - dit soek vir hierdie "transaksie" om te bereik. As dit 'n verband met betalingstelsels is, stuur ons dienooreenkomstig 'n toetsversoek waar ons kan, en sien dat alles reg is met ons.
Watter maatstawwe is belangrik om te monitor?
Wat monitor ons hoofsaaklik? Watter maatstawwe is vir ons belangrik?
- Reaksietyd / RPS op die fronte is 'n baie belangrike aanwyser. Hy antwoord dadelik dat daar iets fout is met jou.
- Die aantal verwerkte boodskappe in alle rye.
- Die aantal werkers.
- Basiese korrektheidsmaatstawwe.
Die laaste punt is 'n "besigheid", "besigheid" maatstaf. As jy dieselfde ding wil monitor, moet jy een of twee maatstawwe definieer wat die hoofaanwysers vir jou is. Ons het so 'n maatstaf - dit is deurset (dit is die verhouding van die aantal suksesvolle transaksies tot die totale vloei van transaksies). As iets daarin verander in die interval van 5-10-15 minute, dan het ons probleme (as dit dramaties verander).
Hoe dit vir ons lyk - 'n voorbeeld van een van ons borde:
Aan die linkerkant - onderskeidelik 6 grafieke langs die lyne - die aantal werkers en die aantal boodskappe in die rye. Aan die regterkant - RPS, RTS. Hieronder is dieselfde "besigheids"-metriek. En op die "besigheids"-metriek kan ons dadelik sien dat iets verkeerd geloop het op die twee middelste kaarte ... Dit is net nog 'n stelsel wat agter ons geval het.Die tweede ding wat ons moes doen, was om die val van eksterne betalingstelsels te monitor. Hier het ons OpenTracing geneem - 'n meganisme, 'n standaard, 'n paradigma wat jou toelaat om verspreide stelsels op te spoor; en dit is 'n bietjie verander. Die standaard OpenTracing-paradigma sê dat ons 'n spoor vir elke individuele versoek bou. Ons het dit nie nodig gehad nie, en ons het dit toegedraai in 'n opsomming, samevoegingspoor. Ons het 'n instrument gemaak waarmee ons die spoed van die stelsels agter ons kan volg.
Die grafiek wys vir ons dat een van die betalingstelsels binne 3 sekondes begin reageer het - ons het probleme. Terselfdertyd sal hierdie ding reageer wanneer die probleme begin, met 'n interval van 20-30 sekondes.En die derde klas moniteringsfoute wat bestaan, is logiese monitering.
Om eerlik te wees, ek het nie geweet wat om op hierdie skyfie te teken nie, want ons het lank gesoek na iets op die mark wat ons sou pas. Ons kon niks kry nie, so ons moes dit self doen.
Wat bedoel ek met logiese monitering? Wel, stel jou voor: jy maak vir jouself 'n stelsel (byvoorbeeld 'n kloon van Tinder); jy het dit gemaak, dit van stapel gestuur. Suksesvolle bestuurder Vasya Pupkin het dit op sy foon gesit, sien 'n meisie daar, hou van haar ... en dies meer gaan nie na die meisie nie - so gaan na die veiligheidswag Mikhalych van dieselfde sakesentrum. Die bestuurder gaan ondertoe, en wonder dan: “Waarom glimlag hierdie veiligheidswag Mikhalych so aangenaam vir hom”?In sulke situasies... Vir ons klink hierdie situasie bietjie anders, want (ek het geskryf) dit is so 'n reputasieverlies wat indirek tot finansiële verliese lei. Ons situasie is die teenoorgestelde: ons kan direkte finansiële verliese ly – byvoorbeeld as ons 'n transaksie as suksesvol uitgevoer het, maar dit was onsuksesvol (of andersom). Ek moes my eie instrument skryf wat die aantal suksesvolle transaksies in dinamika oor 'n tydinterval opspoor gebaseer op besigheidsaanwysers. Het niks op die mark gekry nie! Dit is presies wat ek wou oordra. Daar is niks op die mark om sulke probleme op te los nie.
Dit was op die vraag hoe om die probleem vinnig te identifiseer.
Hoe om die redes vir die ontplooiing te bepaal
Die derde groep take wat ons oplos is nadat ons die probleem geïdentifiseer het, nadat ons daarvan ontslae geraak het, sal dit goed wees om die rede vir ontwikkeling, vir toetsing te verstaan en iets daaromtrent te doen. Gevolglik moet ons ondersoek instel, ons moet die stompe verhoog.
As ons praat oor logs (die hoofrede is logs), die grootste deel van die logs wat ons in die ELK Stack het - byna almal het dit. Sommige het dalk nie ELK nie, maar as jy logs in gigagrepe skryf, dan kom jy vroeër of later na ELK toe. Ons skryf hulle in teragrepe.
Hier is 'n probleem. Ons het reggemaak, die fout vir die gebruiker reggestel, begin uitgrawe wat daar was, in Kibana geklim, die transaksie-ID daar ingevoer en so 'n voetlap gekry (wys baie). En in hierdie voetdoek is absoluut niks duidelik nie. Hoekom? Ja, want dit is nie duidelik watter deel aan watter werker behoort, watter deel aan watter komponent behoort nie. En op daardie oomblik het ons besef dat ons opsporing nodig het - dieselfde OpenTracing waarvan ek gepraat het.Ons het 'n jaar gelede daaraan gedink, ons oë na die mark gerig, en daar blyk twee instrumente te wees - Zipkin en Jaeger. “Huntsman” is in werklikheid so ’n ideologiese erfgenaam, die ideologiese opvolger van “Zipkin”. In "Zipkin" is alles goed, behalwe dat hy nie weet hoe om saam te voeg nie, nie weet hoe om logs in die spoor in te sluit nie, net tydspoor. En die Jaeger het dit ondersteun.
Ons het na Jaeger gekyk: jy kan toepassings instrumenteer, jy kan in Api skryf (die Api-standaard vir PHP destyds is egter nie goedgekeur nie – dit was 'n jaar gelede, maar nou is dit reeds goedgekeur), maar daar was absoluut geen kliënt nie. "Goed," het ons gedink en ons eie kliënt geskryf. Wat het ons gekry? Dit is hoe dit lyk:
In Jaeger word spanne vir elke boodskap geskep. Dit wil sê, wanneer 'n gebruiker die stelsel oopmaak, sien hy een of twee blokke vir elke inkomende versoek (1-2-3 - hoeveel inkomende versoeke van die gebruiker was, soveel blokke). Om dit vir gebruikers makliker te maak, het ons merkers by die logs en tydspoor gevoeg. Gevolglik, in die geval van 'n fout, sal ons toepassing die log met die toepaslike foutmerker merk. Jy kan filtreer volgens die Error tag en slegs streke wat hierdie blok met 'n fout bevat, sal vertoon word. Hier is hoe dit lyk as ons die span uitbrei:
Daar is 'n stel spore binne die span. In hierdie geval is dit drie toetsspore, en die derde spoor vertel ons dat 'n fout voorgekom het. Terselfdertyd, hier sien ons 'n tydspoor: ons het 'n tydskaal bo-op, en ons sien op watter tydinterval hierdie of daardie log aangeteken is.Gevolglik het ons goed gevaar. Ons het ons eie uitbreiding geskryf, en ons het dit oop verkry. As jy met opsporing wil werk, as jy met "Huntsman" in PHP wil werk, is daar ons uitbreiding, welkom om te gebruik, soos hulle sê:
Ons het hierdie uitbreiding - dit is 'n kliënt vir die OpenTracing Api, gemaak as 'n php-uitbreiding, dit wil sê, jy sal dit moet saamstel en in die stelsel plaas. 'n Jaar gelede was daar niks anders nie. Nou is daar ander kliënte wat soos komponente is. Hier is dit aan jou: óf jy laai komponente af as 'n komponis, óf jy gebruik uitbreiding volgens jou.Korporatiewe standaarde
Ons het oor die drie gebooie gepraat. Die vierde gebod is om benaderings te standaardiseer. Waaroor gaan dit? Dit gaan hieroor:
Hoekom is die woord "korporatief" hier? Nie omdat ons 'n groot of burokratiese maatskappy is nie, nee! Ek wil graag die woord "korporatief" hier gebruik in die konteks van die feit dat elke maatskappy, elke produk sy eie standaarde moet hê, insluitend joune. Watter standaarde het ons?
- Ons het 'n ontplooiingskedule. Ons kan nêrens heen beweeg sonder hom nie, ons kan nie. Ons ontplooi ongeveer 60 keer per week, dit wil sê, ons ontplooi byna konstant. Terselfdertyd het ons byvoorbeeld in die ontplooiingsregulasies ’n taboe vir ontplooiing op Vrydag – in beginsel ontplooi ons nie.
- Ons het dokumentasie nodig. Nie 'n enkele nuwe komponent kom in produksie as daar geen dokumentasie daarvoor is nie, selfs al is dit onder die pen van ons RnD-shnikov gebore. Ons benodig van hulle instruksies vir ontplooiing, 'n moniteringskaart en 'n benaderde beskrywing (wel, hoe programmeerders kan skryf) van hoe hierdie komponent werk, hoe om dit op te los.
- Ons los nie die oorsaak van die probleem op nie, maar die probleem – wat ek reeds gesê het. Dit is vir ons belangrik om die gebruiker teen probleme te beskerm.
- Ons het permitte. Ons beskou dit byvoorbeeld nie as 'n stilstand as ons binne twee minute 2% van die verkeer verloor het nie. Dit val in beginsel nie in ons statistieke nie. As meer as 'n persentasie of tydelik, ons reeds oorweeg.
- En ons skryf altyd nadoodse ondersoeke. Wat ook al met ons gebeur, enige situasie wanneer dit abnormaal in produksie gedra het, sal dit in die potsmortem weerspieël word. ’n Nadoodse ondersoek is ’n dokument waarin jy skryf wat met jou gebeur het, gedetailleerde tydsberekening, wat jy gedoen het om dit reg te maak en (dit is ’n verpligte blokkie!) Wat jy sal doen om te verhoed dat dit in die toekoms gebeur. Dit is noodsaaklik vir verdere ontleding.
Wat word as stilstand beskou?
Waartoe het dit alles gelei?Dit het gelei tot (ons het 'n paar stabiliteitsprobleme gehad, dit het nie goed by die kliënte of ons gesit nie) vir die afgelope 6 maande was ons stabiliteittelling 99,97. Ons kan sê dat dit nie baie is nie. Ja, ons het iets om na te streef. Van hierdie aanwyser is ongeveer die helfte die stabiliteit as 't ware nie van ons s'n nie, maar van ons webtoepassings-firewall, wat voor ons staan en as 'n diens gebruik word, maar kliënte gee nie om daaroor nie.
Ons het geleer om in die nag te slaap. Uiteindelik! Ses maande gelede kon ons nie. En op hierdie nota met die resultate wil ek een opmerking maak. Gisteraand was daar 'n wonderlike verslag oor die beheerstelsel van 'n kernreaktor. As die mense wat hierdie stelsel geskryf het my kan hoor, vergeet asseblief wat ek gesê het oor "2% is nie stilstand nie". Vir jou is 2% stilstand, al is dit vir twee minute!
Dis al! Jou vrae.
Oor balanseerders en databasismigrasie
Vraag van die gehoor (hierna - B): - Goeienaand. Baie dankie vir so 'n admin verslag! 'n Kort vraag, oor jou balanseerders. Jy het genoem dat jy 'n WAF het, dit wil sê, soos ek dit verstaan, gebruik jy 'n eksterne een as 'n balanseerder ...
EC: – Nee, ons gebruik ons eie dienste as 'n balanseerder. In hierdie geval is WAF uitsluitlik 'n DDoS-beskermingsinstrument vir ons.
IN: – Kan ek 'n paar woorde sê oor balanseerders?
EC: - Soos ek gesê het, dit is 'n groep bedieners in openresty. Ons het nou 5 oortollige groepe wat eksklusief reageer ... dit wil sê, die bediener waarop slegs openresty geïnstalleer is, dit proxies net verkeer. Gevolglik, om te verstaan hoeveel ons hou: ons het nou 'n gereelde verkeersvloei - dit is 'n paar honderd megabits. Hulle hanteer, hulle is goed, hulle beur nie eens nie.
IN: - Ook 'n eenvoudige vraag. Hier is die Blou/Groen-ontplooiing. En wat doen jy, byvoorbeeld, met databasismigrasies?
EC: - Goeie vraag! Kyk, ons is in Blou/Groen-ontplooiing, ons het aparte toue vir elke lyn. Dit wil sê, as ons praat van gebeurtenisrye wat van werker na werker oorgedra word, is daar aparte toue vir die blou lyn en die groen lyn. As ons praat van die databasis self, dan het ons dit doelbewus vernou soveel as wat ons kon, alles feitlik in rye verskuif, ons stoor net die transaksiestapel in die databasis. En ons transaksiestapel is dieselfde vir alle lyne. Met die databasis in hierdie konteks: ons skei dit nie in blou en groen nie, want beide weergawes van die kode moet weet wat met die transaksie gebeur.
Vriende, ek het nog 'n klein prys om julle aan te spoor - 'n boek. En ek moet dit vir jou gee vir die beste vraag.
IN: - Hallo. Dankie vir die verslag. Die vraag is. Jy monitor betalings, jy monitor die dienste waarmee jy kommunikeer... Maar hoe monitor jy sodat 'n persoon op een of ander manier na jou betalingsbladsy gekom het, 'n betaling gemaak het en die projek hom met geld gekrediteer het? Dit wil sê, hoe monitor jy dat die optog beskikbaar is en aanvaar jy jou terugbel?
EC: - "Merchant" vir ons in hierdie geval is presies dieselfde eksterne diens as die betaling stelsel. Ons monitor die spoed van die handelaar se reaksie.
Oor databasiskodering
IN: - Hallo. Ek het 'n bietjie van 'n vraag. Jy het sensitiewe PCI DSS-data. Ek wou weet hoe jy PAN's in rye stoor, waarin jy moet slaag? Watter soort enkripsie gebruik jy? En vandaar die volgende tweede vraag: volgens PCI DSS is dit nodig om die databasis periodiek te herenkripteer in geval van veranderinge (afdanking van administrateurs, ensovoorts) - hoe gebeur toeganklikheid in hierdie geval?
EC: - Goeie vraag! Eerstens stoor ons nie PAN's in rye nie. Ons het in beginsel nie die reg om PAN op enige plek duidelik te stoor nie, so ons gebruik 'n spesiale diens (ons noem dit "Kademon") - dit is 'n diens wat net een ding doen: dit neem 'n boodskap as inset en gee 'n geënkripteerde boodskap. En ons stoor alles met hierdie geënkripteerde boodskap. Gevolglik het ons 'n sleutellengte van minder as 'n kilogreep, sodat dit direk ernstig en betroubaar is.IN: - Het jy nou 2 kilogrepe nodig?
EC: - Dit lyk asof daar gister 256 was ... Wel, waar anders ?!
Gevolglik is dit die eerste. En tweedens, die oplossing wat bestaan, dit ondersteun die herenkripsieprosedure - daar is twee pare "keks" (sleutels) wat "decks" gee wat enkripteer (sleutel is sleutels, dek is afgeleides van sleutels wat enkripteer). En in die geval van die aanvang van die prosedure (dit vind gereeld plaas, van 3 maande tot ± sommige), laai ons 'n nuwe paar "keks" op, en ons het die data weer geënkripteer. Ons het aparte dienste wat al die data uitruk, dit op 'n nuwe manier enkripteer; langs die data word die identifiseerder gestoor van die sleutel waarmee dit geïnkripteer is. Gevolglik, sodra ons die data met nuwe sleutels enkripteer, vee ons die ou sleutel uit.
Soms moet betalings met die hand gemaak word...
IN: - Dit wil sê, as 'n terugkeer vir een of ander operasie gekom het, dekripteer dit dan vir eers met die ou sleutel?
EC: - Ja.
IN: “Dan nog 'n klein vraag. Wanneer 'n soort mislukking, val, voorval plaasvind, is dit nodig om die transaksie in die handmodus te druk. Daar is so 'n situasie.
EC: - Ja soms.
IN: – Waar kry jy hierdie data vandaan? Of loop jy self met penne in hierdie kluis?
EC: - Nee, wel, natuurlik - ons het 'n soort back-office stelsel wat 'n koppelvlak vir ons ondersteuning bevat. As ons nie weet in watter status die transaksie is nie (byvoorbeeld totdat die betalingstelsel met 'n time-out gereageer het), weet ons nie a priori nie, dit wil sê, ons ken die finale status slegs met volle vertroue toe. In hierdie geval stort ons die transaksie in 'n spesiale status vir handmatige verwerking. In die oggend, die volgende dag, sodra die ondersteuning inligting ontvang dat sulke en sulke transaksies in die betalingstelsel bly, verwerk hulle dit handmatig in hierdie koppelvlak.
IN: – Ek het 'n paar vrae. Een daarvan is die voortsetting van die PCI DSS-sone: hoe haal jy die logs van hul stroombaan uit? So 'n vraag want die ontwikkelaar kon enigiets in die logs plaas! Tweede vraag: hoe ontplooi jy hotfixes? Hanteer in die databasis - dit is een opsie, maar daar kan gratis hot-fixes wees - wat is die prosedure daar? En die derde vraag hou waarskynlik verband met RTO, RPO. Jou beskikbaarheid was 99,97, amper vier nege, maar soos ek dit verstaan, het jy 'n tweede datasentrum, en 'n derde datasentrum, en 'n vyfde datasentrum ... Hoe sinchroniseer jy hulle, repliseer en alles anders?EC: - Kom ons begin met die eerste een. Die eerste vraag was oor die logs? Wanneer logs geskryf word, het ons 'n laag wat alle sensitiewe data masker. Sy kyk na die masker en bykomende velde. Gevolglik kom ons logs uit met data wat reeds gemasker is en die PCI DSS-kring. Dit is een van die gereelde take wat aan die toetsafdeling opgedra word. Daar word van hulle verwag om elke taak na te gaan, insluitend die logs wat hulle skryf, en dit is een van die gereelde take tydens kode-hersiening om te beheer dat die ontwikkelaar nie iets neergeskryf het nie. Die daaropvolgende verifikasie hiervan word gereeld ongeveer een keer per week deur die inligtingsekuriteitsdepartement uitgevoer: logs vir die laaste dag word selektief geneem, en dit word deur 'n spesiale skandeerder-ontleder vanaf die toetsbedieners uitgevoer om dit alles na te gaan.
Oor hot-fixes. Dit is ingesluit in ons ontplooiingsregulasies. Ons het 'n aparte item oor hotfixes. Ons glo dat ons hotfixes rondom die klok ontplooi wanneer ons dit nodig het. Sodra die weergawe gebou is, sodra dit gehardloop is, sodra ons 'n artefak het - het ons 'n diensstelseladministrateur wat van die ondersteuning aangeroep is, en hy ontplooi dit op die oomblik wanneer dit nodig is.Sowat "vier nege". Die syfer wat ons nou het, is werklik bereik, en ons het daarna gestreef by nog een datasentrum. Nou het ons 'n tweede datasentrum, en ons begin om tussen hulle te beweeg, en die kwessie van kruisdatasentrumreplikasie is inderdaad 'n nie-onbeduidende kwessie. Ons het probeer om dit op een slag op verskillende maniere op te los: ons het probeer om dieselfde Tarantula te gebruik - dit het nie vir ons gewerk nie, sê ek dadelik. Daarom het ons tot die feit gekom dat ons die volgorde van "sin" met die hand maak. Ons het elke toepassing, in werklikheid, in die asinchroniese modus van die nodige sinchronisasie "verander - klaar" dryf tussen datasentrums.
IN: - As jy 'n tweede een het, hoekom het dan nie 'n derde een verskyn nie? Want gesplete brein is steeds niemand ...
EC: "Maar ons het nie 'n gesplete brein nie." As gevolg van die feit dat elke toepassing 'n multimaster bedryf, maak dit nie vir ons saak na watter sentrum die versoek gekom het nie. Ons is gereed vir die feit dat, ingeval een van ons datasentrums ineenstort (ons maak staat daarop) en in die middel van die gebruiker se versoek oorskakel na die tweede datasentrum, ons gereed is om hierdie gebruiker inderdaad te verloor; maar dit sal eenhede wees, absolute eenhede.
IN: - Goeienaand. Dankie vir die verslag. Jy het gepraat oor jou ontfouter, wat 'n paar toetstransaksies in produksie uitvoer. Vertel ons van toetstransaksies! Hoe diep gaan dit?
EC: "Dit gaan deur 'n volle siklus van die hele komponent. Vir 'n komponent is daar geen verskil tussen 'n toetstransaksie en 'n gevegstransaksie nie. En vanuit die oogpunt van logika is dit net 'n aparte projek in die stelsel, waarop slegs toetstransaksies jaag.
IN: - Waar sny jy dit af? Kern gestuur...
EC: – Ons is agter “Kor” in hierdie geval vir toetstransaksies... Ons het so iets soos roetering: “Kor” weet na watter betalingstelsel om te stuur - ons stuur dit na 'n vals betaalstelsel wat net 'n http-beat gee en dit is Dit.
IN: - Vertel my asseblief, is jou aansoek in een groot monoliet geskryf, of het jy dit in sommige dienste of selfs mikrodienste opgesny?
EC: - Ons het nie 'n monoliet nie, natuurlik, ons het 'n diensgerigte toepassing. Ons het 'n grap dat ons 'n diens van monoliete het - hulle is regtig groot genoeg. Mikrodienste om dit die taal te noem, draai glad nie van die woord af nie, maar dit is die dienste waarbinne die werkers van verspreide masjiene werk.
As 'n diens op 'n bediener gekompromitteer word...
IN: “Dan het ek die volgende vraag. Selfs al was dit 'n monoliet, het jy steeds gesê dat jy baie van hierdie kitsbedieners het, hulle verwerk almal data in beginsel, en die vraag is: "As een van die kitsbedieners of 'n toepassing gekompromitteer word, kan enige individuele skakel hulle het 'n soort toegangsbeheer? Wie van hulle kan wat doen? Wie om te kontak, vir watter inligting?
EC: - Ja beslis. Sekuriteitsvereistes is redelik ernstig. Eerstens het ons oop dataverkeer, en slegs daardie poorte waardeur ons verkeersverkeer veronderstel. As die komponent met die databasis (sê Muskul) kommunikeer via 5-4-3-2, sal slegs 5-4-3-2 daarvoor oop wees, en ander poorte, ander verkeersaanwysings sal nie beskikbaar wees nie. Daarbenewens moet u verstaan dat daar in ons produksie ongeveer 10 verskillende sekuriteitslusse is. En selfs as die toepassing op een of ander manier gekompromitteer is, sal die aanvaller nie toegang tot die bedienerbestuurkonsole kry nie, want dit is 'n ander netwerksekuriteitsone.IN: - En in hierdie konteks stel ek meer belang in die oomblik dat jy 'n paar kontrakte met dienste het - wat hulle kan doen, deur watter "aksies" hulle mekaar kan kontak ... En in 'n normale vloei, 'n paar spesifieke dienste versoek sommige 'n ry, 'n lys van "aksies" op die ander. Dit lyk asof hulle nie in 'n normale situasie na ander wend nie, en hulle het ander areas van verantwoordelikheid. As een van hulle gekompromitteer word, sal hy die "aksies" van daardie diens kan trek? ..
EC: - Ek verstaan. As, in 'n normale situasie, kommunikasie met 'n ander bediener enigsins toegelaat is, dan ja. Volgens die SLA-kontrak monitor ons nie dat slegs die eerste 3 “aksies” vir jou toegelaat word nie, en 4 “aksies” nie vir jou toegelaat word nie. Dit is waarskynlik vir ons oorbodig, want ons het reeds 'n 4-vlak beskermingstelsel in beginsel vir stroombane. Ons verkies om met die kontoere te verdedig, eerder as op die vlak van die binnekant.
Hoe Visa, MasterCard en Sberbank werk
IN: - Ek wil die punt oor die oorskakeling van 'n gebruiker van een datasentrum na 'n ander verduidelik. Sover ek weet, werk "Visa" en "MasterCard" op die binêre sinchrone protokol 8583, daar is mengsels daar. En ek wou weet, nou bedoel ek oorskakeling - is dit direk "Visa" en "MasterCard" of na betalingstelsels, na verwerking?
EC: - Dit hang af van die mengsels. Ons het mengsels in een datasentrum.
IN: – Rofweg gesproke, het jy een verbindingspunt?
EC: - "Visa" en "MasterCard" - ja. Net omdat "Visa" en "MasterCard" nogal ernstige beleggings in infrastruktuur vereis om byvoorbeeld afsonderlike kontrakte vir die tweede paar mengsels te sluit. Hulle is in dieselfde datasentrum gereserveer, maar as, God verhoede, ons datasentrum sterf, waar daar mengsels is om aan Visa en MasterCard te koppel, dan sal ons 'n verbinding met Visa en MasterCard verloor ...
IN: Hoe kan hulle gereserveer word? Ek weet dat "Visa" in beginsel net een verbinding toelaat om te hou!
EC: “Hulle verskaf self die toerusting. Ons het in elk geval toerusting ontvang wat ironies genoeg binne gereserveer is.
IN: – So die stand is van hul Connects Orange...?
EC: - Ja.
IN: - Maar hoe in hierdie geval: as jou datasentrum verdwyn, hoe kan jy voortgaan om dit te gebruik? Of word die verkeer net gestop?
EC: - Geen. In hierdie geval sal ons bloot verkeer na 'n ander kanaal oorskakel, wat natuurlik duurder vir ons, duurder vir kliënte sal wees. Maar die verkeer sal nie deur ons direkte verbinding met Visa, MasterCard gaan nie, maar deur die voorwaardelike Sberbank (baie oordrewe).
Ek is baie jammer as ek die werknemers van Sberbank aanstoot gegee het. Maar volgens ons statistieke, van die Russiese banke, val Sberbank die meeste. Daar gaan nie 'n maand verby sonder dat iets by Sberbank afval nie.
Sommige advertensies 🙂
Dankie dat jy by ons gebly het. Hou jy van ons artikels? Wil jy meer interessante inhoud sien? Ondersteun ons deur 'n bestelling te plaas of by vriende aan te beveel, , 'n unieke analoog van intreevlakbedieners, wat deur ons vir jou uitgevind is: (beskikbaar met RAID1 en RAID10, tot 24 kerne en tot 40 GB DDR4).
Dell R730xd 2x goedkoper in Equinix Tier IV-datasentrum in Amsterdam? Net hier in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees van
Bron: will.com