SRE-mérnök — gyakornok
Először is, hadd mutatkozzak be. Én vagyok , front-end mérnök a csoportban a GitLabnál. A múlt héten megtiszteltetés volt, hogy gyakornok lehettem az egyik ügyeletes SRE-mérnökünknél. A cél az volt, hogy naponta figyeljem, hogyan reagál az ügyeletes incidensekre, és valós tapasztalatot szerezzek. Szeretnénk, ha mérnökeink jobban megértenék a felhasználók igényeit Monitor::Health.
Egy hétig mindenhová követnem kellett az SRE-mérnököt. Tehát jelen voltam az ügyelet átadásánál, figyeltem ugyanazokat a figyelmeztetési csatornákat, és reagáltam az incidensekre, ha és amikor azok történtek.
Incidensek
A hét során 2 incidens történt.
1. Kriptobányász
Szerdán a GitLab.com-on ugrásszerű növekedést regisztráltak a GitLab Runner használatában, amelyet az indítványozott kriptovaluta-bányászat kísérletei okoztak. Az incidens megoldásához saját megszüntető eszközünket használtuk, amely leállítja a runner feladatokat és eltávolítja a kapcsolódó projektet és fiókot. Ha ezt az eseményt nem vették volna észre, automatizált eszköz elkaptatta volna, de ebben az esetben az SRE-mérnök észlelte a problémát először. Incidens feladat készült, de az információ titkosított.
2. Canary és Main alkalmazások teljesítménycsökkenése
Az incidens általában lassulásokkal és a hibák fokozott gyakoriságával volt jellemző a GitLab.com canary és main webalkalmazásainál. Több Apdex érték is megsértődött.
Nyitott incidens feladat:
Kulcsfontosságú megállapítások
Íme néhány lényeges pont, amit megtanultam az ügyelet egy hete alatt.
1. A figyelmeztetések a legértékesebbek, amikor eltéréseket rögzítenek.
A figyelmeztetéseket több típusra lehet osztani:
Azokon a figyelmeztetéseken, amelyek egy adott küszöbértékre építenek, mint például „történt 10 5xx hiba másodpercenként”.
- Olyan figyelmeztetések, amelyeknél a küszöbérték egy százalékos érték, mint például „5xx hibák előfordulásának gyakorisága 10% az összes kérésből egy adott időszak alatt”.
- Olyan figyelmeztetések, amelyek történelmi átlagértéken alapulnak, mint például „5xx hibák a 90. percentilisben”.
- Általánosságban elmondható, hogy a 2. és 3. típusú figyelmeztetések hasznosabbak az ügyeletes SRE-k számára, mivel feltárják az eltéréseket a folyamat során.
2. Számos figyelmeztetést nem escalálnak incidensekké
2. Sok értesítés sosem kerül eszkalálásra eseményekké
Az SRE mérnökök folyamatos figyelmeztetésekkel foglalkoznak, amelyek közül sok valójában nem kritikus.
Miért ne korlátoznánk a figyelmeztetéseket csak az igazán fontosakra? Ezzel a megközelítéssel azonban lehet, hogy nem ismerjük fel a korai tüneteket, amelyek hókásaként nőhetnek egy valódi problémává, amely jelentős kárt okozhat.
Az SRE ügyelet feladata, hogy meghatározza, mely figyelmeztetések utalnak valóban komoly problémákra, és szükséges-e azokat eszkalálni, és elkezdeni a vizsgálatot. Gyanítom, hogy ez a figyelmeztetések rugalmasságának hiányából is adódik: jobb lenne, ha bevezetnének több szintet vagy „okos” módszereket a figyelmeztetések beállítására a fent említett helyzetekhez.
Funkciós ajánlás:
3. Ügyeletes SRE mérnökeink sok eszközt használnak
Belső:
- GitLab infra projekt: itt találhatók a Runbook-ok, a váltott/hetente történő ügyeletátadások, valamint a balesetekre adott válaszok feladatai.
- GitLab problémák: a vizsgálatok, elemzések és karbantartások szintén nyomon követhetők a feladatokban.
- GitLab címkék: az automatizálási feladatok bizonyos címkék alapján indulnak, amelyeket a botok követnek nyomon a feladatok aktivitásával kapcsolatban.
Külső:
- PagerDuty: figyelmeztetések
- Slack: itt érkezik a PagerDuty/AlertManager üzenetek áramlása. Integráció a /slack parancsokkal különböző feladatok végrehajtására, például: figyelmeztetés lezárása vagy eszkalálás incidensé.
- Grafana: metrikák vizualizálása a hosszú távú trendekre összpontosítva.
- Kibana: lehetőséget ad a naplózási vizualizációra/kutatásra, lehetővé téve a részletesebb vizsgálódást bizonyos eseményekben.
- Zoom: folyamatosan működő „megbeszélő terem” van a Zoomban. Ez lehetővé teszi az SRE mérnökök számára, hogy gyorsan megbeszéljék az eseményeket, anélkül, hogy értékes időt pazarolnának terem létrehozására és résztvevőknek linkek küldésére.
És még sok, sok más.
4. GitLab.com felügyelete GitLab segítségével — ez az egypontos hibalehetőség
Ha a GitLab.com-on súlyos szolgáltatásmegszakítás történik, nem szeretnénk, ha ez befolyásolná a probléma megoldására való képességünket. Ezt lehet kontrollálni, ha elindítunk egy második GitLab példányt a GitLab.com kezelésére. Valójában ez már nálunk működik: .
5. Néhány funkció, amelyet érdemes megfontolni a GitLabhoz való hozzáadásra
- , hasonlóan a Google Docs-hoz. Ez segíthetne az eseményekkel kapcsolatos incidensek kezelésében, valamint a vizsgálati feladatokban. Mindkét esetben több résztvevőnek lehet szüksége arra, hogy valamit valós időben hozzáadjon.
- Több webhook a feladatokhoz. Az a lehetőség, hogy különféle GitLab munkafolyamat lépéseket indítsunk belülről, segíthet csökkenteni a Slack integrációktól való függőséget. Például a PagerDuty értesítésének engedélyezése egy slash-parancs segítségével a GitLab feladatban.
Zárás
Az SRE mérnökök számára sok bonyodalommal kell megküzdeniük. Jó lenne látni több GitLab terméket ezeknek a problémáknak a megoldásában. Már dolgozunk néhány funkció hozzáadásán, amely megkönnyíti a fent említett munkafolyamatokat. A részletek elérhetőek a .
2020-ban bővítjük a csapatot, hogy összegyűjtsük ezeket a nagyszerű funkciókat. Ha érdekel, kérlek, nézd meg a , és ne habozz kapcsolatba lépni a csapatunk bármely tagjával bármilyen kérdéssel.
Forrás: habr.com
