Tê zanîn ku şarezayiya CTO tenê cara duyemîn e ku ew vê rolê dike tê ceribandin. Ji ber ku yek tişt e ku meriv çend salan di pargîdaniyek de bixebite, bi wê re pêş bikeve û, di heman çarçoweya çandî de be, hêdî hêdî berpirsiyariyê bêtir werdigire. Û ev tiştekî din e ku meriv rasterast were pozîsyona rêveberê teknîkî li pargîdaniyek ku bi bagajên mîras û komek pirsgirêk bi rêkûpêk di binê xalîçeyê de ne.

Di vê wateyê de, ezmûna Leon Fire, ku wî li ser parve kir DevOpsConf, ne tam yekta ye, lê ji hêla ezmûna wî û jimara rolên cihêreng ên ku wî di nav 20 salan de hewl da biceribîne, pir bikêr e. Li jêrê birînek kronolojiya bûyerên 90 rojan heye û gelek çîrok hene ku meriv pê dikene dema ku ew bi yekî din re diqewime, lê rûbirûbûna wan ew qas ne xweş e.

Leon bi rûsî pir rengîn dipeyive, ji ber vê yekê heke we 35-40 hûrdem hebe, ez pêşniyar dikim ku vîdyoyê temaşe bikin. Guhertoya nivîsê ku li jêr dem xilas bike.

Guhertoya yekem a raporê ravekirinek birêkûpêk a xebata bi mirov û pêvajoyan re bû, ku tê de pêşniyarên bikêr hene. Lê wê hemû surprîzên ku di rê de rû bi rû hatin negot. Ji ber vê yekê, min format guhert û pirsgirêkên ku di pargîdaniya nû de mîna jack-in-the-box li pêş min derketin, û rêbazên çareserkirina wan bi rêza kronolojîk pêşkêşî min kir.

Berî mehekê

Mîna gelek çîrokên baş, ev yek jî bi alkolê dest pê kir. Em bi hevalan re li barekê rûniştibûn, û wek ku dihat hêvîkirin di nav pisporên IT de, her kes li ser pirsgirêkên xwe digiriya. Yek ji wan tenê kar guhertibû û behsa pirsgirêkên xwe yên bi teknolojiyê, bi mirovan re û bi tîmê re dikir. Her ku min bêtir guhdarî kir, min bêtir fêm kir ku divê ew tenê min bi kar bîne, ji ber ku ev celeb pirsgirêkên ku min di van 15 salên dawî de çareser dikim. Min weha jê re got, û roja din em li hawîrdorek kar hevdu dîtin. Şirket bi navê Teaching Strategies bû.

Stratejiyên Hînkirinê di bernameya dersê de ji bo zarokên pir piçûk ji zayînê heya sê salî pêşengek bazarê ye. Pargîdaniya kevneşopî ya "kaxez" jixwe 40 salî ye, û guhertoya SaaS ya dîjîtal a platformê 10 sal e. Di van demên dawî de, pêvajoya adaptasyona teknolojiya dîjîtal li gorî standardên pargîdaniyê dest pê kir. Guhertoya "nû" di sala 2017-an de dest pê kir û hema hema mîna ya kevn bû, tenê ew xirabtir xebitî.

Tiştê herî balkêş ev e ku seyrûsefera vê pargîdaniyê pir pêşbîn e - roj bi roj, sal bi sal, hûn dikarin pir zelal pêşbînî bikin ka dê çend kes û kengê werin. Mînak, di navbera saet 13 û 15:XNUMX de hemî zarok li baxçeyên zarokan diçin nav nivînan û mamoste dest bi nivîsandina agahiyan dikin. Û ev her roj diqewime, ji bilî dawiya hefteyê, ji ber ku hema bêje kes dawiya hefteyê naxebite.

Piçekî li pêş mêze bikim, ez ê bala xwe bidim ku min di heyama seyrûsefera salane ya herî bilind de dest bi xebata xwe kir, ku ji ber sedemên cûda balkêş e.

Platforma ku dixuya ku tenê 2 salî bû, xwedan stokek taybetî bû: ColdFusion & SQL Server ji 2008-an. ColdFusion, heke hûn nizanin, û bi îhtîmalek mezin hûn nizanin, pargîdaniyek PHP-ê ye ku di nîvê salên 90-an de derketiye, û ji hingê ve min jî jê nebihîstiye. Her weha hebûn: Ruby, MySQL, PostgreSQL, Java, Go, Python. Lê monolîta sereke li ser ColdFusion û SQL Server xebitî.

Pirsgirêkên

Her ku ez bi xebatkarên pargîdaniyê re li ser kar û çi pirsgirêkan dipeyivim, bêtir min fêm kir ku pirsgirêk ne tenê di xwezaya teknîkî de ne. Baş e, teknolojî kevn e - û wan li ser wê nexebitî, lê bi tîmê û bi pêvajoyan re pirsgirêk hebûn, û pargîdanî dest pê kir ku vê yekê fêm bike.

Bi kevneşopî, teknolojiyên wan li quncikê rûniştin û cûreyek kar dikirin. Lê bêtir û bêtir karsazî dest bi guhertoya dîjîtal kir. Ji ber vê yekê, di sala dawîn de berî ku ez dest bi kar bikim, yên nû di pargîdaniyê de derketin: lijneya rêvebir, CTO, CPO û rêveberê QA. Ango şirket dest bi veberhênana sektora teknolojiyê kir.

Şopên mîraseke giran ne tenê di sîsteman de bûn. Şirket xwedî pêvajoyên mîras, mirovên mîras, çanda mîras bû. Diviyabû ev hemû bihatana guhertin. Min fikir kir ku ew ê bê guman ne bêzar be, û biryar da ku ez biceribînim.

Du roj berê

Du roj beriya ku ez dest bi karekî nû bikim, ez hatim ofîsê, kaxezên paşîn tijî kir, tîmê hevdîtin kir, û min dît ku tîmê wê demê bi pirsgirêkek re têdikoşe. Ev bû ku dema barkirina rûpelê navînî 4 çirke, ango 2 car, daket.

Li gorî grafîkê dadbar kirin, tiştek eşkere qewimî, û ne diyar e ku çi. Derket holê ku pirsgirêk derengiya torê ya li navenda daneyê bû: Derengiya 5 ms di navenda daneyê de ji bo bikarhêneran veguherî 2 s. Min nizanibû çima ev çêbû, lê di her rewşê de hate zanîn ku pirsgirêk di navenda daneyê de bû.

Roja pêşîn

Du roj derbas bûn û di roja yekem a xebatê de min dît ku pirsgirêk derneketiye.

Ji bo du rojan, rûpelên bikarhêneran bi navînî di 4 çirkeyan de bar kirin. Ez dipirsim ka wan dît ku pirsgirêk çi ye.

- Belê, me bilêt vekir.
- Û?
- Belê, heta niha bersiva me nedane.

Dûv re min fêm kir ku her tiştê ku berê ji min re hatibû gotin tenê piçûkek piçûk a qeşayê bû ku divê ez şer bikim.

Gotinek baş heye ku bi vê yekê pir xweş tê:

"Carinan ji bo guhertina teknolojiyê divê hûn rêxistinê biguherînin."

Lê ji ber ku min di dema herî qelebalix a salê de dest bi xebatê kir, neçar ma ku ji bo çareserkirina pirsgirêkê li her du vebijarkan binihêrim: hem zû û hem jî demdirêj. Û bi ya ku niha krîtîk e dest pê bikin.

Roja sisiyan

Ji ber vê yekê, barkirin 4 çirkeyan dom dike, û ji 13 heta 15 lûtkeyên herî mezin.

Di roja sêyemîn de di vê heyamê de, leza dakêşanê wiha xuya bû:

Li gorî nêrîna min, qet tiştek nexebitî. Li gorî nêrîna her kesî, ew ji her demê hinekî hêdîtir dimeşiya. Lê ew tenê wusa nabe - pirsgirêkek cidî ye.

Min hewl da ku tîmê razî bikim, ku wan bersiv da ku ew bi tenê hewceyê serverek bêtir in. Ev, bê guman, çareseriyek pirsgirêkê ye, lê her gav ne yekane û herî bi bandor e. Min pirsî çima têra pêşkêşkeran tune, qebareya trafîkê çiqas bû. Min daneyan derxist û dît ku me bi qasî 150 daxwazên serê saniyeyê hene, ku, di prensîbê de, di nav sînorên maqûl de ye.

Lê divê em ji bîr nekin ku berî ku hûn bersiva rast bistînin, divê hûn pirsa rast bipirsin. Pirsa min a din ev bû: çend serverên me yên pêşîn hene? Bersiv "ez piçek şaş kirim" - me 17 serverên pêşîn hebûn!

- Ez şerm dikim ku bipirsim, lê 150 bi 17 ve dabeş dibe 8? Ma hûn dibêjin ku her serverek di çirkeyê de 8 daxwazan dide, û ger sibe di çirkeyê de 160 daxwaz hebin, em ê hewceyê 2 serverên din bin?

Bê guman, hewcedariya me bi serverên zêde tune. Çareserî di kodê bixwe de, û li ser rûyê erdê bû:

var currentClass = classes.getCurrentClass();
return currentClass;

Fonksiyonek hebû getCurrentClass(), ji ber ku her tişt li ser malperê di çarçoveyek polê de dixebite - ew rast e. Û ji bo vê yekê fonksiyonek li ser her rûpelê hebû 200+ daxwazên.

Çareseriya bi vî rengî pir hêsan bû, ne hewce bû ku hûn tiştek ji nû ve binivîsin: tenê dîsa heman agahiyê nepirsin.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Ez pir kêfxweş bûm ji ber ku min biryar da ku tenê di roja sêyemîn de min pirsgirêka sereke dît. Ji ber ku ez neçar bûm, ev tenê yek ji gelek pirsgirêkan bû.

Lê çareserkirina vê pirsgirêka yekem grafîk pir kêmtir daket.

Di heman demê de, me xweşbîniyên din jî dikirin. Li ber çavan gelek tişt hebûn ku dikarin bên sererastkirin. Mînakî, di heman roja sêyem de min vedît ku piştî her tiştî di pergalê de cache heye (destpêkê min fikirîn ku hemî daxwaz rasterast ji databasê dihatin). Dema ku ez li cache difikirim, ez li Redis an Memcached standard difikirim. Lê ez tenê bûm ku wusa difikirîm, ji ber ku wê pergalê MongoDB û SQL Server ji bo cachkirinê bikar anî - heman yek ku daneyên tenê jê dihat xwendin.

Roja deh

Hefteya yekem min bi pirsgirêkên ku hewce ne ku niha çareser bibin re mijûl bûm. Di hefteya duyemîn de, ez yekem car hatim stand-upê da ku bi tîmê re têkiliyê deynim, da ku bibînim ka çi diqewime û tevahiya pêvajo çawa dimeşe.

Tiştekî balkêş dîsa hat dîtin. Tîm ji: 18 pêşdebiran; 8 testers; 3 rêveber; 2 mîmar. Û hemû jî beşdarî ayînên hevpar bûn, ango ji 30î zêdetir kes her sibe dihatin ser stand-upê û digotin ku wan çi kiriye. Eşkere ye ku hevdîtinê 5 û 15 deqe neqedandiye. Kesî guh neda kesî ji ber ku her kes li ser pergalên cûda dixebite. Di vê formê de, 2-3 bilêtên di saetê de ji bo danişîna paqijkirinê jixwe encamek baş bû.

Yekem tiştê ku me kir ev bû ku tîmê li çend xetên hilberandinê veqetandin. Ji bo beş û pergalên cihêreng, me tîmên cihêreng veqetandin, ku tê de pêşdebir, ceribandin, rêveberên hilber û analîstên karsaziyê jî hebûn.

Di encamê de me got:

• Kêmkirina stand-up û mîtîngan.
• Zanîna mijarê ya hilberê.
• Hestek xwedîtiyê. Gava ku mirov her dem bi pergalên xwe ve girêdidin, wan dizanibû ku bi îhtîmalek mezin dê kesek din bi xeletiyên xwe re bixebite, lê ne bi xwe.
• Hevkariya di navbera koman de. Ne hewce ye ku were gotin, QA berê pir bi bernamenûsan re têkilî nedikir, hilber tiştê xwe kir, hwd. Niha xaleke wan a hevpar a berpirsyariyê heye.

Me bi giranî bala xwe da ser karîgerî, hilberandin û kalîteyê - ev pirsgirêkên ku me hewl da ku bi veguherîna tîmê çareser bikin ev in.

Roja yazdeh

Di pêvajoya guheztina strukturên tîmê de, min kifş kir ku meriv çawa bihejmêre ÇîrokPoints. 1 SP bi rojekê re wekhev bû, û her bilêtek hem ji bo pêşkeftinê û hem jî ji bo QA-yê SP-yê dihewand, ango herî kêm 2 SP.

Min ev çawa kifş kir?

Me xeletiyek dît: di yek ji raporan de, ku dîroka destpêk û dawiya heyama ku rapor jê re hewce ye tê nivîsandin, roja paşîn nayê hesibandin. Ango li cihekî di daxwazê ​​de ne <=, lê bi tenê < hebû. Ji min re gotin ku ev sê Xalên Çîrokê ne, yanî 3 ya rojê.

Piştî vê em:

• Sîstema nirxandina Xalên Çîrokê hate guherandin. Naha rastkirinên xeletiyên piçûk ên ku zû di nav pergalê de têne derbas kirin zûtir digihîjin bikarhêner.
• Me dest bi yekkirina bilêtên têkildar ji bo pêşkeftin û ceribandinê kir. Berê, her bilêtek, her xeletiyek ekosîstemek girtî bû, ne bi tiştek din ve girêdayî bû. Guhertina sê bişkokên li ser yek rûpelê dikaribû sê bilêtên cûda bi sê pêvajoyên QA-ya cihêreng li şûna yek ceribandinek otomatîkî ya her rûpelê bûya.
• Me bi pêşdebiran re li ser nêzîkatiyek ji bo texmînkirina lêçûnên kedê dest bi xebatê kir. Sê roj guheztina yek bişkokê ne xweş e.

Roja bîstemîn

Li deverek di nîvê meha yekem de, rewş hinekî aram bû, min fêhm kir ku di bingeh de çi diqewime, û jixwe dest pê kir ku li paşerojê binihêrim û li ser çareseriyên demdirêj bifikirim.

Armancên demdirêj:

• Platforma rêvebirin. Bi sedan daxwazên li ser her rûpelê ne cidî ne.
• Meylên pêşbînîkirî. Pelên trafîkê yên periyodîk hebûn ku di nihêrîna pêşîn de bi metrîkên din re têkildar nedibûn - hewce bû ku em fam bikin ka çima ev çêbû û fêrî pêşbîniyê bibin.
• Berfirehkirina platformê. Karsaz bi domdarî mezin dibe, bêtir û bêtir bikarhêner têne, û seyrûsefer zêde dibe.

Berê gelek caran dihat gotin: "Werin em her tiştî bi [ziman/çarçove] ji nû ve binivîsin, her tişt dê çêtir bixebite!"

Di pir rewşan de ev nexebite, baş e ku ji nû ve nivîsandin bi tevahî bixebite. Ji ber vê yekê, me hewce kir ku nexşeyek rê biafirînin - stratejiyek taybetî ku gav bi gav destnîşan dike ka dê çawa armancên karsaziyê bigihîjin (em ê çi bikin û çima), ku:

• mîsyon û armancên projeyê nîşan dide;
• armancên sereke destnîşan dike;
• ji bo bidestxistina wan bernameyek heye.

Berî vê yekê, ti kesî bi tîmê re li ser armanca guhertinên ku têne çêkirin neaxivî. Ji bo vê yekê pîvanên serkeftinê yên rast hewce dike. Di dîroka pargîdaniyê de yekem car, me KPI ji bo koma teknîkî destnîşan kir, û van nîşanan bi yên rêxistinî ve girêdayî bûn.

Ango, KPI-yên rêxistinî ji hêla tîmê ve têne piştgirî kirin, û KPI-yên tîmê ji hêla KPI-yên kesane ve têne piştgirî kirin. Wekî din, ger KPI-yên teknolojîk bi yên rêxistinî re li hev nekin, wê hingê her kes keriyê li ser xwe dikişîne.

Mînakî, yek ji KPI-yên rêxistinî bi hilberên nû ve para bazarê zêde dike.

Hûn çawa dikarin piştgirî bidin armanca ku bêtir hilberên nû hene?

• Pêşîn, em dixwazin li şûna sererastkirina kêmasiyan bêtir wext derbas bikin da ku hilberên nû pêşve bibin. Ev çareseriyek mentiqî ye ku pîvandina wê hêsan e.
• Ya duyemîn, em dixwazin piştgirî bidin zêdebûna qebareya danûstendinê, ji ber ku her ku para bazarê mezintir be, bêtir bikarhêner û, li gorî vê, seyrûseferek bêtir.

Dûv re KPI-yên ferdî yên ku dikarin di nav komê de bêne darve kirin, dê, mînakî, li cîhê ku kêmasiyên sereke jê têne. Ger hûn bi taybetî li ser vê beşê hûr bibin, hûn dikarin pê ewle bibin ku kêmasiyên pir hindik hene, û wê hingê dema pêşvebirina hilberên nû û dîsa ji bo piştgirîkirina KPI-yên rêxistinî dê zêde bibe.

Bi vî rengî, her biryar, tevî koda ji nû ve nivîsandinê, pêdivî ye ku piştgiriyê bide armancên taybetî yên ku pargîdanî ji me re destnîşan kiriye (mezinbûna rêxistinî, taybetmendiyên nû, peywirdarkirin).

Di vê pêvajoyê de, tiştek balkêş derket holê, ku ne tenê ji bo teknolojiyên, lê bi gelemperî di pargîdaniyê de bû nûçe: Pêdivî ye ku hemî bilêt bi kêmî ve li ser yek KPI-ê were sekinandin. Ango, heke hilberek bêje ku ew dixwaze taybetmendiyek nû çêbike, divê pirsa yekem were pirsîn: "Kîjan KPI ev taybetmendî piştgirî dike?" Heke ne, hingê bibore - ew wekî taybetmendiyek nepêwist xuya dike.

Roja sî

Di dawiya mehê de, min nuwazeyek din kifş kir: çu kesî di tîmê min a Ops de çu carî peymanên ku em bi xerîdaran re dikevin nedîtiye. Hûn dikarin bipirsin çima hûn hewce ne ku têkiliyan bibînin.

• Ya yekem, ji ber ku SLA di peymanan de têne diyar kirin.
• Ya duyemîn, SLA hemî cûda ne. Her xerîdar bi daxwazên xwe re hat, û beşa firotanê bêyî ku binêre îmze kir.

Nîşanek din a balkêş ev e ku peymana bi yek ji mezintirîn xerîdar re diyar dike ku hemî guhertoyên nermalavê yên ku ji hêla platformê ve têne piştgirî kirin divê n-1 bin, ango ne guhertoya herî dawî, lê ya pêşîn.

Eşkere ye ku em çiqas ji n-1 dûr bûn ger platform li ser bingeha ColdFusion û SQL Server 2008 bû, ku di Tîrmehê de êdî qet piştgirî nedihat.

Roja çil û pênc

Nêzîkî nîvê meha duyemîn min têra xwe wextê rûnişt û kirinê hebû giranîherrokMaşallah bi tevahî ji bo tevahiya pêvajoyê. Ev gavên pêwîst in ku divê bêne avêtin, ji afirandina hilberek heya gihandina wê ji bo xerîdar, û pêdivî ye ku ew bi qasî ku gengaz be bi hûrgulî bêne vegotin.

Hûn pêvajoyê di perçeyên piçûk de vediqetînin û dibînin ka çi pir wext digire, çi dikare were xweşkirin, çêtir kirin, hwd. Mînakî, çiqas dem digire da ku daxwazek hilberek bi xêzkirinê derbas bibe, kengê ew digihîje bilêtek ku pêşdebirek dikare bigire, QA, hwd. Ji ber vê yekê hûn bi hûrgulî li her gavek kesane dinêrin û li ser tiştê ku dikare were xweşbîn kirin difikirin.

Dema ku min ev kir, du tişt çavên min ketin:

• rêjeya bilind a bilêtên ku ji QA vedigerin pêşdebiran;
• vekolînên daxwaza kişandinê pir dirêj girt.

Pirsgirêk ev bû ku ev encamên weha bûn: Wusa dixuye ku pir dem digire, lê em nebawer in ka çiqas dirêj.

"Hûn nikarin tiştên ku hûn nikarin bipîvin baştir bikin."

Meriv çawa rast dike ku pirsgirêk çiqas giran e? Ew roj an demjimêr winda dike?

Ji bo pîvandina vê yekê, me du gav li pêvajoya Jira zêde kir: "ji bo dev amade ye" û "ji bo QA amade ye" da ku pîvandin ka her bilêtek çiqas li bendê dimîne û çend caran ew vedigere gavek diyar.

Me "di vekolînê" de jî lê zêde kir da ku hûn zanibin çend bilêtên navînî ji bo vekolînê ne, û ji vê yekê hûn dikarin dest bi dansê bikin. Metrîkên pergalê hebûn, naha me metrîkên nû lê zêde kir û dest bi pîvandinê kir:

• Karbidestiya pêvajoyê: performansa û plankirin / teslîmî.
• Kalîteya pêvajoyê: hejmara kêmasiyan, kêmasiyên ji QA.

Ew bi rastî dibe alîkar ku meriv fêm bike ka çi baş diqewime û çi ne baş e.

Roja pêncî

Ev hemî, bê guman, baş û balkêş e, lê di dawiya meha duyemîn de tiştek qewimî ku, di prensîbê de, pêşbînîkirî bû, her çend min li benda pîvanek wusa nedikir. Ji ber ku rêveberiya jorîn hat guhertin, mirovan dest bi derketinê kirin. Kesên nû ketin rêveberiyê û dest bi guherandina her tiştî kirin, û yên kevin dev jê berdan. Û bi gelemperî di pargîdaniyek ku çend sal salî ye, her kes heval in û her kes hevûdu nas dike.

Ev dihat payîn, lê pîvana jikaravêtinê nediyar bû. Mînakî, di hefteyekê de du serokên tîmê bi îradeya xwe ya azad hevdem îstifayên xwe pêşkêş kirin. Ji ber vê yekê, ez neçar bûm ku ne tenê pirsgirêkên din ji bîr bikim, lê li ser bisekinim tîmek çêbikin. Ev pirsgirêkek dirêj û dijwar e ku were çareser kirin, lê pêdivî bû ku bi wê re were çareser kirin ji ber ku min dixwest mirovên ku mane (an piraniya wan) xilas bikim. Ji bo ku di tîmê de moralê xwe bihêle, hewce bû ku bi rengekî bertek nîşanî rastiya ku mirov çûne.

Di teoriyê de, ev baş e: kesek nû tê ku xwedan kartek bêkêmasî ye, ku dikare jêhatîbûna tîmê binirxîne û karmendan biguhezîne. Bi rastî, hûn nekarin tenê ji ber gelek sedeman mirovên nû bînin. Balans her dem hewce ye.

• Kevin û nû. Pêdivî ye ku em mirovên kal ên ku dikarin mîsyonê biguherînin û piştgirî bikin biparêzin. Lê di heman demê de, pêdivî ye ku em xwînek nû bînin, em ê hinekî paşê li ser biaxivin.
• Tecribe. Min gelek bi xortên baş ên ku dilxwaz bûn û dixwestin bi me re bixebitin re axivîm. Lê min nikarîbû wan bigirim ji ber ku têra xwe kalûpîr tunebûn ku piştgirîya xortan bikin û ji wan re wekî şêwirmend tevbigerin. Pêwîst bû ku pêşî li jor û piştre jî ciwan bihata girtin.
• Xezal û dar.

Ji bo pirsa ku hevsengiya rast çi ye, meriv wê çawa biparêze, çend kes bihêle û çendî biçewisîne, bersivek min a baş tune. Ev pêvajoyek tenê takekesî ye.

Roja pêncî û yekê

Min dest pê kir ku ji nêz ve li tîmê mêze bikim da ku fêm bikim ka kî min heye, û careke din hat bîra min:

"Piraniya pirsgirêkan pirsgirêkên mirovan in."

Min dît ku tîmê wusa - hem Dev û hem jî Ops - sê pirsgirêkên mezin hene:

• Kêfxweşî ji rewşa heyî.
• Nebûna berpirsiyariyê - ji ber ku ti carî encamên xebata performeran neaniye ku bandorê li karsaziyê bike.
• Tirsa guhertinê.

Guhertin her gav we ji qada xweya rehetiyê derdixe, û mirovên ciwan ew qas ji guhertinê hez nakin ji ber ku ew fam nakin çima û ew çawa fam nakin. Bersiva herî gelemperî ku min bihîstiye ev e, "Me tu carî wusa nekiriye." Wekî din, ew gihîşte nuqteya bêaqiliya bêkêmasî - guheztinên herî piçûk bêyî ku kesek aciz bibe çênabe. Û her çi qas guhertinan bandor li karê wan kir jî, mirovan digot: “Na, çima? Ev ê bi ser nekeve."

Lê hûn nikarin bêyî guhartina tiştek çêtir bibin.

Min bi karmendek re danûstendinek bêkêmasî ya bêaqil kir, min ramanên xwe yên ji bo xweşbîniyê jê re got, ku wî ji min re got:
- Ax, te nedît sala borî çi me hebû!
- Başe ku çi?
"Niha ji ya berê pir çêtir e."
- Ango, ew nikare çêtir bibe?
- Ji bo çi?

Pirsa baş - çima? Mîna ku niha ji ya berê çêtir be, wê hingê her tişt têra xwe baş e. Ev dibe sedema nebûna berpirsiyariyê, ku di prensîbê de bi tevahî normal e. Wekî ku min got, koma teknîkî hinekî li kêlekê bû. Pargîdanî bawer kir ku divê ew hebin, lê qet tu kesî pîvanan destnîşan nake. Piştgiriya teknîkî qet SLA nedît, ji ber vê yekê ew ji bo komê pir "qebûl" bû (û ev yek herî zêde li min xist):

• 12 seconds loading;
• 5-10 hûrdeman domdariya her berdanê;
• Çareserkirina pirsgirêkên krîtîk roj û hefteyan digire;
• nebûna personelên peywirê 24x7 / li ser bangê.

Tu carî kesî hewl nedaye ku bipirse ka çima em wiya çêtir nakin, û kesî qet fêm nekir ku ne hewce ye ku bi vî rengî be.

Wekî bonus, pirsgirêkek din jî hebû: nebûna ezmûnê. Mezin çûn, û tîma ciwan a mayî di bin rejîma berê de mezin bû û bi jehrê ket.

Li ser van hemûyan jî mirov ditirsiyan ku bi ser nekevin û bêkêmasî xuya bikin. Ev di rastiyê de diyar dibe ku, pêşî, ew di bin tu şert û mercan de alîkarî nexwest. Çend caran me wek kom û ferdî peyivî, û min got, "Pirsekê bipirse eger tu nizanî tiştekî bikî." Ez bi xwe bawer im û dizanim ku ez dikarim her pirsgirêkek çareser bikim, lê ew ê dem bigire. Ji ber vê yekê, heke ez bikaribim ji kesekî ku dizane di 10 hûrdeman de çareser bike bipirsim, ez ê bipirsim. Tecrûbeya we hindik be, ew qas ditirsin ku hûn bipirsin ji ber ku hûn difikirin ku hûn ê bêkêmasî werin hesibandin.

Ev tirsa pirsan bi awayên balkêş xwe nîşan dide. Mînakî, hûn dipirsin: "Hûn bi vî karî re çawa ne?" - "Çend saet mane, ez jixwe diqedînim." Dotira rojê hûn dîsa bipirsin, hûn bersivê digirin ku her tişt baş e, lê pirsgirêkek hebû, ew ê bê guman heya dawiya rojê amade be. Rojek din derbas dibe, heya ku hûn bi dîwêr ve têne girêdan û neçar dibin ku bi kesek re biaxivin, ev berdewam dike. Mirovek dixwaze pirsgirêkek bi xwe çareser bike, ew bawer dike ku eger ew bi xwe çareser neke dê têkçûnek mezin be.

Ji ber vê yekê pêşdebiran texmîn kirin. Ew heman çîrok bû, dema ku wan li ser karekî nîqaş dikirin, jimarek wusa dan min ku ez pir matmayî mam. Ji min re hat gotin ku di texmînên pêşdebiran de, pêşdebir dema ku dê bilêt ji QA were vegerandin vedihewîne, ji ber ku ew ê li wir xeletiyan bibînin, û dema ku PR dê bigire, û dema kesên ku divê binirxînin. ew ê mijûl be - ango her tişt, çi dibe bila bibe.

Ya duyemîn, mirovên ku ditirsin ku bêkêmasî xuya bikin zêde analîz kirin. Gava ku hûn dibêjin bi rastî çi hewce dike ku were kirin, ew dest pê dike: "Na, heke em li vir li ser wê bifikirin çi dibe?" Di vê wateyê de, pargîdaniya me ne yekta ye; ev ji bo ciwanan pirsgirêkek standard e.

Di bersivê de, min pratîkên jêrîn destnîşan kir:

• Rule 30 deqîqe. Ger hûn nikaribin pirsgirêkê di nîv saetê de çareser bikin, ji kesekî bixwazin ku alîkariyê bike. Ev bi dereceyên cûda yên serfiraziyê dixebite, ji ber ku mirov hîn jî napirsin, lê bi kêmanî pêvajo dest pê kiriye.
• Ji bilî esasê her tiştî ji holê rakin, di texmînkirina maweya qedandina karekî de, ango, tenê bifikire ka ew ê çiqasî dirêj bike ji bo nivîsandina kodê.
• Fêrbûna domdar ji bo kesên ku zêde analîz dikin. Ew tenê karê berdewam bi mirovan re ye.

Roja şêstê

Dema ku min van hemûyan dikir, dem hat ku ez budçeyê bibînim. Bê guman, min gelek tiştên balkêş li cihê ku me pereyên xwe xerc kir dît. Mînakî, me di navendek daneya veqetandî de bi yek serverek FTP re, ku ji hêla yek muwekîlê ve hatî bikar anîn, refikek tevahî hebû. Derket holê ku "... me koç kir, lê ew wisa ma, me ew neguherand." 2 sal berê bû.

Balkêşek taybetî fatûreya karûbarên ewr bû. Ez bawer dikim sedema bingehîn a fatûreya ewr a bilind pêşdebiran e ku di jiyana xwe de yekem car xwedan gihîştina bêsînor a serveran in. Ew ne hewce ne ku bipirsin: "Ji kerema xwe serverek ceribandinê bide min," ew dikarin bixwe bigirin. Zêdeyî, pêşdebir her gav dixwazin pergalek wusa xweş ava bikin ku Facebook û Netflix dê çavnebar bibin.

Lê pêşdebiran di kirîna serveran de û jêhatîbûna diyarkirina mezinahiya pêdivî ya pêşkêşkeran xwedan ezmûn nînin, ji ber ku berê hewcedarê wê nebûn. Û ew bi gelemperî cûdahiya di navbera pîvan û performansê de fêm nakin.

Encamên envanterê:

• Em ji heman navenda daneyê derketin.
• Me peymana bi 3 xizmetên têketinê re betal kir. Ji ber ku me 5 ji wan hebûn - her pêşdebirkerê ku dest bi lîstina tiştek kir yekî nû girt.
• 7 pergalên AWS hatin girtin. Dîsa, tu kes projeyên mirî nesekinîn; hemûyan xebata xwe domandin.
• Mesrefên nermalavê 6 carî kêm kirin.

Roja heftê û pênc

Dem derbas bû, di nav du meh û nîvan de ez neçar bûm ku bi desteya rêvebir re bicivim. Lijneya me ya rêvebir ji yên din ne çêtir û ne xerabtir e, wek hemû desteyên rêvebir dixwaze her tiştî bizanibe. Mirov drav veberhênan dikin û dixwazin fam bikin ka tiştê ku em dikin çiqasî di nav KPI-yên sazkirî de cih digire.

Lijneya rêvebir her meh gelek agahdarî distîne: hejmara bikarhêneran, mezinbûna wan, ew kîjan karûbar û çawa bikar tînin, performans û hilberandin, û di dawiyê de, leza barkirina rûpelê ya navîn.

Pirsgirêk tenê ev e ku ez bawer dikim ku navîn xirabiyek paqij e. Lê ravekirina vê yekê ji lijneya rêveberiyê re gelekî zehmet e. Ew ji bo xebitandina bi hejmarên hevgirtî têne bikar anîn, û ne, wek nimûne, bi belavbûna demên barkirinê di çirkeyê de.

Di vî warî de hin xalên balkêş hebûn. Mînakî, min got ku em hewce ne ku li gorî celebê naverokê seyrûseferê di navbera serverên malperê yên cihêreng de veqetînin.

Ango, ColdFusion di Jetty û nginx re derbas dibe û rûpelan vedike. Û wêne, JS û CSS bi mîhengên xwe ve di nginxek cihêreng re derbas dibin. Ev pratîkek pir standard e ku ez qala wê dikim nivîsand çend sal berê. Wekî encamek, wêne pir zûtir bar dikin, û ... leza barkirinê ya navîn 200 ms zêde bûye.

Ev çêbû ji ber ku graf li ser bingeha daneyên ku bi Jetty re têne çêkirin. Ango, naveroka bilez di nav hesaban de nayê kirin - nirxa navîn hilkişiyaye. Ev ji me re zelal bû, em keniyan, lê em çawa dikarin ji civata rêvebir re rave bikin ka çima me tiştek kir û tişt %12 xirabtir bûn?

Roja heştê û pênc

Di dawiya meha sêyemîn de, min fêm kir ku tiştek heye ku min qet hesab nekiribû: dem. Her tiştê ku min qala wê kir wext digire.

Ev salnameya min a heftane ya rastîn e - tenê hefteyek kar, ne pir mijûl. Ji bo her tiştî dem têrê nake. Ji ber vê yekê, dîsa, hûn hewce ne ku mirovên ku dê ji we re bibin alîkar ku hûn bi pirsgirêkan re rûbirû bibin bicivînin.

encamê

Ev ne hemû. Di vê çîrokê de, min negihîşte wê yekê ku me çawa bi hilberê re xebitî û hewl da ku em bi pêla gelemperî re têkildar bibin, an me çawa piştgiriya teknîkî yekgirtî kir, an me çawa pirsgirêkên teknîkî yên din çareser kir. Mînakî, ez bi tesadufî fêr bûm ku li ser tabloyên herî mezin ên databasê em bikar naynin SEQUENCE. Fonksiyonek me ya xweser heye nextID, û ew di danûstendinê de nayê bikar anîn.

Bi mîlyonan tiştên din ên mîna wan hebûn ku em dikarin demek dirêj li ser biaxivin. Lê ya herî girîng ya ku hîn divê bê gotin çand e.

Ew çand an nebûna wê ye ku dibe sedema hemî pirsgirêkên din. Em hewl didin ku çandek wisa ava bikin ku mirov:

• ji têkçûnan natirsin;
• ji xeletiyan fêr bibin;
• bi tîmên din re hevkariyê bikin;
• însiyatîf bigirin;
• berpirsiyariya xwe bigirin;
• encamê wek armanc pêşwazî bikin;
• serkeftinê pîroz dikin.

Bi vê yekê re her tişt wê were.

Leon Fire li ser twitter, facebook û li ser medya.

Di derbarê mîrasê de du stratejî hene: bi her awayî bi wê re bixebitin, an jî bi wêrekî zehmetiyên têkildar derbas bikin. Em c DevOpsConf Em rêya duyemîn dimeşin, pêvajo û nêzîkatiyan diguherînin. Tevlî me bibin youtube, nûçenameya и têlxiram, û bi hev re em ê çandek DevOps bicîh bikin.

Source: www.habr.com