Em çavdêriya Sportmaster dikin - çawa û bi çi

Em difikirin ku di qonaxa avakirina tîmên hilberê de pergalek çavdêriyê çêbikin. Eşkere bû ku karsaziya me - îstismar - nakeve nava van tîman. Çima wisa ye?

Rastî ev e ku hemî tîmên me li dora pergalên agahdariya kesane, mîkroxizmet û pêşan têne çêkirin, ji ber vê yekê tîm tenduristiya giştî ya tevahiya pergalê bi tevahî nabînin. Mînakî, dibe ku ew nizanibin ka beşek piçûk di paşiya kûr de çawa li dawiya pêşîn bandor dike. Qada berjewendiya wan bi pergalên ku pergala wan pê re yekgirtî ye sînordar e. Ger tîmek û karûbarê wê A hema hema bi karûbarê B re têkildar nebe, wê hingê karûbarek wusa hema ji tîmê re nayê dîtin.

Em çavdêriya Sportmaster dikin - çawa û bi çi

Tîma me, di encamê de, bi pergalên ku bi hevûdu re pir bi hêz in re dixebite: di navbera wan de gelek girêdan hene, ev binesaziyek pir mezin e. Û xebata dikana serhêl bi van hemî pergalan ve girêdayî ye (ya ku me, bi awayê, hejmareke mezin heye).

Ji ber vê yekê derdikeve holê ku beşa me ne girêdayî ti tîmekê ye, lê hinekî li kêlekê ye. Di tevahiya vê çîrokê de, peywira me ev e ku em bi berfirehî fam bikin ka pergalên agahdariyê çawa dixebitin, fonksiyonên wan, yekbûn, nermalava, torê, hardware, û çawa ev hemî bi hevûdu ve girêdayî ne.

Platforma ku li ser firotgehên me yên serhêl dixebitin wiha xuya dike:

  • pêşde
  • ofîsa navîn
  • paş-office

Em çiqas bixwazin jî wisa nabe ku hemû pergal bi rêkûpêk û bêqisûr kar bikin. Xala, dîsa, hejmara pergal û entegrasyonê ye - digel tiştek mîna ya me, hin bûyer neçar in, tevî kalîteya ceribandinê. Ji bilî vê, hem di nav sîstemek cuda de û hem jî di warê yekbûna wan de. Û hûn hewce ne ku rewşa tevahiya platformê bi berfirehî bişopînin, û ne tenê beşek wê ya ferdî.

Bi îdeal, çavdêriya tenduristiyê ya li seranserê platformê divê bixweber be. Û em hatin çavdêrîkirin weke beşeke neçarî ya vê pêvajoyê. Di destpêkê de, ew tenê ji bo beşa pêşîn hate çêkirin, dema ku pisporên torê, rêveberên nermalavê û hardware pergalên xwe yên şopandina qat-bi-pile hebûn û hîn jî hene. Van kesan tenê di asta xwe de çavdêrî dişopandin, têgihiştineke berfireh a kesî jî tunebû.

Mînakî, heke makîneyek virtual têk biçe, di pir rewşan de tenê rêveberê ku ji hardware û makîneya virtual berpirsiyar e pê dizane. Di rewşên weha de, tîmê pêşîn rastiya qezaya serîlêdanê dît, lê di derheqê têkçûna makîneya virtual de daneyên wê tune. Û rêveber dikare bizane ku xerîdar kî ye û ramanek berbiçav li ser tiştê ku niha li ser vê makîneya virtual dimeşîne, hebe, bi şertê ku ew celebek projeyek mezin be. Bi îhtîmaleke mezin ew bi piçûkan nizane. Di her rewşê de, rêveber pêdivî ye ku biçe cem xwediyê xwe û bipirse ka li ser vê makîneyê çi hebû, çi hewce dike ku were sererast kirin û çi divê were guheztin. Û heke tiştek bi rastî ciddî têk çû, wan dest pê kir li dora dorûberan bazdan - ji ber ku kes pergalê bi tevahî nedît.

Di dawiyê de, çîrokên weha yên cihêreng bandorê li tevahiya pêşiyê, bikarhêner û fonksiyona karsaziya meya bingehîn - firotana serhêl dike. Ji ber ku em ne beşek tîmê ne, lê wekî beşek ji firotgehek serhêl bi xebata hemî serîlêdanên e-bazirganiyê ve mijûl in, me peywira afirandina pergalek çavdêriya berfireh ji bo platforma ecommerce girt ser xwe.

Struktura pergalê û stack

Me bi destnîşankirina gelek qatên çavdêriyê yên ji bo pergalên xwe dest pê kir, ku di nav wan de hewce ne ku metrîkan berhev bikin. Û ev hemî hewce bû ku bi hev re bêne hev kirin, ya ku me di qonaxa yekem de kir. Naha di vê qonaxê de em berhevoka kalîteya herî bilind a metrîkan li seranserê hemî qatên xwe bi dawî dikin da ku têkiliyek ava bikin û fam bikin ka pergal çawa bandorê li hev dikin.

Nebûna çavdêriya berfireh di qonaxên destpêkê yên destpêkirina serîlêdanê de (ji ber ku me dest bi avakirina wê kir dema ku piraniya pergalê di hilberînê de bûn) bû sedema vê yekê ku me deynek teknîkî ya girîng hebû ku çavdêriya tevahiya platformê saz bikin. Me nikarîbû em bala xwe bidin ser sazkirina çavdêriyê ji bo yek IS û bi hûrgulî çavdêrîkirina wê bikin, ji ber ku pergalên mayî dê ji bo demekê bê şopandin bimînin. Ji bo çareserkirina vê pirsgirêkê, me navnîşek pîvanên herî pêwîst ên ji bo nirxandina rewşa pergala agahdariyê ji hêla qat ve nas kir û dest bi pêkanîna wê kir.

Ji ber vê yekê, wan biryar da ku fîl parçe parçe bixwin.

Sîstema me ji:

  • hardware;
  • pergala xebatê;
  • software;
  • Parçeyên UI di serîlêdana çavdêriyê de;
  • pîvanên karsaziyê;
  • sepanên entegrasyonê;
  • ewlehiya agahdariyê;
  • networks;
  • balansa trafîkê.

Em çavdêriya Sportmaster dikin - çawa û bi çi

Di navenda vê pergalê de xwe şopandin e. Ji bo ku hûn bi gelemperî rewşa tevahiya pergalê fam bikin, hûn hewce ne ku zanibin ka bi serîlêdanên li ser van hemî qatan û li seranserê tevaya sepanan çi diqewime.

Ji ber vê yekê, li ser stack.

Em çavdêriya Sportmaster dikin - çawa û bi çi

Em nermalava çavkaniya vekirî bikar tînin. Li navendê me Zabbix heye, ku em di serî de wekî pergala hişyarkirinê bikar tînin. Her kes dizane ku ew ji bo çavdêriya binesaziyê îdeal e. Ev tê çi wateyê? Tam wan metrîkên nizm ên ku her pargîdaniyek ku navenda daneya xwe diparêze heye (û Sportmaster navendên daneya xwe hene) - germahiya serverê, rewşa bîranînê, serdegirtinê, metrîkên cîhaza torê.

Me Zabbix bi peyamnêra Telegram û Tîmên Microsoft-ê re, ku bi rengek çalak di tîm de têne bikar anîn, yek kirine. Zabbix qatê tora rastîn, hardware û hin nermalavê vedigire, lê ew ne dermanek e. Em van daneyan ji hin xizmetên din dewlemend dikin. Mînakî, di asta hardware de, em rasterast bi API-ê ve bi pergala xweya virtualîzasyonê ve girêdidin û daneyan berhev dikin.

Êdî çi. Ji bilî Zabbix, em Prometheus bikar tînin, ku destûrê dide me ku metrîkan di serîlêdana hawîrdora dînamîkî de bişopînin. Ango, em dikarin metrîkên serîlêdanê bi navgînek dawiya HTTP-ê werbigirin û xem nekin ka kîjan metrîkan tê de bar bikin û kîjan na. Li ser bingeha van daneyan, pirsên analîtîk dikarin werin pêşve xistin.

Çavkaniyên daneyê ji bo qatên din, mînakî, metrîkên karsaziyê, li sê beşan têne dabeş kirin.

Pêşîn, ev pergalên karsaziya derveyî ne, Google Analytics, em metrîkan ji têketin berhev dikin. Ji wan em daneyên li ser bikarhênerên çalak, veguhertin û her tiştê ku bi karsaziyê ve girêdayî ye digirin. Ya duyemîn, ev pergalek çavdêriya UI ye. Divê bi hûrgulî were vegotin.

Carekê me dest bi ceribandina destan kir û ew di ceribandinên otomatîkî yên fonksiyonel û entegrasyonê de mezin bû. Ji vê yekê me çavdêrî kir, tenê fonksiyona sereke hiştin, û xwe spartin nîşankerên ku bi qasî ku pêkan aram in û bi demê re pir caran naguherin.

Struktura tîmê nû tê vê wateyê ku hemî çalakiyên serîlêdanê bi tîmên hilberê ve girêdayî ne, ji ber vê yekê me dev ji ceribandina paqij berda. Di şûna wê de, me çavdêriya UI ji ceribandinên ku bi Java, Selenium û Jenkins hatine nivîsandin (wek pergalek ji bo destpêkirin û çêkirina raporan tê bikar anîn) çêkir.

Gelek ceribandinên me hebûn, lê di dawiyê de me biryar da ku em biçin ser riya sereke, metrîka asta jorîn. Û heke me gelek ceribandinên taybetî hebin, ew ê dijwar be ku daneyan nûve bikin. Her berdana paşîn dê bi girîngî tevahî pergalê bişkîne, û ya ku em ê bikin ev e ku wê rast bikin. Ji ber vê yekê, me bala xwe da ser tiştên pir bingehîn ên ku kêm têne guhertin, û em tenê çavdêriya wan dikin.

Di dawiyê de, ya sêyemîn, çavkaniya daneyê pergalek têketina navendî ye. Em Elastic Stack-ê ji bo têketin bikar tînin, û dûv re em dikarin van daneyan ji bo metrîkên karsaziyê bixin nav pergala xweya çavdêriyê. Digel van hemîyan, me karûbarê xweya API-ya Şopandinê heye, ku bi Python hatî nivîsandin, ku ji her karûbaran bi navgîniya API-yê dipirse û daneyan ji wan di Zabbix de berhev dike.

Taybetmendiyek din a domdar a çavdêriyê dîtbarî ye. Ya me li ser Grafana ye. Ew di nav pergalên dîtbariyê yên din de radiweste ku ew dihêle hûn metrîkên ji çavkaniyên daneyên cihêreng ên li ser dashboardê xuyang bikin. Em dikarin ji bo firotgehek serhêl metrîkên asta jorîn berhev bikin, mînakî, hejmara fermanên ku di saeta paşîn de ji DBMS-ê hatine danîn, metrîkên performansê yên ji bo OS-ya ku ev firotgeha serhêl ji Zabbix tê xebitandin, û metrîkên ji bo nimûneyên vê serîlêdanê ji Prometheus. Û ev hemî dê li ser yek dashboardê be. Zelal û gihîştî.

Bihêle ez di derbarê ewlehiyê de balê bikşînim - em niha pergalê dawî dikin, ku em ê paşê bi pergala çavdêriya cîhanî re yek bikin. Bi dîtina min, pirsgirêkên sereke yên ku e-bazirganiya e-bazirganiyê di warê ewlehiya agahdariyê de rû bi rû dimînin, bi bot, parser û hêza hov ve girêdayî ne. Pêdivî ye ku em çavê xwe li ser vê yekê bigirin, ji ber ku ev hemî dikarin hem li ser xebata sepanên me hem jî li navûdengê me ji nêrînek karsaziyê bandorek krîtîk bikin. Û bi stûna bijartî em van karan bi serfirazî vedigirin.

Xaleke din a girîng ev e ku qata serîlêdanê ji hêla Prometheus ve hatî berhev kirin. Ew bi xwe jî bi Zabbix re yekgirtî ye. Di heman demê de malpera me jî heye, karûbarek ku destûrê dide me ku em parametreyên wekî leza barkirina rûpela xwe, kêşan, vegotina rûpelê, barkirina nivîsan, hwd., bibînin, ew jî API-ya yekbûyî ye. Ji ber vê yekê metrîkên me li Zabbix têne berhev kirin, û li gorî vê yekê, em ji wir jî hişyar dikin. Hemî hişyarî naha ji rêbazên şandina sereke re têne şandin (ji bo naha ew e-name û telegram e, Tîmên MS-ê jî vê dawiyê hatine girêdan). Plan hene ku hişyarkirina ji rewşek wusa re nûve bikin ku botên aqilmend wekî karûbar dixebitin û agahdariya çavdêriyê ji hemî tîmên hilberên eleqedar re peyda dikin.

Ji bo me, metrîk ne tenê ji bo pergalên agahdariya kesane, lê di heman demê de metrîkên gelemperî jî ji bo tevahî binesaziya ku serîlêdan bikar tînin girîng in: komên pêşkêşkerên laşî yên ku makîneyên virtual li ser dixebitin, hevsengên trafîkê, Balansa barkirina torê, torê bixwe, karanîna kanalên ragihandinê. . Zêdetir metrîkên ji bo navendên daneya xwe (me çend ji wan hene û binesaziya pir mezin e).

Em çavdêriya Sportmaster dikin - çawa û bi çi

Awantajên pergala me ya çavdêriyê ew e ku bi alîkariya wê em rewşa tenduristiya hemî pergalan dibînin û dikarin bandora wan li ser hev û li ser çavkaniyên hevpar binirxînin. Û di dawiyê de, ew dihêle ku em beşdarî plansaziya çavkaniyê bibin, ku ev jî berpirsiyariya me ye. Em çavkaniyên serverê îdare dikin - hewzek di nav e-bazirganiyê de, komîsyon û alavên nû derxistin, alavên nû yên din bikirin, vekolînek karanîna çavkaniyê, hwd. Her sal, tîm projeyên nû plan dikin, pergalên xwe pêşve dibin, û ji bo me girîng e ku em jêderan peyda bikin.

Û bi alîkariya metrîkan, em meyla di xerckirina çavkaniyê de ji hêla pergalên agahdariya xwe ve dibînin. Û li ser wan em dikarin tiştek plan bikin. Di asta virtualkirinê de, em daneyan berhev dikin û agahdariya li ser hêjmara çavkaniyên berdest ji hêla navenda daneyê ve dibînin. Û jixwe di hundurê navenda daneyê de hûn dikarin vezîvirandin, belavkirina rastîn, û vexwarina çavkaniyan bibînin. Digel vê yekê, hem bi serverên serbixwe û hem jî makîneyên virtual û komên serverên laşî yên ku li ser wan hemî makîneyên virtual bi hêz dizivirin.

Pirsên

Niha bingehê me yê sîstemê bi giştî amade ye, lê hîn jî gelek tişt hene ku divê li ser bên xebitandin. Bi kêmanî, ev qatek ewlehiya agahdariyê ye, lê di heman demê de girîng e ku meriv bigihîje torê, hişyariyê pêşve bibe û pirsgirêka pêwendiyê çareser bike. Gelek qat û pergalên me hene, û li ser her qatê gelek metrîk hene. Derdikeve ku ew matryoshka bi dereceya matryoshka ye.

Karê me ew e ku em di dawiyê de hişyariyên rast bikin. Mînakî, heke di hardware de pirsgirêkek hebe, dîsa, bi makîneyek virtual re, û serîlêdanek girîng hebû, û karûbar bi tu awayî nehat piştgirî kirin. Em fêr dibin ku makîneya virtual mir. Dûv re metrîkên karsaziyê dê we hişyar bikin: bikarhêner li cîhek winda bûne, veguheztinek tune, UI di navbeynê de tune ye, nermalava û karûbar jî mirine.

Di vê rewşê de, em ê spam ji hişyariyan bistînin, û ev êdî di forma pergalek çavdêriya rast de cîh nagire. Pirsgirêka hevgirtinê derdikeve holê. Ji ber vê yekê, bi îdeal, pergala meya çavdêriyê divê bêje: "Gelîno, makîneya weya fizîkî mir, û ligel wê ev serîlêdan û van metrîkan jî mir," bi alîkariya yek hişyariyê, li şûna ku bi hêrs bi sed hişyarî me bombebaran bike. Pêdivî ye ku ew tiştê sereke rapor bike - sedem, ku ji ber herêmîbûna wê re dibe alîkar ku pirsgirêk zû ji holê rabike.

Pergala me ya ragihandinê û pêvajoyek hişyariyê li dora karûbarek xeta germ a 24-saetê hatî çêkirin. Hemî hişyariyên ku wekî pêdivî têne hesibandin û di navnîşa kontrolê de cih digirin li wir têne şandin. Pêdivî ye ku her hişyarî raveyek hebe: çi qewimî, bi rastî tê çi wateyê, çi bandor dike. Û her weha girêdanek bi dashboardê û rêwerzên ku di vê rewşê de çi bikin.

Ev hemî li ser hewcedariyên ji bo avakirina hişyariyek e. Wê demê rewş dikare di du aliyan de pêş bikeve - an pirsgirêkek heye û pêdivî ye ku were çareser kirin, an jî di pergala çavdêriyê de têkçûnek çêbûye. Lê di her rewşê de, hûn hewce ne ku biçin û wê fêm bikin.

Bi navînî, em naha rojane nêzî sed hişyarî distînin, li ber çavê xwe didin ku pêwendiya hişyariyan hîn bi rêkûpêk nehatiye mîheng kirin. Û heke hewce bike ku em karê teknîkî bikin, û em tiştek bi zorê biqewirînin, hejmara wan pir zêde dibe.

Digel çavdêriya pergalên ku em dixebitin û berhevkirina metrîkên ku ji hêla me ve girîng têne hesibandin, pergala çavdêriyê dihêle ku em ji bo tîmên hilberê daneyan berhev bikin. Ew dikarin di nav pergalên agahdariyê de ku em çavdêriyê dikin bandorê li pêkhatina metrîkan bikin.

Dibe ku hevkarê me were û bixwaze ku hin metrîka ku hem ji bo me hem jî ji bo tîmê kêrhatî be lê zêde bike. An jî, wek nimûne, tîm dibe ku têra metrîkên bingehîn ên ku me ne hebe; ew hewce ne ku hin taybetî bişopînin. Li Grafana, em ji bo her tîmek cîhek diafirînin û mafên rêveberiyê didin. Di heman demê de, heke tîmek hewceyê dashboardan be, lê ew bi xwe nikaribin / nizanin wiya çawa bikin, em alîkariya wan dikin.

Ji ber ku em li derveyî herikîna afirandina nirxa tîmê, berdan û plansaziya wan in, em gav bi gav digihîjin vê encamê ku berdanên hemî pergalên bêkêmasî ne û dikarin rojane bêyî hevrêziya bi me re werin derxistin. Û ji me re girîng e ku em van berdanan bişopînin, ji ber ku ew bi potansiyel dikarin bandorê li operasyona serîlêdanê bikin û tiştek bişkînin, û ev krîtîk e. Ji bo birêvebirina serbestberdanan, em Bamboo bikar tînin, ku ji wir em bi riya API-ê daneyan distînin û dikarin bibînin ka kîjan berdan di kîjan pergalên agahdariyê de hatine berdan û rewşa wan. Û ya herî girîng di kîjan demê de ye. Em nîşankerên serbestberdanê li ser metrîkên krîtîk ên sereke, ku di bûyera pirsgirêkan de ji hêla dîtbarî ve pir diyarker e, dihejînin.

Bi vî rengî em dikarin pêwendiya di navbera serbestberdanên nû û pirsgirêkên derketinê de bibînin. Fikra sereke ev e ku meriv fêm bike ka pergal di hemî qatan de çawa dixebite, zû pirsgirêkê herêmî bike û bi heman lezê çareser bike. Jixwe, pir caran diqewime ku ya ku herî zêde wext digire ne çareserkirina pirsgirêkê, lê lêgerîna sedemê ye.

Û di vî warî de di paşerojê de em dixwazin giraniyê bidin ser aktîfbûnê. Bi îdeal, ez dixwazim di derbarê pirsgirêkek nêzîk de pêş de bizanim, ne piştî rastiyê, da ku ez bikaribim pêşî lê bigirim ne ku çareser bikim. Carinan alarmên derewîn ên pergala şopandinê çêdibin, hem ji ber xeletiya mirovî û hem jî ji ber guhertinên di sepanê de. Û em li ser vê yekê dixebitin, wê debug dikin, û hewl didin ku bikarhênerên ku wê bi me re bikar tînin li ser vê yekê hişyar bikin berî her manîpulasyonek pergala şopandinê. , an van çalakiyan di pencereya teknîkî de pêk bînin.

Ji ber vê yekê, sîstem hatiye destpêkirin û ji destpêka biharê ve bi serkeftî dixebite ... û qezencên pir rast nîşan dide. Bê guman, ev ne guhertoya wê ya paşîn e; em ê gelek taybetmendiyên bikêrtir destnîşan bikin. Lê naha, digel ewqas entegrasyon û serlêdanan, çavdêriya otomasyona bi rastî neçar e.

Ger hûn jî projeyên mezin ên bi hejmareke girîng a entegrasyonê çavdêrî dikin, di şîroveyan de binivîsin ka we ji bo vê çi guleya zîv dît.

Source: www.habr.com

Add a comment