„HighLoad++“, Jevgenijus Kuzovlevas („EcommPay IT“): ką daryti, kai prastovos minutė kainuoja 100000 XNUMX USD

Visi kalba apie kūrimo ir testavimo procesus, darbuotojų mokymą, motyvacijos didinimą, tačiau šių procesų neužtenka, kai minutė paslaugos prastovos kainuoja milžiniškus pinigus. Ką daryti, kai finansines operacijas atliekate pagal griežtą SLA? Kaip padidinti savo sistemų patikimumą ir atsparumą gedimams, išimant kūrimą ir testavimą iš lygties?

Kita HighLoad++ konferencija vyks 6 metų balandžio 7 ir 2020 dienomis Sankt Peterburge. Išsami informacija ir bilietai nuoroda. Lapkričio 9 d., 18:00 val. HighLoad++ Maskva 2018, Delis + Kolkatos salė. Tezės ir pristatymas.

Jevgenijus Kuzovlevas (toliau – EK): - Draugai, sveiki! Mano vardas Kuzovlevas Jevgenijus. Esu iš EcommPay įmonės, konkretus padalinys yra EcommPay IT, įmonių grupės IT padalinys. O šiandien kalbėsime apie prastovas – apie tai, kaip jų išvengti, kaip sumažinti jų pasekmes, jei to nepavyks išvengti. Tema nurodoma taip: „Ką daryti, kai prastovos minutė kainuoja 100 000 USD“? Žvelgiant į ateitį, mūsų skaičiai yra palyginami.

Ką veikia EcommPay IT?

Kas mes esame? Kodėl aš stoviu čia priešais tave? Kodėl aš turiu teisę tau čia ką nors pasakyti? O apie ką čia plačiau kalbėsime?

„EcommPay“ įmonių grupė yra tarptautinis pirkėjas. Mokėjimus apdorojame visame pasaulyje – Rusijoje, Europoje, Pietryčių Azijoje (All Around the World). Turime 9 biurus, iš viso dirba 500 darbuotojų, iš kurių maždaug kiek mažiau nei pusė yra IT specialistai. Viską, ką darome, iš ko užsidirbame, padarėme patys.

Visus savo produktus (o jų turime gana daug – mūsų didelių IT produktų linijoje turime apie 16 skirtingų komponentų) rašėme patys; Patys rašome, patys tobulėjame. Ir šiuo metu per dieną atliekame apie milijoną operacijų (milijonai tikriausiai yra teisingas būdas). Esame gana jauna įmonė – mums tik apie šešeri metai.

Prieš 6 metus tai buvo toks startuolis, kai vaikinai atėjo kartu su verslu. Juos sujungė idėja (nebuvo nieko kito, tik idėja), ir mes bėgome. Kaip ir kiekvienas startuolis, bėgome greičiau... Mums greitis buvo svarbiau už kokybę.

Kažkuriuo momentu sustojome: supratome, kad nebegalime kažkaip gyventi tokiu greičiu ir su ta kokybe ir pirmiausia reikia susikoncentruoti į kokybę. Šiuo metu nusprendėme sukurti naują platformą, kuri būtų teisinga, keičiamo dydžio ir patikima. Jie pradėjo rašyti šią platformą (pradėjo investuoti, kurti kūrimą, testavimą), bet kažkuriuo metu suprato, kad kūrimas ir testavimas neleidžia pasiekti naujo paslaugų kokybės lygio.

Pagaminsi naują gaminį, dedi į gamybą, bet vis tiek kažkas kažkur suges. O šiandien kalbėsime apie tai, kaip pasiekti naują kokybės lygį (kaip mes tai padarėme, apie savo patirtį), išimant kūrimą ir testavimą iš lygties; kalbėsime apie tai, kas yra prieinama eksploatacijai – kokia operacija gali pasidaryti pati, ką ji gali pasiūlyti testavimui, kad paveiktų kokybę.

Prastovos. Veikimo įsakymai.

Visada pagrindinis kertinis akmuo, apie ką šiandien kalbėsime, yra prastovos. Siaubingas žodis. Jei turime prastovų, viskas mums blogai. Bėgame kelti, adminai laiko serverį - neduok Dieve, kad nenukristų, kaip toje dainoje sakoma. Apie tai šiandien ir kalbėsime.

Kai pradėjome keisti savo požiūrį, suformavome 4 įsakymus. Aš juos pateikiau skaidrėse:

Šie įsakymai yra gana paprasti:

• Greitai nustatykite problemą.
• Atsikratykite jo dar greičiau.
• Padėkite suprasti priežastį (vėliau kūrėjams).
• Ir standartizuoti metodus.

Noriu atkreipti jūsų dėmesį į tašką Nr.2. Mes atsikratome problemos, o ne ją sprendžiame. Sprendimas yra antraeilis dalykas. Mums svarbiausia, kad vartotojas būtų apsaugotas nuo šios problemos. Ji egzistuos kažkokioje izoliuotoje aplinkoje, bet ši aplinka su ja neturės jokio kontakto. Tiesą sakant, mes apžvelgsime šias keturias problemų grupes (vienas išsamiau, kai kurias mažiau), papasakosiu, ką naudojame, kokią aktualią patirtį turime sprendžiant.

Trikčių šalinimas: kada jie atsiranda ir ką su jomis daryti?

Bet pradėsime ne iš eilės, pradėsime nuo punkto Nr.2 – kaip greitai atsikratyti problemos? Iškilo problema – turime ją išspręsti. "Ką turėtume daryti su tuo?" - pagrindinis klausimas. Ir kai pradėjome galvoti, kaip išspręsti problemą, sukūrėme keletą reikalavimų, kurių turi būti laikomasi atliekant trikčių šalinimą.

Norėdami suformuluoti šiuos reikalavimus, nusprendėme užduoti sau klausimą: „Kada turime problemų“? Ir, kaip paaiškėjo, problemos kyla keturiais atvejais:

• Aparatinės įrangos gedimas.
• Išorinės paslaugos nepavyko.
• Programinės įrangos versijos keitimas (tas pats diegimas).
• Sprogios apkrovos augimas.

Apie pirmuosius du nekalbėsime. Techninės įrangos gedimas gali būti išspręstas gana paprastai: viskas turi būti dubliuota. Jei tai diskai, diskai turi būti surinkti RAID; jei tai serveris, serveris turi būti dubliuotas; jei turite tinklo infrastruktūrą, turite pateikti antrą tinklo infrastruktūros kopiją, ty paimkite ją ir dubliuoti jį. Ir jei kas nors nepavyksta, perjungiate į rezervinę galią. Čia sunku ką nors daugiau pasakyti.

Antrasis – išorinių paslaugų gedimas. Daugumai sistema visai ne problema, bet ne mums. Kadangi apdorojame mokėjimus, esame agregatorius, kuris stovi tarp vartotojo (kuris įveda savo kortelės duomenis) ir bankų, mokėjimo sistemų (Visa, MasterCard, Mira ir kt.). Mūsų išorinės paslaugos (mokėjimo sistemos, bankai) dažniausiai žlunga. Nei mes, nei jūs (jei turite tokias paslaugas) negalime tam įtakos.

Ką tada daryti? Čia yra du variantai. Pirma, jei galite, turėtumėte kaip nors dubliuoti šią paslaugą. Pavyzdžiui, jei galime, srautą perkeliame iš vienos paslaugos į kitą: pavyzdžiui, kortelės buvo tvarkomos per „Sberbank“, „Sberbank“ turi problemų – srautą [sąlygiškai] perkeliame į „Raiffeisen“. Antras dalykas, kurį galime padaryti, tai labai greitai pastebėti išorinių paslaugų gedimą, todėl apie reagavimo greitį kalbėsime kitoje ataskaitos dalyje.

Tiesą sakant, iš šių keturių galime konkrečiai paveikti programinės įrangos versijų keitimą – imtis veiksmų, kurie padėtų pagerinti situaciją diegimo ir spartaus apkrovos augimo kontekste. Tiesą sakant, tai mes padarėme. Vėlgi, maža pastaba...

Iš šių keturių problemų kelios iš karto išsprendžiamos, jei turite debesį. Jei esate „Microsoft Azhur“, „Ozone“ debesyse arba naudojate mūsų debesis iš „Yandex“ ar „Mail“, tada bent jau aparatinės įrangos gedimas tampa jų problema ir viskas iš karto susitvarko, kai atsiranda aparatinės įrangos gedimas.

Esame šiek tiek netradicinė įmonė. Čia visi kalba apie „Kubernets“, apie debesis - mes neturime nei „Kubernets“, nei debesų. Tačiau daugelyje duomenų centrų turime aparatūros lentynas ir esame priversti gyventi iš šios aparatinės įrangos, esame priversti už visa tai atsakyti. Todėl kalbėsime šiame kontekste. Taigi, apie problemas. Pirmieji du buvo išimti iš skliaustų.

Programinės įrangos versijos keitimas. Bazės

Mūsų kūrėjai neturi prieigos prie gamybos. Kodėl taip? Tiesiog mes turime PCI DSS sertifikatą, o mūsų kūrėjai tiesiog neturi teisės patekti į „produktą“. Tai tiek, taškas. Iš viso. Todėl atsakomybė už kūrimą baigiasi būtent tuo momentu, kai plėtra pateikia versiją išleisti.

Antrasis mūsų turimas pagrindas, kuris mums taip pat labai padeda, yra unikalių nedokumentuotų žinių nebuvimas. Tikiuosi, kad jums taip pat. Nes jei taip nėra, turėsite problemų. Problemų kils tada, kai šios unikalios, dokumentais nepatvirtintos žinios nebus pateiktos tinkamu laiku tinkamoje vietoje. Tarkime, kad turite vieną žmogų, kuris žino, kaip įdiegti konkretų komponentą – žmogaus nėra, jis atostogauja arba serga – štai ir jūs turite problemų.

Ir trečiasis pagrindas, prie kurio priėjome. Priėjome per skausmą, kraują, ašaras – priėjome išvados, kad bet kuriame mūsų statyme yra klaidų, net jei jis be klaidų. Tai nusprendėme patys: kai ką nors diegiame, kai ką nors paleidžiame į gamybą, turime kūrimą su klaidomis. Suformavome reikalavimus, kuriuos turi atitikti mūsų sistema.

Programinės įrangos versijos keitimo reikalavimai

Yra trys reikalavimai:

• Turime greitai atšaukti dislokavimą.
• Turime kuo labiau sumažinti nesėkmingo diegimo poveikį.
• Ir mes turime sugebėti greitai dislokuoti lygiagrečiai.
  Būtent tokia tvarka! Kodėl? Nes, visų pirma, diegiant naują versiją, greitis nėra svarbus, bet jums svarbu, jei kas nors negerai, greitai atsukti atgal ir turėti minimalų poveikį. Bet jei turite gamyboje esančių versijų rinkinį, dėl kurio paaiškėja, kad įvyko klaida (nebuvo įdiegta, bet yra klaida), jums svarbus tolesnio diegimo greitis. Ką padarėme, kad patenkintume šiuos reikalavimus? Mes ėmėmės šios metodikos:

  
  
  Tai gana gerai žinoma, mes niekada jo nesugalvojome – tai yra Blue/Green dislokavimas. Kas tai yra? Turite turėti kiekvienos serverių grupės, kurioje įdiegtos jūsų programos, kopiją. Kopija yra „šilta“: joje nėra srauto, tačiau bet kuriuo metu šis srautas gali būti siunčiamas į šią kopiją. Šioje kopijoje yra ankstesnė versija. Diegimo metu kodą išleidžiate į neaktyvią kopiją. Tada dalį srauto (arba visą) perjungiate į naują versiją. Taigi, norint pakeisti transporto srautą iš senosios versijos į naują, reikia atlikti tik vieną veiksmą: reikia pakeisti balansyrą prieš srovę, pakeisti kryptį – iš vienos prieš srovę į kitą. Tai labai patogu ir išsprendžia greito perjungimo ir greito grąžinimo problemą.

  Čia antrojo klausimo sprendimas yra minimizavimas: galite siųsti tik dalį srauto į naują eilutę, į eilutę su nauju kodu (tebūnie, pavyzdžiui, 2%). Ir šie 2% nėra 100%! Jei praradote 100% srauto dėl nesėkmingo diegimo, tai baisu; jei praradote 2% srauto, tai nemalonu, bet tai nėra baisu. Be to, vartotojai to greičiausiai net nepastebės, nes kai kuriais atvejais (ne visais) tas pats vartotojas, paspaudęs F5, bus perkeltas į kitą, veikiančią versiją.

  Mėlyna/žalia dislokacija. Maršrutas

  Tačiau ne viskas taip paprasta „Blue/Green deploy“... Visus mūsų komponentus galima suskirstyti į tris grupes:

  • tai frontend (mokėjimo puslapiai, kuriuos mato mūsų klientai);
  • apdorojimo šerdis;
  • adapteris darbui su mokėjimo sistemomis (bankai, MasterCard, Visa...).

  Ir čia yra niuansas – niuansas slypi maršrute tarp eilučių. Jei tiesiog pakeisite 100 % srauto, tokių problemų neturėsite. Bet jei norite pakeisti 2%, pradedate klausinėti: „Kaip tai padaryti? Paprasčiausias dalykas yra tiesiai į priekį: „nginx“ galite nustatyti „Round Robin“ atsitiktiniu pasirinkimu, o jūs turite 2% kairėje, 98% dešinėje. Tačiau tai ne visada tinka.

  Pavyzdžiui, mūsų atveju vartotojas sąveikauja su sistema pateikdamas daugiau nei vieną užklausą. Tai normalu: 2, 3, 4, 5 užklausos – jūsų sistemos gali būti tokios pačios. Ir jei jums svarbu, kad visos vartotojo užklausos patektų į tą pačią eilutę, kurioje buvo pateikta pirmoji užklausa, arba (antrasis taškas) visos vartotojo užklausos patektų į naują eilutę po perjungimo (jis galėjo pradėti dirbti anksčiau su sistema, prieš perjungimą), – tada šis atsitiktinis paskirstymas jums netinka. Tada yra šios parinktys:

  
  
  Pirmasis variantas, pats paprasčiausias, pagrįstas pagrindiniais kliento parametrais (IP Hash). Turite IP ir padalijate jį iš dešinės į kairę pagal IP adresą. Tada jums tiks antrasis mano aprašytas atvejis, kai įvyko diegimas, vartotojas jau galėjo pradėti dirbti su jūsų sistema, o nuo diegimo momento visos užklausos pateks į naują eilutę (tarkime, į tą pačią).

  Jei dėl kokių nors priežasčių tai jums netinka ir turite siųsti užklausas į eilutę, kurioje atėjo vartotojo pradinė, pradinė užklausa, turite dvi parinktis...
  Pirmas variantas: galite nusipirkti mokamą nginx+. Egzistuoja „Sticky sessions“ mechanizmas, kuris vartotojui pradiniu prašymu priskiria vartotojui seansą ir susieja jį su vienu ar kitu prieš srovę. Visos vėlesnės naudotojų užklausos per seansą bus siunčiamos į tą patį srautą, kuriame buvo paskelbta sesija.

  Tai mums netiko, nes jau turėjome įprastą nginx. Perėjimas prie nginx+ nėra tai, kad tai brangu, tiesiog tai mums buvo šiek tiek skausminga ir nelabai teisinga. Pavyzdžiui, „Sticks Sessions“ mums neveikė dėl paprastos priežasties, nes „Sticks Sessions“ neleidžia nukreipti pagal „arba-arba“. Čia galite nurodyti, ką darome „Sticks Sessions“, pavyzdžiui, pagal IP adresą arba pagal IP adresą ir slapukus arba pagal postparametrą, tačiau „arba-arba“ ten yra sudėtingiau.

  Todėl priėjome prie ketvirto varianto. Mes vartojome nginx su steroidais (tai yra openresty) - tai tas pats nginx, kuris papildomai palaiko paskutinių scenarijų įtraukimą. Galite parašyti paskutinį scenarijų, suteikti jam „atvirą poilsį“, o šis paskutinis scenarijus bus vykdomas, kai ateis vartotojo užklausa.

  Tiesą sakant, mes parašėme tokį scenarijų, nustatėme „openresti“ ir šiame scenarijuje mes rūšiuojame 6 skirtingus parametrus sujungdami „Arba“. Priklausomai nuo vieno ar kito parametro buvimo, žinome, kad vartotojas atėjo į vieną ar kitą puslapį, vieną ar kitą eilutę.

  Mėlyna/žalia dislokacija. Privalumai ir trūkumai

  Žinoma, tikriausiai buvo galima tai padaryti šiek tiek paprasčiau (naudokite tuos pačius „Sticky Sessions“), bet turime ir tokį niuansą, kad ne tik vartotojas su mumis bendrauja vienos operacijos apdorojimo rėmuose... Tačiau mokėjimo sistemos taip pat sąveikauja su mumis: kai apdorojame operaciją (išsiunčiant užklausą mokėjimo sistemai), gauname atsipalaidavimą.
  Ir tarkime, jei savo grandinėje galime persiųsti vartotojo IP adresą visose užklausose ir skirstyti vartotojus pagal IP adresą, tai to paties „Visa“ nepasakysime: „Bičiuli, mes tokia retro kompanija, atrodo būti tarptautiniu (svetainėje ir Rusijoje)... Papildomame laukelyje pateikite vartotojo IP adresą, jūsų protokolas yra standartizuotas“! Aišku, kad jie nesutiks.

  
  
  Todėl mums tai nepasiteisino – padarėme atvirą darbą. Atitinkamai, su maršrutizavimu gavome kažką panašaus į tai:

  „Blue/Green Deployment“ turi atitinkamai minėtų privalumų ir trūkumų.

  Du trūkumai:

  • reikia vargti su maršrutizavimu;
  • antras pagrindinis trūkumas yra išlaidos.

  Jums reikia dvigubai daugiau serverių, jums reikia dvigubai daugiau veiklos išteklių, jums reikia išleisti dvigubai daugiau pastangų, kad išlaikytumėte visą šį zoologijos sodą.

  Beje, tarp privalumų yra dar vienas dalykas, kurio anksčiau nepaminėjau: turite rezervą apkrovos augimo atveju. Jei jūsų apkrova sparčiai auga, turite daug vartotojų, tada tiesiog įtraukite antrą eilutę į 50–50 paskirstymą – ir jūs iš karto turėsite x2 serverius savo klasteryje, kol išspręsite daugiau serverių problemą.

  Kaip greitai įdiegti?

  Kalbėjome apie tai, kaip išspręsti sumažinimo ir greito grąžinimo problemą, tačiau lieka klausimas: „Kaip greitai įdiegti?

  
  
  Čia trumpai ir paprastai.

  • Turite turėti kompaktinių diskų sistemą (nuolatinis pristatymas) – be jos negalite gyventi. Jei turite vieną serverį, galite įdiegti rankiniu būdu. Žinoma, turime apie pusantro tūkstančio serverių ir pusantro tūkstančio rankenėlių – galime pasodinti tokio dydžio padalinį, kaip šis kambarys, kad tik išsisklaidytų.
  • Diegimas turi būti lygiagretus. Jei jūsų diegimas yra nuoseklus, tada viskas yra blogai. Vienas serveris yra normalus, visą dieną dislokuosite pusantro tūkstančio serverių.
  • Vėlgi, norint pagreitinti, tai tikriausiai nebereikalinga. Diegimo metu projektas paprastai statomas. Turite žiniatinklio projektą, yra priekinė dalis (ten darote žiniatinklio paketą, sukompiliuojate npm - kažkas panašaus), ir šis procesas iš principo yra trumpalaikis - 5 minutes, bet šios 5 minutės gali būk kritiškas. Štai kodėl, pavyzdžiui, mes to nedarome: pašalinome šias 5 minutes, įdiegiame artefaktus.

    Kas yra artefaktas? Artefaktas – tai surinkta konstrukcija, kurioje visos surinkimo dalys jau baigtos. Šį artefaktą saugome artefaktų saugykloje. Vienu metu naudojome dvi tokias saugyklas – tai buvo „Nexus“, o dabar „jFrog Artifactory“. Iš pradžių naudojome „Nexus“, nes pradėjome praktikuoti šį metodą „Java“ programose (jis gerai tiko). Tada jie įdėjo kai kurias programas, parašytas PHP; ir „Nexus“ nebetinka, todėl pasirinkome jFrog Artefactory, kuri gali artifakuoti beveik viską. Netgi priėjome prie to, kad šioje artefaktų saugykloje saugome savo dvejetainius paketus, kuriuos renkame serveriams.

  Sprogios apkrovos augimas

  Kalbėjomės apie programinės įrangos versijos keitimą. Kitas dalykas, kurį turime, yra sprogus apkrovos padidėjimas. Čia turbūt turiu omenyje sprogstamąjį apkrovos augimą, ne visai teisingą dalyką...

  Parašėme naują sistemą – ji orientuota į paslaugas, madinga, graži, visur darbininkai, visur eilės, visur asinchroniškumas. Ir tokiose sistemose duomenys gali tekėti skirtingais srautais. Pirmajam sandoriui gali būti naudojamas 1, 3, 10 darbuotojas, antrajam sandoriui - 2, 4, 5. Ir šiandien, tarkime, ryte turite duomenų srautą, kuris naudoja pirmuosius tris darbuotojus, o vakare jis kardinaliai pasikeičia, ir viskas naudoja kitus tris darbuotojus.

  Ir čia paaiškėja, kad reikia kažkaip išplėsti darbuotojus, kažkaip išplėsti savo paslaugas, bet tuo pačiu užkirsti kelią resursų išpūtimui.

  
  
  Mes apibrėžėme savo reikalavimus. Šie reikalavimai gana paprasti: kad būtų Service Discovery, parametrizavimas – viskas yra standartinė kuriant tokias keičiamo dydžio sistemas, išskyrus vieną tašką – resursų nusidėvėjimą. Sakėme, kad nesame pasiruošę amortizuoti resursų, kad serveriai šildytų orą. Paėmėme „Konsulą“, pasiėmėme „Nomadą“, kuris valdo mūsų darbininkus.

  Kodėl tai mums yra problema? Truputį atsitraukime. Dabar turime apie 70 mokėjimo sistemų. Ryte eismas vyksta per „Sberbank“, tada, pavyzdžiui, „Sberbank“ krito, ir mes jį perjungiame į kitą mokėjimo sistemą. Prieš „Sberbank“ turėjome 100 darbuotojų, o po to turime smarkiai padidinti 100 darbuotojų kitai mokėjimo sistemai. Ir norima, kad visa tai vyktų be žmogaus dalyvavimo. Nes jei dalyvauja žmogus, 24 valandas per parą turi sėdėti inžinierius, kuris turėtų tik tai daryti, nes tokie gedimai, kai už nugaros stovi 7 sistemų, pasitaiko reguliariai.

  Todėl pažiūrėjome į Nomad, kuris turi atvirą IP, ir parašėme savo Scale-Nomad - ScaleNo, kuris daro maždaug taip: stebi eilės augimą ir sumažina arba padidina darbuotojų skaičių, priklausomai nuo dinamikos. iš eilės. Kai tai padarėme, pagalvojome: „Gal galime tai atviro kodo? Tada jie pažiūrėjo į ją – ji buvo paprasta kaip dvi kapeikos.

  Kol kas nesame atviro kodo, bet jei staiga po pranešimo, supratus, kad tau reikia tokio dalyko, tau jo reikia, mano kontaktai yra paskutinėje skaidrėje - parašyk man. Jei susirinks bent 3-5 žmonės, mes jį paremsime.

  
  
  Kaip tai veikia? Pažiūrėkime! Žvelgiant į priekį: kairėje pusėje yra mūsų stebėjimo dalis: tai yra viena eilutė, viršuje yra įvykių apdorojimo laikas, viduryje - operacijų skaičius, apačioje - darbuotojų skaičius.

  Jei pažvelgsite, šioje nuotraukoje yra gedimas. Viršutinėje diagramoje viena iš diagramų sudužo per 45 sekundes – viena mokėjimo sistemų nukrito. Iš karto per 2 minutes buvo atvežtas srautas ir eilė pradėjo augti kitoje mokėjimo sistemoje, kurioje nebuvo darbuotojų (neišnaudojome resursų - priešingai, tinkamai disponavome ištekliais). Mes nenorėjome šildyti - buvo minimalus skaičius, apie 5-10 darbuotojų, bet jie negalėjo susidoroti.

  Paskutinėje diagramoje pavaizduota „kupra“, o tai tiesiog reiškia, kad „Skaleno“ padvigubino šią sumą. Ir tada, kai grafikas šiek tiek sumažėjo, jis jį šiek tiek sumažino – darbuotojų skaičius buvo pakeistas automatiškai. Štai kaip šis dalykas veikia. Mes kalbėjome apie 2 punktą - „Kaip greitai atsikratyti priežasčių“.

  Stebėjimas. Kaip greitai nustatyti problemą?

  Dabar pirmas dalykas yra „Kaip greitai nustatyti problemą? Stebėjimas! Tam tikrus dalykus turime suprasti greitai. Kokius dalykus turėtume greitai suprasti?

  
  
  Trys dalykai!

  • Turime greitai suprasti ir suprasti savo išteklių efektyvumą.
  • Turime greitai suprasti gedimus ir stebėti mūsų išorės sistemų veikimą.
  • Trečias dalykas yra loginių klaidų nustatymas. Tai yra tada, kai sistema veikia už jus, viskas normalu pagal visus rodiklius, bet kažkas negerai.

  Tikriausiai nieko tokio šaunaus čia nepasakysiu. Aš būsiu kapitonas Akivaizdus. Ieškojome, kas buvo rinkoje. Turime „linksmą zoologijos sodą“. Štai tokį zoologijos sodą dabar turime:

  
  
  Mes naudojame Zabbix techninei įrangai stebėti, pagrindiniams serverių rodikliams stebėti. Duomenų bazėms naudojame Okmeter. Visiems kitiems rodikliams, kurie neatitinka pirmųjų dviejų, naudojame „Grafana“ ir „Prometheus“, kai kurie su „Grafana“ ir „Prometheus“, o kiti su „Grafana“ su „Influx“ ir „Telegraf“.

  Prieš metus norėjome naudoti New Relic. Puiku, ji gali viską. Bet kiek ji gali viską padaryti, tiek ji brangi. Kai išaugome iki 1,5 tūkst. serverių, pas mus atėjo pardavėjas ir pasakė: „Sudarykim sutartį kitiems metams“. Pažiūrėjome į kainą ir pasakėme, kad ne, to nedarysime. Dabar mes atsisakome New Relic, turime apie 15 serverių, kuriuos stebi New Relic. Kaina pasirodė visiškai laukinė.

  Ir yra vienas įrankis, kurį įdiegėme patys – tai Debugger. Iš pradžių pavadinome jį „Bagger“, bet paskui praėjo anglų kalbos mokytojas, pašėlusiai nusijuokė ir pervadino „Debagger“. Kas tai yra? Tai įrankis, kuris iš tikrųjų per 15–30 sekundžių kiekvienam komponentui, kaip sistemos „juodoji dėžė“, atlieka bendro komponento veikimo testus.

  Pavyzdžiui, jei yra išorinis puslapis (mokėjimo puslapis), jis tiesiog jį atidaro ir žiūri, kaip jis turėtų atrodyti. Jei tai apdorojama, jis siunčia bandomąją „operaciją“ ir užtikrina, kad ši „operacija“ būtų atlikta. Jei tai yra ryšys su mokėjimo sistemomis, atitinkamai paleidžiame bandomąją užklausą, kur galime, ir pamatome, kad su mumis viskas gerai.

  Kokie rodikliai yra svarbūs stebėjimui?

  Ką mes daugiausia stebime? Kokie rodikliai mums svarbūs?

  
  

  • Reagavimo laikas / RPS frontuose yra labai svarbus rodiklis. Jis iškart atsako, kad tau kažkas negerai.
  • Apdorotų pranešimų skaičius visose eilėse.
  • Darbuotojų skaičius.
  • Pagrindinės teisingumo metrikos.

  Paskutinis taškas yra „verslas“, „verslo“ metrika. Jei norite stebėti tą patį, turite apibrėžti vieną ar dvi metrikas, kurios yra pagrindiniai jūsų rodikliai. Mūsų metrika yra pralaidumas (tai yra sėkmingų operacijų skaičiaus ir bendro operacijų srauto santykis). Jei kas nors jame pasikeičia 5-10-15 minučių intervalu, vadinasi, turime problemų (jei pasikeičia kardinaliai).

  Kaip mums atrodo, yra vienos iš mūsų lentų pavyzdys:

  
  
  Kairėje pusėje yra 6 grafikai, tai yra pagal eilutes - darbuotojų skaičius ir pranešimų skaičius eilėse. Dešinėje pusėje – RPS, RTS. Žemiau yra ta pati „verslo“ metrika. O „verslo“ metrikoje iš karto matome, kad dviejuose viduriniuose grafikuose kažkas ne taip... Tai tik dar viena už mūsų stovinti sistema, kuri nukrito.

  Antras dalykas, kurį turėjome padaryti, buvo stebėti išorinių mokėjimo sistemų kritimą. Čia paėmėme OpenTracing – mechanizmą, standartą, paradigmą, leidžiančią atsekti paskirstytas sistemas; ir jis buvo šiek tiek pakeistas. Standartinė OpenTracing paradigma sako, kad sukuriame kiekvienos individualios užklausos pėdsaką. Mums to nereikėjo, o mes suvyniojome į santrauką, agregavimo pėdsaką. Sukūrėme įrankį, leidžiantį sekti už mūsų esančių sistemų greitį.

  
  
  Grafikas rodo, kad viena iš mokėjimo sistemų pradėjo reaguoti per 3 sekundes – turime problemų. Be to, šis dalykas reaguos, kai prasidės problemos, 20–30 sekundžių intervalu.

  Ir trečioji egzistuojančių stebėjimo klaidų klasė yra loginis stebėjimas.

  Tiesą sakant, aš nežinojau, ką piešti ant šios skaidrės, nes ilgai ieškojome rinkoje to, kas mums tiktų. Nieko neradome, tad teko daryti patiems.

  
  
  Ką turiu omenyje sakydamas loginis stebėjimas? Na, įsivaizduokite: sukuriate sau sistemą (pavyzdžiui, „Tinder“ kloną); tu tai padarei, paleidai. Sėkmingas vadybininkas Vasya Pupkin įdėjo jį į savo telefoną, pamato ten merginą, jai patinka... o panašus merginai nekeliauja - panašus atitenka apsaugos darbuotojui Michalyčiui iš to paties verslo centro. Vadovas nusileidžia laiptais ir stebisi: „Kodėl šis apsaugininkas Michalyčius taip maloniai jam šypsosi?

  Tokiose situacijose... Mums ši situacija skamba kiek kitaip, nes (rašiau) tai reputacijos praradimas, kuris netiesiogiai sukelia finansinius nuostolius. Mūsų situacija yra priešinga: galime patirti tiesioginių finansinių nuostolių – pavyzdžiui, jei sandorį atlikome kaip sėkmingą, bet jis buvo nesėkmingas (arba atvirkščiai). Turėjau parašyti savo įrankį, kuris seka sėkmingų operacijų skaičių laikui bėgant, naudodamas verslo rodiklius. Rinkoje nieko neradau! Būtent tokią mintį ir norėjau perteikti. Rinkoje nėra nieko, kas galėtų išspręsti tokią problemą.

  Tai buvo apie tai, kaip greitai nustatyti problemą.

  Kaip nustatyti dislokavimo priežastis

  Trečioji problemų grupė, kurią sprendžiame, yra identifikavus problemą, atsikračius jos, būtų gerai suprasti plėtros, išbandymo priežastį ir ką nors padaryti. Atitinkamai reikia tirti, rąstus pakelti.

  
  
  Jei mes kalbame apie rąstus (pagrindinė priežastis yra rąstai), didžioji dalis mūsų rąstų yra ELK Stack - beveik visi turi tą patį. Kai kam gal ir ne ELK, bet jei žurnalus rašai gigabaitais, tai anksčiau ar vėliau ateisi į ELK. Jas rašome terabaitais.

  
  
  Čia yra problema. Ištaisėme, vartotojui ištaisėme klaidą, pradėjome kasinėti, kas ten yra, įlipome į Kibaną, ten įvedėme operacijos ID ir gavome tokią pėdutę (daug rodo). Ir šioje kojytėje visiškai niekas neaišku. Kodėl? Taip, nes neaišku, kuri dalis priklauso kuriam darbuotojui, kuri dalis priklauso kuriam komponentui. Ir tą akimirką supratome, kad mums reikia sekimo – to paties OpenTracing, apie kurį kalbėjau.

  Tai pagalvojome prieš metus, nukreipėme dėmesį į rinką ir ten buvo du įrankiai - „Zipkin“ ir „Jaeger“. „Jageris“ iš tikrųjų yra toks ideologinis įpėdinis, ideologinis „Zipkino“ įpėdinis. Zipkine viskas gerai, išskyrus tai, kad jis nemoka agreguoti, nemoka įtraukti rąstų į pėdsaką, tik laiko pėdsaką. Ir „Jager“ tai palaikė.

  Pažiūrėjome į „Jager“: galite naudoti programas, galite rašyti „Api“ (tačiau tuo metu PHP Api standartas nebuvo patvirtintas - tai buvo prieš metus, bet dabar jis jau patvirtintas), bet ten nebuvo visiškai joks klientas. „Gerai“, – pagalvojome ir parašėme savo klientui. Ką mes gavome? Maždaug taip atrodo:

  
  
  „Jaeger“ kiekvienam pranešimui sukuriami intervalai. Tai yra, kai vartotojas atidaro sistemą, jis mato vieną ar du blokus kiekvienai gaunamai užklausai (1-2-3 - gaunamų vartotojo užklausų skaičius, blokų skaičius). Kad vartotojams būtų lengviau, prie žurnalų ir laiko pėdsakų pridėjome žymų. Atitinkamai, įvykus klaidai, mūsų programa pažymės žurnalą atitinkama Error žyma. Galite filtruoti pagal klaidos žymą ir bus rodomi tik tarpai, kuriuose yra šis blokas su klaida. Taip atrodo, jei išplėsime diapazoną:

  
  
  Viduje yra pėdsakų rinkinys. Šiuo atveju tai yra trys bandymo pėdsakai, o trečiasis rodo, kad įvyko klaida. Tuo pačiu čia matome laiko pėdsaką: viršuje turime laiko skalę ir matome, kokiu laiko intervalu buvo įrašytas tas ar kitas žurnalas.

  Atitinkamai, mums viskas klostėsi gerai. Parašėme savo plėtinį ir sukūrėme jį atvirojo kodo. Jei norite dirbti su sekimu, jei norite dirbti su „Jager“ PHP, yra mūsų plėtinys, kviečiame naudoti, kaip sakoma:

  
  
  Mes turime šį plėtinį – tai OpenTracing Api klientas, jis pagamintas kaip php plėtinys, tai yra, jums reikės jį surinkti ir įdiegti sistemoje. Prieš metus nieko kito nebuvo. Dabar yra kitų klientų, kurie yra tarsi komponentai. Tai priklauso nuo jūsų: arba išpumpuosite komponentus naudodami kompozitorių, arba naudosite plėtinį.

  Įmonių standartai

  Mes kalbėjome apie tris įsakymus. Ketvirtasis įsakymas – standartizuoti požiūrius. Apie ką tai? Tai apie tai:

  
  
  Kodėl čia yra žodis „įmonė“? Ne todėl, kad esame didelė ar biurokratinė įmonė, ne! Čia norėjau vartoti žodį „įmonė“ kontekste, kad kiekviena įmonė, kiekvienas produktas turi turėti savo standartus, įskaitant ir jus. Kokius standartus turime?

  
  

  • Turime dislokavimo taisykles. Mes be jo niekur nejudame, negalime. Mes dislokuojame apie 60 kartų per savaitę, tai yra beveik nuolat. Tuo pačiu metu, pavyzdžiui, dislokavimo taisyklėse yra nustatytas tabu dėl dislokavimo penktadienį – iš esmės mes nedislokuojame.
  • Reikalaujame dokumentų. Nei vienas naujas komponentas nepatenka į gamybą, jei nėra jo dokumentacijos, net jei jis gimė po mūsų RnD specialistų plunksna. Iš jų reikalaujame diegimo instrukcijų, stebėjimo žemėlapio ir apytikslio aprašymo (na, kaip gali parašyti programuotojai), kaip šis komponentas veikia, kaip jį pašalinti.
  • Mes sprendžiame ne problemos priežastį, o problemą – ką jau sakiau. Mums svarbu apsaugoti vartotoją nuo problemų.
  • Turime leidimus. Pavyzdžiui, mes nelaikome prastovos, jei per dvi minutes praradome 2 % srauto. Tai iš esmės nėra įtraukta į mūsų statistiką. Jei tai daugiau procentais ar laikina, mes jau skaičiuojame.
  • Ir mes visada rašome postmortems. Kad ir kas mums nutiktų, bet kokia situacija, kai kas nors gamyboje pasielgė neįprastai, atsispindės pomirtinėje. Postmortem yra dokumentas, kuriame rašote, kas jums nutiko, detalų laiką, ką padarėte, kad tai ištaisytumėte ir (tai yra privalomas blokas!), ką darysite, kad taip nenutiktų ateityje. Tai yra privaloma ir būtina tolesnei analizei.

  Kas laikoma prastovomis?

  
  
  Prie ko visa tai privedė?

  Tai lėmė tai, kad (turėjome tam tikrų stabilumo problemų, tai netiko nei klientams, nei mums) per pastaruosius 6 mėnesius mūsų stabilumo rodiklis buvo 99,97. Galime pasakyti, kad tai nėra labai daug. Taip, turime ko siekti. Iš šio rodiklio maždaug pusę sudaro ne mūsų, o mūsų žiniatinklio programų ugniasienės, kuri stovi prieš mus ir naudojama kaip paslauga, stabilumas, tačiau klientams tai nerūpi.

  Išmokome miegoti naktimis. Pagaliau! Prieš šešis mėnesius negalėjome. Ir šioje pastaboje su rezultatais norėčiau padaryti vieną pastabą. Praėjusią naktį buvo nuostabus pranešimas apie branduolinio reaktoriaus valdymo sistemą. Jei žmonės, kurie parašė šią sistemą, mane girdi, pamirškite tai, ką sakiau apie „2% nėra prastovos“. Jums 2% yra prastovos, net jei dvi minutes!

  Tai viskas! Jūsų klausimai.

  
  

  Apie balansuotojus ir duomenų bazių perkėlimą

  Klausimas iš publikos (toliau – B): – Labas vakaras. Labai ačiū už tokį administratoriaus pranešimą! Trumpas klausimas apie jūsų balansuotojus. Minėjai, kad turi WAF, tai, kaip suprantu, naudoji kažkokį išorinį balansuotoją...

  EK: – Ne, mes naudojame savo paslaugas kaip balansuotoją. Šiuo atveju WAF yra išskirtinai mums skirta DDoS apsaugos priemonė.

  In: – Ar galite pasakyti keletą žodžių apie balansuotojus?

  EK: – Kaip jau sakiau, tai yra atvirojo režimo serverių grupė. Dabar turime 5 rezervines grupes, kurios atsako išskirtinai... tai yra serveris, kuris veikia tik openresty, tik perduoda srautą. Atitinkamai, norėdami suprasti, kiek turime: dabar turime reguliarų kelių šimtų megabitų srautą. Jie susitvarko, jaučiasi gerai, net neįsitempia.

  In: – Taip pat paprastas klausimas. Čia yra mėlynos / žalios spalvos diegimas. Ką darote, pavyzdžiui, su duomenų bazių perkėlimu?

  EK: - Geras klausimas! Pažiūrėkite, mėlynos/žalios spalvos diegimo metu kiekvienai eilutei yra atskiros eilės. Tai yra, jei kalbame apie įvykių eiles, kurios perduodamos iš darbuotojo darbuotojui, yra atskiros mėlynos ir žalios linijos eilės. Jei kalbame apie pačią duomenų bazę, tai sąmoningai ją susiaurinome, kiek galėjome, praktiškai viską perkėlėme į eiles, duomenų bazėje saugome tik krūvą operacijų. Ir mūsų operacijų krūva yra vienoda visoms eilutėms. Su duomenų baze šiame kontekste: neskirstome jos į mėlyną ir žalią, nes abi kodo versijos turi žinoti, kas vyksta su operacija.

  Draugai, aš taip pat turiu nedidelį prizą, kad paskatinčiau jus – knygą. Ir aš turėčiau būti apdovanotas už geriausią klausimą.

  In: - Sveiki. Ačiū už pranešimą. Klausimas toks. Stebi mokėjimus, stebi paslaugas, su kuriomis bendrauji... Bet kaip stebėti, kad žmogus kažkaip atėjo į tavo mokėjimo puslapį, sumokėjo, o projektas jam įskaitė pinigus? Tai yra, kaip stebite, ar prekybininkas yra pasiekiamas ir priėmė jūsų atgalinį skambutį?

  EK: – „Prekybininkas“ mums šiuo atveju yra lygiai tokia pati išorinė paslauga, kaip ir mokėjimo sistema. Stebime prekybininko reakcijos greitį.

  Apie duomenų bazės šifravimą

  In: - Sveiki. Turiu šiek tiek susijusį klausimą. Turite neskelbtinų PCI DSS duomenų. Norėjau sužinoti, kaip saugoti PAN eilėse, į kurias reikia perkelti? Ar naudojate kokį nors šifravimą? Ir tai veda prie antrojo klausimo: pagal PCI DSS būtina periodiškai iš naujo šifruoti duomenų bazę pasikeitus (atleidžiant administratorius ir pan.) – kas tokiu atveju atsitiks su pasiekiamumu?

  
  
  EK: - Nuostabus klausimas! Pirma, mes nesaugome PAN eilėse. Mes neturime teisės niekur saugoti PAN aiškia forma, todėl naudojame specialią paslaugą (vadiname ją „Kademon“) – tai paslauga, kuri atlieka tik vieną dalyką: gauna pranešimą kaip įvestį ir išsiunčia išsiųsti užšifruotą pranešimą. Ir mes saugome viską su šiuo užšifruotu pranešimu. Atitinkamai, mūsų rakto ilgis yra mažesnis nei kilobaitas, todėl tai yra rimta ir patikima.

  In: – Ar tau dabar reikia 2 kilobaitų?

  EK: – Atrodo, dar vakar buvo 256... Na, kur dar?!

  Atitinkamai, tai yra pirmasis. Antra, egzistuojantis sprendimas, jis palaiko pakartotinio šifravimo procedūrą - yra dvi poros „keks“ (raktų), kurios suteikia „denius“, kurie šifruoja (raktas yra raktai, dek yra šifruojančių raktų išvestiniai). . O jei procedūra pradedama (tai vyksta reguliariai, nuo 3 mėnesių iki ± kai kurių), atsisiunčiame naują „tortų“ porą ir iš naujo užšifruojame duomenis. Turime atskiras paslaugas, kurios išplėšia visus duomenis ir užšifruoja juos nauju būdu; Duomenys saugomi šalia rakto, kuriuo jie užšifruoti, identifikatoriaus. Atitinkamai, kai tik užšifruojame duomenis naujais raktais, senąjį raktą ištriname.

  Kartais mokėjimus reikia atlikti rankiniu būdu...

  In: – Tai yra, jei už kokią nors operaciją atėjo pinigų grąžinimas, ar vis tiek ją iššifruosite senu raktu?

  EK: – Taip.

  In: – Tada dar vienas mažas klausimas. Kai įvyksta koks nors gedimas, kritimas ar incidentas, operaciją reikia atlikti rankiniu būdu. Yra tokia situacija.

  EK: - Taip kartais.

  In: – Iš kur jūs gaunate šiuos duomenis? O gal pats važiuojate į šią saugyklą?

  EK: – Ne, na, žinoma, turime kažkokią „back-office“ sistemą, kurioje yra mūsų palaikymo sąsaja. Jei nežinome, kokioje būsenoje yra operacija (pavyzdžiui, kol mokėjimo sistema neatsakė su laiku), nežinome a priori, tai yra, galutinę būseną priskiriame tik visiškai pasitikėdami. Tokiu atveju operacijai priskiriame specialią būseną, kad būtų galima apdoroti rankiniu būdu. Ryte, kitą dieną, kai tik palaikymo tarnyba gauna informaciją, kad tokios ir tokios operacijos lieka mokėjimo sistemoje, jos rankiniu būdu apdoroja jas šioje sąsajoje.

  
  
  In: – Turiu porą klausimų. Vienas iš jų yra PCI DSS zonos tęsinys: kaip užregistruoti jų grandinę? Šis klausimas kyla todėl, kad kūrėjas galėjo įrašyti bet ką į žurnalus! Antras klausimas: kaip įdiegti karštąsias pataisas? Naudoti rankenas duomenų bazėje yra viena iš galimybių, tačiau gali būti nemokamų karštųjų pataisų – kokia ten procedūra? Ir trečias klausimas tikriausiai susijęs su RTO, RPO. Jūsų pasiekiamumas buvo 99,97, beveik keturi devyneri, bet, kaip suprantu, turite antrą duomenų centrą, trečią duomenų centrą ir penktą duomenų centrą... Kaip juos sinchronizuoti, atkartoti ir visa kita?

  EK: – Pradėkime nuo pirmos. Ar pirmasis klausimas buvo apie rąstus? Kai rašome žurnalus, turime sluoksnį, kuris užmaskuoja visus jautrius duomenis. Ji žiūri į kaukę ir į papildomus laukus. Atitinkamai, mūsų žurnalai išeina su jau užmaskuotais duomenimis ir PCI DSS grandine. Tai viena iš įprastų testavimo skyriui priskiriamų užduočių. Jie privalo patikrinti kiekvieną užduotį, įskaitant įrašomus žurnalus, ir tai yra viena iš įprastų užduočių kodo peržiūros metu, kad būtų galima kontroliuoti, ar kūrėjas kažko neužrašė. Vėlesnius patikrinimus informacijos saugos skyrius atlieka reguliariai, maždaug kartą per savaitę: pasirinktinai paimami paskutinės dienos žurnalai ir jie per specialų skaitytuvą-analizatorių iš bandomųjų serverių paleidžiami viskam patikrinti.
  Apie karštąsias pataisas. Tai įtraukta į mūsų diegimo taisykles. Turime atskirą punktą apie karštąsias pataisas. Manome, kad karštąsias pataisas diegiame visą parą, kai to reikia. Kai tik versija yra surinkta, kai tik ji paleidžiama, kai tik turime artefaktą, turime budintį sistemos administratorių pagal iškvietimą iš palaikymo komandos, kuris ją įdiegia tada, kai reikia.

  Apie „keturis devynis“. Dabartinis skaičius tikrai pasiektas, ir mes to siekėme kitame duomenų centre. Dabar turime antrą duomenų centrą ir pradedame maršrutą tarp jų, o kryžminio duomenų centrų replikavimo klausimas yra tikrai nereikšmingas. Vienu metu bandėme tai išspręsti naudodami skirtingas priemones: bandėme naudoti tą patį „Tarantulą“ - mums tai nepasiteisino, aš jums tuoj pat pasakysiu. Štai kodėl „sens“ užsisakėme rankiniu būdu. Tiesą sakant, kiekviena mūsų sistemos programa asinchroniškai vykdo būtiną „pakeitimų – atlikta“ sinchronizavimą tarp duomenų centrų.

  In: – Jei gavote antrą, kodėl negavote trečio? Nes niekam dar nesuskaldytos smegenys...

  EK: – Bet mes neturime suskaidytų smegenų. Kadangi kiekviena programa yra valdoma multimasterio, mums nesvarbu, į kurį centrą buvo pateikta užklausa. Esame pasiruošę tam, kad sugesus vienam iš mūsų duomenų centrų (tuo pasikliaujame) ir vartotojo užklausai persijungus į antrąjį duomenų centrą, tikrai esame pasirengę prarasti šį vartotoją; bet tai bus vienetai, absoliutūs vienetai.

  In: - Labas vakaras. Ačiū už pranešimą. Kalbėjote apie derintuvą, kuris vykdo kai kurias bandomąsias operacijas gamybinėje versijoje. Bet papasakokite apie bandomuosius sandorius! Kaip giliai jis eina?

  EK: – Jis praeina visą viso komponento ciklą. Komponento atveju nėra skirtumo tarp bandomosios operacijos ir gamybos operacijos. Bet loginiu požiūriu tai tiesiog atskiras projektas sistemoje, kuriame vykdomos tik bandomosios operacijos.

  In: -Kur tu jį nutraukei? Čia Core atsiuntė...

  EK: – Mes šiuo atveju atsiliekame už „Kor“ už bandomąsias operacijas... Turime tokį maršrutą: „Kor“ žino, į kurią mokėjimo sistemą siųsti – siunčiame į netikrą mokėjimo sistemą, kuri tiesiog duoda http signalą ir tai viskas.

  In: – Sakykite, prašau, ar jūsų paraiška buvo surašyta vienu didžiuliu monolitu, ar supjaustėte ją į kokias nors paslaugas ar net mikropaslaugas?

  EK: – Mes, žinoma, neturime monolito, turime į paslaugas orientuotą programą. Juokaujame, kad mūsų servisas pagamintas iš monolitų – jie tikrai nemaži. Sunku tai pavadinti mikropaslaugomis, tačiau tai yra paslaugos, kuriose dirba paskirstytų mašinų darbuotojai.

  Jei paslauga serveryje yra pažeista...

  In: – Tada aš turiu kitą klausimą. Net jei tai būtų monolitas, jūs vis tiek sakėte, kad turite daug tokių momentinių serverių, jie visi iš esmės apdoroja duomenis, ir kyla klausimas: „Jei pažeidžiamas vienas iš momentinių serverių ar programos, bet kokia atskira nuoroda , ar jie turi kokią nors prieigos kontrolę? Kuris iš jų ką gali? Į ką turėčiau kreiptis dėl kokios informacijos?

  
  
  EK: - Taip, būtinai. Saugumo reikalavimai yra gana rimti. Pirma, turime atvirų duomenų judėjimą, o prievadai yra tik tie, per kuriuos iš anksto numatome eismo judėjimą. Jei komponentas susisiekia su duomenų baze (tarkime, su Muskul) per 5-4-3-2, jam bus atviras tik 5-4-3-2, o kiti prievadai ir kitos eismo kryptys nebus pasiekiamos. Be to, jūs turite suprasti, kad mūsų gamyboje yra apie 10 skirtingų apsaugos kilpų. Ir net jei programa buvo kažkaip pažeista, neduok Dieve, užpuolikas negalės pasiekti serverio valdymo pulto, nes tai yra kita tinklo saugos zona.

  In: – Ir man šiame kontekste įdomiau yra tai, kad jūs turite tam tikras sutartis su tarnybomis – ką jos gali padaryti, kokiais „veiksmais“ gali susisiekti... O normaliu srautu kažkokios konkrečios tarnybos prašo kažkokių. eilutėje, „veiksmų“ sąrašas kitoje. Atrodo, kad jie nesikreipia į kitus įprastoje situacijoje, o jiems tenka kitos atsakomybės sritys. Jei vienas iš jų bus pažeistas, ar jis galės sutrikdyti tos paslaugos „veiksmus“?..

  EK: - Aš suprantu. Jei įprastoje situacijoje su kitu serveriu ryšys buvo iš viso leidžiamas, tada taip. Pagal SLA sutartį mes neprižiūrime, kad jums būtų leidžiami tik pirmieji 3 „veiksmai“, o jums neleidžiami 4 „veiksmai“. Mums tai turbūt perteklinė, nes jau turime 4 lygių apsaugos sistemą iš principo grandinėms. Mums labiau patinka gintis kontūrais, o ne vidaus lygiu.

  Kaip veikia „Visa“, „MasterCard“ ir „Sberbank“.

  In: – Noriu patikslinti dalyką apie vartotojo perjungimą iš vieno duomenų centro į kitą. Kiek žinau, Visa ir MasterCard veikia naudodami 8583 dvejetainį sinchroninį protokolą, ten yra ir mišinių. Ir aš norėjau sužinoti, dabar turime omenyje perėjimą – ar tai tiesiogiai „Visa“ ir „MasterCard“, ar prieš mokėjimo sistemas, prieš apdorojimą?

  EK: - Tai prieš mišinius. Mūsų mišiniai yra tame pačiame duomenų centre.

  In: – Grubiai tariant, ar turite vieną jungties tašką?

  EK: – „Visa“ ir „MasterCard“ – taip. Tiesiog todėl, kad „Visa“ ir „MasterCard“ reikalauja gana rimtų investicijų į infrastruktūrą, kad būtų galima sudaryti atskiras sutartis, pavyzdžiui, gauti antrąją mišinių porą. Jie yra rezervuoti viename duomenų centre, bet jei, neduok Dieve, mūsų duomenų centras, kuriame yra mišiniai prisijungimui prie Visa ir MasterCard, nutrūks, tada ryšys su Visa ir MasterCard dings...

  In: – Kaip juos galima rezervuoti? Žinau, kad „Visa“ iš principo leidžia tik vieną ryšį!

  EK: – Jie patys tiekia įrangą. Bet kokiu atveju gavome įrangą, kuri viduje yra visiškai perteklinė.

  In: – Vadinasi, stendas iš jų „Connects Orange“?..

  EK: – Taip.

  In: – Bet kaip šiuo atveju: jei jūsų duomenų centras išnyks, kaip galite juo toliau naudotis? O gal tiesiog sustoja eismas?

  EK: – Ne. Tokiu atveju tiesiog perjungsime srautą į kitą kanalą, kuris, natūralu, mums kainuos brangiau, o klientams – brangiau. Bet srautas vyks ne per mūsų tiesioginį ryšį su „Visa“, „MasterCard“, o per sąlyginį „Sberbank“ (labai perdėta).

  Labai atsiprašau, jei įžeidžiau „Sberbank“ darbuotojus. Tačiau pagal mūsų statistiką tarp Rusijos bankų dažniausiai krenta „Sberbank“. Nepraeina nė mėnuo, kad „Sberbank“ kažkas nenukristų.

  
  
  

  Kai kurie skelbimai 🙂

  Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, debesies VPS kūrėjams nuo 4.99 USD, unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: Visa tiesa apie VPS (KVM) E5-2697 v3 (6 branduoliai) 10GB DDR4 480GB SSD 1Gbps nuo 19$ arba kaip dalintis serveriu? (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).

  „Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 televizoriai nuo 199 USD Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo ​​99 USD! Skaityti apie Kaip sukurti infrastruktūros korp. klasę naudojant Dell R730xd E5-2650 v4 serverius, kurių vertė 9000 eurų už centą?

Šaltinis: www.habr.com