Konferansa sêyemîn di 7'ê Kanûnê de pêk hat , ji hêla civaka Moskowê DevOps ve bi piştgiriya Mail.ru Cloud Solutions ve hatî organîze kirin. Digel pêşandanên ji hêla bijîjkên pêşeng ên DevOps ve, beşdar dikarin beşdarî Gotûbêjên Lightning-ê yên motîvasyona kurt, atolyeyan bibin û li cîhên vekirî danûstendinê bikin.
Me ji şeş axaftinan zanyariyên girîng berhev kir û bi çend axaftvanan re hevpeyivîn kirin da ku em bizanin ka çi li dû raporan maye.
Nav:
- Baruch Sadogursky, JFrog: "Bila nermalavê ji firoşkar berbi bikarhêner wekî şilavê biherike"
- Pavel Selivanov, Southbridge: "Dev û Ops yek peywirek hevpar heye - çêkirina hilberek ku dixebite"
- Vladimir Utratenko, Koma X5 Retail: "DevOps di Enterprise de pêşkeftina bê êş û agir e"
- Sergey Puzyrev, Facebook: "Endezyarê Hilberînê bi tevahî karûbar eleqedar dike: da ku hem bikarhêner û hem jî pêşdebiran demek xweş derbas bikin"
- Mikhail Chinkov, AMBOSS: "Yek beş nikare riya DevOps bişopîne, divê tevahiya pargîdanî wê bişopîne"
- Hevalên DevOps ên Rosbank: "1000 roj ji bo pêkanîna DevOps di pargîdaniyek xwîndar de"
1. Baruch Sadogursky, JFrog: "Bila nermalava ji firoşkar berbi bikarhêner mîna şilavê biherike"
Têkçûnên nûvekirina nermalavê her demjimêr û ji bo her kesî çêdibin. Li vir tenê çîrokek tirsnak ji axaftinê heye: Knight Capital piştî nûvekirinek neserkeftî di saetekê de 440 mîlyon dolar winda kir.
Baruch li ser şêwazên nûvekirinên domdar ên DevOps-ê ku dê ji têkçûn û nefreta bikarhêner dûr bixin axivî:
Vegera herêmî - Guhertoya berê ya nermalavê li ser cîhaza xwe bihêlin ku heke tiştek diqewime paşde vegere. Ev ê we biparêze ger tişt ew qas xirab bibin ku hûn nikaribin pêçekê bişînin hewayê.
Li ser nûvekirina hewayê - berdewam baştir. Wekî din, ew ê mîna pêşdebirên Jaguar be: ji ber xeletiyek di pergala frenê de, ku nekare li hewa were nûve kirin, pêdivî bû ku otomobîl ji firotanê werin paşve xistin. Bi êş û biha bû.
Nûvekirinên berdewam - Gava ku taybetmendiyek nû amade ye, nermalavê bi domdarî nûve bikin. Digel nûvekirinên kêm, taybetmendî bi hev re têne kom kirin, dibe ku nûvekirinek krîtîk li benda yên ne-krîtîk bin. Mîna di Tesla de, nûvekirinek ku diviya bû şikestinek bêserûber rast bike li benda nûvekirinek lîstika şetrencê bû.
Vekirina otomatîk - mirovan bi makîneyan biguhezînin, ji ber ku mirov di pêkanîna kiryarên rûtîn de xirab in.
Nûvekirinên Frequent - ji we re bibe alîkar ku hûn adetek pêşve bibin û ji tirsê xilas bibin. Nûvekirinên kêm kêm dibin bûyerên awarte.
Dizanin rewşa amûrê - nûvekirinên ceribandinê, ne ji nû ve sazkirinê. Ev girîng e ji ber ku nûvekirin dibe ku li gorî rewşa cîhazê cûda tevbigerin.
Canary berdide - nûvekirinan ji hejmareke piçûk a bikarhêneran re derxînin û temaşe bikin. Ev zirarê kêm dike eger tiştek çewt e.
Nûvekirin bêyî tunebûnê - Bila xerîdar tenê taybetmendiyên nû ferq bikin, û dema ku hûn nûvekirinek derdixin çend hefte bê karûbar nemînin.
Me bi Baruch Sadogursky re axivî ka nêrîna li ser DevOps çawa di IT-ya rûsî û rojavayî de cûda dibe, gelo Cloud dê di demek nêzîk de her tiştî ji me re bike û gelo dê hemî karûbarên nermalavê bikevin nav pilana aaS - li hevpeyvînê temaşe bikin:
2. Pavel Selivanov, Southbridge: "Dev û Ops yek peywira hevpar heye - çêkirina hilberek ku dixebite"
Pêkanîna Kubernetes dê alîkariya bidestxistina DevOps neke, û berevajî, ew dikare her tiştî bişkîne. Pavel diyar kir ku çima teknolojî (tewra ya herî xweş) nikare hemî pirsgirêkên we çareser bike:
Tevliheviya projeyê ji kodê derbas bûye. Berê, serîlêdanek tevlihev hebû: danûstendina di hundurê projeyê û pêşkeftina tevlihev de, lê avahiyek hêsan - rêveberê ew bicîh kir, her tişt dixebite. Em çûn mîkroxizmetan: her karûbar serîlêdanek hêsan e, ragihandina protokolên standard û pêşkeftina bilez e, lê avahiya projeyê tevlihevtir bûye. Tevliheviya projeyek bi mîmariya mîkroxizmetê neçûye - ew ji kodê derbas bûye. Naha endezyar DevOps berpirsiyar e.
Pêşdebir piştî pêkanîna DevOps guhertinan naxwazin. Wekî encamek, herikîna xebatê bi Kubernetes re berdewam dike mîna avêtina peywiran ji Dev-ê berbi Ops-ê li ser dîwarekî, tenê ne mecazî - Git dibe dîwarek wusa. Pêşdebir kodê li wir datîne û wekî berê dixebite, û rêvebiran Kubernetes, CI/CD û her tiştê din hene.
Lêbelê, pêşdebiran hewce ne ku guhertinan qebûl bikin. Rewşek ku pêşdebiran nizanin admîn çi dikin, û admîn nizanin ka bi pêşdebiran re çi diqewime, pirsgirêkan çêdike.
Ger tiştek ji bo pêşdebiran neguherî, ew nizanin ku xebata serîlêdanê berpirsiyariya wan e - fêlên teknîkî yên cihêreng dê nexebitin.
Bi hatina DevOps û Kubernetes re, dê di pêşveçûnê de gelek tişt biguhezin. Divê Devs di Ops û berevajî de jêhatî bin. Van pisporan jêhatîyên xwe yên taybetî hene, lê divê haya wan ji karê hev hebe. Pêdivî ye ku Dev û Ops berî pêkanîna Kubernetes bibin heval, wekî din hûn ê tiştê ku we heye bişkînin.
Pavel Selivanov li ser wê yekê kir ku di nav 5 salan de dê çi were serê Kubernetes û divê destpêkek nûjen li ser çi stûnek teknolojiyê ava bike - li hevpeyvînê temaşe bikin:
3. Vladimir Utratenko, Koma X5 Retail: "DevOps di Enterprise de pêşkeftina bê êş û agir e"
Pargîdan dema ku fêm dikin ku pêşkeftin pir hêdî ye û bi rastiyan re nagihêje hev, digihîjin veguherîna DevOps, daxwazek wan heye ku çêtir pêşde bibin û zûtir bimeşin.
Vladîmîr diyar kir ku ev çawa diqewime û girtina çi ye:
- Pêşîn, pargîdan endezyarek DevOps digirin. Ev Rêvebirê Pergalê yê Bilind e, ew di belavkirina hilberînê de, standardkirina jîngeha pêşkeftinê, sazkirina binesaziyê, tespîtkirin û sererastkirina pirsgirêkên cihêreng, otomatîkkirina pêvajoyên û karên teknîkî yên din de beşdar e.
- Wê hingê yek endezyarek DevOps êdî têrê nake, û pargîdanî tîmek DevOps digire. Ev navendek jêhatî ye ku hewildanên endezyarên cihêreng organîze dike û dihêle ku ew di yek alî de werin berhev kirin.
- Di rastiyê de, endezyarên DevOps û tîmên DevOps li dijî veguherîna DevOps-ê ne. Ji ber ku DevOps di derbarê pratîk û çandê de ye, ji bilî vê, pêkanînên DevOps di pargîdaniyên teknolojiyê de (SRE, Endezyariya Hilberînê) hene.
Çi bikim? Tîmek DevOps-ê ya demkî ya ku dê alîkariya pêkanîna veguherîna DevOps bike, pratîkan bimeşîne, çandek pêşkeftinê û çandek teknolojîk çêbike.
Dema ku karsaziyek dikeve lîstikê û li DevOps veberhênanê dike, çend senaryo mimkun in: dê her tişt di dema rabûnê de ji hev biqelişe; dê wekî SRE / Endezyariya Hilberînê an Vebijarkên Embedded bimîne; dê biçe BizOps, dema ku pêvajoyên li ser pîvanên karsaziyê têne çêkirin.
Vladîmîr Utratenko ji me re got ka DevOps di pargîdaniyek de çiqas "xwîndar" e û çawa pratîk di nav firotgeha mezin de têne bicîh kirin - li hevpeyvînê temaşe bikin:
4. Sergey Puzyrev, Facebook: "Endezyarê Hilberînê bi tevahî xizmetê dike: da ku hem bikarhêner û hem jî pêşdebiran demek xweş derbas bikin"
Facebook pargîdaniyek mezin e, bi hejmareke mezin ji pêkhate, server, mirov û navendên daneyê. Tevî mezinahiya wê ya mezin, ew pir zû ye - pêşdebir dikarin rojê gelek caran karûbaran derxînin. Di heman demê de, Facebook bi lez mezin dibe, û ne tenê hejmara bikarhêner û pêşkêşkeran e ku zêde dibin, hejmara pêşdebiran jî zêde dibe, ku ev pêvajoyan tevlihevtir dike.
Sergey got ku Endezyarek Hilberînê li Facebookê çi dike:
- Endezyarek Hilberînê pir kod dike, pêdivî ye ku ew xwediyê zanîna pergalê be: pergalên xebitandinê, pergalên pelan, databas, toran û yên wekî wan. Pêdivî ye ku ezmûna xebata bi pergalên belavkirî û Endezyariya pêbaweriyê re hebe, ango piştgirîkirina pêbaweriya hilberê. Pêdivî ye ku ew li ser bangê be, ango ji bo bangkirinê di her kêliyê de hebe.
- Endezyarê Hilberînê ji Endezyarê Nermalavê di xebitandinê de jêhatîbûnên pêşkeftî cûda dibe, lê, bi rastî, celebek Endezyarê Nermalavê ye. Endezyarên nermalavê bêtir kod dikin; Li ser Facebookê, pisporên weha jî divê li ser banga xwe bin, ku ji bo gelek kesan surprîzek ne xweş tê.
- Pîramîda hewcedariyên Endezyarek Hilberînê di pargîdaniyek de bi çavdêriya server û çerxa jiyana wan dest pê dike, ango bidestxistina hardware ya nû, sazkirina wê, xistina wê ya xebatê. Asta din di asta karûbarê de heman e: karûbarên çavdêriyê û çerxa jiyana wan. Dûv re pîvandina bêkêmasî û çavdêriya pêşkeftî tê. Ew piştî ku çerxa jiyana karûbarê otomatîk tê veguheztin berbi xweseriyê. Û di dawiyê de, pêdivî ye ku meriv birêkûpêk were kirin da ku pîvandin bi bandor be û pargîdanî drav û çavkaniyan xilas bike.
5. Mikhail Chinkov, AMBOSS: "Yek dezgeh nikare riya DevOps bişopîne, divê tevahiya pargîdanî wê bişopîne"
Mikhail bawer dike ku DevOps pêşveçûna domdar e. Hûn nikarin hin amûran bidin nasîn û li wir rawestin. Kîjan pirsgirêk rê nadin ku pargîdan bibin DevOps û meriv çawa pratîkan bicîh tîne?
Cûdahî di Têgihiştina DevOps de. Devokên Canonical, wekî ku mizgînvan dibînin, li ser 5 stûnan radiweste:
- çand - li ser mirovan û hevkariyê bisekinin;
- otomasyon - şandina rûtîn ji bo xebata xebatê;
- lean - giranî li ser gihandina nirxê ji bikarhêner re;
- parvekirin - pevguhertina domdar a zanînê;
- metrîk û wergirtina bertek bi karanîna wan.
Pargîdan bi gelemperî tenê li ser otomasyonê û gihandina nirxê ji bikarhêner re disekine. Lê çand, parvekirina zanînê, û metrîkên DevOps ji bo şopandina pêşkeftinê di paşde diçin.
Pirsgirêkên Standardkirina DevOps. Armancên hilberê ji bo hemî pargîdaniyan cûda ne û nayên standardîze kirin. Rewşa DevOps di pargîdaniyek de bi pargîdanî bixwe ve girêdayî ye, lê pir kes vê yekê fêm nakin û bawer dikin ku bes e ku meriv endezyarek DevOps bigire.
Çima em hîn ne DevOps in? Du pirsgirêkên sereke hene. Di Enterprise de pêşveçûnek hêdî ya rêxistinê heye, di guheztina vektorê de di hişê bi hezaran karmendan de dijwarî heye. Di destpêkê de, kêmbûna çavkaniyên zanyariyê û pirsgirêkek bi veqetandina çavkaniyan ji bo veguherînê heye.
Qonaxên pêşveçûna DevOps di pargîdaniyek de:
- ya yekem binesaziya di ewr de ye, lê kes nizane ew çawa dixebite ji bilî yek an du rêveberan;
- ya duyemîn, binesaziya ji hemî endezyaran re zelal û têgihîştî ye, lê pêvajo ne hêsan in;
- sêyem - endezyar serbixwe karûbarên zindî dest pê dikin û tamîr dikin;
- çaremîn - endezyar dê vebijarkî beşdarî binesaziya bingehîn, koda zelal a di ewr de, bişkojk veqetandî bibin.
Pîlana îdeal ev e ku her kes xwedan heman gihîştina binesaziyê ye, hemî endezyaran gihîştina hilberê heye û fêm dikin ka ew çi dikin.
Bi girtina hemî gestaltên çandî û teknîkî, veguherîna DevOps ya pargîdanî dê bertekên ji pîvanên karsaziyê û platformê bigire ber çavan.
6. Hevalên DevOps ên Rosbank: "1000 roj ji bo pêkanîna DevOps di pargîdaniyek xwîndar de"
Yuri Bulich, Dina Maltseva, Evgeny Pankov ji Rosbank re got ku ew di sê salan de çawa hatin DevOps. Du armanc hebûn: çareserkirina pirsgirêkên taybetî di tîmên taybetî de û bicîhkirina amûrên navendî.
Li vir encamên ku hatine bidestxistin hene:
Encamên ji bo Tîmên Hilberê: Civîna 30 carî zûtir, 6 carî sazkirinê zûtir, heya 30% teserûf li ser çerxa tevahî. Naha şiyana me heye ku em bişkokek bikirtînin da ku biçin hilberînê
Encamên ji bo fermanên platformê: Civîn û sazkirinê 10 qat zûtir, 87% hejmara sazkirinan zêde, 46% vegirtina xweseriya testê. Tîma entegrasyonê êdî ne bendek e
Ji ber vê yekê, meriv çawa di pargîdaniyek xwîndar de pratîkên DevOps bicîh tîne?
Pêşî projeyek pîlot pêk bînin: Tîmên hilbijêrin, biryar bidin ka meriv çawa mîmariyê bicîh tîne, û amûran hilbijêrin. Me amûrên bi destûrnameyek vekirî, bi sazkirina li bankê û pisporiya xebata bi wan re hilbijart. Rosbank di heman demê de ewrek taybet bi platforma DevOps vekir, û ev di destpêkê de alîkar bû. Di ewr de, gengaz bû ku di 15 hûrdeman de çavkaniyên pêwîst bi dest bixin, pêvajoyek weha dikare hefteyekê bigire;
Di bank û pargîdaniyên din de, pêdivî ye ku meriv bi tîmê ewlehiya agahdarî re pêşî li qedexeyan bixebite û çareseriyek bibîne ku dê destûrê bide guhertinan.
Piştî pîlotê, pêdivî ye ku çareseriyek serfiraz were mezin kirin.
- Girîng e ku meriv boriyê bi qasî ku gengaz "rast bike", girêdanên nepêwist jê rake, pêşkêşkerên nirxê ronî bike, û hêmanên mayî ji holê rake. Navbirî antîpattern in. Mînakî, li Rosbank, çend tîm pêşveçûna hundurîn pêşnexistin, tenê pêşveçûna derveyî hiştin. Vê yekê bû sedema derketina tîmek DevOps-ê ya taybetî, ku veguheztina kodê ji pêşdebirên derveyî ji bo pêşdebirên hundurîn piştrast kir. Pirsgirêk bi entegrekirina pêşkeftina derve di nav CI/CD de hate çareser kirin, da ku ew ne tenê kodê ji xwe veguhezînin bankê, lê di heman demê de ji serkeftina wê jî berpirsiyar bin.
- Modela mezinbûnê hêmanên pratîkên DevOps, amûrên navnîşkirî vedihewîne, û taybetmendiyên xebata bi dabînkerên derveyî re dihewîne - di pêşerojê de, ev alikar kir ku bi lez û bez kêmkirina peywirên paşdemayî dema ku wan di tîmên nû de bicîh bikin.
- Pêdiviya me bi Rêvebiriyê di forma kontrol û pêşniyarên nerm de heye. Destanek DevOps ku baş dixebite komek taybetmendiyên rêxistinî û amûrkirinê ye ku ji tîm re dibe alîkar ku platformê rast bikar bînin.
- Divê hûn tavilê bala xwe bidin çandê, wê hingê gelek guhertin dê zûtir û hêsantir çêbibin. Civaka xweya navxweyî mezin bikin, civîn, atolyeyên teknîkî, perwerdehî û çalakiyên kêfê bikin. Ev fêkiyê dide: mirov pratîkan parve dikin, dibînin kê çi kiriye, zanibin ku li ku derê bizivirin, di nav pargîdaniyê de pêşbazî û pêşbaziyek saxlem heye.
- Ti wateya xebata bi kesên ku di pêvajoyê de ne, bi ekîbên ku mezin nebûne re çêtir e ku meriv di tîmên eleqedar û mirovên dilsoz de veberhênan bike.
- Divê çareseriya hilbijartî ji bo wan endezyarên ku wê bikar tînin rehet be.
- Pêşkeftina derve ne astengker e jî dikare li wir were sepandin, ya sereke ev e ku tîmê bixwe xwedî daxwaz e.
Feydeya piçekî zêdetir
Lîsteya pirtûkên ku hêjayî xwendinê ne ji bo kesên li DevOps, ji Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Vîn û xwekontrol."
- Daniel Kahneman "Fikirîn, Lez û Hêdî".
- Barbara Oakley "A Hiş ji bo Hejmaran".
- Maxim Dorofeev "Teknîkên Jedi".
- Viktor Frankl "Lêgerîna Mirov li Wateyê".
Li bendê bimînin
Em ji DevOps jî hez dikin. Daxuyaniyên rêzefîlmê bişopînin û @Kubernetes, û her weha bûyerên din ên Mail.ru Cloud Solutions, di kanala meya Telegram de:
Source: www.habr.com
