ProHoster > Blogs > Administrācija > HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

Visi runā par izstrādes un testÄ“Å”anas procesiem, personāla apmācÄ«bu, motivācijas paaugstināŔanu, taču ar Å”iem procesiem nepietiek, kad servisa dÄ«kstāves minÅ«te maksā milzÄ«gas naudas summas. Ko darÄ«t, veicot finanÅ”u darÄ«jumus saskaņā ar stingru SLA? Kā palielināt savu sistēmu uzticamÄ«bu un kļūdu toleranci, izstrādi un testÄ“Å”anu izslēdzot no vienādojuma?

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

Nākamā HighLoad++ konference notiks 6. gada 7. un 2020. aprīlī Sanktpēterburgā. Sīkāka informācija un biļetes uz saite. 9. novembrī 18:00. HighLoad++ Maskava 2018, Deli + Kolkata halle. Tēzes un prezentācija.

Jevgeņijs Kuzovļevs (turpmāk ā€“ EK): - Draugi, sveiki! Mani sauc Kuzovļevs Jevgeņijs. Esmu no uzņēmuma EcommPay, konkrēta nodaļa ir uzņēmumu grupas IT nodaļa EcommPay IT. Un Å”odien mēs runāsim par dÄ«kstāvēm - par to, kā no tām izvairÄ«ties, par to, kā samazināt to sekas, ja no tā nav iespējams izvairÄ«ties. Tēma ir norādÄ«ta Ŕādi: ā€œKo darÄ«t, ja dÄ«kstāves minÅ«te maksā 100 000 USDā€? Raugoties nākotnē, mÅ«su skaitļi ir salÄ«dzināmi.

Ko dara EcommPay IT?

Kas mēs esam? Kāpēc es stāvu Å”eit jÅ«su priekŔā? Kāpēc man ir tiesÄ«bas tev Å”eit kaut ko pastāstÄ«t? Un par ko mēs Å”eit runāsim sÄ«kāk?

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

EcommPay uzņēmumu grupa ir starptautisks ieguvējs. Mēs apstrādājam maksājumus visā pasaulē - Krievijā, Eiropā, Dienvidaustrumāzijā (Visā pasaulē). Mums ir 9 biroji, kopā strādā 500 darbinieki, no kuriem aptuveni nedaudz mazāk kā puse ir IT speciālisti. Visu, ko darām, visu, no kā pelnām naudu, darÄ«jām paÅ”i.

Visus savus produktus (un to mums ir diezgan daudz - mÅ«su lielo IT produktu lÄ«nijā mums ir aptuveni 16 dažādi komponenti) mēs rakstÄ«jām paÅ”i; Mēs paÅ”i rakstām, paÅ”i attÄ«stāmies. Un Å”obrÄ«d mēs veicam apmēram miljonu darÄ«jumu dienā (iespējams, ka miljons ir pareizais veids). Mēs esam diezgan jauns uzņēmums ā€“ mums ir tikai kādi seÅ”i gadi.

Pirms 6 gadiem tas bija tāds startup, kad puiÅ”i nāca kopā ar biznesu. Viņus vienoja ideja (nebija nekā cita kā ideja), un mēs skrējām. Kā jebkurÅ” startup, mēs skrējām ātrāk... Mums ātrums bija svarÄ«gāks par kvalitāti.

Kādā brÄ«dÄ« mēs apstājāmies: sapratām, ka vairs nevaram dzÄ«vot tādā ātrumā un ar tādu kvalitāti, un mums vispirms jākoncentrējas uz kvalitāti. Å obrÄ«d mēs nolēmām izveidot jaunu platformu, kas bÅ«tu pareiza, mērogojama un uzticama. Viņi sāka rakstÄ«t Å”o platformu (sāka investēt, izstrādāt attÄ«stÄ«bu, testēt), bet kādā brÄ«dÄ« saprata, ka izstrāde un testÄ“Å”ana neļauj sasniegt jaunu pakalpojumu kvalitātes lÄ«meni.

JÅ«s izgatavojat jaunu produktu, laižat to ražoÅ”anā, bet tik un tā kaut kas kaut kur noies greizi. Un Å”odien mēs runāsim par to, kā sasniegt jaunu kvalitātes lÄ«meni (kā mēs to paveicām, par mÅ«su pieredzi), izstrādi un testÄ“Å”anu izslēdzot no vienādojuma; mēs runāsim par to, kas ir pieejams darbÄ«bai - kāda darbÄ«ba pati par sevi var, ko tā var piedāvāt testÄ“Å”anai, lai ietekmētu kvalitāti.

Dīkstāves. Darbības bauŔļi.

Vienmēr galvenais stÅ«rakmens, par ko mēs Å”odien runāsim, ir dÄ«kstāves. BriesmÄ«gs vārds. Ja mums ir dÄ«kstāve, mums viss ir slikti. Mēs skrienam pacelt, admini tur serveri - nedod Dievs, lai tas nenokristu, kā saka tajā dziesmā. Par to mēs Å”odien runāsim.

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

Kad mēs sākām mainÄ«t savas pieejas, mēs izveidojām 4 bauŔļus. Man tie ir parādÄ«ti slaidos:

Šie bauŔļi ir pavisam vienkārŔi:

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

  • Ātri identificējiet problēmu.
  • AtbrÄ«vojieties no tā vēl ātrāk.
  • PalÄ«dziet izprast iemeslu (vēlāk izstrādātājiem).
  • Un standartizēt pieejas.

Vēlos vērst jÅ«su uzmanÄ«bu uz punktu Nr.2. Mēs atbrÄ«vojamies no problēmas, nevis risinām to. Lēmums ir sekundārs. Mums primārais ir, lai lietotājs bÅ«tu pasargāts no Ŕīs problēmas. Tā pastāvēs kaut kādā izolētā vidē, bet Å”ai videi ar to nebÅ«s nekāda kontakta. PatiesÄ«bā mēs iziesim cauri Ŕīm četrām problēmu grupām (dažas sÄ«kāk, dažas mazāk), pastāstÄ«Å”u, ko lietojam, kāda mums ir atbilstoÅ”a pieredze risinājumos.

Problēmu novērÅ”ana: kad tās notiek un ko ar tām darÄ«t?

Bet mēs sāksim no ierindas, sāksim ar punktu Nr.2 - kā ātri tikt vaļā no problēmas? Ir problēma - mums tā ir jānovērÅ”. "Kas mums bÅ«tu jādara Å”ajā sakarā?" - galvenais jautājums. Un, kad sākām domāt par to, kā novērst problēmu, mēs izstrādājām dažas prasÄ«bas, kas jāievēro, veicot problēmu novērÅ”anu.

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

Lai formulētu Ŕīs prasÄ«bas, mēs nolēmām uzdot sev jautājumu: ā€œKad mums rodas problēmasā€? Un problēmas, kā izrādÄ«jās, rodas četros gadÄ«jumos:

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

  • AparatÅ«ras kļūme.
  • Ārējie pakalpojumi neizdevās.
  • ProgrammatÅ«ras versijas maiņa (tā pati izvietoÅ”ana).
  • SprādzienbÄ«stamas slodzes pieaugums.

Mēs nerunāsim par pirmajiem diviem. AparatÅ«ras darbÄ«bas traucējumus var atrisināt pavisam vienkārÅ”i: jums viss ir jādublē. Ja tie ir diski, tie ir jāsamontē RAID; ja tas ir serveris, serveris ir jādublē; ja jums ir tÄ«kla infrastruktÅ«ra, jums ir jāpiegādā otra tÄ«kla infrastruktÅ«ras kopija, tas ir, jÅ«s to paņemat un dublēt to. Un, ja kaut kas neizdodas, pārslēdzieties uz rezerves jaudu. Å eit ir grÅ«ti pateikt kaut ko vairāk.

Otrais ir ārējo pakalpojumu kļūme. Lielākajai daļai sistēma nemaz nav problēma, bet ne mums. Tā kā mēs apstrādājam maksājumus, mēs esam agregators, kas atrodas starp lietotāju (kurÅ” ievada savus kartes datus) un bankām, maksājumu sistēmām (Visa, MasterCard, Mira u.c.). MÅ«su ārējie pakalpojumi (maksājumu sistēmas, bankas) mēdz neizdoties. Ne mēs, ne jÅ«s (ja jums ir Ŕādi pakalpojumi) to nevaram ietekmēt.

Ko tad darÄ«t? Å eit ir divas iespējas. Pirmkārt, ja varat, jums vajadzētu kaut kādā veidā dublēt Å”o pakalpojumu. Piemēram, ja mēs varam, mēs pārsÅ«tām trafiku no viena pakalpojuma uz citu: piemēram, kartes tika apstrādātas caur Sberbank, Sberbank ir problēmas - mēs pārsÅ«tām trafiku [nosacÄ«ti] uz Raiffeisen. Otra lieta, ko mēs varam darÄ«t, ir ļoti ātri pamanÄ«t ārējo pakalpojumu kļūmi, un tāpēc nākamajā ziņojuma daļā mēs runāsim par reakcijas ātrumu.

Faktiski no Ŕīm četrām mēs varam Ä«paÅ”i ietekmēt programmatÅ«ras versiju maiņu - veikt darbÄ«bas, kas novedÄ«s pie situācijas uzlaboÅ”anās izvietoÅ”anas kontekstā un sprādzienbÄ«stamas slodzes pieauguma kontekstā. PatiesÄ«bā mēs to darÄ«jām. Å eit atkal neliela piezÄ«me...

Ja jums ir mākonis, vairākas no Ŕīm četrām problēmām tiek atrisinātas nekavējoties. Ja atrodaties Microsoft Azhur, Ozone mākoņos vai izmantojat mÅ«su mākoņus no Yandex vai Mail, tad vismaz aparatÅ«ras darbÄ«bas traucējumi kļūst par viņu problēmu, un aparatÅ«ras darbÄ«bas traucējumu kontekstā viss nekavējoties kļūst kārtÄ«bā.

Mēs esam nedaudz netradicionāls uzņēmums. Å eit visi runā par ā€œKubernetsā€, par mākoņiem - mums nav ne ā€œKubernetsā€, ne mākoņu. Bet mums daudzos datu centros ir aparatÅ«ras plaukti, un mēs esam spiesti dzÄ«vot no Ŕīs aparatÅ«ras, esam spiesti par to visu atbildēt. Tāpēc mēs runāsim Å”ajā kontekstā. Tātad, par problēmām. Pirmie divi tika izņemti no iekavām.

Programmatūras versijas maiņa. Bāzes

MÅ«su izstrādātājiem nav piekļuves produkcijai. Kāpēc ir tā, ka? Mums ir tikai PCI DSS sertifikāts, un mÅ«su izstrādātājiem vienkārÅ”i nav tiesÄ«bu iekļūt ā€œproduktāā€. Tas tā, punkts. Pavisam. Tāpēc izstrādes atbildÄ«ba beidzas tieÅ”i tajā brÄ«dÄ«, kad izstrāde iesniedz bÅ«vējumu izlaiÅ”anai.

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

MÅ«su otrais pamats, kas mums ir un kas arÄ« mums ļoti palÄ«dz, ir unikālu nedokumentētu zināŔanu trÅ«kums. Es ceru, ka tas pats attiecas uz jums. Jo, ja tas tā nav, jums bÅ«s problēmas. Problēmas radÄ«sies tad, kad Ŕīs unikālās, nedokumentētās zināŔanas nebÅ«s Ä«stajā laikā un Ä«stajā vietā. Pieņemsim, ka jums ir viena persona, kas zina, kā izvietot konkrētu komponentu - cilvēka nav, viņŔ ir atvaļinājumā vai slims - tas ir, jums ir problēmas.

Un treÅ”ais pamats, pie kura esam nonākuÅ”i. Mēs nonācām pie tā caur sāpēm, asinÄ«m, asarām ā€“ nonācām pie secinājuma, ka jebkurā mÅ«su bÅ«vniecÄ«bā ir kļūdas, pat ja tā ir bez kļūdām. Mēs paÅ”i to nolēmām: kad mēs kaut ko izvietojam, kad kaut ko ievietojam ražoÅ”anā, mums ir bÅ«vēts ar kļūdām. Mēs esam izveidojuÅ”i prasÄ«bas, kurām mÅ«su sistēmai ir jāatbilst.

Prasības programmatūras versijas maiņai

Ir trīs prasības:

HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

  • Mums ātri jāatceļ izvietoÅ”ana.
  • Mums ir jāsamazina neveiksmÄ«gas izvietoÅ”anas ietekme.
  • Un mums ir jāspēj ātri izvietot paralēli.
    TieÅ”i tādā secÄ«bā! Kāpēc? Jo, pirmkārt, izvietojot jaunu versiju, ātrums nav svarÄ«gs, bet ir svarÄ«gi, lai jÅ«s, ja kaut kas noiet greizi, ātri atvilktu atpakaļ un radÄ«tu minimālu ietekmi. Bet, ja jums ir versiju komplekts ražoÅ”anā, par kuru izrādās, ka ir kļūda (no zila gaisa, nebija izvietoÅ”anas, bet ir kļūda) - jums ir svarÄ«gs turpmākās izvietoÅ”anas ātrums. Ko mēs esam darÄ«juÅ”i, lai izpildÄ«tu Ŕīs prasÄ«bas? Mēs izmantojām Ŕādu metodiku:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Tas ir diezgan labi zināms, mēs nekad to neesam izgudrojuÅ”i - tas ir Blue/Green izvietojums. Kas tas ir? Katrai serveru grupai, kurā ir instalētas jÅ«su lietojumprogrammas, ir jābÅ«t kopijai. Kopija ir ā€œsiltaā€: tajā nav trafika, taču jebkurā brÄ«dÄ« Å”o trafiku var nosÅ«tÄ«t uz Å”o kopiju. Å ajā kopijā ir ietverta iepriekŔējā versija. IzvietoÅ”anas laikā kods tiek izvērsts neaktÄ«vā kopijā. Pēc tam daļu trafika (vai visu) pārslēdzat uz jauno versiju. Tādējādi, lai mainÄ«tu satiksmes plÅ«smu no vecās versijas uz jauno, ir jāveic tikai viena darbÄ«ba: jāmaina balansētājs augÅ”tecē, jāmaina virziens - no viena augÅ”tecē uz otru. Tas ir ļoti ērti un atrisina ātras pārslēgÅ”anas un ātras atgrieÅ”anas problēmu.

    Å eit risinājums otrajam jautājumam ir minimizÄ“Å”ana: jÅ«s varat nosÅ«tÄ«t tikai daļu trafika uz jaunu rindu, uz rindu ar jaunu kodu (lai tas bÅ«tu, piemēram, 2%). Un Å”ie 2% nav 100%! Ja neveiksmÄ«gas izvietoÅ”anas dēļ zaudējāt 100% trafika, tas ir biedējoÅ”i; ja zaudējāt 2% trafika, tas ir nepatÄ«kami, taču tas nav biedējoÅ”i. Turklāt lietotāji to, visticamāk, pat nepamanÄ«s, jo dažos gadÄ«jumos (ne visos) tas pats lietotājs, nospiežot F5, tiks pārcelts uz citu, darba versiju.

    Zila/zaļa izvietoÅ”ana. MarÅ”rutÄ“Å”ana

    Tomēr ne viss ir tik vienkārÅ”i ā€œBlue/Green deployā€... Visas mÅ«su sastāvdaļas var iedalÄ«t trÄ«s grupās:

    • Ŕī ir priekÅ”gals (maksājumu lapas, kuras redz mÅ«su klienti);
    • apstrādes kodols;
    • adapteris darbam ar maksājumu sistēmām (bankas, MasterCard, Visa...).

    Un Å”eit ir nianse - nianse slēpjas marÅ”rutā starp lÄ«nijām. Ja jÅ«s vienkārÅ”i pārslēdzat 100% satiksmes, jums nebÅ«s Å”o problēmu. Bet, ja vēlaties mainÄ«t 2%, jÅ«s sākat uzdot jautājumus: "Kā to izdarÄ«t?" VienkārŔākā lieta ir tieÅ”i uz priekÅ”u: jÅ«s varat iestatÄ«t Round Robin nginx pēc nejauŔības principa, un jums ir 2% pa kreisi, 98% pa labi. Bet tas ne vienmēr ir piemērots.

    Piemēram, mÅ«su gadÄ«jumā lietotājs mijiedarbojas ar sistēmu ar vairāk nekā vienu pieprasÄ«jumu. Tas ir normāli: 2, 3, 4, 5 pieprasÄ«jumi ā€” jÅ«su sistēmas var bÅ«t vienādas. Un, ja jums ir svarÄ«gi, lai visi lietotāja pieprasÄ«jumi nonāk tajā paŔā rindā, kurā tika saņemts pirmais pieprasÄ«jums, vai (otrais punkts) pēc pārslēgÅ”anas visi lietotāja pieprasÄ«jumi nonāk jaunajā rindā (viņŔ varēja sākt strādāt agrāk ar sistēma, pirms slēdža), - tad Å”is nejauÅ”ais sadalÄ«jums jums nav piemērots. Tad ir Ŕādas iespējas:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Pirmā iespēja, visvienkārŔākā, ir balstÄ«ta uz klienta pamata parametriem (IP Hash). Jums ir IP, un jÅ«s to sadalāt no labās puses uz kreiso pēc IP adreses. Tad jums derēs otrais manis aprakstÄ«tais gadÄ«jums, kad izvietoÅ”ana notika, lietotājs jau varēja sākt strādāt ar jÅ«su sistēmu, un no izvietoÅ”anas brīža visi pieprasÄ«jumi tiks pārsÅ«tÄ«ti uz jaunu rindu (teiksim, uz to paÅ”u).

    Ja kāda iemesla dēļ tas jums nav piemērots un jums ir jānosūta pieprasījumi uz rindu, kurā tika saņemts lietotāja sākotnējais, sākotnējais pieprasījums, jums ir divas iespējas...
    Pirmā iespēja: jÅ«s varat iegādāties maksas nginx+. Ir Sticky sesiju mehānisms, kas pēc lietotāja sākotnējā pieprasÄ«juma pieŔķir lietotājam sesiju un saista to ar vienu vai otru augÅ”pusi. Visi turpmākie lietotāju pieprasÄ«jumi sesijas laikā tiks nosÅ«tÄ«ti uz to paÅ”u augŔējo straumi, kurā tika publicēta sesija.

    Tas mums nederēja, jo mums jau bija regulārs nginx. PārslēgÅ”anās uz nginx+ nav tā, ka tā ir dārga, tikai tas, ka mums tas bija nedaudz sāpÄ«gi un ne pārāk pareizi. Piemēram, ā€œSticks Sessionsā€ mums nederēja tā vienkārŔā iemesla dēļ, ka ā€œSticks Sessionsā€ neļauj marÅ”rutēt, pamatojoties uz ā€œVai nu-vaiā€. Tur jÅ«s varat norādÄ«t, ko mēs ā€œSticks Sessionsā€ darām, piemēram, pēc IP adreses vai pēc IP adreses un sÄ«kfailiem vai pēc parametra, bet ā€œVai nu-vaiā€ tur ir sarežģītāk.

    Tāpēc mēs nonācām pie ceturtā varianta. Mēs lietojām nginx uz steroÄ«diem (tas ir openresty) - tas ir tas pats nginx, kas papildus atbalsta pēdējo skriptu iekļauÅ”anu. Varat uzrakstÄ«t pēdējo skriptu, pieŔķirt tam ā€œatvērto atpÅ«tuā€, un Å”is pēdējais skripts tiks izpildÄ«ts, kad tiks saņemts lietotāja pieprasÄ«jums.

    Un mēs faktiski uzrakstÄ«jām Ŕādu skriptu, iestatÄ«jām sev ā€œopenrestiā€, un Å”ajā skriptā mēs Ŕķirojam 6 dažādus parametrus pēc savienojuma ā€œOrā€. AtkarÄ«bā no viena vai otra parametra klātbÅ«tnes mēs zinām, ka lietotājs ir nonācis vienā vai otrā lapā, vienā vai otrā rindiņā.

    Zila/zaļa izvietoŔana. PriekŔrocības un trūkumi

    Protams, droÅ”i vien varēja to padarÄ«t nedaudz vienkārŔāku (izmantot tos paÅ”us ā€œSticky Sessionsā€), taču mums ir arÄ« tāda nianse, ka viena darÄ«juma vienas apstrādes ietvaros ar mums mijiedarbojas ne tikai lietotājs... Bet maksājumu sistēmas arÄ« mijiedarbojas ar mums: pēc darÄ«juma apstrādes (nosÅ«tot pieprasÄ«jumu maksājumu sistēmai), mēs saņemam atteikumu.
    Un teiksim, ja mÅ«su ķēdē mēs varam pārsÅ«tÄ«t lietotāja IP adresi visos pieprasÄ«jumos un sadalÄ«t lietotājus pēc IP adreses, tad mēs neteiksim to paÅ”u "Visa": "VÄ«zi, mēs esam tāds retro uzņēmums, mums Ŕķiet bÅ«t starptautiskam (vietnē un Krievijā)... LÅ«dzu, norādiet mums lietotāja IP adresi papildu laukā, jÅ«su protokols ir standartizētsā€! Skaidrs, ka viņi nepiekritÄ«s.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Tāpēc tas mums nederēja - mēs veicām openresty. AttiecÄ«gi ar marÅ”rutÄ“Å”anu mēs saņēmām kaut ko lÄ«dzÄ«gu:

    AttiecÄ«gi zilajai/zaļajai izvietoÅ”anai ir manis minētās priekÅ”rocÄ«bas un trÅ«kumi.

    Divi trūkumi:

    • jums ir jāraizējas ar marÅ”rutÄ“Å”anu;
    • otrs galvenais trÅ«kums ir izdevumi.

    Vajag divreiz vairāk serveru, vajag divreiz vairāk operatÄ«vo resursu, vajag divreiz vairāk pūļu, lai uzturētu visu Å”o zoodārzu.

    Starp citu, starp priekÅ”rocÄ«bām ir vēl viena lieta, ko iepriekÅ” neminēju: jums ir rezerve slodzes pieauguma gadÄ«jumā. Ja jums ir straujÅ” slodzes pieaugums, jums ir liels lietotāju skaits, tad vienkārÅ”i iekļaujiet otro rindu izplatÄ«jumā no 50 lÄ«dz 50 ā€” un jÅ«su klasterÄ« uzreiz bÅ«s x2 serveri, lÄ«dz atrisināsit problēmu, ka jums ir vairāk serveru.

    Kā veikt ātru izvietoŔanu?

    Mēs runājām par to, kā atrisināt minimizācijas un ātras atcelÅ”anas problēmu, taču paliek jautājums: "Kā ātri izvietot?"

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Šeit tas ir īsi un vienkārŔi.

    • Jums ir jābÅ«t kompaktdisku sistēmai (nepārtraukta piegāde) - jÅ«s nevarat dzÄ«vot bez tās. Ja jums ir viens serveris, varat to izvietot manuāli. Mums, protams, ir aptuveni pusotrs tÅ«kstotis serveru un pusotrs tÅ«kstotis rokturu ā€“ mēs varam ierÄ«kot Ŕīs telpas lieluma nodaļu, lai tikai to izvietotu.
    • IzvietoÅ”anai jābÅ«t paralēlai. Ja jÅ«su izvietoÅ”ana ir secÄ«ga, tad viss ir slikti. Viens serveris ir normāls, jÅ«s visu dienu izvietosit pusotru tÅ«kstoti serveru.
    • Atkal, paātrinājumam tas, iespējams, vairs nav vajadzÄ«gs. IzvērÅ”anas laikā projekts parasti tiek uzbÅ«vēts. Jums ir tÄ«mekļa projekts, ir priekÅ”gala daļa (jÅ«s tur veidojat tÄ«mekļa pakotni, kompilējat npm - kaut kas lÄ«dzÄ«gs), un Å”is process principā ir Ä«slaicÄ«gs - 5 minÅ«tes, bet Ŕīs 5 minÅ«tes var esi kritisks. Tāpēc, piemēram, mēs to nedarām: mēs noņēmām Ŕīs 5 minÅ«tes, izvietojam artefaktus.

      Kas ir artefakts? Artefakts ir samontēta konstrukcija, kurā visas montāžas daļas jau ir pabeigtas. Mēs glabājam Å”o artefaktu artefaktu krātuvē. Vienā reizē mēs izmantojām divas Ŕādas krātuves ā€” tas bija Nexus un tagad jFrog Artifactory. Sākotnēji izmantojām ā€œNexusā€, jo sākām praktizēt Å”o pieeju Java lietojumprogrammās (tas bija labi piemērots). Tad viņi tur ievietoja dažas PHP rakstÄ«tās lietojumprogrammas; un ā€œNexusā€ vairs nebija piemērots, un tāpēc mēs izvēlējāmies jFrog Artefactory, kas var artificēt gandrÄ«z visu. Mēs pat esam nonākuÅ”i pie tā, ka Å”ajā artefaktu krātuvē mēs glabājam paÅ”i savas binārās pakotnes, kuras apkopojam serveriem.

    Sprādzienbīstamas slodzes pieaugums

    Mēs runājām par programmatÅ«ras versijas maiņu. Nākamā lieta, kas mums ir, ir sprādzienbÄ«stams slodzes pieaugums. Å eit es droÅ”i vien domāju ar sprādzienbÄ«stamu slodzes pieaugumu, kas nav gluži pareizais...

    UzrakstÄ«jām jaunu sistēmu - tā ir uz servisu orientēta, moderna, skaista, visur strādnieki, visur rindas, visur asinhronija. Un Ŕādās sistēmās dati var plÅ«st caur dažādām plÅ«smām. Pirmajam darÄ«jumam var izmantot 1., 3., 10. strādnieku, otrajam darÄ«jumam - 2., 4., 5.. Un Å”odien, pieņemsim, no rÄ«ta jums ir datu plÅ«sma, kas izmanto pirmos trÄ«s darbiniekus, un vakarā tā krasi mainās, un viss izmanto pārējos trÄ«s darbiniekus.

    Un Å”eit izrādās, ka jums ir kaut kā jāmēro darbinieki, jums ir kaut kā jāmēro savi pakalpojumi, bet tajā paŔā laikā jānovērÅ” resursu uzpÅ«Å”anās.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Mēs esam definējuÅ”i savas prasÄ«bas. Å Ä«s prasÄ«bas ir pavisam vienkārÅ”as: lai bÅ«tu Servisa atklāŔana, parametru noteikÅ”ana ā€“ viss ir standarts Ŕādu mērogojamu sistēmu veidoÅ”anai, izņemot vienu punktu ā€“ resursu nolietojumu. Teicām, ka neesam gatavi amortizēt resursus, lai serveri silda gaisu. Mēs paņēmām "Consul", mēs paņēmām "Nomad", kas pārvalda mÅ«su strādniekus.

    Kāpēc tā mums ir problēma? Nedaudz atkāpsimies. Tagad mums ir aptuveni 70 maksājumu sistēmas. No rīta satiksme iet caur Sberbanku, tad Sberbank krita, piemēram, un mēs to pārslēdzam uz citu maksājumu sistēmu. Pirms Sberbank mums bija 100 strādnieku, un pēc tam mums krasi jāpalielina 100 strādnieku skaits citai maksājumu sistēmai. Un vēlams, lai tas viss notiktu bez cilvēka līdzdalības. Jo, ja ir cilvēku līdzdalība, tur 24/7 jāsēž inženierim, kuram tas tikai jādara, jo tādas kļūmes, kad aiz muguras ir 70 sistēmas, notiek regulāri.

    Tāpēc mēs apskatÄ«jām Nomad, kuram ir atvērts IP, un uzrakstÄ«jām savu lietu Scale-Nomad - ScaleNo, kas veic aptuveni sekojoÅ”o: uzrauga rindas pieaugumu un samazina vai palielina darbinieku skaitu atkarÄ«bā no dinamikas. no rindas. Kad mēs to izdarÄ«jām, mēs domājām: "VarbÅ«t mēs to varam atvērt pirmkoda?" Tad viņi paskatÄ«jās uz viņu ā€“ viņa bija vienkārÅ”a kā divas kapeikas.

    Pagaidām mēs neesam to atvērtā pirmkoda veidā, bet, ja pēkŔņi pēc ziņojuma, pēc tam, kad sapratāt, ka jums ir vajadzÄ«ga tāda lieta, jums to vajag, mani kontakti ir pēdējā slaidā - lÅ«dzu, rakstiet man. Ja bÅ«s vismaz 3-5 cilvēki, mēs to sponsorēsim.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Kā tas strādā? PaskatÄ«simies! Skatoties uz priekÅ”u: kreisajā pusē ir mÅ«su uzraudzÄ«bas daļa: Ŕī ir viena rinda, augÅ”pusē ir notikumu apstrādes laiks, vidÅ« ir darÄ«jumu skaits, apakŔā ir darbinieku skaits.

    Ja paskatās, Å”ajā attēlā ir kļūme. AugŔējā diagrammā viena no diagrammām avarēja 45 sekunžu laikā - viena no maksājumu sistēmām nokrita. TÅ«lÄ«t 2 minÅ«Å”u laikā tika ievesta satiksme un rinda sāka augt uz citu norēķinu sistēmu, kurā nebija neviena strādnieka (resursus neizmantojām - tieÅ”i otrādi, resursu utilizējām pareizi). Mēs negribējām sildÄ«t - bija minimāls skaits, apmēram 5-10 strādnieku, bet viņi netika galā.

    Pēdējā grafikā redzams ā€œkuprisā€, kas nozÄ«mē tikai to, ka ā€œSkalenoā€ Å”o summu dubultoja. Un tad, kad grafiks nedaudz nokritās, viņŔ to nedaudz samazināja - strādnieku skaits tika mainÄ«ts automātiski. Tā Ŕī lieta darbojas. Mēs runājām par 2. punktu - "Kā ātri atbrÄ«voties no iemesliem."

    Uzraudzība. Kā ātri noteikt problēmu?

    Tagad pirmais punkts ir "Kā ātri noteikt problēmu?" Uzraudzība! Mums ir ātri jāsaprot dažas lietas. Kādas lietas mums vajadzētu ātri saprast?

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Trīs lietas!

    • Mums ātri jāsaprot un jāsaprot mÅ«su paÅ”u resursu darbÄ«ba.
    • Mums ātri jāsaprot kļūmes un jāuzrauga to sistēmu darbÄ«ba, kas ir ārpus mums.
    • TreÅ”ais punkts ir loÄ£isko kļūdu noteikÅ”ana. Tas ir tad, kad sistēma darbojas jÅ«su labā, viss ir normāli pēc visiem rādÄ«tājiem, bet kaut kas noiet greizi.

    Es droÅ”i vien jums neko tik forÅ”u Å”eit nestāstÄ«Å”u. Es bÅ«Å”u kapteinis acÄ«mredzamais. Mēs meklējām to, kas bija tirgÅ«. Mums ir "jautrs zoodārzs". Šāds zoodārzs mums tagad ir:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Mēs izmantojam Zabbix, lai uzraudzītu aparatūru, lai uzraudzītu galvenos serveru rādītājus. Datubāzēm izmantojam Okmeter. Mēs izmantojam "Grafana" un "Prometheus" visiem pārējiem rādītājiem, kas neatbilst pirmajiem diviem, daži ar "Grafana" un "Prometheus", un daži ar "Grafana" ar "Influx" un Telegraf.

    Pirms gada vēlējāmies izmantot New Relic. ForÅ”a lieta, tā var visu. Bet, cik viņa var visu, viņa ir tik dārga. Kad mēs izaugām lÄ«dz 1,5 tÅ«kstoÅ”iem serveru, pie mums pienāca pārdevējs un teica: "Slēgsim lÄ«gumu uz nākamo gadu." Mēs paskatÄ«jāmies uz cenu un teicām, ka nē, mēs to nedarÄ«sim. Tagad mēs atsakāmies no New Relic, mums ir palikuÅ”i apmēram 15 serveri, kas atrodas New Relic uzraudzÄ«bā. Cena izrādÄ«jās absolÅ«ti mežonÄ«ga.

    Un ir viens rÄ«ks, ko mēs paÅ”i ieviesām - tas ir atkļūdotājs. Sākumā mēs to nosaucām par ā€œBaggerā€, bet tad garām gāja angļu valodas skolotāja, mežonÄ«gi smējās un pārdēvēja to par ā€œDebaggerā€. Kas tas ir? Å is ir rÄ«ks, kas faktiski 15ā€“30 sekunžu laikā katrā komponentā, piemēram, sistēmas ā€œmelnajā kastēā€, veic komponenta vispārējās veiktspējas testus.

    Piemēram, ja ir ārēja lapa (maksājumu lapa), viņŔ to vienkārÅ”i atver un apskata, kā tai vajadzētu izskatÄ«ties. Ja tas tiek apstrādāts, viņŔ nosÅ«ta testa ā€œdarÄ«jumuā€ un pārliecinās, ka Å”is ā€œdarÄ«jumsā€ tiek saņemts. Ja tā ir saistÄ«ba ar maksājumu sistēmām, mēs attiecÄ«gi aktivizējam testa pieprasÄ«jumu, kur varam, un pārliecināmies, ka ar mums viss ir kārtÄ«bā.

    Kādi rādītāji ir svarīgi monitoringam?

    Ko mēs galvenokārt uzraugām? Kādi rādītāji mums ir svarīgi?

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    • Reakcijas laiks / RPS frontēs ir ļoti svarÄ«gs rādÄ«tājs. ViņŔ uzreiz atbild, ka ar tevi kaut kas nav kārtÄ«bā.
    • Apstrādāto ziņojumu skaits visās rindās.
    • Strādnieku skaits.
    • Pamata pareizÄ«bas rādÄ«tāji.

    Pēdējais punkts ir ā€œbiznesaā€, ā€œbiznesaā€ metrika. Ja vēlaties pārraudzÄ«t vienu un to paÅ”u, jums ir jādefinē viens vai divi rādÄ«tāji, kas jums ir galvenie rādÄ«tāji. MÅ«su metrika ir caurlaidspēja (tā ir veiksmÄ«go darÄ«jumu skaita attiecÄ«ba pret kopējo darÄ«jumu plÅ«smu). Ja tajā kaut kas mainās ar 5-10-15 minÅ«Å”u intervālu, tas nozÄ«mē, ka mums ir problēmas (ja tas radikāli mainās).

    Kā tas mums izskatās, ir piemērs vienam no mūsu dēļiem:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Kreisajā pusē ir 6 grafiki, tas ir atbilstoÅ”i rindām - strādnieku skaits un ziņojumu skaits rindās. Labajā pusē ā€“ RPS, RTS. Tālāk ir norādÄ«ta tā pati ā€œbiznesaā€ metrika. Un ā€œbiznesaā€ metrikā mēs uzreiz varam redzēt, ka divos vidējos grafikos kaut kas nogāja greizi... Å Ä« ir vēl viena sistēma, kas stāv aiz mums un ir kritusi.

    Otra lieta, kas mums bija jādara, bija uzraudzÄ«t ārējo maksājumu sistēmu kritumu. Å eit mēs paņēmām OpenTracing - mehānismu, standartu, paradigmu, kas ļauj izsekot izplatÄ«tajām sistēmām; un tas tika nedaudz mainÄ«ts. Standarta OpenTracing paradigma saka, ka mēs izveidojam izsekoÅ”anu katram atseviŔķam pieprasÄ«jumam. Mums tas nebija vajadzÄ«gs, un mēs to iekļāvām kopsavilkumā, apkopojuma izsekojamÄ«bā. Mēs izveidojām rÄ«ku, kas ļauj mums izsekot aiz mums esoÅ”o sistēmu ātrumam.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Grafikā redzams, ka viena no maksājumu sistēmām sāka reaģēt 3 sekunžu laikā ā€“ mums ir problēmas. Turklāt Ŕī lieta reaģēs, kad sāksies problēmas, ar intervālu 20-30 sekundes.

    Un treŔā pastāvoŔo uzraudzības kļūdu klase ir loģiskā uzraudzība.

    GodÄ«gi sakot, es nezināju, ko uzzÄ«mēt uz Ŕī slaida, jo mēs jau ilgu laiku meklējām tirgÅ« kaut ko, kas mums bÅ«tu piemērots. Neko neatradām, tāpēc nācās darÄ«t paÅ”iem.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Ko es domāju ar loÄ£isko uzraudzÄ«bu? Iedomājieties: jÅ«s izveidojat sev sistēmu (piemēram, Tinder klonu); jÅ«s to izdarÄ«jāt, palaidāt to. VeiksmÄ«gais menedžeris Vasja Pupkins ielika to savā telefonā, ierauga tur meiteni, viņai patÄ«k... un lÄ«dzÄ«gs meitenei nepienāk - lÄ«dzÄ«gs nonāk apsargam Mihaļičam no tā paÅ”a biznesa centra. Pārvaldnieks nokāpj lejā un tad brÄ«nās: "Kāpēc Å”is apsargs Mihaļičs viņam tik patÄ«kami smaida?"

    Šādās situācijās... Mums Ŕī situācija izklausās nedaudz savādāk, jo (es rakstÄ«ju) tas ir reputācijas zaudējums, kas pastarpināti noved pie finansiāliem zaudējumiem. MÅ«su situācija ir pretēja: mēs varam ciest tieÅ”us finansiālus zaudējumus - piemēram, ja mēs veicām darÄ«jumu kā veiksmÄ«gu, bet tas bija neveiksmÄ«gs (vai otrādi). Man bija jāraksta savs rÄ«ks, kas izseko veiksmÄ«go darÄ«jumu skaitu laika gaitā, izmantojot biznesa rādÄ«tājus. TirgÅ« neko neatradu! TieÅ”i Å”o ideju es gribēju nodot. TirgÅ« nav nekā, kas atrisinātu Ŕāda veida problēmu.

    Tas bija par to, kā ātri noteikt problēmu.

    Kā noteikt izvietoŔanas iemeslus

    TreŔā problēmu grupa, ko mēs risinām, ir pēc tam, kad esam identificējuÅ”i problēmu, pēc tam, kad esam no tās atbrÄ«vojuÅ”ies, bÅ«tu labi saprast attÄ«stÄ«bas, pārbaudes iemeslu un kaut ko darÄ«t lietas labā. AttiecÄ«gi ir jāizmeklē, jāpaceļ baļķi.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Ja mēs runājam par baļķiem (galvenais iemesls ir baļķi), lielākā daļa mūsu baļķu atrodas ELK Stack - gandrīz visiem ir vienādi. Dažam varbūt ELK nav, bet ja žurnālus rakstīsi gigabaitos, tad agri vai vēlu nonāksi ELK. Mēs tos rakstām terabaitos.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Å eit ir problēma. Izlabojām, izlabojām lietotājam kļūdu, sākām izrakt, kas tur ir, iekāpām Kibanā, ievadÄ«jām tur darÄ«juma ID un dabÅ«jām tādu kāju lupatiņu (daudz rāda). Un Å”ajā kāju lupatā pilnÄ«gi nekas nav skaidrs. Kāpēc? Jā, jo nav skaidrs, kura daļa pieder kādam strādniekam, kura daļa pieder kurai komponentei. Un tajā brÄ«dÄ« mēs sapratām, ka mums ir vajadzÄ«ga izsekoÅ”ana ā€“ tas pats OpenTracing, par kuru es runāju.

    Mēs to domājām pirms gada, pievērsām uzmanÄ«bu tirgum, un tur bija divi instrumenti - ā€œZipkinā€ un ā€œJaegerā€. ā€œJagerā€ patiesÄ«bā ir tāds ideoloÄ£isks mantinieks, ā€œZipkinaā€ ideoloÄ£iskais pēctecis. Zipkinā viss ir labi, izņemot to, ka tas neprot apkopot, neprot iekļaut baļķus trasē, tikai laika izsekoÅ”anu. Un "Jager" to atbalstÄ«ja.

    ApskatÄ«jām ā€œJagerā€: var instrumentēt aplikācijas, var rakstÄ«t Api (api standarts PHP tajā laikā gan netika apstiprināts - tas bija pirms gada, bet tagad jau apstiprināts), bet tur nebija absolÅ«ti neviens klients. ā€œLabi,ā€ mēs nodomājām un uzrakstÄ«jām savu klientu. Ko mēs saņēmām? Aptuveni Ŕādi tas izskatās:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Jēgerā katram ziņojumam tiek izveidoti laidumi. Tas ir, kad lietotājs atver sistēmu, viņŔ redz vienu vai divus blokus katram ienākoÅ”ajam pieprasÄ«jumam (1-2-3 - lietotāja ienākoÅ”o pieprasÄ«jumu skaits, bloku skaits). Lai lietotājiem bÅ«tu vieglāk, žurnāliem un laika pēdām pievienojām atzÄ«mes. AttiecÄ«gi kļūdas gadÄ«jumā mÅ«su lietojumprogramma atzÄ«mēs žurnālu ar atbilstoÅ”u Error tagu. Varat filtrēt pēc kļūdas taga, un tiks parādÄ«ti tikai tie diapazoni, kuros ir Å”is bloks ar kļūdu. LÅ«k, kā tas izskatās, ja paplaÅ”inām diapazonu:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Sprauduma iekÅ”pusē ir pēdu kopums. Å ajā gadÄ«jumā tie ir trÄ«s testa pēdas, un treŔā trase norāda, ka ir radusies kļūda. Tajā paŔā laikā Å”eit mēs redzam laika izsekoÅ”anu: augÅ”pusē ir laika skala, un mēs redzam, kādā laika intervālā tika reÄ£istrēts Å”is vai cits žurnāls.

    AttiecÄ«gi mums viss gāja labi. Mēs rakstÄ«jām paÅ”i savu paplaÅ”inājumu, un mēs to izmantojām atvērtā koda vietā. Ja vēlaties strādāt ar izsekoÅ”anu, ja vēlaties strādāt ar ā€œJagerā€ PHP, ir mÅ«su paplaÅ”inājums, laipni lÅ«dzam izmantot, kā saka:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Mums ir Å”is paplaÅ”inājums - tas ir OpenTracing Api klients, tas ir izveidots kā php paplaÅ”inājums, tas ir, jums tas bÅ«s jāsamontē un jāinstalē sistēmā. Pirms gada nekas nebija savādāk. Tagad ir citi klienti, kas ir kā komponenti. Tas ir atkarÄ«gs no jums: vai nu jÅ«s izsÅ«knējat komponentus ar komponistu, vai arÄ« izmantojat paplaÅ”inājumu.

    Korporatīvie standarti

    Mēs runājām par trim bauŔļiem. Ceturtais bauslis ir standartizēt pieejas. Par ko ir runa? Tas ir par Å”o:

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Kāpēc Å”eit ir vārds "korporatÄ«vs"? Ne jau tāpēc, ka esam liels vai birokrātisks uzņēmums, nē! Es gribēju lietot vārdu ā€œkorporatÄ«vsā€ kontekstā, ka katram uzņēmumam, katram produktam ir jābÅ«t saviem standartiem, arÄ« jums. Kādi standarti mums ir?

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    • Mums ir izvietoÅ”anas noteikumi. Mēs bez viņa nekur nekustamies, nevaram. Mēs izvietojam apmēram 60 reizes nedēļā, tas ir, mēs izvietojam gandrÄ«z pastāvÄ«gi. Tajā paŔā laikā mums, piemēram, izvietoÅ”anas noteikumos ir noteikts tabu par izvietoÅ”anu piektdien - principā mēs neizvietojam.
    • Mums ir nepiecieÅ”ama dokumentācija. Neviens jauns komponents nenonāk ražoÅ”anā, ja tam nav dokumentācijas, pat ja tas ir dzimis mÅ«su RnD speciālistu aizgaldā. Mēs no viņiem pieprasām izvietoÅ”anas instrukcijas, uzraudzÄ«bas karti un aptuvenu aprakstu (tā, kā programmētāji var rakstÄ«t), kā Å”is komponents darbojas, kā to novērst.
    • Mēs atrisinām nevis problēmas cēloni, bet gan problēmu ā€“ to, ko es jau teicu. Mums ir svarÄ«gi aizsargāt lietotāju no problēmām.
    • Mums ir atļaujas. Piemēram, mēs neuzskatām par dÄ«kstāvi, ja divu minÅ«Å”u laikā esam zaudējuÅ”i 2% satiksmes. Tas bÅ«tÄ«bā nav iekļauts mÅ«su statistikā. Ja tas ir vairāk procentuāli vai Ä«slaicÄ«gs, mēs jau skaitām.
    • Un mēs vienmēr rakstām pēcnāves ziņas. Lai kas ar mums notiktu, jebkura situācija, kad kāds ražoÅ”anā nenormāli uzvedās, tiks atspoguļots pēcnāves darbā. Pēcnāves ir dokuments, kurā jÅ«s ierakstāt, kas ar jums notika, detalizētu laiku, to, ko jÅ«s darÄ«jāt, lai to labotu, un (tas ir obligāts bloks!), ko jÅ«s darÄ«sit, lai tas nenotiktu nākotnē. Tas ir obligāts un nepiecieÅ”ams turpmākai analÄ«zei.

    Kas tiek uzskatīts par dīkstāvi?

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Pie kā tas viss noveda?

    Tas noveda pie tā, ka (mums bija zināmas problēmas ar stabilitāti, tas nederēja ne klientiem, ne mums) pēdējo 6 mēneÅ”u laikā mÅ«su stabilitātes rādÄ«tājs bija 99,97. Mēs varam teikt, ka tas nav ļoti daudz. Jā, mums ir uz ko tiekties. No Ŕī rādÄ«tāja apmēram puse ir stabilitāte it kā nevis mÅ«su, bet mÅ«su tÄ«mekļa lietojumprogrammas ugunsmÅ«ra, kas stāv mÅ«su priekŔā un tiek izmantots kā pakalpojums, stabilitāte, bet klientiem tas ir vienalga.

    Mēs iemācÄ«jāmies gulēt naktÄ«. Beidzot! Pirms seÅ”iem mēneÅ”iem mēs nevarējām. Un par Å”o piezÄ«mi ar rezultātiem es vēlētos izdarÄ«t vienu piezÄ«mi. Vakar vakarā bija brÄ«niŔķīgs ziņojums par kodolreaktora vadÄ«bas sistēmu. Ja cilvēki, kas uzrakstÄ«ja Å”o sistēmu, mani dzird, lÅ«dzu, aizmirstiet par to, ko es teicu par ā€œ2% nav dÄ«kstāveā€. Jums 2% ir dÄ«kstāve, pat ja uz divām minÅ«tēm!

    Tas ir viss! Jūsu jautājumi.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Par balansētājiem un datu bāzes migrāciju

    KlausÄ«tāju jautājums (turpmāk ā€“ B): ā€“ Labvakar. Liels paldies par Ŕādu administratora ziņojumu! ÄŖss jautājums par jÅ«su balansieriem. JÅ«s minējāt, ka jums ir WAF, tas ir, cik es saprotu, jÅ«s izmantojat kaut kādu ārējo balansieri...

    EK: ā€“ Nē, mēs izmantojam savus pakalpojumus kā balansētāju. Å ajā gadÄ«jumā WAF mums ir tikai un vienÄ«gi DDoS aizsardzÄ«bas rÄ«ks.

    In: ā€“ Vai varat pateikt dažus vārdus par balansieriem?

    EK: ā€“ Kā jau teicu, Ŕī ir atvērtā režīma serveru grupa. Tagad mums ir 5 rezerves grupas, kas reaģē tikai... tas ir, serveris, kas darbojas tikai openresty, tas tikai nodroÅ”ina trafiku. AttiecÄ«gi, lai saprastu, cik daudz mēs turam: tagad mums ir regulāra vairāku simtu megabitu satiksmes plÅ«sma. Viņi tiek galā, jÅ«tas labi, pat nenoslogo sevi.

    In: ā€“ ArÄ« vienkārÅ”s jautājums. Å eit ir zilā/zaļā izvietoÅ”ana. Ko jÅ«s darāt, piemēram, ar datu bāzu migrāciju?

    EK: - Labs jautājums! Paskatieties, zilā/zaļā izvietoÅ”anā katrai rindai ir atseviŔķas rindas. Tas ir, ja mēs runājam par notikumu rindām, kas tiek pārsÅ«tÄ«tas no darbinieka uz darbinieku, zilajai lÄ«nijai un zaļajai lÄ«nijai ir atseviŔķas rindas. Ja mēs runājam par paÅ”u datu bāzi, tad mēs to apzināti saÅ”aurinājām, cik varējām, praktiski visu pārvietojām rindās, datu bāzē mēs glabājam tikai darÄ«jumu kaudzi. Un mÅ«su darÄ«jumu steks ir vienāds visām lÄ«nijām. Ar datubāzi Å”ajā kontekstā: mēs to nedalām zilā un zaļā krāsā, jo abām koda versijām ir jāzina, kas notiek ar darÄ«jumu.

    Draugi, man ir arÄ« neliela balva, ar ko jÅ«s pamudināt ā€” grāmata. Un man tas bÅ«tu jāpieŔķir par labāko jautājumu.

    In: - Sveiki. Paldies par ziņojumu. Jautājums ir Ŕāds. JÅ«s uzraugāt maksājumus, jÅ«s uzraugāt pakalpojumus, ar kuriem jÅ«s sazināties... Bet kā jÅ«s uzraugāt, lai cilvēks kaut kādā veidā nonāca jÅ«su maksājumu lapā, veica maksājumu un projekts viņam ieskaitÄ«ja naudu? Tas ir, kā jÅ«s pārraugāt, vai tirgotājs ir pieejams un ir pieņēmis jÅ«su atzvanÄ«Å”anu?

    EK: ā€“ ā€œTirgotājsā€ mums Å”ajā gadÄ«jumā ir tieÅ”i tāds pats ārējais pakalpojums kā maksājumu sistēma. Mēs uzraugām tirgotāja reakcijas ātrumu.

    Par datu bāzes Å”ifrÄ“Å”anu

    In: - Sveiki. Man ir nedaudz saistÄ«ts jautājums. Jums ir PCI DSS sensitÄ«vi dati. Es gribēju uzzināt, kā jÅ«s glabājat PAN rindās, uz kurām ir jāpārsÅ«ta? Vai jÅ«s izmantojat kādu Å”ifrÄ“Å”anu? Un tas noved pie otrā jautājuma: saskaņā ar PCI DSS ir nepiecieÅ”ams periodiski atkārtoti Å”ifrēt datubāzi izmaiņu gadÄ«jumā (administratoru atlaiÅ”ana utt.) - kas Å”ajā gadÄ«jumā notiek ar pieejamÄ«bu?

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    EK: - BrÄ«niŔķīgs jautājums! Pirmkārt, mēs neglabājam PAN rindās. Mums principā nav tiesÄ«bu nekur glabāt PAN skaidrā formā, tāpēc mēs izmantojam Ä«paÅ”u pakalpojumu (mēs to saucam par "Kademon") - tas ir pakalpojums, kas dara tikai vienu: tas saņem ziņojumu kā ievadi un nosÅ«ta izdod Å”ifrētu ziņojumu. Un mēs visu glabājam ar Å”o Å”ifrēto ziņojumu. AttiecÄ«gi mÅ«su atslēgas garums ir mazāks par kilobaitu, tāpēc tas ir nopietni un uzticami.

    In: ā€“ Vai jums tagad vajag 2 kilobaitus?

    EK: ā€“ Å Ä·iet, ka tieÅ”i vakar bija 256... Nu kur tad vēl?!

    AttiecÄ«gi Å”is ir pirmais. Un, otrkārt, esoÅ”ais risinājums atbalsta atkārtotas Å”ifrÄ“Å”anas procedÅ«ru - ir divi ā€œkeksā€ (atslēgas) pāri, kas dod ā€œklājusā€, kas Å”ifrē (atslēga ir atslēgas, dek ir atslēgu atvasinājumi, kas Å”ifrē) . Un, ja procedÅ«ra tiek uzsākta (tas notiek regulāri, no 3 mēneÅ”iem lÄ«dz Ā± dažiem), mēs lejupielādējam jaunu "kÅ«ku" pāri un atkārtoti Å”ifrējam datus. Mums ir atseviŔķi pakalpojumi, kas izņem visus datus un Å”ifrē tos jaunā veidā; Dati tiek glabāti blakus atslēgas identifikatoram, ar kuru tie ir Å”ifrēti. AttiecÄ«gi, tiklÄ«dz mēs Å”ifrējam datus ar jaunām atslēgām, mēs dzÄ“Å”am veco atslēgu.

    Dažkārt maksājumi ir jāveic manuāli...

    In: ā€“ Tas ir, ja par kādu darbÄ«bu ir saņemta atmaksa, vai jÅ«s joprojām atÅ”ifrēsit to ar veco atslēgu?

    EK: - Jā.

    In: ā€“ Tad vēl viens mazs jautājums. Ja notiek kāda veida kļūme, kritiens vai incidents, darÄ«jums ir jāveic manuāli. Ir tāda situācija.

    EK: - Jā, dažreiz.

    In: ā€“ No kurienes jÅ«s iegÅ«stat Å”os datus? Vai arÄ« jÅ«s pats dodaties uz Å”o noliktavu?

    EK: ā€“ Nē, nu, protams, mums ir sava veida back-office sistēma, kurā ir mÅ«su atbalsta saskarne. Ja mēs nezinām, kādā statusā ir darÄ«jums (piemēram, lÄ«dz maksājumu sistēma atbildēja ar taimautu), mēs nezinām a priori, tas ir, mēs pieŔķiram galÄ«go statusu tikai ar pilnu pārliecÄ«bu. Å ajā gadÄ«jumā darÄ«jumam pieŔķiram Ä«paÅ”u statusu manuālai apstrādei. No rÄ«ta, nākamajā dienā, tiklÄ«dz atbalsts saņem informāciju, ka Ŕādi un tādi darÄ«jumi paliek maksājumu sistēmā, viņi tos manuāli apstrādā Å”ajā interfeisā.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    In: ā€“ Man ir pāris jautājumi. Viens no tiem ir PCI DSS zonas turpinājums: kā reÄ£istrēt to ķēdi? Å is jautājums ir tāpēc, ka izstrādātājs varēja ierakstÄ«t žurnālos jebko! Otrais jautājums: kā ieviest labojumfailus? Viena iespēja ir izmantot rokturus datu bāzē, taču var bÅ«t bezmaksas labojumi ā€” kāda ir procedÅ«ra? Un treÅ”ais jautājums, iespējams, ir saistÄ«ts ar RTO, RPO. JÅ«su pieejamÄ«ba bija 99,97, gandrÄ«z četri deviņi, bet, kā es saprotu, jums ir otrs datu centrs, treÅ”ais datu centrs un piektais datu centrs... Kā jÅ«s tos sinhronizējat, pavairojat un viss pārējais?

    EK: - Sāksim ar pirmo. Vai pirmais jautājums bija par baļķiem? Kad mēs rakstām žurnālus, mums ir slānis, kas maskē visus sensitÄ«vos datus. Viņa skatās uz masku un papildu laukiem. AttiecÄ«gi mÅ«su žurnālos ir jau maskēti dati un PCI DSS ķēde. Å is ir viens no testÄ“Å”anas nodaļas pastāvÄ«gajiem uzdevumiem. Viņiem ir jāpārbauda katrs uzdevums, tostarp žurnāli, ko viņi raksta, un tas ir viens no parastajiem uzdevumiem koda pārskatÄ«Å”anas laikā, lai kontrolētu, vai izstrādātājs kaut ko nav pierakstÄ«jis. Turpmākās pārbaudes informācijas droŔības departaments veic regulāri apmēram reizi nedēļā: selektÄ«vi tiek ņemti pēdējās dienas žurnāli un tie tiek palaisti caur Ä«paÅ”u skeneri-analizatoru no testa serveriem, lai visu pārbaudÄ«tu.
    Par karstajiem labojumiem. Tas ir iekļauts mÅ«su izvietoÅ”anas noteikumos. Mums ir atseviŔķa klauzula par labojumfailiem. Mēs uzskatām, ka labojumfailus izvietojam visu diennakti, kad tas ir nepiecieÅ”ams. TiklÄ«dz versija ir samontēta, tiklÄ«dz tā ir palaista, tiklÄ«dz mums ir artefakts, mums ir sistēmas administrators, kurÅ” dežurē uz atbalsta dienesta zvanu, un viņŔ to izvieto brÄ«dÄ«, kad tas ir nepiecieÅ”ams.

    Apmēram "četri deviņi". Tagadējais skaitlis patieŔām ir sasniegts, un mēs to centāmies sasniegt citā datu centrā. Tagad mums ir otrs datu centrs, un mēs sākam izveidot marÅ”rutu starp tiem, un jautājums par starpdatu centru replikāciju patieŔām ir nenozÄ«mÄ«gs jautājums. Mēs mēģinājām to atrisināt vienā reizē, izmantojot dažādus lÄ«dzekļus: mēs mēģinājām izmantot to paÅ”u "Tarantula" - tas mums neizdevās, es jums tÅ«lÄ«t pateikÅ”u. Tāpēc mēs saņēmām "sens" pasÅ«tÄ«jumu manuāli. Faktiski katra mÅ«su sistēmas lietojumprogramma asinhroni veic nepiecieÅ”amo sinhronizāciju starp datu centriem.

    In: - Ja jums bija otrais, kāpēc jÅ«s nesaņēmāt treÅ”o? Jo nevienam vēl nav saŔķēluŔās smadzenes...

    EK: ā€“ Bet mums nav Ŕķelto smadzeņu. Tā kā katru lietojumprogrammu vada multimasters, mums nav nozÄ«mes, kurā centrā pieprasÄ«jums tika nosÅ«tÄ«ts. Mēs esam gatavi tam, ka gadÄ«jumā, ja kāds no mÅ«su datu centriem neizdosies (mēs paļaujamies uz to) un lietotāja pieprasÄ«juma vidÅ« pārslēdzas uz otro datu centru, mēs esam gatavi zaudēt Å”o lietotāju, patieŔām; bet tās bÅ«s vienÄ«bas, absolÅ«tās vienÄ«bas.

    In: - Labvakar. Paldies par ziņojumu. Jūs runājāt par savu atkļūdotāju, kas ražo dažus testa darījumus. Bet pastāsti par testa darījumiem! Cik dziļi tas iet?

    EK: ā€“ Tas iziet cauri visam komponenta ciklam. Komponentam nav atŔķirÄ«bas starp testa darÄ«jumu un ražoÅ”anas darÄ«jumu. Bet no loÄ£iskā viedokļa Å”is vienkārÅ”i ir atseviŔķs projekts sistēmā, kurā tiek palaisti tikai testa darÄ«jumi.

    In: -Kur tu to nogriezi? Šeit Core nosūtīja...

    EK: ā€“ Mēs esam aiz ā€œKorā€ Å”ajā gadÄ«jumā par testa darÄ«jumiem... Mums ir tāda lieta kā marÅ”rutÄ“Å”ana: ā€œKorā€ zina, uz kuru maksājumu sistēmu sÅ«tÄ«t - mēs sÅ«tām uz viltus maksājumu sistēmu, kas vienkārÅ”i dod http signālu un tas ir viss.

    In: ā€“ Sakiet, lÅ«dzu, vai jÅ«su pieteikums bija rakstÄ«ts vienā milzÄ«gā monolÄ«tā, vai arÄ« jÅ«s to sagriezāt kādos servisos vai pat mikropakalpojumos?

    EK: ā€“ Mums, protams, nav monolÄ«ta, mums ir uz servisu orientēta aplikācija. Mēs jokojam, ka mÅ«su serviss ir no monolÄ«tiem ā€“ tie tieŔām ir diezgan lieli. GrÅ«ti to nosaukt par mikropakalpojumiem, taču tie ir pakalpojumi, kuros darbojas sadalÄ«to iekārtu darbinieki.

    Ja pakalpojums serverī ir apdraudēts...

    In: ā€“ Tad man ir nākamais jautājums. Pat ja tas bÅ«tu monolÄ«ts, jÅ«s tik un tā teicāt, ka jums ir daudz Å”o tÅ«lÄ«tējo serveru, tie visi pamatā apstrādā datus, un jautājums ir Ŕāds: ā€œKāda tÅ«lÄ«tējā servera vai lietojumprogrammas kompromitÄ“Å”anas gadÄ«jumā jebkura atseviŔķa saite. , vai viņiem ir kāda veida piekļuves kontrole? KurÅ” no viņiem ko var darÄ«t? Ar ko man jāsazinās, lai iegÅ«tu kādu informāciju?

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    EK: - Jā noteikti. DroŔības prasÄ«bas ir diezgan nopietnas. Pirmkārt, mums ir atvērta datu kustÄ«ba, un ostas ir tikai tās, caur kurām mēs iepriekÅ” paredzam satiksmes kustÄ«bu. Ja komponents sazinās ar datu bāzi (teiksim, ar Muskul), izmantojot 5-4-3-2, tam bÅ«s atvērts tikai 5-4-3-2, un citas ostas un citi satiksmes virzieni nebÅ«s pieejami. Turklāt jums ir jāsaprot, ka mÅ«su ražoÅ”anā ir aptuveni 10 dažādas droŔības cilpas. Un pat tad, ja aplikācija bÅ«tu kaut kādā veidā apdraudēta, nedod Dievs, uzbrucējs nevarēs piekļūt servera pārvaldÄ«bas konsolei, jo tā ir cita tÄ«kla droŔības zona.

    In: ā€“ Un Å”ajā kontekstā man interesantāk ir tas, ka jums ir noteikti lÄ«gumi ar dienestiem - ko viņi var darÄ«t, ar kādām ā€œdarbÄ«bāmā€ viņi var sazināties savā starpā... Un normālā plÅ«smā daži konkrēti dienesti kādus pieprasa. rinda, ā€œdarbÄ«buā€ saraksts, no otras puses. Å Ä·iet, ka viņi parastā situācijā nevērÅ”as pie citiem, un viņiem ir citas atbildÄ«bas jomas. Ja kāds no tiem tiks apdraudēts, vai tas spēs traucēt Ŕī pakalpojuma ā€œdarbÄ«basā€?..

    EK: - Es saprotu. Ja normālā situācijā ar citu serveri komunikācija vispār bija atļauta, tad jā. Saskaņā ar SLA lÄ«gumu mēs neuzraugām, ka jums ir atļautas tikai pirmās 3 ā€œdarbÄ«basā€, un jums nav atļautas 4 ā€œdarbÄ«basā€. Tas mums laikam ir lieki, jo mums jau principā ir 4 lÄ«meņu aizsardzÄ«bas sistēma ķēdēm. Mēs labprātāk aizstāvam sevi ar kontÅ«rām, nevis iekÅ”puses lÄ«menÄ«.

    Kā darbojas Visa, MasterCard un Sberbank

    In: ā€“ Es vēlos precizēt jautājumu par lietotāja pārslēgÅ”anu no viena datu centra uz citu. Cik es zinu, Visa un MasterCard darbojas, izmantojot bināro sinhrono protokolu 8583, un tur ir maisÄ«jumi. Un es gribēju zināt, tagad mēs domājam pāreju - vai tas ir tieÅ”i "Visa" un "MasterCard" vai pirms maksājumu sistēmām, pirms apstrādes?

    EK: - Tas ir pirms maisījumiem. Mūsu maisījumi atrodas tajā paŔā datu centrā.

    In: ā€“ Aptuveni runājot, vai jums ir viens savienojuma punkts?

    EK: ā€“ ā€œVisaā€ un ā€œMasterCardā€ ā€“ jā. VienkārÅ”i tāpēc, ka Visa un MasterCard prasa diezgan nopietnas investÄ«cijas infrastruktÅ«rā, lai noslēgtu atseviŔķus lÄ«gumus, piemēram, otrā miksu pāra iegÅ«Å”anai. Tie ir rezervēti viena datu centra ietvaros, bet, ja, nedod Dievs, mÅ«su datu centrs, kurā ir maisÄ«jumi pieslēgÅ”anai Visa un MasterCard, tad mums bÅ«s zudis savienojums ar Visa un MasterCard...

    In: ā€“ Kā tos var rezervēt? Zinu, ka Visa principā pieļauj tikai vienu pieslēgumu!

    EK: ā€“ Viņi paÅ”i piegādā aprÄ«kojumu. Jebkurā gadÄ«jumā mēs saņēmām aprÄ«kojumu, kas ir pilnÄ«bā lieks iekŔā.

    In: ā€“ Tātad stends ir no viņu Connects Orange?..

    EK: - Jā.

    In: ā€“ Bet kā ar Å”o gadÄ«jumu: ja jÅ«su datu centrs pazÅ«d, kā jÅ«s varat turpināt to izmantot? Vai arÄ« satiksme vienkārÅ”i apstājas?

    EK: - Nē. Å ajā gadÄ«jumā mēs vienkārÅ”i pārslēgsim trafiku uz citu kanālu, kas, protams, mums bÅ«s dārgāks un mÅ«su klientiem dārgāks. Bet satiksme nenotiks caur mÅ«su tieÅ”o savienojumu ar Visa, MasterCard, bet gan caur nosacÄ«to Sberbank (ļoti pārspÄ«lēti).

    Es ļoti atvainojos, ja aizvainoju Sberbank darbiniekus. Bet saskaņā ar mūsu statistiku starp Krievijas bankām Sberbank krīt visbiežāk. Nepaiet mēnesis, lai Sberbankā kaut kas nenokristu.

    HighLoad++, Jevgeņijs Kuzovļevs (EcommPay IT): ko darīt, ja minūte dīkstāves maksā 100000 XNUMX USD

    Dažas reklāmas šŸ™‚

    Paldies, ka palikāt kopā ar mums. Vai jums patīk mūsu raksti? Vai vēlaties redzēt interesantāku saturu? Atbalsti mūs, pasūtot vai iesakot draugiem, mākoņa VPS izstrādātājiem no 4.99 USD, unikāls sākuma līmeņa serveru analogs, ko mēs jums izgudrojām: Visa patiesība par VPS (KVM) E5-2697 v3 (6 kodoli) 10GB DDR4 480GB SSD 1Gbps no 19$ vai kā koplietot serveri? (pieejams ar RAID1 un RAID10, līdz 24 kodoliem un līdz 40 GB DDR4).

    Dell R730xd 2x lētāk Equinix Tier IV datu centrā Amsterdamā? Tikai Å”eit 2x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV no 199$ NÄ«derlandē! Dell R420 ā€” 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gbps 100 TB ā€” no 99 USD! LasÄ«t par Kā izveidot infrastruktÅ«ras uzņēmumu klase ar Dell R730xd E5-2650 v4 serveru izmantoÅ”anu 9000 eiro par santÄ«mu?

Avots: www.habr.com

Pievieno komentāru