SRE (Site Reliability Engineering) je prístup k zabezpečeniu dostupnosti webových projektov. Považuje sa za rámec pre DevOps a hovorí o tom, ako dosiahnuť úspech pri uplatňovaní postupov DevOps. Preklad v tomto článku knihy od spoločnosti Google. Tento preklad som pripravil sám a opieral som sa o vlastné skúsenosti s pochopením monitorovacích procesov. V telegramovom kanáli и Zverejnil som aj odkaz na preklad 4. kapitoly tej istej knihy o cieľoch úrovne služieb.
Preklad kat. Užívať si čítanie!
Tímy SRE spoločnosti Google majú základné princípy a osvedčené postupy na vytváranie úspešných systémov monitorovania a upozornení. Táto kapitola poskytuje návod, s akými problémami sa môže návštevník webovej stránky stretnúť a ako vyriešiť problémy, ktoré sťažujú zobrazovanie webových stránok.
vymedziť
Na diskusiu o témach súvisiacich s monitorovaním sa nepoužíva jednotný slovník. Ani na Googli sa nižšie uvedené výrazy bežne nepoužívajú, uvedieme však najčastejšie výklady.
monitorovanie
Zhromažďovanie, spracovanie, agregácia a zobrazovanie kvantitatívnych údajov o systéme v reálnom čase: počet požiadaviek a typy požiadaviek, počet chýb a typov chýb, čas spracovania požiadaviek a doba prevádzky servera.
Monitorovanie bielej skrinky
Monitorovanie založené na metrikách zobrazených internými systémovými komponentmi vrátane protokolov, metrík profilovania Java Virtual Machine alebo metrík obsluhy HTTP, ktoré generujú interné štatistiky.
Monitorovanie čiernej skrinky
Testovanie správania aplikácie z pohľadu používateľa.
Dashboard
Rozhranie (zvyčajne webové), ktoré poskytuje prehľad kľúčových zdravotných indikátorov služieb. Prístrojová doska môže mať filtre, možnosť vybrať zobrazené indikátory atď. Rozhranie je navrhnuté tak, aby identifikovalo indikátory, ktoré sú pre používateľov najdôležitejšie. Prístrojová doska môže tiež zobrazovať informácie pre pracovníkov technickej podpory: rad požiadaviek, zoznam chýb s vysokou prioritou a prideleného inžiniera pre danú oblasť zodpovednosti.
Upozornenie (upozornenie)
Oznámenia určené na príjem osoby prostredníctvom e-mailu alebo iných prostriedkov, ktoré môžu byť spustené chybami alebo zvýšením počtu žiadostí. Oznámenia sú klasifikované ako: lístky, e-mailové upozornenia a správy okamžitých správ.
Príčina
Chyba softvéru alebo ľudská chyba, ktorá by sa po odstránení už nemala opakovať. Problém môže mať niekoľko hlavných príčin: nedostatočná automatizácia procesov, softvérová chyba, nedostatočné prepracovanie aplikačnej logiky. Každý z týchto faktorov môže byť hlavnou príčinou a každý z nich musí byť odstránený.
Uzol a stroj (uzol a stroj)
Zameniteľné výrazy označujúce jednu inštanciu spustenej aplikácie na fyzickom serveri, virtuálnom počítači alebo kontajneri. Jeden stroj môže hostiť niekoľko služieb. Služby môžu byť:
- navzájom prepojené: napríklad server vyrovnávacej pamäte a webový server;
- nesúvisiace služby na jednom hardvéri: napríklad úložisko kódu a sprievodca pre konfiguračný systém, ako napr. alebo .
Tlačiť
Akákoľvek zmena v konfigurácii softvéru.
Prečo je potrebné monitorovanie?
Existuje niekoľko dôvodov, prečo je potrebné sledovať aplikácie:
Analýza dlhodobých trendov
Aká veľká je databáza a ako rýchlo rastie? Ako sa mení denný počet používateľov?
Porovnanie výkonu
Sú požiadavky rýchlejšie na Acme Bucket of Bytes 2.72 v porovnaní s Ajax DB 3.14? O čo lepšie sú požiadavky uložené do vyrovnávacej pamäte po objavení sa ďalšieho uzla? Funguje stránka pomalšie v porovnaní s minulým týždňom?
Upozornenie
Niečo sa pokazilo a niekto to musí opraviť. Alebo sa niečo čoskoro pokazí a niekto to musí čoskoro skontrolovať.
Vytváranie informačných panelov
Dashboardy by mali zodpovedať základné otázky a obsahovať niečo z — oneskorenia (latencia), premávka (premávka), chyby (chyby) a veľkosť zaťaženia (saturácia).
Vykonávanie retrospektívnej analýzy (ladenie)
Oneskorenie spracovania žiadosti sa zvýšilo, ale čo sa ešte stalo približne v rovnakom čase?
Monitorovacie systémy sú užitočné ako zdroj údajov pre systémy business intelligence a na uľahčenie analýzy bezpečnostných incidentov. Pretože sa táto kniha zameriava na inžinierske oblasti, v ktorých majú SRE odborné znalosti, nebudeme tu diskutovať o technikách monitorovania.
Monitorovanie a výstrahy umožňujú systému oznámiť vám, kedy došlo k poruche alebo k poruche. Keď sa systém nedokáže automaticky opraviť, chceme, aby človek analyzoval výstrahu, určil, či je problém stále aktívny, vyriešil ho a určil hlavnú príčinu. Ak nekontrolujete komponenty systému, nikdy nedostanete upozornenie jednoducho preto, že „niečo vyzerá trochu divne“.
Zaťažovať človeka notifikáciami je dosť drahé využitie času zamestnanca. Ak zamestnanec pracuje, upozornenie preruší pracovný proces. Ak je zamestnanec doma, upozornenie preruší osobný čas a prípadne spánok. Keď sa upozornenia vyskytujú príliš často, zamestnanci ich prelistujú, odložia alebo ignorujú prichádzajúce upozornenia. Z času na čas ignorujú skutočnú výstrahu, ktorá je maskovaná hlukovými udalosťami. Servisné prerušenia môžu trvať dlhé časové obdobia, pretože hlukové udalosti bránia rýchlej diagnostike a náprave problému. Efektívne varovné systémy majú dobrý pomer signálu k šumu.
Stanovenie primeraných očakávaní pre monitorovací systém
Nastavenie monitorovania pre komplexnú aplikáciu je samo o sebe komplexnou inžinierskou úlohou. Dokonca aj so značnou infraštruktúrou nástrojov na zhromažďovanie, zobrazovanie a upozorňovanie, tím Google SRE s 10 až 12 členmi zvyčajne zahŕňa jedného alebo dvoch ľudí, ktorých primárnym účelom je budovať a udržiavať monitorovacie systémy. Tento počet sa postupom času znižoval, keď konsolidujeme a centralizujeme monitorovaciu infraštruktúru, ale každý tím SRE má zvyčajne aspoň jednu osobu, ktorá sa venuje výlučne monitorovaniu. Musíme povedať, že aj keď sú panely monitorovacieho systému celkom zaujímavé na pohľad, tímy SRE sa starostlivo vyhýbajú situáciám, ktoré vyžadujú, aby sa niekto pozrel na obrazovku, aby mohol sledovať problémy.
Celkovo spoločnosť Google prešla na jednoduché a rýchle monitorovacie systémy s optimálnymi nástrojmi na následnú analýzu. Vyhýbame sa „magickým“ systémom, ktoré sa snažia predpovedať prahové hodnoty alebo automaticky odhaliť hlavnú príčinu. Jediným protipríkladom sú senzory, ktoré detegujú neúmyselný obsah v požiadavkách koncových používateľov; Pokiaľ sú tieto senzory jednoduché, dokážu rýchlo odhaliť príčiny vážnych anomálií. Iné formáty na používanie údajov z monitorovania, ako je plánovanie kapacít alebo prognózovanie dopravy, sú zložitejšie. Pozorovanie počas veľmi dlhého časového obdobia (mesiace alebo roky) pri nízkej vzorkovacej frekvencii (hodiny alebo dni) odhalí dlhodobý trend.
Tím Google SRE mal zmiešaný úspech so zložitými hierarchiami závislostí. Málokedy používame pravidlá ako „ak zistím, že databáza je pomalá, dostanem upozornenie, že databáza je pomalá, inak dostanem upozornenie, že stránka je pomalá.“ Pravidlá založené na závislostiach sa zvyčajne vzťahujú na nemenné časti nášho systému, ako je napríklad systém na filtrovanie návštevnosti dátového centra používateľov. Napríklad „ak je nakonfigurované filtrovanie návštevnosti do dátového centra, neupozorňovať ma na oneskorenia pri spracovaní požiadaviek používateľov“ je jedno zo všeobecných pravidiel pre výstrahy z dátového centra. Len málo tímov v spoločnosti Google podporuje komplexné hierarchie závislostí, pretože naša infraštruktúra sa neustále refaktoruje.
Niektoré z myšlienok popísaných v tejto kapitole sú stále aktuálne: vždy existuje možnosť rýchlejšieho prechodu od symptómu k hlavnej príčine, najmä v neustále sa meniacich systémoch. Preto, zatiaľ čo táto kapitola načrtáva niektoré ciele pre monitorovacie systémy a ako tieto ciele dosiahnuť, je dôležité, aby monitorovacie systémy boli jednoduché a zrozumiteľné pre každého v tíme.
Podobne, aby sa udržali nízke hladiny hluku a vysoké úrovne signálov, prístupy k monitorovaniu aktív musia byť veľmi jednoduché a spoľahlivé. Pravidlá, ktoré generujú varovania pre ľudí, by mali byť ľahko pochopiteľné a mali by predstavovať jasný problém.
Symptómy verzus príčiny
Váš monitorovací systém by mal zodpovedať dve otázky: „čo sa pokazilo“ a „prečo sa pokazilo“.
„Čo sa zlomilo“ hovorí o symptóme a „prečo sa to zlomilo“ hovorí o príčine. V tabuľke nižšie sú uvedené príklady takýchto spojení.
Symptóm
dôvod
Získava sa chyba HTTP 500 alebo 404
Databázové servery odmietajú pripojenia
Pomalé odpovede servera
Vysoké využitie procesora alebo poškodený ethernetový kábel
Používatelia v Antarktíde nedostávajú obrázky GIF pre mačky
Vaša CDN nenávidí vedcov a mačky, takže niektoré IP adresy skončili na čiernej listine
Súkromný obsah je dostupný odkiaľkoľvek
Uvedenie nového vydania softvéru spôsobilo, že brána firewall zabudla na všetky zoznamy ACL a nechala všetkých dnu
„Čo“ a „prečo“ sú niektoré z najdôležitejších stavebných kameňov na vytvorenie dobrého monitorovacieho systému s maximálnym signálom a minimálnym šumom.
Black-box vs White-box
Pre kritické metriky kombinujeme rozsiahle monitorovanie White-box so skromným monitorovaním Black-box. Najjednoduchší spôsob, ako porovnať Black-box a White-box, je ten, že Black-box je zameraný na symptómy a je skôr reaktívny ako proaktívne monitorovanie: „systém práve teraz nefunguje správne“. White-box závisí od interných overovacích schopností systémov: protokolov udalostí alebo webových serverov. White-box vám teda umožňuje odhaliť blížiace sa problémy, poruchy, ktoré sa javia ako opätovné odoslanie požiadavky atď.
Všimnite si, že vo viacvrstvovom systéme je symptóm v oblasti zodpovednosti jedného inžiniera symptómom v oblasti zodpovednosti iného inžiniera. Napríklad výkon databázy sa znížil. Pomalé čítanie databázy je príznakom databázy SRE, ktorá ich zisťuje. Avšak pre front-end SRE, ktorý pozoruje pomalú webovú stránku, je príčinou rovnako pomalého čítania databázy pomalá databáza. Preto je monitorovanie bielej skrinky niekedy zamerané na symptómy a niekedy na príčinu, v závislosti od toho, aké je rozsiahle.
Pri zhromažďovaní telemetrie na ladenie sa vyžaduje monitorovanie White-box. Ak webové servery pomaly reagujú na databázové dotazy, musíte vedieť, ako rýchlo webový server komunikuje s databázou a ako rýchlo reaguje. V opačnom prípade nebudete môcť rozlíšiť medzi pomalým databázovým serverom a problémom siete medzi webovým serverom a databázou.
Monitorovanie čiernej skrinky má pri odosielaní upozornení kľúčovú výhodu: upozornenie príjemcovi spustíte, keď problém už vyústil do skutočných príznakov. Na druhej strane je monitoring zbytočný pri probléme Black-box, ktorý ešte nevznikol, ale hrozí.
Štyri zlaté signály
Štyri zlaté monitorovacie signály sú latencia, návštevnosť, chyby a saturácia. Ak môžete merať iba štyri metriky používateľského systému, zamerajte sa na tieto štyri.
Oneskorenie
Čas potrebný na vybavenie žiadosti. Je dôležité rozlišovať medzi latenciou úspešných a neúspešných žiadostí. Napríklad chyba HTTP 500 spôsobená stratou pripojenia k databáze alebo inému backendu môže byť diagnostikovaná veľmi rýchlo, chyba HTTP 500 však môže indikovať neúspešnú požiadavku. Určenie vplyvu chyby 500 na celkovú latenciu môže viesť k chybným záverom. Na druhej strane, pomalá chyba je dokonca rýchla chyba! Preto je dôležité skôr monitorovať latenciu chýb, než len chyby filtrovať.
prevádzka
Počet požiadaviek do vášho systému sa meria v systémových metrikách na vysokej úrovni. Pre webovú službu toto meranie zvyčajne predstavuje počet požiadaviek HTTP za sekundu vydelený povahou požiadaviek (napríklad statický alebo dynamický obsah). V prípade audio streamingového systému sa toto meranie môže zamerať na rýchlosť I/O siete alebo počet simultánnych relácií. V prípade úložného systému kľúč-hodnota by týmto meraním mohli byť transakcie alebo výsledky vyhľadávania za sekundu.
Chyby
Ide o mieru neúspešných žiadostí, ktoré sú explicitné (napr. HTTP 500), implicitné (napr. HTTP 200, ale kombinované s neplatným obsahom) alebo zásady (napr. „Ak ste zachytili odpoveď za jednu sekundu, každá jedna sekunda je chyba“). Ak kódy odozvy HTTP nie sú dostatočné na vyjadrenie všetkých poruchových stavov, môžu byť potrebné sekundárne (interné) protokoly na zistenie čiastočného zlyhania. Monitorovanie všetkých takýchto neúspešných žiadostí nemusí byť informatívne, zatiaľ čo komplexné systémové testy pomôžu odhaliť, že spracovávate nesprávny obsah.
Sýtosť
Metrika ukazuje, ako intenzívne sa vaša služba využíva. Toto je opatrenie monitorovania systému, ktoré identifikuje prostriedky, ktoré sú najviac obmedzené (napríklad v systéme s obmedzenou pamäťou zobrazuje pamäť, v systéme s obmedzením I/O zobrazuje počet vstupov/výstupov). Všimnite si, že mnohé systémy znižujú výkon skôr, ako dosiahnu 100% využitie, takže je dôležité mať cieľ využitia.
V zložitých systémoch môže byť saturácia doplnená meraniami záťaže vyššej úrovne: dokáže vaša služba správne zvládnuť dvojnásobnú návštevnosť, zvládnuť iba o 10 % vyššiu návštevnosť alebo zvládnuť ešte menšiu návštevnosť ako v súčasnosti? Pre jednoduché služby, ktoré nemajú parametre, ktoré menia zložitosť požiadavky (napríklad „Nič mi nedávajte“ alebo „Potrebujem jedinečné jediné monotónne celé číslo“), ktoré zriedka menia konfiguráciu, môže byť primeraná hodnota testu statického zaťaženia. Ako je však uvedené v predchádzajúcom odseku, väčšina služieb musí používať nepriame signály, ako je využitie CPU alebo šírka pásma siete, ktoré majú známu hornú hranicu. Zvyšujúca sa latencia je často hlavným indikátorom nasýtenia. Meranie 99. percentilového času odozvy v malom okne (napr. jedna minúta) môže poskytnúť veľmi skorý signál saturácie.
Nakoniec, saturácia je tiež spojená s predpoveďami o hroziacej saturácii, napríklad: „Zdá sa, že vaša databáza zaplní váš pevný disk za 4 hodiny.“
Ak zmeriate všetky štyri zlaté signály a keď sa vyskytne problém s niektorou z metrík (alebo v prípade saturácie blízky problém), upozorníte osobu, vaša služba bude viac-menej pokrytá monitorovaním.
Obavy o „chvost“ (alebo prístrojové vybavenie a výkon)
Pri vytváraní monitorovacieho systému od začiatku existuje pokušenie vyvinúť systém založený na priemerných hodnotách: priemerná latencia, priemerné využitie CPU uzlov alebo priemerná plnosť databázy. Nebezpečenstvo posledných dvoch príkladov je zrejmé: procesory a databázy sú likvidované veľmi nepredvídateľným spôsobom. To isté platí pre meškanie. Ak spustíte webovú službu s priemernou latenciou 100 ms s 1000 1 požiadavkami za sekundu, 5 % žiadostí môže trvať 99 sekúnd. Ak používatelia závisia od viacerých takýchto webových služieb, XNUMX. percentil jedného backendu sa môže ľahko stať strednou dobou odozvy frontendu.
Najjednoduchší spôsob, ako rozlíšiť medzi pomalým priemerom a veľmi pomalým koncom žiadostí, je zhromažďovať merania žiadostí vyjadrené v štatistikách (dobrý nástroj na zobrazenie sú histogramy), a nie skutočné latencie: koľko žiadostí služba obslúžila, ktoré trvalo medzi 0 ms a 10 ms, medzi 10 ms a 30 ms, medzi 30 ms a 100 ms, medzi 100 ms a 300 ms atď. Rozšírenie hraníc histogramu približne exponenciálne (približným faktorom 3) je často jednoduchý spôsob vizualizácie distribúcie žiadostí.
Výber vhodnej úrovne detailov pre merania
Rôzne prvky systému sa musia merať na rôznych úrovniach detailov. Napríklad:
- Monitorovanie využitia CPU počas určitého časového obdobia neukáže dlhodobé špičky, ktoré vedú k vysokým latenciám.
- Na druhej strane, pre webovú službu, ktorá nie je zameraná na viac ako 9 hodín výpadku za rok (99,9 % ročná dostupnosť), bude kontrola odpovede HTTP 200 viac ako raz alebo dvakrát za minútu pravdepodobne zbytočne častá.
- Podobne pravdepodobne nie je potrebné kontrolovať miesto na pevnom disku na 99,9% dostupnosť viac ako raz za 1-2 minúty.
Dávajte pozor na to, ako štruktúrujete granularitu svojich meraní. Zhromažďovanie zaťaženia CPU raz za sekundu môže poskytnúť zaujímavé údaje, ale takéto časté merania môžu byť veľmi nákladné na zber, ukladanie a analýzu. Ak váš cieľ monitorovania vyžaduje vysokú úroveň podrobnosti a nevyžaduje vysokú odozvu, tieto náklady môžete znížiť nastavením zhromažďovania metrík na serveri a následným nastavením externého systému na zhromažďovanie a agregáciu týchto metrík. Mohol by si:
- Zmerajte zaťaženie procesora každú sekundu.
- Znížte detaily na 5 %.
- Súhrnné metriky každú minútu.
Táto stratégia vám umožní zhromažďovať údaje s vysokou granularitou bez toho, aby ste museli mať vysoké náklady na analýzu a úložisko.
Čo najjednoduchšie, ale nie jednoduchšie
Prekrývanie rôznych požiadaviek na seba môže viesť k veľmi zložitému monitorovaciemu systému. Váš systém môže mať napríklad tieto komplikujúce prvky:
- Výstrahy podľa rôznych prahov pre latenciu spracovania požiadaviek, v rôznych percentiloch, pre všetky typy rôznych indikátorov.
- Napísanie dodatočného kódu na zistenie a identifikáciu možných príčin.
- Vytvorte súvisiace informačné panely pre každú z možných príčin problémov.
Zdroje potenciálnych komplikácií nikdy nekončia. Ako všetky softvérové systémy, aj monitorovanie môže byť také zložité, že sa stáva krehkým a ťažko sa mení a udržiava.
Svoj monitorovací systém preto navrhnite tak, aby ste ho čo najviac zjednodušili. Pri výbere toho, čo chcete sledovať, majte na pamäti nasledovné:
- Pravidlá, ktoré najčastejšie zachytávajú skutočné incidenty, by mali byť čo najjednoduchšie, predvídateľné a spoľahlivé.
- Konfigurácia zberu, agregácie a varovania údajov, ktorá sa vykonáva zriedkavo (napríklad menej ako štvrťročne pre niektoré tímy SRE), by sa mala odstrániť.
- Metriky, ktoré sa zhromažďujú, ale nezobrazujú sa na žiadnom paneli ukážky ani nepoužívajú žiadne upozornenia, sú kandidátmi na odstránenie.
V Google funguje zber a agregácia základných metrík v kombinácii s upozorneniami a informačnými panelmi dobre ako relatívne samostatný systém (monitorovací systém Google je v skutočnosti rozdelený do niekoľkých podsystémov, ale ľudia si zvyčajne uvedomujú všetky aspekty týchto podsystémov). Môže byť lákavé skombinovať monitorovanie s inými technikami na skúmanie zložitých systémov: podrobné profilovanie systému, ladenie procesov, sledovanie podrobností o výnimkách alebo zlyhaniach, testovanie záťaže, zber a analýza protokolov alebo kontrola premávky. Zatiaľ čo väčšina z týchto vecí má spoločné znaky so základným monitorovaním, ich zmiešanie bude mať za následok príliš veľa výsledkov a vytvorí zložitý a krehký systém. Rovnako ako u mnohých iných aspektov vývoja softvéru je najlepšou stratégiou podpora rôznych systémov s jasnými, jednoduchými, voľne spojenými integračnými bodmi (napríklad použitie webového rozhrania API na získanie súhrnných údajov vo formáte, ktorý môže zostať konzistentný počas dlhého časového obdobia. ).
Spájanie princípov
Princípy diskutované v tejto kapitole možno skombinovať do filozofie monitorovania a varovania, ktorú schvaľujú a dodržiavajú tímy Google SRE. Dodržiavanie tejto filozofie monitorovania je žiaduce, je dobrým východiskovým bodom pre vytváranie alebo revíziu vašej metodiky varovania a môže vám pomôcť klásť správne otázky týkajúce sa vašej prevádzkovej funkcie bez ohľadu na veľkosť vašej organizácie alebo zložitosť služby alebo systému.
Pri vytváraní pravidiel monitorovania a varovania vám môže položenie nasledujúcich otázok pomôcť vyhnúť sa falošným pozitívam a zbytočným upozorneniam:
- Zisťuje toto pravidlo inak nezistiteľný stav systému, ktorý je naliehavý, vyzýva na akciu a nevyhnutne ovplyvňuje používateľa?
- Môžem toto varovanie ignorovať s vedomím, že je neškodné? Kedy a prečo môžem toto upozornenie ignorovať a ako sa tomuto scenáru môžem vyhnúť?
- Znamená toto upozornenie, že používatelia sú negatívne ovplyvnení? Existujú situácie, keď používatelia nie sú negatívne ovplyvnení, napríklad prostredníctvom filtrovania návštevnosti alebo pri používaní testovacích systémov, pre ktoré by sa mali filtrovať upozornenia?
- Môžem v reakcii na toto upozornenie podniknúť kroky? Sú tieto opatrenia naliehavé alebo môžu počkať do rána? Dá sa akcia bezpečne zautomatizovať? Bude táto akcia dlhodobým riešením alebo krátkodobým obídením?
- Niektorí ľudia dostávajú viacero upozornení na tento problém, existuje teda spôsob, ako znížiť počet upozornení?
Tieto otázky odrážajú základnú filozofiu výstražných a varovných systémov:
- Vždy, keď príde upozornenie, musím okamžite reagovať. Dokážem urgentne reagovať aj niekoľkokrát za deň, kým sa neunavím.
- Každé upozornenie musí byť relevantné.
- Každá reakcia na výstrahu si musí vyžadovať ľudský zásah. Ak je možné oznámenie spracovať automaticky, nemalo by prísť.
- Upozornenia by sa mali týkať nového problému alebo udalosti, ktorá predtým neexistovala.
Tento prístup stiera určité rozdiely: ak výstraha spĺňa predchádzajúce štyri podmienky, nezáleží na tom, či je výstraha odoslaná z monitorovacieho systému White-box alebo Black-Box. Tento prístup tiež posilňuje určité rozdiely: je lepšie vynaložiť oveľa viac úsilia na identifikáciu symptómov ako na príčiny; pokiaľ ide o príčiny, musíte sa obávať iba nevyhnutných príčin.
Dlhodobé sledovanie
V dnešnom prostredí produktivity monitorovacie systémy monitorujú neustále sa vyvíjajúci produkčný systém s meniacou sa softvérovou architektúrou, charakteristikami pracovného zaťaženia a výkonnostnými cieľmi. Upozornenia, ktoré je v súčasnosti ťažké zautomatizovať, sa môžu stať samozrejmosťou, možno dokonca stojí za to ich riešiť. V tomto bode musí niekto nájsť a odstrániť základné príčiny problému; ak takéto riešenie nie je možné, odpoveď na výstrahu si vyžaduje plnú automatizáciu.
Je dôležité, aby sa rozhodnutia o monitorovaní robili s ohľadom na dlhodobé ciele. Každé upozornenie, ktoré sa spustí dnes, odvádza pozornosť človeka od zajtrajšieho zlepšovania systému, takže často dochádza k zníženiu dostupnosti alebo výkonu produktívneho systému na čas potrebný na zlepšenie monitorovacieho systému z dlhodobého hľadiska. Pozrime sa na dva príklady na ilustráciu tohto javu.
Bigtable SRE: A Tale of Over-Alert
Interná infraštruktúra spoločnosti Google sa zvyčajne poskytuje a meria podľa úrovne služieb (SLO). Pred mnohými rokmi bola služba SLO spoločnosti Bigtable založená na priemernom výkone syntetickej transakcie simulujúcej živého klienta. V dôsledku problémov v Bigtable a nižších úrovniach zásobníka úložného priestoru bol priemerný výkon poháňaný „veľkým“ chvostom: najhorších 5 % dopytov bolo často výrazne pomalších ako zvyšok.
E-mailové upozornenia sa odosielali, keď sa blížila hranica SLO, a pri prekročení SLO sa odosielali upozornenia služby Messenger. Oba typy upozornení boli odosielané pomerne často, čo si vyžiadalo neprijateľné množstvo inžinierskeho času: tím strávil značné množstvo času triedením upozornení, aby našiel tých niekoľko, ktoré boli skutočne relevantné. Často nám unikol problém, ktorý skutočne ovplyvnil používateľov, pretože iba niektoré z upozornení sa týkali tohto konkrétneho problému. Mnohé z upozornení neboli urgentné z dôvodu pochopiteľných problémov v infraštruktúre a boli spracované štandardným spôsobom, prípadne neboli spracované vôbec.
Na nápravu situácie tím zvolil trojaký prístup: Počas usilovnej práce na zlepšení výkonu Bigtable sme dočasne nastavili náš cieľ SLO na 75. percentil latencie odpovede na dopyt. Vypli sme aj e-mailové upozornenia, pretože ich bolo toľko, že nebolo možné stráviť čas ich diagnostikou.
Táto stratégia nám umožnila začať odstraňovať dlhodobé problémy v Bigtable a nižších úrovniach zásobníka úložného priestoru namiesto neustáleho odstraňovania taktických problémov. Inžinieri mohli skutočne vykonávať prácu bez toho, aby boli neustále bombardovaní výstrahami. V konečnom dôsledku nám dočasné odloženie spracovania upozornení umožnilo zlepšiť kvalitu našich služieb.
Gmail: Predvídateľné, algoritmické ľudské reakcie
Pri svojom zrode bol Gmail postavený na upravenom systéme riadenia procesov Workqueue, ktorý bol navrhnutý na dávkové spracovanie častí indexu vyhľadávania. Workqueue bol prispôsobený dlhodobým procesom a následne aplikovaný na Gmail, ale niektoré chyby v nepriehľadnom kóde plánovača sa veľmi ťažko opravovali.
V tom čase bolo monitorovanie Gmailu štruktúrované tak, aby sa pri zrušení jednotlivých úloh pomocou Workqueue spúšťali upozornenia. Tento prístup nebol ideálny, pretože už v tom čase Gmail vykonával mnoho tisíc úloh, z ktorých každá bola poskytnutá zlomku percenta našich používateľov. Veľmi nám záležalo na tom, aby sme používateľom Gmailu poskytli dobrú používateľskú skúsenosť, no spracovanie toľkých upozornení bolo mimo dosahu.
Na vyriešenie tohto problému vytvoril Gmail SRE nástroj, ktorý pomôže čo najlepšie odladiť plánovač, aby sa minimalizoval dopad na používateľov. Tím mal niekoľko diskusií o tom, či jednoducho zautomatizovať celý cyklus od objavenia problému cez nápravu, kým sa nenájde dlhodobé riešenie, no niektorí sa obávali, že takéto riešenie by oddialilo skutočné vyriešenie problému.
Toto napätie bolo v tíme bežné a často odrážalo nedostatok dôvery v sebadisciplínu: kým niektorí členovia tímu chcú nechať čas na správnu opravu, iní sa obávajú, že na konečnú opravu sa zabudne a dočasná oprava bude trvať večnosť. Tento problém si zaslúži pozornosť, pretože je príliš jednoduché dočasne vyriešiť problémy namiesto toho, aby bola situácia trvalá. Manažéri a technický personál zohrávajú kľúčovú úlohu pri implementácii dlhodobých opráv, podporujú a uprednostňujú potenciálne dlhodobé opravy aj po odznení počiatočnej „bolesti“.
Pravidelné, opakujúce sa upozornenia a algoritmické reakcie by mali byť varovným signálom. Neochota vášho tímu automatizovať tieto upozornenia znamená, že tím nemá istotu, že môže dôverovať algoritmom. Ide o vážny problém, ktorý treba riešiť.
Dlhý termín
Príklady Bigtable a Gmail spája spoločná téma: súťaž medzi krátkodobou a dlhodobou dostupnosťou. Často môže silné úsilie pomôcť krehkému systému dosiahnuť vysokú dostupnosť, ale táto cesta je zvyčajne krátkodobá, plná vyhorenia tímu a závislosti od malého počtu členov toho istého hrdinského tímu.
Kontrolované, krátkodobé zníženie dostupnosti je často bolestivé, ale strategicky dôležité pre dlhodobú stabilitu systému. Je dôležité nepozerať sa na každú výstrahu izolovane, ale zvážiť, či celková úroveň objemu výstrah vedie k zdravému, správne dostupnému systému so životaschopným tímom a priaznivou prognózou. Štatistiku frekvencie výstrah (zvyčajne vyjadrenú ako incidenty na smenu, kde incident môže pozostávať z viacerých súvisiacich incidentov) analyzujeme v štvrťročných správach pre manažment, čo umožňuje osobám s rozhodovacou právomocou mať priebežný prehľad o zaťažení výstražného systému a celkovom zdraví tímu.
Záver
Cesta k zdravému monitorovaniu a varovaniu je jednoduchá a jasná. Zameriava sa na symptómy problému, ktoré spúšťajú výstrahy, a sledovanie príčiny slúži ako pomôcka pri ladení problémov. Monitorovanie symptómov je tým jednoduchšie, čím vyššie ste v zásobníku, ktorý ovládate, aj keď monitorovanie záťaže a výkonu databázy by sa malo vykonávať priamo v databáze samotnej. E-mailové upozornenia majú veľmi obmedzenú užitočnosť a majú tendenciu sa ľahko stať šumom; namiesto toho by ste mali použiť dashboard, ktorý monitoruje všetky aktuálne problémy, ktoré spúšťajú e-mailové upozornenia. Prístrojovú dosku je možné spárovať aj s protokolom udalostí na analýzu historických korelácií.
Z dlhodobého hľadiska je potrebné dosiahnuť úspešnú rotáciu upozornení na symptómy a hroziace skutočné problémy, prispôsobiť ciele tak, aby monitorovanie podporovalo rýchlu diagnostiku.
Ďakujem, že ste si preklad prečítali až do konca. Prihláste sa na odber môjho telegramového kanála o monitorovaní и .
Zdroj: hab.com