HighLoad++, Evgeniy Kuzovlev (EcommPay IT): dema ku deqeyek dorvegerê 100000 $ lêçû, çi bike

Her kes li ser pêvajoyên pêşkeftin û ceribandinê, perwerdekirina karmendan, zêdekirina motîvasyonê diaxive, lê ev pêvajo têrê nakin dema ku deqeyek domdariya karûbarê dravê pir mezin lê dike. Dema ku hûn di bin SLA-ya hişk de danûstendinên darayî dikin çi bikin? Meriv çawa pêbawerî û tolerasyona xeletiya pergalên xwe zêde dike, pêşveçûn û ceribandinê ji hevkêşeyê derdixe?

Konferansa paşîn a HighLoad++ dê di 6 û 7ê Avrêl, 2020 de li St. Details û bilêtên ji bo link. Mijdar 9, 18:00. HighLoad ++ Moskow 2018, Delhi + salona Kolkata. Tez û pêşkêşkirin.

Evgeniy Kuzovlev (li vir - EC): - Hevalno, silav! Navê min Kuzovlev Evgeniy e. Ez ji pargîdaniya EcommPay me, dabeşek taybetî EcommPay IT e, beşa IT ya koma pargîdaniyan. Û îro em ê li ser demên daketinê bipeyivin - li ser ka meriv çawa ji wan dûr dikeve, ka meriv çawa encamên wan kêm bike heke nekare ji holê rabe. Di mijarê de wiha hatiye gotin: “Dema ku deqeyek bêhnvedanê 100 hezar dolar be, emê çi bikin?” Li pêş çavan, hejmarên me berawirdî ne.

EcommPay IT çi dike?

Em kî ne? Çima ez li vir li ber we radiwestim? Çima mafê min heye ku li vir tiştekî ji te re bibêjim? Û em ê li vir bi berfirehî li ser çi biaxivin?

Koma pargîdaniyên EcommPay kirrûbirek navneteweyî ye. Em dravdanan li çaraliyê cîhanê - li Rusya, Ewropa, Asyaya Başûr-rojhilatê (Li seranserê Cîhanê) pêvajoyê dikin. 9 ofîsên me hene, bi tevahî 500 xebatkarên me hene û bi qasî nîvê wan pisporên IT-ê ne. Her tiştê ku em dikin, her tiştê ku em jê pere qezenç dikin, me bi xwe kiriye.

Me hemî hilberên xwe nivîsand (û gelek ji wan jî hene - di rêza hilberên mezin ên IT-ê de em bi qasî 16 pêkhateyên cihêreng hene) xwe; Em bi xwe dinivîsin, xwe pêş dixin. Û di vê gavê de em rojane bi qasî mîlyon danûstendinan pêk tînin (bi mîlyonan belkî awayê rast e ku meriv wê bêje). Em pargîdaniyek pir ciwan in - em tenê şeş ​​salî ne.

6 sal berê gava ku xort bi karsaziyê re hatin, destpêkek wusa bû. Ew bi fikrekê bûn yek (ji bilî ramanê tiştek din tune bû), û em reviyan. Weke her destpêkek, em jî zûtir bezîn... Ji bo me lez û bez ji kalîteyê girîngtir bû.

Di demekê de em sekinîn: me fêm kir ku êdî em nikarin bi rengekî bi wê lezê û bi wê kalîteyê bijîn û hewce bû ku em pêşî li ser kalîteyê bisekinin. Di vê gavê de, me biryar da ku em platformek nû binivîsin ku dê rast, pîvan û pêbawer be. Wan dest bi nivîsandina vê platformê kir (wan dest bi veberhênanê kirin, pêşdebirina pêşkeftinê, ceribandinê), lê di demekê de wan fêm kir ku pêşkeftin û ceribandin nehiştin ku em bigihîjin astek nû ya kalîteya karûbarê.

Hûn hilberek nû çêdikin, hûn wê dixin nav hilberînê, lê dîsa jî tiştek dê li cîhek xelet derkeve. Û îro em ê biaxivin ka meriv çawa bigihîje astek nû ya kalîteyê (me çawa kir, li ser ezmûna xwe), pêşveçûn û ceribandinê ji hevkêşeyê derxîne; em ê li ser tiştê ku ji operasyonê re peyda dibe bipeyivin - çi operasyon dikare bixwe bike, ew dikare çi pêşkêşî ceribandinê bike da ku bandorê li kalîteyê bike.

Downtimes. Fermanên operasyonê.

Her gav kevirê bingehîn, ya ku em ê îro bi rastî li ser bipeyivin dema daketinê ye. Gotinek tirsnak. Ger demsala me hebe, her tişt ji bo me xirab e. Em direvin ku wê bilind bikin, admîn serverê digirin - Xwedê neke ew nekeve, wekî ku di wê stranê de dibêjin. Ya ku em ê îro li ser biaxivin ev e.

Dema me dest bi guhertina nêzîkatiyên xwe kir, me 4 ferman ava kirin. Min ew li ser slaytan pêşkêş kirin:

Ev ferman pir hêsan in:

• Bi lez pirsgirêkê nas bike.
• Hê zûtir jê xilas bibin.
• Alîkariya fêmkirina sedemê bikin (paşê, ji bo pêşdebiran).
• Û nêzîkatiyên standard bikin.

Ez bala we bikşînim ser xala 2. Em ji pirsgirêkê xilas dibin, çareser nakin. Biryara duyemîn e. Ji bo me, ya bingehîn ev e ku bikarhêner ji vê pirsgirêkê parastî ye. Ew ê di hin hawîrdorek veqetandî de hebe, lê têkiliya vê hawîrdorê dê pê re nebe. Bi rastî, em ê di van çar komên pirsgirêkan re derbas bibin (hin bi hûrgulî, hin bi hûrgulî), ez ê ji we re vebêjim ka em çi bikar tînin, çi ezmûna me ya têkildar di çareseriyê de heye.

Çareserkirina pirsgirêkan: Kengî çêdibin û li ser wan çi bikin?

Lê em ê ji rêzê dest pê bikin, em ê bi xala hejmar 2 dest pê bikin - meriv çawa zû ji pirsgirêkê xilas bibe? Pirsgirêkek heye - divê em wê çareser bikin. "Divê em ji bo vê yekê çi bikin?" - Pirsa sereke. Û gava ku me dest pê kir fikirîn ka meriv çawa pirsgirêkê çareser bike, me ji xwe re hin hewcedariyên ku divê çareserkirin bişopînin pêşve xistin.

Ji bo formulekirina van daxwazan, me biryar da ku em vê pirsê ji xwe bikin: "Kengî pirsgirêkên me hene"? Û pirsgirêk, wekî ku derket holê, di çar rewşan de pêk tê:

• têkçûna hardware.
• Xizmetên derve têk çûn.
• Guhertina guhertoya nermalavê (eynî sazkirin).
• Mezinbûna barkirina teqemenî.

Em ê li ser her du yekem neaxivin. Nerazîbûnek hardware bi hêsanî dikare were çareser kirin: divê hûn her tiştî dubare bikin. Ger ev dîsk in, pêdivî ye ku dîsk di RAID-ê de werin berhev kirin; heke ev serverek be, divê server were dubare kirin; heke we binesaziyek torê hebe, divê hûn kopiyek duyemîn a binesaziya torê peyda bikin, ango hûn wê bigirin û wê dubare bikin. Û heke tiştek têk nebe, hûn diçin hêza rezervê. Zehmet e ku meriv li vir tiştek bêtir bêje.

Ya duyemîn jî têkçûna xizmetên derve ye. Ji bo piran, pergal ne pirsgirêkek e, lê ne ji me re. Ji ber ku em dravdanê pêvajoyê dikin, em berhevkarek in ku di navbera bikarhêner (ku daneyên qerta xwe dike) û bank, pergalên dravdanê (Visa, MasterCard, Mira, hwd.) de radiweste. Karûbarên me yên derveyî (pergalên dravdanê, bank) meyldar dibin ku têk biçin. Ne em û ne jî hûn (eger karûbarên we yên weha hebin) nikarin vê yekê bandor bikin.

Wê demê çi bikin? Li vir du vebijark hene. Pêşîn, heke hûn dikarin, divê hûn vê karûbarê bi rengek dubare bikin. Mînakî, heke em karibin, em seyrûseferekê ji karûbarek din vediguhezînin: Mînakî, kartên bi Sberbank ve hatin hilanîn, Sberbank pirsgirêk heye - em seyrûseferê [bi şert] vediguhezînin Raiffeisen. Tişta duyemîn ku em dikarin bikin ev e ku em pir zû têkçûna karûbarên derveyî bibînin, û ji ber vê yekê em ê di beşa paşîn a raporê de li ser leza bersivê biaxivin.

Bi rastî, ji van çaran, em dikarin bi taybetî bandorê li guhertina guhertoyên nermalavê bikin - çalakiyan bikin ku dê di çarçoweya bicîhkirinê de û di çarçoweya mezinbûna teqemenî ya barkirinê de bibe sedema başbûna rewşê. Ya rastî, me ev kir. Li vir, dîsa, notek piçûk ...

Ji van çar pirsgirêkan, heke we ewr hebe gelek tavilê têne çareser kirin. Ger hûn di nav Microsoft Azhur, ewrên Ozone de ne, an ewrên me, ji Yandex an Mail-ê bikar tînin, wê hingê bi kêmanî xeletiyek hardware dibe pirsgirêka wan û her tişt tavilê ji we re di çarçoweya xeletiyek hardware de baş dibe.

Em pargîdaniyek hindik nenas in. Li vir her kes li ser "Kubernets" diaxive, li ser ewran - ne "Kubernets" ne jî ewr hene. Lê di gelek navendên daneyê de rafikên me yên hardware hene, û em neçar in ku li ser vê hardware bijîn, em neçar in ku ji her tiştî berpirsiyar bin. Lewma em ê di vê çarçoveyê de biaxivin. Ji ber vê yekê, li ser pirsgirêkan. Herdu yên pêşîn ji nav kevokan hatin derxistin.

Guhertina guhertoya nermalavê. Bases

Pêşdebirên me gihêştina hilberînê tune. Çima wisa ye? Tenê ew e ku em PCI DSS pejirandî ne, û pêşdebirên me bi tenê ne xwediyê maf in ku bikevin "hilberê". Ew e, heya. Qet. Ji ber vê yekê, berpirsiyariya pêşkeftinê tam di wê gavê de bi dawî dibe dema ku pêşkeftinê ji bo serbestberdanê çêdike.

Bingeha meya duyemîn a ku di destê me de ye, ku di heman demê de pir alîkariya me dike, nebûna zanîna bêhempa ya bêhempa ye. Ez hêvî dikim ji bo we jî wisa be. Ji ber ku eger ev nebe, dê pirsgirêkên we hebin. Dema ku ev zanîna bêhempa, bêbelge di wextê rast de li cîhê rast nebe, dê pirsgirêk derkevin holê. Ka em bibêjin we kesek heye ku dizane ka meriv çawa pêkhateyek taybetî bicîh tîne - ew kes ne li wir e, ew li betlaneyê ye an nexweş e - ew e, pirsgirêkên we hene.

Û bingeha sêyemîn ku em hatine. Em bi êş, xwîn, hêstiran gihîştin wê - em gihîştin wê encamê ku her avahiyek me xeletî dihewîne, her çend ew bê xeletî be jî. Me ev ji bo xwe biryar da: gava ku em tiştek bi cîh dikin, gava ku em tiştek hildiberînin hilberînê, avahiyek me ya bi xeletî heye. Me daxwazên ku divê pergala me têr bike ava kirine.

Pêdiviyên ji bo guhertina guhertoya nermalavê

Sê hewcedarî hene:

• Divê em tavilê bişaftinê paşve bixin.
• Divê em bandora veqetandina neserkeftî kêm bikin.
• Û divê em karibin bi lez di paralel de bi cih bikin.
  Tam di wê rêzê de! Çima? Ji ber ku, berî her tiştî, dema danîna guhertoyek nû, bilez ne girîng e, lê ji we re girîng e, ger tiştek xelet derkeve, zû paşde bizivirin û bandorek hindiktirîn hebe. Lê heke di hilberînê de komek guhertoyên we hebin, ji bo ku derkeve holê ku xeletiyek heye (ji şîn, veqetandin tune bû, lê xeletiyek heye) - leza belavkirina paşîn ji we re girîng e. Ji bo ku van daxwazan bi cih bînin me çi kiriye? Me serî li rêbaza jêrîn da:

  
  
  Ew pir baş tê zanîn, me çu carî ew îcad nekiriye - ev pêvekirina Şîn/Kesk e. Ew çi ye? Pêdivî ye ku ji bo her komek serverên ku serîlêdanên we li ser hatine saz kirin kopiyek we hebe. Kopî "germ" e: li ser wê seyrûsefer tune, lê di her kêliyê de ev seyrûsefer dikare ji vê kopê re were şandin. Di vê kopî de guhertoya berê heye. Û di dema bicîhkirinê de, hûn kodê li kopiyek neçalak derdixin. Dûv re hûn beşek trafîkê (an hemî) veguherînin guhertoya nû. Bi vî rengî, ji bo ku hûn herikîna seyrûseferê ji guhertoya kevn berbi ya nû ve biguhezînin, hûn hewce ne ku tenê çalakiyek bikin: hûn hewce ne ku balanserê li jorê biguhezînin, rêgezê biguhezînin - ji yek jorîn berbi yekî din. Ev pir hêsan e û pirsgirêka guheztina bilez û paşveçûna bilez çareser dike.

  Li vir çareseriya pirsa duyemîn kêmkirin e: hûn dikarin tenê beşek ji seyrûsefera xwe bişînin xetek nû, ji rêzek bi kodek nû re (bihêlin, wek nimûne, 2%). Û ev 2% ne 100% in! Ger we 100% seyrûsefera xwe ji ber veqetandinek neserkeftî winda kir, ew tirsnak e; heke we 2% seyrûsefera xwe winda kir, ew ne xweş e, lê ne tirsnak e. Digel vê yekê, bikarhêner bi îhtîmalek mezin dê vê yekê jî ferq nekin, ji ber ku di hin rewşan de (ne di hemîyan de) heman bikarhêner, bi pêlkirina F5-ê, dê were guheztin guhertoyek din a xebatê.

  Şîn/Kesk belav kirin. Routing

  Lêbelê, ne her tişt ew qas hêsan e "Dabeşandina Şîn/Kesk"... Hemî pêkhateyên me dikarin li sê koman werin dabeş kirin:

  • ev pêşiyê ye (rûpelên dravdanê yên ku xerîdarên me dibînin);
  • core processing;
  • adapter ji bo xebitandina pergalên dravdanê (banqe, MasterCard, Visa...).

  Û li vir nuwazek heye - nuwaze di rêça di navbera rêzan de ye. Ger hûn tenê 100% seyrûseferê biguhezînin, hûn van pirsgirêkan nînin. Lê heke hûn dixwazin %2 biguherînin, hûn dest bi pirsan dikin: "Wê çawa bikin?" Tiştê herî hêsan rasterast pêş e: hûn dikarin Round Robin li nginx bi bijartina rasthatî saz bikin, û we %2 li çepê, 98% li rastê heye. Lê ev her gav ne guncaw e.

  Mînakî, di doza me de, bikarhênerek bi zêdetirî daxwazek bi pergalê re têkilî dike. Ev normal e: 2, 3, 4, 5 daxwaz - dibe ku pergalên we yek bin. Û heke ji we re girîng e ku hemî daxwazên bikarhêner werin heman rêza ku daxwaza yekem tê de, an (xala duyemîn) hemî daxwazên bikarhêner piştî veguheztinê werin rêza nû (wî dikaribû berê dest bi kar bikira pergal, berî veguheztinê), - wê hingê ev dabeşkirina rasthatî ji we re ne maqûl e. Piştre vebijarkên jêrîn hene:

  
  
  Vebijarka yekem, ya herî hêsan, li ser pîvanên bingehîn ên xerîdar (IP Hash) ye. IP-ya we heye, û hûn wê ji rastê ber bi çepê ve bi navnîşana IP-yê dabeş dikin. Dûv re doza duyemîn a ku min diyar kir dê ji we re bixebite, gava ku vekêşandin çêbû, bikarhêner berê dikaribû bi pergala we re dest bi xebatê bike, û ji gava veqetandinê ve hemî daxwaz dê biçin xetek nû (bi heman rengî, bêje).

  Ger ji ber hin sedeman ev ne li gorî we ye û pêdivî ye ku hûn daxwazan bişînin xeta ku daxwaza destpêkê, destpêkê ya bikarhêner lê hat, wê hingê du vebijarkên we hene ...
  Vebijarka yekem: hûn dikarin nginx+ bikirin. Mekanîzmayek danişînên Sticky heye, ku, li ser daxwaza destpêkê ya bikarhêner, danişînek ji bikarhênerê re vedigire û wê bi yek an jor ve girêdide. Hemî daxwazên bikarhêner ên paşîn ên di heyama danişînê de dê ji heman jorîn a ku danişîn lê hatî şandin were şandin.

  Ev li me nedihat ji ber ku me berê nginx bi rêkûpêk hebû. Veguheztina nginx+ ne ew e ku ew biha ye, tenê ew ji bo me hinekî bi êş bû û ne pir rast bû. Mînakî, "Sticks Sessions", ji bo me nexebitî ji ber vê sedemê hêsan ku "Sticks Sessions" rê nade rêvekirina li ser bingeha "Yan-an". Li wir hûn dikarin diyar bikin ku em "Sticks Sessions" çi dikin, mînakî, bi navnîşana IP-yê an bi navnîşana IP-yê û cookie-yan an ji hêla parameterê ve, lê "Yan-an" li wir tevlihevtir e.

  Ji ber vê yekê, em hatin vebijarka çaremîn. Me nginx li ser steroîdan girt (ev vekirî ye) - ev heman nginx e, ku ji bilî vê jî tevlêkirina nivîsarên paşîn piştgirî dike. Hûn dikarin skrîptek paşîn binivîsin, wê bidin "bêhnvedanek vekirî", û dema ku daxwaza bikarhêner were ev skrîpta paşîn dê were darve kirin.

  Û me bi rastî jî skrîpteke wiha nivîsî, xwe "openresti" danî û di vê senaryoyê de em 6 pîvanên cihêreng bi hevgirtina "An" rêz dikin. Bi hebûna yek an pîvanek din ve girêdayî, em dizanin ku bikarhêner hatî rûpelek an rûpelek din, rêzek an rêzek din.

  Şîn/Kesk belav kirin. Awantaj û dezawantajên

  Bê guman, belkî gengaz bû ku meriv wê hinekî hêsantir bike (heman "Rûniştinên Asteng" bikar bînin), lê me jî nuwazeyek wusa heye ku ne tenê bikarhêner di çarçoweya yek pêvajoyek yek danûstendinê de bi me re têkilî daynin ... Lê pergalên dravdanê jî bi me re têkilî daynin: Piştî ku em danûstendinê bişopînin (bi şandina daxwazek ji pergala dravdanê re), em sarbûnek distînin.
  Werin em bibêjin, heke di hundurê çerxa xwe de em dikarin navnîşana IP-ya bikarhêner di hemî daxwazan de bişopînin û bikarhêneran li ser bingeha navnîşana IP-yê dabeş bikin, wê hingê em ê ji heman "Visa" re nebêjin: "Gelo, em pargîdaniyek wusa retro ne, em xuya dikin. ji bo navneteweyî be (li ser malperê û li Rûsyayê)... Ji kerema xwe navnîşana IP-ya bikarhêner di qadeke zêde de ji me re peyda bikin, protokola we standardîze ye”! Diyar e ku ew ê li hev nekin.

  
  
  Ji ber vê yekê, ev ji bo me nexebitî - me vekirî ye. Li gorî vê yekê, bi rêvekirinê re me tiştek weha wergirt:

  Li gorî vê yekê, Damezrandina Şîn / Kesk xwedî avantajên ku min behs kir û dezawantajên wan hene.

  Du kêmasî:

  • hûn hewce ne ku hûn bi rêvekirinê re aciz bibin;
  • kêmasiya sereke ya duyemîn lêçûn e.

  Ji we re du caran bêtir server hewce ye, hûn du caran bêtir çavkaniyên xebitandinê hewce ne, hûn hewce ne ku hûn du caran bêtir hewl bidin ku hûn vê zozanê tevde biparêzin.

  Bi awayê, di nav avantajan de tiştek din heye ku min berê behs nekiriye: di bûyera mezinbûna barkirinê de rezervek we heye. Ger di barkirinê de mezinbûnek weya teqemenî hebe, hejmareke we ya bikarhêneran heye, wê hingê hûn tenê rêza duyemîn di nav belavkirina 50 û 50 de vedihewînin - û hûn tavilê di koma xwe de serverên x2 hene heya ku hûn pirsgirêka hebûna bêtir serveran çareser bikin.

  Meriv çawa birêkûpêkek bilez çêdike?

  Me li ser çawa çareserkirina pirsgirêka kêmkirin û paşvegera bilez peyivî, lê pirs dimîne: "Çawa zû were bicîh kirin?"

  
  
  Li vir kurt û hêsan e.

  • Pêdivî ye ku hûn pergalek CD-yê (Radestkirina Berdewam) hebe - hûn nikarin bêyî wê bijîn. Ger serverek we hebe, hûn dikarin bi destan saz bikin. Nêzîkî hezar û nîv server û hezar û nîv destikên me hene, bê guman - em dikarin dezgehek bi mezinahiya vê jûreyê tenê ji bo bicîh bikin.
  • Pêvekirin divê paralel be. Ger bicîhkirina we rêzdar be, wê hingê her tişt xirab e. Pêşkêşkarek normal e, hûn ê tevahiya rojê yek û nîv hezar serveran bicîh bikin.
  • Dîsa, ji bo lezkirinê, ev belkî êdî ne hewce ye. Di dema sazkirinê de, proje bi gelemperî tête çêkirin. Projeyek we ya webê heye, beşek pêş-endê heye (hûn li wir pakêtek malperê dikin, hûn npm berhev dikin - tiştek wusa), û ev pêvajo, di prensîbê de, demek kurt e - 5 hûrdem, lê ev 5 hûrdem dikarin krîtîk bin. Ji ber vê yekê, mînakî, em wiya nakin: me van 5 hûrdeman rakirin, em huneran bi cih dikin.

    Artifact çi ye? Artifact avahiyek berhevkirî ye ku tê de hemî beşên kombûnê berê hatine qedandin. Em vê berhemê di depoya hunerê de hilînin. Demekê me du depoyên weha bikar anîn - ew Nexus bû û naha jFrog Artifactory) Me di destpêkê de "Nexus" bikar anî ji ber ku me dest bi pratîkkirina vê nêzîkatiyê di sepanên java de kir (ew li gorî wê xweş bû). Dûv re hin serîlêdanên ku bi PHP-ê hatine nivîsandin danîne wir; û "Nexus" êdî ne guncaw bû, û ji ber vê yekê me jFrog Artefactory hilbijart, ku dikare hema hema her tiştî hunerî bike. Em tewra gihîştine wê nuqteyê ku di vê depoya hunerî de em pakêtên xwe yên binary ên ku em ji bo pêşkêşkeran berhev dikin hilînin.

  Mezinbûna barkirina teqemenî

  Me li ser guhertina guhertoya nermalavê axivî. Tiştê din ku me heye zêdebûnek teqemenî ya barkirinê ye. Li vir, belkî mebesta min ji mezinbûna teqemenî ya barkirinê ne tiştek rast e ...

  Me pergalek nû nivîsand - ew karûbar e, moda, xweşik, karker li her derê, li her derê rêz, li her derê asynkronî ye. Û di pergalên weha de, dane dikarin di nav herikên cûda de biherikin. Ji bo danûstendina yekem, karkerê 1, 3, 10 dikare were bikar anîn, ji bo danûstendina duyemîn - 2, 4, 5. Û îro, em bêjin, sibehê we herikîna daneyê heye ku sê karkerên pêşîn bikar tîne, û êvarê ew bi rengek berbiçav diguhezîne, û her tişt sê karkerên din bikar tîne.

  Û li vir derdikeve holê ku hûn hewce ne ku bi rengekî karkeran mezin bikin, hûn hewce ne ku bi rengek karûbarên xwe pîvandin, lê di heman demê de pêşî li bloka çavkaniyê bigirin.

  
  
  Me daxwazên xwe diyar kirine. Van hewcedariyên pir hêsan in: ku vedîtina karûbarê, parameterîzasyon hebe - her tişt standard e ji bo avakirina pergalên wusa berbelav, ji bilî yek xalê - kêmbûna çavkaniyê. Me got ku em ne amade ne ku çavkaniyan amortîze bikin da ku server hewayê germ bikin. Me "Konsolos" girt, me "Nomad" ku xebatkarên me bi rê ve dibe.

  Çima ev ji bo me pirsgirêk e? Ka em piçekî paşde vegerin. Niha li pişt me derdora 70 pergalên dravdanê hene. Serê sibê, seyrûsefer di Sberbank re derbas dibe, dûv re Sberbank ket, mînakî, û em wê diguhezînin pergalek dravdanê ya din. Beriya Sberbankê 100 xebatkarên me hebûn, û piştî wê divê em ji bo pergalek din a dravdanê 100 karkeran bi tundî zêde bikin. Û tê xwestin ku ev hemû bêyî beşdariya mirovan pêk werin. Ji ber ku ger beşdariya mirovî hebe, divê endezyarek 24/7 li wir rûne, ku tenê vî karî bike, ji ber ku têkçûnên weha, gava 70 pergal li pişt we bin, bi rêkûpêk çêdibin.

  Ji ber vê yekê, me li Nomad, ku IP-ya vekirî ye, mêze kir û tiştê xwe nivîsand, Scale-Nomad - ScaleNo, ku bi qasî jêrîn dike: ew mezinbûna dorê dişopîne û li gorî dînamîkê hejmara karkeran kêm dike an zêde dike. ji rêzê. Dema ku me ew kir, me fikirîn: "Dibe ku em jêdera wê vekin?" Dûv re wan li wê nêrî - ew bi qasî du kopîkan sade bû.

  Heya nuha me ew jêder venekiriye, lê heke ji nişka ve piştî raporê, piştî ku hûn fêm bikin ku hûn hewcedariyek wusa ne, hewcedariya we jê heye, têkiliyên min di slayta paşîn de ne - ji kerema xwe ji min re binivîsin. Ger herî kêm 3-5 kes hebin emê sponser bikin.

  
  
  Çawa dixebite? Ka em lê binêrin! Li pêşiya me dinihêre: li milê çepê perçeyek çavdêriya me heye: ev yek rêz e, li jor dema pêvajoyên bûyerê ye, di navîn de hejmara danûstendinan e, li jêr jî hejmara karkeran e.

  Ger hûn lê binêrin, di vê wêneyê de xeletiyek heye. Li ser nexşeya jorîn, yek ji nexşeyan di 45 çirkeyan de têk çû - yek ji pergalên dravdanê daket. Di cih de, seyrûsefer di 2 hûrdeman de hat girtin û rêz dest pê kir li ser pergalek dravdanê ya din, ku li wir karker tune bûn (me çavkanî bikar neanîn - berevajî vê, me çavkaniyê rast derxistin). Me nexwest ku germ bikin - hejmareke hindik bû, bi qasî 5-10 karker, lê wan nikarîbûn bi ser bikevin.

  Grafika paşîn "hump" nîşan dide, ku tenê tê vê wateyê ku "Skaleno" ev mîqdar du qat kir. Û dûv re, gava ku graf hinekî daket, wî ew hinekî kêm kir - hejmara karkeran bixweber hate guheztin. Ev tişt çawa dixebite. Me li ser xala jimare 2-ê peyivî - "Çawa meriv zû ji sedeman xilas dibe."

  Şopandina. Meriv çawa zû pirsgirêkê nas dike?

  Naha xala yekem ev e "Çawa meriv zû pirsgirêkê nas dike?" Monitoring! Divê em hin tiştan zû fam bikin. Çi tiştên ku divê em zû fêm bikin?

  
  
  Sê tişt!

  • Divê em bi lez performansa çavkaniyên xwe fam bikin û fam bikin.
  • Divê em zû têkçûn fam bikin û performansa pergalên ku ji me re derveyî ne bişopînin.
  • Xala sêyemîn tespîtkirina xeletiyên mantiqî ye. Ev gava ku pergal ji we re dixebite, her tişt li gorî hemî nîşanan normal e, lê tiştek xelet diçe.

  Dibe ku ez ê li vir tiştek wusa xweş ji we re nebêjim. Ez ê bibim Captain Obvious. Em li tiştên ku li sûkê hebûn geriyan. Em xwedî "zoo fun". Ev cureyê zozanên ku em niha hene:

  
  
  Em Zabbix bikar tînin ji bo şopandina hardware, ji bo şopandina nîşaneyên sereke yên pêşkêşkeran. Em ji bo databasan Okmeter bikar tînin. Em "Grafana" û "Prometheus" ji bo hemî nîşangirên din ên ku bi du yekeman re nagirin bikar tînin, hin bi "Grafana" û "Prometheus", û hin bi "Grafana" bi "Influx" û Telegraf.

  Salek berê me xwest ku New Relic bikar bînin. Tiştek xweş, ew dikare her tiştî bike. Lê bi qasî ku dikare her tiştî bike, ew qas biha ye. Dema ku em gihîştin 1,5 hezar servers, firoşkarek hat ba me û got: "Werin em ji bo sala pêş peymanek bikin." Me li bihayê nihêrî û got na, em ê wiya nekin. Naha em dev ji New Relic berdidin, nêzî 15 serverên me di bin çavdêriya New Relic de mane. Biha derket holê ku bi tevahî hovane ye.

  Û yek amûrek heye ku me bi xwe bicîh kiriye - ev Debugger e. Di destpêkê de me jê re digot "Bagger", lê paşê mamosteyek îngilîzî derbas bû, bi hovîtî keniya û navê wê kir "Debagger". Ew çi ye? Ev amûrek e ku, bi rastî, di 15-30 saniyeyan de li ser her pêkhateyê, mîna "qutiya reş" a pergalê, ceribandinan li ser performansa giştî ya pêkhateyê dimeşîne.

  Mînakî, heke rûpelek derveyî (rûpelek dravdanê) hebe, ew bi hêsanî wê vedike û li wê yekê dinêre ku divê ew çawa xuya bike. Ger ev pêvajo be, ew ceribandinek "danûstandin" dişîne û piştrast dike ku ev "danûstandin" tê. Ger ev pêwendiyek bi pergalên dravdanê re be, em li gorî vê daxwazek ceribandinê diavêjin, li ku derê em dikarin, û dibînin ku her tişt bi me re baş e.

  Ji bo çavdêriyê kîjan nîşanan girîng in?

  Em bi giranî çi dişopînin? Kîjan nîşanan ji bo me girîng in?

  
  

  • Dema bersivê / RPS li eniyan nîşanek pir girîng e. Ew di cih de bersivê dide ku tiştek bi we re xelet e.
  • Hejmara peyamên pêvajoyî di hemî rêzan de.
  • Hejmara karkeran.
  • Metrîkên rastbûna bingehîn.

  Xala dawîn metrîka "karsaziyê", "karsaziyê" ye. Heke hûn dixwazin heman tiştî bişopînin, hûn hewce ne ku yek an du metrîkên ku ji bo we nîşanên sereke ne diyar bikin. Metrîka me berbelav e (ev rêjeya hejmara danûstendinên serketî bi tevheviya danûstendinê re ye). Ger tiştek di navberek 5-10-15 hûrdeman de tê de biguhezîne, ev tê vê wateyê ku pirsgirêkên me hene (heke ew radîkal biguhere).

  Ya ku ew ji me re xuya dike mînakek yek ji panelên me ye:

  
  
  Li milê çepê 6 grafîk hene, ev li gorî rêzan e - hejmara karkeran û hejmara peyamên di rêzan de. Li milê rastê - RPS, RTS. Li jêr heman metrîka "karsaziyê" heye. Û di metrîka "karsaziyê" de em tavilê dikarin bibînin ku di du grafikên navîn de tiştek xelet derket ... Ev tenê pergalek din e ku li pişt me radiweste ku ketiye.

  Tişta duyemîn ku divê em bikin ev bû ku çavdêriya hilweşîna pergalên dravdana derve bikin. Li vir me OpenTracing girt - mekanîzmayek, standard, paradîgmayek ku dihêle hûn pergalên belavbûyî bişopînin; û hinekî hat guherandin. Paradîgmaya standard OpenTracing dibêje ku em ji bo her daxwazek kesane şopek ava dikin. Pêdiviya me bi vê yekê tunebû, û me ew bi kurtasî, şopa hevgirtinê pêça. Me amûrek çêkir ku dihêle em leza pergalên li pişt xwe bişopînin.

  
  
  Grafik nîşanî me dide ku yek ji pergalên dravdanê di 3 çirkeyan de dest pê kir ku bersiv bide - pirsgirêkên me hene. Wekî din, ev tişt dê dema ku pirsgirêk dest pê bikin, di navberek 20-30 çirkeyan de bertek nîşan bide.

  Û çîna sêyemîn a xeletiyên çavdêriyê yên ku hene çavdêriya mentiqî ye.

  Bi rastî, min nizanibû ku ez li ser vê slaytê çi bikişînim, ji ber ku em demek dirêj li sûkê li tiştek ku li gorî me digeriyan. Me tiştek nedît, lewma neçar ma ku em bixwe bikin.

  
  
  Mebesta min ji çavdêriya mentiqî çi ye? Welê, xeyal bikin: hûn ji xwe re pergalek çêdikin (mînak, klonek Tinder); te ew çêkir, dest pê kir. Rêvebirê serketî Vasya Pupkin ew danî ser têlefona xwe, keçek li wir dibîne, jê hez dike ... û mîna wê naçe keçikê - wusa ji heman navenda karsaziyê diçe cem cerdevanê ewlehiyê Mikhalych. Rêvebir diçe qata xwarê, û dûv re dipirse: "Çima ev cerdevan Mikhalych ew qas xweş bi wî dikene?"

  Di rewşên weha de... Ji bo me, ev rewş hinekî cûda xuya dike, ji ber ku (min nivîsand) ev windabûna navûdengê ye ku nerasterast dibe sedema zirarên darayî. Rewşa me berevajî ye: dibe ku em rastî zirarên darayî werin - mînakî, heke me danûstendinek bi serfirazî kir, lê ew neserketî bû (an berevajî). Diviya bû ku ez amûrê xwe binivîsim ku bi karanîna nîşanên karsaziyê bi demê re hejmara danûstendinên serketî dişopîne. Li sûkê tiştek nedît! Ev tam fikra ku min dixwest ez ragihînim ev e. Li sûkê tiştek tune ku bi vî rengî pirsgirêk çareser bike.

  Ev bû ku meriv çawa zû pirsgirêkê nas bike.

  Meriv çawa sedemên belavkirinê diyar dike

  Koma sêyemîn a pirsgirêkan ku em çareser dikin, piştî ku me pirsgirêk nas kir, piştî ku me jê xilas bû, baş e ku em sedema pêşkeftinê, ceribandinê fam bikin û li ser wê yekê bikin. Li gorî vê, divê em lêkolîn bikin, divê em qeydan rakin.

  
  
  Ger em li ser têketin diaxivin (sedema bingehîn têketin in), pirraniya têketinên me di ELK Stack de ne - hema hema her kes xwedî heman e. Ji bo hinekan, dibe ku ew ne bi ELK be, lê heke hûn têketin bi gigabyte binivîsin, wê hingê zû an dereng hûn ê werin ELK. Em wan bi terabytes dinivîsin.

  
  
  Li vir pirsgirêkek heye. Me ew rast kir, xeletiya bikarhêner rast kir, dest bi kolandina tiştê ku li wir e kir, hilkişiyan nav Kibana, li wir ket nav nasnameya danûstendinê û pêlekek wusa peyda kir (gelek nîşan dide). Û di vê lingê de bi tevahî tiştek ne diyar e. Çima? Belê, ji ber ku ne diyar e kîjan beş aîdî kîjan xebatkar e, kîjan beş girêdayî kîjan pêkhateyê ye. Û di wê gavê de me fêm kir ku hewcedariya me bi şopandinê heye - heman OpenTracing ku min li ser axivî.

  Me ev salek berê fikirî, bala xwe da sûkê, û li wir du amûr hebûn - "Zipkin" û "Jaeger". "Jager" di rastiyê de wêrisekî îdeolojîk e, peyrewê îdeolojîk yê "Zipkin" e. Di Zipkin de her tişt baş e, ji bilî ku ew nizane meriv çawa berhev dike, nizane ka meriv çawa têketin di şopê de vedihewîne, tenê şopa demê. Û "Jager" ev piştgirî kir.

  Me li "Jager" nihêrî: hûn dikarin serîlêdanên amûrê bikin, hûn dikarin bi Api binivîsin (standarda Api ya ji bo PHP-ê di wê demê de nehat pejirandin - ev salek berê bû, lê niha ew jixwe hatî pejirandin), lê li wir bi temamî tu muwekîlê bû. "Baş e," me fikirîn, û muwekîlê xwe nivîsî. Me çi girt? Bi qasî ku xuya dike ev e:

  
  
  Di Jaeger de, ji bo her peyamê spans têne afirandin. Ango, gava ku bikarhêner pergalê vedike, ew ji bo her daxwazek gihîştî yek an du blokan dibîne (1-2-3 - hejmara daxwazên hatîn ji bikarhêner, hejmara blokan). Ji bo ku ew ji bikarhêneran re hêsantir bikin, me etîket li têketin û şopên demê zêde kir. Li gorî vê yekê, heke xeletiyek çêbibe, serîlêdana me dê têketinê bi nîşana Çewtiya guncan nîşan bide. Hûn dikarin li gorî nîşana Çewtiyê fîlter bikin û tenê pêlên ku vê blokê bi xeletî vedihewîne dê werin xuyang kirin. Ger em vedorê berfireh bikin ev e ku ew dixuye:

  
  
  Di hundurê span de komek şop hene. Di vê rewşê de, ev sê şopên ceribandinê ne, û şopa sêyemîn ji me re dibêje ku xeletiyek çêbû. Di heman demê de, li vir em şopek dem dibînin: li jor pîvanek dem heye, û em dibînin di kîjan navberê de ev an ew têketin hatî tomar kirin.

  Li gorî vê yekê, tişt ji bo me baş bûn. Me dirêjkirina xwe nivîsand û me ew jêder vekir. Heke hûn dixwazin bi şopandinê re bixebitin, heke hûn dixwazin bi "Jager" re di PHP-ê de bixebitin, pêvekek me heye, bi xêr hatî bikar bînin, wekî ku ew dibêjin:

  
  
  Me ev pêvek heye - ew xerîdarek ji bo OpenTracing Api ye, ew wekî php-berfirehiyê hatî çêkirin, ango, hûn ê hewce bikin ku wê berhev bikin û li ser pergalê saz bikin. Salek berê tiştek cuda tune bû. Naha xerîdarên din hene ku mîna pêkhateyan in. Li vir ew bi we ve girêdayî ye: an hûn bi sazkerek pêkhateyan derdixin, an jî hûn dirêjkirina li gorî xwe bikar tînin.

  Standardên pargîdanî

  Me behsa sê fermanan kir. Fermana çaremîn standardkirina nêzîkatiyan e. Ev li ser çi ye? Li ser vê yekê ye:

  
  
  Çima peyva "pargîdanî" li vir e? Ne ji ber ku em pargîdaniyek mezin an burokratîk in, na! Min xwest ku li vir peyva "pargîdanî" bikar bînim di vê çarçoveyê de ku her pargîdanî, her hilber divê standardên xwe hebin, tevî we. Çi standardên me hene?

  
  

  • Rêziknameyên me yên bicihkirinê hene. Em bêyî wî naçin cihekî, em nikarin. Em hefteyekê bi qasî 60 caran bi cih dikin, ango em hema hema bi domdarî bi cih dibin. Di heman demê de, me, mînakî, di rêziknameyên bicîhkirinê de tabûyek li ser şandinên roja Înê heye - di prensîbê de, em bicîh nakin.
  • Em hewceyê belgekirinê ne. Ger ku belgeyek jê tune be, yek pêkhateyek nû nakeve hilberînê, her çend ew di bin pênûsa pisporên me yên RnD de çêbûbe. Em ji wan talîmatên bicîhkirinê, nexşeyek çavdêriyê û ravekirinek hişk (belê, wekî bernamenûs dikarin binivîsin) hewce dikin ka ev hêman çawa dixebite, meriv çawa wê çareser dike.
  • Em ne sedema pirsgirêkê, lê pirsgirêkê çareser dikin - ya ku min berê jî got. Ji bo me girîng e ku bikarhêner ji pirsgirêkan biparêzin.
  • Destûrnameyên me hene. Mînakî, heke me di nav du hûrdeman de 2% seyrûseferê wenda kir, em wê dema domandinê nahesibînin. Ev di bingeh de di statîstîkên me de tune ye. Ger ew ji sedî zêdetir be an demkî be, em jixwe hesab dikin.
  • Û em her tim postmortems dinivîsin. Çi dibe bila bibe, her rewşek ku kesek di hilberînê de ne asayî tevdigere, dê di piştî mirinê de were xuyang kirin. Postmortem belgeyek e ku tê de hûn tiştên ku hatine serê we, demek hûrgulî, tiştê ku we kiriye ji bo rastkirina wê dinivîsin û (ev bloka mecbûrî ye!) hûn ê çi bikin da ku hûn di pêşerojê de pêşî li vê yekê bigirin. Ev ji bo analîza paşîn mecbûrî û pêdivî ye.

  Dema bêhnvedanê çi tê hesibandin?

  
  
  Ev hemû bû sedema çi?

  Ev bû sedema vê yekê ku (me hin pirsgirêkên aramiyê hebûn, ev ne li gorî xerîdaran û ne jî me) di 6 mehên borî de nîşana aramiya me 99,97 bû. Em dikarin bibêjin ku ev ne zêde ye. Erê, tiştek me heye ku em ji bo hewl bikin. Ji vê nîşankerê, bi qasî nîvê îstîqrarê ye, wekî ku ne ya me, lê agirê serîlêdana meya webê ye, ku li pêş me radiweste û wekî karûbar tê bikar anîn, lê xerîdar ji vê yekê re eleqedar nabin.

  Em fêrî razana bi şev bûn. Paşan! Şeş meh berê me nekarî. Û li ser vê notê bi encaman re, ez dixwazim yek têbînî bikim. Şeva borî di derbarê pergala kontrolê ya reaktoreke nukleerî de raporek ecêb hate weşandin. Ger kesên ku ev pergal nivîsandine dikarin min bibihîzin, ji kerema xwe gotina min li ser "2% ne demdirêj e" ji bîr bike. Ji bo we, 2% demdirêj e, her çend du hûrdeman be jî!

  Navê pêger! Pirsên we.

  
  

  Di derbarê balans û koçberiya databasê de

  Pirsa temaşevanan (li vir – B): – Êvar baş. Gelek spas ji bo raporek rêveberê wusa! Pirsek kurt li ser balansên we. We behs kir ku we WAF heye, ango, wekî ku ez jê fêm dikim, hûn cûreyek balansek derveyî bikar tînin ...

  EK: - Na, em karûbarên xwe wekî balansek bikar tînin. Di vê rewşê de, WAF ji bo me tenê amûrek parastina DDoS ye.

  In: – Tu dikarî çend peyvan li ser balansan bibêjî?

  EK: - Wekî ku min berê jî got, ev komek serverên vekirî ye. Naha me 5 komên rezervan hene ku bi taybetî bersivê didin... ango serverek ku bi taybetî vekirî dimeşîne, ew tenê seyrûseferê dike. Li gorî vê yekê, ji bo ku em fêm bikin ka em çiqasî digirin: naha seyrûseferek birêkûpêk a çend sed megabit heye. Li ber xwe didin, xwe xweş hîs dikin, xwe jî teng nakin.

  In: - Her weha pirsek hêsan. Li vir bicihkirina Şîn / Kesk e. Ji bo nimûne, hûn bi koçberên databasê re çi dikin?

  EK: - Pirsa baş! Binêrin, di bicihkirina Şîn/Kesk de ji bo her rêzê rêzên me yên cihê hene. Ango, heke em qala rêzikên bûyeran dikin ku ji xebatkar bo xebatkar têne veguheztin, ji bo xeta şîn û ji bo xeta kesk rêzên cuda hene. Ger em li ser databasê bixwe dipeyivin, wê hingê me bi qestî ew bi qasî ku ji destê me hat teng kir, her tişt bi pratîkî veguhezand rêzan; di databasê de em tenê komek danûstendinan hilînin. Û stûna danûstendina me ji bo hemî rêzan yek e. Bi databasê re di vê çarçoveyê de: em wê li şîn û kesk dabeş nakin, ji ber ku her du guhertoyên kodê divê zanibin ku bi danûstendinê re çi diqewime.

  Hevalno, min xelatek piçûk jî heye ku ez we bişopînim - pirtûkek. Û divê ez ji bo pirsa herî baş were xelat kirin.

  In: - Slav. Spas ji bo raporê. Pirs ev e. Hûn çavdêriya dayinan dikin, hûn çavdêriya karûbarên ku hûn pê re danûstandinê dikin... Lê hûn çawa çavdêriyê dikin da ku kesek bi rengekî were ser rûpela dravdana we, drav bide û proje bi pereyan jê re deyne? Ango, hûn çawa dişopînin ku meşvan heye û banga we qebûl kiriye?

  EK: - "Bazirgan" ji bo me di vê rewşê de tam heman karûbarê derveyî ye ku pergala dravdanê ye. Em leza bersiva bazirganan dişopînin.

  Di derbarê şîfrekirina databasê de

  In: - Slav. Pirsek min hinekî têkildar heye. Te daneyên hesas PCI DSS hene. Min dixwest bizanim hûn çawa PAN-an di rêzikên ku hûn hewce ne ku tê de veguhezînin hilînin? Ma hûn şîfrekirinê bikar tînin? Û ev dibe sedema pirsa duyemîn: li gorî PCI DSS, pêdivî ye ku di rewşên guhertinan de (jikarberdana rêvebiran, hwd.) bi awayekî periyodîk ji nû ve şîfrekirina databasê were şîfrekirin - di vê rewşê de gihîştina çi dibe?

  
  
  EK: - Pirsa ecêb! Ya yekem, em PAN-an di rêzan de hilnagirin. Di prensîbê de, mafê me tune ku em PAN-ê li her deverê bi rengek zelal hilînin, ji ber vê yekê em karûbarek taybetî bikar tînin (em jê re dibêjin "Kademon") - ev karûbarek e ku tenê yek tişt dike: ew peyamek wekî têketinê distîne û dişîne. peyamek şîfrekirî derxe. Û em her tiştî bi vê peyama şîfrekirî hilînin. Li gorî vê yekê, dirêjahiya mifteya me di binê kilobyte de ye, da ku ev ciddî û pêbawer e.

  In: – Niha ji te re 2 kîlobayt lazim in?

  EK: – Dixuye ku hema duh bû 256... Baş e, li ku din?!

  Li gorî vê yekê, ev yekem e. Ya duyemîn jî, çareseriya ku heye, ew proseya şîfrekirinê ji nû ve piştgirî dike - du cot "keks" (kilît) hene, ku "decks" didin ku şîfre dikin (kilît mift in, dek jêderên mifteyên şîfrekirî ne) . Û heke pêvajo dest pê kir (ew bi rêkûpêk, ji 3 mehan heta ± hinekan diqewime), em cotek "kelek" nû dakêşin, û em daneyan ji nû ve şîfre dikin. Karûbarên me yên cihê hene ku hemî daneyan jê dikin û bi rengek nû şîfre dikin; Daneyên li kêleka nasnavê mifteya ku pê tê şîfrekirin tê hilanîn. Li gorî vê, gava ku em daneyan bi mifteyên nû şîfre dikin, em mifteya kevin jê dikin.

  Carinan pêdivî ye ku drav bi destan were kirin…

  In: - Ango, heke ji bo hin operasyonê vegerandin hatibe, hûn ê dîsa jî wê bi mifteya kevn deşîfre bikin?

  EK: - Erê.

  In: – Paşê pirseke din a biçûk. Dema ku celebek têkçûn, ketin, an bûyerek çêbibe, pêdivî ye ku meriv bi destan danûstendinê bişopîne. Rewşeke wisa heye.

  EK: - Belê, carinan.

  In: – Tu van daneyan ji ku distînî? An hûn bi xwe diçin vê depoyê?

  EK: - Na, baş e, bê guman, me celebek pergala paşîn-ofîsê heye ku ji bo piştgiriya me navgînek heye. Ger em nizanin danûstendin di kîjan statûyê de ye (mînakî, heya ku pergala dravdanê bi demek dirêj bersiv da), em berê nizanin, ango, em statûya paşîn tenê bi pêbaweriya tam destnîşan dikin. Di vê rewşê de, em danûstendinê ji bo pêvajoyek bi destan di rewşek taybetî de destnîşan dikin. Serê sibê, roja din, gava ku piştgirî agahdarî werdigire ku ev û wusa danûstendinên di pergala dravdanê de dimînin, ew wan bi destan di vê navberê de pêvajoyê dikin.

  
  
  In: – Çend pirsên min hene. Yek ji wan berdewamiya qada PCI DSS ye: hûn çawa çerxa wan têketin? Ev pirs ji ber ku pêşdebir dikaribû tiştek di têketinê de bixista! Pirsa duyemîn: hûn çawa serrastkirinan çêdikin? Bikaranîna destikên di databasê de vebijarkek e, lê dibe ku serrastkirinên belaş hebin - prosedur li wir çi ye? Û pirsa sêyemîn dibe ku bi RTO, RPO ve girêdayî ye. Hebûna we 99,97 bû, hema çar neh, lê wekî ku ez jê fam dikim, we navendek daneya duyemîn, navendek daneya sêyemîn û navendek daneya pêncemîn heye... Hûn wan çawa hevdeng dikin, wan dubare dikin, û her tiştê din?

  EK: - Ka em bi ya yekem dest pê bikin. Pirsa yekem li ser têketin bû? Dema ku em têketin dinivîsin, qatek me heye ku hemî daneyên hesas mask dike. Ew li mask û li zeviyên zêde dinêre. Li gorî vê yekê, têketinên me bi daneya jixwe maskkirî û pêvekek PCI DSS derdikevin. Ev yek ji wan karên birêkûpêk e ku ji beşa ceribandinê re hatî destnîşankirin. Ji wan tê xwestin ku her peywirê, tevî têketinên ku ew dinivîsin, kontrol bikin, û ev yek ji karên birêkûpêk e di dema vekolînên kodê de, da ku kontrol bikin ku pêşdebir tiştek nenivîsandiye. Kontrolên paşîn ên vê yekê bi rêkûpêk ji hêla beşa ewlehiya agahdarî ve bi qasî hefteyekê carekê têne kirin: têketinên roja paşîn bi bijartî têne girtin û ew bi navgînek skaner-analîzatorek taybetî ya ji serverên ceribandinê têne rêve kirin da ku her tiştî kontrol bikin.
  Derbarê serrastkirinên germ. Ev di rêziknameya me ya belavkirinê de ye. Di derbarê serrastkirinên me de bendek cûda heye. Em bawer dikin ku gava ku em jê re lazim in, em dorpêçên germkirinê bi cîh dikin. Hema ku guhertoyek tê berhev kirin, gava ku ew were xebitandin, bi qasî ku hunerek me hebe, li ser banga piştgirîyê li ser peywira me rêvebirek pergalê heye, û ew di wextê ku hewce dike de wê bi cih dike.

  Li ser "çar neh". Hêjmara ku nuha me bi rastî bi dest xistiye, û me ji bo wê di navendek daneya din de hewl da. Naha me navendek daneya duyemîn heye, û em dest bi rêveçûna di navbera wan de dikin, û mijara dubarekirina navenda daneyê bi rastî pirsek ne-pîvan e. Me hewl da ku wê di yek carî de bi karanîna awayên cûda çareser bikin: me hewl da ku heman "Tarantula" bikar bînin - ew ji me re neçû, ez ê tavilê ji we re bibêjim. Ji ber vê yekê me dawî li fermana "sens" bi destan anî. Bi rastî, her serîlêdanek di pergala me de hevdemkirina "guhertin - kirin" ya pêwîst di navbera navendên daneyê de bi asynkronî dimeşîne.

  In: - Heger te yê duyem girt, çima te yê sêyem negirt? Ji ber ku hêj mejiyê kesî perçe nebûye...

  EK: - Lê mejî Mejiyê Parçebûyî nîne. Ji ber ku her serîlêdanek ji hêla multimaster ve tê rêve kirin, ji me re ne girîng e ku daxwaz hatî kîjan navendê. Em ji vê yekê re amade ne ku heke yek ji navendên daneya me têk bibe (em xwe dispêrin vê) û di nîvê daxwazek bikarhêner de derbasî navenda daneya duyemîn bibe, em amade ne ku vî bikarhêner winda bikin, bi rastî; lê ev dê bibin yekîne, yekîneyên mutleq.

  In: - Êvar baş. Spas ji bo raporê. We behsa debugera xwe kir, ku di hilberînê de hin danûstandinên ceribandinê dimeşîne. Lê ji me re li ser danûstandinên testê bêjin! Ew çiqas kûr dibe?

  EK: - Ew di çerxa tevahî ya tevahiyê de derbas dibe. Ji bo pêkhateyek, di navbera danûstendinek ceribandinê û hilberînek de cûdahî tune. Lê ji nêrînek mentiqî de, ev bi tenê projeyek cihêreng di pergalê de ye, ku li ser wê tenê danûstandinên ceribandinê têne meşandin.

  In: -Tu li ku dibirî? Li vir Core şand ...

  EK: – Em di vê rewşê de ji bo danûstendinên ceribandinê li pişt “Kor”ê ne... Tiştek me ya wekî rêgirtinê heye: “Kor” dizane ku ji kîjan pergala dravdanê re bişîne - em dişînin pergalek dravdanê ya sexte, ku bi hêsanî îşaretek http dide û navê pêger.

  In: - Ji min re bêje, ji kerema xwe, serlêdana we di yek monolîtek mezin de hate nivîsandin, an we ew di hin karûbar an jî mîkroxizmetan de qut kir?

  EK: - Me yekalîtek tune, bê guman, serîlêdanek me ya xizmetguzarî heye. Em henek dikin ku karûbarê me ji monolîtan pêk tê - ew bi rastî pir mezin in. Zehmet e ku meriv jê re bibêje mîkroxizmet, lê ev karûbar in ku di nav wan de xebatkarên makîneyên belavkirî dixebitin.

  Ger karûbarê li ser serverê têk bibe...

  In: – Paşê pirsa min heye. Tewra ku ew monolîtek be jî, we dîsa jî got ku we gelek ji van serverên tavilê hene, ew hemî di bingeh de daneyan pêvajoyê dikin, û pirs ev e: "Di bûyera lihevhatina yek ji pêşkêşkerên tavilê an serîlêdanek de, her girêdanek kesane , gelo wan cûreyek kontrola gihîştinê heye? Kîjan ji wan dikare çi bike? Ji bo çi agahdarî divê ez bi kê re têkilî bikim?

  
  
  EK: - Belê, teqez. Pêdiviyên ewlehiyê pir cidî ne. Ya yekem, me tevgerên daneya vekirî hene, û bender tenê ew in ku em di pêş de tevgera trafîkê pêşbînî dikin. Ger pêkhateyek bi databasê re (bibêjin, bi Muskul re) bi 5-4-3-2 re têkilî daynin, dê tenê 5-4-3-2 jê re vekirî be, û portên din û rêwerzên din ên trafîkê dê nebin. Wekî din, hûn hewce ne ku fêm bikin ku di hilberîna me de bi qasî 10 lûleyên ewlehiyê yên cihêreng hene. Û tewra ku serîlêdan bi rengek tawîz hatibe girtin, Xwedê nehêle, êrîşkar dê nikaribe bigihîje konsoleya rêveberiya serverê, ji ber ku ev herêmek ewlehiya torê ya cihê ye.

  In: – Û di vê çarçoveyê de, ya ku ji min re balkêştir e ev e ku hin peymanên we bi karûbaran re hene - ew dikarin çi bikin, bi çi "çalakiyan" dikarin bi hev re têkilî daynin... Û di herikînek normal de, hin karûbarên taybetî hin daxwaz dikin. row, lîsteya "çalakiyên" li ser din. Ew xuya nakin ku di rewşek normal de berê xwe bidin kesên din, û wan deverên din ên berpirsiyariyê hene. Ger yek ji wan tawîz bike, gelo dê karibe “çalakiyên” wê xizmetê têk bibe?..

  EK: - Ez dizanim. Ger di rewşek normal de bi serverek din re danûstendina bi tevahî destûr bû, wê hingê erê. Li gorî peymana SLA, em çavdêr nakin ku hûn tenê 3 "çalakiyên" yekem destûr in, û hûn destûr nadin 4 "çalakiyên". Dibe ku ev ji bo me zêde be, ji ber ku me jixwe pergalek parastinê ya 4-asta, di prensîbê de, ji bo dorhêlan heye. Em tercîh dikin ku xwe bi konturan biparêzin, ne di asta hundir de.

  Visa, MasterCard û Sberbank çawa dixebitin

  In: - Ez dixwazim xalek li ser veguheztina bikarhênerek ji navendek daneyê bo navendek din zelal bikim. Bi qasî ku ez dizanim, Visa û MasterCard bi karanîna protokola hevdem a binary 8583 kar dikin, û li wir tevlihev hene. Û min dixwest bizanim, naha mebesta me ew e ku meriv biguhezîne - gelo ew rasterast "Visa" û "MasterCard" e an berî pergalên dravdanê, berî pêvajoyê?

  EK: - Ev berî tevlihevan e. Miksên me di heman navenda daneyê de ne.

  In: - Bi giştî, yek xala we ya girêdanê heye?

  EK: - "Visa" û "MasterCard" - erê. Tenê ji ber ku Visa û MasterCard di binesaziyê de veberhênanên pir ciddî hewce dike da ku peymanên cihêreng girêbide da ku, mînakî, cotek duyemîn a mixan bistîne. Ew di nav yek navendek daneyê de têne veqetandin, lê heke, Xwedê nehêle, navenda daneya me, ku tê de ji bo girêdana bi Visa û MasterCard re tevlihev hene, bimire, wê hingê pêwendiya me bi Visa û MasterCard re winda dibe ...

  In: - Ew çawa dikarin bêne veqetandin? Ez dizanim ku Visa di prensîbê de tenê yek pêwendiyê destûrê dide!

  EK: – Ew bi xwe alavan tedarik dikin. Di her rewşê de, me alavên ku di hundurê de bi tevahî zêde ne, wergirtin.

  In: - Ango stand ji wan Connects Orange ye?..

  EK: - Erê.

  In: - Lê li ser vê dozê çi ye: heke navenda daneya we winda bibe, hûn çawa dikarin wê bikar bînin? An jî seyrûsefer tenê disekine?

  EK: - Na. Di vê rewşê de, em ê bi tenê seyrûseferê biguhezînin kanalek din, ku, bi xwezayî, dê ji me re bihatir û ji bo xerîdarên me bihatir be. Lê seyrûsefer dê ne bi girêdana meya rasterast a bi Visa, MasterCard re, lê bi Sberbank-ya şert (pir zêde zêde) derbas bibe.

  Ger min ji xebatkarên Sberbank aciz kir ez bi tundî lêborînê dixwazim. Lê li gorî statîstîkên me, di nav bankên rûsî de, Sberbank pir caran dikeve. Mehek derbas nabe ku tiştek li Sberbank nekeve.

  
  
  

  Hin reklam 🙂

  Spas ji bo ku hûn bi me re bimînin. Ma hûn ji gotarên me hez dikin? Ma hûn dixwazin naveroka balkêştir bibînin? Piştgiriya me bikin bi danîna fermanek an pêşniyarkirina hevalan, ewr VPS ji bo pêşdebiran ji 4.99 $, analogek bêhempa ya pêşkêşkerên asta têketinê, ku ji hêla me ve ji bo we hatî vedîtin: Tevahiya rastiyê di derbarê VPS (KVM) E5-2697 v3 (6 Cores) 10 GB DDR4 480 GB SSD 1Gbps ji 19 $ an çawa serverek parve dike? (bi RAID1 û RAID10, heta 24 core û heya 40 GB DDR4 peyda dibe).

  Dell R730xd 2x erzantir li navenda daneya Equinix Tier IV li Amsterdam? Tenê li vir 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ji 199$ li Hollanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ji $99! Li ser bixwînin Meriv çawa pargîdaniya binesaziyê ava dike. pola bi karanîna serverên Dell R730xd E5-2650 v4 bi nirxek 9000 euro ji bo quruşek?

Source: www.habr.com