HighLoad++, Jevgeni Kuzovlev (EcommPay IT): mida teha, kui minut seadistamata maksab $100000

Kõik räägivad arendus- ja testimisprotsessidest, töötajate koolitusest, motivatsiooni tõstmisest, kuid neid protsesse on vähe, kui teenuse seiskamine maksab kosmilisi summasid. Mida teha, kui teete rahanduslikke tehinguid range SLA raames? Kuidas suurendada teie süsteemide usaldusväärsust ja tõrkekindlust, kui arendust ja testimist kõrvale jätta?

Järgmine konverents HighLoad++ toimub 6. ja 7. aprillil 2020 Peterburis. Üksikasjad ja piletid: lingil. 9. novembril, kell 18:00. HighLoad++ Moskva 2018, saal "Deli + Kolkata". Teesid ja esitlus.

Evgeny Kuzovlev (edaspidi – EK): – Tere, sõbrad! Minu nimi on Kuzovlev Evgeny. Olen EcommPay'ist, täpsemalt EcommPay IT-st, ettevõtte IT-osakonnast. Ja täna räägime koos teiega seisakutest – kuidas neid vältida ja kuidas minimeerida nende tagajärgi, kui vältida ei õnnestu. Teema on kõnealune: "Mida teha, kui minute seisak maksab 100 000 dollarit"? Meil, kiirelt öeldes, on numbrid sarnased.

Millega tegeleb EcommPay IT?

Kes me oleme? Miks ma siin teie ees seisan? Miks ma olen õigustatud teile midagi rääkima? Millest räägime siin lähemalt?

EcommPay grupp on rahvusvaheline aktsiaselts. Me töötleme makseid üle kogu maailma – Venemaal, Euroopas, Kagu-Aasias (All Around the World). Meil on 9 kontorit, 500 töötajat kokku ja umbes natuke vähem kui pooled neist on IT-eksperdid. Kõik, mida me teeme, kõik, mille pealt me raha teenime, on meie oma loodud.

Meie kõik tooted (mida on meil piisavalt palju – meie suurte IT-toodete rivi koosneb umbes 16 erinevast komponendist) on meie ise kirjutatud; me kirjutame ise, me arendame ise. Ja hetkel teeme me umbes miljon tehingut päevas (miljonid – arvatavasti on nii õigem öelda). Me oleme piisavalt noor ettevõte – meie vanus on umbes kuus aastat.

6 aastat tagasi oli see selline idufirma, kui meeskond tuli koos äriideega. Nad olid ideest ühendatud (mitte midagi muud ei olnud, peale idee) ja me alustasime. Nii nagu iga idufirma, jooksime me kiiremini... Meie jaoks oli olulisem kiirus, mitte kvaliteet.

Mõnel hetkel peatusime: taipasime, et me ei saa enam sama kiirusel ja kvaliteediga elada ning peame tegema esmalt kvaliteedi nimel. Sel hetkel otsustasime kirjutada uue platvormi, mis oleks õige, skaleeritav ja usaldusväärne. Selle platvormi kirjutamine algas (alustasime investeeringute tegemist, arendamist, testimist), kuid mõnes kohas taipasime, et arendamine ja testimine ei võimalda meil jõuda uuele teenuse kvaliteeditasemele.

Teete uue toote, viite selle tootmisse, kuid ikka midagi ei lähe nii. Ja täna räägime sellest, kuidas jõuda uuele kvaliteeditasandile (kuidas see meil õnnestus, meie kogemus), jättes kõrvale arendamise ja testimise; räägime, mis on ekspluateerimise kätte saadav – mida ekspluateerimine saab ise teha, mida see saab testimisele pakkuda, et mõjutada kvaliteeti.

Seisakud. Ekspluateerimise käsud.

Alati on põhialuseks see, millest me täna räägime – seisakud. Õudne sõna. Kui meil on seisak, siis on meil kõik halvasti. Me jookseme seda üles tõstma, administraatorid hoiavad serverit – olgu jumal, et see ei kukuks, nagu laulus öeldakse. Just sellest me täna räägime.

Kui alustasime oma lähenemiste muutmisega, kujundasime neli käsku. Need on mul esitatud slaididel:

Need käsud on piisavalt lihtsad:

• Probleemi kiiresti tuvastada.
• Küstida veel kiiremini lahti.
• Aidata mõista põhjust (hiljem, arendajatele).
• Ja standardiseerida lähenemised.

Pööran tähelepanu punktile nr 2. Me vabastame probleemist, mitte ei lahenda seda. Lahendada on teisejärguline. Meie jaoks on esmatähtis see, et kasutaja oleks selle probleemi eest kaitstud. See probleem eksisteerib mingis isoleeritud keskkonnas, kuid see keskkond ei suhtle temaga. Tegelikult käime nende nelja probleemi grupi kaudu (mõned üksikasjalikumalt, mõned vähem), räägin, mida me kasutame, milline on meie vastav kogemus lahendustes.

Probleemide kõrvaldamine: kui need juhtuvad ja mida nendega teha?

Kuid alustame me mitte järjekorras, vaid punktist № 2 – kuidas kiiresti probleemist lahti saada? Probleem on olemas – me peame selle lahendama. „Mida me sellega teeme?” – see on peamine küsimus. Ja kui me hakkasime mõtlema, kuidas probleemi lahendada, töötasime välja teatud nõuded, millele probleemide lahendamine peaks vastama.

Et neid nõudeid sõnastada, otsustasime endalt küsida: „Millal meil probleemid esinevad?” Ja probleemid, nagu selgus, tekivad neljas olukorras:

• Riistvaravead.
• Väliste teenuste tõrked.
• Tarkvara versioonimuudatus (see sama deploy).
• Äkiline koormuse kasv.

Esimese kahe kohta me räägime. Riistvaravead lahendatakse piisavalt lihtsalt: teil peab olema kõik kopeeritud. Kui need on kettad – kettad peavad olema RAID-kogumis, kui see on server – server peab olema kopeeritud, kui teil on võrgu infrastruktuur – peate paigaldama teise koopia võrgu infrastruktuurist, st te võtate ja kopeerite. Ja kui midagi ebaõnnestub, lülitate varuressurssidele. Siin on rohkem öelda keeruline.

Teiseks – väliste teenuste tõrked. Enamiku süsteemide jaoks pole see probleem, aga mitte meie jaoks. Kuna me töötleme makseid, oleme me agregeerija, kes seisab kasutaja (kes sisestab oma kaardandmed) ja pankade, maksesüsteemide („Visa”, „MasterCard”, „Maestro” jne) vahel. Meie välistele teenustele (maksesüsteemidele, pankadele) on iseloomulikud tõrked. Me ei saa selle peale mitte mõjutada ei meie ega teie (kui teil on sellised teenused).

Kuidas siis edasi toimida? Siin on kaks varianti. Esiteks, kui saate, peaksite te need teenused mingil moel kopeerima. Näiteks, kui me saame, suuname liikluse ühelt teenuselt teisele: töötlesime näiteks kaarte läbi „Sberbank”, kui „Sberbankil” on probleemid – suuname liikluse [tinglikult] „Rayffaisenile”. Teiseks, mida me saame teha – on väga kiiresti märgata väliste teenuste tõrkeid, seetõttu räägime me järgmises osa ettekandest reageerimise kiirusest.

Nende nelja tõe kohaselt saame me konkreetselt mõjuda tarkvara versioonide vahetusele – teha tegevusi, mis viivad olukorra paranemiseni deploy’de ja koormuse plahvatusliku kasvu kontekstis. Tegelikult, me tegimeki seda. Siin on jälle väike märkus…

Nendest neljast probleemist lahendatakse mõni kohe, kui teil on pilv. Kui olete "Microsoft Azure", "Ozon"'is, kasutate meie pilvi, "Yandexilt" või "Maililt", siis vähemalt riistvara rike muutub nende probleemiks ja teil läheb kohe hästi riistvara rikke kontekstis.

Me oleme pisut ebatavaline ettevõte. Siin räägitakse "Kubernetesest", pilvedest – meil ei ole ei "Kubernetes't" ega pilvi. Küll aga on meil riiulid rauaga mitmes andmekeskuses, ja sellel raual peame me elama, me peame vastutama selle eest. Seetõttu räägime sellest kontekstist. Nii et, probleemidest. Esimesed kaks jätsime kõrvale.

Tarkvara versiooni vahetus. Alused

Meie arendajatel ei ole ligipääsu tootmiselle. Miks nii? Ainsalt põhjusel, et oleme sertifitseeritud PCI DSS järgi, ja meie arendajatel lihtsalt pole õigust "prod"'isse sekkuda. Punkt. Täiesti. Seetõttu lõpeb arenduse vastutus täpselt hetkel, kui arendus on üle andnud versiooni väljalaskmiseks.

Meie teine alus, mis meil on ja mis meid samuti tugevalt aitab – puuduvad unikaalsed dokumenteerimata teadmised. Loodan, et teil on samuti nii. Sest kui ei ole – teil tekivad probleemid. Probleemid tekivad siis, kui neid unikaalseid dokumenteerimata teadmisi ei ole õigeaegselt õiges kohas. Oletame, et teil on üks inimene, kes teab, kuidas konkreetset komponenti deploy’ida – kui seda inimest ei ole, on ta puhkusel või haige – kõik, teil on probleemid.

Ja kolmas alus, mille me saavutasime. Me jõudsime sinna läbi valu, vere, pisarate – me jõudsime selleni, et iga meie versioon sisaldab vigu, isegi kui see on vabama vigadeta. Me otsustasime, et kui me midagi deploy’ime, kui me midagi tootmisse viime – on me versioon vigadega. Oleme määratlenud nõuded, millele meie süsteem peab vastama.

Nõuded tarkvara versiooni vahetusele

Nende nõuete arv on kolm:

• Me peame kiiresti tagasi tõmbama deploy.
• Me peame vähendama ebaõnnestunud deploy mõju.
• Ja peame suutma kiiresti paralleelselt juurutada.
  Just sellises järjekorras! Miks? Sest peamine eesmärk uue versiooni juurutamisel ei ole kiirus, vaid kui midagi läheb valesti, on oluline kiiresti tagasi pöörduda ja mõju minimeerida. Kuid kui teil on tootmises versioonide kogum, millel on viga (näiteks olukord, kus juurutust ei toimunud, kuid viga eksisteerib) – siis on teile oluline järgmise juurutuse kiirus. Mida me tegime, et need nõudmised täita? Kasutasime sellist metoodikat:

  
  
  See on piisavalt tuntud, me ei ole seda kunagi leiutanud – see on Blue/Green juurutamine. Mis see on? Iga serverigruppi, kuhu teie rakendused on paigaldatud, peaks olema koopia. Koopia on 'soe': seal ei ole liiklust, kuid igal hetkel saab sellele liikluse suunata. See koopia sisaldab eelmist versiooni. Ja juurutamise ajal te viite koodi passiivsele koopiale. Siis suunate osa liiklusest (või kogu) uuele versioonile. Seega, et liiklus vanalt versioonilt uuele suunata, peate tegema ainult ühe toimingu: peate upstreamis muutma koormustasakaidjat, muutma suunda – ühest upstreamist teise. See on väga mugav ja lahendab kiire ülemineku, kiire tagasipöördumise probleemi.

  Siin on lahenduse teine küsimus – minimiseerimine: te saate suunata uuele liinile, uue koodiga liinile vaid osa teie liiklusest (näiteks 2%). Ja need 2% – need ei ole 100%! Kui te kaotate 100% liiklusest ebaõnnestunud juurutamise tõttu – see on hirmutav, kui teil kaob 2% liiklusest – see on ebameeldiv, kuid see ei ole hirmutav. Veelgi enam, kasutajad tõenäoliselt ei märka seda, sest mõnel juhul (mitte alati) sama kasutaja vajutades F5 satub ta teise, töötavasse versiooni.

  Blue/Green juurutamine. Suunamine

  Samas ei ole kõik nii lihtne, kui 'Blue/Green' juurutamine... Kõik meie komponendid saab jagada kolme gruppi:

  • see on frontend (makse lehed, mida meie kliendid näevad);
  • tuumprotsess;
  • adapter maksesüsteemide (pangad, 'MasterCard', 'Visa' jne) jaoks.

  Siin on nüanss – see seisneb marsruutimises ridade vahel. Kui te lihtsalt suunate 100% liiklusest, siis selliseid probleeme ei teki. Kuid kui soovite suunata 2%, siis tekivad küsimused: "Kuidas seda teha?" Kõige lihtsam lahendus on see, et saate seadistada juhusliku valiku, Round Robin nginx'is, ja teil on 2% – vasakule, 98% – paremale. Kuid see ei sobi alati.

  Meil on näiteks kasutaja, kes interakteerub süsteemiga mitte ühe, vaid mitme päringuga. See on normaalne: 2, 3, 4, 5 päringut – teie süsteemid võivad olla samasugused. Ja kui te soovite, et kõik kasutaja päringud jõuaksid samale real, kuhu esimene päring tuli, või (teine asi) et kõik kasutaja päringud jõuaksid uuele reale pärast üleminekut (ta on võinud süsteemiga enne üleminekut juba töötada), – siis juhuslik jaotamine ei sobi. Sel juhul on järgmised võimalused:

  
  
  Esimene variant, kõige lihtsam – põhikliendi parameetrite põhjal (IP Hash). Teil on IP, ja te jagate liiklust paremale-vasakule vastavalt IP aadressile. Sel juhul kehtib teine minu kirjeldatud juhtum, kus toimus väljalaskmine, kasutaja on juba saanud teie süsteemiga töötada, ja alates väljalaskmisest suunatakse kõik päringud uuele reale (sama reale, ütleme).

  Kui see mingil põhjusel ei sobi ja peate tingimata saadma päringud sellele reale, kuhu tuli algne, initsialiseeriv päring, siis on teil kaks võimalust...
  Esimene võimalus: võite võtta tasulise nginx+. Seal on mehhanism Sticky sessions, mis algse päringu korral määrab kasutajale sessiooni ja seondab selle teatud ülesse. Kõik edasised kasutaja päringud sessiooni eluea jooksul saadetakse sellele samale ülesse, kuhu sessioon määrati.

  See ei sobinud meile, sest meil oli juba tavaline nginx. Üleminek nginx+ – see ei ole just kallis, kuid see oli meie jaoks natuke valus ja mitte just õige. "Sticky sessions" ei töötanud meie jaoks näiteks selle tõttu, et "Sticky sessions" ei võimalda marsruutimist tingimuse "Kas-kas" alusel. Seal on võimalik määrata, et me teeme "Sticky sessions" näiteks IP aadressi või IP aadressi ja küpsiste või POST parameetri alusel, kuid "Kas-kas" – seal on juba keerulisem.

  Seega jõudsime neljanda variandi juurde. Võtsime nginx'i "steroididega" (see on openresty) – see on sama nginx, mis toetab lisaks ka last-skripte. Saate kirjutada last-skripti, esitada selle “opernestile”, ja see last-skript käivitatakse, kui tuleb kasutaja päring.

  Ja me kirjutasime sellise skripti, paigaldasime “opernesti” ja selle skripti kaudu läbitame 6 erinevat parameetrit konkateneerimise „Või“. Sõltuvalt teatud parameetri olemasolust teame, et kasutaja tuli ühele lehele või teisele, ühele liinile või teisele.

  Blue/Green deploy. Eelised ja puudused.

  Muidugi oleks saanud seda ehk veidi lihtsamalt teha (kasutada samu „Sticky sessions“), kuid meil on veel selline nüanss, et meiega ei suhtle ainult kasutaja ühe tehingu töötlemise käigus... Asetame tööle ka maksesüsteemid: pärast tehingu töötlemist (saates päringu maksesüsteemile) saame tagasiside.
  Ja oletame, et kui meie ringis saame edastada kasutaja IP-aadressi kõigis päringutes ja IP-aadressi põhjal eristada, siis me ei tohi sama „Visa’le“ öelda: „Kutid, me oleme selline retroettevõte, me näiliselt rahvusvaheline (veebisaidil ja Venemaal)... Palun edastage meile, lisaks, kasutaja IP-aadress täiendavasse väljadese, teie standardiseeritud protokoll“! Loogiliselt nad ei nõustu.

  
  
  Seega ei sobinud meile see lahendus – tegime openresty. Seega, meie marsruutimine näeb välja järgmiselt:

  Blue/Green deploy'l on vastavad eelised, millest olen rääkinud, ja puudused.

  Puudusi on kaks:

  • peate muretsema marsruutimise pärast;
  • teine peamine puudus – see on kulud.

  Teil on vaja kaks korda rohkem servereid, kaks korda rohkem operatiivressursse, peate kulutama kaks korda rohkem jõude kogu selle loomaaia hooldamiseks.

  Muide, eeliste seas on veel üks asi, millest ma varem ei rääkinud: teil on varu, kui koormus tõuseb. Kui teie koormus kasvab plahvatuslikult ja teid üritab palju kasutajaid, saate lihtsalt lisada teise liini ja jagada koormust 50-50 – ja teil on kohe kaks korda rohkem servereid teie klastris, kuni te lahendate serverite puudumise probleemi.

  Kuidas teha kiiret deploy'd?

  Me rääkisime sellest, kuidas lahendada probleemi minimeerimise ja kiire tagasipöördumisega, kuid küsimus jääb: "Kuidas kiirelt deploy'ida"?

  
  
  Siin on lühidalt ja kõik on lihtne.

  • Teil peab olema pideva kohaletoimetamise süsteem (Continuous Delivery) – ilma selleta ei toimi. Kui teil on üks server, saate kasutada käsitsi deploy'd. Meil on umbes tuhat viissada serverit ja kui me käsitsi deploy'ime, on selge – me võiksime palgata osakonna, mis on sama suur kui see saal, lihtsalt selleks, et deploy'ida.
  • Deploy peab olema paralleelne. Kui teie deploy on järjestikune, siis on kõik halvasti. Ühe serveri puhul on see normaalne, aga tuhat viissada serverit deploy'id terve päeva.
  • Jällegi, selle kiirendamiseks pole see võib-olla enam vajalik. Deploy käigus tehakse tavaliselt projekti koostamine. Teil on veebi projekt, on frontend osa (teete seal web pack'i, npm koostate – midagi sellist) ja see protsess on põhimõtteliselt kiire – umbes 5 minutit, kuid need 5 minutit võivad olla kriitilised. Seetõttu me näiteks nii ei tee: me oleme need 5 minutit eemaldanud, me deploy'ime artefakte.

    Mis on artefakt? Artefakt on kokku kogutud build, kus on juba kõik koostamisprotsessid teostatud. Me hoiame seda artefakti artefaktide hoidlas. Selliseid hoidu oleme oma ajal kasutanud kahte – see oli Nexus ja nüüd jFrog Artifactory. "Nexus" kasutasime algselt, sest hakkasime seda lähenemist rakendama Java rakendustes (see sobis selleks hästi). Siis lisasime sinna ka osa rakendusi, mis on kirjutatud PHP's; ja "Nexus" ei sobinud enam ning seetõttu valisime jFrog Artifactory, mis suudab artefaktida praktiliselt kõike. Oleme isegi jõudnud selleni, et hoiame selles artefaktide hoidlas oma binaarpakette, mida me serveritele koostame.

  Plahvatuslik koormuse kasv

  Rääkisime tarkvara versiooni vahetamisest. Järgmine, mis meil on – plahvatuslik koormuse kasv. Siin ma ilmselt mõistan plahvatuslikku koormuse kasvu mitte täiesti õige asja tähendusena…

  Meie uus süsteem on teenuste orienteeritud, moodne ja ilus. Igal pool on töötajad, järjekorrad ja asünkroonsus. Sellistes süsteemides võivad andmed liikuda erinevates voogudes. Esimese tehingu jaoks võivad osaleda 1., 3. ja 10. töötaja, teise tehingu jaoks aga 2., 4. ja 5. töötaja. Ja täna, oletame, hommikul toimub andmevoog, mis kaasab esimesed kolm töötajat, aga õhtul muutub kõik ning kaasatakse teised kolm töötajat.

  Ja siin tuleb välja, et peate kuidagi töötajaid skaleerima, peavad teie teenused olema skaleeritavad, kuid samal ajal ei tohi ressursse liialdada.

  
  
  Olema oleme määratlenud enda nõudmised. Need nõudmised on piisavalt lihtsad: seal peab olema teenuse avastamine, parameetriseerimine – kõik on standardne, et ehitada selliseid skaleeritavaid süsteeme, välja arvatud üks punkt – see on ressursside amortiseerimine. Ütlesime, et me ei ole valmis ressursse amortiseerima, et serverid lihtsalt õhku soojendaks. Võtsime 'Consul'i ja 'Nomad'i, mis haldab meie töötajaid.

  Miks on see meie jaoks probleem? Las ma tagasi astun. Meie taga on hetkel umbes 70 maksesüsteemi. Hommikul liigub liiklus läbi 'Sberbanki', siis võib 'Sberbank' näiteks kokku kukkuda ja me lülitame selle teise maksesüsteemi. Meil töötas 100 töötajat 'Sberbanki' jaoks ja pärast seda peame äkitselt tõstma 100 töötajat teise maksesüsteemi jaoks. Ja see kõik peaks toimuma soovitatavalt ilma inimsekkumiseta. Sest kui on inimsekkumine – peab 24/7 olema insener, kes peaks ainult sellega tegelema, kuna selliseid katkestusi, kui 70 süsteemi on teie taga, juhtub regulaarselt.

  Seetõttu vaatasime 'Nomad'i, millel on avatud IP ja koostasime oma lahenduse Scale-Nomad – ScaleNo, mis teeb umbes järgmist: see jälgib järjekorra kasvu ning vähendab või suurendab töötajate arvu vastavalt järjekorra muutumise dünaamikale. Kui olime selle valmis teinud, mõtlesime: 'Kas võib selle avatud lähtekoodiga muuta?' Siis vaatasime seda – see on lihtne, nagu kaks senti.

  Me pole seda seni avatud lähtekoodiga muutnud, kuid kui teie jaoks on pärast ettekannet, pärast arusaama, et vajate sellist lahendust, vajadus tekkimas, siis viimasel slaidil on minu kontaktid – palun kirjutage mulle. Kui koguneb vähemalt 3-5 inimest – avame selle.

  
  
  Kuidas see töötab? Vaadakem! Ütleme kohe: vasakul pool on osa meie jälgimisest: see on üks joon, üleval – sündmuste töötlemise aeg, keskel – tehingute arv, all – töötajate arv.

  Kui vaadata, siis sellel pildil on tõrge. Ülemisel graafikul on üks joon 45 sekundi jooksul kadunud – üks maksesüsteem kukkus kokku. Seal oli kohe toodud liiklus kahe minuti jooksul ja kasvas järjekord teise maksesüsteemi juures, kus töötajaid polnud (me ei kasutanud ressursse – vastupidi, kasutasime ressursse õigesti). Me ei soovinud soojendada – seal oli minimaalne hulk, umbes 5-10 töötajat, kuid nad ei saanud hakkama.

  Viimasel graafikul on näha "kühm", mis näitab, et "Skaleeritud" tõstis seda arvu kaks korda. Ja siis, kui graafik natuke langes, vähendas ta seda veidi – töötajate arvu muudetakse automaatselt. Nii see süsteem töötab. Rääkisime punktist nr 2 – "Kuidas kiiresti vabaneda põhjustest".

  Jälgimine. Kuidas kiiresti probleemi tuvastada?

  Nüüd on esimene punkt – "Kuidas kiiresti probleemi tuvastada?" Jälgimine! Me peame kiiresti mõistma teatud asju. Milliseid asju peame me kiiresti mõistma?

  
  
  Kolm asja!

  • Peame kiiresti mõistma ja kiiresti mõistma meie enda ressursside töökindlust.
  • Peame kiiresti mõistma, kui midagi ebaõnnestub, jälgima süsteemide töökindlust, mis on meie jaoks välised.
  • Kolmas punkt – loogiliste vigade tuvastamine. See on siis, kui süsteem töötab teie jaoks, kõik näitajad on normaalsed, kuid miski ei toimi õigesti.

  Siin ma ilmselt ei räägi midagi tõeliselt lahe. Olen kapten Ilmselgus. Otsisime, mis turul on. Meil on tekkinud "naljakas loomaaias". Selline loomaed meil hetkel olemas on:

  
  
  Me kasutame "Zabbixi" raua jälgimiseks, serverite põhinäitajate jälgimiseks. "Okmeter" kasutame andmebaaside jaoks. "Grafana" ja "Prometheus" kasutame kõikide teiste näitajate jaoks, mis ei sobinud esimeste kahe alla, osa – "Grafana" koos "Prometheus'e", osa – "Grafana" koos "Influx" ja Telegrafiga.

  Aasta tagasi soovisime kasutada New Relici. Väga lahe asi, ta oskab kõike. Kuid niipalju kui ta kõike oskab, on ta ka kallis. Kui meie serverite arv tõusis 1500-ni, tuli meile müüja ja ütles: „Teeme järgmiseks aastaks lepingu.“ Vaatasime hinda ja otsustasime, et ei, me nii ei tee. Praegu loobume me New Relicust, meil on umbes 15 serverit, mis on veel New Relicu jälgimisel. Hind osutus täiesti pööraseks.

  Ja meil on üks tööriist, mille me ise välja töötasime – Debugger. Algul kutsusime seda „Baggeriks“, kuid hiljem tuli meie inglise keele õpetaja, naeris kõvasti ja muutsime nime „Debuggeriks“. Mis see on? See on tööriist, mis tegelikult 15-30 sekundi jooksul iga komponendi kohta, nagu süsteemi „must kast“, käivitab testid komponendi üldise töövõime kohta.

  Näiteks, kui väline leht (makseleht) – avab ta selle lihtsalt ja vaatab, kuidas see välja peaks nägema. Kui see on töötlemine, laseb ta teste „transaktsiooni“ – kontrollib, et see „transaktsioon“ üldse jõuaks kohale. Kui see on ühendus maksesüsteemidega – siis laseme testpäringu seal, kus saame, ja vaatame, et meil on kõik korras.

  Millised näitajad on jälgimiseks olulised?

  Mida me peamiselt jälgime? Millised näitajad on meile olulised?

  
  

  • Response time / RPS frontides – väga oluline näitaja. See näitab kohe, et teil on midagi valesti.
  • Töödeldud sõnumite arv kõigis järjekordades.
  • Tööliste arv.
  • Põhinäitajad korrektsuse kohta.

  Viimane punkt – „ärieluline“, „äritegevuse“ näitaja. Kui soovite sama jälgida, peate määratlema ühe-kaks näitajat, mis on teie jaoks põhinäitajad. Meie puhul on see näitaja – läbilaskevõime (see on eduka transaktsiooni arvu suhe kogu transaktsioonivoogu). Kui selle väärtus muutub 5-10-15 minuti jooksul – tähendab, et meil on probleemid (kui see kardinaalselt muutub).

  Kuidas see meil välja näeb – näide meie ühelt dashboardilt:

  
  
  Vasakul on 6 diagrammi, mis näitavad vastavalt realine - töötajate arvu ja sõnumite arvu järjekordades. Paremal on RPS, RTS. All on see äriline mõõdik. Ja selle äritootega näeme kohe, et keskmistel diagraamidel on midagi valesti ... See on just see, et järjekorrad on järjekordse süsteemi tõttu langenud, mis seisab meie taga.

  Teiseks, mida me pidime tegema, oli jälgida väliste maksesüsteemide katkestusi. Siin kasutasime OpenTracingut - mehhanism, standard, paradigma, mis võimaldab jälgida jaotatud süsteeme; ja muutsime seda veidi. Tavaline OpenTracingu paradigma ütleb, et ehitame iga eraldi päringu jälgimise. Meile seda ei olnud vaja, ja me pakkisime selle kokku akumuleerivasse jälgimisse. Loodud tööriist võimaldab meil jälgida meie taha jäävate süsteemide kiirus.

  
  
  Diagramm näitab meile, et üks maksesüsteem hakkas vastama 3 sekundi pärast - meil ilmusid probleemid. Samas reageerib see asi, kui probleemid hakkavad, 20–30 sekundi intervalis.

  Ja kolmas klass jälgimise vigu, mis eksisteerib - see on loogiline jälgimine.

  Ausalt öeldes ei teadnud ma, mida sellel slaidil joonistada, kuna me otsisime turult kaua, mis meile sobiks. Mitte midagi ei leidnud, seega tuli teha ise.

  
  
  Mida ma mõistan loogilise jälgimise all? Kujutage ette: teete endale süsteemi (näiteks 'Tinder' klooni); olete selle valmistanud ja tööle pannud. Edukas juht Vasja Pupkin pani selle oma telefonisse, näeb seal tüdrukut, meeldib talle... aga meeldimine ei lähe tüdrukule - see läheb selle sama ärikeskuse turvamees Mihhaile. Juht läheb alla ja siis imestab: "Miks see turvamees Mihhail nii lahkelt naeratab?"

  Sellistes olukordades… Meie jaoks kõlab see olukord veidi teisiti, kuna (nagu ma kirjutasin) on see reputatsioonikahju, mis kaudselt toob kaasa rahalised kaotused. Meie olukord on vastupidine: me võime otse rahalisi kahjusid kannatada – näiteks, kui me peame tehingut edukaiks, aga see ei olnud edukas (või vastupidi). Olime sunnitud kirjutama enda tööriista, mis jälgib ärinäitajate põhjal edukate tehingute arvu dünaamikat ajaintervallis. Turult ei leitud midagi! Just selle mõtte tahtsin ma edastada. Taoliste ülesannete lahendamiseks pole turul midagi.

  See käis selle kohta, kuidas kiiresti probleemi tuvastada.

  Kuidas määrata tõrgete põhjuseid

  Kolmas ülesannete rühm, mida me lahendame – pärast seda, kui oleme probleemi tuvastanud, pärast seda, kui oleme sellest vabanenud, oleks hea mõista põhjust, et arendada, testida ja midagi sellega ette võtta. Seega peame uurima, tõstma esile logid.

  
  
  Kui me räägime logidest (peamine põhjus – logid), on meie logide peamine osa ELK Stakis – praktiliselt kõigil on nii. Mõnel võibolla ei ole ELK-d, aga kui kirjutate logisid gigabaidiga, siis jõuate varem või hiljem ELK-nimelise lahenduseni. Meie kirjutame neid terabaidiga.

  
  
  Siin on probleem. Me parandasime, lahendasime kasutaja jaoks vea, hakkasime uurima, mis see täpselt oli, läksime «Kibanas» logisid vaatama, sisestasime seal tehingu ID ja saime sellise portaali (näitab palju). Ja selles portaalis ei ole midagi selgelt arusaadav. Miks? Sest ei ole selge, milline osa kuulub millisele töötlejale, milline osa kuulub millisele komponendile. Ja sel hetkel mõistsime, et meil on vaja jälgimist – just seda OpenTracing, millest ma rääkisin.

  Mõtlesime sellele aasta tagasi, suunates oma pilgu turule, ja seal selgus kaks tööriista – «Zipkin» ja «Jaeger». «Jaeger» on tegelikult ideoloogiline järeltulija, ideoloogiline jätk «Zipkinile». «Zipkinis» on kõik hea, välja arvatud see, et ta ei oska aggregeerida, ei oska logisid jälgimisse lisada, vaid ainult ajajälgimist. «Jaeger» toetas seda.

  Vaatasime „Egeri“ – rakendusi saab instrumenteerida, saab kirjutada API (selle aja jaoks PHP standard API, muidugi, ei olnud veel kinnitatud – see oli aasta tagasi, aga nüüd on juba kinnitatud), kuid klienti ei olnud absoluutselt. „Selge,“ mõtlesime ja kirjutasime oma kliendi. Mis meil välja tuli? Umbes nii see välja näeb:

  
  
  „Egeris“ luuakse iga sõnumi jaoks span’id. See tähendab, et kui kasutaja avab süsteemi, näeb ta iga sissetuleva päringu kohta ühte või kahte plokki (1-2-3 – nii palju sissetulevaid päringuid kasutajalt oli, nii palju on blokke). Selleks, et kasutajatel oleks lihtsam, lisasime logide ja ajajälgimise juurde sildid. Seega, kui juhtub viga, märgib meie rakendus logi vastava Error sildiga. Saame filtreerida Error sildi järgi ja kuvatakse ainult need span’id, mis sisaldavad seda veaga plokki. Nii see välja näeb, kui me span’i avame:

  
  
  Span’i sees on rida jälgimisandmeid. Antud juhul on need kolm testjälgimist ja kolmas jälgimine ütleb meile, et tekkis viga. Samuti näeme siin ajajälgimist: meil on üleval – ajaskaalal ja me näeme, millisel ajavahemikul see või teine logi on salvestatud.

  Seega läks meil suurepäraselt. Kirjutasime oma laienduse ja avasime selle avatud lähtekoodiga. Kui soovite töötada jälgimisega, kui soovite kasutada „Egerit“ PHP keeles – meie laiendus on olemas, nagu öeldakse, welcome to use:

  
  
  Meie laiendus on klient OpenTracing API jaoks, see on tehtud php-extention’ina, mis tähendab, et peate selle koguma ja süsteemi seadistama. Aasta tagasi ei olnud midagi muud. Praegu on ilmunud veel teisi kliente, mis on komponendid. Siin on teie valida: kas tõstate komponendid composeriga üles või kasutate laiendust, see on teie valik.

  Ettevõtte standardid

  Rääkisime kolmest käsust. Neljas käsk – standardiseerida lähenemisi. Mis see on? See on umbes see:

  
  
  Miks on siin sõna „ettevõtte“? Mitte sellepärast, et me oleme suur või bürokraatlik ettevõte, ei! Sõna „ettevõtte“ kasutasin ma siinkohal selle kontekstis, et igal ettevõttel, igal tuotteel peavad olema omad standardid, ja teil samuti. Millised standardid meil siis on?

  
  

  • Meil on deploiendirektiiv. Ilma selleta me ei liigu kuhugi, ei suuda. Me deploime umbes 60 korda nädalas, seega meie deploiendid toimuvad praktiliselt pidevalt. Samas on meil näiteks direktiivis tabu deploiendi tegemiseks reede õhtul – põhimõtteliselt me ei deploime.
  • Meil on dokumentatsioon kohustuslik. Ükski uus komponent ei jõua meie tootmisse, kui selle kohta pole dokumentatsiooni, isegi kui see on loodud meie RnD spetsialistide poolt. Nõuame neilt deploiendi juhendit, seirekaart ja umbkaudu kirjelduse (noh, nagu programmerijad suudavad kirjutada) selle kohta, kuidas see komponent töötab, kuidas seda probleemide korral lahendada.
  • Me lahendame mitte probleemi põhjust, vaid probleemi – nagu ma juba rääkisin. Meie jaoks on oluline kaitsta kasutajat probleemide eest.
  • Meil on lubadused. Näiteks me ei arva, et olukord on allakäik, kui me kahe minuti jooksul kaotasime 2% liiklusest. See ei kuulu meie statistikas arvesse. Kui protsent või aeg on suurem, siis me juba arvestame.
  • Ja me kirjutame alati postmortem'e. Mida iganes meiega ka ei juhtuks, iga olukord, kus tootmises käitus midagi anomaalselt, kajastub postmortem'is. Postmortem on dokument, kus sa kirjutad, mis juhtus, detailsed ajakavad, mida sa tegid parandamiseks ja (see on kohustuslik osa!) mida sa teed, et midagi sellist tulevikus vältida. See on hädavajalik edasiseks analüüsiks.

  Kuidas arvestada allakäiku?

  
  
  Kuhu see kõik viis?

  See viis selleni, et (meil olid teatud stabiilsusprobleemid, mis ei rahuldanud ei kliente ega meid) meie stabiilsusindikaator viimase 6 kuu jooksul oli 99,97. Võib öelda, et see ei ole väga palju. Jah, meil on veel eesmärke. Sellest näitajast ligikaudu pooled on stabiilsus, mis ei ole iseenesest meie, vaid meie veebirakenduse tulemüür, mis meie ees seisab ja teenusena kasutatakse, kuid klientidele ei ole see oluline.

  Oleme õppinud öösel rahulikult magama. Lõ finally! Pool aastat tagasi ei osanud me seda. Ja selle märkuse juures tahaksin teha ühe täienduse. Eile õhtul oli suurepärane ettekande teemal tuumareaktori juhtimissüsteem. Kui mind kuulevad inimesed, kes seda süsteemi kirjutasid – palun unustage, mida ma ütlesin "2% – see ei ole allakäik". Teie jaoks on 2% allakäik, isegi kui see kestab kaks minutit!

  See sellele! Teie küsimused.

  
  

  Tasakaalustajatest ja andmebaasi migreerimisest

  Küsimus publikust (edaspidi - K): – Tere õhtust. Suur aitäh sellise haldustöö esitamise eest! Küsimus on lühike, teie tasakaalustajate teemal. Te mainisite, et teil on WAF, nii et nagu ma aru saan, kasutate tasakaalustajana mingit välist…

  EK: – Ei, tasakaalustajana kasutame oma teenuseid. Antud juhul on WAF meile lihtsalt DDoS-i kaitse tööriist.

  K: – Kas võiks paar sõna tasakaalustajate kohta?

  EK: – Nagu ma juba ütlesin, on see grupo servereid openresty-s. Meil on praegu 5 varutud grupi, mis tegelevad ainult… ehk server, millel on ainult openresty, suunab vaid liiklust. Vastavalt arusaamale, kui palju me hoidame: praegu on meie tavavoog – see on mitu sada megabitti. Nad saavad sellega hakkama, neil on hästi, isegi ei pinguta.

  K: – Samuti lihtne küsimus. On olemas Blue/Green deployment. Mis teete, näiteks, andmebaasi migreerimisega?

  EK: – Hea küsimus! Vaadake, meil on Blue/Green deployment'is iga rea jaoks eraldi järjekorrad. Ehk, kui räägime sündmuste järjekordadest, mis edastatakse töötajalt töötajale, siis seal on eraldi järjekorrad sinise ja rohelise rea jaoks. Kui räägime ise andmebaasist, siis oleme seda tahtlikult kitsendanud, peaaegu kõik edastamine on järjekordades, andmebaasis hoiame vaid tehingute steki. Ja tehingute stek on meil ühiselt kõigi ridade jaoks. Andmebaasi puhul: me ei eralda seda siniseks ja roheliseks, sest mõlemad koodiversioonid peavad teadma, mis toimub tehinguga.

  Sõbrad, mul on veel üks väike auhind, et teid motiveerida – raamat. Ja ma pean selle andma parima küsimuse eest.

  K: – Tere. Aitäh esituse eest. Küsimus on järgmine. Te jälgite makseid, jälgite teenuseid, millega suhtlete… Kuidas te jälgite seda, et inimene mingil viisil jõuab teie makselehele, teeb makse, ja projekt kannab talle raha? Ehk kuidas te jälgite, et kaupmees on saadaval ja on teie callback'i vastu võtnud?

  EK: – „Kaupmees“ on meie jaoks antud juhul täpselt sama väline teenus, mis maksesüsteem. Me jälgime kaupmehe vastuse kiirus.

  Andmebaasi krüpteerimisest

  K: – Tere. Mul on üks väike küsimus. Kas teil on PCI DSS-i alusel tundlikke andmeid? Tahtsin teada, kuidas te järjekordades PAN-e salvestate, mida peate edastama? Kas kasutate mingit krüpteerimist? Ja sealt tulenev teine küsimus: PCI DSS-i kohaselt tuleb andmebaasi perioodiliselt uuesti krüpteerida, kui toimub muudatusi (nt administraatorite lahkumine) – kuidas sel juhul käib ligipääsetavus?

  
  
  EK: – Suurepärane küsimus! Esiteks, me ei salvesta PAN-e järjekordades. Meil ei ole õigust salvestada PAN-e avatud kujul, seega kasutame spetsiaalset teenust (me nimetame seda 'Keydemon') – see teenus teeb ainult ühte asja: see võtab sisendiks sõnumi ja tagastab krüpteeritud sõnumi. Ja me salvestame kõik sellega krüpteeritud sõnumid. Vastavalt on meie võtme pikkus alla kilobaidi, et see oleks tõeliselt tõhus ja usaldusväärne.

  K: – Kas nüüd on tõesti juba 2 kilobaiti vaja?

  EK: – Tundub, et veel eile oli 256... Kuhu veel?!

  Seetõttu on see esiteks. Ja teiseks toetab olemasolev lahendus uuesti krüpteerimise protseduuri – seal on kaks paari 'kekke' (võtmeid), mis annavad 'dekke', mis krüpteerivad (kek on võtmed, dek on võtmete derivaat, mis krüpteerivad). Ja kui algatatakse protsess (see toimub regulaarselt, 3 kuu kuni ± millegi vahel), laeme uue paari 'kekke' ning meil toimub andmete uuesti krüpteerimine. Meil on eraldi teenused, mis võtavad kõik andmed välja, krüpteerivad need uuesti; andmete kõrval on võtme identifikaator, millega need on krüpteeritud. Seega, kui andmed on uute võtmetega krüpteeritud, eemaldame vanad võtmed.

  Mõnikord tuleb makseid käsitsi teostada...

  K: – Seega, kui toimub tagasimakse mõne tehingu puhul, kas krüpteerite seni vana võtmega?

  EK: – Jah.

  K: – Siis veel üks väike küsimus. Kui toimub mingi tõrge, kukkumine, intsident, siis tuleb tehingut käsitsi edasi juhatada. Selline olukord võib ette tulla.

  EK: – Jah, see juhtub.

  K: – Kust te need andmed võtate? Kas te ise käite käsitsi selles salvestuses?

  EK: – Ei, no muidugi – meil on olemas mingi tagalasüsteem, mis sisaldab meie toe jaoks liidest. Kui me ei tea, mis staatuses tehing on (näiteks kuniks maksesüsteem ei vasta ajapiiril) – siis me põhimõtteliselt ei tea, st me määrame lõpliku staatuse ainult täieliku kindluse korral. Sel juhul suuname tehingu eraldi staatusesse käsitsi töötlemiseks. Hommikul, järgmisel päeval, niipea kui tugi saab info, et maksesüsteemis on säilinud sellised tehingud, töötlevad nad need hädasti käsitsi sellel liidesel.

  
  
  K: – Mul on paar küsimust. Üks neist on PCI DSS tsooni jätkamine: kuidas te viite logid nende kontuurist välja? Selline küsimus, sest arendaja võis logidesse panna absoluutset kõike! Teine küsimus: kuidas te väljastate hotfix'e? Käsitsi andmebaasis – see on üks variant, aga võivad olla ka tasuta hotfix'id – mis seal protseduur on? Ja kolmas küsimus, ilmselt seondub see RTO ja RPO-ga. Teie kättesaadavus oli 99,97, peaaegu neli üheksat, aga ma saan aru, et teil on teine andmekeskus, kolmas andmekeskus ja viies andmekeskus… Kuidas te tegelete nende sünkroniseerimise, replikatsiooni ja muu sellisega?

  EK: – Alustame esimesest. Kas esimene küsimus oli logide kohta? Meie puhul, kui logisid kirjutatakse, on seal vahekiht, mis maskib kõik tundlikud andmed. See vaatab maski ja lisaväljade järgi. Seetõttu on meie logid juba maskitud andmete ja PCI DSS kontuuriga. See on üks rutiinseid ülesandeid, mis on määratud testimise osakonnale. Nad peavad kontrollima iga ülesannet sealhulgas ka logide järgi, mida nad kirjutavad, ja see on üks rutiinseid ülesandeid koodikontrolli raames, et jälgida, et arendaja ei oleks midagi salvestanud. Edasine kontroll toimub regulaarselt infosüsteemide turbe osakonna poolt umbes kord nädalas: valitakse välja logid viimase päeva jooksul ja need analüüsitakse spetsiaalse skanner-analyzeriga testserveritest, et kõike kontrollida.
  Hot-fix'idest. See on meil deploide reglemendi osa. Oleme eraldi välja toonud punkt hot-fix'ide kohta. Me arvame, et me deploime hot-fix'e ööpäevaringselt siis, kui me seda vajame. Nii kui versioon on kokku pandud, nii kui see on testitud, nii kui meil on artefakt – tõuseb hädaabi süsteemiadministraator, kes on toetuse kõnes, ja ta deploib selle just siis, kui see on vajalik.

  Neljast üheksast. See number, mis meil praegu on, on tõeliselt saavutatud, ja me püüdsime seda ka teises andmekeskuses. Praegu on meil teine andmekeskus ja hakkame nende vahel suunama, ja andmekeskuste replikatsiooni probleem on tõeliselt keeruline. Oleme püüdnud seda oma ajal erinevate meetoditega lahendada: proovisime kasutada sama 'Tarantulit' – see ei läinud meil läbi, ütlen kohe. Seetõttu oleme jõudnud järeldusele, et teeme 'sensat' käsitsi. Iga rakendus synchroniseerib tegelikult asünkroonselt vajaliku 'change – done' andmekeskuste vahel.

  K: – Kui teil on teine, siis miks ei ole kolmandat? Sest Split-brain'i pole veel keegi…

  EK: – Meil ei ole 'Split-brain'i. Kuna iga rakendus käitab multi-masterit, ei ole meile oluline, millisesse keskusesse päring tuli. Oleme valmis, et juhul, kui üks andmekeskus kukub (me arvestame sellega) ja kasutaja päringu keskpunkti vahetame teise andmekeskusesse, siis oleme valmis selle kasutaja kaotamiseks, tõeliselt; kuid neid on tõeliselt vähe, absoluutne harv.

  K: – Tere õhtust. Aitäh ettekande eest. Te rääkisite oma debuggersist, mis production'is käitavad mingisuguseid testtransaktsioone. Aga räägi testtransaktsioonidest! Kui sügavale see ulatub?

  EK: – See läbib kogu komponendi täieliku tsükli. Komponendi jaoks ei ole vahet testtransaktsiooni ja tootmistransaktsiooni vahel. Ja loogika seisukohalt on see lihtsalt mingi eraldi projekt süsteemis, kus tehakse ainult testtransaktsioone.

  K: – Kuidas te selle välja filtreerite? Siin on Core saatnud…

  EK: – Me jälgime 'Cori' antud juhul testtransaktsioonide jaoks… Meil on selline mõisted nagu suunamine: 'Core' teab, millisesse maksesüsteemi tuleb saata – saadame vale maksesüsteemi, mis lihtsalt annab http-vastuse ja kõik.

  K: – Palun öelge, kas teie rakendus on kirjutatud ühe suure monoliidina või olete selle jaganud teenusteks või isegi mikroteenusteks?

  EK: – Meil ei ole monoliiti, meie rakendus on teenustepõhine. Meil on nalja, et meil on teenused monoliitide seest – need on tõeliselt piisavalt suured. Mikroteenusteks seda päris nimetada ei saa, aga need on tõeliselt teenused, mille sees töötavad jaotatud masinate töölauad.

  Kui teenus serveris on kompromiteeritud…

  K: – Siis on mul järgmine küsimus. Isegi kui see oleks monoliit, ütlesite siiski, et teil on palju neid instant-servereid, kõik nad põhimõtteliselt töötlevad andmeid, ja küsimus on selline: "Kuidas on juurdepääsul ühe instant-serveri või rakenduse, mõne konkreetse elemendi puhul? Milliseid õiguseid neil on? Kes võib mida teha? Kelle poole pöörduda, milliste andmete jaoks?"

  
  
  EK: – Jah, kindlasti. Turvanõuded on piisavalt ranged. Esiteks, meil on avatud andmevood ja sadamad ainult need, mille kohta me eelnevalt eeldame andmevoo liikumist. Kui komponent suhtleb andmebaasiga (ütleme, et MySQL) portidel 5-4-3-2, siis avatakse talle ainult port 5-4-3-2 ja teised sadamad, teised liikuvusliinid ei ole kergesti ligipääsetavad. Lisaks tuleb aru saada, et meil on tootmisüksustes umbes 10 erinevat turvaseadet. Ja isegi kui rakendus on kuidagi kompromiteeritud, jumal hoidku, ei saa ründaja ligipääsu serveri halduskeskkonda, sest see on teine turvaala.

  K: – Mind huvitab antud kontekstis rohkem see, et teil on mingid lepingud teenustega – mida nad saavad teha, milliste "tegevuste" kaudu nad saavad üksteisega suhelda... Ja tavaliselt küsivad mingid spetsiifilised teenused üksteiselt teatud tegevuste loendit. Teised nad tavalistes olukordades ei pöördu ja neil on teised vastutusalad. Kui aga üks neist on kompromiteeritud, kas ta saab siis tõmmata "tegevusi" selle teenuse kohta...?

  EK: – Ma saan aru. Kui tavatingimustes on teise serveriga suhtlemine lubatud, siis – jah. SLA-lepinguga me ei jälgi, et sulle on lubatud ainult esimesed 3 „tegevust”, aga 4. „tegevus” on keelatud. See on tõenäoliselt meile ülearune, sest meil on nii või teisiti neljatasandiline kaitsesüsteem kontuuride jaoks. Me eelistame kaitsta kontuuride kaudu, mitte süvalehte tasandil.

  Kuidas toimivad Visa, MasterCard ja „Sberbank”

  K: – Soovin täpsustada hetke kasutaja üleminekust ühest andmekeskusest teise. Nagu ma tean, toimivad „Visa” ja „MasterCard” binaarsel sünkroonprotokollil 8583, seal on mikserid. Ja tahaksin teada, kas jutt käib üleminekust – kas see on otse „Visa” ja „MasterCardi” või maksesüsteemide, töötlemiskeskuste kohta?

  EK: – See on mikserite juurde. Mikserid on meil ühes andmekeskuses.

  K: – Ühuldudes öeldes, kas teil on üks ühenduspunkt?

  EK: – „Visale” ja „MasterCardile” – jah. Lihtsalt selle tõttu, et „Visa” ja „MasterCard” nõuavad märkimisväärseid investeeringuid infrastruktuuri, et sõlmida eraldi lepingud teise mikseripaariga, näiteks. Need on reserveeritud ühes andmekeskuses, kuid kui meil juhtub, jumal hoidku, andmekeskus, kus mikserid „Visa” ja „MasterCard” ühendamiseks asuvad, laguneb, siis side „Visa” ja „MasterCardiga” kaob...

  K: – Kuidas nad saavad olla reserveeritud? Tean, et „Visa” lubab pidada põhimõtteliselt vaid ühte ühendust!

  EK: – Nad toovad ise varustuse. Igal juhul on meil jõudnud varustus, mis on sisemiselt kindlalt reserveeritud.

  K: – Kas see tähendab, et riiul on pärit nende Connects Orange’ilt?

  EK: – Jah.

  K: – Ent mis siis juhtub, kui teie andmekeskus lakkab eksisteerimast? Kuidas edasi liikuda? Kas liiklus lihtsalt peatub?

  EK: – Ei. Me sel juhul lihtsalt suuname liikluse teisele kanalile, mis loomulikult maksab meile ja klientidele rohkem. Kuid liiklus ei lähe läbi meie otsese ühenduse „Visa”, „MasterCardi”, vaid läbi tinglikku „Sberbanki” (väga ülekohtuselt).

  Vabandan, kui ma puutin „Sberbanki” töötajaid. Kuid meie statistika kohaselt langeb „Sberbank” vene pankade seas kõige sagedamini. Kuu aega ei möödu, et „Sberbankil” midagi ei katke.

  
  
  

  

  Veidi reklaami 🙂

  Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. Pilve VPS arendajatele alates $4.99, ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: Kogu tõde VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps alates $19 või kuidas jagada serverit õigesti? (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).

  Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TB alates $199 Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest Kuidas luua ettevõtte tasemel infrastruktuuri, kasutades Dell R730xd E5-2650 v4 servereid, mille hind on 9000 eurot, taskukohase hinna eest?

Allikas: habr.com