Webinaro garsas prastas, todėl padarėme stenogramą.
Mano vardas Medvedevas Eduardas. Šiandien kalbėsiu apie tai, kas yra SRE, kaip atsirado SRE, kokie yra SRE inžinierių darbo kriterijai, šiek tiek apie patikimumo kriterijus, šiek tiek apie jo stebėjimą. Peržiūrėsime viską, nes per valandą daug nepasakysi, bet pateiksiu medžiagą papildomai peržiūrai, o mes visi jūsų laukiame . sausio pabaigoje Maskvoje.
Pirmiausia pakalbėkime apie tai, kas yra SRE – Site Reliability Engineering. Ir kaip tai atsirado kaip atskira pozicija, kaip atskira kryptis. Viskas prasidėjo nuo to, kad tradiciniuose vystymosi sluoksniuose Dev ir Ops yra dvi visiškai skirtingos komandos, dažniausiai turinčios du visiškai skirtingus tikslus. Kūrėjų komandos tikslas – įdiegti naujas funkcijas, kurios atitiktų verslo poreikius. „Ops“ komandos tikslas – užtikrinti, kad viskas veiktų ir niekas nesugestų. Akivaizdu, kad šie tikslai tiesiogiai prieštarauja vienas kitam: kad viskas veiktų ir niekas nesugestų, verčiau kuo mažiau diegti naujų funkcijų. Dėl šios priežasties kyla daug vidinių konfliktų, kuriuos dabar bando išspręsti DevOps metodika.
Problema ta, kad neturime aiškaus „DevOps“ apibrėžimo ir aiškaus „DevOps“ įgyvendinimo. Prieš 2 metus kalbėjau konferencijoje Jekaterinburge, o iki šiol „DevOps“ skyrius prasidėjo pranešimu „Kas yra „DevOps“. 2017-aisiais devopsui jau beveik 10 metų, bet vis dar ginčijamės, kas tai yra. Ir tai yra labai keista situacija, kurią Google bandė išspręsti prieš keletą metų.
2016 m. „Google“ išleido knygą „Svetainės patikimumo inžinerija“. Ir iš tikrųjų būtent nuo šios knygos prasidėjo SRE judėjimas. SRE yra konkreti galimybė įdiegti DevOps paradigmą konkrečioje įmonėje. SRE inžinieriai užsibrėžė tikslą užtikrinti patikimą sistemų veikimą. Jie daugiausia paimti iš kūrėjų, kartais iš administratorių, turinčių stiprią kūrimo patirtį. Ir jie daro tai, ką darydavo sistemų administratoriai, tačiau stiprus kūrimo išsilavinimas ir sistemos išmanymas kodiniu požiūriu lemia tai, kad šie žmonės nėra linkę į įprastą administracinį darbą, o yra linkę į automatizavimą.
Pasirodo, DevOps paradigma SRE komandose įgyvendinama tuo, kad yra SRE inžinieriai, kurie sprendžia struktūrines problemas. Štai tas pats Dev ir Ops ryšys, apie kurį žmonės kalba jau 8 metus. SRE vaidmuo panašus į architekto, nes naujokai netampa SRE. Karjeros pradžioje žmonės dar neturi jokios patirties ir neturi reikiamų žinių. Kadangi SRE reikia labai sudėtingų žinių apie tai, kas ir kada tiksliai gali suklysti. Todėl čia reikia tam tikros patirties, kaip taisyklė, tiek įmonės viduje, tiek už jos ribų.
Jie klausia, ar bus aprašytas skirtumas tarp SRE ir devops. Ji ką tik buvo aprašyta. Galima kalbėti apie SRE vietą organizacijoje. Skirtingai nuo klasikinio „DevOps“ metodo, kai „Ops“ vis dar yra atskiras skyrius, SRE yra kūrimo komandos dalis. Jie dalyvauja gaminių kūrime. Yra netgi toks požiūris, kai SRE yra vaidmuo, kuris perduodamas iš vieno kūrėjo kitam. Jie dalyvauja kodų peržiūrose taip pat, kaip, pavyzdžiui, UX dizaineriai, patys kūrėjai, o kartais ir produktų vadybininkai. SRE veikia tame pačiame lygyje. Mums reikia jų patvirtinimo, mums reikia jų peržiūros, kad kiekvienam diegimui SRE pasakytų: „Gerai, šis diegimas, šis produktas neturės neigiamos įtakos patikimumui. Ir jei taip, tai bus tam tikrose priimtinose ribose. Pakalbėsime ir apie tai.
Atitinkamai, SRE turi veto teisę keisti kodą. Ir apskritai tai taip pat sukelia nedidelį konfliktą, jei SRE įgyvendinamas neteisingai. Toje pačioje knygoje apie svetainių patikimumo inžineriją daug dalių, net daugiau nei viena, pasakoja, kaip išvengti šių konfliktų.
Žmonės klausia, kaip SRE susijęs su informacijos saugumu. SRE nėra tiesiogiai susijęs su informacijos saugumu. Dažniausiai didelėse įmonėse tai atlieka pavieniai žmonės, testuotojai ir analitikai. Tačiau SRE taip pat sąveikauja su jais ta prasme, kad kai kurios operacijos, kai kurie įsipareigojimai, kai kurie diegimai, turintys įtakos saugumui, taip pat gali turėti įtakos produkto prieinamumui. Todėl SRE apskritai bendrauja su bet kokiomis komandomis, įskaitant apsaugos komandas, įskaitant analitikus. Todėl SRE daugiausia prireikia bandant įdiegti „DevOps“, tačiau kūrėjų našta tampa per didelė. Tai yra, pati kūrimo komanda nebegali susidoroti su tuo, kad dabar jie taip pat turi būti atsakingi už „Ops“. Ir atsiranda atskiras vaidmuo. Šis vaidmuo numatytas biudžete. Kartais šis vaidmuo įkomponuojamas į komandos dydį, atsiranda atskiras žmogus, kartais juo tampa vienas iš kūrėjų. Taip komandoje atsiranda pirmasis SRE.
Sistemos sudėtingumas, kuriam įtakos turi SRE, sudėtingumas, turintis įtakos veikimo patikimumui, gali būti būtinas arba atsitiktinis. Būtinas sudėtingumas yra tada, kai produkto sudėtingumas padidėja tiek, kiek to reikalauja naujos produkto savybės. Atsitiktinis sudėtingumas yra tada, kai sistemos sudėtingumas didėja, tačiau produkto savybės ir verslo reikalavimai tam neturi tiesioginės įtakos. Pasirodo, arba kūrėjas kažkur suklydo, arba algoritmas nėra optimalus, arba įvedami kažkokie papildomi interesai, kurie be reikalo padidina produkto sudėtingumą. Geras SRE visada turėtų vengti šios situacijos. Tai reiškia, kad bet koks įsipareigojimas, bet koks diegimas, bet koks ištraukimo prašymas, kuris padidina sudėtingumą dėl atsitiktinių papildymų, turėtų būti užblokuotas.
Kyla klausimas, kodėl tiesiog nepasisamdžius inžinieriaus, daug žinių turinčio sistemos administratoriaus, kuris prisijungtų prie komandos. Kūrėjas, atliekantis inžinieriaus vaidmenį, mums sako, nėra pats optimaliausias personalo sprendimas. Kūrėjas, atliekantis inžinieriaus vaidmenį, ne visada yra optimalus personalo sprendimas, tačiau esmė ta, kad kūrėjas, užsiimantis Ops, turi šiek tiek daugiau automatizavimo troškimo, turi šiek tiek daugiau žinių ir įgūdžių, kad galėtų tai įgyvendinti. automatizavimas. Ir atitinkamai sumažiname ne tik kai kurių specifinių operacijų laiką, ne tik rutiną, bet ir tokius svarbius verslo parametrus kaip MTTR (Mean Time To Recovery, recovery time). Taigi, ir apie tai kalbėsime šiek tiek vėliau, taupome organizacijai skirtus pinigus.
Dabar pakalbėkime apie SRE darbo kriterijus. Ir pirmiausia apie patikimumą. Mažose įmonėse ir startuoliuose dažnai nutinka taip, kad žmonės mano, kad jei paslauga parašyta gerai, jei produktas parašytas gerai ir teisingai, jis veiks, nesuges. Tai tiek, parašome gerą kodą, todėl nėra ko laužyti. Kodas labai paprastas, nėra ko laužyti. Tai yra maždaug tie patys žmonės, kurie sako, kad mums nereikia testų, nes, žiūrėk, tai trys VPI metodai, kam vargti?
Visa tai, žinoma, neteisinga. Ir šie žmonės labai dažnai kenčia nuo tokio kodekso praktikoje, nes viskas sugenda. Kartais reikalai nutrūksta pačiais nenuspėjamiausiais būdais. Kartais žmonės sako ne, to niekada nebus. Ir vis tiek atsitinka. Pasitaiko gana dažnai. Ir štai kodėl niekas niekada nesiekia 100% pasiekiamumo, nes 100% pasiekiamumas niekada neįvyksta. Tai yra norma. Štai kodėl mes visada kalbame apie devynis, kai kalbame apie paslaugų prieinamumą. 2 devynetai, 3 devynetai, 4 devynetai, 5 devynetai. Jei tai paverstume prastovos laiku, tai, pavyzdžiui, 5 devyneri yra šiek tiek daugiau nei 5 minutės prastovos per metus, 2 devyneri – 3,5 dienos prastovos.
Tačiau akivaizdu, kad tam tikru momentu POI ir investicijų grąža mažėja. Perėjimas nuo dviejų iki trijų devynerių reiškia, kad prastovos laikas sutrumpėja daugiau nei 3 dienomis. Perėjus nuo keturių devynių iki penkių, prastovos laikas sutrumpėja 47 minutėmis per metus. Ir pasirodo, kad tai gali būti ne itin svarbu verslui. Ir apskritai reikalingas patikimumas nėra techninis klausimas, pirmiausia tai verslo, tai produkto klausimas. Kokio lygio prastovos yra priimtinos gaminio vartotojams, ko jie tikisi, kiek moka, pavyzdžiui, kiek pinigų praranda, kiek pinigų praranda sistema.
Svarbus klausimas – koks yra likusių komponentų patikimumas. Nes skirtumas tarp 4 ir 5 devynerių nebus matomas išmaniajame telefone su 2 patikimumo devynetais. Grubiai tariant, jei jūsų tarnyboje kas nors sugenda 10 kartų per metus išmaniajame telefone, greičiausiai 8 kartus gedimas įvyko OS pusėje. Vartotojas prie to yra pripratęs ir nekreips į tai dėmesio vieną kartą per metus. Reikia lyginti patikimumo didinimo ir pelno didinimo kainą.
Tiesiog knygoje apie SRE yra geras pavyzdys, kaip padidinti iki 4 devynių nuo 3 devynių. Pasirodo, prieinamumo padidėjimas yra šiek tiek mažesnis nei 0,1%. Ir jei paslaugos pajamos yra 1 milijonas USD per metus, tada pajamos padidėja 900 USD. Jei padidinti prieinamumą devyniais kainuoja mažiau nei 900 USD per metus, padidinimas yra finansiškai prasmingas. Jei tai kainuoja daugiau nei 900 USD per metus, tai nebėra prasmės, nes pajamų padidėjimas tiesiog nekompensuoja darbo sąnaudų ir išteklių sąnaudų. O mums užteks 3 devynerių.
Tai, žinoma, yra supaprastintas pavyzdys, kai visi prašymai yra vienodi. Ir nuo 3 devynerių iki 4 devynerių eiti gana lengva, tačiau tuo pačiu, pavyzdžiui, nuo 2 devynerių iki 3 jau sutaupote 9 tūkstančius dolerių, tai gali būti finansiškai prasminga. Natūralu, kad iš tikrųjų užklausos neužregistravimas yra blogiau nei puslapio neparodymas; užklausos turi skirtingą svorį. Jie gali turėti visiškai skirtingus kriterijus verslo požiūriu, bet vis tiek, kaip taisyklė, jei nekalbame apie kokias nors konkrečias paslaugas, tai yra gana patikimas apytikslis rodiklis.
Gavome klausimą, ar SRE yra vienas iš koordinatorių renkantis architektūrinį paslaugos sprendimą. Tai priimtina integruojant į esamą infrastruktūrą, kad nebūtų prarastas jos stabilumas. Taip, SRE vienodai įtakoja traukos užklausas, įsipareigojimus, išleidimus; jie daro įtaką architektūrai, naujų paslaugų, mikropaslaugų diegimui ir naujų sprendimų diegimui. Kodėl anksčiau sakiau, kad reikia patirties, reikia kvalifikacijos. Tiesą sakant, SRE yra vienas iš blokuojančių balsų bet kuriame architektūriniame ir programiniame sprendime. Atitinkamai, SRE, kaip inžinierius, pirmiausia turi ne tik suprasti, bet ir suprasti, kaip kai kurie konkretūs sprendimai paveiks patikimumą, stabilumą, ir suprasti, kaip tai susiję su verslo poreikiais ir kokiu požiūriu tai gali būti leistina, ir su kuria taip nėra.
Todėl dabar pats laikas pakalbėti apie patikimumo kriterijus, kurie SRE tradiciškai apibrėžiami kaip SLA (Service Level Agreement). Greičiausiai pažįstamas terminas. SLI (Service Level Indicator). SLO (Service Level Objective). Paslaugos lygio sutartis galbūt yra reikšmingas terminas, ypač jei dirbote su tinklais, teikėjais ir priegloba. Tai yra bendras susitarimas, kuriame aprašomas visos Jūsų paslaugos atlikimas, nuobaudos, kai kurios nuobaudos už klaidas, metrika, kriterijai. O SLI yra pati prieinamumo metrika. Tai yra, kas gali būti SLI: atsako laikas iš paslaugos, klaidų skaičius procentais. Tai gali būti pralaidumas, jei kalbame apie tam tikrą failų prieglobą. Jei kalbame apie atpažinimo algoritmus, rodiklis gali būti net, pavyzdžiui, atsakymo teisingumas. SLO (Service Level Objective) yra atitinkamai SLI rodiklio, jo reikšmės ir laikotarpio derinys.
Tarkime, SLA gali būti tokia. Paslauga teikiama 99,95 % laiko ištisus metus. Arba 99 kritinės techninės pagalbos bilietai bus uždaryti per 3 valandas per ketvirtį. Arba į 85% užklausų bus atsakyta per 1,5 sekundės kiekvieną mėnesį. Tai yra, pamažu pradedame suprasti, kad klaidos ir gedimai yra gana normalu. Tai priimtina situacija, mes ją planuojame, net kažkiek tikimės. Tai yra, SRE kuria sistemas, kurios gali padaryti klaidų, kurios turi normaliai reaguoti į klaidas ir turi į jas atsižvelgti. Ir jei įmanoma, jie turėtų elgtis su klaidomis taip, kad vartotojas jų arba nepastebėtų, arba pastebėtų, bet yra kažkoks sprendimas, kad viskas visiškai nesugriūtų.
Pavyzdžiui, jei įkeliate vaizdo įrašą į „YouTube“, o „YouTube“ negali iš karto jo konvertuoti, jei vaizdo įrašas per didelis, jei formatas nėra optimalus, užklausa natūraliai nepavyks su laiku, „YouTube“ nerodys 502 klaida, „YouTube“ pasakys: „Viską sukūrėme, jūsų vaizdo įrašas apdorojamas. Jis bus paruoštas maždaug po 10 minučių. Tai grakščios degradacijos principas, kuris žinomas, pavyzdžiui, iš priekinės dalies kūrimo, jei kada nors tai padarėte.
Kiti terminai, apie kuriuos kalbėsime, kurie yra labai svarbūs dirbant su patikimumu, su klaidomis, su lūkesčiais, yra MTBF ir MTTR. MTBF yra vidutinis laikas tarp gedimų. MTTR vidutinis atkūrimo laikas, vidutinis laikas iki atsigavimo. Tai yra, kiek laiko praėjo nuo klaidos aptikimo momento, nuo klaidos atsiradimo iki to momento, kai paslauga buvo atkurta iki visiškai normalaus veikimo. MTBF daugiausia koreguojamas dirbant su kodo kokybe. Tai yra tai, kad SRE gali pasakyti „ne“. Ir visa komanda turi suprasti, kad kai SRE sako „ne“, jis tai sako ne todėl, kad yra žalingas, ne todėl, kad jis blogas, o todėl, kad kitaip nukentės visi.
Vėlgi, yra daug straipsnių, daugybė metodų, daugybė būdų, net pačioje knygoje, kurią taip dažnai remiuosi, kaip užtikrinti, kad kiti kūrėjai nepradėtų nekęsti SRE. Kita vertus, MTTR yra darbas su jūsų SLO (paslaugos lygio tikslas). Ir tai dažniausiai yra automatika. Nes, pavyzdžiui, mūsų SLO veikimo laikas yra 4 devynios per ketvirtį. Tai reiškia, kad per 3 mėnesius galime leisti 13 minučių prastovos. Ir pasirodo, kad mūsų MTTR negali būti ilgesnis nei 13 minučių. Jei reaguodami į bent 13 prastovą skiriame 1 minučių, tai reiškia, kad jau išnaudojome visą ketvirčio biudžetą. Mes pažeidžiame SLO. 13 minučių reaguoti ir ištaisyti gedimą yra daug mašinai, bet labai mažai žmogui. Nes kol žmogus gauna įspėjimą, kol jis sureaguoja, kol išsiaiškina klaidą, jau praėjo kelios minutės. Kol žmogus supras, kaip taisyti, ką tiksliai taisyti, ką daryti, tai užtruks dar kelias minutes. Ir iš tikrųjų, net jei jums tiesiog reikia perkrauti serverį, kaip paaiškėja, arba pakelti naują mazgą, MTTR rankiniu būdu užtrunka apie 7–8 minutes. Automatizuojant procesą, MTTR labai dažnai pasiekia sekundę, kartais milisekundes. Google dažniausiai kalba apie milisekundes, bet realybėje, žinoma, viskas nėra taip gerai.
Idealiu atveju SRE turėtų beveik visiškai automatizuoti savo darbą, nes tai tiesiogiai veikia MTTR, jo metriką, visos paslaugos SLO ir atitinkamai verslo pelną. Jei laikas viršytas, mūsų klausiama, ar kaltė tenka SRE. Laimei, kaltė neverčiama niekam. Ir tai yra atskira kultūra, vadinama balmeless postmortem, apie kurią šiandien nekalbėsime, bet analizuosime Slurm. Tai labai įdomi tema, apie kurią galima daug kalbėti. Grubiai tariant, jei per ketvirtį viršijamas skirtas laikas, tai visi po truputį kalti, vadinasi, kaltinti visus nėra produktyvu, verčiau, galbūt, nieko nekaltinkime, o taisykime situaciją ir dirbkime su tuo, ką turime. Mano patirtis rodo, kad šis požiūris yra šiek tiek svetimas daugumai komandų, ypač Rusijoje, tačiau jis yra prasmingas ir veikia labai gerai. Todėl pabaigoje rekomenduosiu straipsnius ir literatūrą, kurią galite perskaityti šia tema. Arba atvykite į Slurm SRE.
Leisk man paaiškinti. Jei viršijamas SLO laikas per ketvirtį, jei prastovos buvo ne 13 minučių, o 15, kas gali būti dėl to kaltas? Žinoma, SRE gali būti kaltas, nes jis aiškiai padarė netinkamą įsipareigojimą ar diegimą. Dėl to gali būti kaltas duomenų centro administratorius, nes jis galėjo atlikti neplaninę priežiūrą. Jei dėl to kaltas duomenų centro administratorius, tai žmogus iš Ops taip pat kaltas, kad susitardamas dėl SLO neapskaičiavo išlaikymo. Dėl to kaltas vadovas, techninis direktorius ar kažkas, kas pasirašė duomenų centro sutartį ir neatkreipė dėmesio į tai, kad duomenų centro SLA nėra sukurta reikiamai prastovai. Atitinkamai, dėl šios situacijos šiek tiek kalti visi. Ir tai reiškia, kad nėra prasmės dėl šios situacijos kaltinti ką nors konkrečiai. Bet, žinoma, tai reikia pataisyti. Štai kodėl egzistuoja postmortems. Ir jei skaitote, pavyzdžiui, GitHub postmortems, ir tai visada yra labai įdomi, maža ir netikėta istorija kiekvienu konkrečiu atveju, galite pakeisti tai, kad niekas niekada nesako, kad kaltas buvo būtent šis asmuo. Visada kaltinami konkretūs nepakankami procesai.
Pereikime prie kito klausimo. Automatika. Aš paprastai, kai kalbu apie automatizavimą kituose kontekstuose, labai dažnai remiuosi lentele, kurioje nurodoma, kiek laiko galite dirbti automatizuodami užduotį, kad jos automatizavimas neužtruktų daugiau laiko, nei paprastai sutaupote. Yra laimikis. Svarbiausia, kad kai SRE automatizuoja užduotį, jie ne tik sutaupo laiko, bet ir pinigų, nes automatizavimas tiesiogiai veikia MTTR. Jie taupo, galima sakyti, darbuotojų ir kūrėjų moralę, kuri taip pat yra išsenkantis resursas. Jie mažina rutiną. Ir visa tai teigiamai atsiliepia darbui, o dėl to ir verslui, net jei atrodo, kad automatizavimas laiko sąnaudų prasme neturi prasmės.
Tiesą sakant, tai daro beveik visada, ir yra labai nedaug atvejų, kai neverta kažko automatizuoti atliekant SRE vaidmenį. Toliau kalbėsime apie tai, kas vadinama klaidų biudžetu, klaidų biudžetu. Tiesą sakant, paaiškėja, kad jei jums sekasi žymiai geriau nei sau nustatytas SLO, tai taip pat nėra labai gerai. Tai gana blogai, nes SLO veikia ne tik kaip apatinė, bet ir kaip apytikslė viršutinė riba. Kai nustatote sau 99% pasiekiamumo SLO, o iš tikrųjų turite 99,99%, paaiškėja, kad turite šiek tiek erdvės eksperimentams, o tai verslui visiškai nepakenks, nes jūs pats visa tai nustatėte kartu ir jūs turi šią erdvę, nenaudokite jos. Turite klaidų biudžetą, kuris jūsų atveju nėra išleistas.
Ką mes su juo darome? Mes naudojame jį tiesiogine prasme viskam. Testavimui gamybos sąlygomis, naujų funkcijų, kurios gali turėti įtakos našumui, diegimui, leidimams, priežiūrai, planuojamoms prastovoms. Galioja ir priešinga taisyklė: išnaudojus biudžetą negalime išleisti nieko naujo, nes kitaip viršysime SLO. Biudžetas jau išnaudotas, kažką išleidome, jei tai neigiamai veikia našumą, tai yra, jei tai nėra kažkoks pataisymas, kuris savaime tiesiogiai padidina SLO, tada mes viršijame biudžetą ir tai yra bloga situacija. , tai reikalauja analizės, pomirtinio ir galbūt tam tikro proceso korekcijos.
Tai yra, paaiškėja, kad jei pati paslauga neveikia gerai, o SLO išleidžiamas ir biudžetas išleidžiamas ne eksperimentams, ne kokiems nors leidimams, o pačiam, tada vietoj įdomių pataisymų, o ne įdomių funkcijų, o ne įdomių leidimų. Užuot dirbę kūrybinį darbą, turėsite atlikti kvailus pataisymus, kad susitvarkytumėte biudžetą, arba redaguoti SLO, o tai taip pat yra procesas, kuris neturėtų vykti per dažnai.
Todėl išeina, kad situacijoje, kai turime didesnį biudžetą klaidoms, domisi visi: ir SRE, ir kūrėjai. Kūrėjams didelis klaidų biudžetas reiškia, kad jie gali susidoroti su leidimais, bandymais ir eksperimentais. SRE atveju klaidų biudžetas ir įtraukimas į šį biudžetą reiškia, kad jie iš tikrųjų atlieka gerą darbą. Ir tai turi įtakos tam tikro bendro darbo motyvacijai. Jei klausysite savo SRE kaip kūrėjų, turėsite daugiau vietos atlikti gerą darbą ir daug mažiau darbų.
Pasirodo, eksperimentai gamyboje yra gana svarbi ir beveik neatsiejama SRE dalis didelėse komandose. Paprastai tai vadinama chaoso inžinerija, kilusia iš „Netflix“ komandos, kuri išleido programą „Chaos Monkey“.
Chaos Monkey prisijungia prie CI / CD dujotiekio ir atsitiktinai sugenda gamybos serverį. Vėlgi, SRE struktūroje sakome, kad sugedęs serveris savaime nėra blogas, jo tikimasi. O jei įtraukta į biudžetą, tai priimtina ir nekenkia verslui. Žinoma, „Netflix“ turi pakankamai perteklinių serverių, pakankamai replikacijos, kad visa tai būtų galima pataisyti visam vartotojui net nepastebint ir tikrai niekas nepalieka vieno serverio už jokį biudžetą.
„Netflix“ vienu metu turėjo daugybę tokių paslaugų, iš kurių viena, „Chaos Gorilla“, visiškai išjungia vieną iš „Amazon“ pasiekiamumo zonų. Ir tokie dalykai puikiai padeda atpažinti, pirma, paslėptas priklausomybes, kai nėra iki galo aišku, kas ką įtakoja, kas nuo ko priklauso. Ir tai, jei dirbate su mikro paslauga, o dokumentacija nėra visiškai tobula, tai jums gali būti žinoma. Ir vėlgi, tai padeda pagauti klaidas kode, kurių negalite pagauti inscenizacijos metu, nes bet koks sustojimo būdas nėra tikslus modeliavimas, nes skiriasi apkrovos skalė, skiriasi apkrovos modelis, įranga taip pat, dauguma tikėtina, kita. Didžiausios apkrovos taip pat gali būti netikėtos ir nenuspėjamos. Ir toks testavimas, kuris vėlgi neperžengia biudžeto ribų, labai gerai padeda pagauti infrastruktūros klaidas, kurių niekad nepagaus inscenizacija, autotestai ir CI/CD konvejeriai. Ir kol visa tai yra įtraukta į jūsų biudžetą, nesvarbu, kad jūsų paslauga ten nukrito, nors tai atrodytų labai baisu, serveris sugedo, koks košmaras. Ne, tai normalu, tai gerai, tai padeda sugauti klaidas. Jei turite biudžetą, galite jį išleisti.
Klausimas: kokią literatūrą galiu rekomenduoti? Sąrašas yra pabaigoje. Literatūros daug, rekomenduočiau keletą pranešimų. Kaip tai veikia ir ar SRE veikia įmonėse, neturinčiose savo programinės įrangos produkto ar su minimalia plėtra. Pavyzdžiui, įmonėje, kurioje pagrindinė veikla nėra programinė įranga. Įmonėje, kur pagrindinė veikla nėra programinė įranga, SRE veikia lygiai taip pat kaip ir bet kur kitur, nes įmonėje taip pat reikia naudoti, net jei nekuriate, programinės įrangos produktus, reikia įdiegti naujinimus, reikia keisti infrastruktūrą, reikia augti, reikia plėstis. O SRE padeda nustatyti ir numatyti galimas šių procesų problemas ir jas kontroliuoti prasidėjus tam tikram augimui ir pasikeitus verslo poreikiams. Nes visiškai nebūtina užsiimti programinės įrangos kūrimu norint turėti SRE, jei turi bent kelis serverius ir tikitės bent kažkiek augimo.
Tas pats pasakytina apie mažus projektus, mažas organizacijas, nes didelės įmonės turi biudžeto ir erdvės eksperimentams. Tačiau tuo pačiu metu visi šie eksperimentų vaisiai gali būti naudojami bet kur, tai yra, SRE, žinoma, pasirodė „Google“, „Netflix“ ir „Dropbox“. Tačiau tuo pat metu mažos įmonės ir startuoliai jau gali skaityti sutrumpintą medžiagą, skaityti knygas, žiūrėti reportažus. Jie pradeda dažniau apie tai girdėti, žiūri į konkrečius pavyzdžius, manau, gerai, tai tikrai gali būti naudinga, mums taip pat reikia, šaunu.
Tai yra, visas pagrindinis šių procesų standartizavimo darbas jau atliktas už jus. Viskas, ką jums reikia padaryti, tai konkrečiai apibrėžti SRE vaidmenį jūsų įmonėje ir pradėti realiai įgyvendinti visas šias praktikas, kurios, vėlgi, jau buvo aprašytos. Tai yra, iš naudingų principų mažoms įmonėms, tai visada yra SLA, SLI, SLO apibrėžimas. Jei nesate susijęs su programine įranga, tai bus vidiniai SLA ir vidiniai SLO, vidinis klaidų biudžetas. Tai beveik visada sukelia įdomių diskusijų komandoje ir versle, nes gali pasirodyti, kad išleidžiate daug daugiau nei reikia infrastruktūrai, kažkokiam idealių procesų organizavimui, idealiam vamzdynui. Ir šių 4 devynerių, kuriuos turite IT skyriuje, jums dabar tikrai nereikia. Tačiau tuo pat metu buvo galima praleisti laiką, išleisti klaidų biudžetą kažkam kitam.
Atitinkamai stebėjimas ir stebėjimo organizavimas yra naudingas bet kokio dydžio įmonei. Ir apskritai toks mąstymas, kai klaidos yra kažkas priimtina, kur yra biudžetas, kur yra Tikslai, vėlgi naudingas bet kokio dydžio įmonei, pradedant nuo 3 žmonių startuolio.
Paskutinis techninis niuansas, apie kurį galime kalbėti, yra stebėjimas. Nes jei kalbame apie SLA, SLI, SLO, mes negalime suprasti, jei neprižiūrime, ar telpame į biudžetą, ar laikomės savo tikslų ir kaip įtakojame galutinį SLA. Daug kartų pastebėjau, kad stebėjimas vyksta taip: yra tam tikra reikšmė, pavyzdžiui, užklausos serveriui laikas, vidutinis laikas arba užklausų į duomenų bazę skaičius. Jis turi standartą, kurį nustato inžinierius. Jei metrika nukrypsta nuo normos, siunčiamas el. Visa tai, kaip taisyklė, yra visiškai nenaudinga, nes tai sukelia tokį įspėjimų persotinimą, stebėjimo pranešimų perpildymą, kai asmuo, visų pirma, kiekvieną kartą turi juos interpretuoti, tai yra nustatyti, ar metrinė vertė reiškia poreikį kažkoks veiksmas. Antra, jis tiesiog nustoja pastebėti visus šiuos įspėjimus, kai iš esmės nereikia imtis jokių veiksmų. Tai yra, gera stebėjimo taisyklė ir pati pirmoji taisyklė įgyvendinant SRE yra ta, kad pranešimas turėtų būti pateikiamas tik tada, kai reikia imtis veiksmų.
Standartiniu atveju yra 3 įvykių lygiai. Yra perspėjimų, yra bilietų, yra žurnalų. Įspėjimai yra viskas, dėl ko reikia nedelsiant imtis veiksmų. Tai yra, viskas sugedo, dabar reikia taisyti. Bilietai yra kažkas, dėl ko reikia laukti veiksmų. Taip, jums reikia ką nors padaryti, reikia ką nors padaryti rankiniu būdu, automatizavimas nepavyko, bet jums nereikia to daryti per kelias artimiausias minutes. Žurnalai yra viskas, kas nereikalauja veiksmų, ir apskritai, jei viskas klostysis gerai, niekas jų niekada neskaitys. Žurnalus skaityti reikės tik tada, kai retrospektyvoje paaiškės, kad kurį laiką kažkas sugedo, mes apie tai nežinojome. Arba reikia atlikti kokį nors tyrimą. Bet apskritai viskas, kas nereikalauja jokių veiksmų, patenka į rąstus.
Kaip šalutinį viso to efektą, jei nustatėme, kokiems įvykiams reikia veiksmų, ir gerai apibūdinome, kokie tie veiksmai turėtų būti, tai reiškia, kad veiksmas gali būti automatizuotas. Tai yra, kas atsitinka. Mes ateiname iš perspėjimo. Pereikime prie veiksmo. Pereikime prie šio veiksmo aprašymo. Ir tada pereiname prie automatizavimo. Tai yra, bet kokia automatizacija prasideda nuo reakcijos į įvykį.
Nuo stebėjimo pereiname prie termino, vadinamo stebimumu. Pastaruosius kelerius metus taip pat buvo šiek tiek ažiotažas apie šį žodį. Ir mažai žmonių supranta, ką tai reiškia, neskaitydami konteksto. Tačiau svarbiausia yra tai, kad Stebimumas yra sistemos skaidrumo metrika. Jei kažkas nutiko, kaip greitai galite nustatyti, kas tiksliai nutiko ir kokia buvo sistemos būsena tuo metu. Kodo požiūriu: kuri funkcija nepavyko, kuri paslauga nepavyko. Kokia buvo, pavyzdžiui, vidinių kintamųjų, konfigūracijos būsena. Infrastruktūros požiūriu tai yra, kurioje pasiekiamumo zonoje įvyko gedimas, o jei turite kokį nors „Kubernetes“, tai kuriame bloke įvyko gedimas, kokia buvo bloko būsena. Ir atitinkamai Stebimumas turi tiesioginį ryšį su MTTR. Kuo didesnis paslaugos Stebimumas, tuo lengviau identifikuoti klaidą, lengviau ištaisyti klaidą, lengviau automatizuoti klaidą, tuo mažesnis MTTR.
Jei vėl pereitume prie mažų įmonių, jos net ir dabar labai dažnai klausia, ką daryti su kolektyvo dydžiu, ar reikia mažoje komandoje samdyti atskirą VĮ. Apie tai jau kalbėjau šiek tiek anksčiau. Pirmuosiuose startuolio ar, pavyzdžiui, komandos vystymosi etapuose tai visai nebūtina, nes SRE galima padaryti pereinamuoju vaidmeniu. Ir tai šiek tiek pagyvins komandą, nes yra bent šiokia tokia įvairovė. O plius tai paruoš žmones tam, kad jiems augant apskritai SRE pareigos labai smarkiai pasikeis. Jei samdote žmogų, tai, žinoma, jis turi tam tikrų lūkesčių. Ir šie lūkesčiai laikui bėgant nepasikeis, tačiau reikalavimai labai keisis. Todėl pradiniame etape samdyti SRE yra gana sunku. Daug lengviau auginti savo. Bet verta pagalvoti.
Vienintelė išimtis, ko gero, yra tada, kai yra labai griežti ir aiškiai apibrėžti ūgio reikalavimai. Tai yra, startuolio atveju tai gali būti tam tikras investuotojų spaudimas, kažkokia augimo prognozė kelis kartus iš karto. Tada SRE samdymas paprastai yra pateisinamas, nes tai gali būti pateisinama. Turime augimo reikalavimus, reikia žmogaus, kuris būtų atsakingas, kad su tokiu augimu niekas nenutrūktų.
Dar vienas klausimas. Ką daryti, kai kelis kartus kūrėjai iškirpo funkciją, kuri praeina testus, bet sulaužo produktą, įkelia duomenų bazę, sulaužo kitas funkcijas, kokį procesą įdiegti. Atitinkamai šiuo atveju įvedamas klaidų biudžetas. O kai kurios paslaugos, kai kurios funkcijos iš karto išbandomos gamyboje. Tai gali būti kanarėlė, kai tik nedaugelis vartotojų, bet jau gaminami, diegia funkciją, tačiau tikisi, kad jei kažkas suges, pavyzdžiui, pusei procento visų vartotojų, jis vis tiek tilps į klaidų biudžetas. Atitinkamai, taip, bus klaida, kai kuriems vartotojams viskas suges, bet mes jau sakėme, kad tai normalu.
Kilo klausimas dėl SRE įrankių. Tai yra, ar yra kažkas konkretaus, ką SRE naudotų, ko nenaudotų visi kiti? Tiesą sakant, yra keletas labai specializuotų paslaugų, yra tam tikra programinė įranga, kuri, pavyzdžiui, imituoja apkrovas arba atlieka A/B testavimą. Tačiau iš esmės SRE įrankiai yra tai, ką jūsų kūrėjai jau naudoja. Kadangi SRE tiesiogiai bendrauja su kūrėjų komanda. O jei turite įvairių įrankių, paaiškėja, kad sinchronizuoti reikia laiko. Ypač jei SRE dirba didelėse komandose, didelėse įmonėse, kur gali būti kelios komandos, čia labai pravers visos įmonės standartizavimas, nes jei 50 komandų naudoja 50 skirtingų komunalinių paslaugų, tai reiškia, kad SRE turi žinoti visas. Ir, žinoma, tai niekada neįvyks. O darbo kokybė, bent kai kurių komandų kontrolės kokybė gerokai sumažės.
Mūsų internetinis seminaras pamažu eina į pabaigą. Man pavyko jums pasakyti keletą pagrindinių dalykų. Žinoma, per valandą nieko apie SRE negalima pasakyti ir suprasti. Bet tikiuosi, kad man pavyko perteikti tokį mąstymą, pagrindinius esminius dalykus. O tada, jei įdomu, galima gilintis į temą, mokytis savarankiškai ir pasižiūrėti, kaip tai įgyvendina kiti žmonės, kitose įmonėse. Ir atitinkamai vasario pradžioje atvykite pas mus į Slurm SRE.
Slurm SRE yra trijų dienų intensyvūs kursai, kurie apims maždaug tai, apie ką aš dabar kalbu, tačiau daug giliau, su realiais atvejais, su praktika, visas intensyvus yra skirtas praktiniam darbui. Žmonės bus suskirstyti į komandas. Jūs visi dirbsite su tikrais atvejais. Atitinkamai, mes turime instruktorius iš Booking.com Ivan Kruglov ir Ben Tyler. Turime nuostabų Evgeniy Varabbas iš „Google“ iš San Francisko. Ir aš tau kai ką papasakosiu. Tad būtinai užsukite pas mus.
Taigi, nuorodų sąrašas. SRE yra nuorodos. toje pačioje knygoje, tiksliau – 2 knygose apie SRE, kurias parašė Google. Kitas , kur terminai ir jų taikymas paaiškinti kiek plačiau. Kiti 3 yra skirtingų įmonių SRE ataskaitos. Pirmas - , tai pagrindinis „Google“ Beno Trenerio pranešimas. Antra - . Trečiasis vėl apie . Ketvirtasis reportažas iš , kurioje dirba tik 5 pagrindiniai SRE darbuotojai 190 šalių. Labai įdomu į visa tai pažvelgti, nes kaip „DevOps“ skirtingoms įmonėms ir net skirtingoms komandoms reiškia labai skirtingus dalykus, SRE turi labai skirtingas pareigas net ir panašaus dydžio įmonėse.
Dar 2 nuorodos apie chaoso inžinerijos principus: , . Ir pabaigoje yra 3 sąrašai iš serijos Awesome Lists apie apie ir apie . SRE sąrašas yra neįtikėtinai didžiulis, jums nereikia viso to peržiūrėti, yra apie 200 straipsnių. Labai rekomenduoju straipsnius apie pajėgumų planavimą ir nepriekaištingą postmortem.
Įdomus straipsnis:
Ačiū, kad visą šį laiką manęs klausėtės. Tikiuosi ko nors išmokai. Tikiuosi, kad turite pakankamai medžiagos, kad išmoktumėte dar daugiau. Ir iki pasimatymo vėliau. Tikiuosi vasario mėn.
Webinarą vedė Eduardas Medvedevas.
PS: mėgstantiems skaityti Eduardas pateikė literatūros sąrašą. Tie, kurie nori tai suprasti praktiškai, laukiami adresu .
Šaltinis: www.habr.com