SRE inženýr – stážista
Nejprve dovolte, abych se představil. Jsem , frontend inženýr ve skupině GitLab. Minulý týden jsem měl tu čest být stážistou jedné z našich pohotovostních SRE inženýrů. Cílem bylo každodenní sledování reakce pohotovostního inženýra na incidenty a získání reálné pracovní zkušenosti. Chtěli bychom, aby naši inženýři lépe chápali potřeby uživatelů. Monitor::Health.
Měl jsem možnost sledovat SRE inženýra celý týden. To znamenalo, že jsem byl přítomen při předání směny, sledoval jsem stejné upozornění a reagoval na incidenty, pokud nějaké nastaly.
Incidenty
Během týdne došlo k 2 incidentům.
1. Kryptoměnový miner
Ve středu jsme na GitLab.com zaznamenali nárůst využívání vyplývající z pokusů využít minuty runnera pro těžbu kryptoměn. Incident jsme vyřešili pomocí našeho vlastního nástroje k neutralizaci porušení, který zastavuje úkoly runnera a odstraňuje s nimi spojený projekt a účet.
Kdyby si tohoto události nikdo nevšiml, zachytil by ho automatizovaný nástroj, ale v tomto případě porušení jako první zpozoroval SRE inženýr. Byla vytvořena úloha k incidentu, nicméně informace o ní jsou neveřejné.
2. Degradace výkonu aplikací Canary a Main
Incident vyvolaly zpomalení a zvýšená frekvence chyb v canary a main webových aplikacích na Gitlab.com. Bylo narušeno několik hodnot Apdex.
Otevřená úloha k incidentu:
Klíčové poznatky
Zde je několik bodů, které jsem si uvědomil během týdne na pohotovosti.
1. Upozornění jsou nejvíce užitečná, když detekují odchylky od normy.
Upozornění lze rozdělit do několika typů:
- Upozornění založená na konkrétní prahové hodnotě, například 'došlo k 10 5xx chybám za sekundu'.
- Upozornění, kde je prahová hodnota procento, například 'frekvence 5xx chyb na 10% celkového objemu požadavků v daném čase'.
- Upozornění založená na historickém průměrném hodnotě, například '5xx chyby v 90. percentilu'.
Obecně platí, že 2. a 3. typ jsou užitečnější pro pohotovostní SRE, protože odhalují odchylky od normy v procesu.
2. Mnoho upozornění se nikdy neeskaluje do incidentů
SRE inženýři čelí neustálému toku upozornění, z nichž mnohá ve skutečnosti nejsou kritická.
Tak proč omezit upozornění pouze na opravdu důležitá? S takovým přístupem však může být obtížné rozeznat počáteční příznaky, které mohou přerůst v reálný problém s vážnými důsledky.
Úkolem hlídkujícího SRE je určovat, která upozornění skutečně znamenají něco vážného a zda je třeba je eskalovat a začít se jimi zabývat. Mám za to, že to je způsobeno také neflexibilitou upozornění: bylo by lepší zavést několik úrovní nebo "inteligentní" způsoby konfigurace upozornění podle dříve popsané situace.
Návrh na funkci:
3. Naši hlídkující SRE používají mnoho nástrojů
Interní:
- GitLab infra projekt: zde žijí Runbooky, předání služby na směnu/týden, úkoly k reakcím na incidenty.
- GitLab issues: vyšetřování, analýzy a údržba jsou také sledovány v úkolech.
- GitLab štítky: úkoly automatizace se spouštějí podle určitých štítků, podle kterých boti sledují aktivitu úkolů.
Externí:
- PagerDuty: upozornění
- Slack: sem směřuje tok zpráv z PagerDuty/AlertManageru. Integrace se slash příkazy pro plnění různých úkolů, jako je uzavření upozornění nebo eskalace na incident.
- Grafana: vizualizace metrik se zaměřením na dlouhodobé trendy.
- Kibana: poskytuje vizualizaci/hledání v protokolech, možnost hlouběji zkoumat konkrétní události.
- Zoom: máme neustále běžící "diskusní místnost" na Zoomu. To umožňuje SRE inženýrům rychle probírat události, aniž by trávili cenný čas vytvářením místnosti a posíláním odkazů účastníkům.
A mnoho, mnoho dalšího.
4. Monitorování GitLab.com pomocí GitLab — je to jediný bod selhání
Pokud dojde na GitLab.com k větší poruše služeb, nechtěli bychom, aby to ovlivnilo naši schopnost vyřešit problém. Ten lze zmírnit spuštěním druhého instance GitLab pro řízení GitLab.com. Ve skutečnosti už to u nás funguje: .
5. Několik funkcí, které by měly být zváženy k přidání do GitLab
- , podobně jako Google Docs. To by pomohlo při úlohách na incidenty během události, stejně jako při analytických úlohách. V obou případech může několik účastníků potřebovat přidat něco v reálném čase.
- Více webhooks pro úkoly. Možnost spouštět různé kroky pracovního postupu GitLab zevnitř pomůže snížit závislost na integracích Slack. Například schopnost povolit upozornění v PagerDuty pomocí příkazové řádky v úkolu GitLab.
Závěr
SRE inženýři to nemají jednoduché kvůli mnoha složitostem. Bylo by skvělé vidět více produktů GitLab, které by řešily tyto problémy. Již pracujeme na některých přídavcích k produktu, které usnadní výše zmíněné pracovní postupy. Podrobnosti najdete v .
V roce 2020 rozšiřujeme tým, abychom shromáždili všechny tyto skvělé funkce. Pokud máte zájem, prosím, podívejte se na , a neváhejte kontaktovat někoho z našeho týmu s jakýmikoli dotazy.
Zdroj: habr.com
