Hlavní principy a postupy SRE: cykly zlepšování
Pokud je skutečně pravda, že v nějakém smyslu "jste to, co děláte", pak jsme se dostali do srdce tohoto modulu. V této lekci se podíváme na dva postupy, které jsou často považovány za základní pro praxi SRE. Oba pocházejí z principu, že je důležité vytvořit "virtuózní cykly". Cykly zlepšování v tomto kontextu jsou postupy, které vytvářejí smyčky zpětné vazby v organizaci, které organizaci pomáhají průběžně zlepšovat. Na těchto dvou postupech máme celé následující moduly, takže se na povrch podíváme jen s přehledem každého z těchto postupů.
Cyklus zlepšování č.1: SLI a SLO
Dříve v tomto modulu jsme zdůraznili náš bod práce na "odpovídající úrovni spolehlivosti". Tato část je přesně místem, kde se tento koncept přináší.
Řekněme, že máte novou službu, kterou plánujete přenést do produkce (buď ta, která byla vytvořena, nebo ta, která je stále v procesu plánování). V rámci tohoto procesu je důležité se rozhodnout o požadované spolehlivosti. Pokud nepíšete celý kód sami, tato rozhodnutí se provádějí (a tento bod je zásadní) ve spolupráci s vývojáři, kteří to dělají.
Prvním rozhodnutím je, co bychom měli použít jako indikátory stavu služby (ukazatel úrovně služeb nebo SLI)? Dalším způsobem, jak se na tuto otázku zeptat, je "Jak víte, kdy je to v pořádku?". Existuje mnoho způsobů, jak sledovat SLI a podrobněji se podíváme později. Obvykle se ale jedná o tyto ukazatele:
- Úspěch vs. míry selhání. Úspěšně dokončila služba operaci v procentech času?
- Míry načasování. Vrátili jsme odpověď v určité prahové hodnotě času?
- Míry propustnosti Zpracovali jsme určité množství dat?
Nebo některé kombinace všech těchto měr.
Jednoduchý příklad může být, že jako SLI pro naši službu stanovíme, jak často byl vrácen úspěch – signalizováno kódem HTTP 200 (oproti kódu 500 nebo jinému kódu).
Teď, když máme jasný indikátor, který nám řekne, jak služba dělá. Chceme rozhodnout, jakou úroveň spolehlivosti od ní očekáváme nebo si přejeme. Očekáváme například, že v průběhu jednoho dne uvidíme míru selhání 20 % ze služby? Tohle kulaté a velké číslo tu používáme čistě proto, že do začátku se nám tu při vysvětlování s ním bude v příkladech dobře pracovat. V pozdějších modulech zvýšíme složitost a přesnost příkazů, jako je tato ("kteří uživatelé vidí tuto chybovost? někdo z nich? většina z nich?" a tak dále). Toto očekávání, opět vypracované ve spolupráci s vývojářem služby, je cíl úrovně služby (SLO, Service Level Objective).
SLO musí být něco, co můžete v monitorovacím systému přesně měřit a prezentovat. Má to být cíl, dobře pochopitelného cíle pro spolehlivost služby, jaké je číslo, které je dostatečně dobré? Žádné spekulace „...přišlo mi, že služba minulý týden docela jela, ale těžko říct...“ Služba buď splňuje své kritérium SLO, nebo ho nesplňuje. Data musí hovořit jasně. Pokud služba své SLO nesplňuje (zejména pokud to nastává opakovaně v delším časovém období), pak je něco špatně a je potřeba to řešit.
Rozpočty chyb
Můžeme si uvědomit, že organizace se může přichytit k akci, pokud služba nesplňuje své cíle úrovně služeb. SRE ale tento koncept přenese do budoucna dalším krokem v případech, kdy je cíl úrovně služby splněn nebo překročen. Některé organizace využívají SLO k sestavení takzvaných „rozpočtů chyb“.
Abychom si tuto myšlenku demonstrovali, použijeme ukázkovou službu, kterou jsme probírali, a její SLO 80 % úspěchu (můžeme brát, jako že „musí být v provozu až 80 % času“). SLO 80% provozuschopnosti deklaruje, že naše služba musí být v provozu až 80 % času. Ale co těch zbývajících 20 %? Pokud je naše služba zbývajících 20 % času mimo provoz, moc nám na tom nezáleží, protože jsme rozhodli, že provozuschopnost po těchto dalších 20 % času není pro náš cíl služby důležitá.
Takže pokud nám nezáleží, co se během této doby bude dít, co můžeme se službou dělat? Jednou z věcí, které určitě můžeme dělat, je rozvířit běžící službu tím, že ji upgradujeme, například novou verzí přinášející další funkce. Pokud tato nová verze bude fungovat a nebude způsobovat dodatečné výpadky, skvěle. Pokud tato nová verze způsobí, že služba bude méně stabilní a vrátí chyby dalších 10 % času při ladění, stále je v pořádku. Pohybujeme se v rámci našeho rozpočtu povolené nespolehlivosti.
Rozpočet chyb je rozdíl mezi potenciální perfektní spolehlivostí služby a její žádanou spolehlivostí (100 % - 80 % = 20 %). V tomto případě nám rozpočet chyb dává fond 20% nespolehlivosti 20 % času, kdy "nezajímáme, jestli je to v provozu, nebo ne, protože je stále ve specifikaci". Můžeme se na to spolehnout a strávit 20 % času libovolným způsobem (možná s dalšími verzemi), dokud se nevyčerpá stejně jako jakýkoli jiný rozpočet.
Rozpočty chyb se používají také v některých organizacích v méně šťastných případech, když se nedosahuje požadované SLO. V takovém případě se můžete rozhodnout udělat něco trochu přísnějšího než jen "provést akci". Řekněme, že naše služba měla nějaké problémy a byla provozuschopná jen 60 % času, jak nám to signalizují ukazatele SLI, které jsme zvolili dříve. To znamená, že služba nedosáhla svého cíle (SLO). Naše služba vyčerpala svůj rozpočet chyb. Organizace se může rozhodnout odložit plánované vydání nové verze, protože ví, že další modifikace systému by v tuto chvíli pravděpodobně vedly jen k dalšímu zhoršení situace ohledně spolehlivosti. Rozpočty chyb se obvykle počítají po stanovenou dobu; měsíc, čtvrtletí a tak dále. Postupně, takže pokud se spolehlivost služby zlepší, vrátí se tento rozpočet.
Během této doby vyměněných verzí se organizace může rozhodnout, že některé technické prostředky přenese mimo vývoj funkcí směrem k práci na spolehlivosti. S cílem pomoci odhalit a zlepšit zdroj problémů, které způsobily, že služba vystřelila své SLO.
Důvod, proč mluvíme v souvislosti s rozpočty chyb o „některých organizacích“, je, že implementace těchto rozpočtů je docela náročná, obzvlášť v případě jejich použití s omezeným uváděním nové verze. Je tedy nutná vyšší úroveň nasazení ze strany organizace, což je ne v každé organizaci splněno. Pokud se organizace musí setkat s rozhodnutím o vydání, musí být ochotná vydržet vydání, pokud spolehlivost služby k dnešnímu dni nebyla v provozu. Toto rozhodnutí není jediné, co by všechny organizace ochotny učinit. Toto rozhodnutí také není jedinou možnou odpovědí na rozpočet chyb, který je vyčerpána, ale je to ta nejmluvnější.
V samostatném modulu si podrobněji probereme rozpočty SLI, SLO a chyb. Je ale vhodné zde zdůraznit aspekt cyklu virtuózního cyklu těchto postupů. Teoreticky poskytuje organizaci způsob, jak popsat, komunikovat a reagovat na spolehlivost služby. Při práci tak, aby všichni pracovali na lepší spolehlivosti. Tento cyklus pozitivní zpětné vazby může být až neuvěřitelně důležitý.
Cyklus zlepšování č. 2: Analýza po incidentu bez obviňování
Myšlenka postmortemu – retrospektivní analýza významné, obvykle nežádoucí události – není ani vzdáleně specifická pro techniky spolehlivosti lokality. Ani v normálním provozu není něčím výjimečným. V případě SRE je ovšem kladem obzvláště důraz na specifikum, že tato analýza musí být bez obviňování. Je třeba zaměřit na selhání procesu nebo technologie, které k incidentu vedlo, ne na akce konkrétních lidí. „Kde je problém v našem procesu, že umožnil X udělat tuhle věc, která vedla k selhání? Jaké informace scházely této osobě, nebo je zrovna neměla pohotově před očima v daný moment, že jí to převedlo k nesprávnému závěru? Jaké mantinely by měly být zavedeny, aby takové katastrofické selhání nebylo možné?" Tyto otázky jsou seřazené v bezobvižné postmortem.
Klíčové je, kam tyto otázky směřují. Hledáme způsoby, jak zlepšit systémy nebo procesy, nikoli způsoby, jak potrestat jednotlivce, jejichž používání těchto systémů nebo procesů v dobré víře přispělo k výpadku. Je důležité si uvědomit, že sice můžete někoho vyhodit, ale rozhodně se neprovyhazujete ke spolehlivému provozu. V naší zkušenosti organizace, která vyhodí člověka pokaždé, když dojde k produkčnímu incidentu (s několika výjimkami), se z těchto incidentů nevyučuje. Místo toho zůstali s jedním jednotlivcem, zatřesávali se v rohu a báli se, že se vůbec něco změní.
Naopak fungující proces analýzy po incidentu bez obviňování vede v organizaci k pozitivní zpětné vazbě v cyklu zlepšování. Umožňuje organizaci učit se z výpadků a průběžně zlepšovat své systémy (zajištění správné analýzy a následného provádění).
Tento vztah k chybám a chybám, které organizace přijala jako příležitosti pro učení a zlepšování, je základním principem přípravy spolehlivosti lokalit. Dalším je nastavení cyklů zlepšování, aby byly tyto příležitosti řádně využity a organizace směřovala k vyšší spolehlivosti.
Pojďme se podívat na některé další principy a postupy, které jsou zaměřené na lidskou stranu SRE, v naší další lekci.