Webinar ima slab zvok, zato smo naredili prepis.
Moje ime je Medvedev Eduard. Danes bom govoril o tem, kaj je SRE, kako se je SRE pojavil, kakšni so delovni kriteriji SRE inženirjev, malo o merilih zanesljivosti, malo o njegovem spremljanju. Bomo šli čez vrh, ker v eni uri ne moreš veliko povedati, ti pa dam materiale v dodatni pregled, vsi pa te čakamo na . konec januarja v Moskvi.
Najprej se pogovorimo o tem, kaj je SRE – Site Reliability Engineering. In kako se je pojavila kot posebna pozicija, kot posebna smer. Vse se je začelo z dejstvom, da sta v tradicionalnih razvojnih krogih Dev in Ops dve popolnoma različni ekipi, običajno z dvema popolnoma različnima ciljema. Cilj razvojne ekipe je uvesti nove funkcije za izpolnjevanje poslovnih potreb. Cilj ekipe Ops je zagotoviti, da vse deluje in da se nič ne pokvari. Očitno si ti cilji neposredno nasprotujejo: tako da vse deluje in se nič ne pokvari, je bolje čim manj uvajati nove funkcije. Zaradi tega nastajajo številni notranji konflikti, ki jih skuša rešiti metodologija, ki se danes imenuje DevOps.
Težava je v tem, da nimamo jasne definicije DevOps in jasne implementacije DevOps. Pred dvema letoma sem govoril na konferenci v Jekaterinburgu in do zdaj se je razdelek DevOps začel s poročilom »Kaj je DevOps«. Leta 2 je devops star skoraj 2017 let, a se še vedno prepiramo, kaj je. In to je zelo čudna situacija, ki jo je Google poskušal rešiti pred nekaj leti.
Leta 2016 je Google izdal knjigo z naslovom »Site Reliability Engineering«. In pravzaprav se je s to knjigo začelo gibanje SRE. SRE je posebna možnost za implementacijo paradigme DevOps v določenem podjetju. Inženirji SRE so si zadali cilj zagotoviti zanesljivo delovanje sistemov. Večinoma so vzeti od razvijalcev, včasih tudi od skrbnikov z močnim razvojnim ozadjem. In delajo to, kar so nekoč počeli sistemski skrbniki, vendar močno razvojno ozadje in poznavanje sistema s kodnega vidika privede do tega, da ti ljudje niso nagnjeni k rutinskemu administrativnemu delu, ampak k avtomatizaciji.
Izkazalo se je, da se paradigma DevOps v ekipah SRE izvaja z dejstvom, da obstajajo inženirji SRE, ki rešujejo strukturne probleme. Tukaj je ista povezava med Dev in Ops, o kateri ljudje govorijo že 8 let. Vloga SRE je podobna vlogi arhitekta, saj novinci ne postanejo SRE. Ljudje na začetku kariere še nimajo izkušenj in zahtevane širine znanja. Ker SRE zahteva zelo prefinjeno znanje o tem, kaj točno in kdaj gre lahko narobe. Zato so tu praviloma potrebne določene izkušnje, tako znotraj podjetja kot zunaj njega.
Sprašujejo, ali bo opisana razlika med SRE in devops. Pravkar je bila opisana. Lahko govorimo o mestu SRE v organizaciji. Za razliko od klasičnega pristopa DevOps, kjer je Ops še vedno ločen oddelek, je SRE del razvojne ekipe. Sodelujejo pri razvoju izdelkov. Obstaja celo pristop, kjer je SRE vloga, ki prehaja z enega razvijalca na drugega. Pri pregledih kode sodelujejo na enak način kot na primer UX oblikovalci, sami razvijalci in včasih produktni vodje. SRE delujejo na isti ravni. Potrebujemo njihovo odobritev, potrebujemo njihov pregled, tako da SRE za vsako uvedbo reče: »V redu, ta uvedba, ta izdelek ne bo negativno vplival na zanesljivost. In če bo, bo v nekih sprejemljivih mejah.” Tudi o tem bomo govorili.
Skladno s tem ima SRE veto na spremembe kodeksa. In na splošno to vodi tudi do nekaterih manjših konfliktov, če je SRE implementiran nepravilno. V isti knjigi o inženiringu zanesljivosti mesta veliko delov, celo več kot en, pove, kako se izogniti tem konfliktom.
Ljudje se sprašujejo, kako je SRE povezan z informacijsko varnostjo. SRE ni neposredno vključen v informacijsko varnost. Večinoma v velikih podjetjih to delajo posamezniki, preizkuševalci in analitiki. Toda SRE sodeluje tudi z njimi v smislu, da lahko nekatere operacije, nekatere potrditve, nekatere uvedbe, ki vplivajo na varnost, vplivajo tudi na razpoložljivost izdelka. Zato ima SRE na splošno interakcijo z vsemi ekipami, vključno z varnostnimi ekipami, vključno z analitiki. Zato so SRE potrebni predvsem pri poskusu implementacije DevOps, vendar postane breme za razvijalce preveliko. To pomeni, da se razvojna ekipa sama ne more več spopasti z dejstvom, da mora zdaj biti odgovorna tudi za Ops. In pojavi se ločena vloga. Ta vloga je predvidena v proračunu. Včasih je ta vloga vgrajena v velikost ekipe, pojavi se ločena oseba, včasih postane eden od razvijalcev. Tako se v ekipi pojavi prvi SRE.
Kompleksnost sistema, na katero vpliva SRE, kompleksnost, ki vpliva na zanesljivost delovanja, je lahko nujna ali naključna. Nujna kompleksnost je takrat, ko se kompleksnost izdelka poveča do te mere, da zahtevajo nove lastnosti izdelka. Naključna kompleksnost je, ko se kompleksnost sistema poveča, vendar funkcija izdelka in poslovne zahteve na to neposredno ne vplivajo. Izkazalo se je, da se je razvijalec nekje zmotil ali algoritem ni optimalen ali pa so vneseni dodatni interesi, ki po nepotrebnem povečujejo kompleksnost izdelka. Dober SRE bi se moral tej situaciji vedno izogibati. To pomeni, da bi morala biti blokirana vsaka objava, vsaka uvedba, vsaka zahteva za vlečenje, ki poveča kompleksnost zaradi naključnih dodatkov.
Vprašanje je, zakaj ne bi kar zaposlili inženirja, sistemskega administratorja z veliko znanja, ki bi se pridružil ekipi. Razvijalec v vlogi inženirja, nam pravijo, ni najbolj optimalna kadrovska rešitev. Razvijalec v vlogi inženirja ni vedno optimalna kadrovska rešitev, ampak tukaj gre za to, da ima razvijalec, ki se ukvarja z Opsom, malo večjo željo po avtomatizaciji, ima malo več znanja in veščin, da lahko to implementira. avtomatizacija. In v skladu s tem zmanjšamo ne le čas za nekatere specifične operacije, ne samo rutino, ampak tudi tako pomembne poslovne parametre, kot je MTTR (Mean Time To Recovery, čas okrevanja). Tako, in tudi o tem bomo govorili malo kasneje, prihranimo denar za organizacijo.
Zdaj pa se pogovorimo o merilih za delo SRE. In najprej o zanesljivosti. V majhnih podjetjih in startupih se velikokrat zgodi, da ljudje domnevajo, da če je storitev dobro napisana, če je izdelek dobro in pravilno napisan, bo deloval, ne bo se pokvaril. To je to, pišemo dobro kodo, tako da ni ničesar za pokvariti. Koda je zelo preprosta, ničesar ni za zlomiti. To so približno isti ljudje, ki pravijo, da ne potrebujemo testov, ker, poglejte, to so tri metode VPI, zakaj bi se trudili?
Vse to je seveda narobe. In ti ljudje so zaradi tovrstne kode v praksi zelo pogosto prizadeti, ker se stvari pokvarijo. Stvari se včasih zlomijo na najbolj nepredvidljive načine. Včasih ljudje rečejo ne, to se ne bo nikoli zgodilo. In še vedno se dogaja. Zgodi se precej pogosto. In zato si nihče nikoli ne prizadeva za 100% razpoložljivost, ker 100% razpoložljivost nikoli ne pride. To je norma. In zato vedno govorimo o devetih, ko govorimo o razpoložljivosti storitev. 2 devetki, 3 devetki, 4 devetki, 5 devetki. Če to prevedemo v čas izpada, potem je na primer 5 devetk nekaj več kot 5 minut izpada na leto, 2 devetki pa 3,5 dni izpada.
Očitno pa je, da na neki točki pride do zmanjšanja POI in donosnosti naložbe. Prehod z dveh devetk na tri devetke pomeni zmanjšanje izpadov za več kot 3 dni. Prehod s štirih devet na pet skrajša čas izpadov za 47 minut na leto. In izkazalo se je, da to morda ni kritično za poslovanje. In na splošno zahtevana zanesljivost ni tehnično vprašanje, najprej je poslovno vprašanje, je vprašanje izdelka. Kakšna stopnja nedelovanja je sprejemljiva za uporabnike produkta, kaj pričakujejo, koliko plačajo, na primer, koliko denarja izgubijo, koliko denarja izgubi sistem.
Pomembno vprašanje je, kakšna je zanesljivost preostalih komponent. Ker razlika med 4 in 5 devetkami ne bo vidna na pametnem telefonu z 2 devetkama zanesljivosti. Grobo rečeno, če se vam na pametnem telefonu v servisu kaj pokvari 10-krat na leto, se je najverjetneje 8-krat okvara zgodila na strani OS. Uporabnik je tega navajen in temu ne bo posvetil niti enkrat več na leto. Treba je primerjati ceno povečanja zanesljivosti in povečanja dobička.
Samo v knjigi o SRE je dober primer povečanja na 4 devetke s 3 devetk. Izkazalo se je, da je povečanje razpoložljivosti nekaj manj kot 0,1%. In če je prihodek storitve 1 milijon dolarjev na leto, potem je povečanje prihodkov 900 dolarjev. Če nas povečanje razpoložljivosti za devet stane manj kot 900 USD na leto, je povečanje finančno smiselno. Če stane več kot 900 dolarjev na leto, nima več smisla, saj povečanje prihodkov enostavno ne nadomesti stroškov dela in virov. In 3 devetke nam bodo dovolj.
To je seveda poenostavljen primer, kjer so vse zahteve enake. In s 3 devetk na 4 devetke je zelo enostavno iti, hkrati pa je na primer prehod z 2 devetk na 3 že prihranek 9 tisoč dolarjev, lahko je finančno smiselno. Seveda je v resnici neregistracija zahteve hujša kot neprikaz strani, zahteve imajo različne uteži. Lahko imajo s poslovnega vidika povsem drugačna merila, a vseeno je to praviloma, če ne govorimo o kakšnih posebnih storitvah, dokaj zanesljiv približek.
Prejeli smo vprašanje, ali je SRE eden od koordinatorjev pri izbiri arhitekturne rešitve storitve. To je sprejemljivo z vidika integracije v obstoječo infrastrukturo, da ne pride do izgube njene stabilnosti. Da, SRE na enak način vplivajo na zahteve po vleki, potrditve, sprostitve; vplivajo na arhitekturo, implementacijo novih storitev, mikrostoritev in implementacijo novih rešitev. Zakaj sem prej rekel, da potrebujete izkušnje, potrebujete kvalifikacije. Pravzaprav je SRE eden od blokirajočih glasov v kateri koli arhitekturni in programski rešitvi. Skladno s tem mora SRE kot inženir najprej ne le razumeti, ampak tudi razumeti, kako bodo nekatere posebne odločitve vplivale na zanesljivost, stabilnost, in razumeti, kako je to povezano s poslovnimi potrebami in s katerega vidika je to lahko dopustno, in s katerim ni.
Zato je zdaj čas za pogovor o kriterijih zanesljivosti, ki so v SRE tradicionalno opredeljeni kot SLA (Service Level Agreement). Najverjetneje znan izraz. SLI (indikator ravni storitve). SLO (Service Level Objective). Sporazum o ravni storitev je morda pomemben izraz, še posebej, če ste delali z omrežji, ponudniki in gostovanjem. To je splošni dogovor, ki opisuje uspešnost vaše celotne storitve, kazni, nekatere kazni za napake, meritve, merila. In SLI je sama metrika dostopnosti. To je, kaj je lahko SLI: odzivni čas storitve, število napak v odstotkih. To bi lahko bila pasovna širina, če govorimo o nekakšnem gostovanju datotek. Če govorimo o algoritmih za prepoznavanje, je indikator lahko celo na primer pravilnost odgovora. SLO (Service Level Objective) je kombinacija indikatorja SLI, njegove vrednosti in obdobja.
Recimo, da bi SLA lahko bil tak. Storitev je na voljo 99,95% časa skozi vse leto. Ali pa bo 99 kritičnih zahtev za tehnično podporo zaprtih v 3 urah na četrtletje. Ali pa bo na 85 % poizvedb vsak mesec odgovorjeno v 1,5 sekunde. To pomeni, da postopoma spoznavamo, da so napake in neuspehi povsem običajni. To je sprejemljiva situacija, to načrtujemo, do neke mere celo računamo. To pomeni, da SRE gradi sisteme, ki lahko delajo napake, ki se morajo normalno odzivati na napake in jih morajo upoštevati. In če je možno, naj napake obravnavajo tako, da jih uporabnik ne opazi, ali pa jih opazi, vendar obstaja neka rešitev, da se vse skupaj ne razpade v celoti.
Na primer, če naložite videoposnetek v YouTube in ga YouTube ne more takoj pretvoriti, če je videoposnetek prevelik, če format ni optimalen, potem zahteva seveda ne bo padla s časovno omejitvijo, YouTube ne bo prikazal 502 napaka, bo YouTube rekel: »Ustvarili smo vse, vaš video je v obdelavi. Pripravljen bo v približno 10 minutah.” To je načelo graciozne degradacije, ki je znano na primer iz front-end razvoja, če ste to že kdaj počeli.
Naslednja izraza, o katerih bomo govorili in ki so zelo pomembni za delo z zanesljivostjo, z napakami, s pričakovanji, sta MTBF in MTTR. MTBF je srednji čas med napakami. MTTR Mean Time To Recovery, povprečni čas do okrevanja. Se pravi, koliko časa je minilo od trenutka, ko je bila napaka zaznana, od trenutka, ko se je pojavila napaka, do trenutka, ko je bila storitev ponovno vzpostavljena v popolnoma normalno delovanje. MTBF se v glavnem popravlja z delom na kakovosti kode. To je dejstvo, da SRE lahko rečejo "ne". In celotna ekipa mora razumeti, da ko SRE reče "ne", tega ne reče zato, ker je škodljiv, ne zato, ker je slab, ampak ker bodo drugače vsi trpeli.
Še enkrat, obstaja veliko člankov, veliko metod, veliko načinov, tudi v sami knjigi, na katero se tako pogosto sklicujem, kako zagotoviti, da drugi razvijalci ne začnejo sovražiti SRE. Po drugi strani pa gre pri MTTR za delo na vašem SLO (Service Level Objective). In to je predvsem avtomatizacija. Ker je recimo naša SLO uptime 4 devetke na kvartal. To pomeni, da lahko v 3 mesecih omogočimo 13 minut izpada. In izkazalo se je, da naš MTTR nikakor ne more biti daljši od 13 minut. Če si vzamemo 13 minut časa, da se odzovemo na vsaj 1 izpad, to pomeni, da smo že izčrpali celoten proračun za četrtletje. Kršimo SLO. 13 minut za reakcijo in odpravo napake je za stroj veliko, za človeka pa zelo malo. Ker do takrat, ko človek prejme opozorilo, ko reagira, ko ugotovi napako, je že nekaj minut. Dokler človek razume, kako to popraviti, kaj točno popraviti, kaj narediti, bo trajalo še nekaj minut. In dejansko, tudi če morate samo znova zagnati strežnik, kot se izkaže, ali dvigniti novo vozlišče, potem MTTR ročno traja približno 7-8 minut. Pri avtomatizaciji procesa MTTR zelo pogosto doseže sekundo, včasih milisekundo. Google običajno govori o milisekundah, v resnici pa stvari seveda niso tako dobre.
Idealno bi bilo, če bi SRE skoraj popolnoma avtomatiziral svoje delo, ker to neposredno vpliva na MTTR, njegovo metriko, SLO celotne storitve in s tem na poslovni dobiček. Če je čas prekoračen, nas vprašajo, ali je za to kriv SRE. Na srečo krivde ne pripisujejo nikomur. In to je ločena kultura, ki se imenuje postmortem brez balzama, o kateri danes ne bomo govorili, ampak jo bomo analizirali na Slurmu. To je zelo zanimiva tema, o kateri se da veliko govoriti. Grobo rečeno, če je dodeljeni čas na četrtletje prekoračen, potem so vsi malo krivi, kar pomeni, da kriviti vse ni produktivno, namesto tega morda ne krivimo nikogar, ampak popravimo situacijo in delamo s tem, kar imamo. Po mojih izkušnjah je ta pristop večini ekip nekoliko tuj, zlasti v Rusiji, vendar je smiseln in deluje zelo dobro. Zato bom na koncu priporočil članke in literaturo, ki jo lahko preberete na to temo. Ali pa pridite v Slurm SRE.
Naj pojasnim. Če je SLO čas za trimesečje presežen, če zastoj ni bil 13 minut, ampak 15, kdo je lahko za to kriv? Seveda je SRE morda kriv, ker je očitno izvedel kakšno napačno zavezo ali uvedbo. Morda je za to kriv skrbnik podatkovnega centra, ker je morda izvedel kakšno nenačrtovano vzdrževanje. Če je za to kriv skrbnik podatkovnega centra, potem je kriv tudi človek iz Opsa, ki pri dogovoru o SLO ni izračunal vzdrževanja. Za to je kriv vodja, tehnični direktor ali nekdo, ki je podpisal pogodbo o podatkovnem centru in ni bil pozoren na to, da SLA podatkovnega centra ni zasnovan za zahtevane izpade. Skladno s tem so vsi po malem krivi za to stanje. In to pomeni, da za to situacijo nima smisla kriviti nikogar posebej. Je pa seveda treba popraviti. Zato obsmrtnice obstajajo. In če berete na primer GitHub postmortems, in to je vedno zelo zanimiva, majhna in nepričakovana zgodba v vsakem konkretnem primeru, lahko zamenjate, da nihče nikoli ne reče, da je kriva ta oseba. Krivda se vedno pripisuje določenim pomanjkljivim procesom.
Preidimo na naslednje vprašanje. Avtomatizacija. Običajno se, ko govorim o avtomatizaciji v drugih kontekstih, zelo pogosto sklicujem na tabelo, ki govori o tem, kako dolgo lahko delate na avtomatizaciji opravila, da ne bi vzeli več časa za avtomatizacijo, kot ga običajno prihranite. Tukaj je ulov. Ulov je v tem, da ko SRE avtomatizirajo nalogo, ne prihranijo le časa, ampak tudi denar, ker avtomatizacija neposredno vpliva na MTTR. Rešujejo tako rekoč moralo zaposlenih in razvijalcev, ki je prav tako izčrpen vir. Zmanjšajo rutino. In vse to pozitivno vpliva na delo in posledično na poslovanje, četudi se zdi, da avtomatizacija z vidika stroškov časa ni smiselna.
Pravzaprav se skoraj vedno zgodi in zelo malo je primerov, ko se ne splača nekaj avtomatizirati v vlogi SRE. Nato bomo govorili o tem, čemur pravimo proračun za napake, proračun za napake. Pravzaprav se izkaže, da če ti gre bistveno bolje od SLO, ki si ga zadaš, tudi to ni zelo dobro. To je precej slabo, saj SLO ne deluje samo kot spodnja meja, ampak tudi kot približna zgornja meja. Ko si postaviš SLO 99% razpoložljivosti, dejansko pa imaš 99,99%, se izkaže, da imaš nekaj prostora za eksperimentiranje, kar pa ne bo prav nič škodilo poslu, saj si to vse skupaj določil sam in si imejte ta prostor, ne uporabljajte ga. Imate proračun za napake, ki v vašem primeru ni porabljen.
Kaj počnemo z njim? Uporabljamo ga dobesedno za vse. Za testiranje v proizvodnih pogojih, za uvajanje novih funkcij, ki lahko vplivajo na zmogljivost, za izdaje, za vzdrževanje, za načrtovane izpade. Velja tudi obratno pravilo: če je proračun izčrpan, ne moremo izdati ničesar novega, ker sicer presežemo SLO. Proračun je že izčrpan, nekaj smo sprostili, če to negativno vpliva na uspešnost, se pravi, če ni nek popravek, ki sam po sebi direktno poveča SLO, potem gremo čez proračun in to je slaba situacija. , zahteva analizo, postmortem in po možnosti nekaj popravkov postopka.
To pomeni, da se izkaže, da če sama storitev ne deluje dobro in se SLO porabi in proračun ne porabi za poskuse, ne za kakršne koli izdaje, ampak zase, potem namesto nekaj zanimivih popravkov, namesto zanimivih funkcije, namesto zanimivih izdaj. Namesto kreativnega dela boste morali delati neumne popravke, da bi spravili proračun nazaj v red, ali urejati SLO, in tudi to je proces, ki se ne bi smel dogajati prepogosto.
Zato se izkaže, da so v situaciji, ko imamo več proračuna za napake, zainteresirani vsi: tako SRE kot razvijalci. Za razvijalce velik proračun za napake pomeni, da se lahko ukvarjajo z izdajami, testi in poskusi. Za SRE proračun za napake in vključitev v ta proračun pomeni, da dejansko dobro opravljajo svoje delo. In to vpliva na motivacijo za nekakšno skupno delo. Če kot razvijalci poslušate svoje SRE, boste imeli več prostora za dobro delo in veliko manj opravil.
Izkazalo se je, da so eksperimenti v proizvodnji dokaj pomemben in skoraj sestavni del SRE v velikih timih. Običajno gre za ime inženiring kaosa, ki prihaja od ekipe pri Netflixu, ki je izdala pripomoček, imenovan Chaos Monkey.
Chaos Monkey se poveže s cevovodom CI/CD in naključno zruši strežnik v produkciji. Še enkrat, v strukturi SRE pravimo, da zrušeni strežnik sam po sebi ni slab, je pričakovan. In če je vključeno v proračun, je sprejemljivo in ne škoduje poslu. Seveda ima Netflix dovolj redundantnih strežnikov, dovolj replikacij, da je vse to mogoče popraviti, ne da bi uporabnik kot celota sploh opazil, in zagotovo nihče ne zapusti enega strežnika za kakršen koli proračun.
Netflix je nekoč imel cel nabor takšnih pripomočkov, eden od njih, Chaos Gorilla, popolnoma onemogoči eno od območij razpoložljivosti v Amazonu. In takšne stvari dobro pomagajo prepoznati, prvič, skrite odvisnosti, ko ni povsem jasno, kaj na kaj vpliva, kaj je odvisno od česa. In to, če delate z mikrostoritvijo in dokumentacija ni povsem popolna, se vam to morda pozna. In spet, to pomaga ujeti napake v kodi, ki jih ne morete ujeti med uprizoritvijo, ker nobena uprizoritev ni natančna simulacija, ker je lestvica obremenitve drugačna, vzorec obremenitve je drugačen, oprema je tudi večina verjetno, drugo. Konične obremenitve so lahko tudi nepričakovane in nepredvidljive. In takšno testiranje, ki spet ne presega proračuna, zelo dobro pomaga pri lovljenju napak v infrastrukturi, ki jih uprizarjanje, samodejni testi in CI/CD cevovodi ne bodo nikoli ujeli. In dokler je vse to vključeno v vaš proračun, ni pomembno, da je vaša storitev tam padla, čeprav se zdi zelo strašljivo, strežnik se je zrušil, kakšna nočna mora. Ne, to je normalno, to je dobro, pomaga pri odkrivanju napak. Če imate proračun, ga lahko porabite.
Vprašanje: katero literaturo lahko priporočim? Seznam je na koncu. Literature je veliko, priporočam več poročil. Kako deluje in ali SRE deluje v podjetjih brez lastnega programskega izdelka ali z minimalnim razvojem. Na primer v podjetju, kjer glavna dejavnost ni programska oprema. V podjetju, kjer glavna dejavnost ni programska oprema, SRE deluje povsem enako kot kjerkoli drugje, saj morate tudi v podjetju uporabljati, tudi če ne razvijate, programske izdelke, uvajati morate posodobitve, morate spremeniti infrastrukturo, morate rasti, morate se razširiti. SRE pa pomagajo prepoznati in predvideti morebitne težave v teh procesih ter jih nadzorovati, ko se začne rast in se poslovne potrebe spremenijo. Ker absolutno ni nujno, da se ukvarjaš z razvojem programske opreme, da imaš SRE, če imaš vsaj več strežnikov in pričakuješ vsaj neko rast.
Enako velja za majhne projekte, majhne organizacije, saj imajo velika podjetja proračun in prostor za eksperimentiranje. Toda hkrati je vse te plodove poskusov mogoče uporabiti kjer koli, torej SRE so se seveda pojavili v Googlu, Netflixu in Dropboxu. Hkrati pa mala podjetja in startupi že lahko berejo zgoščeno gradivo, berejo knjige in gledajo poročila. Začnejo pogosteje poslušati o tem, pogledajo konkretne primere, pomislim, v redu, to je res lahko koristno, tudi to potrebujemo, kul.
To pomeni, da je bilo vse glavno delo na standardizaciji teh procesov že opravljeno za vas. Vse kar morate storiti je, da definirate vlogo SRE konkretno v vašem podjetju in začnete dejansko izvajati vse te prakse, ki so bile spet že opisane. Se pravi, od uporabnih načel za mala podjetja je to vedno definicija SLA, SLI, SLO. Če se ne ukvarjate s programsko opremo, bodo to notranji SLA-ji in notranji SLO-ji, notranji proračun za napake. To skoraj vedno vodi do kakšnih zanimivih razprav znotraj ekipe in znotraj posla, ker se lahko izkaže, da porabiš veliko več, kot je potrebno za infrastrukturo, za nekakšno organizacijo idealnih procesov, idealen cevovod. In teh 4 devetk, ki jih imate v IT oddelku, jih zdaj res ne potrebujete. Toda hkrati je bilo mogoče porabiti čas, porabiti proračun za napake za nekaj drugega.
Zato sta spremljanje in organizacija spremljanja koristna za podjetja katere koli velikosti. In na splošno je ta način razmišljanja, kjer so napake nekaj sprejemljivega, kjer je proračun, kjer obstajajo cilji, spet uporaben za podjetje katere koli velikosti, začenši s startupom s tremi osebami.
Zadnja od tehničnih nians, o katerih lahko govorimo, je spremljanje. Kajti če govorimo o SLA, SLI, SLO, brez nadzora ne moremo razumeti, ali se uvrščamo v proračun, ali izpolnjujemo svoje cilje in kako vplivamo na končni SLA. Večkrat sem opazil, da spremljanje poteka na naslednji način: obstaja neka vrednost, na primer čas zahteve do strežnika, povprečni čas ali število zahtev do baze podatkov. Ima standard, ki ga je določil inženir. Če metrika odstopa od norme, se pošlje e-poštno sporočilo. Vse to je praviloma popolnoma neuporabno, ker vodi do takšne prenasičenosti opozoril, prenasičenosti nadzornih sporočil, ko jih mora človek najprej vsakič interpretirati, torej ugotoviti, ali metrična vrednost pomeni potrebo po nekakšna akcija. In drugič, preprosto neha opaziti vseh teh opozoril, ko od njega v bistvu ni potrebno nobeno dejanje. To pomeni, da je dobro pravilo spremljanja in prvo pravilo pri izvajanju SRE, da mora obvestilo prispeti le, ko je potrebno dejanje.
V standardnem primeru obstajajo 3 ravni dogodkov. Obstajajo opozorila, obstajajo vstopnice, obstajajo dnevniki. Opozorila so vse, kar od vas zahteva takojšnje ukrepanje. To pomeni, da je vse pokvarjeno, to je treba takoj popraviti. Vstopnice so nekaj, kar zahteva čakajoče ukrepanje. Da, nekaj morate narediti, nekaj morate narediti ročno, avtomatizacija ni uspela, vendar vam tega ni treba storiti v naslednjih nekaj minutah. Dnevniki so vse, kar ne zahteva ukrepanja, in na splošno, če gredo stvari dobro, jih nihče ne bo nikoli prebral. Dnevnike bo treba prebrati šele takrat, ko se bo za nazaj izkazalo, da je bilo nekaj časa pokvarjeno, za kar nismo vedeli. Ali pa je treba narediti kakšno preiskavo. Toda na splošno gre vse, kar ne zahteva nobenega ukrepa, v dnevnike.
Kot stranski učinek vsega tega, če smo ugotovili, kateri dogodki zahtevajo dejanja, in smo dobro opisali, kakšna bi morala biti ta dejanja, to pomeni, da je dejanje mogoče avtomatizirati. Se pravi, kaj se zgodi. Prihajamo iz opozorila. Gremo v akcijo. Pojdimo na opis tega dejanja. In potem gremo proti avtomatizaciji. To pomeni, da se vsaka avtomatizacija začne z reakcijo na dogodek.
Od spremljanja preidemo na izraz, imenovan Opazljivost. Zadnjih nekaj let je bilo tudi malo pompa okoli te besede. In malo ljudi razume, kaj to pomeni izven konteksta. Toda glavna točka je, da je opazljivost metrika preglednosti sistema. Če je šlo kaj narobe, kako hitro lahko ugotovite, kaj točno je šlo narobe in v kakšnem stanju je bil sistem v tistem trenutku. Z vidika kode: katera funkcija je odpovedala, katera storitev je odpovedala. Kakšno je bilo stanje na primer notranjih spremenljivk, konfiguracije. Z vidika infrastrukture je to v katerem območju razpoložljivosti je prišlo do okvare, in če imate nekakšen Kubernetes, potem v katerem podu je prišlo do okvare, kakšno je bilo stanje poda. V skladu s tem je opazljivost neposredno povezana z MTTR. Večja kot je Opazljivost storitve, lažje je prepoznati napako, lažje je odpraviti napako, lažje je avtomatizirati napako, nižji je MTTR.
Če gremo spet k majhnim podjetjem, se zelo pogosto sprašujejo, že zdaj, kaj narediti z velikostjo ekipe in ali je treba v majhni ekipi zaposliti ločenega SRE. O tem sem že govoril malo prej. V prvih fazah razvoja startupa ali na primer ekipe to sploh ni potrebno, saj lahko SRE postane prehodna vloga. In to bo malo poživilo ekipo, saj je vsaj nekaj pestrosti. In poleg tega bo ljudi pripravil na dejstvo, da se bodo z njihovo rastjo na splošno odgovornosti SRE zelo spremenile. Če človeka zaposliš, potem ima seveda neka pričakovanja. In ta pričakovanja se sčasoma ne bodo spremenila, zahteve pa se bodo zelo spremenile. Zato je najem SRE v zgodnjih fazah precej težaven. Veliko lažje je vzgojiti svojega. Vendar je vredno razmisliti.
Edina izjema so verjetno zelo stroge in natančno določene zahteve glede višine. Se pravi, v primeru startupa je to lahko nekakšen pritisk investitorjev, nekakšna napoved rasti večkrat naenkrat. Potem je najem SRE na splošno upravičen, ker je lahko upravičen. Imamo zahteve po rasti, potrebujemo osebo, ki bo odgovorna za to, da se s tako rastjo nič ne zalomi.
Še eno vprašanje. Kaj storiti, ko razvijalci večkrat izrežejo funkcijo, ki prestane teste, vendar pokvari izdelek, naloži bazo podatkov, pokvari druge funkcije, kakšen postopek implementirati. V skladu s tem se v tem primeru uvede proračun za napake. In nekatere storitve, nekatere funkcije so preizkušene takoj v proizvodnji. To je lahko kanarček, ko le majhno število uporabnikov, vendar že v produkciji, uvaja funkcijo, vendar s pričakovanjem, da če se nekaj pokvari, na primer pri pol odstotka vseh uporabnikov, bo še vedno ustrezalo znotraj proračun za napake. V skladu s tem, da, prišlo bo do napake, pri nekaterih uporabnikih se bo vse zlomilo, vendar smo že rekli, da je to normalno.
Bilo je vprašanje o orodjih SRE. Se pravi, ali obstaja nekaj posebnega, kar bi SRE uporabili, česar drugi ne bi? Pravzaprav obstaja nekaj zelo specializiranih pripomočkov, obstaja nekaj programske opreme, ki na primer simulira obremenitve ali izvaja kanarsko A/B testiranje. Toda v bistvu je orodje SRE tisto, kar vaši razvijalci že uporabljajo. Ker SRE neposredno sodeluje z razvojno ekipo. In če imate različna orodja, se izkaže, da je za sinhronizacijo potreben čas. Še posebej, če SRE delajo v velikih timih, v velikih podjetjih, kjer je lahko več timov, bo standardizacija na ravni podjetja tukaj zelo koristna, kajti če 50 timov uporablja 50 različnih pripomočkov, to pomeni, da jih mora SRE poznati vse. In to se seveda ne bo nikoli zgodilo. In kakovost dela, kakovost nadzora vsaj nekaterih ekip se bo bistveno zmanjšala.
Naš webinar se počasi bliža koncu. Uspelo mi je povedati nekaj osnovnih stvari. Seveda o SRE ni mogoče ničesar povedati in razumeti v eni uri. Upam pa, da mi je uspelo posredovati ta način razmišljanja, glavne ključne točke. In potem, če vas zanima, se lahko poglobite v temo, preučite sami in pogledate, kako to izvajajo drugi ljudje, v drugih podjetjih. In zato v začetku februarja pridite k nam na Slurm SRE.
Slurm SRE je tridnevni intenzivni tečaj, ki bo pokrival približno to, o čemer zdaj govorim, vendar z veliko večjo globino, z realnimi primeri, s prakso, celoten intenziv je namenjen praktičnemu delu. Ljudje bodo razdeljeni v ekipe. Vsi boste delali na resničnih primerih. Temu primerno imamo inštruktorja iz Booking.com Ivana Kruglova in Bena Tylerja. Imamo čudovitega Evgeniya Varabbasa iz Googla iz San Francisca. In nekaj vam bom tudi povedal. Zato nas vsekakor obiščite.
Torej, seznam referenc. Obstajajo povezave na SRE. na isto knjigo, oziroma na 2 knjigi o SRE, ki ju je napisal Google. Še en , kjer so izrazi in njihova uporaba nekoliko podrobneje razloženi. Naslednja 3 so poročila o SRE v različnih podjetjih. prvi - , to je osrednja beseda Bena Trainerja iz Googla. drugi - . Pri tretjem gre spet za . Četrto poročilo iz , ki ima samo 5 ključnih SRE zaposlenih v 190 državah. Zelo zanimivo je pogledati vse to, kajti tako kot DevOps pomeni zelo različne stvari za različna podjetja in celo različne ekipe, ima SRE zelo različne odgovornosti, tudi v podjetjih podobne velikosti.
Še 2 povezavi o principih inženiringa kaosa: , . In na koncu so 3 seznami iz serije Awesome Lists o približno in približno . Seznam na SRE je neverjetno ogromen, ni vam treba iti skozi vsega, tam je približno 200 člankov. Toplo priporočam članke o načrtovanju zmogljivosti in neoporečnem postmortemu.
Zanimiv članek:
Hvala, ker ste me poslušali ves ta čas. Upam, da si se kaj naučil. Upam, da imate dovolj gradiva, da se naučite še več. In se vidimo kasneje. Upam, da februarja.
Webinar je vodil Eduard Medvedev.
PS: za tiste, ki radi berete, je Eduard posredoval seznam referenc. Tisti, ki ga raje razumete v praksi, vabljeni na .
Vir: www.habr.com