Rêveberê Karûbarên Portala Banki.ru Andrey Nikolsky di konferansa sala borî de axivî di derbarê karûbarên sêwî de: meriv çawa sêwîyek di binesaziyê de nas bike, çima karûbarên sêwî xirab in, bi wan re çi bikin, û heke tiştek ne alîkar be divê çi bikin.
Li jêr birîn guhertoya nivîsê ya raporê heye.
Silav hevalno! Navê min Andrey e, ez li Banki.ru-yê kar dikim.
Xizmetên me yên mezin hene, ev xizmetên yekparêz in, di wateya klasîk de xizmet hene û yên pir piçûk jî hene. Di termînolojiya xwe ya karker-gundî de ez dibêjim ger xizmetek hêsan û piçûk be, mîkro ye û heke ne pir hêsan û piçûk be, tenê xizmetek e.
Pros yên xizmetên
Ez ê zû li ser avantajên karûbaran biçim.
Ya yekem scaling e. Hûn dikarin zû li ser karûbarê tiştek bikin û hilberînê dest pê bikin. We seyrûsefer wergirtiye, we karûbar klon kiriye. We bêtir seyrûsefera we heye, we ew klon kiriye û pê re dijîn. Ev bonusek baş e, û, di prensîbê de, dema ku me dest pê kir, ew ji bo me ya herî girîng hate hesibandin, çima em van hemîyan dikin.
Ya duyemîn, pêşkeftina veqetandî, dema ku we çend tîmên pêşkeftinê hene, di her tîmekê de çend pêşdebirên cihêreng hene, û her tîm karûbarê xwe pêş dixe.
Bi tîman re nuwazeyek heye. Pêşdebir cuda ne. Û hene, wek nimûne, . Min ev yekem bi Maxim Dorofeev re dît. Carinan mirovên berfê li hin tîman in û ne li yên din in. Ev karûbarên cihêreng ên ku li seranserê pargîdaniyê têne bikar anîn hinekî nehevdeng dike.
Li wêneyê binêrin: ev pêşdebirek baş e, destên wî yên mezin hene, ew dikare gelek tiştan bike. Pirsgirêka sereke ev e ku ev dest ji ku derê têne.
Karûbar dihêle ku hûn zimanên bernamenûs ên cihêreng ên ku ji bo karên cihêreng maqûltir in bikar bînin. Hin karûbar di Go de ye, hinek li Erlang e, hin di Ruby de, tiştek di PHP de, tiştek di Python de ye. Bi gelemperî, hûn dikarin pir berfireh berfireh bikin. Li vir jî nuwaze hene.
Mîmariya-xizmetkar di serî de li ser devops e. Ango, heke we otomasyon tune be, pêvajoyek bicîhkirinê tune ye, heke hûn wê bi destan mîheng bikin, vesazên we dikarin ji mînaka karûbar heya mînakek biguhezin, û hûn neçar in ku biçin wir da ku tiştek bikin, wê hingê hûn di dojehê de ne.
Mînakî, 20 karûbarên we hene û hûn hewce ne ku hûn bi destan bicîh bikin, 20 konsolên we hene, û hûn di heman demê de mîna ninjak "enter"-ê pêl dikin. Ew ne pir baş e.
Ger piştî ceribandinê karûbarek we hebe (bê guman heke ceribandin hebe), û hûn hîn jî hewce ne ku wê bi pelê biqedînin da ku ew di hilberînê de bixebite, min jî ji we re nûçeyên xirab hene.
Ger hûn xwe dispêrin karûbarên taybetî yên Amazon û li Rûsyayê dixebitin, wê hingê du meh berê we jî hebû "Her tişt li dora agir e, ez baş im, her tişt xweş e."
Em Ansible bikar tînin da ku bicîhkirinê bixweber bikin, Puppet ji bo hevgirtinê, Bamboo ji bo sazkirina otomatîkî, û Confluence bikar bînin da ku bi rengekî hemî wê rave bikin.
Ez ê li ser vê yekê bi hûrgulî nesekinim, ji ber ku rapor bêtir li ser pratîkên danûstendinê ye, û ne li ser pêkanîna teknîkî ye.
Mînakî, me pirsgirêkên ku Puppet li ser serverê bi Ruby 2 re dixebite hene, lê hin serîlêdan ji bo Ruby 1.8 hatî nivîsandin, û ew bi hev re naxebitin. Li wir tiştek xelet dibe. Û gava ku hûn hewce ne ku gelek guhertoyên Ruby li ser yek makîneyê bimeşînin, hûn bi gelemperî dest bi pirsgirêkan dikin.
Mînakî, em ji her pêşdebir re platformek didin ku li ser wê hema hema her tiştê me heye, hemî karûbarên ku dikarin werin pêşve xistin, da ku ew xwedan hawîrdorek veqetandî be, ew dikare wê bişkîne û wekî ku dixwaze ava bike.
Diqewime ku hûn hewceyê pakêtek taybetî ya berhevkirî bi piştgirî ji bo tiştek li wir in. Ew pir dijwar e. Min li raporek guhdarî kir ku wêneya Docker 45 GB giran e. Di Linux-ê de, bê guman, ew hêsan e, her tişt li wir piçûktir e, lê dîsa jî, dê cîhê têr nebe.
Welê, girêdanên nakokî hene, gava ku perçeyek projeyê bi pirtûkxaneyek guhertoyek ve girêdayî ye, perçeyek din a projeyê bi guhertoyek din ve girêdayî ye, û pirtûkxane qet bi hev re nayên saz kirin.
Di PHP 5.6 de malper û karûbarên me hene, em ji wan şerm dikin, lê em dikarin çi bikin? Ev yek malpera me ye. Li ser PHP 7 malper û karûbar hene, ji wan zêdetir in, em ji wan şerm nakin. Û her pêşdebir bingeha xwe ya ku ew bi kêfxweşî dîtiye heye.
Ger hûn di pargîdaniyek de bi yek zimanî binivîsin, wê hingê sê makîneyên virtual her pêşdebiran normal xuya dikin. Ger zimanên we yên bernamenûsê yên cûda hebin, wê hingê rewş xirabtir dibe.
Li ser vê yekê we malper û karûbarên we hene, li ser vê yekê, dûv re malperek din ji bo Go, malperek ji bo Ruby, û hin Redisên din li kêlek. Wekî encamek, ev hemî ji bo piştgiriyê vediguhere qadek mezin, û her dem hin jê dikare bişkîne.
Ji ber vê yekê, me feydeyên zimanê bernamesaziyê bi karanîna çarçoveyên cihêreng veguhezand, ji ber ku çarçoveyên PHP-ê pir cûda ne, wan xwedî kapasîteyên cihêreng, civakên cihêreng û piştgirîyek cihê ne. Û hûn dikarin karûbarek binivîsin da ku hûn jixwe tiştek ji bo wê amade ne.
Her xizmetek tîmek xwe heye
Feydeya meya sereke, ku di çend salan de krîstalîze bûye, ev e ku her karûbar tîmê xwe heye. Ev ji bo projeyek mezin rehet e, hûn dikarin wextê li ser belgekirinê hilînin, rêveber projeya xwe baş dizanin.
Hûn dikarin bi hêsanî peywiran ji piştgirîyê bişînin. Ji bo nimûne, xizmeta sîgorteyê hilweşand. Û tavilê ekîba ku bi sîgorteyê re mijûl dibe diçe wê rast bike.
Taybetmendiyên nû zû têne afirandin, ji ber ku gava we yek karûbarek atomî hebe, hûn dikarin zû tiştek têxin nav wê.
Û gava ku hûn karûbarê xwe dişkînin, û ev yek bê guman diqewime, we bandor li ser karûbarên mirovên din nekir, û pêşdebirên tîmên din bi bitikan naçin ba we û nabêjin: "Ay-ay, wiya neke."
Wekî her gav, nuwaze hene. Tîmên me yên bi îstîqrar hene, rêvebir bi tîmê ve girêdayî ne. Belgeyên zelal hene, rêvebir ji nêz ve her tiştî dişopînin. Her tîmek bi rêveberek xwedan gelek karûbar hene, û xalek jêhatî ya taybetî heye.
Ger tîm diherikin (em carinan vê yekê jî bikar tînin), rêbazek baş heye ku jê re "nexşeya stêrk" tê gotin.
Te navnîşek karûbar û kesan heye. Stêrk tê wateya ku mirov di vê xizmetê de pispor e, pirtûk tê wateya ku mirov vê xizmetê dixwîne. Karê mirov ew e ku pirtûkê ji bo stêrkê biguherîne. Û heke tiştek li ber karûbarê neyê nivîsandin, wê hingê pirsgirêk dest pê dikin, ku ez ê bêtir li ser biaxivim.
Xizmetên sêwî çawa xuya dikin?
Pirsgirêka yekem, riya yekem a ku hûn di binesaziya xwe de karûbarek sêwî bistînin ev e ku mirov ji kar derxînin. Ma çu carî karsaziyek berî ku kar werin nirxandin bernameyên xwe bicivîne? Carinan diqewime ku muhlet teng in û ji bo belgekirinê dem têr nake. "Divê em karûbarê radestî hilberînê bikin, paşê em ê lê zêde bikin."
Ger tîm piçûk be, diqewime ku pêşdebirek heye ku her tiştî dinivîse, yên mayî di baskan de ne. "Min mîmariya bingehîn nivîsand, bila navberan lê zêde bikin." Dûv re di hin xalan de rêveber, wek nimûne, derdikeve. Û di vê heyamê de, dema ku rêveber derketiye û hîna yekî nû nehatiye tayîn kirin, pêşdebir bixwe biryar didin ku karûbar diçe ku derê û li wir çi diqewime. Û wek ku em dizanin (em vegerin çend slaytan), di hin tîman de mirovên berfê hene, carinan jî serokê tîmê berfê hene. Dûv re ew dev jê berdide, û em xizmetek sêwî distînin.
Di heman demê de, peywirên ji piştgirî û ji karsaziyê winda nabin; ew di paşketinê de diqedin. Ger di dema pêşkeftina karûbarê de xeletiyên mîmarî hebin, ew jî di paşdemayînê de diqedin. Xizmet hêdî hêdî xirab dibe.
Meriv çawa sêwîyek nas dike?
Ev lîste rewşê baş diyar dike. Kî di derbarê binesaziya wan de tiştek fêr bû?
Di derbarê xebata belgekirî de: karûbarek heye û, bi gelemperî, ew dixebite, pirtûkek du-rûpelî heye ka meriv çawa bi wê re dixebite, lê kes nizane ew di hundurê de çawa dixebite.
An jî, wek nimûne, celebek kurtkirina girêdanê heye. Mînakî, me niha sê kurtkerên girêdanê hene ku ji bo armancên cûda di karûbarên cihêreng de têne bikar anîn. Ev tenê encam in.
Niha ez ê bibim kaptanê eşkere. Divê çi bê kirin? Pêşîn, em hewce ne ku karûbarê ji rêveberek din, tîmek din re veguhezînin. Ger rêberiya tîmê we hîn dev jê bernedaye, wê hingê di vê tîmê din de, gava ku hûn fêm bikin ku karûbar mîna sêwî ye, hûn hewce ne ku kesek ku bi kêmanî tiştek jê fam dike têxin nav xwe.
Ya sereke: divê hûn prosedurên veguheztinê bi xwînê werin nivîsandin. Di doza me de, ez bi gelemperî çavdêriya vê dikim, ji ber ku ez hewce dikim ku ew hemî bixebitim. Rêvebir hewce dike ku ew zû were radest kirin, û tiştê ku paşê tê serê wan êdî ji wan re ne ew qas girîng e.
Awayê din ku meriv sêwî bike ev e "Em ê wê bi derve re bikin, ew ê zûtir be, û paşê em ê radestî tîmê bikin." Eşkere ye ku her kes di tîmê de hin planên xwe hene, zivirîn. Bi gelemperî xerîdarek karsaziyê difikire ku dervî çavkanî dê heman tiştê ku beşa teknîkî ya ku pargîdanî heye bike. Tevî ku motîvatorên wan cuda ne. Di derve de çareseriyên teknolojîk ên ecêb û çareseriyên algorîtmîkî yên xerîb hene.
Mînakî, karûbarek me hebû ku Sphinx li deverên cihêreng ên nediyar hebû. Ez ê paşê ji we re bibêjim ku ez çi bikim.
Çavkaniyên derveyî xwedan çarçoveyên xwe-nivîsandî ne. Ev tenê PHP-ya tazî bi kopî-paste ji projeyek berê ye, ku hûn dikarin her cûre tiştan bibînin. Dema ku hûn hewce ne ku hin nivîsarên tevlihev ên Bash bikar bînin da ku hûn çend rêzan di pelê de biguhezînin, skrîptên bicîhkirinê kêmasiyek mezin in, û van nivîsarên bicîhkirinê ji hêla hin tîpek sêyemîn ve têne gazî kirin. Wekî encamek, hûn pergala bicîhkirinê diguherînin, tiştek din hilbijêrin, hop bikin, lê karûbarê we nexebite. Ji ber ku li wir hewce bû ku 8 girêdanên din di navbera peldankên cûda de bêne danîn. An jî diqewime hezar tomar kar dikin, lê sed hezar jî êdî naxebitin.
Ez ê serweriya xwe bidomînim. Qebûlkirina karûbarek derveyî pêvajoyek mecbûrî ye. Ma çu carî kesek karûbarek jêderkirî gihîştiye û li deverek nehatiye pejirandin? Ev ne ewqas populer e, bê guman, wekî karûbarê sêwî, lê dîsa jî.
Pêdivî ye ku karûbar were kontrol kirin, pêdivî ye ku karûbar were vekolîn, şîfre bêne guhertin. Me bûyerek hebû ku wan karûbarek da me, panelek rêveberiyê heye "ger têketin == 'rêvebir' && şîfre == 'rêveber'...", ew rast di kodê de hatî nivîsandin. Em rûniştin û difikirin, û mirov vê yekê di sala 2018 de dinivîsin?
Testkirina kapasîteya hilanînê jî tiştek pêdivî ye. Pêdivî ye ku hûn lê binêrin ka dê li ser sed hezar tomar çi bibe, tewra berî ku hûn vê karûbarê li cîhek hilberînê bikin.
Di şandina karûbarek ji bo çêtirkirinê divê şerm nebe. Dema ku hûn dibêjin: "Em vê xizmetê qebûl nakin, 20 karên me hene, bikin, paşê em ê qebûl bikin," ev normal e. Divê wijdanê we ji ber ku hûn rêveberek saz dikin an karsaziyek dravê winda dike, zirarê neke. Wê hingê karsaz dê bêtir xerc bikin.
Dema ku me biryar da ku em projeyek pîlotê derxin holê, bûyerek me hebû.
Ew di wextê xwe de hate radest kirin, û ev pîvana kalîteyê tenê bû. Ji ber vê yekê me projeyek din a pîlot çêkir, ku ew jî êdî ne pîlot bû. Van karûbaran hatin pejirandin, û bi rêyên îdarî ve wan got, li vir koda we ye, li vir tîmê ye, li vir rêveberê we ye. Karûbar bi rastî jixwe dest bi qezenckirinê kirine. Di heman demê de, bi rastî, ew hîn jî sêwî ne, kes fam nake ka ew çawa dixebitin, û rêvebir jî her tiştê ku ji destê wan tê dikin ku karên xwe red bikin.
Konseptek din a mezin heye - pêşveçûna gerîla. Gava ku hin beş, bi gelemperî beşa kirrûbirrê, dixwaze hîpotezek biceribîne û ferman dide ku tevahiya karûbarê ji derve were derxistin. Trafîk dest pê dike diherike, belgeyan digrin, bi îhaleyê re belgeyan îmze dikin, dikevin operasyonê û dibêjin: "Gelîno, li vir xizmetek me heye, jixwe seyrûsefera wê heye, pere ji me re tîne, em qebûl bikin." Me digot, "Oppa, ew çawa dibe."
Û rêyek din ji bo bidestxistina karûbarek sêwî: gava ku tîmek ji nişka ve xwe barkirî dibîne, rêveberî dibêje: "Em karûbarê vê tîmê veguhezînin tîmek din, barek wê piçûktir e." Û paşê em ê wê veguherînin tîmek sêyemîn û rêveberê biguherînin. Û di dawiyê de dîsa sêwîyek me heye.
Pirsgirêka sêwiyan çi ye?
Kî nizane, ev keştiya şer a Wasa ye ku li Swêdê hatiye rakir, bi wê yekê navdar e ku 5 hûrdem piştî avêtinê binav bû. Û Qralê Swêdê jî, ji bo vê yekê tu kes îdam nekir. Ew ji hêla du nifşên endezyaran ve hatî çêkirin ku nizanin keştiyên weha çawa çêbikin. Bandora xwezayî.
Keştî dikaribû bi awayekî pir xerabtir binav bibûya, wek nimûne, dema ku padîşah berê xwe da derekê di nav bahozekê de. Û ji ber vê yekê, ew di cih de xeniqî, li gorî Agile baş e ku meriv zû têk biçe.
Ger em zû têk biçin, bi gelemperî pirsgirêk tune. Mînakî, di dema pejirandinê de ew ji bo verastkirinê hate şandin. Lê heke em di hilberînê de têk biçin, dema ku drav hate razandin, wê hingê dibe ku pirsgirêk hebin. Encam, wekî ku di karsaziyê de têne gotin.
Çima karûbarên sêwî xeternak in:
- Dibe ku karûbar ji nişka ve têk bibe.
- Karûbar demek dirêj digire ku tamîr bike an jî qet nayê tamîrkirin.
- Pirsgirêkên ewlehiyê.
- Pirsgirêkên başkirin û nûvekirinê.
- Ger karûbarek girîng têk bibe, navûdengê pargîdaniyê zirarê dibîne.
Bi xizmetên sêwî re çi bikin?
Ez ê dîsa dubare bikim ka çi bikim. Pêşîn, divê belge hebe. 7 sal li Banki.ru min fêr kir ku ceribandiner divê peyva pêşdebiran negirin, û operasyon divê peyva her kesî negirin. Divê em kontrol bikin.
Ya duyemîn, pêdivî ye ku meriv diagramên danûstendinê binivîsîne, ji ber ku diqewime ku karûbarên ku pir baş nayên wergirtin girêdanên ku kes li ser negotiye dihewîne. Mînakî, pêşdebiran karûbar li ser mifteya xwe ya hin Yandex.Maps an Dadata saz kirin. Te sînorê belaş xilas kir, her tişt şikestî ye, û hûn qet nizanin çi bûye. Pêdivî ye ku hemî rakêşên weha bêne diyar kirin: karûbar Dadata, SMS, tiştek din bikar tîne.
Ya sêyemîn, bi deynê teknîkî re dixebitin. Çaxê hûn cûre-cûre çeqelan dikin yan jî xizmetekê dipejirînin û dibêjin ku tiştekî lazim e bê kirin, hûn gerekê pê ewle bin ku ew tê kirin. Ji ber ku wê hingê dibe ku derkeve holê ku qulika piçûk ne ew çend piçûk e, û hûn ê têkevin nav wê.
Digel karên mîmarî, me çîrokek li ser Sfinxê hebû. Yek ji karûbaran Sphinx bikar anî da ku têkevin navnîşan. Tenê navnîşek rûpelkirî, lê ew her şev ji nû ve hate navnîş kirin. Ew ji du îndeksan hate berhev kirin: yekek mezin her şev dihat îndeks kirin, û di heman demê de pêvekek piçûk jî hebû ku pê ve dihat girêdan. Her roj, bi îhtîmala 50% ya bombebarkirî an na, îndeks di dema hesabkirinê de têk diçû, û nûçeyên me di rûpela sereke de nûvekirina rawestiyan. Di destpêkê de 5 hûrdem lazim bû ku îndeks ji nû ve were îndeks kirin, dûv re îndeks mezin bû, û di demekê de dest bi 40 hûrdeman kir ku ji nû ve îndeks bike. Dema ku me ev yek qut kir, me bêhnek bêhn kişand, ji ber ku diyar bû ku dê demek din derbas bibe û navnîşa me dê bi tevahî dem ji nû ve were navnîş kirin. Ev ê ji bo portalê me têkçûn be, heşt demjimêran xeber tune - ew e, karsazî rawestiyaye.
Plan ji bo xebatê bi xizmeta sêwî
Bi rastî, ev pir dijwar e ku meriv bike, ji ber ku devops li ser danûstendinê ye. Hûn dixwazin bi hevkarên xwe re baş bin, û gava ku hûn bi rêziknameyê serî li hevkar û rêvebirên xwe didin, dibe ku ew li hember wan kesên ku vê dikin xwedî hestên nakok bin.
Ji xeynî van hemî xalan, tiştek din a girîng heye: Divê mirovên taybetî ji bo her karûbarek taybetî, ji bo her beşê taybetî yê prosedûra danînê berpirsiyar bin. Dema ku mirov tunebin û divê hûn hin kesên din bikişînin ku vê mijarê bi tevahî lêkolîn bikin, ew zehmet dibe.
Ger ev hemî alîkarî nekir, û karûbarê weya sêwî hîn jî sêwî ye, kes naxwaze wê hilde ser xwe, belge nehatiye nivîsandin, tîmê ku nav vê karûbarê hatî gazî kirin tiştek red dike, rêyek hêsan heye - ji nû ve kirin her tişt.
Ango, hûn hewcedariyên karûbarê ji nû ve digirin û karûbarek nû, çêtir, li ser platformek çêtir, bêyî çareseriyên teknolojîk ên xerîb dinivîsin. Û hûn di şer de koçî wê dikin.
Me rewşek hebû dema ku me karûbarek li ser Yii 1 girt û fêhm kir ku em nekarin wê bêtir pêşde bibin, ji ber ku me ji pêşdebirên ku dikarin li ser Yii 1 baş binivîsin kêm bûn. Hemî pêşdebiran li ser Symfony XNUMX baş dinivîsin. Çi bikim? Me dem veqetand, tîmek veqetand, rêveberek veqetand, proje ji nû ve nivîsand û bi rêkûpêk seyrûsefera wê veguherand.
Piştî vê yekê, karûbarê kevn dikare were jêbirin. Ev pêvajoya mina bijare ye, gava ku hûn hewce ne ku hin karûbar ji pergala rêveberiya mîhengê bistînin û paqij bikin û dûv re derbas bibin û bibînin ku hemî gerîdeyên di hilberînê de neçalak bûne, da ku ji pêşdebiran re ti şopek nemîne. Depo li Git dimîne.
Tiştê ku min dixwest ez li ser biaxivim ev e, ez amade me ku nîqaş bikim, mijar holîvar e, gelek kes tê de avjenî kirine.
Di slaytan de hat gotin ku we zimanan yek kir. Mînak mezinbûna wêneyan bû. Ma bi rastî hewce ye ku ew bi hişkî bi yek zimanî ve were sînorkirin? Ji ber ku mezinbûna wêneyê di PHP-ê de, baş e, bi rastî dikare li Golang were kirin.
Bi rastî, ew wekî hemî pratîkan vebijarkî ye. Dibe ku, di hin rewşan de, ew nexwestî jî be. Lê divê hûn fêhm bikin ku heke we di pargîdaniyek ji 50 kesan de beşa teknîkî hebe, 45 ji wan pisporên PHP-ê ne, 3 yên din devop in ku Python, Ansible, Puppet û tiştek mîna wê dizanin, û tenê yek ji wan di hinan de dinivîse. hindek karûbarê guheztina mezinahiya wêneyê Go, wê gavê gava ew derkeve, pisporî pê re diçe. Û di heman demê de, hûn ê hewce bikin ku li pêşdebirek bazarê-taybetî ku bi vî zimanî dizane bigerin, nemaze heke ew kêm be. Yanî ji aliyê rêxistinî ve ev pirsgirêk e. Ji awirek devops ve, hûn ê ne tenê hewce ne ku hin komek pirtûkên lîstikê yên amade yên ku hûn bikar tînin ji bo bicîhkirina karûbaran klon bikin, lê hûn neçar in ku wan ji nû ve binivîsin.
Em niha li ser Node.js karûbarek ava dikin, û ev ê ji bo her pêşdebirek bi zimanek cihê tenê platformek nêzîk be. Lê em rûniştin û fikirîn ku lîstik hêjayî mûmê ye. Ango ev pirsek e ku hûn rûnin û li ser bifikirin.
Hûn karûbarên xwe çawa dişopînin? Meriv çawa têketin berhev dike û çavdêrî dike?
Em di Elasticsearch de têketin berhev dikin û wan di Kibana de dihêlin, û li gorî ka ew hilberîn an jîngehên ceribandinê ne, berhevkarên cihêreng li wir têne bikar anîn. Li deverek Lumberjack, li cîhek din tiştek din, nayê bîra min. Û hîn jî di hin karûbaran de hin cîh hene ku em Telegrafê saz dikin û li cîhek din ji hev cihê dikişînin.
Meriv çawa bi Puppet û Ansible re di heman hawîrdorê de bijî?
Bi rastî, niha du hawîrdorên me hene, yek Puppet e, ya din jî Ansible ye. Em ji bo hîbrîdîzekirina wan dixebitin. Ansible ji bo sazkirina destpêkê çarçoveyek baş e, Puppet ji bo sazkirina destpêkê çarçoveyek xirab e ji ber ku ew rasterast li ser platformê xebata desta hewce dike, û Puppet hevbûna veavakirinê misoger dike. Ev tê vê wateyê ku platform xwe di rewşek nûjen de diparêze, û ji bo ku makîneya ansîbilkirî nûve bibe, divê hûn her dem bi hin frekansan pirtûkên lîstikê li ser wê bimeşînin. Ciyawazî ev e.
Hûn çawa lihevhatî diparêzin? Di Ansible û Puppet de mîhengên we hene?
Ev êşa me ya mezin e, em bi destên xwe re hevahengiyê diparêzin û li ser vê yekê difikirin ka em ê çawa ji van hemûyan li cîhek din biçin. Derket holê ku Puppet pakêtan derdixe û li wir hin girêdan diparêze, û Ansible, bo nimûne, kodê derdixe û li wir mîhengên serîlêdana herî paşîn eyar dike.
Pêşniyar li ser guhertoyên cûda yên Ruby bû. Çi çareserî?
Em li cihekî bi vê yekê re rû bi rû man û divê em her dem di serê xwe de bihêlin. Me tenê beşa ku li ser Ruby-yê ku bi serîlêdanan re hevaheng bû veqetand û ew ji hev veqetand.
Konferansa îsal dê di 7'ê Kanûnê de li Teknopolis pêk were. Em heta 11’ê Mijdarê serlêdanên raporan qebûl dikin. eger hûn bixwazin em biaxivin.
Qeydkirina beşdaran vekirî ye, beşdarî me bibin!
Source: www.habr.com