SRE inženjer — pripravnik
Za početak, dopustite mi da se predstavim. Ja sam , frontend inženjer u grupi GitLaba. Prošli tjedan imao sam čast biti pripravnik jednog od naših dežurnih SRE inženjera. Cilj je bio svakodnevno pratiti kako dežurni reagira na incidentne situacije i steći stvarno iskustvo. Željeli bismo da naši inženjeri bolje razumiju potrebe korisnika Monitor::Health.
Trebalo je da tjedan dana svuda pratim SRE inženjera. To znači da sam prisustvovao prijenosu dežurstva, promatrao iste kanale obavijesti i reagirao na incidente, ako su se pojavili.
Incidenti
Tijekom tjedna dogodila su se 2 incidenta.
1. Kriptominač
U srijedu na GitLab.com zabilježen je porast korištenja izazvan pokušajima korištenja minuta runnerta za rudarenje kriptovalute. S incidentom smo se nosili koristeći vlastiti alat za neutralizaciju kršenja, koji zaustavlja zadatke runnerta i uklanja povezani projekt i račun.
Da ovo događanje nije primijećeno, automatski alat bi ga uhvatio, no u ovom slučaju SRE inženjer je prvi primijetio kršenje. Kreirana je zadaća vezana uz incident, međutim informacije o njoj su zatvorene.
2. Degeneracija performansi aplikacija Canary i Main
Incident su izazvale usporenja i povećana učestalost grešaka u canary i main web aplikacijama na GitLab.com. Poremećena su neka Apdex vrijednosti.
Otvorena zadaća o incidentu:
Ključni zaključci
Evo nekoliko točaka koje sam shvatio tijekom tjedna dežurstva.
1. Obavijesti su najkorisnije kada bilježe odstupanja od norme.
Obavijesti se mogu podijeliti u nekoliko tipova:
- Obavijesti temeljene na određenoj pragu, poput 'dogodilo se 10 5xx grešaka u sekundi'.
- Obavijesti u kojima je prag postotak, poput 'učestalost 5xx grešaka na 10% ukupnog obima zahtjeva u određenom vremenu'.
- Obavijesti temeljene na povijesnom prosjeku kao što je '5xx grešaka u 90. percentilu'.
Govoreći općenito, drugi i treći tip su korisniji za dežurne SRE, jer otkrivaju odstupanja od norme tijekom procesa.
2. Mnoge obavijesti nikada ne eskaliraju do incidenata
SRE inženjeri se suočavaju s kontinuiranim protokom obavijesti, od kojih je mnoge zapravo nebitne.
Pa zašto ne ograničiti obavijesti samo na one doista važne? Međutim, s ovakvim pristupom, moglo bi se propustiti prepoznavanje ranih simptoma koji bi se mogli razviti u stvarni problem s velikim posljedicama.
Zadatak dežurnog SRE-a je odrediti koje obavijesti zapravo govore o nečemu ozbiljnom i da li ih treba eskalirati i početi rješavati. Sumnjam da je to također uzrokovano krutosti obavijesti: bilo bi bolje kada bi se uvelo nekoliko razina ili 'pametan' način podešavanja obavijesti u skladu s gore opisanim situacijama.
Prijedlog za funkciju:
3. Naši dežurni SRE koriste mnogo alata
Interni:
- GitLab infra projekt: ovdje žive Runbook-ovi, prijenosi dežurstva na smjenu/tjedan, zadatci za odgovaranje na incidente.
- GitLab problemi: istraživanje, analize i održavanje također se prate u zadacima.
- GitLab oznake: zadatci automatizacije se pokreću prema određenim oznakama na kojima botovi prate aktivnost zadataka.
Vanjski:
- PagerDuty: obavijesti
- Slack: ovdje dolazi niz poruka iz PagerDuty/AlertManager. Integracija sa slash komandama za izvođenje različitih zadataka, kao što su: zatvoriti obavijest ili eskalirati do incidenta.
- Grafana: vizualizacija metrika s fokusom na dugoročne trendove.
- Kibana: pruža vizualizaciju/pretraživanje u dnevnicima, mogućnost dubljeg istraživanja određenih događaja.
- Zoom: postoji stalno aktivna 'soba za raspravu' u Zoom-u. Ovo omogućuje SRE inženjerima brzo raspravljanje o događajima, ne trošeći dragocjeno vrijeme na stvaranje sobe i dijeljenje linkova sudionicima.
I mnogo, mnogo više.
4. Praćenje GitLab.com putem GitLab-a je jedinstvena točka neuspjeha
Ako dođe do velikog kvara usluga na GitLab.com, ne bismo željeli da to utječe na našu sposobnost rješavanja problema. Može se zaustaviti pokretanjem druge instance GitLab-a za upravljanje GitLab.com. U stvarnosti, ovo već funkcioniše kod nas: .
5. Nekoliko funkcija koje treba razmotriti za dodavanje u GitLab
- , slično Google Docs. To bi pomoglo u zadacima vezanim uz incidente tijekom događaja, kao i u zadacima vezanim uz analizu. U oba slučaja, više sudionika može istovremeno trebati dodavati nešto u stvarnom vremenu.
- Više webhooka za zadatke. Mogućnost pokretanja različitih koraka radnog toka GitLab iznutra pomoći će smanjiti ovisnost o Slack integracijama. Na primjer, mogućnost omogućavanja obavijesti u PagerDuty putem slash komande u GitLab zadatku.
Zaključak
SRE inženjeri suočavaju se s mnogim izazovima. Bilo bi sjajno vidjeti više GitLab proizvoda u rješavanju ovih problema. Već radimo na nekoliko dodataka proizvodu koji će olakšati ranije spomenute radne tokove. Detalji su dostupni u .
U 2020. godini proširujemo tim kako bismo skupili sve ove sjajne funkcionalnosti. Ako ste zainteresirani, molimo vas da pogledate , i slobodno se obratite nekome iz našeg tima za bilo kakva pitanja.
Izvor: habr.com
