Kako sam proveo tjedan dana kao SRE inženjer pripravnik. Dužnost kroz oči softverskog inženjera

Kako sam proveo tjedan dana kao SRE inženjer pripravnik. Dužnost kroz oči softverskog inženjera

inženjer SRE – vježbenik

Prvo da se predstavim. ja - @tristan.čitaj, front-end inženjer u grupi Monitor::Zdravlje GitLab. Prošli tjedan imao sam čast stažirati kod jednog od naših dežurnih SRE inženjera. Cilj je bio promatrati kako dežurni službenik svakodnevno reagira na incidente i steći iskustvo iz stvarnog života na poslu. Željeli bismo da naši inženjeri bolje razumiju potrebe korisnika funkcija Monitor::Zdravlje.

Morao sam pratiti SRE inženjera posvuda tjedan dana. Odnosno, prisustvovao sam primopredaji, pratio iste kanale dojave i reagirao na incidente ako i kada su se dogodili.

Incidenti

Dogodila su se 2 incidenta unutar tjedan dana.

1. Cryptominer

GitLab.com zabilježio je skok u korištenju u srijedu GitLab trkač'a, uzrokovano pokušajima korištenja trkačevih minuta za rudarenje kriptovalute. Incident je riješen pomoću našeg vlastitog alata za neutralizaciju kršenja, koji zaustavlja zadatke pokretača i briše projekt i račun koji je s njim povezan.

Da ovaj događaj nije primijećen, automatizirani alat bi ga uhvatio, ali u ovom slučaju, SRE inženjer je prvi primijetio kršenje. Izrađen je incidentni zadatak, ali su informacije o njemu zatvorene.

2. Degradacija performansi Canary i Main aplikacija

Incident je uzrokovan usporavanjem i povećanom učestalošću pogrešaka u canary i glavnim web aplikacijama na Gitlab.com. Nekoliko Apdex vrijednosti je prekršeno.

Otvoreni zadatak incidenta: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

Ključni nalazi

Evo nekoliko stvari koje sam naučio tijekom tjedna na dužnosti.

1. Upozorenja su najkorisnija pri otkrivanju odstupanja od norme.

Upozorenja se mogu podijeliti u nekoliko vrsta:

  • Upozorenja na temelju određene granične vrijednosti, kao što je "pojavilo se 10 5xx pogrešaka u sekundi."
  • Upozorenja u kojima je prag postotna vrijednost kao što je "učestalost 5xx pogrešaka na 10% ukupnog volumena zahtjeva u određenom trenutku."
  • Upozorenja temeljena na povijesnom prosjeku kao što je "5xx pogrešaka na 90. percentilu".

Općenito govoreći, tipovi 2 i 3 su korisniji za SRE na dužnosti, jer otkrivaju odstupanja od norme u procesu.

2. Mnoga upozorenja nikada ne eskaliraju u incidente.

SR inženjeri suočavaju se sa stalnim nizom upozorenja, od kojih mnoga zapravo nisu kritična.

Pa zašto ne biste ograničili svoja upozorenja samo na ona stvarno važna? S ovim pristupom, međutim, možda nećete prepoznati rane simptome onoga što će se pretvoriti u pravi problem koji prijeti velikom štetom.

Posao dežurnog SRE-a je utvrditi koja upozorenja zapravo ukazuju na nešto ozbiljno i treba li ih eskalirati i postupati s njima. Pretpostavljam da je to također zbog nefleksibilnosti upozorenja: bilo bi bolje da postoji nekoliko razina ili "pametnih" načina za konfiguriranje upozorenja u skladu s gore opisanom situacijom.

Prijedlog značajke: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. Naši SRE na dužnosti koriste mnogo alata.

Interno:

  • GitLab infra projekt: runbookovi uživo ovdje, smjenski/tjedni zadaci, zadaci odgovora na incidente.
  • Problemi s GitLabom: Istrage, pregledi i održavanje također se prate u problemima.
  • GitLab oznake: zadaci automatizacije pokreću se pomoću posebnih oznaka koje botovi koriste za praćenje aktivnosti zadataka.

Vanjski:

  • PagerDuty: Upozorenja
  • Slack: PagerDuty/AlertManager protok poruka ide ovdje. Integracija s naredbama kose crte za obavljanje raznih zadataka, kao što je zatvaranje upozorenja ili eskalacija do incidenta.
  • Grafana: vizualizacija metrike s fokusom na dugoročne trendove.
  • Kibana: Omogućuje vizualizaciju/pretragu dnevnika, mogućnost dubljeg kopanja po određenim događajima.
  • Zoom: u Zoomu postoji stalno pokrenuta "prosobna soba". To SRE inženjerima omogućuje brzu raspravu o događajima bez gubljenja dragocjenog vremena na stvaranje sobe i povezivanje sudionika.

I mnogi mnogi drugi.

4. Praćenje GitLab.com s GitLabom je jedna točka neuspjeha

Ako GitLab.com doživi veliki prekid usluge, ne želimo da to utječe na našu sposobnost rješavanja problema. Može se zaustaviti pokretanjem druge GitLab instance za upravljanje GitLab.com. Zapravo, ovo već radi za nas: https://ops.gitlab.net/.

5. Nekoliko značajki za razmatranje dodavanja u GitLab

  • Uređivanje zadataka za više korisnika, slično Google dokumentima. To bi pomoglo u zadacima o incidentima tijekom događaja, kao i zadacima na izvješćivanju. U oba slučaja, nekoliko sudionika će možda morati nešto dodati u stvarnom vremenu.
  • Više web-dojavnika za zadatke. Sposobnost pokretanja različitih koraka tijeka rada GitLaba iznutra pomoći će smanjiti vaše oslanjanje na Slack integracije. Na primjer, mogućnost dopuštanja upozorenja u PagerDuty putem naredbe kose crte u problemu GitLaba.
    Zaključak

SRE inženjeri imaju problema s puno složenosti. Bilo bi sjajno vidjeti više GitLab proizvoda koji se bave ovim problemima. Već radimo na nekim dodacima proizvodu koji će olakšati gore navedene tijekove rada. Pojedinosti dostupne na Odjeljak Ops Product Vision.

Proširujemo tim 2020. kako bismo objedinili sve ove izvrsne značajke. Ako ste zainteresirani, provjerite slobodna radna mjesta, i slobodno kontaktirajte bilo koga iz našeg tima ako imate pitanja.

Izvor: www.habr.com

Dodajte komentar