SRE inženjer - pripravnik
Za početak, dozvolite mi da se predstavim. ja - , front-end inženjer u grupi GitLab. Prošle sedmice, imao sam privilegiju da budem pripravnik kod jednog od naših dežurnih inženjera SRE. Cilj je bio svakodnevno posmatrati kako dežurni reaguje na incidente i steći pravo radno iskustvo. Željeli bismo da naši inženjeri bolje razumiju potrebe korisnika Monitor::Zdravlje.
Morao sam da pratim SRE nedelju dana. Odnosno, prisustvovao sam premještaju dužnosti, posmatrao iste kanale uzbunjivanja i odgovarao na incidente, ako i kada su se dogodili.
Incidenti
Bilo je 2 incidenta u sedmici.
1. Cryptominer
GitLab.com je u srijedu zabilježio skok u upotrebi 'a, uzrokovan pokušajima korištenja minuta trkača za rudarenje kriptovaluta. Incident je riješen korištenjem vlasničkog alata za ublažavanje posljedica koji zaustavlja zadatke trkača i briše projekt i račun povezan s njim.
Da ovaj događaj nije primećen, automatizovani alat bi ga uhvatio, ali u ovom slučaju, SRE inženjer je prvi uočio prekršaj. Incidentni zadatak je kreiran, ali su informacije o njemu zatvorene.
2. Degradacija performansi Canary i Main aplikacija
Incident je bio podstaknut usporavanjem i povećanim stopama grešaka u canary i glavnim web aplikacijama na Gitlab.com. Nekoliko Apdex vrijednosti je prekršeno.
Otvoren zadatak po incidentu:
Ključni nalazi
Evo nekoliko stvari koje sam naučio tokom sedmice dežurstva.
1. Upozorenja su najkorisnija kada se otkriju odstupanja od norme.
Obavijesti se mogu podijeliti u nekoliko vrsta:
- Upozorenja zasnovana na određenom pragu, kao što je "10 5xx grešaka u sekundi."
- Upozorenja gdje je prag vrijednost u procentima kao što je "stopa greške 5xx na 10% ukupnih zahtjeva u datom trenutku".
- Upozorenja zasnovana na istorijskom prosjeku kao što je "5xx greške u 90. percentilu".
Uopšteno govoreći, tipovi 2 i 3 su korisniji za SRE na dužnosti, jer otkrivaju abnormalnosti u procesu.
2. Mnoga upozorenja nikada ne eskaliraju u incidente
SR inženjeri se bave stalnim nizom upozorenja, od kojih mnoga nisu kritična.
Pa zašto ne ograničiti upozorenja samo na ona zaista važna? S ovim pristupom, međutim, mogu se previdjeti rani simptomi onoga što će snježna gruda prerasti u pravi problem koji prijeti velikom štetom.
Zadatak dežurnog SRE-a je da utvrdi koja upozorenja zaista znače nešto ozbiljno i da li ih treba eskalirati i početi rješavati. Pretpostavljam da je to također zbog nefleksibilnosti upozorenja: bilo bi bolje kada bi uveli nekoliko nivoa ili „pametne“ načine prilagođavanja upozorenja prema gore opisanoj situaciji.
Prijedlog funkcije:
3. Naši SRE koriste mnogo alata
Interno:
- GitLab infra projekat: Runbooks žive ovdje, primopredaje smjena/nedjelja, zadaci odgovora na incidente.
- Problemi sa GitLabom: Istraga, ispitivanje i održavanje se takođe prate u problemima.
- GitLab oznake: Zadatke automatizacije pokreću određene oznake koje botovi koriste za praćenje aktivnosti zadataka.
Vanjski:
- PagerDuty Alerts
- Slack: Ovo je mjesto gdje ide tok poruka PagerDuty/AlertManager. Integracija sa komandama kosih crta za obavljanje raznih zadataka, kao što je zatvaranje upozorenja ili eskalacija do incidenta.
- Grafana: vizualizacija metrike s fokusom na dugoročne trendove.
- Kibana: daje vizualizaciju/pretragu dnevnika, mogućnost da se dublje kopa u određene događaje.
- Zoom: U Zoom-u postoji stalna "soba za odmor". Ovo omogućava SRE-ima da brzo razgovaraju o događajima bez gubljenja dragocjenog vremena na kreiranje sobe i povezivanje članova.
I mnoge mnoge druge.
4. Nadgledanje GitLab.com sa GitLab-om je jedna tačka neuspjeha
Ako GitLab.com doživi veliki prekid usluge, ne želimo da to utiče na našu sposobnost da riješimo problem. Može se zaustaviti pokretanjem druge GitLab instance za upravljanje GitLab.com. U stvari, ovo nam već funkcionira: .
5. Nekoliko funkcija koje treba razmotriti dodavanjem u GitLab
- , slično Google dokumentima. Ovo bi pomoglo u zadacima incidenta tokom događaja, kao i u zadacima debrifinga. U oba slučaja, nekoliko učesnika će možda morati da doda nešto u realnom vremenu odjednom.
- Više webhookova za zadatke. Mogućnost pokretanja različitih koraka GitLab toka posla iznutra pomoći će vam da smanjite ovisnost o Slack integracijama. Na primjer, mogućnost da se omogući upozorenje u PagerDuty putem komande kose crte u problemu s GitLabom.
zaključak
Inženjeri SRE-a imaju problema sa mnogim složenostima. Bilo bi sjajno vidjeti da više GitLab proizvoda rješava ove probleme. Već radimo na nekim dodacima proizvodu koji će olakšati gore navedene tokove rada. Dijelovi su dostupni u .
U 2020. proširujemo tim kako bismo spojili sve ove sjajne karakteristike. Ako ste zainteresirani, provjerite , i slobodno kontaktirajte nekoga iz našeg tima za sva pitanja.
izvor: www.habr.com