Webinar ima loš zvuk, pa smo ga transkribirali.
Moje ime je Medvedev Eduard. Danas ću govoriti o tome što je SRE, kako se pojavio SRE, koji su kriteriji rada SRE inženjera, malo o kriterijima pouzdanosti, malo o njegovom praćenju. Hodat ćemo po vrhovima, jer u sat vremena se ne može puno ispričati, ali dat ću materijale na dodatni pregled, a svi vas čekamo na . u Moskvi krajem siječnja.
Prvo, razgovarajmo o tome što je SRE - Site Reliability Engineering. I kako se pojavio kao posebna pozicija, kao poseban pravac. Sve je počelo s činjenicom da su u tradicionalnim razvojnim krugovima Dev i Ops dva potpuno različita tima, obično s dva potpuno različita cilja. Cilj razvojnog tima je uvesti nove značajke i zadovoljiti potrebe poslovanja. Cilj Ops tima je osigurati da sve radi i da se ništa ne pokvari. Očito, ovi ciljevi izravno proturječe jedan drugome: da sve radi i da se ništa ne kvari, uvodite nove značajke što je manje moguće. Zbog toga postoje mnogi interni sukobi koje metodologija koja se sada naziva DevOps pokušava riješiti.
Problem je što nemamo jasnu definiciju DevOpsa i jasnu implementaciju DevOpsa. Govorio sam na konferenciji u Jekaterinburgu prije 2 godine, a do sada je odjeljak DevOps počinjao izvješćem “Što je DevOps”. U 2017. godini Devops je star skoro 10 godina, ali još se svađamo što je to. I ovo je vrlo čudna situacija koju je Google pokušao riješiti prije nekoliko godina.
Google je 2016. objavio knjigu pod nazivom Site Reliability Engineering. I zapravo je ovom knjigom započeo SRE pokret. SRE je specifična implementacija DevOps paradigme u određenoj tvrtki. SRE inženjeri predani su osiguravanju pouzdanog rada sustava. Uglavnom dolaze od programera, ponekad administratora s jakim iskustvom u razvoju. I rade ono što su nekada radili administratori sustava, ali jaka pozadina u razvoju i poznavanje sustava u smislu koda dovodi do toga da ti ljudi nisu skloni rutinskom administrativnom poslu, već su skloni automatizaciji.
Ispada da je DevOps paradigma u SRE timovima implementirana činjenicom da postoje SRE inženjeri koji rješavaju strukturne probleme. Evo je, ista veza između Deva i Opsa o kojoj ljudi pričaju već 8 godina. Uloga SRE-a slična je ulozi arhitekta po tome što pridošlice ne postaju SRE-i. Ljudi na početku karijere još nemaju nikakvo iskustvo, nemaju potrebnu širinu znanja. Jer SRE zahtijeva vrlo suptilno znanje o tome što točno i kada točno može poći po zlu. Stoga je ovdje u pravilu potrebno neko iskustvo, kako unutar tvrtke tako i izvan nje.
Pitaju hoće li biti opisana razlika između SRE i devopsa. Upravo je opisana. Možemo govoriti o mjestu SRE u organizaciji. Za razliku od ovog klasičnog DevOps pristupa, gdje je Ops još uvijek zaseban odjel, SRE je dio razvojnog tima. Uključeni su u razvoj proizvoda. Postoji čak i pristup u kojem je SRE uloga koja prelazi s jednog programera na drugog. Oni sudjeluju u pregledima koda na isti način kao, primjerice, UX dizajneri, sami programeri, ponekad i voditelji proizvoda. SRE rade na istoj razini. Moramo ih odobriti, moramo ih pregledati, tako da za svaku implementaciju SRE kaže: “U redu, ova implementacija, ovaj proizvod neće negativno utjecati na pouzdanost. A ako i jest, onda u nekim prihvatljivim granicama. O ovome ćemo također razgovarati.
Sukladno tome, SRE ima pravo veta na promjenu kodeksa. I općenito, to također dovodi do neke vrste malog sukoba ako se SRE implementira na pogrešan način. U istoj knjizi o inženjerstvu pouzdanosti mjesta, mnogi dijelovi, niti jedan, govore kako izbjeći ove sukobe.
Pitaju kako se SRE odnosi na informacijsku sigurnost. SRE nije izravno uključen u informacijsku sigurnost. Uglavnom, u velikim tvrtkama to rade pojedinci, testeri, analitičari. Ali SRE je također u interakciji s njima u smislu da neke operacije, neka predaja, neke implementacije koje utječu na sigurnost također mogu utjecati na dostupnost proizvoda. Stoga SRE kao cjelina ima interakciju s bilo kojim timovima, uključujući sigurnosne timove, uključujući analitičare. Stoga su SRE-ovi uglavnom potrebni kada pokušavaju implementirati DevOps, ali u isto vrijeme teret programera postaje prevelik. Odnosno, sam razvojni tim se više ne može nositi s činjenicom da sada moraju biti odgovorni i za Ops. A postoji i zasebna uloga. Ova uloga je planirana u proračunu. Ponekad je ta uloga određena veličinom tima, pojavljuje se posebna osoba, ponekad to postane jedan od programera. Tako se prvi SRE pojavljuje u timu.
Složenost sustava na koju utječe SRE, složenost koja utječe na pouzdanost rada, nužna je i slučajna. Nužna složenost je kada se složenost proizvoda povećava do mjere koju zahtijevaju nove karakteristike proizvoda. Nasumična složenost je kada se složenost sustava povećava, ali značajka proizvoda i poslovni zahtjevi ne utječu izravno na to. Ispada da je ili programer negdje pogriješio, ili algoritam nije optimalan, ili se uvode neki dodatni interesi koji povećavaju složenost proizvoda bez posebne potrebe. Dobar SRE bi uvijek trebao prekinuti ovu situaciju. Odnosno, svako predanje, bilo koja implementacija, svaki zahtjev za povlačenjem, gdje je poteškoća povećana zbog nasumičnog dodavanja, treba biti blokiran.
Pitanje je zašto jednostavno ne zaposliti inženjera, sistem administratora s puno znanja u tim. Programer u ulozi inženjera, kažu nam, nije najbolje kadrovsko rješenje. Programer u ulozi inženjera nije uvijek najbolje kadrovsko rješenje, ali ovdje se radi o tome da programer koji se bavi Opsom ima malo veću želju za automatizacijom, ima malo više znanja i skupa vještina kako bi implementirao ovu automatizaciju. I sukladno tome, smanjujemo ne samo vrijeme za neke specifične operacije, ne samo rutinu, već i tako važne poslovne parametre kao što je MTTR (Mean Time To Recovery, vrijeme oporavka). Time, a o tome ćemo također malo kasnije, štedimo novac za organizaciju.
Razgovarajmo sada o kriterijima za rad SRE. I prije svega o pouzdanosti. U malim tvrtkama, startupima, često se događa da ljudi pretpostavljaju da ako je usluga dobro napisana, ako je proizvod dobro i ispravno napisan, da će raditi, neće se pokvariti. To je to, pišemo dobar kod, tako da se nema što pokvariti. Kod je vrlo jednostavan, nema se što razbiti. To su otprilike isti ljudi koji kažu da nam ne trebaju testovi, jer, gledajte, ovo su tri VPI metode, zašto prekidati ovdje.
Sve je to pogrešno, naravno. I ti ljudi vrlo često u praksi grizu takvim kodeksom, jer se stvari kvare. Stvari se ponekad pokvare na najnepredvidivije načine. Ponekad ljudi kažu ne, to se nikada neće dogoditi. I to se stalno događa. To se događa dovoljno često. I zato nitko nikada ne teži 100% dostupnosti, jer 100% dostupnost se nikada ne događa. Ovo je norma. I zato, kada govorimo o dostupnosti usluge, uvijek govorimo o devetkama. 2 devetke, 3 devetke, 4 devetke, 5 devetki. Ako to prevedemo u zastoje, pa npr. 5 devetki, onda je to nešto više od 5 minuta zastoja godišnje, 2 devetke su 3,5 dana zastoja.
Ali očito je da u nekom trenutku dolazi do smanjenja POI, povrata investicije. Prelazak s dvije devetke na tri devetke znači manje zastoja za više od 3 dana. Prelazak s četiri devetke na pet smanjuje vrijeme zastoja za 47 minuta godišnje. I ispada da za posao to možda i nije kritično. I općenito, potrebna pouzdanost nije tehničko pitanje, prije svega, to je poslovno pitanje, to je pitanje proizvoda. Koja je razina zastoja prihvatljiva za korisnike proizvoda, što očekuju, koliko plaćaju, na primjer, koliko novca gube, koliko novca gubi sustav.
Ovdje je važno pitanje koja je pouzdanost preostalih komponenti. Jer razlika između 4 i 5 devetki neće biti vidljiva na pametnom telefonu s 2 devetke pouzdanosti. Grubo rečeno, ako vam se 10 puta godišnje nešto pokvari na pametnom telefonu u servisu, najvjerojatnije 8 puta se kvar dogodio na strani OS-a. Korisnik je navikao na to i neće obraćati pažnju na još jednom godišnje. Potrebno je korelirati cijenu povećanja pouzdanosti i povećanja profita.
Samo u knjizi o SRE postoji dobar primjer povećanja na 4 devetke sa 3 devetke. Ispada da je povećanje dostupnosti nešto manje od 0,1%. A ako je prihod usluge milijun dolara godišnje, tada je povećanje prihoda 1 dolara. Ako nas povećanje pristupačnosti za devet košta manje od 900 USD godišnje, povećanje ima financijski smisla. Ako košta više od 900 dolara godišnje, to više nema smisla, jer povećanje prihoda jednostavno ne kompenzira troškove rada, troškove resursa. I 900 devetke će nam biti dovoljne.
Ovo je naravno pojednostavljeni primjer gdje su svi zahtjevi jednaki. I prijeći s 3 devetke na 4 devetke dovoljno je jednostavno, ali u isto vrijeme, na primjer, prijeći s 2 devetke na 3, to je već ušteda od 9 tisuća dolara, može imati financijski smisao. Naravno, u stvarnosti je neuspjeh zahtjeva za registraciju gori od neuspjeha prikazivanja stranice, zahtjevi imaju različite težine. Oni mogu imati potpuno drugačiji kriterij s poslovnog gledišta, ali svejedno, u pravilu, ako ne govorimo o nekim specifičnim uslugama, to je prilično pouzdana aproksimacija.
Dobili smo upit je li SRE jedan od koordinatora pri odabiru arhitektonskog rješenja usluge. Recimo u smislu integracije u postojeću infrastrukturu, kako ne bi došlo do gubitka njene stabilnosti. Da, SRE-ovi, na isti način na koji zahtjevi za povlačenjem, predaje, izdanja utječu na arhitekturu, uvođenje novih usluga, mikroservisa, implementaciju novih rješenja. Zašto sam prije rekao da je potrebno iskustvo, potrebne su kvalifikacije. Zapravo, SRE je jedan od blokirajućih glasova u bilo kojem arhitektonskom i softverskom rješenju. Sukladno tome, SRE kao inženjer mora, prije svega, ne samo razumjeti, već i razumjeti kako će neke specifične odluke utjecati na pouzdanost, stabilnost, te razumjeti kako se to odnosi na poslovne potrebe i s kojeg gledišta može biti prihvatljivo i koji ne.
Dakle, sada možemo govoriti samo o kriterijima pouzdanosti, koji su tradicionalno definirani u SRE kao SLA (Service Level Agreement). Najvjerojatnije poznati izraz. SLI (indikator razine usluge). SLO (Cilj razine usluge). Service Level Agreement je možda simboličan pojam, pogotovo ako ste radili s mrežama, s provajderima, s hostingom. Ovo je opći ugovor koji opisuje izvedbu cijele vaše usluge, kazne, neke kazne za pogreške, metrike, kriterije. A SLI je sama metrika dostupnosti. Odnosno, što SLI može biti: vrijeme odziva usluge, broj pogrešaka u postotku. To bi mogla biti propusnost ako se radi o nekoj vrsti hostinga datoteka. Kad su u pitanju algoritmi za prepoznavanje, indikator može biti, primjerice, čak i točnost odgovora. SLO (Service Level Objective) je kombinacija indikatora SLI, njegove vrijednosti i razdoblja.
Recimo da bi SLA mogao biti ovakav. Usluga je dostupna 99,95% vremena tijekom cijele godine. Ili će 99 kritičnih zahtjeva za podršku biti zatvoreno unutar 3 sata po kvartalu. Ili će 85% upita dobiti odgovore u roku od 1,5 sekunde svaki mjesec. To jest, postupno shvaćamo da su pogreške i kvarovi sasvim normalni. To je prihvatljiva situacija, mi to planiramo, čak donekle i računamo na to. Odnosno, SRE gradi sustave koji mogu griješiti, koji moraju normalno reagirati na pogreške, koji ih moraju uzeti u obzir. I kad god je to moguće, trebaju rješavati pogreške na takav način da ih korisnik ili ne primijeti, ili primijeti, ali postoji nekakvo zaobilazno rješenje, zahvaljujući kojem sve neće pasti u vodu.
Na primjer, ako prenesete video na YouTube, a YouTube ga ne može odmah pretvoriti, ako je video prevelik, ako format nije optimalan, tada zahtjev prirodno neće uspjeti s timeoutom, YouTube neće dati pogrešku 502 , YouTube će reći: “Stvorili smo sve, vaš video je u obradi. Bit će gotovo za 10-ak minuta." Ovo je princip graciozne degradacije, koji je poznat, na primjer, iz front-end razvoja, ako ste to ikada radili.
Sljedeći pojmovi o kojima ćemo govoriti, a koji su vrlo važni za rad s pouzdanošću, s greškama, s očekivanjima, su MTBF i MTTR. MTBF je srednje vrijeme između kvarova. MTTR srednje vrijeme do oporavka, prosječno vrijeme do oporavka. Odnosno, koliko je vremena prošlo od trenutka kada je greška otkrivena, od trenutka kada se greška pojavila do trenutka kada je usluga vraćena u normalan rad. MTBF se uglavnom popravlja radom na kvaliteti koda. Odnosno, činjenica da SRE mogu reći "ne". I potrebno vam je razumijevanje cijele ekipe da kada SRE kaže "ne", on to ne kaže zato što je štetan, ne zato što je loš, već zato što će inače svi ispaštati.
Opet, postoji mnogo članaka, mnogo metoda, mnogo načina, čak iu samoj knjizi na koju se tako često pozivam, kako osigurati da drugi programeri ne počnu mrziti SRE. MTTR se, s druge strane, odnosi na rad na vašim SLO (Service Level Objective). I to je uglavnom automatizacija. Jer npr. naš SLO je uptime 4 devetke po kvartalu. To znači da u 3 mjeseca možemo dopustiti 13 minuta zastoja. I ispada da MTTR ne može biti duži od 13 minuta. Ako odgovorimo na barem 13 prekid rada u 1 minuta, to znači da smo već potrošili cijeli budžet za kvartal. Razbijamo ČVN. 13 minuta za reakciju i otklanjanje kvara puno je za stroj, ali vrlo kratko za čovjeka. Jer dok čovjek ne dobije dojavu, dok ne reagira, dok ne shvati grešku, to je već nekoliko minuta. Dok čovjek ne shvati kako to popraviti, što točno popraviti, što učiniti, onda je to još nekoliko minuta. I zapravo, čak i ako trebate samo ponovno pokrenuti poslužitelj, kako se ispostavilo, ili podići novi čvor, tada je ručno MTTR već oko 7-8 minuta. Kod automatizacije procesa, MTTR vrlo često doseže sekundu, ponekad milisekundu. Google obično govori o milisekundama, ali u stvarnosti, naravno, nije sve tako dobro.
U idealnom slučaju, SRE bi trebao gotovo u potpunosti automatizirati svoj rad, jer to izravno utječe na MTTR, njegovu metriku, SLO cijele usluge, a time i na poslovnu dobit. Ako je vrijeme prekoračeno, postavlja nam se pitanje je li SRE kriv. Srećom, nitko nije kriv. A ovo je zasebna kultura koja se zove balmeless postmortem, o kojoj danas nećemo govoriti, ali ćemo je analizirati na Slurmu. Ovo je vrlo zanimljiva tema o kojoj se može puno pričati. Grubo rečeno, ako se prekorači predviđeno vrijeme po kvartalu, onda su svi pomalo krivi, što znači da svaljivati krivicu na sve nije produktivno, nego, možda, ne krivimo nikoga, ali ispravimo situaciju i radimo s onim što imamo. Po mom iskustvu, ovaj je pristup pomalo stran većini momčadi, posebice u Rusiji, ali ima smisla i vrlo dobro funkcionira. Stoga ću na kraju članka preporučiti i literaturu koju možete pročitati na ovu temu. Ili dođite u Slurm SRE.
Dopustite da objasnim. Ako je prekoračeno SLO vrijeme po četvrtini, ako zastoj nije bio 13 minuta, nego 15, tko može biti kriv za to? Naravno, SRE može biti kriv, jer je očito napravio neku vrstu lošeg predanja ili raspoređivanja. Za to može biti kriv administrator podatkovnog centra, jer je možda proveo neku vrstu neplaniranog održavanja. Ako je za to kriv administrator podatkovnog centra, onda je za to kriv čovjek iz Opsa koji nije obračunao održavanje kada je koordinirao ČVN. Za to je kriv voditelj, tehnički direktor ili netko tko je potpisao ugovor o podatkovnom centru, a nije obratio pozornost na to da SLA podatkovnog centra nije predviđen za potrebno vrijeme zastoja. Sukladno tome, svi malo po malo u ovoj situaciji su krivi. A to znači da u ovoj situaciji nema smisla svaljivati krivnju na bilo koga. Ali naravno da treba ispraviti. Zato postoje obdukcije. A ako čitate, na primjer, GitHub obdukcije, a to je uvijek vrlo zanimljiva, mala i neočekivana priča u svakom slučaju, možete zamijeniti da nitko nikada ne kaže da je ta osoba kriva. Krivica se uvijek pripisuje određenim nesavršenim procesima.
Prijeđimo na sljedeće pitanje. Automatizacija. Kada govorim o automatizaciji u drugim kontekstima, često se pozivam na tablicu koja vam govori koliko dugo možete raditi na automatizaciji zadatka, a da vam za automatizaciju ne treba više vremena nego što zapravo uštedite. Postoji kvaka. Kvaka je u tome što kada SRE automatiziraju zadatak, ne samo da štede vrijeme, već i novac, jer automatizacija izravno utječe na MTTR. Štede, da tako kažemo, moral zaposlenika i programera, što je također iscrpan resurs. Smanjuju rutinu. A sve to pozitivno utječe na rad, a posljedično i na poslovanje, iako se čini da automatizacija nema smisla s obzirom na vremenske troškove.
Zapravo, gotovo uvijek jest, a vrlo je malo slučajeva u kojima nešto ne bi trebalo biti automatizirano u ulozi SRE-a. Zatim ćemo govoriti o onome što se zove proračun pogreške, proračun za pogreške. Zapravo, ispada da ako je sve puno bolje za vas od ČVN-a koji ste sami postavili, to također nije baš dobro. To je prilično loše, jer SLO ne funkcionira samo kao donja, već i kao približna gornja granica. Kad sebi postavite SLO od 99% dostupnosti, a zapravo imate 99,99%, ispada da imate prostora za eksperimente koji neće nimalo štetiti poslu jer ste to sve skupa sami odredili i jeste ovaj prostor ne koriste. Imate budžet za greške, koji u vašem slučaju nije potrošen.
Što da radimo s tim. Koristimo ga doslovno za sve. Za testiranje u proizvodnim uvjetima, za uvođenje novih značajki koje mogu utjecati na performanse, za izdanja, za održavanje, za planirane zastoje. Vrijedi i obrnuto pravilo: ako je budžet potrošen, ne možemo izdati ništa novo, jer ćemo u protivnom premašiti ČVN. Proračun je već potrošen, nešto smo pustili ako negativno utječe na učinak, odnosno ako to nije nekakav popravak koji sam po sebi direktno povećava ČVN, onda idemo izvan proračuna, a to je loša situacija , potrebno ga je analizirati, postmortem i eventualno neke popravke procesa.
Odnosno, ispada da ako sama usluga ne radi dobro, a SLO se troši i proračun se ne troši na eksperimente, ne na neka izdanja, već sam po sebi, onda umjesto nekih zanimljivih popravaka, umjesto zanimljivih značajki, umjesto zanimljivih izdanja. Umjesto ikakvog kreativnog rada, morat ćete se baviti glupim popravcima kako bi budžet doveli u red ili uredili ČVN, a to je također proces koji se ne bi smio događati prečesto.
Dakle, ispada da su u situaciji kada imamo više proračuna za greške zainteresirani svi: i SRE i programeri. Za programere veliki proračun za bugove znači da se možete baviti izdanjima, testovima, eksperimentima. Za SRE, proračun za pogreške i unošenje tog proračuna znači da izravno rade dobro svoj posao. A to utječe na motivaciju za neku vrstu zajedničkog rada. Ako slušate svoje SRE-ove kao programere, imat ćete više prostora za dobar rad i puno manje rutine.
Ispostavilo se da su eksperimenti u proizvodnji vrlo važan i gotovo sastavni dio SRE-a u velikim timovima. Obično se naziva inženjering kaosa, a dolazi od tima Netflixa koji je izdao pomoćni program pod nazivom Chaos Monkey.
Chaos Monkey spaja se na CI/CD cjevovod i nasumično ruši poslužitelj u produkciji. Opet, u SRE strukturi, govorimo o činjenici da srušeni server nije loš sam po sebi, to je očekivano. I ako je unutar proračuna, prihvatljivo je i ne šteti poslovanju. Naravno, Netflix ima dovoljno redundantnih servera, dovoljno replikacije, da se sve to može popraviti, a da korisnik u cjelini niti ne primijeti, a još više nitko ne ostavlja jedan server za bilo koji budžet.
Netflix je neko vrijeme imao cijeli paket takvih uslužnih programa, od kojih je jedan, Chaos Gorilla, potpuno isključio jednu od Amazonovih zona dostupnosti. A takve stvari pomažu otkriti, prvo, skrivene ovisnosti, kada nije sasvim jasno što na što utječe, što o čemu ovisi. A ovo, ako radite s mikroservisom, a dokumentacija nije baš savršena, ovo vam može biti poznato. I opet, ovo puno pomaže da se uhvate pogreške u kodu koje ne možete uhvatiti tijekom postavljanja, jer svako postavljanje nije baš točna simulacija, zbog činjenice da je skala opterećenja drugačija, obrazac opterećenja je drugačiji, oprema je također, najvjerojatnije, drugo. Vršna opterećenja također mogu biti neočekivana i nepredvidiva. A takvo testiranje, koje opet ne ide dalje od budžeta, jako dobro pomaže da se uhvate greške u infrastrukturi koje staging, autotestovi, CI/CD pipeline nikada neće uhvatiti. I dokle god je to sve uključeno u vaš proračun, nije važno što vam je usluga pala, iako bi se činilo vrlo zastrašujuće, server je pao, kakva noćna mora. Ne, to je normalno, to je dobro, pomaže u hvatanju grešaka. Ako imate proračun, možete ga potrošiti.
P: Koju literaturu mogu preporučiti? Popis na kraju. Ima puno literature, savjetovat ću nekoliko izvješća. Kako to funkcionira i funkcionira li SRE u tvrtkama koje nemaju vlastiti programski proizvod ili su s minimalnim razvojem. Na primjer, u poduzeću u kojem glavna djelatnost nije softver. U poduzeću, gdje glavna djelatnost nije softver, SRE radi potpuno isto kao i svugdje drugdje, jer u poduzeću također morate koristiti, čak i ako nisu razvijeni, softverske proizvode, morate uvesti ažuriranja, morate promijeniti infrastruktura, morate rasti, morate se širiti. A SRE pomažu identificirati i predvidjeti moguće probleme u tim procesima i kontrolirati ih nakon što započne rast i promjene poslovnih potreba. Jer apsolutno nije nužno biti uključen u razvoj softvera da biste imali SRE ako imate barem nekoliko poslužitelja i od vas se očekuje da imate barem neki rast.
Isto vrijedi i za male projekte, male organizacije, jer velike tvrtke imaju proračun i prostor za eksperimentiranje. Ali u isto vrijeme, svi ti plodovi eksperimenata mogu se koristiti bilo gdje, to jest, SRE se, naravno, pojavio u Googleu, u Netflixu, u Dropboxu. Ali u isto vrijeme, male tvrtke i startupi već mogu čitati sažeti materijal, čitati knjige, gledati izvješća. Počnu češće slušati o tome, gledaju konkretne primjere, mislim da je u redu, stvarno može biti od koristi, trebamo i ovo, super je.
Odnosno, sav glavni posao na standardizaciji ovih procesa već je obavljen za vas. Ostaje vam da odredite ulogu SRE-a konkretno u vašoj tvrtki i počnete stvarno provoditi sve ove prakse, koje su, opet, već opisane. Odnosno, od korisnih principa za mala poduzeća, ovo je uvijek definicija SLA, SLI, SLO. Ako se ne bavite softverom, onda će to biti interni SLA i interni SLO, interni proračun za pogreške. To gotovo uvijek dovodi do nekih zanimljivih rasprava unutar tima i unutar posla, jer se može ispostaviti da trošite na infrastrukturu, na nekakvu organizaciju idealnih procesa, idealan cjevovod je puno više nego što je potrebno. A ove 4 devetke koje imate u informatičkom odjelu, sad vam baš i ne trebaju. Ali u isto vrijeme, možete potrošiti vrijeme, potrošiti proračun za pogreške na nešto drugo.
Sukladno tome, nadzor i organizacija nadzora korisni su poduzeću bilo koje veličine. I općenito, ovakav način razmišljanja, gdje su greške nešto prihvatljivo, gdje postoji budžet, gdje postoje ciljevi, opet je koristan za tvrtku bilo koje veličine, počevši od startupa za 3 osobe.
Posljednja od tehničkih nijansi o kojoj treba govoriti je praćenje. Jer ako govorimo o SLA, SLI, SLO, ne možemo shvatiti bez praćenja uklapamo li se u proračun, pridržavamo li se svojih ciljeva i kako utječemo na konačni SLA. Toliko sam puta vidio da se praćenje događa ovako: postoji neka vrijednost, na primjer, vrijeme zahtjeva prema poslužitelju, prosječno vrijeme ili broj zahtjeva prema bazi podataka. Ima standard koji je odredio inženjer. Ako metrika odstupa od norme, tada stiže e-mail. To je sve u pravilu apsolutno beskorisno, jer dovodi do prenatrpanosti dojavama, prenatrpanosti porukama iz monitoringa, kada ih čovjek, prvo, mora svaki put protumačiti, odnosno utvrditi je li vrijednost metrike značila potreba za nekim djelovanjem. I drugo, on jednostavno prestaje primjećivati sva ta upozorenja, kada se od njega zapravo ne zahtijeva ništa. To je dobro pravilo nadzora i prvo pravilo kada se SRE implementira je da obavijest treba stići samo kada je potrebna akcija.
U standardnom slučaju postoje 3 razine događaja. Postoje upozorenja, postoje karte, postoje zapisi. Upozorenja su sve što od vas zahtijeva hitnu akciju. Odnosno, sve je pokvareno, morate to popraviti odmah. Ulaznice su ono što zahtijeva odgođeno djelovanje. Da, morate nešto učiniti, morate nešto učiniti ručno, automatizacija nije uspjela, ali ne morate to učiniti sljedećih nekoliko minuta. Dnevnici su sve što ne zahtijeva radnju i općenito, ako stvari idu dobro, nitko ih nikada neće čitati. Trebat ćete samo čitati dnevnike kada se retrospektivno pokaže da se neko vrijeme nešto pokvarilo, a mi za to nismo znali. Ili morate malo istražiti. Ali općenito, sve što ne zahtijeva nikakvu radnju ide u zapisnike.
Kao nuspojava svega ovoga, ako smo definirali koji događaji zahtijevaju akcije i dobro opisali koje bi te radnje trebale biti, to znači da se akcija može automatizirati. Odnosno, što se događa. Idemo iz pripravnosti. Idemo u akciju. Idemo na opis ove akcije. A onda prelazimo na automatizaciju. Odnosno, svaka automatizacija počinje reakcijom na događaj.
Od praćenja prelazimo na pojam koji se zove Opservabilnost. Posljednjih nekoliko godina postoji i mala pompa oko ove riječi. I malo ljudi razumije što to znači izvan konteksta. Ali glavna je poanta da je vidljivost metrika za transparentnost sustava. Ako je nešto pošlo po zlu, koliko brzo možete utvrditi što je točno pošlo po zlu i kakvo je stanje sustava u tom trenutku. U smislu koda: koja funkcija nije uspjela, koja usluga nije uspjela. Kakvo je bilo stanje npr. internih varijabli, konfiguracije. Što se tiče infrastrukture, ovo je u kojoj je zoni dostupnosti došlo do kvara, a ako imate instaliran Kubernetes, onda u kojem je podu došlo do kvara, u kakvom je stanju pod. I sukladno tome, Observability ima izravan odnos s MTTR-om. Što je veća vidljivost usluge, lakše je identificirati grešku, lakše je popraviti grešku, lakše je automatizirati grešku, niži je MTTR.
Prelazeći ponovno na male tvrtke, vrlo je uobičajeno pitati se, čak i sada, kako se nositi s veličinom tima i treba li mali tim zaposliti zasebnog SRE-a. O ovome je već bilo riječi malo ranije. U prvim fazama razvoja startupa ili, na primjer, tima, to uopće nije potrebno, jer SRE može postati prijelazna uloga. A ovo će malo oživjeti ekipu jer bar ima šarolikosti. I plus to će pripremiti ljude na činjenicu da će se s rastom, općenito, odgovornosti SRE-a vrlo značajno promijeniti. Ako zaposlite osobu, onda, naravno, ona ima neka očekivanja. I ta se očekivanja neće promijeniti tijekom vremena, ali će se zahtjevi jako promijeniti. Stoga je vrlo teško u ranim fazama zaposliti SRE-a. Uzgoj vlastitog je puno lakši. Ali vrijedi razmisliti.
Možda je jedina iznimka kada postoje vrlo strogi i dobro definirani zahtjevi za rastom. Odnosno, u slučaju startupa, to može biti neka vrsta pritiska investitora, neka vrsta prognoze rasta nekoliko puta odjednom. Tada je angažiranje SRE-a u osnovi opravdano jer se može opravdati. Imamo zahtjeve za rastom, trebamo osobu koja će biti odgovorna da se takvim rastom ništa ne pokvari.
Još jedno pitanje. Što učiniti kada programeri nekoliko puta izrežu značajku koja prolazi testove, ali prekida proizvodnju, učitava bazu, kvari druge značajke, koji proces implementirati. Sukladno tome, u ovom slučaju uvodi se proračun za pogreške. A neke od usluga, neke od značajki već se testiraju u proizvodnji. To može biti kanarinsko, kada je samo mali broj korisnika, ali već u produkciji, značajka implementirana, ali već s očekivanjem da će, ako se nešto pokvari, na primjer, za pola posto svih korisnika, svejedno zadovoljiti proračun za pogreške. Sukladno tome, da, doći će do pogreške, za neke korisnike će se sve pokvariti, ali već smo rekli da je to normalno.
Postojalo je pitanje o SRE alatima. Odnosno, postoji li nešto posebno što bi SRE koristili, a svi drugi ne bi. Zapravo, postoje neki visoko specijalizirani uslužni programi, postoji neka vrsta softvera koji, na primjer, simulira opterećenja ili se bavi kanarskim A / B testiranjem. Ali u osnovi SRE toolkit je ono što vaši programeri već koriste. Budući da SRE izravno komunicira s razvojnim timom. A ako imate različite alate, ispostavit će se da je potrebno vrijeme za sinkronizaciju. Pogotovo ako SRE rade u velikim timovima, u velikim tvrtkama gdje može postojati nekoliko timova, tu će puno pomoći standardizacija na razini cijele tvrtke, jer ako se 50 različitih uslužnih programa koristi u 50 timova, to znači da ih SRE mora poznavati svi. I naravno da se to nikada neće dogoditi. I kvaliteta rada, kvaliteta kontrole barem nekih timova značajno će se smanjiti.
Naš webinar se bliži kraju. Uspio sam reći neke osnovne stvari. Naravno, ništa se o SRE ne može reći i razumjeti u sat vremena. Ali nadam se da sam uspio prenijeti ovaj način razmišljanja, glavne ključne točke. A onda će biti moguće, ako bude zainteresiran, zadubiti se u temu, učiti sam, pogledati kako to provode drugi ljudi, u drugim tvrtkama. I sukladno tome, početkom veljače dođite k nama u Slurm SRE.
Slurm SRE je trodnevni intenzivni tečaj koji će govoriti o ovome o čemu ja sada govorim, ali s mnogo više dubine, sa stvarnim slučajevima, s praksom, cijeli intenziv je usmjeren na praktičan rad. Ljudi će biti podijeljeni u timove. Svi ćete raditi na stvarnim slučajevima. Sukladno tome, imamo Booking.com instruktore Ivana Kruglova i Bena Tylera. Imamo divnog Eugenea Barabu iz Googlea, iz San Francisca. A reći ću ti i nešto. Stoga nas svakako posjetite.
Dakle, bibliografija. Postoje reference na SRE. na istoj knjizi, odnosno na 2 knjige o SRE, koje je napisao Google. Još jedan , gdje su pojmovi i njihova primjena nešto detaljniji. Sljedeća 3 su izvješća o SRE u različitim tvrtkama. Prvo - , ovo je uvodna riječ Bena Trainera iz Googlea. drugo - . Treći je opet . Četvrto izvješće iz , koja ima samo 5 ključnih SRE zaposlenika u 190 zemalja. Vrlo je zanimljivo gledati na sve ovo, jer baš kao što DevOps znači vrlo različite stvari za različite tvrtke, pa čak i različite timove, SRE ima vrlo različite odgovornosti, čak iu tvrtkama slične veličine.
Još 2 linka o principima inženjeringa kaosa: , . I na kraju su 3 liste iz serije Awesome Lists about , oko i otprilike . Popis na SRE je nevjerojatno velik, nije ga potrebno cijelog pregledavati, ima oko 200 članaka. Toplo preporučam tamošnje članke o planiranju kapaciteta i o besprijekornom postmortemu.
Zanimljiv članak:
Hvala vam što ste me slušali sve ovo vrijeme. Nadam se da ste nešto naučili. Nadam se da imate dovoljno materijala da naučite još više. I vidimo se. Nadamo se u veljači.
Webinar je vodio Eduard Medvedev.
PS: za one koji vole čitati, Eduard je dao popis referenci. Oni koji više vole razumjeti u praksi su dobrodošli .
Izvor: www.habr.com