SRE-insener — praktikant
Esiteks laske mul end tutvustada. Ma olen , esmaste insener rühmas GitLab'is. Eelmisel nädalal oli mul au olla praktikant ühe meie vahetuses viibiva SRE-inseneri juures. Eesmärk oli igapäevane jälgimine, kuidas vahetus reageerib intsidentidele ja saada reaalset töökogemust. Soovime, et meie insenerid mõistaksid paremini kasutajate vajadusi Monitor::Health.
Minu ülesanne oli nädal aega pidevalt jälgida SRE-inseneri. St ma osalesin vahetuse üleminekul, jälgisin samu teatekanaleid ja reageerisin intsidentidele, kui ja kui need esinesid.
Juhtumid
Nädala jooksul toimus 2 intsidenti.
1. Krüptovaluuta kaevandamine
Kolmapäeval tuvastati GitLab.com 'i kasutuse suurenemine , mis oli põhjustatud katsetest kasutada runner'i minuteid krüptovaluuta kaevandamiseks. Intsidendi lahendasime oma rikkumiste neutraliseerimise tööriista abil, mis peatab runner'i ülesanded ja eemaldab seotud projekti ja konto.
Kui seda sündmust poleks märgatud, oleks selle tuvastanud automatiseeritud tööriist, kuid sel korral märkis rikkumist esimesena SRE-insener. Probleemi kohta loodi juhtumite ülesanne, kuid teave selle kohta on suletud.
2. Canaride ja peamiste rakenduste jõudluse halvenemine
Incidendi põhjustasid kiiruslangused ja suurenenud vigade sagedus canary ja main veebirakendustes Gitlab.com. Rikkusid mitmed Apdex väärtused.
Avatud ülesanne seoses juhtumiga:
Peamised järeldused
Siin on mõned punktid, mida ma nädalase valvetöö jooksul õppisin.
1. Teavitused on kõige kasulikumad, kui need tuvastavad normist kõrvalekalded.
Teavitusi saab jagada mitme tüübi vahel:
- Teavitused, mis põhinevad teatud künnisväärtusel, näiteks „sündis 10 5xx viga sekundis”.
- Teavitused, mille künnis on protsentuaalne väärtus, näiteks „5xx vigade sagedus 10% kogu päringute mahust antud ajal”.
- Teavitused, mis põhinevad ajaloolisel keskmisel, näiteks „5xx viga 90. protsentiilis”.
Üldiselt on 2. ja 3. tüüpi teavitused valvurite SRE-de jaoks kasulikumad, kuna need paljastavad protsessi käigus normist kõrvalekalded.
2. Paljud teavitused ei jõua kunagi probleemideni.
SR-insenerid tegelevad pideva teavituste vooga, millest paljud ei ole tegelikult kriitilised.
Miks mitte piirata teavitusi ainult tõeliselt olulistega? Sellise lähenemisega võite siiski mitte märgata varajasi sümptomeid, mis võivad kasvades muutuda tõeliseks probleemiks, mis ähvardab suuri kahjustusi.
Kohustus SRE-valve alla on määratleda, millised teavitused räägivad tegelikult millestki tõsisest ning kas neid tuleb eskaleerida ja nendega tegelema hakata. Kahtlustan, et see on tingitud teavituste paindumatust: oleks parem, kui oleks sisse viidud erinevad tasemed või "nutikad" viisid teavituste kohandamiseks vastavalt eespool kirjeldatud olukorrale.
Funktsiooni ettepanek:
3. Meie valve SRE-d kasutavad palju tööriistu
Sisemised:
- GitLabi infrastruktuuri projekt: siin elavad Runbook'id, valve vahetused/nädalad, ülesanded insidentide lahendamiseks.
- GitLabi probleemid: uurimised, arutelud ja hooldus jälgitakse samuti ülesannetes.
- GitLab'i sildid: automatiseerimise ülesanded käivitatakse teatud siltide alusel, mille järgi botid jälgivad ülesannete aktiivsust.
Välised:
- PagerDuty: teated
- Slack: siia suunatakse PagerDuty/AlertManager'i teatevoog. Integreerimine slash-käskudega, et täita erinevaid ülesandeid, nagu teate sulgemine või ülesande eskaleerimine juhtumiks.
- Grafana: mõõdikute visualiseerimine, keskendudes pikaajalistele trendidele.
- Kibana: pakub logide visualiseerimist/otsimist, võimaldades süvitsi kaevata teatud sündmustesse.
- Zoom: Zoom'is on pidevalt avatud «arutelu ruum». See võimaldab SRE-inseneridel kiiresti sündmusi arutada, raiskamata väärtuslikku aega ruumi loomise ja osalejate linkimise peale.
Ja palju, palju muud.
4. GitLab.com jälgimine GitLab'i abil — see on üksainus rikke punkt
Kui GitLab.com-il juhtub suur teenuste rike, ei tahaks me, et see mõjutaks meie võimet probleemi lahendada. Selle saab peatada, käivitades teise GitLab'i instantsi GitLab.com'i haldamiseks. Tegelikult töötab see juba meie juures: .
5. Mitmed funktsioonid, mida võiks kaaluda GitLab'i lisamiseks
- , sarnane nagu Google Docs. See aitaks sündmuste käigus tekkida ülesannete puhul ning ka analüüsiülesannetes. Mõlemal juhul võib mitmel osalejal olla vaja reaalajas midagi lisada.
- Rohkem webhooks'e ülesannetele. Võime käivitada erinevaid GitLabi töövoo samme seest, aitaks vähendada sõltuvust Slacki integratsioonidest. Näiteks võimalus lubada PagerDuty teavitust GitLabi ülesande sulgkommando kaudu.
Kokkuvõte
SRE-inseneridel on palju väljakutseid, millega tegeleda. Oleks tore näha rohkem GitLabi tooteid nende probleemide lahendamisel. Töötame juba mõne toote täiustuse kallal, mis lihtsustaks eelnevalt mainitud töövooge. Üksikasjad on saadaval .
Aastal 2020 laiendame meeskonda, et kõik need suurepärased funktsioonid kokku koguda. Kui huvi on, tutvuge palun , ja ärge kartke meie meeskonnaga igasugustes küsimustes ühendust võtta.
Allikas: habr.com
