Mae sain wael yn y gweminar, felly rydym wedi ei thrawsgrifio.
Fy enw i yw Medvedev Eduard. Heddiw, byddaf yn siarad am beth yw SRE, sut roedd SRE yn ymddangos, pa feini prawf gwaith sydd gan beirianwyr SRE, ychydig am feini prawf dibynadwyedd, ychydig am ei fonitro. Byddwn yn cerdded ar y topiau, oherwydd ni allwch ddweud llawer mewn awr, ond byddaf yn rhoi deunyddiau ar gyfer adolygiad ychwanegol, ac rydym i gyd yn aros amdanoch chi ar . ym Moscow ddiwedd mis Ionawr.
Yn gyntaf, gadewch i ni siarad am beth yw SRE - Peirianneg Dibynadwyedd Safle. A sut yr oedd yn ymddangos fel sefyllfa ar wahân, fel cyfeiriad ar wahân. Dechreuodd y cyfan gyda'r ffaith bod Dev ac Ops yn ddau dîm hollol wahanol mewn cylchoedd datblygu traddodiadol, fel arfer gyda dwy gôl hollol wahanol. Nod y tîm datblygu yw cyflwyno nodweddion newydd a chwrdd ag anghenion y busnes. Nod tîm yr Ops yw sicrhau bod popeth yn gweithio a dim byd yn torri. Yn amlwg, mae'r nodau hyn yn gwrth-ddweud ei gilydd yn uniongyrchol: er mwyn i bopeth weithio a dim byd i'w dorri, cyflwyno nodweddion newydd cyn lleied â phosibl. Oherwydd hyn, mae yna lawer o wrthdaro mewnol y mae'r fethodoleg a elwir bellach yn DevOps yn ceisio ei datrys.
Y broblem yw nad oes gennym ddiffiniad clir o DevOps a gweithrediad clir o DevOps. Siaradais mewn cynhadledd yn Yekaterinburg 2 flynedd yn ôl, a hyd yn hyn dechreuodd yr adran DevOps gyda'r adroddiad “Beth yw DevOps”. Yn 2017, mae Devops bron yn 10 oed, ond rydym yn dal i ddadlau beth ydyw. Ac mae hon yn sefyllfa ryfedd iawn y ceisiodd Google ei datrys ychydig flynyddoedd yn ôl.
Yn 2016, rhyddhaodd Google lyfr o'r enw Site Reliability Engineering. Ac mewn gwirionedd, gyda'r llyfr hwn y dechreuodd y mudiad ARhPh. Mae SRE yn weithrediad penodol o batrwm DevOps mewn cwmni penodol. Mae peirianwyr ARhPh wedi ymrwymo i sicrhau bod systemau'n gweithredu'n ddibynadwy. Maent yn dod yn bennaf gan ddatblygwyr, weithiau gweinyddwyr gyda chefndir datblygu cryf. Ac maen nhw'n gwneud yr hyn roedd gweinyddwyr system yn arfer ei wneud, ond mae cefndir cryf mewn datblygiad a gwybodaeth am y system o ran cod yn arwain at y ffaith nad yw'r bobl hyn yn dueddol o wneud gwaith gweinyddol arferol, ond yn hytrach yn dueddol o awtomeiddio.
Mae'n ymddangos bod patrwm DevOps mewn timau ARhPh yn cael ei weithredu gan y ffaith bod yna beirianwyr ARhPh sy'n datrys problemau strwythurol. Dyma hi, yr un cysylltiad rhwng Dev ac Ops y mae pobl wedi bod yn siarad amdano ers 8 mlynedd. Mae rôl ARhPh yn debyg i rôl pensaer yn yr ystyr nad yw newydd-ddyfodiaid yn dod yn ARhPh. Nid oes gan bobl ar ddechrau eu gyrfaoedd unrhyw brofiad eto, nid oes ganddynt yr ehangder gwybodaeth angenrheidiol. Gan fod ARhPh yn gofyn am wybodaeth gynnil iawn o beth yn union a phryd all fynd o'i le. Felly, mae angen rhywfaint o brofiad yma, fel rheol, y tu mewn i'r cwmni a'r tu allan.
Maen nhw'n gofyn a fydd y gwahaniaeth rhwng ARhPh a devops yn cael ei ddisgrifio. Mae hi newydd gael ei disgrifio. Gallwn siarad am le'r ARhPh yn y sefydliad. Yn wahanol i'r dull DevOps clasurol hwn, lle mae Ops yn dal i fod yn adran ar wahân, mae ARhPh yn rhan o'r tîm datblygu. Maent yn ymwneud â datblygu cynnyrch. Mae hyd yn oed ymagwedd lle mae ARhPh yn rôl sy'n trosglwyddo o un datblygwr i'r llall. Maent yn cymryd rhan mewn adolygiadau cod yn yr un modd ag, er enghraifft, dylunwyr UX, datblygwyr eu hunain, weithiau rheolwyr cynnyrch. Mae SREs yn gweithio ar yr un lefel. Mae angen i ni eu cymeradwyo, mae angen i ni eu hadolygu, fel bod SRE ar gyfer pob defnydd yn dweud: “Iawn, y defnydd hwn, ni fydd y cynnyrch hwn yn effeithio'n negyddol ar ddibynadwyedd. Ac os ydyw, yna o fewn rhai terfynau derbyniol. Byddwn hefyd yn siarad am hyn.
Yn unol â hynny, mae gan yr ARhPh feto i newid y cod. Ac yn gyffredinol, mae hyn hefyd yn arwain at ryw fath o wrthdaro bach os yw'r ARhPh yn cael ei weithredu'n anghywir. Yn yr un llyfr am Beirianneg Dibynadwyedd Safle, mae llawer o rannau, nid hyd yn oed un, yn dweud sut i osgoi'r gwrthdaro hyn.
Maen nhw'n gofyn sut mae ARhPh yn ymwneud â diogelwch gwybodaeth. Nid yw ARhPh yn ymwneud yn uniongyrchol â diogelwch gwybodaeth. Yn y bôn, mewn cwmnïau mawr, unigolion, profwyr, dadansoddwyr sy'n gwneud hyn. Ond mae SRE hefyd yn rhyngweithio â nhw yn yr ystyr y gall rhai gweithrediadau, rhai yn ymrwymo, rhai gosodiadau sy'n effeithio ar ddiogelwch hefyd effeithio ar argaeledd y cynnyrch. Felly, mae SRE yn ei gyfanrwydd yn rhyngweithio ag unrhyw dimau, gan gynnwys timau diogelwch, gan gynnwys dadansoddwyr. Felly, mae angen SREs yn bennaf pan fyddant yn ceisio gweithredu DevOps, ond ar yr un pryd, mae'r baich ar ddatblygwyr yn mynd yn rhy fawr. Hynny yw, ni all y tîm datblygu ei hun bellach ymdopi â'r ffaith bod angen iddynt fod yn gyfrifol am Ops yn awr hefyd. Ac mae rôl ar wahân. Mae'r rôl hon wedi'i chynllunio yn y gyllideb. Weithiau mae'r rôl hon wedi'i gosod ym maint y tîm, mae person ar wahân yn ymddangos, weithiau mae un o'r datblygwyr yn dod yn ei. Dyma sut mae'r ARhPh cyntaf yn ymddangos yn y tîm.
Mae cymhlethdod y system sy'n cael ei effeithio gan ARhPh, y cymhlethdod sy'n effeithio ar ddibynadwyedd y llawdriniaeth, yn angenrheidiol ac yn ddamweiniol. Cymhlethdod angenrheidiol yw pan fydd cymhlethdod cynnyrch yn cynyddu i'r graddau sy'n ofynnol gan nodweddion cynnyrch newydd. Cymhlethdod ar hap yw pan fydd cymhlethdod y system yn cynyddu, ond nid yw nodwedd y cynnyrch a'r gofynion busnes yn effeithio'n uniongyrchol ar hyn. Mae'n ymddangos bod naill ai'r datblygwr wedi gwneud camgymeriad yn rhywle, neu nad yw'r algorithm yn optimaidd, neu cyflwynir rhai diddordebau ychwanegol sy'n cynyddu cymhlethdod y cynnyrch heb angen arbennig. Dylai ARhPh dda dorri'r sefyllfa hon i ffwrdd bob amser. Hynny yw, unrhyw ymrwymiad, unrhyw ddefnydd, dylid atal unrhyw gais tynnu, lle mae'r anhawster yn cynyddu oherwydd adio ar hap.
Y cwestiwn yw pam na llogi peiriannydd, gweinyddwr system gyda llawer o wybodaeth yn y tîm. Dywedir wrthym nad datblygwr yn rôl peiriannydd yw'r ateb staffio gorau. Nid datblygwr yn rôl peiriannydd yw'r ateb staffio gorau bob amser, ond y pwynt yma yw bod gan ddatblygwr sy'n ymwneud ag Ops ychydig mwy o awydd am awtomeiddio, mae ganddo ychydig mwy o wybodaeth a set sgiliau er mwyn gweithredu yr awtomeiddio hwn. Ac yn unol â hynny, rydym yn lleihau nid yn unig yr amser ar gyfer rhai gweithrediadau penodol, nid yn unig y drefn arferol, ond hefyd paramedrau busnes mor bwysig â MTTR (Amser Cymedrig i Adfer, amser adfer). Felly, a byddwn hefyd yn siarad am hyn ychydig yn ddiweddarach, rydym yn arbed arian i'r sefydliad.
Nawr, gadewch i ni siarad am y meini prawf ar gyfer gweithredu ARhPh. Ac yn gyntaf oll am ddibynadwyedd. Mewn cwmnïau bach, cychwyniadau, mae'n aml yn digwydd bod pobl yn tybio, os yw'r gwasanaeth wedi'i ysgrifennu'n dda, os yw'r cynnyrch wedi'i ysgrifennu'n dda ac yn gywir, bydd yn gweithio, ni fydd yn torri. Dyna ni, rydyn ni'n ysgrifennu cod da, felly does dim byd i'w dorri. Mae'r cod yn syml iawn, nid oes dim i'w dorri. Mae'r rhain tua'r un bobl sy'n dweud nad oes angen profion arnom, oherwydd, edrychwch, dyma'r tri dull VPI, pam torri yma.
Mae hyn i gyd yn anghywir, wrth gwrs. Ac yn aml iawn mae'r bobl hyn yn cael eu brathu gan god o'r fath yn ymarferol, oherwydd bod pethau'n torri. Mae pethau'n torri weithiau yn y ffyrdd mwyaf anrhagweladwy. Weithiau bydd pobl yn dweud na, ni fydd byth yn digwydd. Ac mae'n digwydd drwy'r amser. Mae'n digwydd yn ddigon aml. A dyna pam nad oes neb byth yn ymdrechu am argaeledd 100%, oherwydd nid yw argaeledd 100% byth yn digwydd. Dyma'r norm. Ac felly, pan fyddwn yn sôn am argaeledd gwasanaeth, rydym bob amser yn siarad am naw. 2 naw, 3 naw, 4 naw, 5 naw. Os byddwn yn trosi hyn yn amser segur, yna, er enghraifft, 5 naw, yna mae hyn ychydig yn fwy na 5 munud o amser segur y flwyddyn, mae 2 naw yn 3,5 diwrnod o amser segur.
Ond mae'n amlwg ar ryw adeg bod gostyngiad mewn POI, adenillion ar fuddsoddiad. Mae mynd o ddau naw i dri naw yn golygu llai o amser segur o fwy na 3 diwrnod. Mae mynd o bedwar naw i bump yn lleihau amser segur 47 munud y flwyddyn. Ac mae'n troi allan efallai na fydd yn hollbwysig ar gyfer busnes. Ac yn gyffredinol, nid yw'r dibynadwyedd gofynnol yn fater technegol, yn gyntaf oll, mae'n fater busnes, mae'n fater o gynnyrch. Pa lefel o amser segur sy'n dderbyniol i ddefnyddwyr y cynnyrch, beth maen nhw'n ei ddisgwyl, faint maen nhw'n ei dalu, er enghraifft, faint o arian maen nhw'n ei golli, faint o arian y mae'r system yn ei golli.
Cwestiwn pwysig yma yw beth yw dibynadwyedd y cydrannau sy'n weddill. Oherwydd ni fydd y gwahaniaeth rhwng 4 a 5 nines yn weladwy ar ffôn clyfar gyda 2 naw o ddibynadwyedd. Yn fras, os bydd rhywbeth yn torri ar ffôn clyfar yn eich gwasanaeth 10 gwaith y flwyddyn, mae'n debyg 8 gwaith y dadansoddiad wedi digwydd ar ochr yr OS. Mae'r defnyddiwr wedi arfer â hyn, ac ni fydd yn talu sylw i un amser arall y flwyddyn. Mae angen cydberthyn pris cynyddu dibynadwyedd a chynyddu elw.
Yn union yn y llyfr ar ARhPh mae enghraifft dda o gynyddu i 4 naw o 3 naw. Mae'n ymddangos bod y cynnydd mewn argaeledd ychydig yn llai na 0,1%. Ac os yw refeniw'r gwasanaeth yn $1 miliwn y flwyddyn, yna $900 yw'r cynnydd mewn refeniw. Os yw'n costio llai na $900 y flwyddyn i ni gynyddu fforddiadwyedd o naw, mae'r cynnydd yn gwneud synnwyr ariannol. Os yw'n costio mwy na 900 o ddoleri y flwyddyn, nid yw bellach yn gwneud synnwyr, oherwydd nid yw'r cynnydd mewn refeniw yn gwneud iawn am gostau llafur, costau adnoddau. A bydd 3 naw yn ddigon i ni.
Mae hyn wrth gwrs yn enghraifft symlach lle mae pob cais yn gyfartal. Ac mae mynd o 3 naw i 4 naw yn ddigon hawdd, ond ar yr un pryd, er enghraifft, mynd o 2 naw i 3, mae hyn eisoes yn arbedion o 9 mil o ddoleri, gall wneud synnwyr ariannol. Yn naturiol, mewn gwirionedd, mae methiant y cais cofrestru yn waeth na'r methiant i arddangos y dudalen, mae gan geisiadau bwysau gwahanol. Efallai fod ganddynt faen prawf hollol wahanol o safbwynt busnes, ond beth bynnag, fel rheol, os nad ydym yn sôn am rai gwasanaethau penodol, mae hwn yn frasamcan eithaf dibynadwy.
Cawsom gwestiwn a yw ARhPh yn un o'r cydlynwyr wrth ddewis datrysiad pensaernïol ar gyfer y gwasanaeth. Gadewch i ni ddweud o ran integreiddio i'r seilwaith presennol, fel nad oes unrhyw golled yn ei sefydlogrwydd. Ydy, mae SREs, yn yr un modd ag y mae ceisiadau tynnu, ymrwymo, datganiadau yn effeithio ar y bensaernïaeth, cyflwyno gwasanaethau newydd, microwasanaethau, gweithredu atebion newydd. Pam wnes i ddweud cyn bod angen profiad, mae angen cymwysterau. Mewn gwirionedd, SRE yw un o'r lleisiau blocio mewn unrhyw ddatrysiad pensaernïol a meddalwedd. Yn unol â hynny, mae'n rhaid i SRE fel peiriannydd, yn gyntaf oll, nid yn unig ddeall, ond hefyd ddeall sut y bydd rhai penderfyniadau penodol yn effeithio ar ddibynadwyedd, sefydlogrwydd, a deall sut mae hyn yn berthnasol i anghenion busnes, ac o ba safbwynt y gall fod yn dderbyniol a sydd ddim.
Felly, nawr gallwn ni siarad am feini prawf dibynadwyedd, a ddiffinnir yn draddodiadol mewn SRE fel CLG (Cytundeb Lefel Gwasanaeth). Term cyfarwydd yn fwyaf tebygol. SLI (Dangosydd Lefel Gwasanaeth). SLO (Amcan Lefel Gwasanaeth). Efallai bod Cytundeb Lefel Gwasanaeth yn derm symbolaidd, yn enwedig os ydych wedi gweithio gyda rhwydweithiau, gyda darparwyr, gyda gwesteio. Mae hwn yn gytundeb cyffredinol sy'n disgrifio perfformiad eich gwasanaeth cyfan, cosbau, rhai cosbau am wallau, metrigau, meini prawf. A SLI yw'r metrig argaeledd ei hun. Hynny yw, yr hyn y gall SLI fod: amser ymateb gan y gwasanaeth, nifer y gwallau fel canran. Gallai fod yn lled band os yw'n rhyw fath o hosting ffeil. O ran algorithmau adnabod, gall y dangosydd fod, er enghraifft, hyd yn oed cywirdeb yr ateb. Mae SLO (Amcan Lefel Gwasanaeth), yn y drefn honno, yn gyfuniad o'r dangosydd SLI, ei werth a'i gyfnod.
Gadewch i ni ddweud y gallai'r CLG fod fel hyn. Mae'r gwasanaeth ar gael 99,95% o'r amser trwy gydol y flwyddyn. Neu bydd 99 o docynnau cymorth critigol ar gau o fewn 3 awr y chwarter. Neu bydd 85% o ymholiadau yn cael ymatebion o fewn 1,5 eiliad bob mis. Hynny yw, yn raddol rydym yn dod i ddeall bod gwallau a methiannau yn eithaf normal. Mae hon yn sefyllfa dderbyniol, rydym yn ei chynllunio, rydym hyd yn oed yn dibynnu arni i raddau. Hynny yw, mae SRE yn adeiladu systemau sy'n gallu gwneud camgymeriadau, y mae'n rhaid iddynt ymateb fel arfer i wallau, y mae'n rhaid eu cymryd i ystyriaeth. A phryd bynnag y bo modd, dylent drin gwallau yn y fath fodd fel nad yw'r defnyddiwr naill ai'n sylwi arnynt, neu'n sylwi arnynt, ond mae yna ryw fath o ateb, ac ni fydd popeth yn cwympo'n llwyr oherwydd hynny.
Er enghraifft, os ydych chi'n uwchlwytho fideo i YouTube, ac na all YouTube ei drosi ar unwaith, os yw'r fideo yn rhy fawr, os nad yw'r fformat yn optimaidd, yna yn naturiol ni fydd y cais yn methu gyda goramser, ni fydd YouTube yn rhoi gwall 502 , Bydd YouTube yn dweud: “Rydym wedi creu popeth, mae eich fideo yn cael ei brosesu. Bydd yn barod mewn tua 10 munud." Dyma'r egwyddor o ddiraddio gosgeiddig, sy'n gyfarwydd, er enghraifft, o ddatblygiad pen blaen, os ydych chi erioed wedi gwneud hyn.
Y termau nesaf y byddwn yn siarad amdanynt, sy'n bwysig iawn ar gyfer gweithio gyda dibynadwyedd, gyda gwallau, gyda disgwyliadau, yw MTBF a MTTR. MTBF yw'r amser cymedrig rhwng methiannau. Amser Cymedrig MTTR i Adferiad, amser cyfartalog i adferiad. Hynny yw, faint o amser sydd wedi mynd heibio o'r eiliad y darganfuwyd y gwall, o'r eiliad yr ymddangosodd y gwall i'r eiliad y cafodd y gwasanaeth ei adfer i weithrediad arferol llawn. Mae MTBF yn cael ei osod yn bennaf gan waith ar ansawdd cod. Hynny yw, y ffaith y gall SREs ddweud "na". Ac mae angen dealltwriaeth y tîm cyfan arnoch, pan fydd ARhPh yn dweud "na", mae'n ei ddweud nid oherwydd ei fod yn niweidiol, nid oherwydd ei fod yn ddrwg, ond oherwydd fel arall bydd pawb yn dioddef.
Unwaith eto, mae yna lawer o erthyglau, llawer o ddulliau, llawer o ffyrdd hyd yn oed yn yr union lyfr rydw i'n cyfeirio ato mor aml, sut i wneud yn siŵr nad yw datblygwyr eraill yn dechrau casáu ARhPh. Mae MTTR, ar y llaw arall, yn ymwneud â gweithio ar eich SLO (Amcan Lefel Gwasanaeth). Ac mae'n bennaf awtomeiddio. Oherwydd, er enghraifft, mae ein SLO yn uptime o 4 naw y chwarter. Mae hyn yn golygu y gallwn ganiatáu 3 munud o amser segur mewn 13 mis. Ac mae'n ymddangos na all MTTR fod yn fwy na 13 munud. Os byddwn yn ymateb i o leiaf 13 amser segur mewn 1 munud, mae hyn yn golygu ein bod eisoes wedi disbyddu'r gyllideb gyfan ar gyfer y chwarter. Rydym yn torri'r SLO. Mae 13 munud i ymateb a thrwsio damwain yn llawer i beiriant, ond yn fyr iawn i ddyn. Oherwydd hyd nes y bydd person yn derbyn rhybudd, nes ei fod yn ymateb, nes ei fod yn deall y gwall, mae eisoes yn sawl munud. Hyd nes y bydd person yn deall sut i'w drwsio, beth yn union i'w drwsio, beth i'w wneud, yna mae hyn ychydig mwy o funudau. Ac mewn gwirionedd, hyd yn oed os oes angen i chi ailgychwyn y gweinydd, fel y mae'n digwydd, neu godi nod newydd, yna mae MTTR â llaw eisoes tua 7-8 munud. Wrth awtomeiddio'r broses, mae MTTR yn aml iawn yn cyrraedd eiliad, weithiau milieiliadau. Mae Google fel arfer yn siarad am milieiliadau, ond mewn gwirionedd, wrth gwrs, nid yw popeth mor dda.
Yn ddelfrydol, dylai'r ARhPh awtomeiddio ei waith bron yn gyfan gwbl, oherwydd mae hyn yn effeithio'n uniongyrchol ar y MTTR, ei fetrigau, SLO y gwasanaeth cyfan, ac, yn unol â hynny, elw'r busnes. Os eir y tu hwnt i'r amser, gofynnir i ni a yw ARhPh ar fai. Yn ffodus, does neb ar fai. Ac mae hwn yn ddiwylliant ar wahân o'r enw postmortem balmeless, na fyddwn yn siarad amdano heddiw, ond byddwn yn ei ddadansoddi ar Slurm. Mae hwn yn bwnc diddorol iawn y gellir siarad llawer amdano. Yn fras, os eir y tu hwnt i'r amser a neilltuwyd fesul chwarter, yna ychydig o bawb sydd ar fai, sy'n golygu nad yw beio pawb yn gynhyrchiol, gadewch i ni yn lle hynny, efallai nid beio neb, ond cywiro'r sefyllfa a gweithio gyda'r hyn sydd gennym. Yn fy mhrofiad i, mae'r dull hwn ychydig yn estron i'r rhan fwyaf o dimau, yn enwedig yn Rwsia, ond mae'n gwneud synnwyr ac yn gweithio'n dda iawn. Felly, byddaf yn argymell ar ddiwedd yr erthygl a'r llenyddiaeth y gallwch eu darllen ar y pwnc hwn. Neu dewch i SRE Slurm.
Gadewch i mi egluro. Os eir y tu hwnt i'r amser SLO y chwarter, os nad 13 munud oedd yr amser segur, ond 15, pwy all fod ar fai am hyn? Wrth gwrs, efallai mai ARhPh sydd ar fai, oherwydd ei fod yn amlwg wedi gwneud rhyw fath o ymrwymiad neu ddefnydd gwael. Efallai mai gweinyddwr y ganolfan ddata sydd ar fai am hyn, oherwydd efallai ei fod wedi gwneud rhyw fath o waith cynnal a chadw heb ei drefnu. Os mai gweinyddwr y ganolfan ddata sydd ar fai am hyn, yna'r person o Ops sydd ar fai am hyn, na chyfrifodd y gwaith cynnal a chadw pan gydlynodd yr SLO. Y rheolwr, cyfarwyddwr technegol neu rywun a lofnododd gontract y ganolfan ddata ac na thalodd sylw at y ffaith nad yw CLG y ganolfan ddata wedi'i gynllunio ar gyfer yr amser segur gofynnol sydd ar fai am hyn. Yn unol â hynny, ychydig ar y tro yn y sefyllfa hon sydd ar fai. Ac mae'n golygu nad oes diben gosod y bai ar unrhyw un yn y sefyllfa hon. Ond wrth gwrs mae angen ei gywiro. Dyna pam y ceir post mortem. Ac os darllenwch, er enghraifft, post mortem GitHub, ac mae hon bob amser yn stori ddiddorol, fach ac annisgwyl iawn ym mhob achos, gallwch gymryd lle nad oes neb byth yn dweud mai'r person penodol hwn oedd ar fai. Rhoddir y bai bob amser ar brosesau amherffaith penodol.
Symudwn ymlaen at y cwestiwn nesaf. Awtomatiaeth. Pan soniaf am awtomeiddio mewn cyd-destunau eraill, cyfeiriaf yn aml at dabl sy’n dweud wrthych pa mor hir y gallwch weithio ar awtomeiddio tasg heb gymryd mwy o amser i’w hawtomeiddio nag yr ydych yn ei arbed mewn gwirionedd. Mae yna snag. Y dal yw, pan fydd SREs yn awtomeiddio tasg, maen nhw nid yn unig yn arbed amser, maen nhw'n arbed arian, oherwydd mae awtomeiddio yn effeithio'n uniongyrchol ar MTTR. Maent yn arbed, fel petai, morâl gweithwyr a datblygwyr, sydd hefyd yn adnodd dihysbydd. Maent yn lleihau'r drefn. Ac mae hyn i gyd yn cael effaith gadarnhaol ar waith ac, o ganlyniad, ar fusnes, hyd yn oed os yw'n ymddangos nad yw awtomeiddio yn gwneud synnwyr o ran costau amser.
Mewn gwirionedd, mae wedi gwneud hynny bron bob amser, ac ychydig iawn o achosion sydd lle na ddylai rhywbeth gael ei awtomeiddio yn rôl ARhPh. Nesaf byddwn yn siarad am yr hyn a elwir yn gyllideb gwallau, y gyllideb ar gyfer gwallau. Mewn gwirionedd, mae'n ymddangos, os yw popeth yn llawer gwell i chi na'r SLO a osodwyd gennych chi'ch hun, nid yw hyn hefyd yn dda iawn. Mae hyn braidd yn ddrwg, oherwydd mae SLO yn gweithio nid yn unig fel ffin isaf, ond hefyd fel ffin uchaf fras. Pan osodoch SLO o 99% o argaeledd, ac mewn gwirionedd mae gennych 99,99%, mae'n ymddangos bod gennych rywfaint o le ar gyfer arbrofion na fyddant yn niweidio'r busnes o gwbl, oherwydd rydych chi'ch hun wedi pennu hyn i gyd gyda'ch gilydd, ac rydych yn nid yw'r gofod hwn yn defnyddio. Mae gennych gyllideb ar gyfer camgymeriadau, nad ydynt yn cael eu defnyddio i fyny yn eich achos chi.
Beth ydyn ni'n ei wneud ag ef. Rydyn ni'n ei ddefnyddio ar gyfer popeth yn llythrennol. Ar gyfer profi mewn amodau cynhyrchu, ar gyfer cyflwyno nodweddion newydd a allai effeithio ar berfformiad, ar gyfer rhyddhau, ar gyfer cynnal a chadw, ar gyfer amseroedd segur a gynlluniwyd. Mae'r rheol gwrthdro hefyd yn berthnasol: os yw'r gyllideb wedi'i disbyddu, ni allwn ryddhau unrhyw beth newydd, oherwydd fel arall byddwn yn mynd y tu hwnt i'r SLO. Mae'r gyllideb eisoes wedi'i disbyddu, rydym wedi rhyddhau rhywbeth os yw'n effeithio'n negyddol ar berfformiad, hynny yw, os nad yw hwn yn rhyw fath o atgyweiriad sydd ynddo'i hun yn cynyddu'r SLO yn uniongyrchol, yna rydym yn mynd y tu hwnt i'r gyllideb, ac mae hon yn sefyllfa wael. , mae angen ei ddadansoddi , post mortem, ac o bosibl rhai atgyweiriadau proses.
Hynny yw, mae'n ymddangos, os nad yw'r gwasanaeth ei hun yn gweithio'n dda, a bod SLO yn cael ei wario a bod y gyllideb yn cael ei gwario nid ar arbrofion, nid ar rai datganiadau, ond ar ei ben ei hun, yna yn lle rhai atebion diddorol, yn lle nodweddion diddorol, yn lle datganiadau diddorol. Yn lle unrhyw waith creadigol, bydd yn rhaid i chi ddelio ag atebion twp i gael trefn ar y gyllideb yn ôl, neu olygu'r SLO, ac mae hon hefyd yn broses na ddylai ddigwydd yn rhy aml.
Felly, mae'n ymddangos bod gan bawb ddiddordeb mewn sefyllfa lle mae gennym fwy o gyllideb ar gyfer gwallau: ARhPh a datblygwyr. I ddatblygwyr, mae cyllideb fawr ar gyfer chwilod yn golygu y gallwch chi ddelio â datganiadau, profion, arbrofion. Ar gyfer SREs, mae cyllideb ar gyfer gwallau a nodi'r gyllideb honno yn golygu eu bod yn gwneud eu gwaith yn dda yn uniongyrchol. Ac mae hyn yn effeithio ar gymhelliant rhyw fath o waith ar y cyd. Os gwrandewch ar eich SREs fel datblygwyr, bydd gennych fwy o le ar gyfer gwaith da a llawer llai o drefn.
Mae'n ymddangos bod arbrofion mewn cynhyrchu yn rhan eithaf pwysig a bron yn rhan annatod o ARhPh mewn timau mawr. Ac fe'i gelwir fel arfer yn beirianneg anhrefn, sy'n dod o'r tîm yn Netflix a ryddhaodd gyfleustodau o'r enw Chaos Monkey.
Mae Chaos Monkey yn cysylltu â'r biblinell CI / CD ac yn chwalu'r gweinydd wrth gynhyrchu ar hap. Unwaith eto, yn y strwythur ARhPh, rydym yn sôn am y ffaith nad yw gweinydd wedi'i ostwng yn ddrwg ynddo'i hun, disgwylir. Ac os yw o fewn y gyllideb, mae'n dderbyniol ac nid yw'n niweidio'r busnes. Wrth gwrs, mae gan Netflix ddigon o weinyddion segur, digon o ddyblygu, fel y gellir trwsio hyn i gyd, ac fel nad yw'r defnyddiwr cyfan hyd yn oed yn sylwi, a hyd yn oed yn fwy felly nid oes neb yn gadael un gweinydd am unrhyw gyllideb.
Roedd gan Netflix gyfres gyfan o gyfleustodau o'r fath am gyfnod, ac mae un ohonynt, Chaos Gorilla, yn cau un o Barthau Argaeledd Amazon yn llwyr. Ac mae pethau o'r fath yn helpu i ddatgelu, yn gyntaf, ddibyniaethau cudd, pan nad yw'n gwbl glir beth sy'n effeithio ar beth, beth sy'n dibynnu ar beth. A hyn, os ydych chi'n gweithio gyda microwasanaeth, ac nad yw'r ddogfennaeth yn berffaith, efallai y bydd hyn yn gyfarwydd i chi. Ac eto, mae hyn yn helpu llawer i ddal gwallau yn y cod na allwch eu dal ar lwyfannu, oherwydd nid yw unrhyw lwyfannu yn union efelychiad, oherwydd y ffaith bod y raddfa lwyth yn wahanol, mae'r patrwm llwyth yn wahanol, mae'r offer yn wahanol. hefyd, tebycaf, arall. Gall llwythi brig hefyd fod yn annisgwyl ac yn anrhagweladwy. Ac mae profion o'r fath, nad ydynt eto'n mynd y tu hwnt i'r gyllideb, yn helpu'n dda iawn i ddal gwallau yn y seilwaith na fydd llwyfannu, autotests, piblinell CI / CD byth yn dal. A chyn belled â bod y cyfan wedi'i gynnwys yn eich cyllideb, nid oes ots bod eich gwasanaeth wedi mynd i lawr yno, er y byddai'n ymddangos yn frawychus iawn, aeth y gweinydd i lawr, am hunllef. Na, mae hynny'n normal, mae hynny'n dda, sy'n helpu i ddal chwilod. Os oes gennych gyllideb, yna gallwch ei wario.
C: Pa lenyddiaeth y gallaf ei hargymell? Rhestr ar y diwedd. Mae llawer o lenyddiaeth, byddaf yn cynghori ychydig o adroddiadau. Sut mae'n gweithio, ac a yw ARhPh yn gweithio mewn cwmnïau heb eu cynnyrch meddalwedd eu hunain neu heb fawr o ddatblygiad. Er enghraifft, mewn menter lle nad meddalwedd yw'r prif weithgaredd. Mewn menter, lle nad yw'r prif weithgaredd yn feddalwedd, mae SRE yn gweithio'n union yr un fath ag ym mhobman arall, oherwydd mewn menter mae angen i chi hefyd ddefnyddio cynhyrchion meddalwedd, hyd yn oed os na chânt eu datblygu, mae angen i chi gyflwyno diweddariadau, mae angen i chi newid. y seilwaith, mae angen i chi dyfu, mae angen i chi raddfa. Ac mae SREs yn helpu i nodi a rhagweld problemau posibl yn y prosesau hyn a'u rheoli ar ôl i rywfaint o dwf ddechrau ac anghenion busnes newid. Oherwydd nid yw'n gwbl angenrheidiol bod yn rhan o ddatblygu meddalwedd er mwyn cael SRE os oes gennych o leiaf ychydig o weinyddion a disgwylir i chi gael rhywfaint o dwf o leiaf.
Mae'r un peth yn wir am brosiectau bach, sefydliadau bach, oherwydd bod gan gwmnïau mawr y gyllideb a'r lle i arbrofi. Ond ar yr un pryd, gellir defnyddio'r holl ffrwythau hyn o arbrofion yn unrhyw le, hynny yw, SRE, wrth gwrs, yn ymddangos yn Google, yn Netflix, yn Dropbox. Ond ar yr un pryd, gall cwmnïau bach a busnesau newydd ddarllen deunydd cywasgedig, darllen llyfrau, gwylio adroddiadau. Maen nhw'n dechrau clywed amdano'n amlach, maen nhw'n edrych ar enghreifftiau penodol, rwy'n meddwl ei fod yn iawn, gall fod yn ddefnyddiol mewn gwirionedd, mae angen hyn arnom hefyd, mae'n wych.
Hynny yw, mae'r holl brif waith ar safoni'r prosesau hyn eisoes wedi'i wneud i chi. Chi sy'n parhau i benderfynu ar rôl ARhPh yn benodol yn eich cwmni a dechrau gweithredu'r holl arferion hyn, sydd, unwaith eto, wedi'u disgrifio eisoes. Hynny yw, o egwyddorion defnyddiol i gwmnïau bach, dyma'r diffiniad o CLG, SLI, SLO bob amser. Os nad ydych yn ymwneud â meddalwedd, yna CLGau mewnol a SLOs mewnol fydd y rhain, sef cyllideb fewnol ar gyfer gwallau. Mae hyn bron bob amser yn arwain at rai trafodaethau diddorol o fewn y tîm ac o fewn y busnes, oherwydd efallai y byddwch yn gwario ar seilwaith, ar ryw fath o drefnu prosesau delfrydol, mae'r biblinell ddelfrydol yn llawer mwy nag sydd ei angen. A'r 4 naw hyn sydd gennych chi yn yr adran TG, nid oes eu hangen arnoch chi nawr. Ond ar yr un pryd, fe allech chi dreulio amser, gwario'r gyllideb am gamgymeriadau ar rywbeth arall.
Yn unol â hynny, mae monitro a threfnu monitro yn ddefnyddiol i gwmni o unrhyw faint. Ac yn gyffredinol, y ffordd hon o feddwl, lle mae camgymeriadau yn rhywbeth derbyniol, lle mae cyllideb, lle mae Amcanion, mae eto'n ddefnyddiol i gwmni o unrhyw faint, gan ddechrau o startups ar gyfer 3 o bobl.
Yr olaf o'r naws technegol i siarad amdano yw monitro. Oherwydd os ydym yn sôn am CLG, SLI, SLO, ni allwn ddeall heb fonitro a ydym yn ffitio i mewn i'r gyllideb, a ydym yn cydymffurfio â'n Hamcanion, a sut yr ydym yn dylanwadu ar y CLG terfynol. Rwyf wedi gweld cymaint o weithiau bod monitro yn digwydd fel hyn: mae rhywfaint o werth, er enghraifft, amser cais i'r gweinydd, yr amser cyfartalog, neu nifer y ceisiadau i'r gronfa ddata. Mae ganddo safon a bennir gan beiriannydd. Os yw'r metrig yn gwyro oddi wrth y norm, yna mae e-bost yn cyrraedd. Mae hyn i gyd yn gwbl ddiwerth, fel rheol, oherwydd ei fod yn arwain at ormodedd o rybuddion, llu o negeseuon monitro, pan fydd yn rhaid i berson, yn gyntaf, eu dehongli bob tro, hynny yw, penderfynu a yw gwerth y modd metrig. yr angen am ryw weithred. Ac yn ail, mae'n rhoi'r gorau i sylwi ar yr holl rybuddion hyn, pan nad oes angen unrhyw gamau ganddo yn y bôn. Mae honno'n rheol fonitro dda a'r rheol gyntaf un pan fydd ARhPh yn cael ei rhoi ar waith yw mai dim ond pan fydd angen gweithredu y dylid hysbysu.
Yn yr achos safonol, mae 3 lefel o ddigwyddiadau. Mae rhybuddion, mae tocynnau, mae logiau. Mae rhybuddion yn unrhyw beth sy'n gofyn ichi gymryd camau ar unwaith. Hynny yw, mae popeth wedi torri, mae angen i chi ei drwsio ar hyn o bryd. Tocynnau sy'n gofyn am oedi cyn gweithredu. Oes, mae angen i chi wneud rhywbeth, mae angen i chi wneud rhywbeth â llaw, methodd awtomeiddio, ond nid oes rhaid i chi ei wneud am yr ychydig funudau nesaf. Mae logiau yn unrhyw beth nad oes angen gweithredu arno, ac yn gyffredinol, os aiff pethau'n dda, ni fydd neb byth yn eu darllen. Dim ond pan fydd yn digwydd, wrth edrych yn ôl, y torrodd rhywbeth ers peth amser, nid oeddem yn gwybod amdano y bydd angen i chi ddarllen y logiau. Neu a oes angen i chi wneud rhywfaint o ymchwil. Ond yn gyffredinol, mae popeth nad oes angen unrhyw gamau ar ei gyfer yn mynd i'r logiau.
Fel sgil-effaith i hyn oll, os ydym wedi diffinio pa ddigwyddiadau y mae angen gweithredu arnynt ac wedi disgrifio’n dda beth ddylai’r camau hyn fod, mae hyn yn golygu y gellir awtomeiddio’r cam gweithredu. Hynny yw, beth sy'n digwydd. Awn o effro. Gadewch i ni fynd i weithredu. Awn at y disgrifiad o'r weithred hon. Ac yna symudwn ymlaen at awtomeiddio. Hynny yw, mae unrhyw awtomeiddio yn dechrau gydag adwaith i ddigwyddiad.
O fonitro, symudwn ymlaen at derm o’r enw Arsylwedd. Mae ychydig o hype wedi bod o gwmpas y gair hwn hefyd dros y blynyddoedd diwethaf. Ac ychydig o bobl sy'n deall beth mae'n ei olygu allan o'r cyd-destun. Ond y prif bwynt yw bod Observability yn fetrig ar gyfer tryloywder system. Os aeth rhywbeth o'i le, pa mor gyflym allwch chi benderfynu beth yn union aeth o'i le a beth oedd cyflwr y system ar y foment honno. O ran cod: pa swyddogaeth a fethodd, pa wasanaeth a fethodd. Beth oedd cyflwr, er enghraifft, newidynnau mewnol, cyfluniad. O ran seilwaith, dyma ym mha parth argaeledd y digwyddodd y methiant, ac os oes gennych unrhyw Kubernetes, yna ym mha goden y digwyddodd y methiant, beth oedd cyflwr y pod. Ac yn unol â hynny, mae gan Observability berthynas uniongyrchol â MTTR. Po uchaf yw Arsylwedd y gwasanaeth, yr hawsaf yw nodi'r gwall, yr hawsaf yw trwsio'r gwall, yr hawsaf yw awtomeiddio'r gwall, yr isaf yw'r MTTR.
Gan symud ymlaen at gwmnïau bach eto, mae'n gyffredin iawn gofyn, hyd yn oed nawr, sut i ddelio â maint tîm, ac a oes angen i dîm bach logi ARhPh ar wahân. Eisoes wedi siarad am hyn ychydig yn gynharach. Ar gamau cyntaf datblygiad busnes newydd neu, er enghraifft, tîm, nid yw hyn yn angenrheidiol o gwbl, oherwydd gellir gwneud ARhPh yn rôl drosiannol. A bydd hyn yn adfywio'r tîm ychydig, oherwydd mae o leiaf rhywfaint o amrywiaeth. Ac yn ogystal bydd yn paratoi pobl ar gyfer y ffaith, gyda thwf, yn gyffredinol, y bydd cyfrifoldebau ARhPh yn newid yn sylweddol iawn. Os ydych chi'n llogi person, yna, wrth gwrs, mae ganddo rai disgwyliadau. Ac ni fydd y disgwyliadau hyn yn newid dros amser, ond bydd y gofynion yn newid yn fawr iawn. Felly, mae sut i logi ARhPh yn eithaf anodd yn y camau cynnar. Mae tyfu eich rhai eich hun yn llawer haws. Ond mae'n werth meddwl amdano.
Yr unig eithriad, efallai, yw pan fo gofynion twf llym iawn ac wedi’u diffinio’n dda. Hynny yw, yn achos cychwyn, gall hyn fod yn rhyw fath o bwysau gan fuddsoddwyr, rhyw fath o ragolwg ar gyfer twf sawl gwaith ar unwaith. Yna gellir cyfiawnhau llogi ARhPh yn y bôn oherwydd gellir ei gyfiawnhau. Mae gennym ofynion ar gyfer twf, mae angen person arnom a fydd yn gyfrifol am y ffaith na fydd unrhyw beth yn torri gyda thwf o'r fath.
Un cwestiwn arall. Beth i'w wneud pan fydd y datblygwyr sawl gwaith yn torri nodwedd sy'n pasio'r profion, ond yn torri'r cynhyrchiad, yn llwytho'r sylfaen, yn torri nodweddion eraill, pa broses i'w gweithredu. Yn unol â hynny, yn yr achos hwn, y gyllideb ar gyfer gwallau a gyflwynir. Ac mae rhai o'r gwasanaethau, rhai o'r nodweddion eisoes yn cael eu profi yn y cynhyrchiad. Gall fod yn ganeri, pan mai dim ond nifer fach o ddefnyddwyr, ond eisoes yn y cynhyrchiad, mae nodwedd yn cael ei defnyddio, ond eisoes gyda'r disgwyliad, os bydd rhywbeth yn torri, er enghraifft, ar gyfer hanner y cant o'r holl ddefnyddwyr, bydd yn dal i fodloni'r gyllideb ar gyfer gwallau. Yn unol â hynny, ie, bydd gwall, i rai defnyddwyr bydd popeth yn torri, ond rydym eisoes wedi dweud bod hyn yn normal.
Roedd cwestiwn am offer ARhPh. Hynny yw, a oes rhywbeth penodol y byddai SREs yn ei ddefnyddio na fyddai pawb arall yn ei ddefnyddio. Mewn gwirionedd, mae yna rai cyfleustodau hynod arbenigol, mae yna ryw fath o feddalwedd sydd, er enghraifft, yn efelychu llwythi neu'n cymryd rhan mewn profion caneri A / B. Ond yn y bôn y pecyn cymorth ARhPh yw'r hyn y mae eich datblygwyr eisoes yn ei ddefnyddio. Oherwydd bod ARhPh yn rhyngweithio'n uniongyrchol â'r tîm datblygu. Ac os oes gennych wahanol offer, bydd yn cymryd amser i gydamseru. Yn enwedig os yw SREs yn gweithio mewn timau mawr, mewn cwmnïau mawr lle gall fod sawl tîm, safoni ar draws y cwmni a fydd yn helpu llawer yma, oherwydd os defnyddir 50 o wahanol gyfleustodau mewn 50 o dimau, mae hyn yn golygu bod yn rhaid i'r ARhPh eu gwybod. I gyd. Ac wrth gwrs ni fydd hyn byth yn digwydd. Ac ansawdd y gwaith, bydd ansawdd rheolaeth o leiaf rhai o'r timau yn gostwng yn sylweddol.
Mae ein gweminar yn dod i ben. Llwyddais i ddweud rhai pethau sylfaenol. Wrth gwrs, ni ellir dweud a deall dim byd am ARhPh mewn awr. Ond rwy’n gobeithio fy mod wedi llwyddo i gyfleu’r ffordd hon o feddwl, y prif bwyntiau allweddol. Ac yna bydd yn bosibl, os oes gennych ddiddordeb, ymchwilio i'r pwnc, dysgu ar eich pen eich hun, edrych ar sut mae'n cael ei weithredu gan bobl eraill, mewn cwmnïau eraill. Ac yn unol â hynny, yn gynnar ym mis Chwefror, dewch atom yn SRE Slurm.
Mae’r Slurm SRE yn gwrs dwys tri diwrnod a fydd yn sôn am yr hyn yr wyf yn sôn yn awr amdano, ond gyda llawer mwy o ddyfnder, gydag achosion go iawn, gydag ymarfer, mae’r holl ddwys wedi’i anelu at waith ymarferol. Bydd pobl yn cael eu rhannu'n dimau. Byddwch i gyd yn gweithio ar achosion go iawn. Yn unol â hynny, mae gennym hyfforddwyr Booking.com Ivan Kruglov a Ben Tyler. Mae gennym Eugene Barabbas bendigedig gan Google, o San Francisco. A dywedaf rywbeth wrthych hefyd. Felly gwnewch yn siŵr eich bod chi'n ymweld â ni.
Felly, y llyfryddiaeth. Ceir cyfeiriadau ar ARhPh. ar yr un llyfr, neu yn hytrach ar 2 lyfr am ARhPh, a ysgrifennwyd gan Google. Un arall , lle mae'r telerau a'u cymhwysiad ychydig yn fwy manwl. Mae'r 3 nesaf yn adroddiadau ar ARhPh mewn gwahanol gwmnïau. Yn gyntaf - , dyma gyweirnod gan Ben Trainer o Google. Ail - . Mae'r trydydd eto . Pedwerydd adroddiad gan , sydd â dim ond 5 o weithwyr ARhPh allweddol mewn 190 o wledydd. Mae'n ddiddorol iawn edrych ar hyn i gyd, oherwydd yn union fel y mae DevOps yn golygu pethau gwahanol iawn i wahanol gwmnïau a hyd yn oed gwahanol dimau, mae gan SRE gyfrifoldebau gwahanol iawn, hyd yn oed mewn cwmnïau o feintiau tebyg.
2 ddolen arall ar egwyddorion peirianneg anhrefn: , . Ac ar y diwedd mae 3 rhestr o'r gyfres Awesome Lists about , am ac am . Mae'r rhestr ar ARhPh yn anhygoel o enfawr, nid oes angen mynd trwy'r cyfan, mae tua 200 o erthyglau. Rwy’n argymell yn fawr erthyglau oddi yno am gynllunio capasiti ac am bost mortem di-fai.
Erthygl ddiddorol:
Diolch i chi am wrando arnaf trwy'r amser hwn. Gobeithio eich bod wedi dysgu rhywbeth. Gobeithio bod gennych chi ddigon o ddeunydd i ddysgu hyd yn oed mwy. A gweld chi. Ym mis Chwefror gobeithio.
Eduard Medvedev oedd yn cynnal y gweminar.
ON: i'r rhai sy'n hoffi darllen, rhoddodd Eduard restr o gyfeiriadau. Mae croeso i'r rhai y mae'n well ganddynt ddeall yn ymarferol .
Ffynhonnell: hab.com