SRE inženýr - praktikant
Pro začátek mi dovolte, abych se představil. já - , front-end inženýr ve skupině GitLab. Minulý týden jsem měl tu čest být na stáži u jednoho z našich inženýrů SRE ve službě. Cílem bylo denně pozorovat, jak služebník reaguje na incidenty, a získat skutečné pracovní zkušenosti. Rádi bychom, aby naši inženýři lépe rozuměli potřebám uživatelů Monitor::Zdraví.
Musel jsem týden sledovat SRE. To znamená, že jsem byl přítomen předání povinnosti, pozoroval stejné varovné kanály a reagoval na incidenty, pokud a kdy k nim došlo.
Incidenty
Během týdne došlo ke 2 incidentům.
1. Kryptominer
GitLab.com zaznamenal ve středu skok v používání 'a, způsobené pokusy využít běžcovy minuty pro těžbu kryptoměn. Incident byl vyřešen pomocí vlastního zmírňujícího nástroje, který zastaví běžcovy úkoly a odstraní projekt a účet s ním spojený.
Pokud by tato událost nebyla zaznamenána, automatický nástroj by ji zachytil, ale v tomto případě si porušení všiml nejprve technik SRE. Byla vytvořena úloha incidentu, ale informace v ní jsou uzavřeny.
2. Snížení výkonu aplikací Canary a Main
Incident byl podpořen zpomalením a zvýšenou chybovostí v kanárcích a hlavních webových aplikacích na Gitlab.com. Bylo porušeno několik hodnot Apdex.
Otevřít úkol po incidentu:
Klíčová zjištění
Zde je několik bodů, které jsem se naučil během týdne služby.
1. Upozornění jsou nejužitečnější při zjišťování odchylek od normy.
Oznámení lze rozdělit do několika typů:
- Výstrahy založené na určité prahové hodnotě, například „10 chyb 5xx za sekundu“.
- Upozornění, kde prahová hodnota je procentuální hodnota, jako například „chybovost 5xx na 10 % celkových požadavků v daném čase“.
- Upozornění založená na historickém průměru, jako je „5xx chyb v 90. percentilu“.
Obecně řečeno, typy 2 a 3 jsou užitečnější pro SRE ve službě, protože odhalují abnormality v procesu.
2. Mnoho výstrah nikdy neeskaluje k incidentům
Inženýři SR řeší neustálý proud výstrah, z nichž mnohé nejsou ve skutečnosti kritické.
Proč tedy neomezit upozornění pouze na skutečně důležitá? S tímto přístupem však mohou být přehlédnuty rané příznaky toho, co se stane sněhovou koulí ve skutečný problém, který hrozí velkými škodami.
Úkolem SRE ve službě je určit, které výstrahy skutečně znamenají něco vážného a zda je třeba je eskalovat a začít řešit. Domnívám se, že je to také kvůli nepružnosti výstrah: bylo by lepší, kdybychom zavedli několik úrovní nebo „chytrých“ způsobů přizpůsobení výstrah podle výše popsané situace.
Návrh funkce:
3. Naše SRE používají spoustu nástrojů
Vnitřní:
- Infraprojekt GitLab: Runbooky žijí zde, předávání na směny/týden, úkoly reakce na incidenty.
- Problémy GitLab: Vyšetřování, debriefing a údržba jsou také sledovány v problémech.
- Štítky GitLab: Úlohy automatizace jsou spouštěny konkrétními štítky, které roboti používají ke sledování aktivity úkolu.
Externí:
- Upozornění PagerDuty
- Slack: Zde jde tok zpráv PagerDuty/AlertManager. Integrace s příkazy lomítka pro provádění různých úkolů, jako je uzavření výstrahy nebo eskalace na incident.
- Grafana: vizualizace metrik se zaměřením na dlouhodobé trendy.
- Kibana: poskytuje vizualizaci/prohledávání protokolů, možnost proniknout hlouběji do určitých událostí.
- Zoom: V Zoomu je stálá "oddělovací místnost". To umožňuje SRE rychle diskutovat o událostech bez plýtvání drahocenným časem vytvářením místnosti a propojováním členů.
A mnoho mnoho dalších.
4. Monitorování GitLab.com pomocí GitLab je jediným bodem selhání
Pokud na GitLab.com dojde k velkému výpadku služby, nechceme, aby to ovlivnilo naši schopnost problém vyřešit. Lze jej zastavit spuštěním druhé instance GitLab pro správu GitLab.com. Ve skutečnosti nám to již funguje: .
5. Několik funkcí ke zvážení přidání do GitLabu
- , podobně jako Dokumenty Google. To by pomohlo při úkolech incidentů během události, stejně jako při úkolech s debriefingem. V obou případech může několik účastníků potřebovat přidat něco v reálném čase najednou.
- Další webhooky pro úkoly. Možnost spouštět různé kroky pracovního postupu GitLab zevnitř vám pomůže snížit vaši závislost na integracích Slack. Například možnost povolit výstrahu v PagerDuty pomocí příkazu lomítko v problému GitLab.
Závěr
Inženýři SRE to mají těžké s mnoha složitostmi. Bylo by skvělé vidět více produktů GitLab, které řeší tyto problémy. Již pracujeme na některých doplňcích produktu, které usnadní výše uvedené pracovní postupy. Díly jsou k dispozici v .
V roce 2020 rozšiřujeme tým, abychom spojili všechny tyto skvělé funkce. Pokud máte zájem, podívejte se a s jakýmikoli dotazy se neváhejte obrátit na někoho z našeho týmu.
Zdroj: www.habr.com