SRE (Site Reliability Engineering) je přístup k zajištění dostupnosti webových projektů. Je považován za rámec pro DevOps a hovoří o tom, jak dosáhnout úspěchu při uplatňování postupů DevOps. Překlad v tomto článku knihy od Googlu. Tento překlad jsem připravil sám a opíral jsem se o vlastní zkušenosti s pochopením monitorovacích procesů. V telegramovém kanálu и Také jsem zveřejnil odkaz na překlad 4. kapitoly téže knihy o cílech na úrovni služeb.
Překlad kat. Příjemné čtení!
Týmy SRE společnosti Google mají základní principy a doporučené postupy pro vytváření úspěšných systémů monitorování a upozornění. Tato kapitola poskytuje návod, s jakými problémy se může návštěvník webové stránky setkat a jak vyřešit problémy, které znesnadňují zobrazení webových stránek.
Definice
Neexistuje jediný slovník používaný k diskusi o tématech souvisejících s monitorováním. Ani na Googlu se níže uvedené výrazy běžně nepoužívají, ale uvedeme si nejčastější výklady.
Sledování
Sběr, zpracování, agregace a zobrazení kvantitativních dat o systému v reálném čase: počet požadavků a typů požadavků, počet chyb a typů chyb, doba zpracování požadavků a doba provozu serveru.
Monitorování bílé skříňky
Monitorování na základě metrik zobrazených interními systémovými komponentami, včetně protokolů, metrik profilování Java Virtual Machine nebo metrik HTTP handleru, které generují interní statistiky.
Monitorování černé skříňky
Testování chování aplikace z pohledu uživatele.
Přístrojová deska
Rozhraní (obvykle webové), které poskytuje přehled klíčových zdravotních ukazatelů služeb. Přístrojová deska může mít filtry, možnost vybrat zobrazené indikátory atd. Rozhraní je navrženo tak, aby identifikovalo indikátory, které jsou pro uživatele nejdůležitější. Řídicí panel může také zobrazovat informace pro pracovníky technické podpory: frontu požadavků, seznam chyb s vysokou prioritou a přiděleného inženýra pro danou oblast odpovědnosti.
Upozornění (oznámení)
Oznámení určená k přijímání osobou prostřednictvím e-mailu nebo jiných prostředků, která mohou být vyvolána chybami nebo zvýšením fronty žádostí. Oznámení jsou klasifikována jako: vstupenky, e-mailová upozornění a zprávy rychlých zpráv.
Příčina
Softwarová vada nebo lidská chyba, která by se po opravě neměla opakovat. Problém může mít několik hlavních příčin: nedostatečná automatizace procesů, softwarová závada, nedostatečné propracování aplikační logiky. Každý z těchto faktorů může být hlavní příčinou a každý z nich musí být odstraněn.
Uzel a stroj (uzel a stroj)
Zaměnitelné termíny označující jednu instanci spuštěné aplikace na fyzickém serveru, virtuálním počítači nebo kontejneru. Jeden stroj může hostit několik služeb. Služby mohou být:
- vzájemně propojené: například mezipaměťový server a webový server;
- nesouvisející služby na jednom hardwaru: například úložiště kódu a průvodce pro konfigurační systém, jako je např. nebo .
Tlačit
Jakákoli změna v konfiguraci softwaru.
Proč je nutné monitorování?
Existuje několik důvodů, proč je třeba aplikace monitorovat:
Analýza dlouhodobých trendů
Jak velká je databáze a jak rychle roste? Jak se mění denní počet uživatelů?
Srovnání výkonu
Jsou požadavky rychlejší na Acme Bucket of Bytes 2.72 ve srovnání s Ajax DB 3.14? O co lépe jsou požadavky ukládány do mezipaměti poté, co se objeví další uzel? Běží web pomaleji ve srovnání s minulým týdnem?
Upozornění (oznámení)
Něco je rozbité a někdo to musí opravit. Nebo se něco brzy rozbije a někdo to musí brzy zkontrolovat.
Vytváření dashboardů
Dashboardy by měly odpovídat na základní otázky a obsahovat něco z — zpoždění (latence), provoz (provoz), chyby (chyby) a velikost zatížení (saturace).
Provádění retrospektivní analýzy (ladění)
Zpoždění zpracování požadavku se prodloužilo, ale co dalšího se stalo přibližně ve stejnou dobu?
Monitorovací systémy jsou užitečné jako zdroj dat pro systémy business intelligence a pro usnadnění analýzy bezpečnostních incidentů. Protože se tato kniha zaměřuje na inženýrské oblasti, ve kterých mají SRE odborné znalosti, nebudeme zde diskutovat o technikách monitorování.
Monitorování a výstrahy umožňují systému, aby vám sdělil, kdy došlo k poruše nebo k poruše. Když se systém nemůže automaticky opravit, chceme, aby člověk výstrahu analyzoval, určil, zda je problém stále aktivní, vyřešil jej a určil hlavní příčinu. Pokud neprovádíte audit systémových komponent, nikdy neobdržíte upozornění jednoduše proto, že „něco vypadá trochu divně“.
Zatěžovat člověka notifikacemi je dost drahé využití času zaměstnance. Pokud zaměstnanec pracuje, upozornění přeruší pracovní proces. Pokud je zaměstnanec doma, upozornění přeruší osobní čas a případně spánek. Když se výstrahy objevují příliš často, zaměstnanci je prolétají, odkládají nebo ignorují příchozí výstrahy. Čas od času ignorují skutečnou výstrahu, která je maskována hlukovými událostmi. Přerušení služby může trvat dlouhou dobu, protože hlukové události brání rychlé diagnostice a nápravě problému. Efektivní varovné systémy mají dobrý poměr signálu k šumu.
Nastavení přiměřených očekávání pro monitorovací systém
Nastavení monitorování pro komplexní aplikaci je samo o sobě složitým inženýrským úkolem. I přes významnou infrastrukturu shromažďovacích, zobrazovacích a upozorňovacích nástrojů tým Google SRE složený z 10–12 členů obvykle zahrnuje jednoho nebo dva lidi, jejichž primárním účelem je budovat a udržovat monitorovací systémy. Toto číslo se postupem času snižovalo, jak konsolidujeme a centralizujeme infrastrukturu monitorování, ale každý tým SRE má obvykle alespoň jednu osobu, která se věnuje výhradně monitorování. Musíme říci, že zatímco řídicí panely monitorovacího systému jsou docela zajímavé na pohled, týmy SRE se pečlivě vyhýbají situacím, které vyžadují, aby se někdo díval na obrazovku, aby mohl sledovat problémy.
Celkově Google přešel na jednoduché a rychlé monitorovací systémy s optimálními nástroji pro následnou analýzu. Vyhýbáme se „magickým“ systémům, které se snaží předvídat prahové hodnoty nebo automaticky detekovat hlavní příčinu. Jediným protipříkladem jsou senzory, které detekují nezamýšlený obsah v požadavcích koncových uživatelů; Dokud tyto senzory zůstanou jednoduché, mohou rychle odhalit příčiny vážných anomálií. Jiné formáty pro použití monitorovacích dat, jako je plánování kapacit nebo prognózování provozu, jsou složitější. Pozorování po velmi dlouhé časové období (měsíce nebo roky) při nízké vzorkovací frekvenci (hodiny nebo dny) odhalí dlouhodobý trend.
Tým Google SRE zaznamenal smíšený úspěch se složitými hierarchiemi závislostí. Málokdy používáme pravidla jako „pokud zjistím, že databáze je pomalá, dostanu upozornění, že databáze je pomalá, jinak dostanu upozornění, že je web pomalý.“ Pravidla založená na závislosti obvykle odkazují na neměnné části našeho systému, jako je systém pro filtrování uživatelského provozu do datového centra. Například „pokud je nakonfigurováno filtrování provozu do datového centra, neupozorňovat mě na zpoždění při zpracování požadavků uživatelů“ je jedno obecné pravidlo pro výstrahy z datového centra. Jen málo týmů ve společnosti Google podporuje složité hierarchie závislostí, protože naše infrastruktura se neustále refaktoruje.
Některé z myšlenek popsaných v této kapitole jsou stále aktuální: vždy existuje příležitost přejít rychleji od příznaku k hlavní příčině, zvláště v neustále se měnících systémech. Proto, zatímco tato kapitola nastiňuje některé cíle pro monitorovací systémy a jak těchto cílů dosáhnout, je důležité, aby monitorovací systémy byly jednoduché a srozumitelné všem v týmu.
Podobně, aby se udržely nízké hladiny hluku a vysoké úrovně signálu, přístupy k monitorování aktiv, na které je upozorněno, musí být velmi jednoduché a spolehlivé. Pravidla, která generují varování pro lidi, by měla být snadno srozumitelná a měla by představovat jasný problém.
Příznaky versus příčiny
Váš monitorovací systém by měl odpovědět na dvě otázky: „co se rozbilo“ a „proč to prasklo“.
„Co se zlomilo“ mluví o příznaku a „proč se to zlomilo“ mluví o příčině. Níže uvedená tabulka ukazuje příklady takových připojení.
Symptom
důvod
Získává se chyba HTTP 500 nebo 404
Databázové servery odmítají připojení
Pomalé odezvy serveru
Vysoké využití CPU nebo poškozený ethernetový kabel
Uživatelé v Antarktidě nedostávají kočičí GIFy
Vaše CDN nenávidí vědce a kočky, takže některé IP adresy skončily na černé listině
Soukromý obsah je dostupný odkudkoli
Zavedení nové verze softwaru způsobilo, že firewall zapomněl na všechny ACL a nechal všechny dovnitř
„Co“ a „proč“ jsou některé z nejdůležitějších stavebních kamenů pro vytvoření dobrého monitorovacího systému s maximálním signálem a minimálním šumem.
Black-box vs White-box
Pro kritické metriky kombinujeme rozsáhlé monitorování White-box se skromným monitorováním Black-box. Nejjednodušší způsob, jak porovnat Black-box a White-box, je ten, že Black-box je zaměřen na symptomy a je spíše reaktivní než proaktivní monitorování: „systém právě teď nefunguje správně“. White-box závisí na interních ověřovacích schopnostech systémů: protokolech událostí nebo webových serverech. White-box vám tedy umožňuje odhalit hrozící problémy, chyby, které se jeví jako opakované odeslání požadavku atd.
Všimněte si, že ve vícevrstvém systému je příznak v oblasti odpovědnosti jednoho inženýra příznakem v oblasti odpovědnosti jiného inženýra. Snížil se například výkon databáze. Pomalé čtení databáze je příznakem databáze SRE, která je detekuje. U front-endového SRE pozorujícího pomalý web je však příčinou stejně pomalého čtení databáze pomalá databáze. Proto je sledování bílé skříňky někdy zaměřeno na symptomy a někdy na příčinu, v závislosti na tom, jak je rozsáhlé.
Při shromažďování telemetrie pro ladění je vyžadováno monitorování White-box. Pokud webové servery reagují na databázové dotazy pomalu, musíte vědět, jak rychle webový server komunikuje s databází a jak rychle reaguje. Jinak nebudete schopni rozlišit mezi pomalým databázovým serverem a síťovým problémem mezi webovým serverem a databází.
Sledování černé skříňky má klíčovou výhodu při odesílání výstrah: oznámení příjemci spustíte, když problém již vyústil ve skutečné příznaky. Na druhou stranu je monitoring k ničemu u problému Black-box, který ještě nevznikl, ale hrozí.
Čtyři zlaté signály
Čtyři zlaté monitorovací signály jsou latence, provoz, chyby a saturace. Pokud můžete měřit pouze čtyři systémové metriky uživatelů, zaměřte se na tyto čtyři.
Zpoždění
Čas potřebný ke zpracování žádosti. Je důležité rozlišovat mezi latencí úspěšných a neúspěšných požadavků. Například chyba HTTP 500 způsobená ztrátou připojení k databázi nebo jinému backendu může být diagnostikována velmi rychle, chyba HTTP 500 však může znamenat neúspěšný požadavek. Určení dopadu chyby 500 na celkovou latenci může vést k chybným závěrům. Na druhou stranu pomalá chyba je dokonce rychlá chyba! Proto je důležité spíše monitorovat latenci chyb než jen chyby filtrovat.
provoz
Počet požadavků na váš systém je měřen pomocí systémových metrik na vysoké úrovni. U webové služby toto měření obvykle představuje počet požadavků HTTP za sekundu vydělený povahou požadavků (například statický nebo dynamický obsah). U audio streamingového systému se toto měření může zaměřit na síťovou I/O rychlost nebo počet simultánních relací. U úložného systému klíč-hodnota mohou být tímto měřením transakce nebo výsledky vyhledávání za sekundu.
Chyby
Toto je míra neúspěšných požadavků, které jsou explicitní (např. HTTP 500), implicitní (např. HTTP 200, ale v kombinaci s neplatným obsahem) nebo zásady (např. „Pokud jste zachytili odpověď za jednu sekundu, každá jedna sekunda je chyba“). Pokud kódy odezvy HTTP nestačí k vyjádření všech poruchových stavů, mohou být pro detekci částečného selhání vyžadovány sekundární (interní) protokoly. Monitorování všech takových neúspěšných požadavků nemusí být informativní, zatímco end-to-end systémové testy pomohou odhalit, že zpracováváte nesprávný obsah.
Nasycení
Metrika ukazuje, jak intenzivně je vaše služba využívána. Toto je opatření pro monitorování systému, které identifikuje prostředky, které jsou nejvíce omezené (například v systému s omezenou pamětí zobrazuje paměť, v systému s omezeným vstupem/výstupem zobrazuje počet vstupů a výstupů). Všimněte si, že mnoho systémů snižuje výkon, než dosáhnou 100% využití, takže je důležité mít cíl využití.
Ve složitých systémech může být saturace doplněna měřením zátěže na vyšší úrovni: dokáže vaše služba správně zvládnout dvojnásobný provoz, zpracovat pouze o 10 % více provozu nebo zvládnout ještě menší provoz než v současnosti? U jednoduchých služeb, které nemají parametry, které mění složitost požadavku (například „Dej mi nic“ nebo „Potřebuji jedinečné jediné monotónní celé číslo“), které zřídka mění konfiguraci, může být adekvátní hodnota statického zátěžového testu. Jak je však uvedeno v předchozím odstavci, většina služeb musí používat nepřímé signály, jako je využití CPU nebo šířka pásma sítě, které mají známou horní hranici. Zvyšující se latence je často hlavním indikátorem saturace. Měření doby odezvy 99. percentilu v malém okně (např. jedna minuta) může poskytnout velmi časný signál saturace.
A konečně, saturace je také spojena s předpověďmi o nadcházející saturaci, například: „Vypadá to, že vaše databáze zaplní váš pevný disk za 4 hodiny.“
Pokud změříte všechny čtyři zlaté signály a když se vyskytne problém s jednou z metrik (nebo v případě saturace blízký problém), upozorníte osobu, vaše služba bude víceméně pokryta monitorováním.
Obavy o „ocas“ (nebo o vybavení a výkon)
Při vytváření monitorovacího systému od začátku existuje pokušení vyvinout systém založený na průměrných hodnotách: průměrná latence, průměrné využití CPU uzlů nebo průměrná zaplněnost databáze. Nebezpečí posledních dvou příkladů je zřejmé: procesory a databáze jsou likvidovány velmi nepředvídatelným způsobem. Totéž platí pro zpoždění. Pokud provozujete webovou službu s průměrnou latencí 100 ms s 1000 požadavky za sekundu, 1 % požadavků může trvat 5 sekund. Pokud jsou uživatelé závislí na více takových webových službách, může se 99. percentil jednoho backendu snadno stát střední dobou odezvy frontendu.
Nejjednodušší způsob, jak rozlišit mezi pomalým průměrem a velmi pomalým koncem požadavků, je shromažďovat měření požadavků vyjádřených ve statistikách (dobrý nástroj k zobrazení jsou histogramy) spíše než skutečné latence: kolik požadavků služba obsloužila, které trvalo mezi 0 ms a 10 ms, mezi 10 ms a 30 ms, mezi 30 ms a 100 ms, mezi 100 ms a 300 ms atd. Rozšíření hranic histogramu přibližně exponenciálně (přibližným faktorem 3) je často jednoduchý způsob, jak vizualizovat rozložení žádostí.
Výběr vhodné úrovně detailů pro měření
Různé prvky systému musí být měřeny na různých úrovních detailu. Například:
- Sledování využití CPU po určitou dobu neukáže dlouhodobé špičky, které vedou k vysokým latencím.
- Na druhou stranu u webové služby, která necílí na více než 9 hodin výpadku za rok (99,9 % roční doby provozuschopnosti), bude kontrola odpovědi HTTP 200 více než jednou nebo dvakrát za minutu pravděpodobně zbytečně častá.
- Stejně tak pravděpodobně není nutné kontrolovat místo na pevném disku pro 99,9% dostupnost více než jednou za 1-2 minuty.
Dávejte pozor na to, jak strukturujete granularitu svých měření. Sběr zatížení CPU jednou za sekundu může poskytnout zajímavá data, ale taková častá měření mohou být velmi nákladná na sběr, ukládání a analýzu. Pokud váš cíl monitorování vyžaduje vysokou granularitu a nevyžaduje vysokou odezvu, můžete tyto náklady snížit nastavením shromažďování metrik na serveru a poté nastavením externího systému pro shromažďování a agregaci těchto metrik. Mohl bys:
- Změřte zatížení procesoru každou sekundu.
- Snížit detaily na 5 %.
- Souhrnné metriky každou minutu.
Tato strategie vám umožní shromažďovat data s vysokou granularitou, aniž byste museli vynakládat vysoké náklady na analýzu a úložiště.
Co nejjednodušší, ale ne jednodušší
Překrytí různých požadavků na sebe může vést k velmi složitému monitorovacímu systému. Váš systém může mít například následující komplikující prvky:
- Upozornění podle různých prahových hodnot pro latenci zpracování požadavků, v různých percentilech, pro všechny typy různých indikátorů.
- Zápis dalšího kódu pro detekci a identifikaci možných příčin.
- Vytvořte související řídicí panely pro každou z možných příčin problémů.
Zdroje potenciálních komplikací nikdy nekončí. Stejně jako všechny softwarové systémy může být monitorování tak složité, že se stává křehkým a obtížně se mění a udržuje.
Navrhněte proto svůj monitorovací systém tak, aby byl co nejvíce zjednodušen. Při výběru toho, co chcete sledovat, mějte na paměti následující:
- Pravidla, která nejčastěji zachycují skutečné incidenty, by měla být co nejjednodušší, předvídatelná a spolehlivá.
- Konfigurace pro shromažďování dat, agregaci a upozornění, která se provádí zřídka (například méně než čtvrtletně u některých týmů SRE), by měla být odstraněna.
- Metriky, které jsou shromážděny, ale nejsou zobrazeny na žádném panelu náhledu nebo používané žádným upozorněním, jsou kandidáty na smazání.
Ve společnosti Google funguje sběr a agregace základních metrik v kombinaci s upozorněními a řídicími panely dobře jako relativně samostatný systém (monitorovací systém Google je ve skutečnosti rozdělen do několika podsystémů, ale lidé si obvykle uvědomují všechny aspekty těchto podsystémů). Může být lákavé kombinovat monitorování s jinými technikami pro zkoumání složitých systémů: podrobné profilování systému, ladění procesů, sledování podrobností o výjimkách nebo selháních, testování zátěže, sběr a analýza protokolů nebo kontrola provozu. Zatímco většina z těchto věcí má společné rysy se základním monitorováním, jejich smícháním bude výsledkem příliš mnoho výsledků a vznikne složitý a křehký systém. Stejně jako u mnoha jiných aspektů vývoje softwaru je nejlepší strategií podpora různých systémů s jasnými, jednoduchými, volně propojenými integračními body (například použití webového rozhraní API k načtení agregovaných dat ve formátu, který může zůstat konzistentní po dlouhou dobu ).
Spojení principů dohromady
Principy diskutované v této kapitole lze zkombinovat do filozofie monitorování a varování, kterou schvalují a dodržují týmy Google SRE. Dodržování této filozofie monitorování je žádoucí, je to dobrý výchozí bod pro vytváření nebo revizi vaší metodiky upozorňování a může vám pomoci klást správné otázky týkající se vaší provozní funkce, bez ohledu na velikost vaší organizace nebo složitost služby nebo systému.
Při vytváření pravidel monitorování a upozornění vám může položení následujících otázek pomoci vyhnout se falešným poplachům a zbytečným upozorněním:
- Detekuje toto pravidlo jinak nezjistitelný stav systému, který je naléhavý, vyzývá k akci a nevyhnutelně ovlivňuje uživatele?
- Mohu toto varování ignorovat s vědomím, že je neškodné? Kdy a proč mohu toto varování ignorovat a jak se tomuto scénáři mohu vyhnout?
- Znamená toto upozornění, že jsou uživatelé negativně ovlivněni? Existují situace, kdy uživatelé nejsou negativně ovlivněni, například prostřednictvím filtrování provozu nebo při použití testovacích systémů, pro které by měla být filtrována upozornění?
- Mohu v reakci na toto upozornění podniknout nějaké kroky? Jsou tato opatření naléhavá nebo mohou počkat do rána? Lze akci bezpečně zautomatizovat? Bude tato akce dlouhodobým řešením nebo krátkodobým řešením?
- Někteří lidé dostávají více upozornění na tento problém, existuje tedy způsob, jak počet upozornění snížit?
Tyto otázky odrážejí základní filozofii výstražných a varovných systémů:
- Pokaždé, když přijde upozornění, musím okamžitě reagovat. Dokážu několikrát denně naléhavě reagovat, než se unaví.
- Každé upozornění musí být relevantní.
- Každá reakce na výstrahu musí vyžadovat lidský zásah. Pokud lze oznámení zpracovat automaticky, nemělo by dorazit.
- Upozornění by se měla týkat nového problému nebo události, která dříve neexistovala.
Tento přístup stírá určité rozdíly: pokud výstraha splňuje předchozí čtyři podmínky, nezáleží na tom, zda je výstraha odeslána z monitorovacího systému White-box nebo Black-Box. Tento přístup také posiluje určité rozdíly: je lepší vynaložit mnohem více úsilí na identifikaci symptomů než na příčiny; pokud jde o příčiny, musíte se starat pouze o nevyhnutelné příčiny.
Dlouhodobé sledování
V dnešních produktivních prostředích monitorovací systémy monitorují neustále se vyvíjející produkční systém s měnící se softwarovou architekturou, charakteristikami pracovního zatížení a výkonnostními cíli. Výstrahy, které je v současné době obtížné automatizovat, se mohou stát běžnými, možná dokonce stojí za to je řešit. V tomto okamžiku musí někdo najít a odstranit základní příčiny problému; pokud takové řešení není možné, vyžaduje reakce na výstrahu plnou automatizaci.
Je důležité, aby rozhodnutí o monitorování byla činěna s ohledem na dlouhodobé cíle. Každá výstraha, která se dnes spustí, odvádí pozornost člověka od zítřejšího zlepšování systému, takže často dochází ke snížení dostupnosti nebo výkonu produktivního systému na dobu potřebnou ke zlepšení monitorovacího systému v dlouhodobém horizontu. Pro ilustraci tohoto jevu se podívejme na dva příklady.
Bigtable SRE: A Tale of Over-Alert
Interní infrastruktura společnosti Google je obvykle zajišťována a měřena podle úrovně služeb (SLO). Před mnoha lety byla služba SLO společnosti Bigtable založena na průměrném výkonu syntetické transakce simulující živého klienta. Kvůli problémům v Bigtable a nižším úrovním zásobníku úložiště byl průměrný výkon poháněn „velkým“ koncem: nejhorších 5 % dotazů bylo často výrazně pomalejších než zbytek.
E-mailová upozornění byla zasílána, když se přiblížila prahová hodnota SLO, a při překročení SLO byla odeslána upozornění messengeru. Oba typy výstrah byly zasílány poměrně často, což zabralo nepřijatelné množství inženýrského času: tým strávil značné množství času tříděním výstrah, aby našel těch několik, které byly skutečně relevantní. Často jsme přehlédli problém, který skutečně ovlivnil uživatele, protože pouze některá upozornění se týkala tohoto konkrétního problému. Řada upozornění nebyla urgentní kvůli pochopitelným problémům v infrastruktuře a byla zpracována standardním způsobem, nebo nebyla zpracována vůbec.
Aby tým napravil situaci, zvolil třístupňový přístup: Zatímco jsme usilovně pracovali na zlepšení výkonu Bigtable, dočasně jsme si stanovili cíl SLO na 75. percentil pro latenci odpovědi na dotaz. Vypnuli jsme také e-mailová upozornění, protože jich bylo tolik, že nebylo možné trávit čas jejich diagnostikou.
Tato strategie nám umožnila začít opravovat dlouhodobé problémy v Bigtable a nižších vrstvách zásobníku úložiště, místo abychom neustále opravovali taktické problémy. Inženýři mohli skutečně pracovat, aniž by byli neustále bombardováni výstrahami. Nakonec nám dočasné odložení zpracování výstrah umožnilo zlepšit kvalitu našich služeb.
Gmail: Předvídatelné, algoritmické lidské reakce
Při svém zrodu byl Gmail postaven na upraveném systému řízení procesů Workqueue, který byl navržen tak, aby dávkové zpracování částí indexu vyhledávání. Workqueue byla přizpůsobena dlouhodobým procesům a následně aplikována na Gmail, ale některé chyby v neprůhledném kódu plánovače bylo velmi obtížné opravit.
V té době bylo monitorování Gmailu strukturováno tak, aby se při zrušení jednotlivých úkolů pomocí Workqueue spouštěly výstrahy. Tento přístup nebyl ideální, protože i v té době Gmail prováděl mnoho tisíc úkolů, z nichž každý byl poskytnut zlomku procenta našich uživatelů. Velmi nás zajímalo, abychom uživatelům Gmailu poskytli dobrý uživatelský dojem, ale zpracování tolika upozornění bylo mimo dosah.
K vyřešení tohoto problému vytvořil Gmail SRE nástroj, který pomáhá co nejlépe odladit plánovač, aby se minimalizoval dopad na uživatele. Tým vedl několik diskusí o tom, zda jednoduše zautomatizovat celý cyklus od objevení problému přes nápravu, dokud nebude nalezeno dlouhodobé řešení, ale někteří se obávali, že takové řešení zdrží skutečné vyřešení problému.
Toto napětí bylo v týmu běžné a často odráželo nedostatek důvěry v sebekázeň: zatímco někteří členové týmu chtějí nechat čas na správnou opravu, jiní se obávají, že na konečnou opravu se zapomene a dočasná oprava bude trvat věčnost. Tento problém si zaslouží pozornost, protože je příliš snadné dočasně opravit problémy místo toho, aby byla situace trvalá. Manažeři a technický personál hrají klíčovou roli při zavádění dlouhodobých oprav, podporují a upřednostňují potenciálně dlouhodobé opravy i poté, co počáteční „bolest“ odezní.
Pravidelná, opakovaná upozornění a algoritmické reakce by měly být varovným signálem. Neochota vašeho týmu automatizovat tato upozornění znamená, že tým postrádá důvěru, že může důvěřovat algoritmům. To je vážný problém, který je třeba řešit.
Dlouhodobý
Příklady Bigtable a Gmail spojují společné téma: konkurence mezi krátkodobou a dlouhodobou dostupností. Často může silné úsilí pomoci křehkému systému dosáhnout vysoké dostupnosti, ale tato cesta je obvykle krátkodobá, plná vyhoření týmu a závislosti na malém počtu členů stejného hrdinského týmu.
Řízené, krátkodobé snížení dostupnosti je často bolestivé, ale strategicky důležité pro dlouhodobou stabilitu systému. Je důležité nedívat se na každou výstrahu izolovaně, ale zvážit, zda celková úroveň objemu výstrah vede ke zdravému, správně dostupnému systému s životaschopným týmem a příznivou prognózou. Analyzujeme statistiky frekvence výstrah (obvykle vyjádřené jako incidenty za směnu, kde incident může sestávat z více souvisejících incidentů) ve čtvrtletních zprávách pro vedení, což umožňuje osobám s rozhodovací pravomocí mít průběžný přehled o zatížení systému varování a celkovém stavu týmu.
Závěr
Cesta ke zdravému sledování a upozorňování je jednoduchá a jasná. Zaměřuje se na příznaky problému, které spouštějí výstrahy, a sledování příčiny slouží jako pomůcka při ladění problémů. Sledování příznaků je tím snazší, čím výše jste v zásobníku, který ovládáte, i když sledování zatížení a výkonu databáze by mělo být prováděno přímo v databázi samotné. E-mailová upozornění mají velmi omezenou užitečnost a mají tendenci se snadno stát šumem; místo toho byste měli používat řídicí panel, který monitoruje všechny aktuální problémy, které spouštějí e-mailová upozornění. Řídicí panel lze také spárovat s protokolem událostí pro analýzu historických korelací.
Z dlouhodobého hlediska je nutné dosáhnout úspěšného střídání výstrah o symptomech a hrozících skutečných problémech a přizpůsobit cíle tak, aby monitorování podporovalo rychlou diagnostiku.
Děkuji za přečtení překladu až do konce. Přihlaste se k odběru mého telegramového kanálu o monitorování и .
Zdroj: www.habr.com