Webinar ima loš zvuk, pa smo napravili transkript.
Moje ime je Medvedev Eduard. Danas ću govoriti o tome šta je SRE, kako se SRE pojavio, koji su kriterijumi rada za SRE inženjere, malo o kriterijumima pouzdanosti, malo o njegovom praćenju. Preci ćemo preko vrha, jer za sat vremena ne možete puno reći, ali dat ću vam materijale na dodatni pregled, a svi vas čekamo na . u Moskvi krajem januara.
Prvo, hajde da razgovaramo o tome šta je SRE - Inženjering pouzdanosti sajta. I kako se to pojavilo kao posebna pozicija, kao poseban pravac. Sve je počelo č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 uvođenje novih funkcija kako bi se zadovoljile poslovne potrebe. Cilj Ops tima je osigurati da sve funkcionira i da se ništa ne pokvari. Očigledno, ovi ciljevi su direktno u suprotnosti jedni s drugima: kako bi sve funkcioniralo i da se ništa ne pokvarilo, bolje je što je manje moguće uvoditi nove funkcije. Zbog toga nastaju mnogi interni sukobi koje pokušava riješiti metodologija koja se sada zove DevOps.
Problem je što nemamo jasnu definiciju DevOps-a i jasnu implementaciju DevOps-a. Govorio sam na konferenciji u Jekaterinburgu pre 2 godine, a do sada je DevOps sekcija počinjala sa izveštajem „Šta je DevOps“. Devops je 2017. godine star skoro 10 godina, ali se još uvijek svađamo šta je to. I ovo je vrlo čudna situacija koju je Google pokušao riješiti prije nekoliko godina.
Google je 2016. godine objavio knjigu pod nazivom „Inženjering pouzdanosti sajta“. I zapravo, ovom knjigom je započeo SRE pokret. SRE je specifična opcija za implementaciju DevOps paradigme u određenoj kompaniji. SRE inženjeri su sebi postavili cilj da osiguraju pouzdan rad sistema. Uglavnom se preuzimaju od programera, ponekad od administratora sa jakim razvojnim iskustvom. I rade ono što su radili sistem administratori, ali jaka pozadina u razvoju i poznavanje sistema sa kodne tačke gledišta 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, ista veza između Deva i Opsa o kojoj ljudi pričaju već 8 godina. Uloga SRE je slična onoj arhitekte u tome što početnici ne postaju SRE. Ljudi na početku svoje karijere još nemaju nikakvog iskustva i nemaju potrebnu širinu znanja. Zato što SRE zahteva veoma sofisticirano znanje o tome šta tačno i kada tačno može poći po zlu. Stoga je ovdje potrebno neko iskustvo, po pravilu, kako unutar kompanije, tako i izvan nje.
Pitaju hoće li biti opisana razlika između SRE i devopsa. Ona je upravo opisana. Možemo govoriti o mjestu SRE u organizaciji. Za razliku od klasičnog DevOps pristupa, gdje je Ops još uvijek zasebno odjeljenje, SRE je dio razvojnog tima. Oni su uključeni u razvoj proizvoda. Postoji čak i pristup u kojem je SRE uloga koja prelazi sa jednog programera na drugog. Oni sudjeluju u pregledima koda na isti način kao, na primjer, UX dizajneri, sami programeri, a ponekad i menadžeri proizvoda. SRE rade na istom nivou. Trebamo njihovo odobrenje, trebamo njihovu reviziju, tako da za svaku implementaciju SRE kaže: „U redu, ova implementacija, ovaj proizvod neće negativno utjecati na pouzdanost. A ako i bude, to će biti u nekim prihvatljivim granicama.” Pričaćemo i o ovome.
Shodno tome, SRE ima pravo veta na promjene koda. I općenito, ovo također dovodi do malog konflikta ako se SRE implementira pogrešno. U toj knjizi o inženjeringu pouzdanosti sajta, mnogi delovi, čak i više od jednog, govore kako da izbegnete ove konflikte.
Ljudi pitaju kako se SRE odnosi na sigurnost informacija. SRE nije direktno uključen u sigurnost informacija. Uglavnom u velikim kompanijama to rade pojedinci, testeri i analitičari. Ali SRE također stupa u interakciju s njima u smislu da neke operacije, neke obaveze, neke implementacije koje utiču na sigurnost također mogu utjecati na dostupnost proizvoda. Stoga, SRE općenito ima interakciju sa svim timovima, uključujući sigurnosne timove, uključujući analitičare. Stoga su SRE-ovi uglavnom potrebni kada se pokušava implementirati DevOps, ali opterećenje za programere postaje preveliko. Odnosno, sam razvojni tim se više ne može nositi s činjenicom da sada moraju biti odgovorni i za Ops. I pojavljuje se posebna uloga. Ova uloga je planirana u budžetu. Ponekad je ova uloga ugrađena u veličinu tima, pojavljuje se posebna osoba, ponekad to postaje jedan od programera. Ovako se pojavljuje prvi SRE u timu.
Složenost sistema na koju utiče SRE, složenost koja utiče na operativnu pouzdanost, može biti neophodna ili slučajna. Neophodna složenost je kada se složenost proizvoda povećava u onoj mjeri koju zahtijevaju nove karakteristike proizvoda. Slučajna složenost je kada se kompleksnost sistema povećava, ali karakteristike proizvoda i poslovni zahtjevi ne utiču direktno na to. Ispada da je ili programer negdje pogriješio, ili algoritam nije optimalan, ili su uvedeni neki dodatni interesi koji nepotrebno povećavaju složenost proizvoda. Dobar SRE uvijek treba izbjegavati ovu situaciju. Odnosno, svako urezivanje, bilo koja implementacija, svaki zahtjev za povlačenjem koji povećava složenost zbog nasumičnih dodataka treba biti blokiran.
Pitanje je zašto jednostavno ne angažovati inženjera, sistem administratora sa mnogo znanja, da se pridruži timu. Programer u ulozi inženjera, kažu nam, nije najoptimalnije kadrovsko rješenje. Programer u ulozi inženjera nije uvijek optimalno kadrovsko rješenje, ali stvar je u tome da programer koji se bavi operacijama ima malo više želje za automatizacijom, ima malo više znanja i vještina kako bi to implementirao. automatizacija. I shodno 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). Tako, a o tome ćemo nešto kasnije, uštedjeti novac za organizaciju.
Hajde sada da razgovaramo o kriterijumima za rad SRE. I prije svega o pouzdanosti. U malim kompanijama i startupima često se dešava da ljudi pretpostavljaju da ako je usluga dobro napisana, ako je proizvod napisan dobro i ispravno, da će raditi, neće se pokvariti. To je to, pišemo dobar kod, tako da nema šta da se pokvari. Kod je vrlo jednostavan, nema šta da se razbije. To su otprilike isti ljudi koji kažu da nam testovi ne trebaju, jer gle, ovo su tri VPI metode, čemu se mučiti?
Ovo je sve pogrešno, naravno. I ovi ljudi se vrlo često povrijede ovakvim kodom u praksi, jer se stvari pokvare. Stvari se ponekad lome na najnepredvidljivije načine. Ponekad ljudi kažu ne, to se nikada neće dogoditi. I to se još uvijek dešava. Događa se prilično često. I zato niko nikada ne teži 100% dostupnosti, jer 100% dostupnosti se nikada ne dešava. Ovo je norma. I zato uvijek govorimo o devetkama kada govorimo o dostupnosti usluga. 2 devetke, 3 devetke, 4 devetke, 5 devetke. Ako ovo prevedemo u vrijeme zastoja, onda je, na primjer, 5 devetki nešto više od 5 minuta zastoja godišnje, 2 devetke su 3,5 dana zastoja.
Ali očigledno je da u nekom trenutku dolazi do smanjenja POI i povrata ulaganja. Prelazak sa dvije devetke na tri devetke znači smanjenje zastoja za više od 3 dana. Prelazak sa četiri devet na pet smanjuje vrijeme zastoja za 47 minuta godišnje. I ispostavilo se da to možda nije kritično za poslovanje. I općenito, tražena pouzdanost nije tehničko pitanje, prije svega, to je poslovno pitanje, to je pitanje proizvoda. Koji nivo zastoja je prihvatljiv za korisnike proizvoda, šta očekuju, koliko plaćaju, na primjer, koliko novca gube, koliko novca gubi sistem.
Važno pitanje je kolika je pouzdanost preostalih komponenti. Jer razlika između 4 i 5 devetke neće biti vidljiva na pametnom telefonu sa 2 devetke pouzdanosti. Grubo govoreći, ako se nešto pokvari na pametnom telefonu u vašem servisu 10 puta godišnje, najvjerovatnije 8 puta se kvar dogodio na strani OS-a. Korisnik je na to navikao i neće obraćati pažnju na to još jednom godišnje. Potrebno je uporediti cijenu povećanja pouzdanosti i povećanja profita.
Upravo u knjizi o SRE-u postoji dobar primjer povećanja na 4 devetke sa 3 devetke. Pokazalo se da je povećanje dostupnosti nešto manje od 0,1%. A ako je prihod usluge 1 milion dolara godišnje, onda je povećanje prihoda 900 dolara. Ako nas povećanje dostupnosti za devet košta manje od 900 dolara godišnje, povećanje ima finansijskog smisla. Ako košta više od 900 dolara godišnje, to više nema smisla, jer povećanje prihoda jednostavno ne nadoknađuje troškove rada i resursa. I 3 devetke će nam biti dovoljne.
Ovo je naravno pojednostavljeni primjer gdje su svi zahtjevi jednaki. A sa 3 devetke na 4 devetke prilično je lako ići, ali u isto vrijeme, na primjer, prelazak sa 2 devetke na 3 je već ušteda od 9 hiljada dolara, može imati financijskog smisla. Naravno, u stvarnosti, neuspjeh registracije zahtjeva je gori od neuspjeha da se prikaže stranica; zahtjevi imaju različite težine. Oni mogu imati potpuno različite kriterije s poslovnog gledišta, ali ipak, u pravilu, ako ne govorimo o nekim konkretnim uslugama, ovo je prilično pouzdana aproksimacija.
Dobili smo pitanje da li je SRE jedan od koordinatora prilikom odabira arhitektonskog rješenja za uslugu. To je prihvatljivo u smislu integracije u postojeću infrastrukturu kako ne bi došlo do gubitka njene stabilnosti. Da, SRE-ovi utiču na pull zahteve, urezivanja, izdanja na isti način; utiču na arhitekturu, implementaciju novih servisa, mikroservisa i implementaciju novih rešenja. Zašto sam prije rekao da vam treba iskustvo, potrebne su vam kvalifikacije. U stvari, SRE je jedan od blokirajućih glasova u svakom arhitektonskom i softverskom rješenju. Shodno tome, SRE kao inženjer mora, prije svega, ne samo razumjeti, već i razumjeti kako će neke konkretne odluke utjecati na pouzdanost, stabilnost, te razumjeti kako se to odnosi na poslovne potrebe i s koje tačke gledišta to može biti dozvoljeno, a sa kojim nije.
Stoga je sada vrijeme da govorimo o kriterijima pouzdanosti, koji se u SRE tradicionalno definiraju kao SLA (Service Level Agreement). Najvjerovatnije poznat izraz. SLI (Indikator nivoa usluge). SLO (Cilj razine usluge). Ugovor o nivou usluge je možda značajan pojam, posebno ako ste radili sa mrežama, provajderima i hostingom. Ovo je opšti ugovor koji opisuje performanse vaše celokupne usluge, kazne, neke kazne za greške, metrike, kriterijume. A SLI je sama metrika pristupačnosti. Odnosno, šta SLI može biti: vrijeme odgovora servisa, broj grešaka u postocima. Ovo bi mogao biti propusni opseg ako govorimo o nekoj vrsti hostinga datoteka. Ako govorimo o algoritmima za prepoznavanje, indikator može biti čak, na primjer, tačnost odgovora. SLO (Service Level Objective) je, odnosno, kombinacija SLI indikatora, njegove vrijednosti i perioda.
Recimo da bi SLA mogao biti ovakav. Usluga je dostupna 99,95% vremena tokom cijele godine. Ili će 99 tiketa za kritičnu tehničku podršku biti zatvoreno u roku od 3 sata po kvartalu. Ili će na 85% upita biti odgovoreno u roku od 1,5 sekunde svakog mjeseca. Odnosno, postepeno shvatamo da su greške i kvarovi sasvim normalni. Ovo je prihvatljiva situacija, mi to planiramo, čak donekle i računamo na to. Odnosno, SRE gradi sisteme koji mogu napraviti greške, koji moraju normalno reagirati na greške i koji ih moraju uzeti u obzir. I ako je moguće, trebali bi postupati s greškama na način da ih korisnik ili ne primijeti, ili ih primijeti, ali postoji neka vrsta rješenja da se sve ne raspadne u potpunosti.
Na primjer, ako postavite video na YouTube, a YouTube ga ne može odmah konvertirati, ako je video prevelik, ako format nije optimalan, onda zahtjev naravno neće uspjeti s timeoutom, YouTube neće prikazati 502 greška, YouTube će reći: „Sve smo kreirali, vaš video se obrađuje. Biće spreman za oko 10 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 veoma važni za rad sa pouzdanošću, sa greškama, sa 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 potpuno normalan rad. MTBF se uglavnom koriguje radom na kvalitetu koda. To jest, činjenica da SRE mogu reći „ne“. I cijeli tim treba da shvati da kada SRE kaže „ne“, on to ne kaže zato što je štetan, ne zato što je loš, već zato što će u suprotnom svi patiti.
Opet, postoji puno članaka, mnogo metoda, mnogo načina, čak iu samoj knjizi na koju se često pozivam, kako se pobrinuti da drugi programeri ne počnu mrzeti SRE. MTTR se, s druge strane, odnosi na rad na vašem SLO (Service Level Cilj). I to je uglavnom automatizacija. Jer, na primjer, naš SLO je produženje rada od 4 devetke po kvartalu. To znači da za 3 mjeseca možemo dozvoliti 13 minuta zastoja. I ispostavilo se da naš MTTR nikako ne može biti duži od 13 minuta. Ako nam je potrebno 13 minuta da reagujemo na barem 1 zastoj, to znači da smo već potrošili cijeli budžet za tromjesečje. Kršimo SLO. 13 minuta da se reaguje i ispravi kvar je mnogo za mašinu, ali jako malo za čoveka. Jer do trenutka kada osoba primi upozorenje, dok reaguje, dok shvati grešku, to je već nekoliko minuta. Dok čovjek ne shvati kako to popraviti, šta točno popraviti, šta treba učiniti, trebat će još nekoliko minuta. I u stvari, čak i ako samo trebate ponovo pokrenuti server, kako se ispostavilo, ili podići novi čvor, onda MTTR ručno traje oko 7-8 minuta. Prilikom automatizacije procesa, MTTR vrlo često doseže sekundu, ponekad i milisekunde. Google obično govori o milisekundama, ali u stvarnosti, naravno, stvari nisu tako dobre.
U idealnom slučaju, SRE bi trebao gotovo potpuno automatizirati svoj rad, jer to direktno utječe na MTTR, njegove metrike, SLO cjelokupne usluge i, shodno tome, poslovni profit. Ako se vrijeme prekorači, pitamo se da li je za to kriv SRE. Srećom, krivica se ne svaljuje na nikome. A ovo je posebna kultura, koja se zove postmortem bez balmeza, o kojoj danas nećemo govoriti, već ćemo analizirati u Slurmu. Ovo je veoma interesantna tema o kojoj se može mnogo pričati. Grubo govoreći, ako se prekorači predviđeno vrijeme po kvartalu, onda su svi pomalo krivi, što znači da okrivljavanje svih nije produktivno, hajde da umjesto toga, možda, ne krivimo nikoga, nego ispravimo situaciju i radimo sa onim što imamo. Prema mom iskustvu, ovaj pristup je malo stran većini timova, posebno u Rusiji, ali ima smisla i funkcionira jako dobro. Stoga ću na kraju preporučiti članke i literaturu koju možete pročitati na ovu temu. Ili dođite u Slurm SRE.
Dopusti mi da objasnim. Ako je SLO vrijeme za kvartal prekoračeno, ako zastoj nije bio 13 minuta, već 15, ko može biti kriv za to? Naravno, SRE može biti kriv zato što je očito napravio neko loše preuzimanje ili raspoređivanje. Za to je možda kriv administrator data centra, jer je možda izvršio neko neplanirano održavanje. Ako je za to kriv administrator data centra, onda je kriva i osoba iz Opsa što nije obračunavala održavanje pri dogovaranju SLO. Za to je kriv menadžer, tehnički direktor ili neko ko je potpisao ugovor o data centru, a nije obratio pažnju na to da SLA data centra nije dizajniran za potrebno vrijeme zastoja. Shodno tome, svi su pomalo krivi za ovu situaciju. A to znači da nema smisla okrivljavati bilo koga posebno za ovu situaciju. Ali naravno to treba ispraviti. Zato postoje obdukcije. A ako čitate, na primjer, GitHub postmortems, a ovo je uvijek vrlo zanimljiva, mala i neočekivana priča u svakom konkretnom slučaju, možete zamijeniti da niko nikada ne kaže da je ta osoba kriva. Okrivljavanje se uvijek stavlja na specifične procese s nedostatkom.
Idemo na sljedeće pitanje. Automatizacija. Obično, kada govorim o automatizaciji u drugim kontekstima, vrlo često se pozivam na tabelu koja govori o tome koliko dugo možete raditi na automatizaciji zadatka kako ne biste oduzimali više vremena za automatizaciju nego što općenito uštedite. Postoji kvaka. Kvaka je u tome što kada SRE automatizuju zadatak, ne samo da štede vreme, već štede i novac jer automatizacija direktno utiče na MTTR. Oni štede, da tako kažem, moral zaposlenih i programera, što je takođe neiscrpan resurs. Oni smanjuju rutinu. A sve to ima pozitivan učinak na rad i, kao rezultat, na poslovanje, čak i ako se čini da automatizacija nema smisla u smislu vremenskih troškova.
U stvari, gotovo uvijek je tako, a vrlo je malo slučajeva u kojima ne vrijedi automatizirati nešto u SRE ulozi. Dalje ćemo govoriti o onome što se zove budžet za greške, budžet za greške. Zapravo, ispada da ako radite znatno bolje od SLO-a koji ste sebi zadali, to također nije dobro. Ovo je prilično loše, jer SLO radi ne samo kao donja granica, već i kao približna gornja granica. Kada sebi postavite SLO od 99% dostupnosti, a zapravo imate 99,99%, ispada da imate prostora za eksperimentiranje, što neće nimalo štetiti poslu, jer ste sami to sve zajedno odredili, a vi imati ovaj prostor nemojte ga koristiti. Imate budžet za greške, koji se u vašem slučaju ne troši.
Šta radimo s tim? Koristimo ga bukvalno za sve. Za testiranje u proizvodnim uslovima, za uvođenje novih funkcija koje mogu uticati na performanse, za izdanja, za održavanje, za planirane zastoje. Vrijedi i suprotno pravilo: ako je budžet iscrpljen, ne možemo objaviti ništa novo, jer ćemo u suprotnom premašiti SLO. Budžet je već potrošen, nešto smo pustili, ako to negativno utječe na performanse, odnosno ako nije neka popravka koja sama po sebi direktno povećava SLO, onda prelazimo budžet i ovo je loša situacija , zahtijeva analizu, postmortem i eventualno neke korekcije procesa.
Odnosno, ispada da ako sama usluga ne radi dobro, a SLO se troši i budžet se troši ne na eksperimente, ne na bilo koje izdanje, već na sam sebe, onda umjesto nekih zanimljivih popravki, umjesto zanimljivih funkcije, umjesto zanimljivih izdanja. Umjesto da se bavite bilo kakvim kreativnim radom, morat ćete raditi glupe popravke kako biste doveli budžet u red, ili uređivati SLO, a to je također proces koji se ne bi trebao događati prečesto.
Dakle, ispada da su u situaciji kada imamo više budžeta za greške svi zainteresovani: i SRE i programeri. Za programere, veliki budžet za greške znači da se mogu nositi s izdanjima, testovima i eksperimentima. Za SRE, budžet za greške i ulazak u ovaj budžet znači da oni zapravo rade dobar posao. A to utiče na motivaciju neke vrste zajedničkog rada. Ako slušate svoje SRE kao programeri, imat ćete više prostora za dobar posao i mnogo manje poslova.
Pokazalo se da su eksperimenti u proizvodnji prilično važan i gotovo sastavni dio SRE u velikim timovima. I obično ide pod nazivom chaos engineering, koji dolazi od tima u Netflixu koji je objavio uslužni program pod nazivom Chaos Monkey.
Chaos Monkey se povezuje na CI/CD cevovod i nasumično ruši server u proizvodnji. Opet, u SRE strukturi kažemo da srušeni server sam po sebi nije loš, to je očekivano. A ako je to u budžetu, to je prihvatljivo i ne šteti poslovanju. Naravno, Netflix ima dovoljno redundantnih servera, dovoljno replikacije, da se sve to može popraviti, a da korisnik u cjelini i ne primijeti, a svakako da niko ne napušta jedan server za bilo koji budžet.
Netflix je svojevremeno imao čitav niz takvih uslužnih programa, od kojih jedan, Chaos Gorilla, potpuno onemogućava jednu od zona dostupnosti na Amazonu. I takve stvari dobro pomažu da se identifikuju, prvo, skrivene zavisnosti, kada nije sasvim jasno šta na šta utiče, šta zavisi od čega. A ovo, ako radite sa mikroservisom i dokumentacija nije sasvim savršena, ovo vam je možda poznato. I opet, ovo pomaže da se uhvate greške u kodu koje ne možete uhvatiti tokom insceniranja, jer bilo koje insceniranje nije precizna simulacija, zbog činjenice da je skala opterećenja drugačija, obrazac opterećenja je drugačiji, oprema je također, većina vjerovatno, drugo. Vršna opterećenja također mogu biti neočekivana i nepredvidiva. A takvo testiranje, koje opet ne ide dalje od budžeta, vrlo dobro pomaže u hvatanju grešaka u infrastrukturi koje infrastrukturno postavljanje, autotestovi i CI/CD kanali nikada neće uhvatiti. I dokle god je sve to uključeno u vaš budžet, nema veze što vam je usluga tu pala, iako bi se činilo vrlo zastrašujuće, server se srušio, kakva noćna mora. Ne, to je normalno, to je dobro, pomaže u otkrivanju grešaka. Ako imate budžet, možete ga potrošiti.
Pitanje: koju literaturu mogu preporučiti? Lista je na kraju. Ima dosta literature, preporučio bih nekoliko izvještaja. Kako funkcioniše i da li SRE radi u kompanijama bez sopstvenog softverskog proizvoda ili sa minimalnim razvojem. Na primjer, u preduzeću, gdje glavna djelatnost nije softver. U preduzeću, gde osnovna delatnost nije softver, SRE funkcioniše potpuno isto kao i bilo gde drugde, jer u preduzeću takođe morate da koristite, čak i ako ne razvijate, softverske proizvode, morate da uvedete ažuriranja, morate promijeniti infrastrukturu, morate rasti, trebate skalirati. A SRE pomažu u identifikaciji i predviđanju mogućih problema u ovim procesima i kontrolišu ih nakon početka rasta i promjene poslovnih potreba. Jer apsolutno nije potrebno baviti se razvojem softvera da biste imali SRE, ako imate barem nekoliko servera i očekujete barem neki rast.
Isto važi i za male projekte, male organizacije, jer velike kompanije imaju budžet i prostor za eksperimentisanje. Ali u isto vrijeme, svi ovi plodovi eksperimenata mogu se koristiti bilo gdje, odnosno SRE su se, naravno, pojavili u Googleu, Netflixu i Dropboxu. Ali u isto vrijeme, male kompanije i startupi već mogu čitati sažeti materijal, čitati knjige i gledati izvještaje. Počinju češće da čuju o tome, pogledaju konkretne primjere, mislim, ok, ovo stvarno može biti korisno, treba nam i ovo, super.
Odnosno, sav glavni posao na standardizaciji ovih procesa je već obavljen za vas. Sve što treba da uradite je da definišete ulogu SRE konkretno u vašoj kompaniji i da počnete da realno implementirate sve ove prakse, koje su, opet, već opisane. Odnosno, od korisnih principa za male kompanije, ovo je uvijek definicija SLA, SLI, SLO. Ako niste uključeni u softver, onda će to biti interni SLA i interni SLO, interni budžet za greške. To gotovo uvijek dovede do nekih zanimljivih diskusija unutar tima i unutar biznisa, jer se može ispostaviti da trošite mnogo više nego što je potrebno na infrastrukturu, na nekakvu organizaciju idealnih procesa, idealan pipeline. A ove 4 devetke koje imate u IT odjelu, sada vam baš i ne trebaju. Ali u isto vrijeme, bilo je moguće potrošiti vrijeme, potrošiti budžet za greške na nešto drugo.
Shodno tome, praćenje i organizacija monitoringa je korisna za kompaniju 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 kompaniju bilo koje veličine, počevši od startupa od 3 osobe.
Posljednja od tehničkih nijansi o kojima možemo govoriti je praćenje. Jer ako govorimo o SLA, SLI, SLO, ne možemo razumjeti bez praćenja da li se uklapamo u budžet, da li ispunjavamo svoje ciljeve i kako utičemo na konačni SLA. Mnogo puta sam primetio da se praćenje dešava na sledeći način: postoji neka vrednost, na primer, vreme zahteva prema serveru, prosečno vreme ili broj zahteva prema bazi podataka. Ima standard koji je odredio inžinjer. Ako metrika odstupa od norme, šalje se email. Sve je to, po pravilu, apsolutno beskorisno, jer dovodi do takve prezasićenosti upozorenja, prezasićenosti poruka praćenja, kada ih osoba, prvo, svaki put mora interpretirati, odnosno utvrditi da li metrička vrijednost znači potrebu za neka vrsta akcije. I drugo, on jednostavno prestaje da primjećuje sva ova upozorenja, kada se u osnovi ne traži ništa od njega. Odnosno, dobro pravilo praćenja i prvo pravilo pri implementaciji SRE je da obavještenje treba doći samo kada je potrebna radnja.
U standardnom slučaju postoje 3 nivoa događaja. Postoje upozorenja, postoje karte, postoje zapisnici. Upozorenja su sve što zahtijeva hitnu akciju od vas. Odnosno, sve je pokvareno, to treba odmah popraviti. Karte su nešto što zahtijeva radnju na čekanju. Da, morate nešto da uradite, nešto morate da uradite ručno, automatizacija je zakazala, ali ne morate to da uradite u narednih nekoliko minuta. Dnevnici su sve ono što ne zahtijeva radnju, i općenito, ako stvari idu dobro, niko ih nikada neće pročitati. Logove će biti potrebno pročitati tek kada se, gledajući unazad, ispostavi da je neko vrijeme nešto pokvareno, a mi za to nismo znali. Ili je potrebna neka vrsta istrage. Ali općenito, sve što ne zahtijeva nikakvu radnju ide u dnevnike.
Kao nuspojava svega ovoga, ako smo identificirali koji događaji zahtijevaju radnje i dobro opisali koje bi te radnje trebale biti, to znači da se radnja može automatizirati. Odnosno, šta se dešava. Dolazimo iz uzbune. Idemo u akciju. Idemo na opis ove akcije. A onda idemo ka automatizaciji. Odnosno, svaka automatizacija počinje reakcijom na događaj.
Od praćenja prelazimo na termin koji se zove Opservabilnost. Posljednjih nekoliko godina također je bilo malo hajma oko ove riječi. I malo ljudi razumije šta ovo znači van konteksta. Ali glavna stvar je da je Opservabilnost metrika transparentnosti sistema. Ako je nešto pošlo po zlu, koliko brzo možete utvrditi šta je tačno pošlo po zlu i kakvo je bilo stanje sistema u tom trenutku. Sa stanovišta koda: koja funkcija nije uspjela, koja usluga nije uspjela. Kakvo je bilo stanje, na primjer, internih varijabli, konfiguracije. Sa infrastrukturne tačke gledišta, ovo je u kojoj zoni dostupnosti je došlo do kvara, a ako imate neku vrstu Kubernetesa, u kom podu se desio kvar, u kakvom je stanju pod. I prema tome, Observability ima direktnu vezu sa MTTR. Što je veća uočljivost usluge, to je lakše identificirati grešku, lakše je popraviti grešku, lakše je automatizirati grešku, niži je MTTR.
Ako opet pređemo na male kompanije, vrlo često se i sada pitaju šta da rade sa veličinom tima i da li je potrebno u malom timu angažovati posebnog SRE. O tome sam već govorio malo ranije. U prvim fazama razvoja startupa ili, na primjer, tima, to uopće nije potrebno, jer SRE može postati prelazna uloga. I ovo će malo oživjeti ekipu, jer postoji bar neka raznolikost. Osim toga, to će pripremiti ljude na činjenicu da će se, kako rastu, generalno, odgovornosti SRE-a vrlo značajno promijeniti. Ako zaposlite osobu, onda, naravno, ima neka očekivanja. I ova očekivanja se neće promijeniti tokom vremena, ali će se zahtjevi jako promijeniti. Stoga je zapošljavanje SRE-a prilično teško u ranim fazama. Mnogo je lakše odgajati svoje. Ali vredi razmisliti.
Jedini izuzetak je vjerovatno kada postoje vrlo strogi i dobro definirani zahtjevi za visinu. Odnosno, u slučaju startupa, to može biti neka vrsta pritiska investitora, nekakva prognoza rasta nekoliko puta odjednom. Tada je zapošljavanje SRE općenito opravdano jer može biti opravdano. Imamo zahtjeve za rastom, potrebna nam je osoba koja će biti odgovorna da se ništa ne pokvari sa takvim rastom.
Još jedno pitanje. Šta učiniti kada programeri nekoliko puta iseku funkciju koja prolazi testove, ali pokvari proizvod, učita bazu podataka, razbije druge funkcije, koji proces implementirati. Shodno tome, u ovom slučaju se uvodi budžet za greške. I neke usluge, neke karakteristike se testiraju odmah u proizvodnji. Ovo može biti kanarinac, kada samo mali broj korisnika, ali već u produkciji, implementira neku funkciju, ali s očekivanjem da ako se nešto pokvari, na primjer, za pola posto svih korisnika, to će ipak stati u okvir budžet za greške. Shodno tome, da, doći će do greške, za neke korisnike će se sve pokvariti, ali smo već rekli da je to normalno.
Postojalo je pitanje o SRE alatima. Odnosno, postoji li nešto specifično što bi SRE koristili a svi ostali ne bi? U stvari, postoje neki visokospecijalizirani uslužni programi, postoji neki softver koji, na primjer, simulira opterećenja ili radi kanarsko A/B testiranje. Ali u osnovi, SRE alati su ono što vaši programeri već koriste. Zato što SRE direktno komunicira sa razvojnim timom. A ako imate različite alate, ispostavilo se da je potrebno vrijeme za sinhronizaciju. Naročito ako SRE rade u velikim timovima, u velikim kompanijama gdje može biti nekoliko timova, standardizacija za cijelu kompaniju će ovdje biti od velike pomoći, jer ako 50 timova koristi 50 različitih uslužnih programa, to znači da ih SRE mora poznavati sve. I naravno to se nikada neće dogoditi. I kvalitet rada, kvaliteta kontrole barem nekih timova će se značajno smanjiti.
Naš webinar se postepeno bliži kraju. Uspio sam vam reći neke osnovne stvari. Naravno, ništa o SRE se ne može reći i razumjeti za sat vremena. Ali nadam se da sam uspeo da prenesem ovaj način razmišljanja, glavne ključne tačke. A onda, ako ste zainteresovani, možete dublje ući u temu, samostalno proučiti i pogledati kako se to implementira od strane drugih ljudi, u drugim kompanijama. I shodno tome, početkom februara dođite kod nas u Slurm SRE.
Slurm SRE je trodnevni intenzivni kurs koji će otprilike pokriti ovo o čemu sada pričam, ali sa mnogo većom dubinom, sa stvarnim slučajevima, sa praksom, ceo intenziv je usmeren na praktičan rad. Ljudi će biti podijeljeni u timove. Svi ćete raditi na stvarnim slučajevima. U skladu s tim, imamo instruktore iz Booking.com-a Ivana Kruglova i Bena Tylera. Imamo divnog Evgenija Varabasa iz Gugla, iz San Francisca. I ja ću vam reći nešto. Zato nas svakako posjetite.
Dakle, lista referenci. Postoje linkovi na SRE. na istoj knjizi, odnosno na 2 knjige o SRE-u, koje je napisao Google. Drugi , gdje su termini i njihova primjena malo detaljnije objašnjeni. Sljedeća 3 su izvještaji o SRE u različitim kompanijama. Prvo - , ovo je ključna riječ Bena Trenera iz Googlea. Sekunda - . Treći je opet o . Četvrti izvještaj iz , koja ima samo 5 ključnih SRE zaposlenih u 190 zemalja. Vrlo je zanimljivo pogledati sve ovo, jer kao što DevOps znači veoma različite stvari različitim kompanijama, pa čak i različitim timovima, SRE ima veoma različite odgovornosti, čak i u kompanijama slične veličine.
Još 2 linka o principima haos inženjeringa: , . I na kraju su 3 liste iz serije Awesome Lists o , o i otprilike . Lista na SRE-u je nevjerovatno ogromna, ne morate sve prolaziti, ima oko 200 članaka. Toplo preporučujem članke o planiranju kapaciteta i besprijekornom postmortemu.
Zanimljiv članak:
Hvala vam što ste me slušali sve ovo vreme. Nadam se da ste nešto naučili. Nadam se da imate dovoljno materijala da naučite još više. I vidimo se kasnije. Nadam se u februaru.
Domaćin webinara bio je Eduard Medvedev.
PS: za one koji vole da čitaju, Eduard je dao listu referenci. Oni koji više vole da to shvate u praksi su dobrodošli .
izvor: www.habr.com