HighLoad++, Evgeniy Kuzovlev (EcommPay IT): wat te doen als een minuut downtime $ 100000 kost

Iedereen praat over de processen van ontwikkelen en testen, het trainen van personeel en het vergroten van de motivatie, maar deze processen zijn niet voldoende als een minuut stilstand van de service enorme hoeveelheden geld kost. Wat moet u doen als u financiële transacties uitvoert onder een strikte SLA? Hoe kunt u de betrouwbaarheid en fouttolerantie van uw systemen vergroten, zonder dat u zich hoeft te ontwikkelen en testen?

De volgende HighLoad++ conferentie vindt plaats op 6 en 7 april 2020 in St. Petersburg. Details en kaartjes voor link. 9 november, 18 uur. HighLoad++ Moskou 00, Delhi + Kolkata hal. Scripties en presentatie.

Evgeniy Kuzovlev (hierna – EC): - Vrienden, hallo! Mijn naam is Kuzovlev Evgeniy. Ik kom uit het bedrijf EcommPay, een specifieke divisie is EcommPay IT, de IT-divisie van de bedrijvengroep. En vandaag zullen we het hebben over stilstandtijden - over hoe u deze kunt vermijden, over hoe u de gevolgen ervan kunt minimaliseren als deze niet kunnen worden vermeden. Het onderwerp luidt als volgt: “Wat te doen als een minuut downtime €100 kost”? Vooruitkijkend zijn onze cijfers vergelijkbaar.

Wat doet EcommPay IT?

Wie zijn we? Waarom sta ik hier voor je? Waarom heb ik het recht om je hier iets te vertellen? En waar zullen we het hier in meer detail over hebben?

De EcommPay-bedrijvengroep is een internationale overnemende partij. We verwerken betalingen over de hele wereld - in Rusland, Europa, Zuidoost-Azië (over de hele wereld). We hebben 9 kantoren, in totaal 500 medewerkers, waarvan ongeveer iets minder dan de helft IT-specialisten. Alles wat we doen, alles waar we geld aan verdienen, hebben we zelf gedaan.

We hebben al onze producten (en we hebben er behoorlijk veel - in onze lijn van grote IT-producten hebben we ongeveer 16 verschillende componenten) zelf geschreven; We schrijven onszelf, we ontwikkelen onszelf. En op dit moment voeren we ongeveer een miljoen transacties per dag uit (miljoenen is waarschijnlijk de juiste manier om het te zeggen). Wij zijn een vrij jong bedrijf, we bestaan ​​pas een jaar of zes.

6 jaar geleden was het zo’n startup toen de jongens met de zaak kwamen. Ze waren verenigd door een idee (er was niets anders dan een idee), en we renden weg. Zoals elke startup liepen wij sneller... Voor ons was snelheid belangrijker dan kwaliteit.

Op een gegeven moment zijn we ermee gestopt: we beseften dat we op de een of andere manier niet meer met die snelheid en met die kwaliteit konden leven en dat we ons eerst op kwaliteit moesten concentreren. Op dit moment besloten we een nieuw platform te schrijven dat correct, schaalbaar en betrouwbaar zou zijn. Ze begonnen dit platform te schrijven (ze begonnen te investeren, ontwikkeling te ontwikkelen, te testen), maar op een gegeven moment beseften ze dat ontwikkeling en testen ons niet in staat stelden een nieuw niveau van servicekwaliteit te bereiken.

Je maakt een nieuw product, je brengt het in productie, maar toch gaat er ergens iets mis. En vandaag zullen we praten over hoe we een nieuw kwaliteitsniveau kunnen bereiken (hoe we dat hebben gedaan, over onze ervaring), waarbij we ontwikkeling en testen buiten beschouwing laten; we zullen praten over wat beschikbaar is voor bediening - wat bediening zelf kan doen, wat het kan bieden aan testen om de kwaliteit te beïnvloeden.

Uitvaltijden. Bedieningsgeboden.

Wat altijd de belangrijkste hoeksteen is, waar we het vandaag over zullen hebben, is downtime. Een verschrikkelijk woord. Als we downtime hebben, is alles slecht voor ons. We rennen om het omhoog te brengen, de beheerders houden de server vast - God verhoede dat het niet valt, zoals ze in dat liedje zeggen. Dit is waar we het vandaag over zullen hebben.

Toen we onze aanpak begonnen te veranderen, formuleerden we vier geboden. Ik heb ze gepresenteerd op de dia's:

Deze geboden zijn vrij eenvoudig:

• Identificeer snel het probleem.
• Ben er nog sneller vanaf.
• Help de reden te begrijpen (later, voor ontwikkelaars).
• En standaardiseer benaderingen.

Ik zou graag uw aandacht willen vestigen op punt nr. 2. We lossen het probleem op, maar lossen het niet op. Beslissen is secundair. Voor ons is het belangrijkste dat de gebruiker tegen dit probleem wordt beschermd. Het zal in een geïsoleerde omgeving bestaan, maar deze omgeving zal er geen enkel contact mee hebben. Eigenlijk zullen we deze vier groepen problemen doornemen (sommige in meer detail, andere in minder detail), ik zal u vertellen wat we gebruiken, welke relevante ervaring we hebben met oplossingen.

Probleemoplossing: wanneer gebeuren ze en wat kun je eraan doen?

Maar we beginnen in de verkeerde volgorde, we beginnen met punt nr. 2: hoe kom je snel van het probleem af? Er is een probleem: we moeten het oplossen. “Wat moeten we hieraan doen?” - de hoofdvraag. En toen we begonnen na te denken over hoe we het probleem konden oplossen, hebben we voor onszelf een aantal vereisten ontwikkeld waaraan het oplossen van problemen moet voldoen.

Om deze eisen te formuleren, hebben we besloten onszelf de vraag te stellen: “Wanneer hebben we problemen”? En problemen, zo bleek, komen in vier gevallen voor:

• Hardwarestoring.
• Externe services zijn mislukt.
• Het wijzigen van de softwareversie (dezelfde implementatie).
• Explosieve groei van de belasting.

Over de eerste twee zullen we het niet hebben. Een hardwarestoring is heel eenvoudig op te lossen: je moet alles dubbel laten doen. Als dit schijven zijn, moeten de schijven in RAID worden samengesteld; als dit een server is, moet de server worden gedupliceerd; als u over een netwerkinfrastructuur beschikt, moet u een tweede kopie van de netwerkinfrastructuur aanleveren, dat wil zeggen dat u deze meeneemt en dupliceer het. En mocht er iets uitvallen, dan schakel je over op reservestroom. Het is moeilijk om hier nog iets over te zeggen.

De tweede is het falen van externe diensten. Voor de meesten is het systeem helemaal geen probleem, maar voor ons niet. Omdat wij betalingen verwerken, zijn wij een aggregator die tussen de gebruiker (die zijn kaartgegevens invoert) en banken, betalingssystemen (Visa, MasterCard, Mira, etc.) staat. Onze externe diensten (betalingssystemen, banken) falen vaak. Noch wij, noch u (als u over dergelijke diensten beschikt) kunnen hierop invloed uitoefenen.

Wat moet je dan doen? Er zijn hier twee opties. Ten eerste moet u, als u kunt, deze service op de een of andere manier dupliceren. Als we kunnen, dragen we bijvoorbeeld verkeer over van de ene dienst naar de andere: kaarten zijn bijvoorbeeld verwerkt via Sberbank, Sberbank heeft problemen - we dragen verkeer [voorwaardelijk] over naar Raiffeisen. Het tweede wat we kunnen doen is het falen van externe diensten zeer snel opmerken, en daarom zullen we het in het volgende deel van het rapport hebben over de reactiesnelheid.

Van deze vier kunnen we specifiek de verandering van softwareversies beïnvloeden - acties ondernemen die zullen leiden tot een verbetering van de situatie in de context van implementaties en in de context van explosieve groei van de belasting. Eigenlijk is dat wat we deden. Hier nogmaals een kleine opmerking...

Van deze vier problemen zijn er meerdere meteen opgelost als je een cloud hebt. Als u zich in de Microsoft Azhur-, Ozone-wolken bevindt, of onze clouds gebruikt, van Yandex of Mail, dan wordt in ieder geval een hardwarestoring hun probleem en wordt alles onmiddellijk in orde voor u in de context van een hardwarestoring.

Wij zijn een enigszins onconventioneel bedrijf. Hier heeft iedereen het over “Kubernets”, over wolken – we hebben noch “Kubernets”, noch wolken. Maar we hebben in veel datacentra rekken met hardware, en we zijn gedwongen om van deze hardware te leven, we zijn gedwongen om voor alles verantwoordelijk te zijn. Daarom zullen we in deze context praten. Dus over de problemen. De eerste twee zijn tussen haakjes verwijderd.

De softwareversie wijzigen. Basissen

Onze ontwikkelaars hebben geen toegang tot de productie. Waarom is dat? Het is alleen zo dat we PCI DSS-gecertificeerd zijn en dat onze ontwikkelaars eenvoudigweg niet het recht hebben om in het “product” te komen. Dat is het, punt. Helemaal niet. Daarom eindigt de ontwikkelingsverantwoordelijkheid precies op het moment dat de ontwikkeling de build ter release indient.

Onze tweede basis die we hebben, die ons ook veel helpt, is de afwezigheid van unieke ongedocumenteerde kennis. Ik hoop dat het voor jou hetzelfde is. Want als dit niet het geval is, krijg je problemen. Er zullen problemen ontstaan ​​wanneer deze unieke, ongedocumenteerde kennis niet op het juiste moment op de juiste plaats aanwezig is. Stel dat u één persoon heeft die weet hoe u een specifiek onderdeel moet inzetten - de persoon is er niet, hij is op vakantie of ziek - dat is alles, u heeft problemen.

En de derde basis waartoe we zijn gekomen. We zijn er met pijn, bloed en tranen toe gekomen - we kwamen tot de conclusie dat al onze builds fouten bevatten, zelfs als deze foutloos zijn. We hebben dit voor onszelf besloten: als we iets implementeren, als we iets in productie brengen, hebben we een build met fouten. Wij hebben de eisen opgesteld waar ons systeem aan moet voldoen.

Vereisten voor het wijzigen van de softwareversie

Er zijn drie vereisten:

• We moeten de inzet snel terugdraaien.
• We moeten de impact van een mislukte inzet minimaliseren.
• En we moeten snel parallel kunnen inzetten.
  Precies in die volgorde! Waarom? Want bij het inzetten van een nieuwe versie is snelheid allereerst niet belangrijk, maar wel belangrijk dat je, als er iets misgaat, snel terugdraait en minimale impact heeft. Maar als u een reeks versies in productie heeft, waarbij blijkt dat er een fout is opgetreden (uit het niets was er geen implementatie, maar er is wel een fout), dan is de snelheid van de daaropvolgende implementatie belangrijk voor u. Wat hebben we gedaan om aan deze eisen te voldoen? We hebben gebruik gemaakt van de volgende methodologie:

  
  
  Het is heel bekend, we hebben het nooit uitgevonden – dit is een blauw/groene inzet. Wat het is? U moet over een exemplaar beschikken voor elke groep servers waarop uw applicaties zijn geïnstalleerd. De kopie is “warm”: er staat geen verkeer op, maar dit verkeer kan op elk moment naar deze kopie worden gestuurd. Dit exemplaar bevat de vorige versie. En op het moment van implementatie rolt u de code uit naar een inactieve kopie. Vervolgens schakel je een deel van het verkeer (of alles) over naar de nieuwe versie. Om de verkeersstroom van de oude versie naar de nieuwe te veranderen, hoeft u dus maar één actie uit te voeren: u moet de balancer stroomopwaarts veranderen, de richting veranderen - van de ene stroomopwaarts naar de andere. Dit is erg handig en lost het probleem van snel schakelen en snel terugdraaien op.

  Hier is de oplossing voor de tweede vraag minimalisering: u kunt slechts een deel van uw verkeer naar een nieuwe lijn sturen, naar een lijn met een nieuwe code (laat het bijvoorbeeld 2%) zijn. En deze 2% zijn niet 100%! Als u 100% van uw verkeer bent kwijtgeraakt vanwege een mislukte implementatie, is dat beangstigend; als u 2% van uw verkeer bent kwijtgeraakt, is dat onaangenaam, maar niet eng. Bovendien zullen gebruikers dit waarschijnlijk niet eens merken, omdat in sommige gevallen (niet in alle gevallen) dezelfde gebruiker, door op F5 te drukken, naar een andere, werkende versie wordt gebracht.

  Blauw/Groen inzetten. Routering

  Niet alles is echter zo eenvoudig “Blauw/Groen inzetten”... Al onze componenten kunnen in drie groepen worden verdeeld:

  • dit is de frontend (betaalpagina’s die onze klanten zien);
  • verwerking kern;
  • adapter voor het werken met betalingssystemen (banken, MasterCard, Visa...).

  En er is hier een nuance: de nuance ligt in de routing tussen de lijnen. Als je gewoon 100% van het verkeer omschakelt, heb je deze problemen niet. Maar als je 2% wilt overstappen, begin je vragen te stellen: “Hoe doe je dit?” Het eenvoudigste is eenvoudig: je kunt Round Robin in nginx instellen door willekeurige keuze, en je hebt 2% aan de linkerkant, 98% aan de rechterkant. Maar dit is niet altijd geschikt.

  In ons geval heeft een gebruiker bijvoorbeeld interactie met het systeem met meer dan één verzoek. Dit is normaal: 2, 3, 4, 5 verzoeken - uw systemen kunnen hetzelfde zijn. En als het voor u belangrijk is dat alle verzoeken van de gebruiker op dezelfde regel komen waarop het eerste verzoek kwam, of (tweede punt) alle verzoeken van de gebruiker op de nieuwe regel komen na de overstap (hij had eerder kunnen gaan werken met de systeem, vóór de overstap), - dan is deze willekeurige verdeling niet geschikt voor u. Dan zijn er de volgende opties:

  
  
  De eerste optie, de eenvoudigste, is gebaseerd op de basisparameters van de client (IP-hash). U hebt een IP-adres en deelt dit van rechts naar links op basis van het IP-adres. Dan zal het tweede geval dat ik heb beschreven voor u werken: toen de implementatie plaatsvond, kon de gebruiker al met uw systeem gaan werken, en vanaf het moment van implementatie zullen alle verzoeken naar een nieuwe regel gaan (bijvoorbeeld naar dezelfde regel).

  Als dit om wat voor reden dan ook niet bij u past en u verzoeken moet sturen naar de lijn waar het initiële verzoek van de gebruiker binnenkwam, dan heeft u twee opties...
  Eerste optie: u kunt betaalde nginx+ kopen. Er is een Sticky Sessions-mechanisme dat, op het eerste verzoek van de gebruiker, een sessie aan de gebruiker toewijst en deze aan de een of andere stroomopwaartse sessie koppelt. Alle volgende gebruikersverzoeken binnen de levensduur van de sessie worden verzonden naar dezelfde upstream waar de sessie is gepost.

  Dit beviel ons niet omdat we al reguliere nginx hadden. Overstappen naar nginx+ is niet dat het duur is, het is alleen dat het enigszins pijnlijk voor ons was en niet erg juist. “Sticks Sessions” werkte bijvoorbeeld niet voor ons om de simpele reden dat “Sticks Sessions” geen routering op basis van “Of-of” toestaat. Daar kun je aangeven wat wij “Sticks Sessions” doen, bijvoorbeeld per IP-adres of per IP-adres en cookies of per postparameter, maar “Of-of” is daar ingewikkelder.

  Daarom kwamen we bij de vierde optie. We hebben nginx op steroïden genomen (dit is openresty) - dit is dezelfde nginx, die bovendien de opname van de laatste scripts ondersteunt. U kunt een laatste script schrijven, het een “open rust” geven, en dit laatste script zal worden uitgevoerd wanneer het gebruikersverzoek komt.

  En we hebben in feite zo'n script geschreven, onszelf "openresti" ingesteld en in dit script sorteren we 6 verschillende parameters door aaneenschakeling "Or". Afhankelijk van de aanwezigheid van een of andere parameter, weten we dat de gebruiker naar de ene of de andere pagina, de ene of de andere regel is gekomen.

  Blauw/Groen inzetten. Voor-en nadelen

  Natuurlijk was het waarschijnlijk mogelijk om het wat eenvoudiger te maken (gebruik dezelfde “Sticky Sessions”), maar we hebben ook zo’n nuance dat niet alleen de gebruiker met ons communiceert in het kader van één verwerking van één transactie... Maar betalingssystemen communiceren ook met ons: nadat we de transactie hebben verwerkt (door een verzoek naar het betalingssysteem te sturen), ontvangen we een coolback.
  En laten we zeggen dat als we binnen ons circuit het IP-adres van de gebruiker in alle verzoeken kunnen doorsturen en gebruikers kunnen verdelen op basis van het IP-adres, dan zullen we niet hetzelfde "Visa" vertellen: "Kerel, we zijn zo'n retro-bedrijf, we lijken internationaal zijn (op de website en in Rusland)... Geef ons het IP-adres van de gebruiker op in een extra veld, uw protocol is gestandaardiseerd”! Het is duidelijk dat zij het er niet mee eens zullen zijn.

  
  
  Daarom werkte dit niet voor ons - we deden openresty. Dienovereenkomstig kregen we met routing zoiets als dit:

  Blauw/Groen Implementatie heeft dan ook de voordelen die ik noemde en de nadelen.

  Twee nadelen:

  • je moet je bezighouden met routering;
  • het tweede grote nadeel zijn de kosten.

  Je hebt twee keer zoveel servers nodig, je hebt twee keer zoveel operationele middelen nodig, je moet twee keer zoveel moeite doen om deze hele dierentuin te onderhouden.

  Tussen de voordelen is er trouwens nog één ding dat ik nog niet eerder heb genoemd: je hebt een reserve in geval van belastinggroei. Als je een explosieve groei in belasting hebt, je hebt een groot aantal gebruikers, dan neem je eenvoudigweg de tweede regel op in de 50 tot 50-verdeling - en je hebt onmiddellijk x2-servers in je cluster totdat je het probleem van het hebben van meer servers hebt opgelost.

  Hoe maak je een snelle implementatie?

  We hebben gesproken over hoe we het probleem van minimalisering en snelle terugdraaiing kunnen oplossen, maar de vraag blijft: “Hoe snel inzetten?”

  
  
  Het is hier kort en eenvoudig.

  • U moet een CD-systeem hebben (Continuous Delivery) - u kunt niet zonder. Als u één server heeft, kunt u deze handmatig implementeren. We hebben natuurlijk ongeveer anderhalfduizend servers en anderhalfduizend handvatten. We kunnen een afdeling zo groot als deze ruimte inrichten, alleen maar om in te zetten.
  • De implementatie moet parallel zijn. Als uw implementatie sequentieel is, is alles slecht. Eén server is normaal, u zet de hele dag anderhalfduizend servers in.
  • Nogmaals, voor acceleratie is dit waarschijnlijk niet langer nodig. Tijdens de implementatie wordt het project meestal gebouwd. Je hebt een webproject, er is een front-endgedeelte (je doet daar een webpakket, je compileert npm - zoiets), en dit proces is in principe van korte duur - 5 minuten, maar deze 5 minuten kunnen wees kritisch. Daarom doen we dat bijvoorbeeld niet: we hebben deze 5 minuten verwijderd, we zetten artefacten in.

    Wat is een artefact? Een artefact is een geassembleerd bouwwerk waarin alle assemblagedelen al zijn voltooid. We slaan dit artefact op in de artefactopslag. We gebruikten ooit twee van dergelijke opslagplaatsen - het was Nexus en nu jFrog Artifactory. We gebruikten aanvankelijk "Nexus" omdat we deze aanpak in Java-toepassingen begonnen te oefenen (het beviel goed). Vervolgens stopten ze er een aantal van de in PHP geschreven applicaties in; en “Nexus” was niet langer geschikt, en daarom kozen we voor jFrog Artefactory, dat bijna alles kan artifactoriseren. We zijn zelfs op het punt gekomen dat we in deze artefactrepository onze eigen binaire pakketten opslaan die we verzamelen voor servers.

  Explosieve groei van de belasting

  We hadden het over het wijzigen van de softwareversie. Het volgende dat we hebben is een explosieve toename van de belasting. Hier bedoel ik waarschijnlijk dat de explosieve groei van de lading niet helemaal het juiste is...

  We hebben een nieuw systeem geschreven: het is servicegericht, modieus, mooi, overal werkers, overal wachtrijen, overal asynchronie. En in dergelijke systemen kunnen gegevens door verschillende stromen stromen. Voor de eerste transactie kunnen de 1e, 3e, 10e arbeider worden gebruikt, voor de tweede transactie - de 2e, 4e, 5e. En vandaag de dag, laten we zeggen, heb je 's morgens een gegevensstroom die de eerste drie werkers gebruikt, en 's avonds verandert deze dramatisch, en gebruikt alles de andere drie werkers.

  En hier blijkt dat je op de een of andere manier de werknemers moet opschalen, je diensten op de een of andere manier moet opschalen, maar tegelijkertijd moet voorkomen dat de middelen opzwellen.

  
  
  Wij hebben onze eisen gedefinieerd. Deze vereisten zijn vrij eenvoudig: dat er service-ontdekking en parametrisatie moet zijn - alles is standaard voor het bouwen van dergelijke schaalbare systemen, behalve één punt: de afschrijving van hulpbronnen. We hebben gezegd dat we niet bereid zijn om middelen af ​​te schrijven, zodat de servers de lucht verwarmen. We namen "Consul", we namen "Nomad", die onze werknemers beheert.

  Waarom is dit een probleem voor ons? Laten we even teruggaan. Inmiddels hebben we zo’n 70 betaalsystemen achter de rug. 'S Morgens gaat het verkeer via Sberbank, dan valt Sberbank bijvoorbeeld uit en schakelen we over naar een ander betalingssysteem. Vóór Sberbank hadden we 100 werknemers, en daarna moeten we de 100 werknemers fors uitbreiden voor een ander betalingssysteem. En het is wenselijk dat dit alles gebeurt zonder menselijke tussenkomst. Want als er menselijke participatie is, zou daar 24/7 een ingenieur moeten zitten, die dit alleen maar zou moeten doen, want zulke storingen, als je 70 systemen achter je hebt, komen regelmatig voor.

  Daarom keken we naar Nomad, dat een open IP heeft, en schreven ons eigen ding, Scale-Nomad - ScaleNo, dat ongeveer het volgende doet: het bewaakt de groei van de wachtrij en vermindert of vergroot het aantal werknemers, afhankelijk van de dynamiek. van de wachtrij. Toen we het deden, dachten we: “Misschien kunnen we het open source maken?” Toen keken ze naar haar - ze was zo simpel als twee kopeken.

  Tot nu toe hebben we het niet open source gemaakt, maar als je het plotseling na het rapport, nadat je je realiseerde dat je zoiets nodig hebt, nodig hebt, staan ​​mijn contacten op de laatste dia - schrijf me alsjeblieft. Als er minimaal 3-5 personen zijn, sponsoren wij het.

  
  
  Hoe het werkt? Laten we eens kijken! Vooruitkijkend: aan de linkerkant staat een stukje van onze monitoring: dit is één regel, bovenaan staat het tijdstip van de gebeurtenisverwerking, in het midden staat het aantal transacties, onderaan staat het aantal werknemers.

  Als je goed kijkt, zit er een fout in deze foto. Op de bovenste kaart crashte een van de kaarten binnen 45 seconden - een van de betalingssystemen viel uit. Onmiddellijk werd er binnen 2 minuten verkeer binnengebracht en begon de wachtrij te groeien op een ander betalingssysteem, waar geen werknemers waren (we gebruikten geen middelen - integendeel, we hebben de middelen op de juiste manier weggegooid). We wilden niet verwarmen - er was een minimaal aantal, ongeveer 5-10 arbeiders, maar ze konden het niet aan.

  De laatste grafiek toont een “bult”, wat alleen maar betekent dat “Skaleno” dit bedrag heeft verdubbeld. En toen de grafiek een beetje daalde, verkleinde hij deze een beetje - het aantal arbeiders werd automatisch gewijzigd. Zo werkt dit ding. We hadden het over punt nummer 2: "Hoe je snel van redenen af ​​kunt komen."

  Toezicht houden. Hoe het probleem snel identificeren?

  Het eerste punt is nu: “Hoe kan ik het probleem snel identificeren?” Toezicht houden! We moeten bepaalde dingen snel begrijpen. Welke dingen moeten we snel begrijpen?

  
  
  Drie dingen!

  • We moeten de prestaties van onze eigen middelen snel begrijpen en begrijpen.
  • We moeten fouten snel begrijpen en de prestaties van systemen buiten ons monitoren.
  • Het derde punt is het identificeren van logische fouten. Dit is wanneer het systeem voor u werkt, alles is normaal volgens alle indicatoren, maar er gaat iets mis.

  Ik zal je hier waarschijnlijk niets cools vertellen. Ik zal Kapitein Duidelijk zijn. Wij zochten wat er op de markt was. We hebben een “leuke dierentuin”. Dit is het soort dierentuin dat we nu hebben:

  
  
  We gebruiken Zabbix om hardware te monitoren, om de belangrijkste indicatoren van servers te monitoren. Voor databases gebruiken wij Okmeter. We gebruiken “Grafana” en “Prometheus” voor alle andere indicatoren die niet bij de eerste twee passen, sommige met “Grafana” en “Prometheus”, en sommige met “Grafana” met “Influx” en Telegraf.

  Een jaar geleden wilden we New Relic gebruiken. Cool ding, het kan alles. Maar hoezeer ze ook alles kan, ze is zo duur. Toen we groeiden naar een volume van 1,5 duizend servers, kwam er een leverancier naar ons toe die zei: “Laten we een overeenkomst sluiten voor volgend jaar.” We keken naar de prijs en zeiden nee, dat doen we niet. Nu we New Relic verlaten, hebben we nog ongeveer 15 servers onder toezicht van New Relic. De prijs bleek absoluut wild te zijn.

  En er is één tool die we zelf hebben geïmplementeerd: dit is Debugger. In eerste instantie noemden we het ‘Bagger’, maar toen kwam er een leraar Engels langs, lachte wild en noemde het ‘Debagger’. Wat het is? Dit is een tool die in feite in 15-30 seconden op elk onderdeel, als een “black box” van het systeem, tests uitvoert op de algehele prestaties van het onderdeel.

  Als er bijvoorbeeld een externe pagina (betaalpagina) is, opent hij deze eenvoudig en kijkt hoe deze eruit moet zien. Als deze in verwerking is, stuurt hij een test “transactie” en zorgt ervoor dat deze “transactie” aankomt. Als het om een ​​verbinding met betalingssystemen gaat, sturen we, waar mogelijk, een testverzoek uit om te controleren of alles goed met ons gaat.

  Welke indicatoren zijn belangrijk voor monitoring?

  Wat monitoren we vooral? Welke indicatoren zijn voor ons belangrijk?

  
  

  • Reactietijd / RPS op fronten is een zeer belangrijke indicator. Hij antwoordt meteen dat er iets mis is met je.
  • Het aantal verwerkte berichten in alle wachtrijen.
  • Aantal werknemers.
  • Basis correctheidsstatistieken.

  Het laatste punt is de statistiek ‘zakelijk’, ‘zakelijk’. Als u hetzelfde wilt monitoren, moet u een of twee statistieken definiëren die voor u de belangrijkste indicatoren zijn. Onze maatstaf is doorvoer (dit is de verhouding tussen het aantal succesvolle transacties en de totale transactiestroom). Als er met een interval van 5-10-15 minuten iets in verandert, betekent dit dat we problemen hebben (als het radicaal verandert).

  Hoe het er voor ons uitziet is een voorbeeld van een van onze boards:

  
  
  Aan de linkerkant zijn er 6 grafieken, dit is volgens de lijnen: het aantal werknemers en het aantal berichten in de wachtrijen. Aan de rechterkant - RPS, RTS. Hieronder vindt u dezelfde ‘zakelijke’ statistiek. En in de “business”-statistiek kunnen we meteen zien dat er iets mis is gegaan in de twee middelste grafieken... Dit is gewoon een ander systeem dat achter ons staat en is gevallen.

  Het tweede dat we moesten doen, was de val van externe betalingssystemen monitoren. Hier hebben we OpenTracing genomen - een mechanisme, een standaardparadigma waarmee je gedistribueerde systemen kunt traceren; en het is een beetje veranderd. Het standaard OpenTracing-paradigma zegt dat we voor elk individueel verzoek een trace opbouwen. We hadden dit niet nodig en we hebben het verpakt in een samenvattende aggregatietrace. We hebben een tool gemaakt waarmee we de snelheid van de systemen achter ons kunnen volgen.

  
  
  De grafiek laat ons zien dat een van de betalingssystemen binnen 3 seconden begon te reageren - we hebben problemen. Bovendien zal dit ding reageren als de problemen beginnen, met een interval van 20-30 seconden.

  En de derde klasse van monitoringfouten die bestaat, is logische monitoring.

  Eerlijk gezegd wist ik niet wat ik op deze dia moest tekenen, omdat we al een hele tijd op de markt op zoek waren naar iets dat bij ons zou passen. We vonden niets, dus moesten we het zelf doen.

  
  
  Wat bedoel ik met logische monitoring? Stel je voor: je maakt voor jezelf een systeem (bijvoorbeeld een Tinder-kloon); jij hebt het gehaald, gelanceerd. Succesvolle manager Vasya Pupkin zet het op zijn telefoon, ziet daar een meisje, vindt haar leuk... en hetzelfde gaat niet naar het meisje - hetzelfde gaat naar de bewaker Mikhalych van hetzelfde zakencentrum. De manager gaat naar beneden en vraagt ​​zich dan af: "Waarom lacht deze bewaker Michalych zo vriendelijk naar hem?"

  In dergelijke situaties... Voor ons klinkt deze situatie een beetje anders, omdat (ik schreef) dit een reputatieverlies is dat indirect tot financiële verliezen leidt. Onze situatie is het tegenovergestelde: we kunnen directe financiële verliezen lijden, bijvoorbeeld als we een transactie als succesvol hebben uitgevoerd, maar deze niet succesvol was (of omgekeerd). Ik moest mijn eigen tool schrijven die het aantal succesvolle transacties in de loop van de tijd bijhoudt met behulp van bedrijfsindicatoren. Niets gevonden op de markt! Dit is precies het idee dat ik wilde overbrengen. Er is niets op de markt dat dit soort problemen oplost.

  Dit ging over hoe je het probleem snel kunt identificeren.

  Hoe u de redenen voor implementatie kunt bepalen

  De derde groep problemen die we oplossen is nadat we het probleem hebben geïdentificeerd, nadat we er vanaf zijn gekomen. Het zou goed zijn om de reden voor ontwikkeling en testen te begrijpen en er iets aan te doen. Dienovereenkomstig moeten we het onderzoeken, we moeten de boomstammen opheffen.

  
  
  Als we het over logs hebben (de belangrijkste reden zijn logs), bevindt het grootste deel van onze logs zich in ELK Stack - bijna iedereen heeft hetzelfde. Voor sommigen is het misschien niet in ELK, maar als je logs in gigabytes schrijft, kom je vroeg of laat bij ELK. We schrijven ze in terabytes.

  
  
  Er is hier een probleem. We hebben het opgelost, de fout voor de gebruiker gecorrigeerd, begonnen uit te zoeken wat er was, klommen in Kibana, voerden daar de transactie-ID in en kregen zo'n voetdoek (laat veel zien). En absoluut niets is duidelijk in dit voetdoek. Waarom? Ja, want het is niet duidelijk welk onderdeel bij welke medewerker hoort, welk onderdeel bij welk onderdeel hoort. En op dat moment beseften we dat we tracering nodig hadden - dezelfde OpenTracing waar ik het over had.

  We dachten dit een jaar geleden, richtten onze aandacht op de markt en er waren daar twee tools: "Zipkin" en "Jaeger". ‘Jager’ is in feite zo’n ideologische erfgenaam, een ideologische opvolger van ‘Zipkin’. Alles is goed in Zipkin, behalve dat het niet weet hoe het moet aggregeren, het weet niet hoe het logs in de trace moet opnemen, alleen tijdtracering. En “Jager” steunde dit.

  We hebben gekeken naar “Jager”: je kunt applicaties instrumenteren, je kunt in Api schrijven (de Api-standaard voor PHP was destijds echter niet goedgekeurd - dit was een jaar geleden, maar nu is het al goedgekeurd), maar daar was absoluut geen klant. “Oké”, dachten we, en schreven onze eigen cliënt. Wat hebben we gekregen? Zo ziet het er ongeveer uit:

  
  
  In Jaeger worden voor elk bericht spanten aangemaakt. Dat wil zeggen dat wanneer een gebruiker het systeem opent, hij een of twee blokken ziet voor elk binnenkomend verzoek (1-2-3 - het aantal binnenkomende verzoeken van de gebruiker, het aantal blokken). Om het gebruikers gemakkelijker te maken, hebben we tags aan de logs en tijdsporen toegevoegd. Dienovereenkomstig zal onze applicatie, in geval van een fout, het logboek markeren met de juiste Error-tag. U kunt filteren op Error-tag en alleen reeksen die dit blok met een fout bevatten, worden weergegeven. Zo ziet het eruit als we de spanwijdte uitbreiden:

  
  
  Binnen de overspanning bevindt zich een reeks sporen. In dit geval zijn dit drie testsporen, en de derde spoor vertelt ons dat er een fout is opgetreden. Tegelijkertijd zien we hier een tijdspoor: we hebben bovenaan een tijdschaal en we zien met welk tijdsinterval dit of dat logboek is opgenomen.

  Bij ons ging het dan ook goed. We hebben onze eigen extensie geschreven en deze open source gemaakt. Als je met tracering wilt werken, als je met “Jager” in PHP wilt werken, dan is er onze extensie, welkom om te gebruiken, zoals ze zeggen:

  
  
  We hebben deze extensie - het is een client voor de OpenTracing Api, het is gemaakt als php-extensie, dat wil zeggen dat je het moet samenstellen en op het systeem moet installeren. Een jaar geleden was er niets anders. Nu zijn er andere clients die op componenten lijken. Hier is het aan jou: je pompt de componenten eruit met een componist, of je gebruikt de extensie naar jouw keuze.

  Bedrijfsnormen

  We spraken over de drie geboden. Het vierde gebod is om benaderingen te standaardiseren. Waar gaat dit over? Het gaat hier over:

  
  
  Waarom staat hier het woord ‘bedrijf’? Niet omdat we een groot of bureaucratisch bedrijf zijn, nee! Ik wilde het woord ‘corporate’ hier gebruiken in de context dat elk bedrijf en elk product zijn eigen normen zou moeten hebben, ook jij. Welke normen hebben we?

  
  

  • Wij hebben een inzetreglement. We gaan nergens heen zonder hem, dat kunnen we niet. We zetten ongeveer 60 keer per week in, dat wil zeggen vrijwel constant. Tegelijkertijd hebben we in de inzetregeling bijvoorbeeld een taboe op inzet op vrijdag – in principe zetten we niet in.
  • Wij hebben documentatie nodig. Geen enkel nieuw onderdeel wordt in productie genomen als er geen documentatie voor is, ook al is het geboren onder de leiding van onze RnD-specialisten. We hebben van hen implementatie-instructies nodig, een monitoringkaart en een ruwe beschrijving (nou ja, zoals programmeurs kunnen schrijven) van hoe dit onderdeel werkt en hoe je er problemen mee kunt oplossen.
  • We lossen niet de oorzaak van het probleem op, maar het probleem - wat ik al zei. Het is belangrijk voor ons om de gebruiker tegen problemen te beschermen.
  • We hebben toestemming. We beschouwen het bijvoorbeeld niet als downtime als we binnen twee minuten 2% van het verkeer verliezen. Dit is in principe niet opgenomen in onze statistieken. Als het procentueel gezien of tijdelijk is, tellen we al mee.
  • En we schrijven altijd postmortems. Wat er ook met ons gebeurt, elke situatie waarin iemand zich tijdens de productie abnormaal gedroeg, zal in het autopsieproces tot uiting komen. Een autopsie is een document waarin u opschrijft wat er met u is gebeurd, een gedetailleerde timing, wat u hebt gedaan om het te corrigeren en (dit is een verplicht blok!) wat u gaat doen om te voorkomen dat dit in de toekomst gebeurt. Dit is verplicht en noodzakelijk voor latere analyse.

  Wat wordt beschouwd als downtime?

  
  
  Waar heeft dit allemaal toe geleid?

  Dit leidde ertoe dat (we hadden bepaalde problemen met de stabiliteit, dit beviel noch de klant, noch ons) de afgelopen 6 maanden onze stabiliteitsindicator 99,97 was. We kunnen zeggen dat dit niet veel is. Ja, we hebben iets om naar te streven. Ongeveer de helft van deze indicator is als het ware de stabiliteit, niet die van ons, maar van onze webapplicatie-firewall, die voor ons staat en als service wordt gebruikt, maar klanten interesseren zich daar niet voor.

  We leerden 's nachts slapen. Eindelijk! Zes maanden geleden konden we dat niet. En over deze opmerking met de resultaten zou ik graag een opmerking willen maken. Gisteravond was er een prachtige reportage over het besturingssysteem voor een kernreactor. Als de mensen die dit systeem hebben geschreven mij kunnen horen, vergeet dan alstublieft wat ik zei over “2% is geen downtime.” Voor u is 2% downtime, ook al is het maar twee minuten!

  Dat is alles! Jouw vragen.

  
  

  Over balancers en databasemigratie

  Vraag uit het publiek (hierna – B): – Goedenavond. Hartelijk dank voor zo'n beheerdersrapport! Een korte vraag over uw balancers. U zei dat u een WAF heeft, dat wil zeggen dat u, zoals ik het begrijp, een soort externe balancer gebruikt...

  EK: – Nee, wij gebruiken onze diensten als balancer. In dit geval is WAF voor ons uitsluitend een DDoS-beveiligingstool.

  В: – Kun je iets zeggen over balancers?

  EK: – Zoals ik al zei, dit is een groep servers in openresty. We hebben nu 5 reservegroepen die exclusief reageren... dat wil zeggen, een server die uitsluitend openresty draait en alleen proxyverkeer stuurt. Om te begrijpen hoeveel we vasthouden: we hebben nu een regelmatige verkeersstroom van enkele honderden megabits. Ze kunnen ermee omgaan, ze voelen zich goed, ze belasten zichzelf niet eens.

  В: – Ook een simpele vraag. Hier is de blauw/groene implementatie. Wat doen jullie bijvoorbeeld met databasemigraties?

  EK: - Goede vraag! Kijk, bij de blauw/groene implementatie hebben we voor elke lijn aparte wachtrijen. Dat wil zeggen, als we het hebben over gebeurteniswachtrijen die van werknemer naar werknemer worden verzonden, zijn er afzonderlijke wachtrijen voor de blauwe lijn en voor de groene lijn. Als we het over de database zelf hebben, dan hebben we deze bewust zoveel mogelijk beperkt, alles praktisch in wachtrijen geplaatst; in de database slaan we alleen een stapel transacties op. En onze transactiestapel is voor alle lijnen hetzelfde. Met de database in deze context: we verdelen deze niet in blauw en groen, omdat beide versies van de code moeten weten wat er met de transactie gebeurt.

  Vrienden, ik heb ook een kleine prijs om jullie aan te moedigen: een boek. En ik zou de prijs moeten krijgen voor de beste vraag.

  В: - Hallo. Bedankt voor het rapport. De vraag is deze. U controleert betalingen, u controleert de diensten waarmee u communiceert... Maar hoe controleert u of iemand op de een of andere manier naar uw betalingspagina komt, een betaling uitvoert en het project hem geld bijschrijft? Dat wil zeggen: hoe controleert u of de marsant beschikbaar is en uw terugbelactie heeft geaccepteerd?

  EK: – “Merchant” is voor ons in dit geval precies dezelfde externe dienst als het betalingssysteem. Wij monitoren de reactiesnelheid van de webwinkelier.

  Over database-encryptie

  В: - Hallo. Ik heb een enigszins gerelateerde vraag. U beschikt over PCI DSS-gevoelige gegevens. Ik wilde weten hoe je PAN's opslaat in wachtrijen waarnaar je moet overstappen? Gebruik je enige encryptie? En dit leidt tot de tweede vraag: volgens PCI DSS is het noodzakelijk om de database periodiek opnieuw te versleutelen in geval van wijzigingen (ontslag van beheerders, enz.) - wat gebeurt er in dit geval met de toegankelijkheid?

  
  
  EK: - Geweldige vraag! Ten eerste slaan we PAN's niet op in wachtrijen. We hebben in principe niet het recht om PAN ergens in duidelijke vorm op te slaan, daarom gebruiken we een speciale service (we noemen het “Kademon”) - dit is een service die maar één ding doet: hij ontvangt een bericht als invoer en verzendt een gecodeerd bericht uit. En we slaan alles op met dit gecodeerde bericht. Dienovereenkomstig is onze sleutellengte minder dan een kilobyte, zodat dit serieus en betrouwbaar is.

  В: – Heb je nu 2 kilobyte nodig?

  EK: – Het lijkt alsof het gisteren nog 256 was... Wel, waar anders?!

  Daarom is dit de eerste. En ten tweede ondersteunt de bestaande oplossing de hercoderingsprocedure - er zijn twee paar "keks" (sleutels), die "decks" opleveren die coderen (sleutel zijn de sleutels, dek zijn afgeleiden van de sleutels die coderen) . En als de procedure wordt gestart (het gebeurt regelmatig, van 3 maanden tot ± enkele), downloaden we een nieuw paar “cakes” en coderen we de gegevens opnieuw. We hebben aparte diensten die alle gegevens eruit halen en op een nieuwe manier versleutelen; De gegevens worden opgeslagen naast de identificatie van de sleutel waarmee ze zijn gecodeerd. Zodra we de gegevens met nieuwe sleutels versleutelen, verwijderen we dus de oude sleutel.

  Soms moeten betalingen handmatig worden gedaan...

  В: – Dat wil zeggen: als er voor een bepaalde bewerking een terugbetaling is ontvangen, zult u deze dan nog steeds met de oude sleutel decoderen?

  EK: - Ja.

  В: – Dan nog een klein vraagje. Wanneer zich een storing, val of incident voordoet, is het noodzakelijk om de transactie handmatig door te voeren. Er is zo'n situatie.

  EK: - Ja soms.

  В: – Waar haal je deze gegevens vandaan? Of gaat u zelf naar deze opslag?

  EK: – Nee, natuurlijk hebben we een soort backofficesysteem dat een interface bevat voor onze ondersteuning. Als we niet weten in welke status de transactie zich bevindt (bijvoorbeeld totdat het betalingssysteem reageerde met een time-out), weten we dat niet a priori, dat wil zeggen dat we de definitieve status alleen met volledig vertrouwen toewijzen. In dit geval geven wij de transactie een speciale status voor handmatige verwerking. Zodra de klantenservice 's ochtends, de volgende dag, informatie ontvangt dat bepaalde transacties in het betalingssysteem blijven staan, verwerken ze deze handmatig in deze interface.

  
  
  В: – Ik heb een paar vragen. Eén daarvan is de voortzetting van de PCI DSS-zone: hoe log je hun circuit? Deze vraag is omdat de ontwikkelaar alles in de logboeken had kunnen zetten! Tweede vraag: hoe rol je hotfixes uit? Het gebruik van handvatten in de database is één optie, maar er kunnen gratis hotfixes zijn. Wat is daar de procedure? En de derde vraag heeft waarschijnlijk te maken met RTO, RPO. Je beschikbaarheid was 99,97, bijna vier negens, maar zoals ik het begrijp, heb je een tweede datacenter, een derde datacenter en een vijfde datacenter... Hoe synchroniseer je ze, repliceer je ze en al het andere?

  EK: - Laten we beginnen met de eerste. Ging de eerste vraag over logboeken? Wanneer we logbestanden schrijven, hebben we een laag die alle gevoelige gegevens maskeert. Ze kijkt naar het masker en naar de extra velden. Dienovereenkomstig verschijnen onze logs met reeds gemaskeerde gegevens en een PCI DSS-circuit. Dit is een van de vaste taken van de testafdeling. Ze moeten elke taak controleren, inclusief de logboeken die ze schrijven, en dit is een van de reguliere taken tijdens codebeoordelingen, om te controleren of de ontwikkelaar niets heeft opgeschreven. Daaropvolgende controles hierop worden regelmatig ongeveer één keer per week uitgevoerd door de afdeling informatiebeveiliging: logs van de laatste dag worden selectief verzameld en door een speciale scanner-analyzer van testservers gehaald om alles te controleren.
  Over hotfixes. Dit is opgenomen in ons inzetreglement. We hebben een aparte clausule over hotfixes. Wij zijn van mening dat we XNUMX uur per dag hotfixes implementeren wanneer dat nodig is. Zodra de versie is samengesteld, zodra deze wordt uitgevoerd, zodra we een artefact hebben, hebben we een systeembeheerder van dienst die wordt gebeld door de ondersteuning, en hij zet deze in op het moment dat het nodig is.

  Over "vier negens". Het cijfer dat we nu hebben is echt gehaald en daar hebben we in een ander datacenter naar gestreefd. Nu hebben we een tweede datacenter en beginnen we daartussen te navigeren, en de kwestie van replicatie tussen datacenters is echt een niet-triviale kwestie. We hebben geprobeerd het in één keer op verschillende manieren op te lossen: we probeerden dezelfde "Tarantula" te gebruiken - het werkte niet voor ons, ik zal het je meteen vertellen. Daarom hebben we de "sens" uiteindelijk handmatig besteld. In feite voert elke applicatie in ons systeem de noodzakelijke ‘change – done’-synchronisatie tussen datacenters asynchroon uit.

  В: – Als je een tweede hebt gekregen, waarom heb je dan geen derde gekregen? Omdat nog niemand een gespleten brein heeft...

  EK: – Maar we hebben geen gespleten brein. Omdat elke applicatie wordt aangestuurd door een multimaster, maakt het voor ons niet uit bij welk centrum de aanvraag binnenkomt. We zijn er klaar voor dat als een van onze datacenters uitvalt (we vertrouwen erop) en midden in een gebruikersverzoek overschakelt naar het tweede datacenter, we klaar zijn om deze gebruiker inderdaad te verliezen; maar dit zullen eenheden zijn, absolute eenheden.

  В: - Goedeavond. Bedankt voor het rapport. U had het over uw debugger, die enkele testtransacties in productie uitvoert. Maar vertel ons over testtransacties! Hoe diep gaat het?

  EK: – Het doorloopt de volledige cyclus van het gehele onderdeel. Voor een component is er geen verschil tussen een testtransactie en een productietransactie. Maar logisch gezien is dit gewoon een apart project in het systeem, waarop alleen testtransacties worden uitgevoerd.

  В: - Waar knip je het af? Hier stuurde Core...

  EK: – Wij staan ​​in dit geval achter “Kor” voor testtransacties... We hebben zoiets als routing: “Kor” weet naar welk betalingssysteem hij moet sturen - we sturen naar een nepbetalingssysteem, dat eenvoudigweg een http-signaal geeft en dat is alles.

  В: – Vertel me alstublieft, is uw applicatie geschreven in één enorme monoliet, of heeft u deze opgedeeld in enkele services of zelfs microservices?

  EK: – We hebben uiteraard geen monoliet, we hebben een servicegerichte toepassing. We maken grapjes dat ons servies uit monolieten bestaat - ze zijn echt behoorlijk groot. Het is moeilijk om het microservices te noemen, maar dit zijn services waarbinnen werknemers van gedistribueerde machines werken.

  Als de service op de server in gevaar komt...

  В: – Dan heb ik de volgende vraag. Zelfs als het een monoliet zou zijn, zei je nog steeds dat je veel van deze instantservers hebt, ze verwerken in principe allemaal gegevens, en de vraag is: “In het geval van een compromis van een van de instantservers of een applicatie, kan elke individuele link Hebben ze een vorm van toegangscontrole? Wie van hen kan wat? Met wie moet ik contact opnemen voor welke informatie?

  
  
  EK: - Ja absoluut. De veiligheidseisen zijn behoorlijk serieus. Ten eerste hebben we open databewegingen, en de havens zijn alleen die waardoor we van tevoren op verkeersbewegingen anticiperen. Als een component communiceert met de database (bijvoorbeeld met Muskul) via 5-4-3-2, zal alleen 5-4-3-2 ervoor openstaan ​​en zullen andere poorten en andere verkeersrichtingen niet beschikbaar zijn. Bovendien moet u begrijpen dat er in onze productie ongeveer 10 verschillende beveiligingslussen zijn. En zelfs als de applicatie op de een of andere manier gecompromitteerd zou zijn, God verhoede het, zal de aanvaller geen toegang hebben tot de serverbeheerconsole, omdat dit een andere netwerkbeveiligingszone is.

  В: – En wat voor mij in deze context interessanter is, is dat je bepaalde contracten hebt met diensten - wat ze kunnen doen, via welke “acties” ze met elkaar in contact kunnen komen... En in een normale stroom vragen sommige specifieke diensten om bepaalde rij, een lijst met “acties” aan de andere kant. In een normale situatie lijken ze zich niet tot anderen te wenden, en ze hebben andere verantwoordelijkheidsgebieden. Als een van hen wordt gecompromitteerd, zal deze dan de “acties” van die dienst kunnen verstoren?

  EK: - Ik begrijp. Als in een normale situatie met een andere server communicatie überhaupt was toegestaan, dan ja. Volgens het SLA-contract controleren wij niet of u alleen de eerste 3 ‘acties’ mag doen, en niet de 4 ‘acties’. Dit is waarschijnlijk overbodig voor ons, omdat we in principe al een beveiligingssysteem met 4 niveaus voor circuits hebben. Wij verdedigen ons liever met de contouren dan op het niveau van de binnenkant.

  Hoe Visa, MasterCard en Sberbank werken

  В: – Ik wil een punt verduidelijken over het overschakelen van een gebruiker van het ene datacenter naar het andere. Voor zover ik weet werken Visa en MasterCard met het binaire synchrone protocol 8583, en daar zijn combinaties van. En ik wilde weten: nu bedoelen we overstappen – is het rechtstreeks “Visa” en “MasterCard” of vóór betalingssystemen, vóór verwerking?

  EK: - Dit is vóór de mixen. Onze mixen bevinden zich in hetzelfde datacenter.

  В: – Heeft u grofweg één aansluitpunt?

  EK: – “Visa” en “MasterCard” - ja. Simpelweg omdat Visa en MasterCard behoorlijk serieuze investeringen in infrastructuur vergen om bijvoorbeeld aparte contracten af ​​te sluiten voor het verkrijgen van een tweede paar mixen. Ze zijn gereserveerd binnen één datacenter, maar als, God verhoede, ons datacenter, waar er combinaties zijn voor verbinding met Visa en MasterCard, sterft, dan zal de verbinding met Visa en MasterCard verloren gaan...

  В: – Hoe kunnen ze gereserveerd worden? Ik weet dat Visa in principe slechts één verbinding toestaat!

  EK: – Zij leveren de apparatuur zelf. Wij hebben in ieder geval apparatuur ontvangen die van binnen volledig redundant is.

  В: – Dus de stand is van hun Connects Orange?..

  EK: - Ja.

  В: – Maar hoe zit het met deze casus: als uw datacenter verdwijnt, hoe kunt u er dan nog gebruik van maken? Of stopt het verkeer gewoon?

  EK: - Nee. In dit geval schakelen we het verkeer eenvoudigweg over naar een ander kanaal, wat uiteraard duurder is voor ons en duurder voor onze klanten. Maar het verkeer gaat niet via onze directe verbinding met Visa, MasterCard, maar via de voorwaardelijke Sberbank (erg overdreven).

  Ik bied mijn excuses aan als ik werknemers van Sberbank heb beledigd. Maar volgens onze statistieken valt Sberbank onder de Russische banken het vaakst. Er gaat geen maand voorbij zonder dat er iets misgaat bij Sberbank.

  
  
  

  Sommige advertenties 🙂

  Bedankt dat je bij ons bent gebleven. Vind je onze artikelen leuk? Wil je meer interessante inhoud zien? Steun ons door een bestelling te plaatsen of door vrienden aan te bevelen, cloud VPS voor ontwikkelaars vanaf $ 4.99, een unieke analoog van servers op instapniveau, die door ons voor u is uitgevonden: De hele waarheid over VPS (KVM) E5-2697 v3 (6 kernen) 10 GB DDR4 480 GB SSD 1 Gbps vanaf $ 19 of hoe een server te delen? (beschikbaar met RAID1 en RAID10, tot 24 cores en tot 40GB DDR4).

  Dell R730xd 2x goedkoper in Equinix Tier IV datacenter in Amsterdam? Alleen hier 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV vanaf $199 in Nederland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - vanaf $99! Lees over Hoe infrastructuur corp te bouwen. klasse met het gebruik van Dell R730xd E5-2650 v4-servers ter waarde van 9000 euro voor een cent?

Bron: www.habr.com