SRE mérnök – gyakornok
Először is hadd mutassam be magam. én - , front-end mérnök a csoportban GitLab. Múlt héten abban a megtiszteltetésben volt részem, hogy az egyik ügyeletes SRE mérnökünknél dolgozhattam. A cél az volt, hogy megfigyeljük, hogyan reagál az ügyeletes napi rendszerességgel az eseményekre, és valós tapasztalatokat szerezzen a munka során. Szeretnénk, ha mérnökeink jobban megértenék a felhasználói igényeket Monitor::Egészség.
Egy hétig mindenhova követnem kellett az SRE mérnökét. Vagyis jelen voltam az átadáson, ugyanazokat a riasztási csatornákat figyeltem, és reagáltam az incidensekre, ha és amikor bekövetkeztek.
Incidensek
Egy héten belül 2 incidens történt.
1. Cryptominer
A GitLab.com szerdán ugrásszerűen megnőtt a használatban 'a, amelyet a futó perceinek kriptovaluta bányászására tett kísérletei okoztak. Az esetet saját szabálysértés-semlegesítő eszközünkkel kezeltük, amely leállítja a futó feladatait, és törli a hozzá tartozó projektet és fiókot.
Ha ezt az eseményt nem vették volna észre, egy automata eszköz elkapta volna, de ebben az esetben az SRE mérnöke vette észre először a szabálysértést. Létrejött egy eseményfeladat, de az arra vonatkozó információ le van zárva.
2. A Canary és a Main alkalmazások teljesítményének romlása
Az incidenst a lassulások és a megnövekedett hibák okozták a Gitlab.com kanári és fő webalkalmazásaiban. Számos Apdex értéket megsértettek.
Nyitott eseményfeladat:
Főbb megállapítások
Íme néhány dolog, amit megtanultam a heti ügyelet alatt.
1. A riasztások a normától való eltérések észlelésekor a leghasznosabbak.
A riasztások több típusra oszthatók:
- Egy bizonyos küszöbértéken alapuló figyelmeztetések, például „10 5xx hiba történt másodpercenként”.
- Figyelmeztetések, amelyeknél a küszöb százalékos érték, például „5xx hiba gyakorisága a kérelmek teljes mennyiségének 10%-án egy adott időpontban”.
- A korábbi átlagon alapuló figyelmeztetések, például „5xx hibák a 90. percentilisnél”.
Általánosságban elmondható, hogy a 2. és 3. típus hasznosabb az ügyeletes SRE-k számára, mivel a folyamat során a normától való eltéréseket mutatják.
2. Sok riasztás soha nem eszkalálódik incidenssé.
Az SR mérnökei folyamatos riasztásokkal foglalkoznak, amelyek közül sok valójában nem kritikus.
Tehát miért nem korlátozza a figyelmeztetéseket az igazán fontosakra? Ezzel a megközelítéssel azonban előfordulhat, hogy nem ismeri fel annak korai tüneteit, hogy mitől lesz egy valódi probléma, amely komoly károkat fenyeget.
Az ügyeleti SRE feladata annak meghatározása, hogy mely riasztások jeleznek valójában valami komolyat, és hogy kell-e ezeket fokozni és kezelni. Gyanítom, hogy ez a riasztások rugalmatlanságából is adódik: jobb lenne, ha több szinten vagy „okos” módon lehetne a riasztásokat a fent leírt helyzetnek megfelelően konfigurálni.
Funkciójavaslat:
3. Ügyeletes SRE-ink nagyon sok eszközt használnak.
Belső:
- GitLab infra projekt: itt élnek a runbookok, műszak/heti feladatok, eseményreakciós feladatok.
- GitLab problémák: A vizsgálatok, felülvizsgálatok és karbantartások is nyomon követhetők a problémákban.
- GitLab-címkék: Az automatizálási feladatok meghatározott címkék segítségével indulnak el, amelyeket a robotok a feladattevékenység nyomon követésére használnak.
Külső:
- PagerDuty: Figyelmeztetések
- Slack: A PagerDuty/AlertManager üzenetfolyam ide megy. Integráció perjel parancsokkal különféle feladatok végrehajtásához, például riasztások bezárásához vagy incidensig való eszkalációhoz.
- Grafana: mérőszámok megjelenítése a hosszú távú trendekre összpontosítva.
- Kibana: Vizualizálást/naplókeresést tesz lehetővé, lehetővé teszi, hogy mélyebbre ássunk konkrét eseményeket.
- Zoom: A Zoomban folyamatosan működik egy „kitörési szoba”. Ez lehetővé teszi az SRE mérnökei számára, hogy gyorsan megvitassák az eseményeket anélkül, hogy értékes időt pazarolnának egy szoba létrehozására és a résztvevők összekapcsolására.
És még sokan mások.
4. A GitLab.com figyelése a GitLab segítségével egyetlen hibapont
Ha a GitLab.com jelentős szolgáltatáskimaradást tapasztal, nem akarjuk, hogy ez befolyásolja a probléma megoldásának képességét. Megállítható egy második GitLab-példány elindításával a GitLab.com kezelésére. Valójában ez már működik nálunk: .
5. Néhány szolgáltatás, amelyet érdemes megfontolni a GitLab hozzáadásával
- , hasonló a Google Docshoz. Ez segítene az esemény közbeni incidensekkel kapcsolatos feladatokban, valamint az eligazítással kapcsolatos feladatokban. Mindkét esetben előfordulhat, hogy több résztvevőnek valós időben hozzá kell adnia valamit.
- További webhookok a feladatokhoz. A különböző GitLab-munkafolyamat-lépések belülről történő futtatása segít csökkenteni a Slack-integrációktól való függőséget. Például egy riasztás engedélyezése a PagerDuty programban perjel paranccsal egy GitLab-probléma esetén.
Következtetés
Az SRE mérnökei nehezen viselik a sok bonyolultságot. Jó lenne, ha több GitLab-termék foglalkozna ezekkel a problémákkal. Már dolgozunk néhány olyan kiegészítésen a termékhez, amelyek megkönnyítik a fent említett munkafolyamatokat. Részletek a címen érhetők el .
2020-ban kibővítjük a csapatot, hogy összehozzuk ezeket a nagyszerű funkciókat. Ha érdekel, nézd meg , és bármilyen kérdéssel forduljon bizalommal csapatunkhoz.
Forrás: will.com