Dengê webinar kêm e, lewra me ew transkrîbe kir.
Navê min Medvedev Eduard e. Îro ez ê biaxivim ka SRE çi ye, SRE çawa xuya bû, endezyarên SRE çi pîvanên xebatê hene, hinekî li ser pîvanên pêbaweriyê, hinekî li ser çavdêriya wê. Em ê li ser jor bimeşin, ji ber ku hûn di saetekê de nekarin pir tiştan bibêjin, lê ez ê materyalan ji bo vekolîna zêde bidim, û em hemî li benda we ne . li Moskowê di dawiya Çile de.
Pêşîn, bila em biaxivin ka SRE çi ye - Endezyariya pêbaweriya malperê. Û çawa wekî helwestek cuda, wekî rêgezek cuda xuya bû. Hemî bi vê yekê dest pê kir ku di derdorên pêşkeftina kevneşopî de, Dev û Ops du tîmên bi tevahî cûda ne, bi gelemperî bi du armancên bi tevahî cûda ne. Armanca tîmê pêşkeftinê ew e ku taybetmendiyên nû derxîne holê û hewcedariyên karsaziyê bicîh bîne. Armanca tîmê Ops ev e ku piştrast bike ku her tişt kar dike û tiştek neşikest. Eşkere ye, ev armanc rasterast bi hevûdu re nakokî ne: ji bo ku her tişt bixebite û tiştek têk neçe, bi qasî ku gengaz be taybetmendiyên nû derxînin. Ji ber vê yekê, gelek nakokiyên navxweyî hene ku metodolojiya ku naha jê re dibêjin DevOps hewl dide çareser bike.
Pirsgirêk ev e ku me pênaseyek zelal a DevOps û pêkanîna zelal a DevOps tune. Min 2 sal berê di konferansek li Yekaterinburgê de axivî, û heya nuha beşa DevOps bi rapora "DevOps çi ye" dest pê kir. Di sala 2017 de, Devops hema hema 10 salî ye, lê em hîn jî nîqaş dikin ka ew çi ye. Û ev rewşek pir ecêb e ku Google çend sal berê hewl da ku çareser bike.
Di 2016 de, Google pirtûkek bi navê Endezyariya Pêbaweriya Malperê derxist. Û bi rastî, bi vê pirtûkê bû ku tevgera SRE dest pê kir. SRE di pargîdaniyek taybetî de pêkanîna taybetî ya paradîgmaya DevOps e. Endezyarên SRE pêbawer in ku pê ewle bin ku pergalên pêbawer tevdigerin. Ew bi piranî ji pêşdebiran, carinan rêveberên xwedan paşverûyek pêşkeftinê ya xurt têne. Û ew çi dikin ku rêvebirên sîstemê berê dikirin, lê paşxaneyek bihêz di pêşkeftin û zanîna pergalê de di warê kodê de rê li ber vê yekê vedike ku ev kes ne meyla karê îdarî ya rûtîn in, lê meyla otomosyonê ne.
Derket holê ku paradîgmaya DevOps di tîmên SRE de ji hêla vê rastiyê ve tête bicîh kirin ku endezyarên SRE hene ku pirsgirêkên avahîsaziyê çareser dikin. Li vir ew e, heman girêdana di navbera Dev û Ops de ku mirov 8 sal in qala wê dikin. Rola SRE dişibe ya mîmarekî ku kesên nû nebin SRE. Mirov di destpêka kariyera xwe de hîn ne xwediyê ezmûnek e, ne xwediyê berfirehiya zanîna pêwîst e. Ji ber ku SRE zanînek pir nazik hewce dike ka çi û kengê tam dikare xelet bibe. Ji ber vê yekê, hin ezmûnek li vir hewce ye, wekî qaîdeyek, hem li hundurê pargîdaniyê û hem jî li derve.
Ew dipirsin gelo dê cûdahiya di navbera SRE û devops de were vegotin. Ew nû hatiye vegotin. Em dikarin behsa cihê SRE di rêxistinê de bikin. Berevajî vê nêzîkatiya DevOps-a klasîk, ku Ops hîn jî dezgehek veqetandî ye, SRE beşek ji tîmê pêşkeftinê ye. Ew di pêşveçûna hilberê de beşdar dibin. Tewra nêzîkbûnek heye ku SRE rolek e ku ji pêşdebirek derbasî ya din dibe. Ew bi heman rengî beşdarî nirxandinên kodê dibin, mînakî, sêwiranerên UX, pêşdebiran bixwe, carinan rêveberên hilberê. SRE di heman astê de dixebitin. Pêdivî ye ku em wan bipejirînin, pêdivî ye ku em wan binirxînin, da ku ji bo her bicîhkirinê SRE dibêje: "Temam, ev bicîhkirin, ev hilber dê bandorek neyînî li pêbaweriyê neke. Û heke wusa be, wê hingê di nav hin sînorên pejirandî de. Em ê jî li ser vê yekê biaxivin.
Li gorî vê yekê, SRE xwedî veto ye ku kodê biguhezîne. Û bi gelemperî, heke SRE bi xeletî were bicîh kirin, ev jî dibe sedema pevçûnek piçûk. Di heman pirtûkê de li ser Endezyariya Pêbaweriya Malperê, gelek beş, ne yek jî, vedibêjin ka meriv çawa ji van nakokiyan dûr dikeve.
Ew dipirsin ka SRE çawa bi ewlehiya agahdariyê re têkildar e. SRE rasterast di ewlehiya agahdariyê de ne girêdayî ye. Di bingeh de, di pargîdaniyên mezin de, ev ji hêla kesan, ceribandinan, analîstan ve tê kirin. Lê SRE di heman demê de bi wan re têkiliyek dike ku hin operasyon, hin peywir, hin bicihkirinên ku bandorê li ewlehiyê dikin jî dikarin bandorê li hebûna hilberê bikin. Ji ber vê yekê, SRE bi tevahî bi her tîm re, tevî tîmên ewlehiyê, tevî analîstan, têkiliyek heye. Ji ber vê yekê, SRE bi piranî hewce ne dema ku ew hewl didin ku DevOps bicîh bikin, lê di heman demê de, barê pêşdebiran pir mezin dibe. Ango, tîmê pêşkeftinê bixwe nema dikare bi vê rastiyê re rû bi rû bimîne ku naha ew jî hewce ne ku ji Ops berpirsiyar bin. Û rolek cuda heye. Ev rol di butçeyê de hatiye plankirin. Carinan ev rol di mezinahiya tîmê de tête danîn, kesek cûda xuya dike, carinan yek ji pêşdebiran dibe ew. Bi vî rengî yekem SRE di tîmê de xuya dike.
Tevliheviya pergala ku ji hêla SRE ve tê bandor kirin, tevliheviya ku bandorê li pêbaweriya operasyonê dike, pêdivî û tesadufî ye. Tevliheviya pêdivî ev e ku dema ku tevliheviya hilberek bi qasî ku ji hêla taybetmendiyên hilberê nû ve tê xwestin zêde dibe. Tevliheviya rasthatî dema ku tevliheviya pergalê zêde dibe ye, lê taybetmendiya hilberê û hewcedariyên karsaziyê rasterast bandorê li vê nakin. Derket holê ku an pêşdebir li cîhek xeletiyek kiriye, an algorîtma ne çêtirîn e, an jî hin berjewendîyên din têne destnîşan kirin ku bêyî hewcedariya taybetî tevliheviya hilberê zêde dike. SRE-yek baş divê her gav vê rewşê qut bike. Ango, her peywirdarkirin, her veqetandin, her daxwazek kişandinê, li cihê ku dijwarî ji ber lêzêdekirina rasthatî zêde dibe, divê were asteng kirin.
Pirs ev e ku çima ne tenê endezyarek, rêveberek pergalê ku pir zanîn di tîmê de digire. Pêşdebirek di rola endezyariyê de, ji me re tê gotin, ne çareseriya herî baş a karmendan e. Pêşdebirek di rola endezyariyê de ne her gav çareseriya karmendê çêtirîn e, lê xal li vir ev e ku pêşdebirek ku bi Ops re mijûl dibe piçekî bêtir xwestek ji bo otomatiyê heye, ji bo bicîhkirinê piçek bêtir zanîn û jêhatîbûnek heye. ev automation. Li gorî vê yekê, em ne tenê dema hin operasyonên taybetî, ne tenê rûtîn, lê di heman demê de pîvanên karsaziyê yên girîng ên wekî MTTR (Mean Time To Recovery, dema başbûnê) jî kêm dikin. Ji ber vê yekê, û em ê hinekî paşê jî li ser vê yekê biaxivin, em ji bo rêxistinê drav dikin.
Naha em li ser pîvanên xebata SRE biaxivin. Û berî her tiştî li ser pêbaweriyê. Di fîrmayên biçûk, startupan de gelek caran diqewime ku mirov texmîn dike ku ger xizmet baş were nivîsandin, ger hilber baş û rast were nivîsandin dê bixebite, naşkê. Ew e, em kodek baş dinivîsin, ji ber vê yekê tiştek tune ku were şikandin. Kod pir hêsan e, tiştek ku were şikandin tune. Vana li ser heman kesên ku dibêjin ku em ne hewce ne ceribandinan in, ji ber ku, binihêrin, ev sê rêbazên VPI ne, çima li vir bişkînin.
Ev hemû şaş e, bê guman. Û ev mirov pir caran di pratîkê de ji hêla kodek weha ve têne kişandin, ji ber ku tişt dişkînin. Tişt carinan bi awayên herî nediyar dişkênin. Carinan mirov dibêje na, ew ê qet nebe. Û her dem dibe. Ew pir caran têra xwe dibe. Û ji ber vê yekê tu carî kes ji bo hebûna 100% hewl nade, ji ber ku 100% hebûna qet nabe. Ev norm e. Û ji ber vê yekê, dema ku em li ser hebûna karûbarek diaxivin, em her gav li ser neh diaxivin. 2 neh, 3 neh, 4 neh, 5 neh. Ger em vê wergerînin dema daketinê, wê hingê, mînakî, 5 neh, wê hingê ev salek ji 5 hûrdeman domdar hindiktir e, 2 neh 3,5 rojên bêhnvedanê ye.
Lê diyar e ku di hin xalan de kêmbûna POI, vegera veberhênanê heye. Çûyîna ji du neh bo sê neh tê wateya ku ji 3 rojan zêdetir demdirêj kêm dibe. Çûna ji çar neh bo pênc salane 47 hûrdeman dema bêhnvedanê kêm dike. Û derket holê ku ji bo karsaziyê dibe ku ew ne krîtîk be. Û bi gelemperî, pêbaweriya hewce ne pirsgirêkek teknîkî ye, berî her tiştî, ew pirsgirêkek karsaziyê ye, ew pirsgirêkek hilberek e. Ji bo bikarhênerên hilberê çi astê dakêşanê tête pejirandin, ew çi hêvî dikin, ew çiqas didin, mînakî, ew çiqas drav winda dikin, pergal çiqas drav winda dike.
Li vir pirsek girîng ev e ku pêbaweriya pêkhateyên mayî çi ye. Ji ber ku cûdahiya di navbera 4 û 5 nehan de dê li ser smartphoneek bi pêbaweriya 2 neh xuya nebe. Bi gelemperî, heke salê 10 carî tiştek li ser smartphone di karûbarê we de têk bibe, bi îhtîmalek mezin 8 caran têkçûn li aliyê OS-ê çêbûye. Bikarhêner bi vê yekê tê bikar anîn, û salê carek din bala xwe nade. Pêdivî ye ku bi bihayê zêdekirina pêbaweriyê û zêdekirina qezencê ve girêdayî be.
Tenê di pirtûka li ser SRE-ê de mînakek baş heye ku ji 4 nehan 3 neh zêde dibin. Derket holê ku zêdebûna hebûna ji% 0,1 kêmtir e. Û eger dahata xizmetê salê 1 mîlyon dolar be, wê demê zêdebûna dahatê 900 dolar e. Ger salek ji 900 dolar kêmtir ji me re lêçûn e ku em erzaniyê bi nehek zêde bikin, zêdebûn wateya darayî dide. Ger salek ji 900 dolaran zêdetir lêçûn, êdî ew ne maqûl e, ji ber ku zêdebûna dahatê bi tenê lêçûnên kedê, lêçûnên çavkaniyê telafî nake. Û 3 neh jî têra me bike.
Bê guman ev mînakek hêsankirî ye ku hemî daxwaz wekhev in. Û çûna ji 3 neh heta 4 neh têra xwe hêsan e, lê di heman demê de, ji bo nimûne, ji 2 neh ber 3 ve diçe, ev jixwe teserûfek 9 hezar dolar e, ew dikare wateya darayî bide. Bi xwezayî, di rastiyê de, têkçûna daxwaza qeydkirinê ji nebûna nîşandana rûpelê xirabtir e, daxwazî giraniyên cûda hene. Dibe ku ew ji nêrînek karsaziyê ve xwedan pîvanek bi tevahî cûda bin, lê her weha, wekî qaîdeyek, heke em li ser hin karûbarên taybetî neaxivin, ev nêzîkbûnek pêbawer e.
Me pirsek wergirt gelo SRE yek ji koordînatoran e dema ku çareseriyek mîmarî ji bo karûbarê hilbijêrin. Em bibêjin di warê entegrasyona binesaziya heyî de, da ku di aramiya wê de winda nebe. Erê, SRE, bi heman awayê ku daxwazî dikişîne, bicivîne, berdan bandorê li mîmarî, danasîna karûbarên nû, mîkroxizmet, pêkanîna çareseriyên nû dike. Çima min berê got ezmûn lazim e, jêhatîbûn lazim in. Bi rastî, SRE yek ji wan dengên astengker e ku di her çareseriya mîmarî û nermalavê de ye. Li gorî vê yekê, SRE wekî endezyar, berî her tiştî, pêdivî ye ku ne tenê fam bike, lê di heman demê de jî fam bike ku dê çawa hin biryarên taybetî bandorê li pêbawerî, aramî bike, û fam bike ka ev çawa bi hewcedariyên karsaziyê re têkildar e, û ji kîjan nêrînê ve ew dikare were pejirandin û ku ne.
Ji ber vê yekê, naha em dikarin tenê li ser pîvanên pêbaweriyê biaxivin, ku bi kevneşopî di SRE de wekî SLA (Peymana Asta Karûbar) têne destnîşan kirin. Bi îhtîmaleke mezin termeke naskirî ye. SLI (Service Level Indicator). SLO (Armanca Asta Xizmetê). Peymana Asta Karûbar dibe ku têgehek sembolîk e, nemaze heke we bi toran, bi pêşkêşvanan re, bi mêvandariyê re xebitîbe. Ev peymanek gelemperî ye ku performansa tevahiya karûbarê we, cezayên, hin cezayên ji bo xeletiyan, metrîkan, pîvanan vedibêje. Û SLI metrîka hebûna xwe bixwe ye. Ango, SLI dikare çi be: dema bersivê ji karûbarê, hejmara xeletiyan wekî sedî. Ger ew celebek mêvandariya pelê be ew dikare bibe berfê. Dema ku dor tê ser algorîtmayên naskirinê, nîşankar dikare bibe, mînakî, rastbûna bersivê jî. SLO (Armanca Asta Xizmetê) bi rêzê ve, berhevokek nîşana SLI, nirx û heyama wê ye.
Em bêjin SLA dikare bi vî rengî be. Karûbar 99,95% ji demê li seranserê salê peyda dibe. An jî 99 bilêtên piştevaniya krîtîk dê di nav çaryeka 3 demjimêran de bêne girtin. An jî 85% ji pirsan dê her meh di nav 1,5 çirkeyan de bersivan bistînin. Ango hêdî hêdî em têdigihîjin ku xeletî û têkçûn pir normal in. Ev rewşek meqbûl e, em plan dikin, heta radeyekê em li ser vê yekê jî hesab dikin. Ango, SRE pergalên ku dikarin xeletiyan bikin ava dike, ku divê bi gelemperî bersiva xeletiyan bidin, ku divê wan li ber çavan bigirin. Û gava ku gengaz be, divê ew xeletiyan bi vî rengî bi rê ve bibin ku bikarhêner an wan ferq nake, an jî hay jê çêdibe, lê cûreyek çareyek heye, bi saya ku dê her tişt bi tevahî nekeve.
Mînakî, heke hûn vîdyoyek li YouTube bar bikin, û YouTube nikaribe tavilê wê veguhezîne, ger vîdyoyek pir mezin be, heke format ne çêtirîn be, wê hingê daxwaz bi xwezayî bi demek dirêj re têk naçe, YouTube dê xeletiyek 502 nede. , YouTube dê bêje: “Me her tişt çêkiriye, vîdyoya we tê pêvajo kirin. Nêzî 10 deqeyan dê amade bibe." Ev prensîba hilweşandina dilşewat e, ku ji pêşkeftina pêş-endê naskirî ye, heke we çu carî wiya kiriye.
Mercên din ên ku em ê li ser biaxivin, yên ku ji bo xebata bi pêbawer, bi xeletî, bi hêviyê pir girîng in, MTBF û MTTR ne. MTBF dema navîn di navbera têkçûnan de ye. MTTR Mean Time To Recovery, dema navîn a başbûnê. Ango, ji gava ku xeletî hate kifş kirin, ji gava ku xeletî xuya bû heya gava ku karûbar ji nû ve vegerandina xebata normal de çiqas dem derbas bûye. MTBF bi piranî ji hêla xebata li ser kalîteya kodê ve tête rast kirin. Ango rastiya ku SRE dikarin bibêjin "na". Û ji te re têgihîştina tevahiya tîmê hewce ye ku gava SRE dibêje "na", ew dibêje ne ji ber ku ew zirardar e, ne ji ber ku ew xirab e, lê ji ber ku wekî din dê her kes cefayê bikişîne.
Dîsa, gelek gotar, gelek rêbaz, gelek rê hene tewra di pirtûka ku ez pir caran jê re vedibêjim, ka meriv çawa pê ewle dibe ku pêşdebirên din dest bi nefreta SRE-yê nekin. MTTR, ji hêla din ve, li ser xebata li ser SLO-yên we ye (Armanca Asta Karûbar). Û ew bi piranî automation e. Ji ber ku, mînakî, SLO-ya me ji çaryeka 4 neh dema kar e. Ev tê wê wateyê ku di 3 mehan de em dikarin destûr bidin 13 hûrdem dema daketinê. Û derket holê ku MTTR nikare ji 13 hûrdeman zêdetir be. Ger em di nav 13 hûrdeman de bi kêmî ve 1 demsalê bersivê bidin, ev tê vê wateyê ku me jixwe budceya çaryekê westandiye. Em SLO dişkînin. 13 hûrdem ji bo bertek û rastkirina qezayek ji bo makîneyek pir pir e, lê ji bo mirovek pir kurt e. Ji ber ku heta ku mirov hişyariyek werbigire, heya ku bertek nîşan bide, heya ku xeletiyê fêm bike, jixwe çend deqe ye. Heya ku mirov fêm bike ka meriv wê çawa rast bike, bi rastî çi rast bike, çi bike, wê hingê ev çend hûrdem e. Û bi rastî, tewra ku hûn tenê hewce ne ku serverê ji nû ve bidin destpêkirin, wekî ku xuya dibe, an girêkek nû bilind bikin, wê hingê MTTR bi destan hema hema 7-8 hûrdem e. Dema ku pêvajoyê otomatîk dike, MTTR pir caran digihîje duyemîn, carinan millisecond. Google bi gelemperî li ser millisecond dipeyive, lê di rastiyê de, bê guman, her tişt ne ew çend baş e.
Bi îdeal, divê SRE hema hema bi tevahî xebata xwe otomatîk bike, ji ber ku ev rasterast bandorê li MTTR, metrîkên wê, SLO ya tevahî karûbarê, û, li gorî, li ser qezenca karsaziyê dike. Ger dem derbas bibe, ji me tê pirsîn ka SRE xelet e. Xweşbextane tu kes sûcdar nîne. Û ev çandek cihêreng e ku jê re dibêjin postmortem bêbalme, ku em ê îro nebêjin, lê em ê li ser Slurm analîz bikin. Ev mijarek pir balkêş e ku meriv dikare pir li ser biaxive. Bi giştî ger dema çaryeka diyarkirî derbas bibe, wê demê piçekî ji her kesî sûcdar e, yanî sûcdarkirina her kesî ne berhemdar e, em li şûna vê yekê, belkî tu kesî sûcdar nekin, lê rewşê rast bikin û bi tiştên me re bixebitin. Di ezmûna min de, ev nêzîkatî ji piraniya tîman re, nemaze li Rûsyayê, hinekî xerîb e, lê ew watedar e û pir baş dixebite. Ji ber vê yekê, ez ê di dawiya gotar û wêjeyê de pêşniyar bikim ku hûn dikarin li ser vê mijarê bixwînin. An jî werin Slurm SRE.
Bila ez şirove bikim. Ger dema SLO her çaryek derbas bibe, ger dema daketinê ne 13 hûrdem, lê 15 be, kî dikare ji bo vê yekê sûcdar be? Bê guman, dibe ku SRE sûcdar be, ji ber ku wî bi eşkere cûreyek kirdar an bicîhkirina xirab çêkir. Rêvebirê navenda daneyê dibe ku ji ber vê yekê sûcdar be, ji ber ku dibe ku wî cûreyek lênihêrîna neplankirî pêk anibe. Ger rêvebirê navenda daneyê ji bo vê yekê sûcdar e, wê hingê kesê ji Ops ji bo vê yekê sûcdar e, yê ku dema ku SLO-yê hevrêz kir, lênêrînê hesab nekir. Rêvebir, rêveberê teknîkî an jî kesê ku peymana navenda daneyê îmze kiriye û guh nedaye vê yekê ku SLA ya navenda daneyê ji bo dema daketinê ya pêwîst nehatiye sêwirandin ji bo vê yekê sûcdar e. Li gorî vê yekê, di vê rewşê de hêdî hêdî hemî sûcdar in. Û ev tê wê wateyê ku di vê rewşê de tu wateya sûcdarkirina kesek tune. Lê helbet divê bê rastkirin. Ji ber vê yekê jî piştî mirinê hene. Û heke hûn, mînakî, postmortemên GitHub bixwînin, û ev her gav di her bûyerek taybetî de çîrokek pir balkêş, piçûk û neçaverêkirî ye, hûn dikarin biguhezînin ku kes çu carî nabêje ku ev kesê taybetî sûcdar bû. Sûcdar her gav li ser pêvajoyên taybetî yên bêkêmasî tê danîn.
Ka em herin ser pirsa din. Otomatîkî. Dema ku ez di çarçoveyek din de behsa otomasyonê dikim, ez bi gelemperî behsa tabloyek dikim ku ji we re vedibêje ka hûn kengî dikarin li ser otomatîkkirina peywirek bixebitin bêyî ku bêtir wext ji bo otomatîkkirina wê ji ya ku hûn bi rastî xilas dikin bigirin. Xemgîniyek heye. Girîng ev e ku gava SRE karekî otomatîk dike, ew ne tenê wextê xilas dikin, ew drav jî teserûf dikin, ji ber ku otomasyon rasterast bandorê li MTTR dike. Ew, bi vî rengî, moralê karmend û pêşdebiran xilas dikin, ku ev jî çavkaniyek bêserûber e. Ew rûtîn kêm dikin. Û ev hemî bandorek erênî li ser kar û, wekî encam, li ser karsaziyê dike, tewra xuya dike ku otomasyon di warê lêçûnên demê de wate nake.
Bi rastî, hema hema her gav heye, û pir hindik rewş hene ku divê tiştek di rola SRE de otomatîk nebe. Piştre em ê li ser tiştê ku jê re budceya xeletiyê tê gotin, budceya xeletiyan biaxivin. Di rastiyê de, derdikeve holê ku ger her tişt ji bo we ji SLO-ya ku we ji xwe re saz kiriye pir çêtir be, ev jî ne pir baş e. Ev pir xirab e, ji ber ku SLO ne tenê wekî jêrîn, lê di heman demê de wekî sînorê jorîn a texmînî jî dixebite. Gava ku hûn ji xwe re SLO-ya 99% hebûna xwe destnîşan dikin, û bi rastî we 99,99%, derdikeve holê ku cîhek we heye ji bo ceribandinan ku qet zirarê nade karsaziyê, ji ber ku we bi xwe ev hemî bi hev re destnîşan kiriye, û hûn ev cîh nayê bikaranîn. Ji bo xeletiyan budceyek we heye, ku di doza we de nayê bikar anîn.
Em bi wê re çi bikin. Em wê bi rastî ji bo her tiştî bikar tînin. Ji bo ceribandina di şert û mercên hilberînê de, ji bo derxistina taybetmendiyên nû yên ku dibe ku bandorê li performansê bikin, ji bo berdanê, ji bo lênihêrînê, ji bo demên daketinê yên plansazkirî. Rêzika berevajî jî derbas dibe: heke budçe biqede, em nikanin tiştek nû derxînin, ji ber ku wekî din em ê ji SLO-yê derbas bikin. Bûdce jixwe qediya ye, me tiştek derxist heke ew bandorek neyînî li performansê bike, ango heke ev ne cûreyek rastkirinek be ku bi serê xwe rasterast SLO zêde dike, wê hingê em ji budçeyê wêdetir diçin, û ev rewşek xirab e. , pêdivî ye ku ew were analîz kirin, postmortem, û dibe ku hin pêvajoyên rast bikin.
Ango, derdikeve holê ku ger karûbar bixwe baş nexebite, û SLO were xerc kirin û budçe ne li ser ceribandinan, ne li ser hin berdanan, lê bi serê xwe were xerc kirin, wê hingê li şûna hin sererastkirinên balkêş, li şûna taybetmendiyên balkêş, li şûna weşanên balkêş. Li şûna her xebata afirîner, hûn ê neçar bibin ku bi rastkirinên ehmeqî re mijûl bibin da ku budçeyê bi rêkûpêk vegerînin, an SLO-yê biguherînin, û ev jî pêvajoyek e ku divê pir caran çênebe.
Ji ber vê yekê, derdikeve holê ku di rewşek ku me ji bo xeletiyan bêtir budce heye, her kes eleqedar e: hem SRE û hem jî pêşdebiran. Ji bo pêşdebiran, budceyek mezin ji bo xeletiyan tê vê wateyê ku hûn dikarin bi berdan, ceribandin, ceribandinan re mijûl bibin. Ji bo SRE-yan, budceyek ji bo xeletiyan û ketina wê budceyê tê vê wateyê ku ew rasterast karê xwe baş dikin. Û ev yek bandorê li motîvasyona cûreyek xebata hevbeş dike. Ger hûn wekî pêşdebiran guh bidin SRE-yên xwe, dê cîhê we ji bo xebata baş û pir kêmtir rûtîn hebe.
Derket holê ku ceribandinên di hilberînê de di tîmên mezin de beşek girîng û hema hema yekbûyî ya SRE ne. Û bi gelemperî jê re endezyariya kaosê tê gotin, ku ji tîmê Netflix-ê tê ku amûrek bi navê Chaos Monkey derxist.
Chaos Monkey bi lûleya CI/CD-ê ve girêdide û di hilberînê de serverê bi rasthatinî têk dibe. Dîsa, di strûktûra SRE de, em li ser vê yekê diaxivin ku serverek daxistî bi serê xwe ne xirab e, ew tê hêvî kirin. Û eger ew di nav budceyê de be, ew tê qebûl kirin û zirarê nade karsaziyê. Bê guman, Netflix xwedan serverên bêserûber, têr dubarekirin e, da ku ev hemî were rast kirin, û ji ber vê yekê bikarhêner bi tevahî ferq nake, û hêj bêtir kes ji bo her budceyê yek serverek nahêle.
Netflix ji bo demekê xwedan komek karûbarên weha bû, yek ji wan, Chaos Gorilla, yek ji Herêmên Hebûna Amazonê bi tevahî qut dike. Û tiştên weha alîkariya eşkerekirina, yekem, girêdanên veşartî dikin, dema ku bi tevahî ne diyar e ka çi bandorê li ser çi dike, çi bi çi ve girêdayî ye. Û ev, heke hûn bi mîkroxizmetek re dixebitin, û belge ne pir bêkêmasî ye, dibe ku ev ji we re nas be. Û dîsa, ev ji bo girtina xeletiyên di kodê de ku hûn nikaribin li ser sehneyê bigirin, pir arîkar dike, ji ber ku her qonax bi rastî ne simulasyonek rastîn e, ji ber ku pîvana barkirinê cûda ye, şêwaza barkirinê cûda ye, amûrek e. jî, bi îhtimaleke mezin, yên din. Barên lûtkeyê jî dikarin nediyar û nediyar bin. Û ceribandinek wusa, ku dîsa ji budceyê wêdetir naçe, pir baş dibe alîkar ku hûn xeletiyên di binesaziya ku stêrk, ceribandin, boriyên CI / CD-yê çu carî negirin bigirin. Û heta ku ew hemî di nav budceya we de ye, ne girîng e ku karûbarê we li wir daketiye, her çend ew ê pir tirsnak xuya bike jî, server daket, çi kabûsek. Na, ew normal e, ew baş e, ku alîkariya girtina xeletiyan dike. Ger budçeyek we hebe, wê hingê hûn dikarin wê xerc bikin.
Pirs: Ez dikarim kîjan edebiyatê pêşniyar bikim? Lîsteya di dawiyê de. Gelek edebiyat hene, ez ê çend raporan şîret bikim. Ew çawa dixebite, û SRE di pargîdaniyan de bêyî hilbera nermalava xwe an bi pêşkeftina hindiktirîn dixebite. Mînakî, di pargîdaniyek ku çalakiya sereke ne nermalavê ye. Di pargîdaniyek de, ku çalakiya sereke ne nermalavê ye, SRE tam mîna her cîhek din dixebite, ji ber ku di pargîdaniyek de hûn jî hewce ne ku hilberên nermalavê bikar bînin, her çend ne pêşkeftî be jî, hûn hewce ne ku nûvekirinan derxînin, divê hûn biguhezînin. binesaziyê, divê hûn mezin bibin, hûn hewce ne ku pîvan bikin. Û SRE alîkarî dide naskirin û pêşbînîkirina pirsgirêkên mimkun ên di van pêvajoyan de û wan kontrol dike piştî ku hin mezinbûn dest pê dike û hewceyên karsaziyê biguherînin. Ji ber ku ne hewce ye ku hûn beşdarî pêşkeftina nermalavê bibin ji bo ku hûn bi kêmî çend serverên we hebin û hûn bi kêmî ve hin mezinbûnek hebe hebe SRE.
Heman tişt ji bo projeyên piçûk, rêxistinên piçûk jî derbas dibe, ji ber ku pargîdaniyên mezin xwedî budce û cîhê ceribandinê ne. Lê di heman demê de, hemî van fêkiyên ceribandinan dikarin li her deverê bêne bikar anîn, ango SRE, bê guman, di Google, li Netflix, di Dropbox de xuya bû. Lê di heman demê de, pargîdaniyên piçûk û destpêk dikarin berê xwe bidin materyalên berhevkirî, pirtûkan bixwînin, raporan temaşe bikin. Ew pir caran dest bi bihîstina wê dikin, ew li mînakên taybetî dinêrin, ez difikirim ku ew baş e, ew bi rastî dikare bikêr be, em jî hewceyê vê yekê ne, ew pir xweş e.
Ango hemû xebatên sereke yên standardkirina van pêvajoyan jixwe ji bo we hatine kirin. Ji we re dimîne ku hûn rola SRE bi taybetî di pargîdaniya xwe de diyar bikin û bi rastî dest bi pêkanîna van hemî pratîkan bikin, yên ku, dîsa, berê hatine diyar kirin. Ango, ji prensîbên kêrhatî yên ji bo pargîdaniyên piçûk, ev her gav pênaseya SLA, SLI, SLO ye. Ger hûn di nermalavê de nebin, wê hingê ew ê SLA-yên hundurîn û SLO-yên hundurîn bin, budceyek navxweyî ya ji bo xeletiyan. Ev hema hema her gav dibe sedema nîqaşên balkêş di nav tîmê de û di hundurê karsaziyê de, ji ber ku dibe ku derkeve holê ku hûn li ser binesaziyê, li ser cûreyek organîzasyona pêvajoyên îdeal xerc dikin, lûleya îdeal ji hewcedariyê pir wêdetir e. Û ev 4 nehên ku hûn di beşa IT-ê de hene, hûn niha bi rastî ne hewce ne. Lê di heman demê de, hûn dikarin dem derbas bikin, budceya xeletiyan li ser tiştek din xerc bikin.
Li gorî vê yekê, çavdêrî û organîzekirina çavdêriyê ji bo pargîdaniyek her mezinahiyê bikêr e. Û bi gelemperî, ev awayê ramanê, li ku derê xeletî tiştek qebûlkirî ye, li ku derê budceyek heye, li ku derê Armanc hene, ew dîsa ji bo pargîdaniyek her mezinahiyê bikêr e, ji destpêka 3 kesan dest pê dike.
Dawiya nuwazeyên teknîkî yên ku li ser biaxivin çavdêrî ye. Ji ber ku ger em li ser SLA, SLI, SLO dipeyivin, em nikarin bêyî çavdêriyê fam bikin ka em di budceyê de cih digirin, gelo em bi Armancên xwe re tevdigerin, û em çawa bandorê li SLA-ya paşîn dikin. Min gelek caran dît ku çavdêrî bi vî rengî çêdibe: hin nirx heye, mînakî, dema daxwazek ji serverê re, dema navîn, an jî hejmara daxwazên databasê. Ew standardek heye ku ji hêla endezyarek ve hatî destnîşankirin. Ger metrîk ji normê dûr dikeve, wê hingê e-nameyek tê. Ev hemî bêkêr e, wekî qaîdeyek, ji ber ku ew rê li ber zêdegaviyek hişyariyê vedike, pir peyamên ji çavdêriyê, gava ku kesek, pêşî, divê her car wan şîrove bike, ango diyar bike ka nirxa metrîkê tê wateya hewcedariya hin çalakiyan. Û ya duyemîn jî, ew bi tenê guh nade van hemî hişyariyan, gava ku di bingeh de tu tevger ji wî nayê xwestin. Ew qaîdeyek çavdêriyek baş e û gava ku SRE tête bicîh kirin qaîdeya yekem ev e ku agahdarî tenê gava ku tevger hewce ye were.
Di rewşa standard de, 3 astên bûyeran hene. Hişyar hene, bilêt hene, têketin hene. Hişyar tiştek e ku ji we re hewce dike ku hûn gavê gav bavêjin. Ango her tişt şikestî ye, divê hûn niha rast bikin. Bilêt ew in ku çalakiya dereng hewce ne. Erê, hûn hewce ne ku hûn tiştek bikin, hûn hewce ne ku tiştek bi destan bikin, otomasyon têk çû, lê ne hewce ye ku hûn çend hûrdeman bikin. Têketin tiştek e ku ne hewceyî çalakiyê ye, û bi gelemperî, ger tişt baş bibin, kes çu carî wan naxwîne. Hûn ê tenê hewce bikin ku têketin bixwînin dema ku, di paşerojê de, derket holê ku tiştek ji bo demekê şikestiye, me jê nizanibû. An jî hûn hewce ne ku hin lêkolînan bikin. Lê bi gelemperî, her tiştê ku hewcedariya çalakiyê nake diçe têketin.
Wekî bandorek alikî ya van hemîyan, heke me diyar kir ku çi bûyer hewcedarê çalakiyan in û baş diyar kir ku divê ev kiryar çi bin, ev tê vê wateyê ku çalakî dikare otomatîk bibe. Yanî çi dibe. Em ji hişyariyê diçin. Werin em herin çalakiyê. Em diçin danasîna vê çalakiyê. Û paşê em derbasî otomatê bibin. Ango her otomasyon bi bertekek li hember bûyerekê dest pê dike.
Ji çavdêriyê, em derbasî termek bi navê Çavdêrî dibin. Di van çend salên borî de jî li dora vê peyvê hinekî dengbêjî heye. Û hindik kes fêm dikin ku ew tê çi wateyê ji derveyî çarçoveyê. Lê xala sereke ev e ku Çavdêrî ji bo zelalbûna pergalê metrikek e. Ger tiştek xelet çû, hûn dikarin çiqas zû diyar bikin ka bi rastî çi xelet bû û di wê gavê de rewşa pergalê çi bû. Di warê kodê de: kîjan fonksiyon têk çû, kîjan karûbar têk çû. Ji bo nimûne, guherbarên navxweyî, veavakirin, rewşa wan çi bû. Di warê binesaziyê de, ev e ku têkçûn li kîjan devera peydabûnê qewimî, û heke we Kubernetes hebe, wê hingê têkçûn li kîjan podê qewimî, rewşa pod çawa bû. Û li gorî vê yekê, Çavdêrî têkiliyek rasterast bi MTTR re heye. Çavdêriya karûbarê her ku bilindtir e, ew qas hêsan e ku meriv xeletiyê nas bike, rastkirina xeletiyê hêsantir e, otomatîkkirina xeletiyê hêsantir e, MTTR kêmtir dibe.
Ji nû ve ber bi pargîdaniyên piçûk ve diçin, pir gelemperî ye ku meriv bipirse, heya naha jî, meriv çawa bi mezinahiya tîmê re mijûl dibe, û gelo tîmek piçûk hewce dike ku SRE-yek cûda bikire. Jixwe li ser vê yekê hinekî berê axivî. Di qonaxên pêşîn ên pêşkeftina destpêkek an, mînakî, tîmek de, ev yek ne hewce ye, ji ber ku SRE dikare bibe rolek veguhêz. Û ev ê tîmê hinekî vejîne, ji ber ku bi kêmî ve cûrbecûr heye. Û her weha ew ê mirovan ji vê yekê re amade bike ku bi mezinbûnê re, bi gelemperî, berpirsiyariyên SRE dê pir girîng biguhezin. Ger hûn kesek kar bikin, wê hingê, bê guman, hin hêviyên wî hene. Û ev bendewarî dê bi demê re neguherin, lê pêdivî dê pir biguhezin. Ji ber vê yekê, meriv çawa SRE-yek di qonaxên destpêkê de pir dijwar e. Mezinbûna xwe pir hêsantir e. Lê hêjayî hizirkirinê ye.
Dibe ku tenê îstîsna ev e ku dema ku hewcedariyên mezinbûnê yên pir hişk û diyarkirî hene. Ango, di doza destpêkek de, ev dibe ku cûreyek zextek ji veberhêneran, celebek pêşbîniyek ji bo mezinbûnê bi carekê re çend caran be. Dûv re karkirina SRE bi bingehîn rastdar e ji ber ku ew dikare rastdar be. Pêdiviyên me ji bo mezinbûnê hene, hewcedariya me bi kesek heye ku ji vê yekê berpirsiyar be ku bi mezinbûnek wusa tiştek dê bişkê.
Pirsek din. Çi bikin dema ku çend caran pêşdebir taybetmendiyek ku ceribandinan derbas dike qut dike, lê hilberînê dişkîne, bingehê bar dike, taybetmendiyên din dişkîne, kîjan pêvajoyê bicîh tîne. Li gorî vê yekê, di vê rewşê de, ew budceya xeletiyan tê destnîşan kirin. Û hin karûbar, hin taybetmendî jixwe di hilberînê de têne ceribandin. Ew dikare canary be, dema ku tenê hejmarek piçûk bikarhêneran, lê jixwe di hilberînê de, taybetmendiyek tête bicîh kirin, lê jixwe bi hêviya ku heke tiştek bişkê, mînakî, ji sedî nîvê hemî bikarhêneran, ew ê dîsa jî bigihîje budceya ji bo çewtiyên. Li gorî vê yekê, erê, dê xeletiyek hebe, ji bo hin bikarhêneran dê her tişt bişkê, lê me berê jî got ku ev normal e.
Li ser amûrên SRE pirsek hebû. Ango, tiştek bi taybetî heye ku SRE dê bikar bîne ku her kesê din bikar neynin. Di rastiyê de, hin karûbarên pir pispor hene, celebek nermalava ku, mînakî, barkêşan simule dike an bi ceribandina kanarya A / B ve mijûl dibe, heye. Lê di bingeh de amûra SRE ew e ku pêşdebirên we berê bikar tînin. Ji ber ku SRE rasterast bi tîmê pêşveçûnê re têkilî dike. Û heke we amûrên cihêreng hebin, ew ê derkeve holê ku ew dem hewce dike ku hevdem bikin. Nemaze heke SRE di tîmên mezin de bixebitin, di pargîdaniyên mezin de ku dikarin çend tîm hebin, ew standardîzasyona pargîdanî ye ku dê li vir pir alîkar be, ji ber ku heke di 50 tîm de 50 karûbarên cûda werin bikar anîn, ev tê vê wateyê ku SRE divê wan bizane. gişt. Û bê guman ev ê qet nebe. Û kalîteya xebatê, kalîteya kontrolê ya herî kêm hin tîm dê pir kêm bibe.
Webinara me ber bi dawîbûnê ve diçe. Min karî hin tiştên bingehîn vebêjim. Bê guman, tiştek di derbarê SRE de di saetekê de nayê gotin û fêm kirin. Lê ez hêvî dikim ku min karîbû ku ev awayê ramanê, xalên sereke yên sereke ragihînim. Dûv re, heke eleqedar be, dê mimkun be ku hûn di mijarê de hûr bibin, bi serê xwe fêr bibin, binihêrin ka ew çawa ji hêla kesên din ve, di pargîdaniyên din de têne bicîh kirin. Û li gorî vê yekê, di destpêka Sibatê de, werin ba me li Slurm SRE.
Slurm SRE qursek zexm a sê-rojî ye ku dê li ser tiştê ku ez nuha behs dikim biaxive, lê bi pir kûrtir, bi dozên rastîn, bi pratîkê re, tevahî întensîv bi armanca xebata pratîkî ye. Mirov wê di koman de werin dabeş kirin. Hûn ê hemî li ser dozên rastîn bixebitin. Li gorî vê yekê, mamosteyên me yên Booking.com Ivan Kruglov û Ben Tyler hene. Me ji Google, ji San Francisco, Eugene Barabbasek ecêb heye. Û ez ê jî tiştekî ji te re bibêjim. Ji ber vê yekê bi rastî serdana me bikin.
Ji ber vê yekê, bîbliyografya. Li ser SRE referans hene. li ser heman pirtûkê, an bêtir li ser 2 pirtûkên li ser SRE, ku ji hêla Google ve hatî nivîsandin. Yeka din , ku şert û sepana wan hinekî berfirehtir in. 3 paşîn raporên li ser SRE di pargîdaniyên cihêreng de ne. Yekem - , ev ji Ben Trainer ya Google-ê sereke ye. Duyem - . Ya sêyemîn dîsa ye . Rapora çaremîn ji , ku li 5 welatan tenê 190 karmendên sereke yên SRE hene. Pir balkêş e ku meriv li van hemîyan mêze bike, ji ber ku çawa ku DevOps ji pargîdaniyên cihêreng û hetta tîmên cihêreng re tê wateya tiştên pir cûda, SRE jî di pargîdaniyên bi pîvanên wekhev de xwedî berpirsiyariyên pir cûda ye.
2 girêdanên din li ser prensîbên endezyariya kaosê: , . Û di dawiyê de 3 navnîşên ji rêze Lîsteyên Awesome li ser hene , der barê û li ser . Navnîşa li ser SRE pir pir mezin e, ne hewce ye ku meriv tev de derbas bibe, bi qasî 200 gotar hene. Ez gotarên ji wir di derbarê plansazkirina kapasîteyê û di derbarê paşverûya bêqusûr de pir pêşniyar dikim.
Gotara balkêş:
Spas dikim ji bo ku hûn hemî vê demê li min guhdarî dikin. Hêvî dikim ku hûn tiştek fêr bûne. Hêvî dikim ku hûn materyalek têr hebe ku hûn hîn bêtir fêr bibin. Û te bibînin. Bi hêviya di sibatê de.
Webinar ji aliyê Eduard Medvedev ve hat kirin.
PS: ji bo kesên ku dixwazin bixwînin, Eduard navnîşek referansan da. Kesên ku tercîh dikin ku di pratîkê de fêm bikin, bi xêr hatin .
Source: www.habr.com