Webinár má slabý zvuk, preto sme urobili prepis.
Volám sa Medvedev Eduard. Dnes budem hovoriť o tom, čo je SRE, ako sa objavil SRE, aké sú pracovné kritériá pre inžinierov SRE, trochu o kritériách spoľahlivosti, trochu o jeho monitorovaní. Pôjdeme nad vecou, pretože za hodinu toho veľa nepoviete, ale dám vám materiály na dodatočné posúdenie a všetci vás čakáme o hod. . v Moskve koncom januára.
Najprv si povedzme, čo je SRE – Site Reliability Engineering. A ako sa to javilo ako samostatná pozícia, ako samostatný smer. Všetko to začalo tým, že v tradičných vývojových kruhoch sú Dev a Ops dva úplne odlišné tímy, zvyčajne s dvoma úplne odlišnými cieľmi. Cieľom vývojového tímu je zaviesť nové funkcie, aby vyhovovali obchodným potrebám. Cieľom tímu Ops je zabezpečiť, aby všetko fungovalo a nič sa nezlomilo. Je zrejmé, že tieto ciele si priamo protirečia: aby všetko fungovalo a nič sa nepokazilo, je lepšie zavádzať nové funkcie čo najmenej. Z tohto dôvodu vzniká mnoho vnútorných konfliktov, ktoré sa snaží vyriešiť metodika teraz nazývaná DevOps.
Problém je, že nemáme jasnú definíciu DevOps a jasnú implementáciu DevOps. Pred 2 rokmi som hovoril na konferencii v Jekaterinburgu a doteraz sekcia DevOps začínala správou „Čo je DevOps“. V roku 2017 má devops takmer 10 rokov, no stále sa dohadujeme, čo to je. A to je veľmi zvláštna situácia, ktorú sa Google snažil pred pár rokmi vyriešiť.
V roku 2016 spoločnosť Google vydala knihu s názvom „Site Reliability Engineering“. A v skutočnosti práve touto knihou začalo hnutie SRE. SRE je špecifická možnosť implementácie paradigmy DevOps v konkrétnej spoločnosti. Inžinieri SRE si dali za cieľ zabezpečiť spoľahlivú prevádzku systémov. Sú prevzaté najmä od vývojárov, niekedy od správcov so silným vývojovým zázemím. A robia to, čo kedysi správcovia systému, ale silné zázemie vo vývoji a znalosť systému z pohľadu kódu vedie k tomu, že títo ľudia neinklinujú k rutinnej administratívnej práci, ale inklinujú k automatizácii.
Ukazuje sa, že paradigma DevOps v tímoch SRE je implementovaná skutočnosťou, že existujú inžinieri SRE, ktorí riešia štrukturálne problémy. Tu je to isté spojenie medzi Dev a Ops, o ktorom ľudia hovoria už 8 rokov. Úloha SRE je podobná úlohe architekta v tom, že nováčikovia sa nestávajú SRE. Ľudia na začiatku kariéry ešte nemajú žiadne skúsenosti a nemajú požadovanú šírku vedomostí. Pretože SRE vyžaduje veľmi sofistikované znalosti o tom, čo a kedy presne sa môže pokaziť. Preto je tu spravidla potrebná určitá skúsenosť vo vnútri spoločnosti aj mimo nej.
Pýtajú sa, či bude popísaný rozdiel medzi SRE a devops. Práve bola opísaná. Môžeme hovoriť o mieste SRE v organizácii. Na rozdiel od klasického prístupu DevOps, kde je Ops stále samostatným oddelením, SRE je súčasťou vývojového tímu. Podieľajú sa na vývoji produktov. Existuje dokonca prístup, kde SRE je rola, ktorá prechádza z jedného vývojára na druhého. Na kontrole kódu sa podieľajú rovnako ako napríklad UX dizajnéri, samotní vývojári a niekedy aj produktoví manažéri. SRE fungujú na rovnakej úrovni. Potrebujeme ich schválenie, potrebujeme ich kontrolu, aby pri každom nasadení SRE povedalo: „Dobre, toto nasadenie, tento produkt neovplyvní negatívne spoľahlivosť. A ak áno, bude to v rámci nejakých prijateľných hraníc.“ Aj o tomto si povieme.
V súlade s tým má SRE právo veta na zmeny kódu. A vo všeobecnosti to tiež vedie k malému konfliktu, ak sa SRE implementuje nesprávne. Práve v tejto knihe o inžinierstve spoľahlivosti stránok mnohé časti, dokonca viac ako jedna, hovoria, ako sa vyhnúť týmto konfliktom.
Ľudia sa pýtajú, ako súvisí SRE s informačnou bezpečnosťou. SRE nie je priamo zapojená do informačnej bezpečnosti. Väčšinou vo veľkých spoločnostiach to robia jednotliví ľudia, testeri a analytici. Ale SRE s nimi interaguje aj v tom zmysle, že niektoré operácie, niektoré potvrdenia, niektoré nasadenia, ktoré ovplyvňujú bezpečnosť, môžu tiež ovplyvniť dostupnosť produktu. Preto má SRE vo všeobecnosti interakciu s akýmikoľvek tímami, vrátane bezpečnostných tímov, vrátane analytikov. Preto sú SRE potrebné hlavne pri pokuse o implementáciu DevOps, ale zaťaženie vývojárov je príliš veľké. To znamená, že samotný vývojový tím sa už nedokáže vyrovnať s tým, že teraz musí byť zodpovedný aj za Ops. A objaví sa samostatná úloha. Táto úloha je naplánovaná v rozpočte. Niekedy je táto rola zabudovaná do veľkosti tímu, objavuje sa samostatná osoba, niekedy sa ňou stáva jeden z vývojárov. Takto sa v tíme objavuje prvá SRE.
Zložitosť systému, ktorá je ovplyvnená SRE, zložitosť, ktorá ovplyvňuje prevádzkovú spoľahlivosť, môže byť nevyhnutná alebo náhodná. O nevyhnutnú zložitosť ide vtedy, keď sa zložitosť produktu zvýši do takej miery, ako si to nové vlastnosti produktu vyžadujú. Náhodná zložitosť je, keď sa zložitosť systému zvyšuje, ale vlastnosti produktu a obchodné požiadavky to priamo neovplyvňujú. Ukazuje sa, že buď vývojár niekde urobil chybu, alebo algoritmus nie je optimálny, alebo sú zavedené nejaké ďalšie záujmy, ktoré zbytočne zvyšujú zložitosť produktu. Dobrý SRE by sa mal vždy vyhnúť tejto situácii. To znamená, že akékoľvek potvrdenie, akékoľvek nasadenie, akákoľvek požiadavka na stiahnutie, ktorá zvyšuje zložitosť v dôsledku náhodných pridaní, by mala byť zablokovaná.
Otázkou je, prečo si do tímu neprijať inžiniera, systémového administrátora s množstvom vedomostí. Vývojár v úlohe inžiniera vraj nie je najoptimálnejším personálnym riešením. Vývojár v úlohe inžiniera nie je vždy optimálnym personálnym riešením, ale tu ide o to, že vývojár, ktorý sa zaoberá Ops, má trochu väčšiu túžbu po automatizácii, má trochu viac vedomostí a zručností, aby to mohol implementovať. automatizácie. A podľa toho znižujeme nielen čas na niektoré špecifické operácie, nielen rutinné, ale aj také dôležité obchodné parametre ako MTTR (Mean Time To Recovery, recovery time). Tým, a o tom si povieme aj o niečo neskôr, šetríme peniaze pre organizáciu.
Teraz si povedzme o kritériách pre prácu SRE. A v prvom rade o spoľahlivosti. V malých firmách a startupoch sa často stáva, že ľudia predpokladajú, že ak je služba napísaná dobre, ak je produkt napísaný dobre a správne, bude fungovať, nerozbije sa. To je všetko, napíšeme dobrý kód, takže nie je čo pokaziť. Kód je veľmi jednoduchý, nie je čo pokaziť. Ide o tých istých ľudí, ktorí hovoria, že nepotrebujeme testy, pretože, pozrite, toto sú tri metódy VPI, prečo sa obťažovať?
To všetko je, samozrejme, nesprávne. A títo ľudia sa veľmi často zrania takýmto kódexom v praxi, pretože veci sa pokazia. Veci sa niekedy zlomia tými najnepredvídateľnejšími spôsobmi. Niekedy ľudia povedia nie, nikdy sa to nestane. A stále sa to stáva. Stáva sa to dosť často. A to je dôvod, prečo sa nikto nikdy nesnaží o 100% dostupnosť, pretože 100% dostupnosť nikdy nenastane. Toto je norma. A to je dôvod, prečo vždy hovoríme o deviatich, keď hovoríme o dostupnosti služieb. 2 deviataci, 3 deviataci, 4 deviataci, 5 deviataci. Ak to premietneme do prestojov, tak napríklad 5 deviatok je o niečo viac ako 5 minút výpadku za rok, 2 deviatky sú 3,5 dňa prestoja.
Je ale zrejmé, že v určitom bode dochádza k poklesu POI a návratnosti investícií. Prechod z dvoch deviatok na tri deviatky znamená skrátenie prestojov o viac ako 3 dni. Prechod zo štyroch deviatok na päť znižuje prestoje o 47 minút ročne. A ukazuje sa, že to nemusí byť pre podnikanie rozhodujúce. A vo všeobecnosti požadovaná spoľahlivosť nie je technický problém, v prvom rade je to obchodná záležitosť, je to otázka produktu. Aká miera prestojov je prijateľná pre používateľov produktu, čo očakávajú, koľko zaplatia, napríklad koľko peňazí stratia, koľko peňazí stratí systém.
Dôležitou otázkou je, aká je spoľahlivosť zvyšných komponentov. Pretože rozdiel medzi 4 a 5 deviatkami nebude na smartfóne s 2 spoľahlivostnými deviatkami viditeľný. Zhruba povedané, ak sa niečo pokazí na smartfóne vo vašich službách 10-krát za rok, s najväčšou pravdepodobnosťou 8-krát došlo k poruche na strane OS. Používateľ je na to zvyknutý a nebude tomu venovať pozornosť raz za rok navyše. Je potrebné porovnávať cenu zvyšujúcej sa spoľahlivosti a zvyšujúceho sa zisku.
Práve v knihe o SRE je dobrý príklad zvýšenia na 4 deviatky z 3 deviatok. Ukazuje sa, že nárast dostupnosti je o niečo menší ako 0,1 %. A ak je príjem zo služby 1 milión dolárov ročne, zvýšenie výnosov je 900 dolárov. Ak nás zvýšenie dostupnosti o deväť stojí menej ako 900 dolárov ročne, zvýšenie dáva finančný zmysel. Ak to stojí viac ako 900 dolárov ročne, už to nemá zmysel, pretože zvýšenie výnosov jednoducho nekompenzuje mzdové náklady a náklady na zdroje. A 3 deviatky nám budú stačiť.
Toto je samozrejme zjednodušený príklad, kde sú všetky požiadavky rovnaké. A z 3 deviatok na 4 deviatky je to celkom jednoduché, ale zároveň napríklad prechod z 2 deviatok na 3 je už úspora 9 XNUMX dolárov, môže to dávať finančný zmysel. Prirodzene, v skutočnosti je nezaregistrovanie požiadavky horšie ako nezobrazenie stránky, požiadavky majú rôznu váhu. Z obchodného hľadiska môžu mať úplne iné kritériá, ale spravidla, ak nehovoríme o žiadnych konkrétnych službách, ide o pomerne spoľahlivú aproximáciu.
Dostali sme otázku, či je SRE jedným z koordinátorov pri výbere architektonického riešenia služby. To je prijateľné z hľadiska integrácie do existujúcej infraštruktúry tak, aby nedošlo k strate jej stability. Áno, SRE ovplyvňujú požiadavky na stiahnutie, potvrdenia, vydania rovnakým spôsobom; ovplyvňujú architektúru, implementáciu nových služieb, mikroslužieb a implementáciu nových riešení. Prečo som predtým povedal, že potrebujete skúsenosti, potrebujete kvalifikáciu. V skutočnosti je SRE jedným z blokujúcich hlasov v akomkoľvek architektonickom a softvérovom riešení. V súlade s tým musí SRE ako inžinier v prvom rade nielen pochopiť, ale aj pochopiť, ako niektoré konkrétne rozhodnutia ovplyvnia spoľahlivosť, stabilitu a pochopiť, ako to súvisí s obchodnými potrebami a z akého hľadiska je to prijateľné. , a ktorý nie je.
Preto je teraz čas hovoriť o kritériách spoľahlivosti, ktoré sú v SRE tradične definované ako SLA (Service Level Agreement). S najväčšou pravdepodobnosťou známy pojem. SLI (Ukazovateľ úrovne služieb). SLO (Cieľ úrovne služieb). Dohoda o úrovni služieb je možno dôležitý pojem, najmä ak ste pracovali so sieťami, poskytovateľmi a hostingom. Toto je všeobecná dohoda, ktorá popisuje výkon celej vašej služby, sankcie, niektoré sankcie za chyby, metriky, kritériá. A SLI je samotná metrika dostupnosti. To znamená, čo môže byť SLI: čas odozvy služby, počet chýb v percentách. To by mohla byť šírka pásma, ak hovoríme o nejakom hostovaní súborov. Ak hovoríme o rozpoznávacích algoritmoch, indikátorom môže byť napríklad aj správnosť odpovede. SLO (Service Level Objective) je kombináciou ukazovateľa SLI, jeho hodnoty a periódy.
Povedzme, že SLA by mohla byť takáto. Služba je dostupná 99,95 % času počas celého roka. Alebo 99 kritických lístkov technickej podpory bude uzavretých do 3 hodín za štvrťrok. Alebo 85 % otázok bude zodpovedaných do 1,5 sekundy každý mesiac. To znamená, že postupne chápeme, že chyby a zlyhania sú celkom normálne. To je prijateľný stav, plánujeme to, dokonca s tým do istej miery počítame. To znamená, že SRE vytvára systémy, ktoré môžu robiť chyby, ktoré musia normálne reagovať na chyby a ktoré ich musia brať do úvahy. A pokiaľ je to možné, mali by s chybami narábať tak, aby si ich používateľ buď nevšimol, alebo si ich všimol, no existuje nejaké riešenie, aby sa všetko úplne nerozpadlo.
Ak napríklad odovzdáte video na YouTube a YouTube ho nemôže okamžite skonvertovať, ak je video príliš veľké, ak formát nie je optimálny, potom žiadosť prirodzene nezlyhá s časovým limitom, YouTube nezobrazí 502 Chyba, YouTube povie: „Všetko sme vytvorili, vaše video sa spracováva. Bude pripravený asi za 10 minút." Toto je princíp ladnej degradácie, ktorý je známy napríklad z front-end vývoja, ak ste to niekedy robili.
Ďalšie pojmy, ktoré sú veľmi dôležité pre prácu so spoľahlivosťou, s chybami, s očakávaniami, o ktorých si povieme, sú MTBF a MTTR. MTBF je stredný čas medzi poruchami. MTTR Mean Time To Recovery, priemerný čas do zotavenia. Teda koľko času uplynulo od momentu zistenia chyby, od momentu, kedy sa chyba objavila až po moment, kedy bola služba obnovená do úplne normálnej prevádzky. MTBF sa koriguje hlavne prácou na kvalite kódu. To znamená, že SRE môžu povedať „nie“. A celý tím musí pochopiť, že keď SRE povie „nie“, nepovie to preto, že je škodlivý, nie preto, že je zlý, ale preto, že inak budú všetci trpieť.
Opäť, existuje veľa článkov, veľa metód, veľa spôsobov, dokonca aj v samotnej knihe, na ktorú tak často odkazujem, ako zabezpečiť, aby ostatní vývojári nezačali nenávidieť SRE. Na druhej strane MTTR je o práci na vašom SLO (Cieľ úrovne služieb). A to je väčšinou automatizácia. Pretože napríklad naše SLO je uptime 4 deviatky za štvrťrok. To znamená, že za 3 mesiace môžeme povoliť 13 minút výpadku. A ukázalo sa, že naše MTTR nemôže byť dlhšie ako 13 minút. Ak si vezmeme 13 minút na reakciu aspoň na 1 výpadok, znamená to, že sme už vyčerpali celý rozpočet za štvrťrok. Porušujeme SLO. 13 minút na reakciu a nápravu poruchy je veľa pre stroj, ale veľmi málo pre človeka. Pretože kým človek dostane výstrahu, kým zareaguje, kým zistí chybu, je to už niekoľko minút. Kým človek pochopí, ako to opraviť, čo presne opraviť, čo robiť, potrvá to ešte pár minút. A v skutočnosti, aj keď potrebujete reštartovať server, ako sa ukázalo, alebo vytvoriť nový uzol, potom manuálne MTTR trvá asi 7-8 minút. Pri automatizácii procesu MTTR veľmi často dosahuje sekundu, niekedy milisekúnd. Google zvyčajne hovorí o milisekundách, ale v skutočnosti to, samozrejme, nie je také dobré.
V ideálnom prípade by mal SRE takmer úplne automatizovať svoju prácu, pretože to priamo ovplyvňuje MTTR, jeho metriky, SLO celej služby a podľa toho aj obchodné zisky. V prípade prekročenia času sa nás pýtajú, či je vina na strane SRE. Našťastie sa vina nehádže na nikoho. A to je samostatná kultúra, ktorá sa nazýva balmeless postmortem, o ktorej dnes nebudeme hovoriť, ale rozoberieme ju na Slurm. Toto je veľmi zaujímavá téma, o ktorej sa dá veľa rozprávať. Zhruba povedané, ak sa prekročí stanovený čas za štvrťrok, tak si za to môže trochu každý, to znamená, že obviňovať všetkých nie je produktívne, radšej možno nikoho neobviňujme, ale napravme situáciu a pracujme s tým, čo máme. Podľa mojich skúseností je tento prístup väčšine tímov, najmä v Rusku, trochu cudzí, ale dáva zmysel a funguje veľmi dobre. Preto vám na záver odporučím články a literatúru, ktoré si k tejto téme môžete prečítať. Alebo príďte do Slurm SRE.
Nechaj ma vysvetliť. Ak sa prekročí čas SLO za štvrťrok, ak prestoj nebol 13 minút, ale 15, kto za to môže? Samozrejme, na vine môže byť SRE, pretože zjavne urobil nejaké zlé odovzdanie alebo nasadenie. Môže za to správca dátového centra, ktorý mohol vykonať nejakú neplánovanú údržbu. Ak za to môže správca datacentra, tak je na vine aj človek z Ops, že pri odsúhlasovaní SLO nevypočítal údržbu. Môže za to manažér, technický riaditeľ alebo niekto, kto podpísal zmluvu o dátovom centre a nevenoval pozornosť tomu, že SLA dátového centra nie je dimenzovaná na požadované odstávky. Podľa toho si každý môže za túto situáciu tak trochu sám. A to znamená, že nemá zmysel zvaľovať vinu na niekoho konkrétneho za túto situáciu. Ale samozrejme to treba napraviť. Preto existujú posmrtné tresty. A ak čítate napríklad posmrtné správy na GitHub, a to je vždy veľmi zaujímavý, malý a nečakaný príbeh v každom konkrétnom prípade, môžete nahradiť, že nikto nikdy nepovie, že za to môže práve tento človek. Vina je vždy kladená na konkrétne nedostatočné procesy.
Prejdime k ďalšej otázke. automatizácia. Keď hovorím o automatizácii v iných kontextoch, zvyčajne sa veľmi často odvolávam na tabuľku, ktorá hovorí o tom, ako dlho môžete pracovať na automatizácii úlohy, aby jej automatizácia nezabrala viac času, ako vo všeobecnosti ušetríte. Je v tom háčik. Háčik je v tom, že keď SRE automatizujú úlohu, šetria nielen čas, ale aj peniaze, pretože automatizácia priamo ovplyvňuje MTTR. Šetria takpovediac morálku zamestnancov a vývojárov, čo je tiež vyčerpateľný zdroj. Znižujú rutinu. A to všetko má pozitívny vplyv na prácu a vo výsledku aj na podnikanie, aj keď sa zdá, že automatizácia z hľadiska časových nákladov nemá zmysel.
V skutočnosti je to takmer vždy a existuje len veľmi málo prípadov, keď sa neoplatí automatizovať niečo v úlohe SRE. Ďalej si povieme niečo o tom, čo sa nazýva chybový rozpočet, rozpočet na chyby. V skutočnosti sa ukazuje, že ak sa vám darí výrazne lepšie ako SLO, ktoré ste si nastavili, tiež to nie je príliš dobré. To je dosť zlé, pretože SLO funguje nielen ako spodná hranica, ale aj ako približná horná hranica. Keď si nastavíte SLO na 99% dostupnosť a v skutočnosti máte 99,99%, ukáže sa, že máte priestor na experimentovanie, čo biznisu vôbec neuškodí, pretože ste si toto všetko spoločne určili a mať tento priestor, nepoužívať ho. Máte rozpočet na chyby, ktorý sa vo vašom prípade neminie.
Čo s tým robíme? Používame ho doslova na všetko. Na testovanie v produkčných podmienkach, na zavádzanie nových funkcií, ktoré môžu ovplyvniť výkon, na vydania, na údržbu, na plánované odstávky. Platí aj opačné pravidlo: ak je rozpočet vyčerpaný, nemôžeme vydať nič nové, lebo inak prekročíme SLO. Rozpočet je už vyčerpaný, niečo sme uvoľnili, ak to negatívne ovplyvní výkon, teda ak to nie je nejaká oprava, ktorá sama o sebe priamo zvyšuje SLO, tak ideme cez rozpočet, a to je zlá situácia , vyžaduje si to analýzu, postmortem a možno aj nejakú úpravu procesu.
To znamená, že sa ukáže, že ak samotná služba nefunguje dobre a SLO sa míňa a rozpočet sa míňa nie na experimenty, nie na žiadne vydania, ale na svoje vlastné, potom namiesto niektorých zaujímavých opráv namiesto zaujímavých funkcie namiesto zaujímavých vydaní. Namiesto akejkoľvek kreatívnej práce budete musieť robiť hlúpe opravy, aby ste dostali rozpočet späť do poriadku, alebo upravovať SLO, a to je tiež proces, ktorý by sa nemal stávať príliš často.
Preto sa ukazuje, že v situácii, keď máme väčší rozpočet na chyby, to zaujíma každého: SRE aj vývojárov. Pre vývojárov znamená veľký rozpočet na chyby, že sa môžu zaoberať vydaniami, testami a experimentmi. Pre SRE znamená rozpočet na chyby a vstup do tohto rozpočtu, že v skutočnosti robia dobrú prácu. A to ovplyvňuje motiváciu nejakej spoločnej práce. Ak budete počúvať svoje SRE ako vývojári, budete mať viac priestoru na dobrú prácu a oveľa menej práce.
Ukazuje sa, že experimenty vo výrobe sú pomerne dôležitou a takmer neoddeliteľnou súčasťou SRE vo veľkých tímoch. A zvyčajne sa to nazýva chaosové inžinierstvo, ktoré pochádza od tímu spoločnosti Netflix, ktorý vydal nástroj s názvom Chaos Monkey.
Chaos Monkey sa pripojí k potrubiu CI/CD a náhodne zrúti server vo výrobe. Opäť v štruktúre SRE hovoríme, že zrútený server nie je sám o sebe zlý, je očakávaný. A ak je to zahrnuté v rozpočte, je to prijateľné a nepoškodzuje to podnikanie. Samozrejme, Netflix má dostatok redundantných serverov, dostatok replikácií, že toto všetko sa dá opraviť bez toho, aby si to používateľ ako celok všimol, a určite nikto nenechá jeden server za akýkoľvek rozpočet.
Netflix mal naraz celý rad takýchto nástrojov, z ktorých jeden, Chaos Gorilla, úplne deaktivuje jednu zo zón dostupnosti v Amazone. A takéto veci dobre pomáhajú identifikovať po prvé skryté závislosti, keď nie je celkom jasné, čo čo ovplyvňuje, čo od čoho závisí. A toto, ak pracujete s mikroslužbou a dokumentácia nie je úplne dokonalá, vám to môže byť známe. A opäť to pomáha zachytiť chyby v kóde, ktoré nemôžete zachytiť počas stagingu, pretože akékoľvek staging nie je presnou simuláciou, pretože miera zaťaženia je iná, vzor zaťaženia je iný, vybavenie je tiež najviac pravdepodobné, iné. Špičkové zaťaženie môže byť tiež neočakávané a nepredvídateľné. A takéto testovanie, ktoré opäť nejde nad rámec rozpočtu, veľmi dobre pomáha zachytiť chyby v infraštruktúre, ktoré staging, autotesty a pipeline CI/CD nikdy nezachytia. A pokiaľ je toto všetko zahrnuté vo vašom rozpočte, nezáleží na tom, že vaša služba tam klesla, aj keď by to vyzeralo veľmi strašidelne, server sa zrútil, aká nočná mora. Nie, to je normálne, to je dobré, pomáha to zachytiť chyby. Máte rozpočet, čo znamená, že ho môžete minúť.
Otázka: Akú literatúru môžem odporučiť? Zoznam je na konci. Literatúry je veľa, odporúčal by som niekoľko správ. Ako to funguje a či SRE funguje vo firmách bez vlastného softvérového produktu alebo s minimálnym vývojom. Napríklad v podniku, kde hlavnou činnosťou nie je softvér. V podniku, kde hlavnou činnosťou nie je softvér, funguje SRE úplne rovnako ako kdekoľvek inde, pretože v podniku musíte tiež používať, aj keď nevyvíjate, softvérové produkty, musíte zavádzať aktualizácie, potrebujete zmeniť infraštruktúru, musíte rásť, musíte sa škálovať. A SRE pomáhajú identifikovať a predvídať možné problémy v týchto procesoch a kontrolovať ich po začiatku rastu a zmene obchodných potrieb. Pretože na to, aby ste mali SRE, absolútne nie je potrebné zaoberať sa vývojom softvéru, ak máte aspoň niekoľko serverov a očakávate aspoň nejaký rast.
To isté platí pre malé projekty, malé organizácie, pretože veľké firmy majú rozpočet a priestor na experimentovanie. Zároveň sa však všetky tieto plody experimentov dajú použiť kdekoľvek, to znamená, že SRE sa samozrejme objavili v službách Google, Netflix a Dropbox. Zároveň však malé spoločnosti a startupy už môžu čítať zhustený materiál, čítať knihy a sledovať správy. Začínajú o tom počuť častejšie, pozerajú sa na konkrétne príklady, myslím si, dobre, toto môže byť naozaj užitočné, aj toto potrebujeme, super.
To znamená, že všetka hlavná práca na štandardizácii týchto procesov už bola vykonaná za vás. Jediné, čo musíte urobiť, je definovať úlohu SRE konkrétne vo vašej spoločnosti a začať skutočne implementovať všetky tieto postupy, ktoré už boli opäť popísané. To znamená, že z užitočných princípov pre malé firmy je to vždy definícia SLA, SLI, SLO. Ak nie ste zapojený do softvéru, potom to budú interné SLA a interné SLO, interný rozpočet pre chyby. Takmer vždy to vedie k zaujímavým diskusiám v tíme a v rámci biznisu, pretože sa môže ukázať, že míňate oveľa viac, ako je potrebné na infraštruktúru, na nejakú organizáciu ideálnych procesov, ideálne potrubie. A tieto 4 deviatky, ktoré máte v IT oddelení, teraz naozaj nepotrebujete. Zároveň však bolo možné minúť čas, minúť rozpočet na chyby na niečo iné.
Preto je monitorovanie a organizácia monitorovania užitočná pre spoločnosť akejkoľvek veľkosti. A vôbec, tento spôsob myslenia, kde sú chyby niečo prijateľné, kde je rozpočet, kde existujú ciele, je opäť užitočný pre spoločnosť akejkoľvek veľkosti, počnúc startupom s 3 ľuďmi.
Poslednou z technických nuancií, o ktorých môžeme hovoriť, je monitorovanie. Pretože ak hovoríme o SLA, SLI, SLO, bez sledovania nevieme pochopiť, či sa zmestíme do rozpočtu, či dodržiavame naše Ciele a ako ovplyvníme výslednú SLA. Mnohokrát som si všimol, že monitorovanie prebieha nasledujúcim spôsobom: existuje určitá hodnota, napríklad čas požiadavky na server, priemerný čas alebo počet požiadaviek do databázy. Má normu určenú inžinierom. Ak sa metrika odchyľuje od normy, odošle sa e-mail. Toto všetko je spravidla úplne zbytočné, pretože to vedie k takémuto presýteniu výstrahami, k presýteniu monitorovacích správ, keď ich človek v prvom rade musí zakaždým interpretovať, teda určiť, či metrická hodnota znamená potrebu nejaký druh akcie. A po druhé, jednoducho si prestane všímať všetky tieto upozornenia, keď sa od neho v podstate nevyžaduje žiadna akcia. To znamená, že dobré pravidlo monitorovania a úplne prvé pravidlo pri implementácii SRE je, že oznámenie by malo prísť len vtedy, keď sa vyžaduje akcia.
V štandardnom prípade existujú 3 úrovne udalostí. Existujú upozornenia, existujú lístky, existujú záznamy. Upozornenia sú čokoľvek, čo od vás vyžaduje okamžitú akciu. To znamená, že všetko je pokazené, treba to hneď opraviť. Vstupenky sú niečo, čo si vyžaduje čakajúcu akciu. Áno, musíte niečo urobiť, musíte niečo urobiť manuálne, automatizácia zlyhala, ale nemusíte to robiť v najbližších minútach. Protokoly sú všetko, čo nevyžaduje akciu a vo všeobecnosti, ak veci idú dobre, nikto ich nikdy nebude čítať. Čítať denníky bude potrebné až vtedy, keď sa spätne ukáže, že niečo bolo nejaký čas pokazené, nevedeli sme o tom. Alebo treba urobiť nejaké vyšetrovanie. Vo všeobecnosti však všetko, čo nevyžaduje žiadnu akciu, ide do denníkov.
Vedľajším efektom tohto všetkého je, že ak sme identifikovali, ktoré udalosti vyžadujú akcie a dobre popísali, aké by tieto akcie mali byť, znamená to, že akciu možno automatizovať. Teda čo sa stane. Prichádzame z výstrahy. Poďme k akcii. Poďme k popisu tejto akcie. A potom prejdeme k automatizácii. To znamená, že akákoľvek automatizácia začína reakciou na udalosť.
Od monitorovania prejdeme k termínu s názvom Pozorovateľnosť. Posledných pár rokov je okolo tohto slova tiež mierny humbuk. A málokto chápe, čo to znamená mimo kontextu. Ale hlavným bodom je, že pozorovateľnosť je metrikou transparentnosti systému. Ak sa niečo pokazilo, ako rýchlo viete určiť, čo presne sa pokazilo a aký bol v danom momente stav systému. Z hľadiska kódu: ktorá funkcia zlyhala, ktorá služba zlyhala. Aký bol stav napríklad interných premenných, konfigurácie. Z hľadiska infraštruktúry ide o to, v ktorej zóne dostupnosti došlo k zlyhaniu, a ak máte nejaký Kubernetes, tak v ktorom podu k zlyhaniu došlo, aký bol stav podu. A teda Observability má priamy vzťah s MTTR. Čím vyššia je viditeľnosť služby, tým ľahšie je identifikovať chybu, tým ľahšie je opraviť chybu, tým ľahšie je automatizovať chybu, tým nižšia je MTTR.
Ak sa opäť presunieme k malým firmám, veľmi často sa aj teraz pýtajú, čo s veľkosťou tímu a či je potrebné najať samostatné SRE v malom tíme. Už som o tom hovoril trochu skôr. V prvých fázach vývoja startupu alebo napríklad tímu to vôbec nie je potrebné, pretože zo SRE možno urobiť prechodnú rolu. A tým to trošku oživí, lebo je tam aspoň nejaká rôznorodosť. A navyše pripraví ľudí na to, že s ich rastom sa vo všeobecnosti budú povinnosti SRE veľmi výrazne meniť. Ak najmete človeka, tak má, samozrejme, nejaké očakávania. A tieto očakávania sa časom nezmenia, ale požiadavky sa budú veľmi meniť. Preto je najímanie SRE v počiatočných fázach dosť ťažké. Je oveľa jednoduchšie vychovať si vlastné. Ale stojí to za zamyslenie.
Jedinou výnimkou je pravdepodobne situácia, keď sú veľmi prísne a presne definované požiadavky na výšku. To znamená, že v prípade startupu by to mohol byť nejaký tlak investorov, nejaká prognóza rastu niekoľkokrát naraz. Potom je prenájom SRE vo všeobecnosti opodstatnený, pretože sa dá ospravedlniť. Máme požiadavky na rast, potrebujeme človeka, ktorý bude zodpovedný za to, aby sa s takýmto rastom nič nezlomilo.
Ešte jedna otázka. Čo robiť, keď vývojári niekoľkokrát seknú funkciu, ktorá prejde testami, ale pokazí produkt, načíta databázu, poruší ďalšie funkcie, aký proces implementovať. Preto sa v tomto prípade zavádza rozpočet pre chyby. A niektoré služby, niektoré funkcie sú testované okamžite vo výrobe. To môže byť kanárik, keď len malý počet používateľov, no už vo výrobe, nasadzuje nejakú funkciu, no s očakávaním, že ak sa niečo pokazí napríklad pol percenta všetkých používateľov, stále sa to zmestí do rozpočet na chyby. V súlade s tým áno, dôjde k chybe, pre niektorých používateľov sa všetko pokazí, ale už sme povedali, že je to normálne.
Bola tu otázka týkajúca sa nástrojov SRE. To znamená, existuje niečo špecifické, čo by SRE používali, čo by všetci ostatní nepoužívali? V skutočnosti existujú niektoré vysoko špecializované nástroje, existuje nejaký softvér, ktorý napríklad simuluje zaťaženie alebo robí kanárske A/B testovanie. Ale v zásade sú nástroje SRE to, čo už vaši vývojári používajú. Pretože SRE interaguje priamo s vývojovým tímom. A ak máte rôzne nástroje, ukazuje sa, že synchronizácia si vyžaduje čas. Najmä ak SRE pracujú vo veľkých tímoch, vo veľkých spoločnostiach, kde môže byť viacero tímov, tu veľmi pomôže celofiremná štandardizácia, pretože ak 50 tímov používa 50 rôznych utilít, znamená to, že SRE ich musí poznať všetky. A to sa samozrejme nikdy nestane. A výrazne sa zníži kvalita práce, kvalita kontroly aspoň niektorých tímov.
Náš webinár sa postupne chýli ku koncu. Podarilo sa mi povedať pár základných vecí. Samozrejme, nič o SRE sa nedá povedať a pochopiť za hodinu. Dúfam však, že sa mi podarilo sprostredkovať tento spôsob myslenia, hlavné kľúčové body. A potom, ak máte záujem, môžete sa hlbšie ponoriť do témy, študovať na vlastnú päsť a pozrieť sa, ako ju implementujú iní ľudia v iných spoločnostiach. A preto začiatkom februára príďte k nám do Slurm SRE.
Slurm SRE je trojdňový intenzívny kurz, ktorý pokryje približne to, o čom teraz hovorím, no s oveľa väčšou hĺbkou, s reálnymi prípadmi, s praxou je celý intenzívny zameraný na praktickú prácu. Ľudia budú rozdelení do tímov. Všetci budete pracovať na skutočných prípadoch. Preto máme inštruktorov z Booking.com Ivana Kruglova a Bena Tylera. Máme úžasného Evgeniyho Varabbasa z Google zo San Francisca. A ja vám tiež niečo poviem. Tak nás určite príďte navštíviť.
Takže zoznam referencií. Na SRE sú odkazy. na tej istej knihe, alebo skôr na 2 knihách o SRE, ktoré napísal Google. Ďalší , kde sú pojmy a ich aplikácia vysvetlené trochu podrobnejšie. Ďalšie 3 sú správy o SRE v rôznych spoločnostiach. Najprv - , to je hlavná poznámka Bena Trainera z Google. druhá - . Tretia je opäť o . Štvrtá správa z , ktorá má len 5 kľúčových zamestnancov SRE v 190 krajinách. Je veľmi zaujímavé pozrieť sa na toto všetko, pretože tak ako DevOps znamená pre rôzne spoločnosti a dokonca rôzne tímy veľmi odlišné veci, SRE má veľmi odlišné zodpovednosti, dokonca aj v spoločnostiach podobnej veľkosti.
2 ďalšie odkazy o princípoch chaosového inžinierstva: , . A na konci sú 3 zoznamy zo série Awesome Lists o , o a asi . Zoznam na SRE je neuveriteľne obrovský, nemusíte ho celý prechádzať, je tam asi 200 článkov. Dôrazne odporúčam články o kapacitnom plánovaní a bezúhonnej posmrtnom konaní.
Zaujímavý článok:
Ďakujem, že ma celý ten čas počúvaš. Dúfam, že ste sa niečo naučili. Dúfam, že máte dostatok materiálov, aby ste sa naučili ešte viac. A uvidíme sa neskôr. Dúfam, že vo februári.
Hostiteľom webinára bol Eduard Medvedev.
PS: pre tých, ktorí radi čítajú, Eduard poskytol zoznam referencií. Vítaní sú tí, ktorí to chcú pochopiť v praxi .
Zdroj: hab.com