HighLoad++, Evgeniy Kuzovlev (EcommPay IT): mida teha, kui minut seisakuid maksab 100000 XNUMX dollarit

Kõik räägivad arendus- ja testimisprotsessidest, personali koolitamisest, motivatsiooni tõstmisest, kuid neist protsessidest ei piisa, kui minutiline teenindusseisak maksab tohutult raha. Mida teha, kui sooritate finantstehinguid range SLA alusel? Kuidas suurendada oma süsteemide töökindlust ja tõrketaluvust, jättes arenduse ja testimise võrrandist välja?

Järgmine HighLoad++ konverents peetakse 6. ja 7. aprillil 2020 Peterburis. Üksikasjad ja piletid link. 9. november kell 18. HighLoad++ Moskva 00, Delhi + Kolkata hall. Teesid ja esitlus.

Jevgeni Kuzovlev (edaspidi – EK): - Sõbrad, tere! Minu nimi on Kuzovlev Evgeniy. Olen ettevõttest EcommPay, konkreetseks divisjoniks on ettevõtete grupi IT-divisjon EcommPay IT. Ja täna räägime seisakutest - sellest, kuidas neid vältida, kuidas minimeerida nende tagajärgi, kui seda pole võimalik vältida. Teema on välja toodud järgmiselt: “Mida teha, kui minut seisakuid maksab 100 000 dollarit”? Tulevikku vaadates on meie numbrid võrreldavad.

Mida EcommPay IT teeb?

Kes me oleme? Miks ma siin teie ees seisan? Miks on mul õigus sulle siin midagi rääkida? Ja millest me siin täpsemalt räägime?

EcommPay ettevõtete grupp on rahvusvaheline omandaja. Töötleme makseid üle kogu maailma – Venemaal, Euroopas, Kagu-Aasias (All Around the World). Meil on 9 kontorit, kokku 500 töötajat, kellest ligi pooled on IT-spetsialistid. Kõik, mida teeme, kõik, millest raha teenime, tegime ise.

Kirjutasime kõik oma tooted (ja neid on meil päris palju - meie suurte IT-toodete sarjas on umbes 16 erinevat komponenti) ise; Kirjutame ise, arendame ennast. Ja hetkel teeme päevas umbes miljon tehingut (miljonid on ilmselt õige viis). Oleme üsna noor ettevõte – oleme alles umbes kuueaastased.

6 aastat tagasi oli see selline startup, kui poisid äriga kaasa tulid. Neid ühendas idee (polnud muud kui idee) ja me jooksime. Nagu iga startup, jooksime ka kiiremini... Meie jaoks oli kiirus tähtsam kui kvaliteet.

Mingil hetkel jäime seisma: saime aru, et me ei saa enam kuidagi sellise kiiruse ja kvaliteediga elada ning peame esmalt keskenduma kvaliteedile. Sel hetkel otsustasime kirjutada uue platvormi, mis oleks õige, skaleeritav ja usaldusväärne. Nad hakkasid seda platvormi kirjutama (hakkasid investeerima, arendama arendust, testima), kuid mingil hetkel said nad aru, et arendus ja testimine ei võimalda meil teenuse kvaliteedis uuele tasemele jõuda.

Teete uue toote, paned selle tootmisse, aga ikkagi läheb kuskil midagi viltu. Ja täna räägime sellest, kuidas jõuda uuele kvaliteeditasemele (kuidas me seda tegime, oma kogemustest), võttes võrrandist välja arenduse ja testimise; Räägime sellest, mis on tööks saadaval – milline operatsioon saab ise hakkama, mida suudab testimisele pakkuda, et kvaliteeti mõjutada.

Seisakud. Käsud tegutsemiseks.

Alati peamine nurgakivi, millest me täna tegelikult räägime, on seisakud. Kohutav sõna. Kui meil on seisakuid, on kõik meie jaoks halb. Me jookseme seda tõstma, administraatorid hoiavad serverit - hoidku jumal, et see ei kukuks, nagu selles laulus öeldakse. Sellest me täna räägime.

Kui hakkasime oma lähenemisviise muutma, moodustasime 4 käsku. Mul on need esitletud slaididel:

Need käsud on üsna lihtsad:

• Tuvastage probleem kiiresti.
• Vabane sellest veelgi kiiremini.
• Aidake põhjust mõista (hiljem arendajatele).
• Ja standardiseerige lähenemisviisid.

Juhin teie tähelepanu punktile nr 2. Me vabaneme probleemist, mitte ei lahenda seda. Otsustamine on teisejärguline. Meie jaoks on esmane, et kasutaja oleks selle probleemi eest kaitstud. See eksisteerib mõnes isoleeritud keskkonnas, kuid see keskkond ei puutu sellega kokku. Tegelikult käime need neli probleemigruppi läbi (mõni täpsemalt, mõni vähem), räägin, mida me kasutame, milline asjakohane kogemus meil lahenduste vallas on.

Tõrkeotsing: millal need ilmnevad ja mida nendega teha?

Aga alustame korrast ära, alustame punktist nr 2 - kuidas kiiresti probleemist lahti saada? On probleem – me peame selle parandama. "Mida me peaksime sellega tegema?" - põhiküsimus. Ja kui hakkasime mõtlema, kuidas probleemi lahendada, töötasime enda jaoks välja mõned nõuded, mida veaotsing peab järgima.

Nende nõuete sõnastamiseks otsustasime esitada endale küsimuse: "Millal meil probleeme on?" Ja nagu selgus, ilmnevad probleemid neljal juhul:

• Riistvara rike.
• Välisteenused ebaõnnestusid.
• Tarkvara versiooni muutmine (sama juurutus).
• Plahvatusliku koormuse kasv.

Kahest esimesest me ei räägi. Riistvara rikke saab lahendada üsna lihtsalt: kõik peab olema dubleeritud. Kui need on kettad, tuleb kettad kokku panna RAID-is; kui tegemist on serveriga, siis tuleb server dubleerida; kui teil on võrguinfrastruktuur, peate esitama võrguinfrastruktuuri teise koopia, st võtate selle ja dubleerida seda. Ja kui midagi ebaõnnestub, lülitute reservvõimsusele. Siin on raske midagi rohkemat öelda.

Teine on välisteenuste ebaõnnestumine. Enamiku jaoks pole süsteem üldse probleem, kuid mitte meie jaoks. Kuna töötleme makseid, oleme agregaator, mis seisab kasutaja (kes sisestab oma kaardiandmed) ja pankade, maksesüsteemide (Visa, MasterCard, Mira jne) vahel. Meie välisteenused (maksesüsteemid, pangad) kipuvad ebaõnnestuma. Ei meie ega teie (kui teil on selliseid teenuseid) ei saa seda mõjutada.

Mida siis teha? Siin on kaks võimalust. Esiteks, kui saate, peaksite seda teenust mingil viisil dubleerima. Näiteks kanname võimalusel liiklust ühelt teenuselt teisele: näiteks kaarte töödeldi Sberbanki kaudu, Sberbankil on probleeme - edastame liikluse [tinglikult] Raiffeisenile. Teine asi, mida saame teha, on välisteenuste rikkeid väga kiiresti märgata ja seetõttu räägime reageerimiskiirusest raporti järgmises osas.

Tegelikult saame neist neljast konkreetselt mõjutada tarkvaraversioonide muutmist – võtta kasutusele tegevusi, mis viivad olukorra paranemiseni juurutuste kontekstis ja koormuse plahvatusliku kasvu kontekstis. Tegelikult me ​​seda tegimegi. Siin jälle väike märkus...

Neist neljast probleemist lahendatakse mitu kohe, kui teil on pilv. Kui olete Microsoft Azhuri, Ozone'i pilvedes või kasutate meie Yandexi või Maili pilvi, saab nende probleemiks vähemalt riistvara rike ja riistvara rikke kontekstis muutub teie jaoks kohe kõik hästi.

Oleme veidi ebatavaline ettevõte. Siin räägivad kõik “Kubernetsist”, pilvedest - meil pole ei “Kubernetsit” ega pilvi. Kuid meil on paljudes andmekeskustes riistvarariiulid ja me oleme sunnitud selle riistvaraga elama, oleme sunnitud selle kõige eest vastutama. Seetõttu räägime selles kontekstis. Niisiis, probleemidest. Kaks esimest võeti sulgudest välja.

Tarkvara versiooni muutmine. Alused

Meie arendajatel puudub juurdepääs tootmisele. Miks nii? Asi on selles, et meil on PCI DSS-sertifikaat ja meie arendajatel pole lihtsalt õigust sellesse tootesse siseneda. See on kõik, punkt. Üleüldse. Seetõttu lõpeb arendusvastutus täpselt sel hetkel, kui arendus esitab järgu avaldamiseks.

Meie teine ​​alus, mis meil on ja mis meid samuti palju aitab, on ainulaadsete dokumentideta teadmiste puudumine. Loodan, et see on teie jaoks sama. Sest kui see nii ei ole, on teil probleeme. Probleemid tekivad siis, kui need ainulaadsed, dokumenteerimata teadmised pole õigel ajal ja õiges kohas olemas. Oletame, et teil on üks inimene, kes teab, kuidas konkreetset komponenti kasutusele võtta – inimest pole kohal, ta on puhkusel või haige – see on kõik, teil on probleeme.

Ja kolmas alus, milleni oleme jõudnud. Jõudsime selleni läbi valu, vere, pisarate – jõudsime järeldusele, et iga meie ehitus sisaldab vigu, isegi kui see on veatu. Otsustasime selle ise: kui me midagi juurutame, kui paneme midagi tootmisse, on meil vigadega konstruktsioon. Oleme kujundanud nõuded, millele meie süsteem peab vastama.

Nõuded tarkvara versiooni muutmisele

Nõuet on kolm:

• Peame kasutuselevõtu kiiresti tagasi tõmbama.
• Peame minimeerima ebaõnnestunud kasutuselevõtu mõju.
• Ja me peame suutma kiiresti paralleelselt kasutusele võtta.
  Täpselt sellises järjekorras! Miks? Sest esiteks ei ole uue versiooni juurutamisel kiirus oluline, aga kui midagi läheb valesti, siis on oluline kiiresti tagasi kerida ja minimaalselt mõjuda. Kuid kui teil on tootmises versioonide komplekt, mille puhul selgub, et tegemist on veaga (ärast ilma, et juurutamist ei toimunud, kuid on viga) - on teie jaoks oluline järgneva juurutamise kiirus. Mida oleme nende nõudmiste täitmiseks teinud? Kasutasime järgmist metoodikat:

  
  
  See on üsna tuntud, me pole seda kunagi leiutanud – see on sinine/roheline juurutamine. Mis see on? Teil peab olema koopia iga serverirühma kohta, kuhu teie rakendused on installitud. Koopia on “soe”: sellel pole liiklust, kuid igal hetkel saab selle liikluse sellele koopiale saata. See koopia sisaldab eelmist versiooni. Ja juurutamise ajal avaldate koodi passiivseks koopiaks. Seejärel lülitate osa liiklusest (või kogu) uuele versioonile. Seega, selleks, et muuta liiklusvoogu vanalt versioonilt uuele, peate tegema ainult ühe toimingu: peate vahetama ülesvoolu tasakaalustajat, muutma suunda - ühest ülesvoolust teise. See on väga mugav ja lahendab kiire ümberlülitamise ja kiire tagasipööramise probleemi.

  Siin on teise küsimuse lahendus minimeerimine: saate saata ainult osa oma liiklusest uuele reale, uue koodiga reale (olgu see näiteks 2%). Ja need 2% pole 100%! Kui kaotasite ebaõnnestunud kasutuselevõtu tõttu 100% liiklusest, on see hirmutav; kui kaotasite 2% liiklusest, on see ebameeldiv, kuid mitte hirmutav. Pealegi ei pane kasutajad seda suure tõenäosusega isegi tähele, sest mõnel juhul (mitte kõigil) suunatakse sama kasutaja F5 vajutades teise töötavasse versiooni.

  Sinine/roheline kasutuselevõtt. Marsruutimine

  Kõik pole aga nii lihtne “Blue/Green deploy”... Kõik meie komponendid võib jagada kolme rühma:

  • see on kasutajaliides (maksete lehed, mida meie kliendid näevad);
  • töötlemise südamik;
  • adapter maksesüsteemidega töötamiseks (pangad, MasterCard, Visa...).

  Ja siin on nüanss – nüanss peitub liinidevahelises marsruutimises. Kui muudate lihtsalt 100% liiklust, pole teil neid probleeme. Aga kui soovite 2% vahetada, hakkate esitama küsimusi: "Kuidas seda teha?" Lihtsaim asi on otse edasi: saate Round Robini nginxis juhusliku valiku abil seadistada ja teil on 2% vasakule, 98% paremale. Kuid see pole alati sobiv.

  Näiteks meie puhul suhtleb kasutaja süsteemiga rohkem kui ühe päringuga. See on normaalne: 2, 3, 4, 5 päringut – teie süsteemid võivad olla samad. Ja kui teie jaoks on oluline, et kõik kasutaja päringud jõuaksid samale reale, millelt esimene päring tuli, või (teine ​​punkt) jõuaksid kõik kasutaja päringud pärast vahetust uuele reale (ta oleks võinud alustada tööd varem süsteem, enne lülitit), - siis see juhuslik jaotus teile ei sobi. Siis on järgmised valikud:

  
  
  Esimene, kõige lihtsam variant, põhineb kliendi põhiparameetritel (IP Hash). Teil on IP ja jagate selle IP-aadressiga paremalt vasakule. Siis töötab teie jaoks minu kirjeldatud teine ​​​​juhtum, kui juurutamine toimus, sai kasutaja juba teie süsteemiga tööd alustada ja juurutamise hetkest lähevad kõik päringud uuele reale (näiteks samale).

  Kui see teile mingil põhjusel ei sobi ja peate saatma päringud reale, kust tuli kasutaja esialgne päring, siis on teil kaks võimalust...
  Esimene võimalus: saate osta tasulise nginx+. Seal on kleepuvate seansside mehhanism, mis kasutaja esialgsel nõudmisel määrab kasutajale seansi ja seob selle ühe või teise ülesvooluga. Kõik järgnevad kasutajapäringud seansi jooksul saadetakse samale ülesvoolu, kuhu seanss postitati.

  See meile ei sobinud, sest meil oli juba tavaline nginx. Nginx+-le üleminek ei tähenda, et see oleks kallis, vaid see, et see oli meie jaoks mõnevõrra valus ja mitte väga õige. Näiteks "Sticks Sessions" ei töötanud meie jaoks sel lihtsal põhjusel, et "Sticks Sessions" ei võimalda marsruutimist "Kas-või" alusel. Seal saab määrata, mida me “Sticks Sessions” teeme näiteks IP-aadressi või IP-aadressi ja küpsiste või postparameetri järgi, aga “Kas-või” on seal keerulisem.

  Seetõttu jõudsime neljanda variandini. Võtsime nginxi steroididel (see on openresty) - see on sama nginx, mis toetab lisaks viimaste skriptide kaasamist. Saate kirjutada viimase skripti, anda sellele "avatud puhkeaja" ja see viimane skript käivitatakse, kui kasutaja päring tuleb.

  Ja me kirjutasime tegelikult sellise skripti, seadsime endale "openresti" ja selles skriptis sorteerime 6 erinevat parameetrit konkatenatsiooniga "Or". Olenevalt ühe või teise parameetri olemasolust teame, et kasutaja jõudis ühele või teisele lehele, ühele või teisele reale.

  Sinine/roheline kasutuselevõtt. Eelised ja miinused

  Ilmselt sai seda muidugi veidi lihtsamaks teha (kasutada sedasama “Sticky Sessions”), aga meil on ka selline nüanss, et ühe tehingu ühe töötluse raames ei suhtle meiega ainult kasutaja... Kuid ka maksesüsteemid suhtlevad meiega: pärast tehingu töötlemist (maksesüsteemile päringu saatmisega) saame tagasilöögi.
  Ja oletame, et kui meie vooluringis saame kõigis päringutes edastada kasutaja IP-aadressi ja jagada kasutajaid IP-aadressi järgi, siis me ei ütle sedasama “Visa”: “Kutt, me oleme selline retrofirma, tundub olla rahvusvaheline (veebisaidil ja Venemaal)... Palun andke meile lisaväljale kasutaja IP-aadress, teie protokoll on standardiseeritud”! On selge, et nad ei nõustu.

  
  
  Seetõttu see meie jaoks ei toiminud - tegime avatud mängu. Sellest lähtuvalt saime marsruutimisega midagi sellist:

  Blue/Green Deploymentil on vastavalt minu mainitud eelised ja puudused.

  Kaks puudust:

  • peate marsruutimisega vaeva nägema;
  • teine ​​peamine puudus on kulu.

  Teil on vaja kaks korda rohkem servereid, vajate kaks korda rohkem tööressursse, peate kulutama kaks korda rohkem jõupingutusi kogu selle loomaaia ülalpidamiseks.

  Muide, eeliste hulgas on veel üks asi, mida ma varem pole maininud: teil on reservi koormuse kasvu puhuks. Kui teie koormus kasvab plahvatuslikult, teil on palju kasutajaid, siis lisate lihtsalt teise rea 50–50 distributsiooni – ja teie klastris on kohe x2 serverid, kuni lahendate serverite arvu probleemi.

  Kuidas teha kiiret kasutuselevõttu?

  Rääkisime minimeerimise ja kiire tagasipööramise probleemi lahendamisest, kuid küsimus jääb: "Kuidas kiiresti juurutada?"

  
  
  Siin on see lühike ja lihtne.

  • Teil peab olema CD-süsteem (pidev kohaletoimetamine) – te ei saa ilma selleta elada. Kui teil on üks server, saate seda käsitsi juurutada. Meil on muidugi umbes poolteist tuhat serverit ja poolteist tuhat käepidet – me saame rajada selle ruumi suuruse osakonna lihtsalt kasutuselevõtuks.
  • Kasutuselevõtt peab olema paralleelne. Kui teie juurutamine on järjestikune, on kõik halb. Üks server on normaalne, te juurutate terve päeva poolteist tuhat serverit.
  • Jällegi, kiirendamiseks pole see ilmselt enam vajalik. Kasutuselevõtmise ajal ehitatakse projekt tavaliselt üles. Teil on veebiprojekt, seal on esiotsa osa (teed seal veebipaketi, kompileerid npm - midagi sellist) ja see protsess on põhimõtteliselt lühiajaline - 5 minutit, aga see 5 minutit võib ole kriitiline. Seetõttu me näiteks seda ei tee: eemaldasime need 5 minutit, juurutame artefakte.

    Mis on artefakt? Artefakt on kokkupandud konstruktsioon, mille kõik koosteosad on juba valmis. Talletame selle artefakti artefaktihoidlas. Korraga kasutasime kahte sellist salvestusruumi – see oli Nexus ja nüüd jFrog Artifactory. Algul kasutasime “Nexust”, kuna hakkasime seda lähenemist Java rakendustes harjutama (see sobis hästi). Seejärel panid nad sinna mõned PHP-s kirjutatud rakendused; ja “Nexus” enam ei sobinud ning seetõttu valisime jFrog Artefactory, mis suudab artefitseerida peaaegu kõike. Oleme isegi jõudnud selleni, et sellesse artefaktihoidlasse salvestame oma binaarpakette, mida kogume serverite jaoks.

  Plahvatusliku koormuse kasv

  Rääkisime tarkvaraversiooni muutmisest. Järgmine asi on meil plahvatuslik koormuse suurenemine. Siin pean ma ilmselt silmas plahvatusliku koormuse kasvu all, mis pole päris õige asi...

  Kirjutasime uue süsteemi – see on teeninduskeskne, moekas, ilus, igal pool töötajad, igal pool järjekorrad, kõikjal asünkroonsus. Ja sellistes süsteemides võivad andmed voolata läbi erinevate voogude. Esimese tehingu puhul saab kasutada 1., 3., 10. töötajat, teise tehingu puhul - 2., 4., 5. töötajat. Ja täna, oletame, et hommikul on teil andmevoog, mis kasutab kolme esimest töötajat, ja õhtul muutub see dramaatiliselt ja kõik kasutab ülejäänud kolme töötajat.

  Ja siin selgub, et peate kuidagi skaleerima töötajaid, peate kuidagi oma teenuseid skaleerima, kuid samal ajal vältima ressursside paisumist.

  
  
  Oleme oma nõuded määratlenud. Need nõuded on üsna lihtsad: teenuse avastamine, parameetrite määramine - kõik on selliste skaleeritavate süsteemide ehitamisel standardne, välja arvatud üks punkt - ressursi amortisatsioon. Ütlesime, et me pole valmis ressursse amortiseerima, et serverid õhku soojendaksid. Võtsime "Konsuli", võtsime "Nomad", mis juhib meie töölisi.

  Miks see meile probleemiks on? Lähme natuke tagasi. Nüüd on meil seljataga umbes 70 maksesüsteemi. Hommikul käib liiklus läbi Sberbanki, siis kukkus näiteks Sberbank ja lülitame selle üle teisele maksesüsteemile. Enne Sberbanki oli meil 100 töötajat ja pärast seda peame teise maksesüsteemi jaoks järsult suurendama 100 töötaja arvu. Ja on soovitav, et see kõik toimuks ilma inimese osaluseta. Sest kui on inimeste osalus, siis peaks seal 24/7 istuma insener, kes peaks ainult seda tegema, sest selliseid rikkeid, kui 70 süsteemi on selja taga, tuleb ette regulaarselt.

  Seetõttu vaatasime avatud IP-ga Nomadi ja kirjutasime oma asja, Scale-Nomad - ScaleNo, mis teeb ligikaudu järgmist: jälgib järjekorra kasvu ja vähendab või suurendab töötajate arvu sõltuvalt dünaamikast. järjekorrast. Kui me seda tegime, mõtlesime: "Võib-olla saame selle avatud lähtekoodiga?" Siis vaatasid nad teda – ta oli lihtne kui kaks kopikat.

  Seni pole me seda avatud lähtekoodiga, aga kui järsku peale aruannet, peale aru saamist, et sul on sellist asja vaja, on sul seda vaja, on minu kontaktid viimasel slaidil - palun kirjuta mulle. Kui on vähemalt 3-5 inimest, siis sponsoreerime.

  
  
  Kuidas see töötab? Lähme vaatama! Vaadates tulevikku: vasakul pool on meie seire tükk: see on üks rida, üleval on sündmuste töötlemise aeg, keskel on tehingute arv, all on töötajate arv.

  Kui vaatate, on sellel pildil tõrge. Ülemisel graafikul kukkus üks graafik kokku 45 sekundiga – üks maksesüsteem läks alla. Kohe 2 minutiga toodi liiklus sisse ja järjekord hakkas kasvama teises maksesüsteemis, kus töötajaid polnud (ressursi me ei kasutanud - vastupidi, käsutasime ressursi õigesti). Me ei tahtnud kütta - töötajaid oli minimaalne, umbes 5-10, kuid nad ei saanud hakkama.

  Viimane graafik näitab "küüru", mis tähendab lihtsalt, et "Skaleno" kahekordistas selle koguse. Ja siis, kui graafik veidi langes, vähendas ta seda veidi – töötajate arv muudeti automaatselt. Nii see asi käibki. Rääkisime punktist number 2 - "Kuidas põhjustest kiiresti lahti saada."

  Järelevalve. Kuidas probleemi kiiresti tuvastada?

  Nüüd on esimene punkt "Kuidas probleemi kiiresti tuvastada?" Jälgimine! Peame teatud asjadest kiiresti aru saama. Milliseid asju peaksime kiiresti mõistma?

  
  
  Kolm asja!

  • Peame mõistma ja mõistma kiiresti oma ressursside toimimist.
  • Peame kiiresti mõistma tõrkeid ja jälgima meie väliste süsteemide toimimist.
  • Kolmas punkt on loogikavigade tuvastamine. See on siis, kui süsteem töötab teie jaoks, kõik on kõigi näitajate järgi normaalne, kuid midagi läheb valesti.

  Tõenäoliselt ei räägi ma teile siin midagi nii lahedat. Minust saab Captain Obvious. Otsisime, mis turul oli. Meil on "lõbus loomaaed". Selline loomaaed on meil praegu:

  
  
  Kasutame Zabbixi riistvara jälgimiseks, serverite põhinäitajate jälgimiseks. Andmebaaside jaoks kasutame Okmeterit. Kõigi muude näitajate jaoks, mis ei sobi kahe esimesega, kasutame "Grafana" ja "Prometheus", mõned "Grafana" ja "Prometheus" ning mõned "Grafana" koos "Influx" ja Telegrafiga.

  Aasta tagasi tahtsime kasutada New Relic. Lahe asi, sellega saab kõike. Aga nii palju kui ta kõike teha suudab, on ta nii kallis. Kui meie maht kasvas 1,5 tuhande serverini, tuli meie juurde müüja ja ütles: "Sõlmime järgmiseks aastaks lepingu." Vaatasime hinda ja ütlesime, et ei, me ei tee seda. Nüüd loobume New Relicist, meil on jäänud umbes 15 serverit New Relic jälgimise alla. Hind osutus täiesti metsikuks.

  Ja on üks tööriist, mille me ise juurutasime - see on silur. Alguses nimetasime seda "Baggeriks", kuid siis möödus inglise keele õpetaja, naeris metsikult ja nimetas selle ümber "Debagger". Mis see on? See on tööriist, mis tegelikult testib iga komponendi puhul 15-30 sekundiga, nagu süsteemi "must kast", komponendi üldist jõudlust.

  Näiteks kui on olemas väline leht (makseleht), siis ta lihtsalt avab selle ja vaatab, kuidas see välja peaks nägema. Kui see on töötlemisel, saadab ta testtehingu ja veendub, et see "tehing" saabub. Kui see on seos maksesüsteemidega, käivitame vastavalt võimalusel testpäringu ja vaatame, et meiega on kõik korras.

  Millised näitajad on monitooringu jaoks olulised?

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

  
  

  • Reageerimisaeg / RPS rindel on väga oluline näitaja. Ta vastab kohe, et sinuga on midagi valesti.
  • Töödeldud kirjade arv kõigis järjekordades.
  • Tööliste arv.
  • Põhilised korrektsuse mõõdikud.

  Viimane punkt on "äri", "äri" mõõdik. Kui soovite sama asja jälgida, peate määratlema ühe või kaks mõõdikut, mis on teie jaoks peamised näitajad. Meie mõõdik on läbilaskevõime (see on edukate tehingute arvu ja tehingute koguvoo suhe). Kui selles midagi muutub intervalliga 5-10-15 minutit, tähendab see, et meil on probleeme (kui see muutub radikaalselt).

  Kuidas see meie jaoks välja näeb, on näide ühest meie tahvlitest:

  
  
  Vasakul pool on 6 graafikut, see on ridade järgi - töötajate arv ja järjekordades olevate sõnumite arv. Paremal pool – RPS, RTS. Allpool on sama "äri" mõõdik. Ja “äri” mõõdikus on kohe näha, et kahel keskmisel graafikul läks midagi valesti... See on lihtsalt järjekordne süsteem, mis seisab meie selja taga ja on kukkunud.

  Teise asjana tuli jälgida välismaksete süsteemide kukkumist. Siin võtsime ette OpenTracingu – mehhanismi, standardse paradigma, mis võimaldab jälgida hajutatud süsteeme; ja seda muudeti veidi. Standardne OpenTracingu paradigma ütleb, et loome jälje iga üksiku päringu jaoks. Meil ei olnud seda vaja ja panime selle kokkuvõtlikuks, koondamisjäljeks. Tegime tööriista, mis võimaldab jälgida meie taga olevate süsteemide kiirust.

  
  
  Graafik näitab, et üks maksesüsteemidest hakkas reageerima 3 sekundiga – meil on probleeme. Veelgi enam, see asi reageerib probleemide ilmnemisel 20-30-sekundilise intervalliga.

  Ja kolmas olemasolevate seirevigade klass on loogiline jälgimine.

  Ausalt öeldes ei teadnud ma, mida sellele slaidile joonistada, sest olime juba pikka aega turult otsinud midagi, mis meile sobiks. Midagi me ei leidnud, seega pidime ise tegema.

  
  
  Mida ma mõtlen loogilise jälgimise all? Kujutage ette: teete endale süsteemi (näiteks Tinderi klooni); sa tegid seda, käivitasid selle. Edukas mänedžer Vasja Pupkin pani selle oma telefonile, näeb seal tüdrukut, talle meeldib... ja sarnane ei lähe tüdrukule - meeldiv läheb sama ärikeskuse turvamehele Mihhalõtšile. Juhataja läheb alla ja imestab siis: "Miks see turvamees Mihhalitš talle nii meeldivalt naeratab?"

  Sellistes olukordades... Meie jaoks kõlab see olukord veidi teistmoodi, sest (ma kirjutasin) see on mainekaotus, mis toob kaudselt kaasa rahalisi kaotusi. Meie olukord on vastupidine: võime kanda otsest rahalist kahju – näiteks kui tegime tehingu edukalt, kuid see oli ebaõnnestunud (või vastupidi). Pidin kirjutama oma tööriista, mis jälgib ärinäitajate abil edukate tehingute arvu aja jooksul. Ei leidnud turult midagi! Just seda mõtet tahtsin edasi anda. Turul pole midagi sellist probleemi lahendamiseks.

  See puudutas probleemi kiiret tuvastamist.

  Kuidas teha kindlaks kasutuselevõtu põhjused

  Kolmas probleemide rühm, mida lahendame, on pärast seda, kui oleme probleemi tuvastanud, pärast seda, kui oleme sellest lahti saanud, oleks hea mõista arenduse, testimise põhjust ja sellega midagi ette võtta. Vastavalt sellele peame uurima, peame palke tõstma.

  
  
  Kui me räägime palkidest (peamine põhjus on palgid), siis suurem osa meie palgist on ELK Stackis - peaaegu kõigil on sama. Mõne jaoks ei pruugi see ELK-s olla, aga kui logid kirjutada gigabaitides, siis varem või hiljem jõuad ELK-sse. Kirjutame need terabaitides.

  
  
  Siin on probleem. Parandasime ära, parandasime kasutaja jaoks vea, hakkasime seal leiduvat välja kaevama, ronisime Kibanasse, sisestasime sinna tehingu ID ja saime sellise jalalapi (näitab palju). Ja selles jalalapis pole absoluutselt midagi selge. Miks? Jah, sest pole selge, milline osa kuulub millisele töötajale, milline osa millisele komponendile. Ja sel hetkel mõistsime, et vajame jälgimist – sedasama OpenTracingut, millest ma rääkisin.

  Mõtlesime seda aasta tagasi, pöörasime pilgu turu poole ja seal oli kaks tööriista - “Zipkin” ja “Jaeger”. “Jager” on tegelikult selline ideoloogiline pärija, “Zipkini” ideoloogiline järglane. Zipkinis on kõik hästi, välja arvatud see, et ta ei tea, kuidas koondada, ta ei tea, kuidas logida jälgi, ainult ajajälgi. Ja "Jager" toetas seda.

  Vaatasime “Jagerit”: saab rakendusi instrumenteerida, saab kirjutada Apis (sel ajal PHP-i API-standardit siiski heaks ei kiidetud - see oli aasta tagasi, aga nüüd on see juba kinnitatud), aga seal polnud absoluutselt klient. "Olgu," mõtlesime ja kirjutasime oma kliendile. Mida me saime? Umbes nii see välja näeb:

  
  
  Jäägeris luuakse iga sõnumi jaoks vahemikud. See tähendab, et kui kasutaja süsteemi avab, näeb ta iga sissetuleva päringu kohta ühte või kahte plokki (1-2-3 - kasutajalt sissetulevate päringute arv, plokkide arv). Kasutajate jaoks lihtsamaks muutmiseks lisasime logidele ja ajajälgedele sildid. Vastavalt sellele märgib meie rakendus tõrke korral logi vastava veasildiga. Saate filtreerida veasildi järgi ja kuvatakse ainult need ulatused, mis sisaldavad seda veaga plokki. See näeb välja selline, kui laiendame ulatust:

  
  
  Ava sees on hulk jälgi. Sel juhul on tegemist kolme testjäljega ja kolmas jälg ütleb meile, et ilmnes viga. Samas näeme siin aja jälge: meil on ülaosas ajaskaala ja me näeme, millise ajaintervalliga see või teine ​​logi salvestati.

  Sellest lähtuvalt läks meil hästi. Kirjutasime oma laienduse ja kasutasime seda avatud lähtekoodiga. Kui soovite töötada jälgimisega, kui soovite töötada PHP-s "Jageriga", on olemas meie laiendus, tere tulemast kasutama, nagu öeldakse:

  
  
  Meil on see laiendus - see on OpenTracing Api klient, see on tehtud php-laiendusena, see tähendab, et peate selle kokku panema ja süsteemi installima. Aasta tagasi polnud midagi teistmoodi. Nüüd on teisi kliente, kes on nagu komponendid. Siin on see teie otsustada: kas pumpate komponendid välja koos heliloojaga või kasutate laiendust.

  Ettevõtte standardid

  Rääkisime kolmest käsust. Neljas käsk on lähenemiste ühtlustamine. Millest see jutt käib? Jutt on sellest:

  
  
  Miks on siin sõna "ettevõte"? Mitte sellepärast, et oleme suur või bürokraatlik ettevõte, ei! Tahtsin siin kasutada sõna “korporatiiv” kontekstis, et igal ettevõttel, igal tootel peaksid olema oma standardid, ka sinul. Millised standardid meil on?

  
  

  • Meil on kasutuselevõtueeskirjad. Me ei liigu ilma temata kuhugi, me ei saa. Me kasutame umbes 60 korda nädalas, see tähendab peaaegu pidevalt. Samas on meil näiteks kasutuselevõtumäärustes tabu reedeste lähetuste kohta – põhimõtteliselt me ​​ei lähe.
  • Nõuame dokumentatsiooni. Ükski uus komponent ei jõua tootmisse, kui selle kohta pole dokumentatsiooni, isegi kui see on sündinud meie RnD spetsialistide sule all. Nõuame neilt juurutamisjuhiseid, seirekaarti ja ligikaudset kirjeldust (nagu programmeerijad oskavad kirjutada), kuidas see komponent töötab ja kuidas seda tõrkeotsingut teha.
  • Me ei lahenda mitte probleemi põhjust, vaid probleemi – mida ma juba ütlesin. Meie jaoks on oluline kaitsta kasutajat probleemide eest.
  • Meil on luba. Näiteks ei pea me seisakuks seda, kui kaotasime kahe minuti jooksul 2% liiklusest. Seda meie statistikas põhimõtteliselt ei arvestata. Kui see on rohkem protsentides või ajutine, siis me juba arvestame.
  • Ja me kirjutame alati postmortem. Mis meiega ka ei juhtuks, iga olukord, kus keegi lavastuses ebanormaalselt käitus, kajastub surmajärgses teoses. Surmajärgne dokument on dokument, kuhu kirjutate, mis teiega juhtus, üksikasjaliku ajastuse, selle, mida te selle parandamiseks tegite ja (see on kohustuslik blokk!), mida teete, et seda tulevikus vältida. See on kohustuslik ja vajalik järgnevaks analüüsiks.

  Mida loetakse seisakuteks?

  
  
  Milleni see kõik viis?

  See tõi kaasa asjaolu, et (meil oli teatud probleeme stabiilsusega, see ei sobinud ei klientidele ega meile) viimase 6 kuu jooksul oli meie stabiilsusnäitaja 99,97. Võime öelda, et seda pole kuigi palju. Jah, meil on, mille poole püüelda. Sellest näitajast umbes poole moodustab justkui mitte meie, vaid meie ees seisva ja teenusena kasutatava veebirakenduse tulemüüri stabiilsus, kuid kliente see ei huvita.

  Õppisime öösel magama. Lõpuks ometi! Kuus kuud tagasi me ei saanud. Ja selle tulemuste kohta tahaksin teha ühe märkuse. Eile õhtul oli suurepärane aruanne tuumareaktori juhtimissüsteemi kohta. Kui inimesed, kes selle süsteemi kirjutasid, kuulevad mind, unustage see, mida ma ütlesin teemal "2% ei ole seisakuaeg". Teie jaoks on 2% seisakuaeg, isegi kui kaks minutit!

  See on kõik! Teie küsimused.

  
  

  Tasakaalurite ja andmebaaside migratsiooni kohta

  Küsimus publikult (edaspidi – B): – Tere õhtust. Suur tänu sellise administraatori aruande eest! Lühike küsimus teie tasakaalustajate kohta. Mainisid, et sul on WAF ehk nagu ma aru saan, kasutad mingit välist tasakaalustajat...

  EK: – Ei, me kasutame oma teenuseid tasakaalustajana. Antud juhul on WAF meie jaoks eranditult DDoS-i kaitsetööriist.

  Sisse: – Kas saate öelda paar sõna tasakaalustajate kohta?

  EK: – Nagu ma juba ütlesin, on see avatud režiimis serverite rühm. Meil on nüüd 5 reservrühma, mis vastavad eranditult... see tähendab server, mis töötab eranditult openrestyga, vaid puhverserverit. Sellest lähtuvalt, et mõista, kui palju meil on: meil on nüüd regulaarne liiklusvoog, mis on mitusada megabitti. Nad tulevad toime, tunnevad end hästi, isegi ei pinguta ennast.

  Sisse: – Samuti lihtne küsimus. Siin on sinine/roheline kasutuselevõtt. Mida teete näiteks andmebaaside migreerimisega?

  EK: - Hea küsimus! Vaata, sinise/rohelise juurutamise korral on meil iga rea ​​jaoks eraldi järjekorrad. See tähendab, et kui me räägime sündmuste järjekordadest, mis edastatakse töötajalt töötajale, on sinise ja rohelise joone jaoks eraldi järjekorrad. Kui me räägime andmebaasist endast, siis me kitsendasime seda teadlikult nii palju kui saime, tõstsime kõik praktiliselt järjekordadesse, andmebaasis salvestame ainult tehingute virna. Ja meie tehingute virn on kõigil ridadel sama. Andmebaasiga selles kontekstis: me ei jaga seda siniseks ja roheliseks, sest mõlemad koodi versioonid peavad teadma, mis tehinguga toimub.

  Sõbrad, mul on teile julgustuseks ka väike auhind – raamat. Ja ma peaksin selle auhinna saama parima küsimuse eest.

  Sisse: - Tere. Täname raporti eest. Küsimus on selles. Jälgid makseid, jälgid teenuseid, millega suhtled... Aga kuidas sa jälgid, et inimene tuli kuidagi sinu makselehele, tegi makse ja projekt krediteeris talle raha? See tähendab, kuidas jälgite, et müüja on saadaval ja on teie tagasihelistamise vastu võtnud?

  EK: – “Kaupmees” on meie jaoks antud juhul täpselt samasugune välisteenus, mis maksesüsteem. Jälgime kaupmehe reageerimiskiirust.

  Andmebaasi krüptimise kohta

  Sisse: - Tere. Mul on veidi seotud küsimus. Teil on tundlikud PCI DSS-andmed. Tahtsin teada, kuidas salvestate PAN-e järjekordadesse, kuhu peate üle kandma? Kas kasutate mingit krüptimist? Ja see viib teise küsimuseni: PCI DSS-i järgi on muudatuste korral (administraatorite vallandamine jne) vaja andmebaasi perioodiliselt uuesti krüpteerida - mis saab sel juhul ligipääsetavusega?

  
  
  EK: - Imeline küsimus! Esiteks, me ei salvesta PAN-e järjekordadesse. Meil ei ole põhimõtteliselt õigust PAN-i kuskil selgel kujul salvestada, seega kasutame eriteenust (nimetame seda "Kademoniks") - see on teenus, mis teeb ainult üht: võtab sisendina vastu sõnumi ja saadab krüpteeritud sõnumi välja saatma. Ja me salvestame kõik selle krüpteeritud sõnumiga. Sellest lähtuvalt on meie võtme pikkus alla kilobaidi, nii et see on tõsine ja usaldusväärne.

  Sisse: – Kas teil on nüüd vaja 2 kilobaiti?

  EK: – Tundub, et just eile oli 256... No kus siis veel?!

  Sellest lähtuvalt on see esimene. Ja teiseks, olemasolev lahendus toetab uuesti krüpteerimisprotseduuri - seal on kaks paari "keksi" (võtmeid), mis annavad "tekid", mis krüpteerivad (võti on võtmed, dek on krüpteerivate võtmete tuletised) . Ja kui protseduur käivitatakse (see juhtub regulaarselt, 3 kuud kuni ± mõni), laadime alla uue paari "kooke" ja krüpteerime andmed uuesti. Meil on eraldi teenused, mis rebivad välja kõik andmed ja krüpteerivad need uuel viisil; Andmed salvestatakse selle võtme identifikaatori kõrvale, millega need krüpteeritakse. Seetõttu kustutame niipea, kui krüpteerime andmed uute võtmetega, vana võtme.

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

  Sisse: – See tähendab, et kui mõne toimingu eest on saabunud tagasimakse, kas dekrüpteerite selle ikkagi vana võtmega?

  EK: - Jah.

  Sisse: – Siis veel üks väike küsimus. Kui juhtub mingisugune rike, kukkumine või vahejuhtum, tuleb tehing käsitsi läbi suruda. Selline olukord on.

  EK: - Jah, mõnikord.

  Sisse: – Kust te need andmed võtate? Või lähete ise sellesse hoidlasse?

  EK: – Ei, muidugi, meil on mingisugune back-office süsteem, mis sisaldab meie toe liidest. Kui me ei tea, mis olekus tehing on (näiteks seni, kuni maksesüsteem vastas ajalõpuga), ei tea me seda ka a priori, st määrame lõpliku oleku ainult täie kindlustundega. Sel juhul määrame tehingu käsitsi töötlemiseks eriolekusse. Hommikul, järgmisel päeval, niipea kui tugiteenus saab teavet, et sellised ja sellised tehingud jäävad maksesüsteemi, töötlevad nad neid selles liideses käsitsi.

  
  
  Sisse: – Mul on paar küsimust. Üks neist on PCI DSS-i tsooni jätkamine: kuidas nende vooluringi logida? See küsimus tuleneb sellest, et arendaja oleks võinud logidesse panna mida iganes! Teine küsimus: kuidas käigultparandusi juurutada? Andmebaasi käepidemete kasutamine on üks võimalus, kuid võib olla tasuta kiirparandusi – milline on seal protseduur? Ja kolmas küsimus on ilmselt seotud RTO, RPO-ga. Teie saadavus oli 99,97, peaaegu neli üheksat, aga nagu ma aru saan, on teil teine ​​andmekeskus, kolmas andmekeskus ja viies andmekeskus... Kuidas neid sünkroonida, kopeerida ja kõike muud?

  EK: - Alustame esimesest. Kas esimene küsimus oli palkide kohta? Logide kirjutamisel on meil kiht, mis maskeerib kõik tundlikud andmed. Ta vaatab maski ja lisavälju. Sellest lähtuvalt tulevad meie logid välja juba maskeeritud andmete ja PCI DSS-ahelaga. See on üks tavapärastest testimisosakonnale pandud ülesannetest. Nad peavad kontrollima iga ülesannet, sealhulgas nende poolt kirjutatud logisid, ja see on üks tavalisi ülesandeid koodide ülevaatamise ajal, et kontrollida, kas arendaja ei kirjutanud midagi üles. Selle hilisemaid kontrolle teeb infoturbe osakond regulaarselt umbes kord nädalas: võetakse valikuliselt viimase päeva logid ja need lastakse testserveritest läbi spetsiaalse skanner-analüsaatori, et kõike kontrollida.
  Kuumparanduste kohta. See sisaldub meie kasutuselevõtu eeskirjades. Meil on kiirparanduste kohta eraldi klausel. Usume, et juurutame kiirparandusi ööpäevaringselt, kui seda vajame. Niipea kui versioon on kokku pandud, niipea, kui see on käivitatud, niipea kui meil on artefakt, on meil tugiteenuse kõne alusel valves süsteemiadministraator, kes võtab selle kasutusele hetkel, kui see on vajalik.

  Umbes "neli üheksa". Praegune näitaja on tõesti saavutatud ja me püüdlesime selle poole teises andmekeskuses. Nüüd on meil teine ​​andmekeskus ja me hakkame nende vahel marsruutima ning andmekeskuseülese replikatsiooni küsimus on tõesti mittetriviaalne küsimus. Proovisime seda korraga lahendada erinevate vahenditega: proovisime kasutada sama "Tarantulat" - see ei tulnud meile välja, ma ütlen teile kohe. Seetõttu tellisimegi "sensid" käsitsi. Tegelikult käitab iga meie süsteemi rakendus vajalikku andmekeskuste vahelist sünkroonimist „muudatus tehtud” asünkroonselt.

  Sisse: – Kui saite teise, siis miks te ei saanud kolmandat? Sest kellelgi pole veel aju lõhki...

  EK: – Aga meil pole lõhestatud aju. Kuna iga rakendust juhib multimaster, ei ole meie jaoks oluline, millisesse keskusesse päring tuli. Oleme valmis selleks, et kui üks meie andmekeskustest ebaõnnestub (oleme sellele tuginenud) ja keset kasutaja päringut lülitub teisele andmekeskusele, oleme valmis selle kasutaja tõepoolest kaotama; kuid need on ühikud, absoluutsed ühikud.

  Sisse: - Tere õhtust. Täname raporti eest. Rääkisite oma silurist, mis käivitab mõned testtehingud tootmises. Aga rääkige meile testtehingutest! Kui sügavale see läheb?

  EK: – See läbib kogu komponendi täistsükli. Komponendi puhul pole testtehingu ja tootmistehingu vahel vahet. Aga loogilisest vaatenurgast on see lihtsalt süsteemis eraldi projekt, mille peal jooksevad ainult testtehingud.

  Sisse: - Kust sa selle ära lõikad? Siin Core saatis...

  EK: – Oleme testtehingute puhul antud juhul “Kori” taga... Meil ​​on selline asi nagu marsruutimine: “Kor” teab, millisesse maksesüsteemi saata – saadame võltsmaksesüsteemi, mis annab lihtsalt http signaali ja see on kõik.

  Sisse: – Ütle mulle, palun, kas teie taotlus oli kirjutatud ühte tohutusse monoliiti või lõigasite selle mõneks teenuseks või isegi mikroteenusteks?

  EK: – Meil ​​pole loomulikult monoliiti, meil on teenusele orienteeritud rakendus. Teeme nalja, et meie teenus on valmistatud monoliitidest - need on tõesti üsna suured. Seda on raske nimetada mikroteenusteks, kuid need on teenused, mille raames töötavad hajutatud masinate töötajad.

  Kui teenus serveris on ohus...

  Sisse: – Siis on mul järgmine küsimus. Isegi kui see oleks monoliit, ütlesite ikkagi, et teil on palju selliseid kiirservereid, need töötlevad põhimõtteliselt andmeid ja küsimus on järgmine: "Ühe kiirserveri või rakenduse ohu korral võib iga üksik link , kas neil on mingisugune juurdepääsukontroll? Kumb neist saab mida teha? Kelle poole peaksin pöörduma mis teabe saamiseks?

  
  
  EK: - Jah, kindlasti. Turvanõuded on üsna tõsised. Esiteks on meil avatud andmete liikumine ja pordid on ainult need, mille kaudu me liikluse liikumist ette näeme. Kui komponent suhtleb andmebaasiga (ütleme Muskuliga) 5-4-3-2 kaudu, on talle avatud ainult 5-4-3-2 ja muud sadamad ja muud liiklussuunad pole saadaval. Lisaks peate mõistma, et meie tootmises on umbes 10 erinevat turvasilmust. Ja isegi kui rakendus oleks kuidagi ohustatud, jumal hoidku, ei pääse ründaja serveri halduskonsoolile, sest see on erinev võrgu turvatsoon.

  Sisse: – Ja selles kontekstis on minu jaoks huvitavam see, et teil on teenustega teatud lepingud – mida nad saavad teha, milliste “toimingute” kaudu saavad nad omavahel ühendust võtta... Ja tavalises voolus nõuavad mõned konkreetsed teenused mõnda rida, teiselt poolt "toimingute" loend. Tundub, et nad ei pöördu tavaolukorras teiste poole ja neil on muud vastutusvaldkonnad. Kui üks neist on ohustatud, kas see võib häirida selle teenuse "toiminguid"?

  EK: - Ma saan aru. Kui tavaolukorras teise serveriga suhtlemine üldse lubatud oli, siis jah. Vastavalt SLA lepingule ei jälgi me, et teil on lubatud ainult 3 esimest "toimingut" ja 4 "toimingut" ei ole lubatud. See on meie jaoks ilmselt üleliigne, sest meil on juba põhimõtteliselt vooluahelate jaoks 4-astmeline kaitsesüsteem. Eelistame end kaitsta kontuuridega, mitte sisemuse tasandil.

  Kuidas Visa, MasterCard ja Sberbank töötavad

  Sisse: – Soovin selgitada üht kasutaja vahetamist ühest andmekeskusest teise. Minu teada töötavad Visa ja MasterCard binaarse sünkroonprotokolli 8583 abil ja seal on segud. Ja ma tahtsin teada, et nüüd mõtleme vahetamist – kas see on otse “Visa” ja “MasterCard” või enne maksesüsteeme, enne töötlemist?

  EK: - See on enne segusid. Meie segud asuvad samas andmekeskuses.

  Sisse: – Jämedalt öeldes, kas teil on üks ühenduspunkt?

  EK: – “Visa” ja “MasterCard” – jah. Lihtsalt sellepärast, et Visa ja MasterCard nõuavad päris tõsiseid investeeringuid infrastruktuuri, et sõlmida eraldi lepingud näiteks teise segupaari saamiseks. Need on reserveeritud ühe andmekeskuse piires, aga kui jumal hoidku, meie andmekeskus, kus on Visa ja MasterCardiga ühendamiseks segud, ära sureb, siis kaob ühendus Visa ja MasterCardiga...

  Sisse: – Kuidas saab neid reserveerida? Tean, et Visa lubab põhimõtteliselt ainult ühte ühendust!

  EK: – Nad tarnivad seadmed ise. Igal juhul saime varustuse, mis on sees täiesti üleliigne.

  Sisse: – Nii et alus on nende Connects Orange’ilt?

  EK: - Jah.

  Sisse: – Aga kuidas on selle juhtumiga: kui teie andmekeskus kaob, kuidas saate seda edasi kasutada? Või jääb liiklus lihtsalt seisma?

  EK: - Ei. Sel juhul suuname lihtsalt liikluse teisele kanalile, mis on loomulikult meile kallim ja klientidele kallim. Kuid liiklus ei toimu meie otseühenduse kaudu Visa, MasterCardiga, vaid tingimusliku Sberbanki kaudu (väga liialdatud).

  Vabandan meeletult, kui solvasin Sberbanki töötajaid. Kuid meie statistika kohaselt langeb Venemaa pankade seas Sberbank kõige sagedamini. Ei möödu kuudki, kui Sberbankis midagi maha ei kukuks.

  
  
  

  

  Mõned reklaamid 🙂

  Täname, et jäite meiega. Kas teile meeldivad meie artiklid? Kas soovite näha huvitavamat sisu? Toeta meid, esitades tellimuse või soovitades sõpradele, pilve VPS arendajatele alates 4.99 dollarist, algtaseme serverite ainulaadne analoog, mille me teie jaoks leiutasime: Kogu tõde VPS (KVM) E5-2697 v3 (6 tuuma) 10GB DDR4 480GB SSD 1Gbps kohta alates 19 dollarist või kuidas serverit jagada? (saadaval RAID1 ja RAID10, kuni 24 tuuma ja kuni 40 GB DDR4-ga).

  Dell R730xd 2x odavam Amsterdami Equinixi Tier IV andmekeskuses? Ainult siin 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6 GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 telerit alates 199 dollarist Hollandis! Dell R420 – 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB – alates 99 dollarist! Millegi kohta lugema Kuidas ehitada infrastruktuuri ettevõtet. klassis koos Dell R730xd E5-2650 v4 serverite kasutusega 9000 eurot senti?

Allikas: www.habr.com