Webinář má špatný zvuk, takže jsme udělali přepis.
Jmenuji se Medveděv Eduard. Dnes budu mluvit o tom, co je SRE, jak se SRE objevil, jaká jsou pracovní kritéria pro inženýry SRE, trochu o kritériích spolehlivosti, trochu o jeho sledování. Půjdeme přes okraj, protože za hodinu toho moc neřekneš, ale dám ti materiály k dodatečné kontrole a všichni na tebe čekáme na . v Moskvě na konci ledna.
Nejprve si řekněme, co je SRE – Site Reliability Engineering. A jak se to jevilo jako samostatná pozice, jako samostatný směr. Všechno to začalo tím, že v tradičních vývojářských kruzích jsou Dev a Ops dva zcela odlišné týmy, obvykle se dvěma zcela odlišnými cíli. Cílem vývojového týmu je zavádět nové funkce, které splňují obchodní potřeby. Cílem týmu Ops je zajistit, aby vše fungovalo a nic se nerozbilo. Je zřejmé, že tyto cíle si přímo odporují: aby vše fungovalo a nic se nerozbilo, je lepší zavádět nové funkce co nejméně. Kvůli tomu vzniká mnoho vnitřních konfliktů, které se snaží řešit metodika nyní nazývaná DevOps.
Problém je, že nemáme jasnou definici DevOps a jasnou implementaci DevOps. Před 2 lety jsem hovořil na konferenci v Jekatěrinburgu a až dosud sekce DevOps začínala zprávou „Co je DevOps“. V roce 2017 je devops téměř 10 let, ale stále se dohadujeme, co to je. A to je velmi zvláštní situace, kterou se Google před pár lety snažil vyřešit.
V roce 2016 Google vydal knihu s názvem „Site Reliability Engineering“. A vlastně právě touto knihou začalo hnutí SRE. SRE je specifická možnost implementace paradigmatu DevOps v konkrétní společnosti. Inženýři SRE si dali za cíl zajistit spolehlivý provoz systémů. Jsou převzaty především od vývojářů, někdy od administrátorů se silným vývojářským zázemím. A dělají to, co dělali systémoví administrátoři, ale silné zázemí ve vývoji a znalost systému z pohledu kódu vede k tomu, že tito lidé neinklinují k běžné administrativní práci, ale inklinují k automatizaci.
Ukazuje se, že paradigma DevOps v týmech SRE je implementováno tím, že existují inženýři SRE, kteří řeší strukturální problémy. Tady to je, stejné spojení mezi Dev a Ops, o kterém lidé mluví už 8 let. Role SRE je podobná roli architekta v tom, že nováčci se nestávají SRE. Lidé na začátku své kariéry ještě nemají žádné zkušenosti a nemají požadovanou šíři znalostí. Protože SRE vyžaduje velmi sofistikovanou znalost toho, co a kdy přesně se může pokazit. Proto je zde zpravidla potřeba určitá zkušenost, a to jak uvnitř firmy, tak mimo ni.
Ptají se, zda bude popsán rozdíl mezi SRE a devops. Právě byla popsána. Můžeme mluvit o místě SRE v organizaci. Na rozdíl od klasického přístupu DevOps, kde je Ops stále samostatným oddělením, je SRE součástí vývojového týmu. Podílejí se na vývoji produktů. Existuje dokonce přístup, kdy SRE je role, která přechází z jednoho vývojáře na druhého. Podílejí se na code review stejně jako například UX designéři, samotní vývojáři a někdy i produktoví manažeři. SRE fungují na stejné úrovni. Potřebujeme jejich schválení, potřebujeme jejich kontrolu, aby SRE pro každé nasazení řeklo: „Dobře, toto nasazení, tento produkt neovlivní negativně spolehlivost. A pokud ano, bude to v nějakých přijatelných mezích.“ O tom si také povíme.
V souladu s tím má SRE právo veta na změny kódu. A obecně to také vede k malému konfliktu, pokud je SRE implementováno nesprávně. Právě v této knize o Site Reliability Engineering mnoho částí, dokonce více než jedna, říká, jak se těmto konfliktům vyhnout.
Lidé se ptají, jak SRE souvisí s bezpečností informací. SRE se přímo nepodílí na bezpečnosti informací. Většinou ve velkých společnostech to dělají jednotliví lidé, testeři a analytici. Ale SRE s nimi také interaguje v tom smyslu, že některé operace, některá potvrzení, některá nasazení, která ovlivňují zabezpečení, mohou také ovlivnit dostupnost produktu. Proto má SRE obecně interakci s jakýmikoli týmy, včetně bezpečnostních týmů, včetně analytiků. Proto jsou SRE potřeba hlavně při pokusu o implementaci DevOps, ale zátěž pro vývojáře je příliš velká. To znamená, že samotný vývojový tým se již nemůže vyrovnat s tím, že nyní musí být také zodpovědný za Ops. A objeví se samostatná role. Tato role je plánována v rozpočtu. Někdy je tato role zabudována do velikosti týmu, objeví se samostatná osoba, někdy se jí stane jeden z vývojářů. Tak se v týmu objevuje první SRE.
Složitost systému, která je ovlivněna SRE, složitost, která ovlivňuje provozní spolehlivost, může být nezbytná nebo náhodná. Nezbytná složitost je, když se složitost produktu zvýší do té míry, kterou nové vlastnosti produktu vyžadují. Náhodná složitost nastává, když se zvyšuje složitost systému, ale funkce produktu a obchodní požadavky to přímo neovlivňují. Ukazuje se, že buď vývojář někde udělal chybu, nebo algoritmus není optimální, nebo jsou zavedeny nějaké další zájmy, které zbytečně zvyšují složitost produktu. Dobrý SRE by se měl této situaci vždy vyhnout. To znamená, že jakékoli potvrzení, jakékoli nasazení, jakýkoli požadavek na stažení, který zvyšuje složitost kvůli náhodným přidáním, by měl být blokován.
Otázkou je, proč si do týmu nenajmout inženýra, systémového administrátora s mnoha znalostmi. Vývojář v roli inženýra prý není nejoptimálnější personální řešení. Vývojář v roli inženýra není vždy optimální personální řešení, ale jde o to, že vývojář, který se zabývá Ops, má trochu více touhy po automatizaci, má trochu více znalostí a dovedností, aby to mohl implementovat. automatizace. A podle toho zkracujeme nejen čas na některé specifické operace, nejen rutinní, ale i tak důležité obchodní parametry, jako je MTTR (Mean Time To Recovery, recovery time). Tím, a také o tom budeme mluvit o něco později, šetříme peníze na organizaci.
Nyní si promluvme o kritériích pro práci SRE. A v první řadě o spolehlivosti. V malých firmách a startupech se často stává, že lidé předpokládají, že když je služba dobře napsaná, když je produkt dobře a správně napsaný, bude fungovat, nerozbije se. To je vše, píšeme dobrý kód, takže není co rozbíjet. Kód je velmi jednoduchý, není co rozbíjet. Jsou to asi stejní lidé, kteří říkají, že nepotřebujeme testy, protože, podívejte, to jsou tři metody VPI, proč se obtěžovat?
To všechno je samozřejmě špatně. A tito lidé jsou tímto druhem kódu v praxi velmi často zraněni, protože se věci pokazí. Věci se někdy zlomí tím nejnepředvídatelnějším způsobem. Někdy lidé říkají ne, to se nikdy nestane. A stále se to děje. Stává se to docela často. A to je důvod, proč nikdo nikdy neusiluje o 100% dostupnost, protože 100% dostupnost nikdy nenastane. To je norma. A to je důvod, proč vždy mluvíme o devítkách, když mluvíme o dostupnosti služeb. 2 devítky, 3 devítky, 4 devítky, 5 devítek. Pokud to převedeme na dobu prostojů, tak například 5 devítek je o něco více než 5 minut prostoje za rok, 2 devítky jsou 3,5 dne prostoje.
Je ale zřejmé, že v určitém okamžiku dochází k poklesu POI a návratnosti investic. Přechod ze dvou devítek na tři devítky znamená snížení prostojů o více než 3 dny. Přechod ze čtyř devítek na pět snižuje prostoje o 47 minut ročně. A ukazuje se, že to nemusí být pro podnikání kritické. A obecně, požadovaná spolehlivost není technický problém, v první řadě je to obchodní záležitost, je to otázka produktu. Jaká míra prostojů je pro uživatele produktu přijatelná, co očekávají, kolik například platí, o kolik peněz přijdou, o kolik peněz přijde systém.
Důležitou otázkou je, jaká je spolehlivost zbývajících komponentů. Protože rozdíl mezi 4 a 5 devítkami nebude na smartphonu se 2 spolehlivostními devítkami vidět. Zhruba řečeno, pokud se něco porouchá na smartphonu ve vašich službách 10krát za rok, pravděpodobně 8krát došlo k poruše na straně OS. Uživatel je na to zvyklý a nebude tomu věnovat pozornost jednou za rok navíc. Je třeba porovnávat cenu zvyšující se spolehlivosti a rostoucích zisků.
Právě v knize o SRE je dobrý příklad zvýšení na 4 devítky ze 3 devítek. Ukazuje se, že nárůst dostupnosti je o něco menší než 0,1 %. A pokud jsou příjmy služby 1 milion $ ročně, pak nárůst příjmů je 900 $. Pokud nás zvýšení dostupnosti o devět stojí méně než 900 USD ročně, dává toto zvýšení finanční smysl. Pokud to stojí více než 900 dolarů ročně, už to nedává smysl, protože nárůst příjmů prostě nekompenzuje mzdové náklady a náklady na zdroje. A 3 devítky nám budou stačit.
Toto je samozřejmě zjednodušený příklad, kde jsou všechny požadavky stejné. A ze 3 devítek na 4 devítky je to docela snadné, ale zároveň například přechod z 2 devítek na 3 je již úspora 9 tisíc dolarů, to může dávat finanční smysl. Ve skutečnosti je samozřejmě nezaregistrování požadavku horší než nezobrazení stránky, požadavky mají různou váhu. Mohou mít z obchodního hlediska úplně jiná kritéria, ale i tak jde zpravidla, pokud nemluvíme o žádných konkrétních službách, o poměrně spolehlivou aproximaci.
Dostali jsme dotaz, zda je SRE jedním z koordinátorů při výběru architektonického řešení služby. To je přijatelné z hlediska integrace do stávající infrastruktury tak, aby nedocházelo ke ztrátě její stability. Ano, SRE ovlivňují požadavky na stahování, potvrzení, vydání stejným způsobem; ovlivňují architekturu, implementaci nových služeb, mikroslužeb a implementaci nových řešení. Proč jsem předtím řekl, že potřebujete zkušenosti, potřebujete kvalifikaci. Ve skutečnosti je SRE jedním z blokujících hlasů v jakémkoli architektonickém a softwarovém řešení. V souladu s tím musí SRE jako inženýr především nejen pochopit, ale také pochopit, jak některá konkrétní rozhodnutí ovlivní spolehlivost, stabilitu, a pochopit, jak to souvisí s obchodními potřebami a z jakého hlediska to může být přípustné, a se kterými není.
Proto je nyní čas mluvit o kritériích spolehlivosti, která jsou v SRE tradičně definována jako SLA (Service Level Agreement). S největší pravděpodobností známý termín. SLI (Ukazatel úrovně služeb). SLO (Cíl úrovně služeb). Smlouva o úrovni služeb je možná důležitý pojem, zvláště pokud jste pracovali se sítěmi, poskytovateli a hostingem. Toto je obecná dohoda, která popisuje výkon celé vaší služby, sankce, některé sankce za chyby, metriky, kritéria. A SLI je samotná metrika přístupnosti. To znamená, co může být SLI: doba odezvy služby, počet chyb v procentech. To by mohla být šířka pásma, pokud mluvíme o nějakém hostování souborů. Pokud se bavíme o rozpoznávacím algoritmu, indikátorem může být například i správnost odpovědi. SLO (Service Level Objective) je kombinací ukazatele SLI, jeho hodnoty a periody.
Řekněme, že SLA by mohla být taková. Služba je dostupná 99,95 % času po celý rok. Nebo bude 99 kritických lístků technické podpory uzavřeno do 3 hodin za čtvrtletí. Nebo 85 % dotazů bude zodpovězeno do 1,5 sekundy každý měsíc. To znamená, že postupně začínáme chápat, že chyby a selhání jsou zcela normální. To je přijatelný stav, plánujeme to, dokonce s tím do jisté míry počítáme. To znamená, že SRE buduje systémy, které mohou dělat chyby, které musí normálně reagovat na chyby a které je musí brát v úvahu. A pokud možno by měli zacházet s chybami tak, aby si jich uživatel buď nevšiml, nebo si jich všimnul, ale existuje nějaké řešení, aby se vše nezhroutilo úplně.
Pokud například nahrajete video na YouTube a YouTube jej nemůže okamžitě převést, pokud je video příliš velké, pokud formát není optimální, pak požadavek přirozeně selže s časovým limitem, YouTube nezobrazí 502 Chyba, YouTube řekne: „Všechno jsme vytvořili, vaše video se zpracovává. Bude to hotové asi za 10 minut." Jedná se o princip ladné degradace, který je známý například z frontendového vývoje, pokud jste to někdy dělali.
Dalšími pojmy, o kterých si budeme povídat a které jsou velmi důležité pro práci se spolehlivostí, s chybami, s očekáváním, jsou MTBF a MTTR. MTBF je střední doba mezi poruchami. MTTR Mean Time To Recovery, průměrná doba do zotavení. Tedy kolik času uplynulo od okamžiku zjištění chyby, od okamžiku, kdy se chyba objevila, až do okamžiku, kdy byla služba obnovena do zcela normálního provozu. MTBF se koriguje hlavně prací na kvalitě kódu. To znamená, že SRE mohou říci „ne“. A celý tým musí pochopit, že když SRE říká „ne“, říká to ne proto, že je škodlivý, ne proto, že je špatný, ale protože jinak budou trpět všichni.
Opět je spousta článků, spousta metod, spousta způsobů, dokonce i v té knize, na kterou tak často odkazuji, jak zajistit, aby ostatní vývojáři nezačali SRE nenávidět. MTTR je na druhé straně o práci na vašem SLO (Service Level Objective). A to je většinou automatizace. Protože například naše SLO je uptime 4 devítky za čtvrtletí. To znamená, že za 3 měsíce můžeme povolit 13 minut výpadku. A ukázalo se, že naše MTTR nemůže být delší než 13 minut. Pokud si vezmeme 13 minut na reakci na alespoň 1 výpadek, znamená to, že jsme již vyčerpali celý rozpočet za čtvrtletí. Porušujeme SLO. 13 minut na reakci a nápravu poruchy je hodně pro stroj, ale velmi málo pro člověka. Protože v době, kdy člověk obdrží upozornění, v době, kdy zareaguje, v době, kdy zjistí chybu, je to již několik minut. Než člověk pochopí, jak to opravit, co přesně opravit, co udělat, bude to ještě pár minut trvat. A ve skutečnosti, i když potřebujete restartovat server, jak se ukázalo, nebo vytvořit nový uzel, pak MTTR ručně trvá asi 7-8 minut. Při automatizaci procesu MTTR velmi často dosahuje sekundy, někdy milisekund. Google obvykle mluví o milisekundách, ale ve skutečnosti to samozřejmě tak dobré není.
V ideálním případě by SRE měl svou práci téměř zcela automatizovat, protože to přímo ovlivňuje MTTR, jeho metriky, SLO celé služby a v důsledku toho i obchodní zisky. Pokud je čas překročen, jsme dotázáni, zda je vina na straně SRE. Naštěstí není vina na nikoho svalena. A to je samostatná kultura, která se nazývá balmeless postmortem, o které dnes nebudeme mluvit, ale rozebereme ji na Slurmu. To je velmi zajímavé téma, o kterém se dá hodně mluvit. Zhruba řečeno, pokud dojde k překročení stanoveného času za čtvrtletí, tak si za to mohou trochu všichni, to znamená, že obviňovat všechny není produktivní, raději to možná nikoho neobviňujme, ale napravme situaci a pracujme s tím, co máme. Podle mých zkušeností je tento přístup většině týmů, zejména v Rusku, trochu cizí, ale dává smysl a funguje velmi dobře. Proto na závěr doporučím články a literaturu, kterou si můžete na toto téma přečíst. Nebo přijďte do Slurm SRE.
Nech mě to vysvětlit. Pokud je překročena doba SLO za čtvrtletí, pokud prostoj nebyl 13 minut, ale 15, kdo za to může? Samozřejmě může být na vině SRE, protože zjevně provedlo nějaké špatné potvrzení nebo nasazení. Může za to správce datového centra, protože možná provedl nějakou neplánovanou údržbu. Pokud za to může správce datového centra, pak je na vině i člověk z Ops, že při domlouvání SLO nekalkuloval s údržbou. Může za to manažer, technický ředitel nebo někdo, kdo podepsal smlouvu o datovém centru a nevěnoval pozornost tomu, že SLA datového centra není dimenzováno na požadovaný výpadek. Každý si tedy za tuto situaci může tak trochu sám. A to znamená, že nemá smysl házet vinu na někoho konkrétního z této situace. Ale samozřejmě je potřeba to upravit. Proto existují postmortem. A pokud čtete například posmrtné zprávy na GitHubu, a to je v každém konkrétním případě vždy velmi zajímavý, malý a nečekaný příběh, můžete nahradit, že nikdo nikdy neřekne, že za to mohl právě tento člověk. Vina je vždy kladena na konkrétní nedostatečné procesy.
Přejděme k další otázce. Automatizace. Obvykle, když mluvím o automatizaci v jiných kontextech, velmi často odkazuji na tabulku, která hovoří o tom, jak dlouho můžete pracovat na automatizaci úkolu, abyste nezabrali více času na automatizaci, než obvykle ušetříte. Je v tom háček. Háček je v tom, že když SRE automatizují úlohu, šetří nejen čas, ale šetří peníze, protože automatizace přímo ovlivňuje MTTR. Šetří takříkajíc morálku zaměstnanců a vývojářů, což je také vyčerpatelný zdroj. Snižují rutinu. A to vše má pozitivní vliv na práci a ve výsledku i na podnikání, i když se zdá, že automatizace z hlediska časových nákladů nedává smysl.
Ve skutečnosti tomu tak je téměř vždy a je jen velmi málo případů, kdy nemá cenu něco automatizovat v roli SRE. Dále budeme hovořit o tom, co se nazývá chybový rozpočet, rozpočet na chyby. Ve skutečnosti se ukazuje, že pokud se vám daří výrazně lépe než SLO, které jste si nastavili, není to také příliš dobré. To je spíše špatné, protože SLO funguje nejen jako spodní hranice, ale také jako přibližná horní hranice. Když si nastavíte SLO na 99% dostupnost a ve skutečnosti máte 99,99%, ukáže se, že máte prostor pro experimentování, což obchodu vůbec neuškodí, protože jste si to všechno společně určili sami a mít tento prostor, nepoužívejte ho. Máte rozpočet na chyby, který ve vašem případě není utracen.
co s tím děláme? Používáme ho doslova na všechno. Pro testování v produkčních podmínkách, pro zavádění nových funkcí, které mohou ovlivnit výkon, pro vydání, pro údržbu, pro plánované odstávky. Platí i opačné pravidlo: při vyčerpání rozpočtu nemůžeme vydat nic nového, protože jinak překročíme SLO. Rozpočet je již vyčerpán, něco jsme vydali, pokud to negativně ovlivní výkon, tedy pokud to není nějaká oprava, která sama o sobě přímo zvyšuje SLO, tak jdeme přes rozpočet, a to je špatná situace , vyžaduje analýzu, posmrtnou a možná i nějakou procesní korekci.
To znamená, že se ukáže, že pokud samotná služba nefunguje dobře a SLO se utrácí a rozpočet se nevydává na experimenty, ne na žádná vydání, ale na vlastní, pak místo nějakých zajímavých oprav namísto zajímavých funkce, místo zajímavých verzí. Místo jakékoli kreativní práce budete muset dělat hloupé opravy, abyste dostali rozpočet zpět do pořádku, nebo upravit SLO, a to je také proces, který by se neměl stávat příliš často.
Proto se ukazuje, že v situaci, kdy máme větší rozpočet na chyby, to zajímá každého: SRE i vývojáře. Pro vývojáře znamená velký rozpočet na chyby, že se mohou vypořádat s vydáními, testy a experimenty. Pro SRE znamená rozpočet na chyby a vstup do tohoto rozpočtu, že skutečně odvádějí dobrou práci. A to ovlivňuje motivaci nějaké společné práce. Pokud budete naslouchat svým SRE jako vývojáři, budete mít více prostoru pro dobrou práci a mnohem méně práce.
Ukazuje se, že experimenty ve výrobě jsou poměrně důležitou a téměř nedílnou součástí SRE ve velkých týmech. A obvykle se to nazývá chaos engineering, který pochází od týmu Netflixu, který vydal nástroj s názvem Chaos Monkey.
Chaos Monkey se připojí k potrubí CI/CD a náhodně zhroutí server ve výrobě. Opět ve struktuře SRE říkáme, že havarovaný server není sám o sobě špatný, je očekávaný. A pokud je to zahrnuto v rozpočtu, je to přijatelné a nepoškozuje to obchod. Netflix má samozřejmě dostatek redundantních serverů, dostatek replikace, že to vše lze opravit, aniž by si toho uživatel jako celek vůbec všiml, a rozhodně nikdo nenechá jeden server za jakýkoli rozpočet.
Netflix měl najednou celou sadu takových nástrojů, z nichž jedna, Chaos Gorilla, zcela deaktivuje jednu z zón dostupnosti v Amazonu. A takové věci dobře pomáhají identifikovat za prvé skryté závislosti, kdy není zcela jasné, co co ovlivňuje, co na čem závisí. A pokud pracujete s mikroslužbou a dokumentace není úplně dokonalá, může vám to být povědomé. A opět to pomáhá zachytit chyby v kódu, které nemůžete zachytit během stagingu, protože jakékoli staging není přesnou simulací, protože měřítko zatížení je jiné, vzor zatížení je jiný, vybavení je také nejvíce pravděpodobné, jiné. Špičkové zatížení může být také neočekávané a nepředvídatelné. A takové testování, které opět nejde nad rámec rozpočtu, velmi dobře pomáhá zachytit chyby v infrastruktuře, které staging, autotesty a pipeline CI/CD nikdy nezachytí. A pokud je to vše zahrnuto ve vašem rozpočtu, nezáleží na tom, že tam vaše služba klesla, i když by to vypadalo velmi děsivě, server se zhroutil, jaká noční můra. Ne, to je normální, to je dobré, pomáhá to zachytit chyby. Pokud máte rozpočet, můžete ho utratit.
Otázka: Jakou literaturu mohu doporučit? Seznam je na konci. Literatury je spousta, doporučil bych několik zpráv. Jak to funguje a zda SRE funguje ve firmách bez vlastního softwarového produktu nebo s minimálním vývojem. Například v podniku, kde hlavní činností není software. V podniku, kde hlavní činností není software, funguje SRE úplně stejně jako kdekoli jinde, protože v podniku také musíte používat, i když nevyvíjíte, softwarové produkty, musíte zavádět aktualizace, potřebujete změnit infrastrukturu, musíte růst, musíte se škálovat. A SRE pomáhají identifikovat a předvídat možné problémy v těchto procesech a řídit je poté, co začne určitý růst a změní se obchodní potřeby. Protože pro SRE není absolutně nutné zabývat se vývojem softwaru, pokud máte alespoň několik serverů a očekáváte alespoň nějaký růst.
Totéž platí pro malé projekty, malé organizace, protože velké firmy mají rozpočet a prostor na experimentování. Ale zároveň lze všechny tyto plody experimentů použít kdekoli, to znamená, že SRE se samozřejmě objevily v Googlu, Netflixu a Dropboxu. Zároveň však malé společnosti a startupy již mohou číst zhuštěný materiál, číst knihy a sledovat zprávy. Začnou o tom slýchat častěji, podívejte se na konkrétní příklady, myslím, dobře, tohle může být opravdu užitečné, potřebujeme to taky, super.
To znamená, že veškerá hlavní práce na standardizaci těchto procesů již byla provedena za vás. Jediné, co musíte udělat, je definovat roli SRE konkrétně ve vaší společnosti a začít skutečně zavádět všechny tyto praktiky, které již byly opět popsány. Čili z užitečných principů pro malé firmy je to vždy definice SLA, SLI, SLO. Pokud se nepodílíte na softwaru, pak to budou interní SLA a interní SLO, interní rozpočet pro chyby. Téměř vždy to vede k zajímavým diskusím v týmu i v rámci byznysu, protože se může ukázat, že utrácíte mnohem víc, než je nutné, za infrastrukturu, za nějakou organizaci ideálních procesů, ideální potrubí. A tyto 4 devítky, které máte v IT oddělení, je teď opravdu nepotřebujete. Ale zároveň bylo možné strávit čas, utratit rozpočet za chyby na něco jiného.
Proto je monitorování a organizace monitorování užitečné pro společnost jakékoli velikosti. A obecně, tento způsob uvažování, kde jsou chyby něco přijatelného, kde je rozpočet, kde existují cíle, je opět užitečný pro společnost jakékoli velikosti, počínaje startupem o 3 lidech.
Poslední z technických nuancí, o kterých můžeme mluvit, je monitorování. Protože pokud mluvíme o SLA, SLI, SLO, nemůžeme bez sledování pochopit, zda se vejdeme do rozpočtu, zda plníme naše Cíle a jak ovlivňujeme výslednou SLA. Mnohokrát jsem pozoroval, že monitorování probíhá následujícím způsobem: existuje nějaká hodnota, například čas požadavku na server, průměrný čas nebo počet požadavků na databázi. Má normu určenou inženýrem. Pokud se metrika odchyluje od normy, je odeslán e-mail. To vše je zpravidla naprosto zbytečné, protože to vede k takovému přesycení výstrah, přesycení monitorovacích zpráv, kdy je člověk za prvé musí pokaždé interpretovat, tedy určit, zda metrická hodnota znamená potřebu nějaký druh akce. A za druhé, jednoduše přestane vnímat všechna tato upozornění, když se od něj v podstatě nevyžaduje žádná akce. To znamená, že dobré pravidlo monitorování a úplně první pravidlo při implementaci SRE je, že oznámení by mělo přijít pouze tehdy, když je vyžadována akce.
Ve standardním případě jsou 3 úrovně událostí. Existují výstrahy, existují vstupenky, existují protokoly. Upozornění jsou cokoli, co od vás vyžaduje okamžitou akci. To znamená, že vše je rozbité, je třeba to hned opravit. Vstupenky jsou něco, co vyžaduje čekající akci. Ano, musíte něco udělat, musíte něco udělat ručně, automatizace selhala, ale nemusíte to dělat v příštích několika minutách. Protokoly jsou vše, co nevyžaduje akci, a obecně platí, že pokud jde dobře, nikdo je nikdy nebude číst. Protokoly bude nutné číst, až když se zpětně ukáže, že něco bylo nějakou dobu rozbité, nevěděli jsme o tom. Nebo je potřeba provést nějaké vyšetřování. Ale obecně platí, že vše, co nevyžaduje žádnou akci, jde do protokolů.
Jako vedlejší efekt toho všeho, pokud jsme identifikovali, které události vyžadují akce a dobře popsali, jaké by tyto akce měly být, znamená to, že akci lze automatizovat. To znamená, co se stane. Přicházíme z poplachu. Pojďme k akci. Pojďme k popisu této akce. A pak se přesuneme k automatizaci. To znamená, že jakákoli automatizace začíná reakcí na událost.
Od monitorování přejdeme k termínu zvanému Observability. Také kolem tohoto slova je v posledních letech trochu humbuk. A málokdo chápe, co to znamená vytržené z kontextu. Ale hlavním bodem je, že pozorovatelnost je metrikou transparentnosti systému. Pokud se něco pokazilo, jak rychle můžete určit, co přesně se pokazilo a jaký byl v tu chvíli stav systému. Z hlediska kódu: která funkce selhala, která služba selhala. Jaký byl stav např. vnitřních proměnných, konfigurace. Z hlediska infrastruktury jde o to, ve které zóně dostupnosti k selhání došlo, a pokud máte nějaký Kubernetes, tak ve kterém modulu k selhání došlo, jaký byl stav modulu. A proto má Observability přímý vztah s MTTR. Čím vyšší je Observability služby, tím snazší je identifikovat chybu, tím snazší je opravit chybu, tím snazší je automatizovat chybu, tím nižší je MTTR.
Přejdeme-li opět k malým firmám, velmi často se i nyní ptají, co dělat s velikostí týmu a zda je nutné najmout samostatné SRE v malém týmu. Už jsem o tom mluvil trochu dříve. V prvních fázích vývoje startupu nebo například týmu to není vůbec nutné, protože ze SRE lze udělat přechodnou roli. A tím se tým trochu oživí, protože je tam alespoň nějaká rozmanitost. A navíc to lidi připraví na to, že s růstem se obecně velmi výrazně změní povinnosti SRE. Pokud najmete člověka, pak má samozřejmě nějaká očekávání. A tato očekávání se časem nezmění, ale požadavky se budou velmi měnit. Proto je najímání SRE v raných fázích poměrně obtížné. Je mnohem jednodušší vychovat si vlastní. Ale stojí to za zamyšlení.
Jedinou výjimkou je pravděpodobně situace, kdy jsou velmi přísné a přesně definované požadavky na výšku. To znamená, že v případě startupu by to mohl být nějaký tlak investorů, nějaká prognóza růstu vícekrát najednou. Pak je najímání SRE obecně oprávněné, protože lze ospravedlnit. Máme požadavky na růst, potřebujeme člověka, který bude zodpovědný za to, že se s takovým růstem nic nezlomí.
Ještě jedna otázka. Co dělat, když vývojáři několikrát seříznou funkci, která projde testy, ale rozbije produkt, načte databázi, rozbije další funkce, jaký proces implementovat. V souladu s tím je v tomto případě zaveden rozpočet pro chyby. A některé služby, některé funkce jsou testovány okamžitě ve výrobě. To může být kanárek, kdy jen malý počet uživatelů, ale již ve výrobě, nasazuje nějakou funkci, ovšem s očekáváním, že když se něco rozbije třeba půl procenta všech uživatelů, tak se to ještě vejde do rozpočet na chyby. V souladu s tím ano, dojde k chybě, u některých uživatelů se vše rozbije, ale již jsme řekli, že je to normální.
Byl zde dotaz ohledně nástrojů SRE. To znamená, existuje něco konkrétního, co by SRE používali, co by všichni ostatní nepoužívali? Ve skutečnosti existují některé vysoce specializované nástroje, existuje nějaký software, který například simuluje zatížení nebo dělá kanárské A/B testování. Ale v zásadě jsou nástroje SRE to, co vaši vývojáři již používají. Protože SRE komunikuje přímo s vývojovým týmem. A pokud máte různé nástroje, ukazuje se, že synchronizace nějakou dobu trvá. Zejména pokud SRE pracují ve velkých týmech, ve velkých společnostech, kde může být několik týmů, zde velmi pomůže celopodniková standardizace, protože pokud 50 týmů používá 50 různých utilit, znamená to, že je SRE musí znát všechny. A to se samozřejmě nikdy nestane. A výrazně se sníží kvalita práce, kvalita kontroly alespoň některých týmů.
Náš webinář se postupně chýlí ke konci. Podařilo se mi říct pár základních věcí. O SRE se samozřejmě nedá nic říct a pochopit za hodinu. Ale doufám, že se mi podařilo zprostředkovat tento způsob myšlení, hlavní klíčové body. A pak, pokud vás to zajímá, můžete se do tématu ponořit hlouběji, studovat na vlastní pěst a podívat se, jak to zavádějí jiní lidé, v jiných firmách. A proto na začátku února přijďte k nám do Slurm SRE.
Slurm SRE je třídenní intenzivní kurz, který pokryje přibližně to, o čem teď mluvím, ale s mnohem větší hloubkou, s reálnými případy, s praxí, celý intenzivní je zaměřen na praktickou práci. Lidé budou rozděleni do týmů. Všichni budete pracovat na skutečných případech. V souladu s tím máme instruktory z Booking.com Ivana Kruglova a Bena Tylera. Máme skvělého Evgeniy Varabbase z Googlu ze San Francisca. A taky ti něco řeknu. Tak nás určitě přijďte navštívit.
Takže seznam referencí. Na SRE jsou odkazy. na stejné knize, nebo spíše na 2 knihách o SRE, které napsal Google. Další , kde jsou pojmy a jejich použití vysvětleny trochu podrobněji. Další 3 jsou zprávy o SRE v různých společnostech. První - , to je hlavní poznámka Bena Trainera z Google. Druhý - . Třetí je opět o . Čtvrtá zpráva z , která má pouze 5 klíčových zaměstnanců SRE ve 190 zemích. Je velmi zajímavé se na to všechno podívat, protože stejně jako DevOps znamená pro různé společnosti a dokonce různé týmy velmi odlišné věci, SRE má velmi odlišné odpovědnosti, a to i ve společnostech podobné velikosti.
2 další odkazy o principech chaosového inženýrství: , . A na konci jsou 3 seznamy ze série Awesome Lists o o a asi . Seznam na SRE je neuvěřitelně obrovský, nemusíte ho procházet celý, je tam asi 200 článků. Vřele doporučuji články o kapacitním plánování a bezúhonné pitvě.
Zajímavý článek:
Děkuji, že mě celou tu dobu posloucháš. Doufám, že jste se něco naučili. Doufám, že máte dostatek materiálů, abyste se naučili ještě více. A uvidíme se později. Snad v únoru.
Webinář moderoval Eduard Medveděv.
PS: pro ty, kteří rádi čtou, Eduard poskytl seznam referencí. Vítáni jsou ti, kteří tomu chtějí rozumět v praxi .
Zdroj: www.habr.com