Silav Habr! Ez deh salan piştgirî didim pergalên IT-ya Highload. Ez ê di vê gotarê de li ser pirsgirêkên sazkirina nginx-ê nenivîsim ku di moda 1000+ RPS-ê de an tiştên teknîkî yên din de bixebite. Ez ê çavdêriyên xwe yên li ser pirsgirêkên pêvajoyên ku di piştgirî û xebitandina pergalên bi vî rengî de derdikevin, parve bikim.
Ingopandin
Piştgiriya teknîkî li bendê namîne heya ku daxwazek bi naveroka "Çima Çima ... malper dîsa naxebite?" Di nav hûrdemek piştî têkçûna malperê de, pêdivî ye ku piştgirî jixwe pirsgirêkê bibîne û dest bi çareserkirina wê bike. Lê malper serê befrê ye. Hebûna wê yek ji yekem e ku tê şopandin.
Dema ku tiştên mayî yên firotgehek serhêl êdî ji pergala ERP nayên bi rewşê re çi bikin? An jî pergala CRM ya ku dakêşan ji bo xerîdaran hesab dike bersivdayînê rawestandiye? Malper xuya dike ku dixebite. Zabbix bi şert 200 bersiva xwe distîne. Veguheztina peywirê ji çavdêriyê tu agahdarî negirtiye û bi kêfxweşî li beşa yekem a sezona nû ya Game of Thrones temaşe dike.
Çavdêrî bi gelemperî tenê bi pîvandina rewşa bîra, RAM û barkirina pêvajoya serverê ve tête sînor kirin. Lê ji bo karsaziyê pir girîng e ku meriv hebûna hilberê li ser malperê bigire. Têkçûna şertî ya yek makîneya virtual ya di komê de dê bibe sedema vê yekê ku seyrûsefer dê ber bi wê ve raweste û barkirina li ser serverên din dê zêde bibe. Pargîdanî dê drav winda neke.
Ji ber vê yekê, ji bilî çavdêriya pîvanên teknîkî yên pergalên xebitandinê yên li ser serveran, hûn hewce ne ku pîvanên karsaziyê mîheng bikin. Metrîkên ku rasterast bandorê li drav dikin. Têkiliyên cihêreng bi pergalên derveyî (CRM, ERP û yên din). Hejmara fermanan ji bo demek diyarkirî. Destûrnameyên xerîdar ên serketî an neserkeftî û pîvanên din.
Têkiliya bi pergalên derveyî re
Her malper an serîlêdana desta ya ku xwedan berberiya salane ya zêdetirî mîlyar ruble ye, bi pergalên derveyî re têkildar dibe. Ji CRM û ERP-ya jorîn dest pê dike û bi veguheztina daneyên firotanê ber bi pergalek Daneyên Mezin ên derveyî ve ji bo analîzkirina kirînan û pêşkêşkirina xerîdar hilberek ku ew ê bê guman bikire (bi rastî, ne) bi dawî dibe. Her sîstemeke wisa xwedî piştgiriya xwe ye. Û pir caran danûstandina bi van pergalan re dibe sedema êşê. Bi taybetî dema ku pirsgirêk gerdûnî ye û hûn hewce ne ku wê di pergalên cûda de analîz bikin.
Hin pergal ji bo rêvebirên xwe jimareyek têlefon an telegram peyda dikin. Li cîhek hûn hewce ne ku ji rêveberan re nameyan binivîsin an biçin şopînerên xeletiyên van pergalên derveyî. Tewra di çarçoveya yek pargîdaniyek mezin de, pergalên cihêreng bi gelemperî di pergalên hesabkirina serîlêdana cihêreng de dixebitin. Carinan şopandina rewşa serîlêdanê ne mumkun dibe. Hûn daxwazek di yek Jira şert de distînin. Dûv re di şîroveya vê Jira yekem de we lînka pirsgirêkê li Jîrayek din danî. Di Jira duyemîn de di serîlêdanê de, kesek jixwe şîroveyek wê dinivîse hûn hewce ne ku gazî adminê şertî Andrey bikin da ku pirsgirêkê çareser bikin. Û vî awayî.
Çareseriya çêtirîn ji bo vê pirsgirêkê dê avakirina cîhek yekane ji bo ragihandinê be, mînakî di Slack de. Vexwendina hemî beşdarên di pêvajoya xebitandina pergalên derve de ku tevlê bibin. Û her weha şopek yekane da ku serîlêdanan dubare nekin. Pêdivî ye ku serîlêdan li yek cîhek werin şopandin, ji agahdariya çavdêriyê bigire heya derketina çareseriyên xeletiyê di pêşerojê de. Hûn ê bêjin ku ev ne rast e û di dîrokê de qewimî ku em di şopekek de dixebitin, û ew di yekî din de dixebitin. Pergalên cihêreng xuya bûn, wan tîmên xwe yên IT-ya xweser hebûn. Ez razî me, û ji ber vê yekê pêdivî ye ku pirsgirêk ji jor ve di asta CIO an xwediyê hilberê de were çareser kirin.
Her pergala ku hûn pê re têkilî daynin divê wekî karûbarek bi SLA-ya zelal piştgirî peyda bike da ku pirsgirêkan ji hêla pêşîn ve çareser bike. Û ne gava ku adminê şertî Andrey ji we re deqeyek heye.
Bottleneck Man
Ma her kesê li ser projeyek (an hilberek) kesek heye ku çûna betlaneyê di nav serekên wan de dibe sedema tevliheviyan? Ev dibe ku endezyar, analîstek an pêşdebirek devops be. Beriya her tiştî, tenê endezyarek devops dizane ku kîjan server kîjan konteyneran saz kirine, di rewşek pirsgirêkê de meriv çawa konteynerê ji nû ve dest pê dike, û bi gelemperî, her pirsgirêkek tevlihev bêyî wî nayê çareser kirin. Analyst yekane ye ku dizane mekanîzmaya weya tevlihev çawa dixebite. Kîjan herikên daneyê diçin ku derê. Di binê kîjan pîvanên daxwazan de ji kîjan karûbaran re, em ê bersiva kîjanan bistînin.
Kî dê zû fêm bike ka çima di têketinan de xeletî hene û tavilê xeletiyek krîtîk di hilberê de rast bike? Bêguman heman pêşdebirker. Yên din hene, lê ji ber hin sedeman tenê ew fam dike ka modulên cihêreng ên pergalê çawa dixebitin.
Koka vê pirsgirêkê nebûna belgeyan e. Beriya her tiştî, heke hemî karûbarên pergala we were diyar kirin, wê hingê ew ê bêyî analîstek bi pirsgirêkê re mijûl bibe. Ger devops çend roj ji bernameya xwe ya mijûl derxe û hemî server, karûbar û rêwerzên ji bo çareserkirina pirsgirêkên tîpîk diyar bike, wê hingê pirsgirêk di nebûna wî de bêyî wî were çareser kirin. Hûn ne hewce ne ku hûn di dema betlaneyê de zû bîraya xwe li ser golê biqedînin û li wi-fi bigerin da ku pirsgirêkê çareser bikin.
Karîn û berpirsiyariya karmendên piştgirî
Li ser projeyên mezin, pargîdan li ser mûçeyên pêşdebiran kêm nakin. Ew ji projeyên wekhev li navîn an kalûpîrên biha digerin. Bi piştgirîyê rewş hinekî cuda ye. Bi her awayî hewl didin van lêçûnan kêm bikin. Pargîdan karkerên erzan ên duh ên Enikey digirin û bi wêrekî dikevin şer. Ger em li ser malperek qerta karsaziyê ya nebatek li Zelenograd biaxivin ev stratejî mimkun e.
Ger em behsa firotgehek serhêl a mezin dikin, wê hingê her demjimêrek domdar ji mûçeya mehane ya rêveberek Enikey bêtir lêçû. Werin em 1 mîlyar ruble ji cîroya salane wekî xala destpêkê bigirin. Ev herî kêm dorhêla her firotgeha serhêl a ji rêzê ye . Vê mîqdarê salê bi hejmara demjimêran dabeş bikin û ji 100 rubleyan zêdetir windahiyên netîce bistînin. Û heke hûn demjimêrên şevê nehesibînin, hûn dikarin bi ewlehî mîqdarê ducar bikin.
Lê pere ne ya sereke ye, rast? (na, bê guman ya sereke) Di heman demê de windahiyên navdar jî hene. Hilweşîna firotgehek serhêl a naskirî dikare hem bibe sedema pêlek nirxandinan li ser torên civakî û hem jî weşanên di medyaya mijarê de. Û sohbetên hevalan ên di mitbaxê de bi şêwaza "Li wir tiştek nekirin, malpera wan her dem xera ye" qet nayê pîvandin.
Niha li ser berpirsiyariyê. Di pratîka min de, bûyerek hebû ku rêveberê peywirdar di wextê xwe de bersiv neda agahiyek ji pergala çavdêriyê ya di derbarê tunebûna malperê de. Di êvara înê ya havînê ya xweş de, malpera firoşgehek serhêl a navdar li Moskowê bêdeng ma. Sibeha Şemiyê, gerînendeyê hilberê vê malperê fêm nekir çima malper venebû, û di piştgirî û danûstendinên agahdarkirina bilez de li Slack bêdengiyek hebû. Xeletiyeke wiha ji me re 6 reqeman e û ev efserê peywirê jî karê wî ye.
Berpirsiyarî jêhatîbûnek dijwar e ku meriv pêşve bibe. An mirov heye an na. Ji ber vê yekê, di dema hevpeyivînan de, ez hewl didim hebûna wê bi pirsên cûrbecûr ve nas bikim ku nerasterast nîşan didin ka gelo mirov fêrî berpirsiyariyê ye an na. Ger mirovek bersivê bide zanîngehek hilbijart ji ber ku dê û bavê wî weha gotine an jî ji ber ku jina wî gotiye ku ew têra xwe qezenc nake, karê xwe biguherîne, wê demê çêtir e ku bi kesên weha re mijûl nebe.
Têkilî bi tîmê pêşveçûnê re
Dema ku bikarhêner di dema xebatê de bi hilberek re bi pirsgirêkên hêsan re rû bi rû dimînin, piştgirî wan bi xwe çareser dike. Hewl dide ku pirsgirêkê ji nû ve hilberîne, têketin analîz dike û hwd. Lê gava ku xeletiyek di hilberê de xuya dibe çi bike? Di vê rewşê de, piştgirî peywirê dide pêşdebiran û li vir kêfê dest pê dike.
Pêşdebir bi berdewamî zêde têne barkirin. Ew taybetmendiyên nû diafirînin. Rastkirina xeletiyên bi firotanê ne çalakiya herî balkêş e. Demjimêr nêzîk dibin ku sprinta din temam bikin. Dûv re kesên ji piştgirîyê ne xweş têne û dibêjin: "Tiştê tavilê berdin, pirsgirêkên me hene." Pêşîniya karên weha hindik e. Nemaze gava ku pirsgirêk ne ya herî krîtîk e û fonksiyona sereke ya malperê dixebite, û dema ku rêveberê berdanê bi çavên gemarî li dora xwe nagere û nanivîse: "Bi lezgînî vê peywirê li serbestberdana paşîn an serrastkirinê zêde bike."
Pirsgirêkên bi pêşengiya normal an kêm ji berdanê ber bi berdanê ve têne veguhestin. Ji bo pirsa "Wê kengê kar biqede?" hûn ê bersivên bi şêwazê werbigirin: "Bibore, niha gelek peywir hene, ji serokên tîmê xwe bipirsin an rêvebirê serbest berdan."
Pirsgirêkên hilberandinê ji afirandina taybetmendiyên nû pêşanîtir digirin. Nirxên xirab dê demek dirêj nemînin ger bikarhêner bi domdarî li xeletiyan bikevin. Navûdengek xerabûyî dijwar e ku were vegerandin.
Pirsgirêkên pêwendiya di navbera pêşveçûn û piştgirî de ji hêla DevOps ve têne çareser kirin. Ev kurtasî bi gelemperî di forma kesek taybetî de tête bikar anîn ku ji bo pêşveçûnê hawîrdorên ceribandinê diafirîne, lûleyên CICD ava dike û zû koda ceribandinê tîne hilberînê. DevOps nêzîkatiyek ji bo pêşkeftina nermalavê ye dema ku hemî beşdarên pêvajoyê ji nêz ve bi hevûdu re têkilî daynin û bibin alîkar ku zû hilber û karûbarên nermalavê biafirînin û nûve bikin. Mebesta min analîst, pêşdebir, ceribandin û piştgirî ye.
Di vê nêzîkatiyê de, piştgirî û pêşveçûn ne dezgehên cûda yên bi armanc û armancên xwe ne. Pêşveçûn bi operasyonê ve girêdayî ye û berevajî. Gotina navdar a tîmên belavbûyî: "Pirsgirêk ne li ser milê min e" êdî di sohbetan de pir caran xuya nake, û bikarhênerên dawîn hinekî kêfxweş dibin.
Source: www.habr.com