SRE-ingeniør — praktikant
Lad mig først præsentere mig selv. Jeg er , frontend-ingeniør i gruppen i GitLab. I sidste uge havde jeg æren af at være praktikant hos en af vores vagthavende SRE-ingeniører. Målet var daglig overvågning af, hvordan vagthavende reagerer på hændelser og få reel arbejdserfaring. Vi ønsker, at vores ingeniører bedre forstår brugernes behov Monitor::Health.
Jeg skulle følge SRE-ingeniøren overalt i en uge. Det vil sige, jeg var til stede ved overdragelsen af vagten, overvågede de samme varslingskanaler og reagerede på hændelser, hvis og når de opstod.
Hændelser
I løbet af ugen opstod der 2 hændelser.
1. Krypto-miner
I onsdags blev der registreret et spike i brugen af GitLab.com, forårsaget af forsøg på at udnytte runner-minutter til mining af kryptovaluta. Hændelsen blev håndteret med vores eget værktøj til neutralisering af overtrædelser, som stopper runner-opgaver og sletter de tilknyttede projekter og konti. Hvis denne hændelse ikke var blevet opdaget, ville den være blevet opfanget af et automatiseret værktøj, men i dette tilfælde opdagede SRE-ingeniøren overtrædelsen først. Der blev oprettet en hændelsesopgave, men informationen om den er lukket.
2. Forringelse af ydeevnen for Canary- og Main-applikationer
Hændelsen blev forårsaget af forsinkelser og en stigende fejlrate i canary- og main-webapplikationerne på GitLab.com. Flere Apdex-værdier blev overtrådt.
Den åbne hændelsesopgave:
Vigtige indsigter
Her er nogle punkter, jeg har forstået i løbet af ugen med vagt.
1. Varsler er mest nyttige, når de registrerer afvigelser fra normen.
Varsler kan opdeles i flere typer:
Varsler baseret på et bestemt tærskel, som 'der opstod 10 5xx fejl i sekundet'.
- Varsler, hvor tærsklen er en procentdel som '5xx fejl hyppighed på 10% af det samlede antal anmodninger i et givet tidsrum'.
- Varsler baseret på historisk gennemsnit som '5xx fejl i 90. percentil'.
- Generelt set er type 2 og 3 mere nyttige for vagthavende SRE'er, da de afslører afvigelser fra normen i processen.
2. Mange varsler bliver aldrig eskaleret til hændelser
2. Mange meddelelser eskaleres aldrig til hændelser
SRE-ingeniører har med en konstant strøm af alarmer at gøre, mange af dem er faktisk ikke kritiske.
Så hvorfor ikke begrænse alarmerne til kun dem der er virkelig vigtige? Med en sådan tilgang kan man dog misse tidlige symptomer på noget, der kan vokse, som en sneboldeffekt, til et reelt problem, der truer med store skader.
Opgaven for den pågældende SRE er at bestemme, hvilke alarmer der faktisk indikerer noget alvorligt, og om de skal eskaleres og tages hånd om. Jeg mistænker, at dette også er forårsaget af manglende fleksibilitet i alarmerne: det ville være bedre at introducere flere niveauer eller "smarte" metoder til at konfigurere alarmer i henhold til den beskrevne situation.
Funktionsforslag:
3. Vores pågældende SRE bruger mange værktøjer
Interne:
- GitLab infra projekt: her lever Runbooks, skiftoverførsler pr. skifte/uge, opgaver vedrørende incident response.
- GitLab issues: undersøgelser, gennemgange og vedligeholdelse spores også i opgaver.
- GitLab labels: automationsopgaver startes baseret på bestemte mærker, som bots overvåger aktiviteten af opgaver.
Eksterne:
- PagerDuty: alarmer
- Slack: her dirigeres strømmen af beskeder fra PagerDuty/AlertManager. Integration med slash-kommandoer til at udføre forskellige opgaver, såsom: luk alarmen eller eskaler til incident.
- Grafana: visualisering af metrikker med fokus på langsigtede tendenser.
- Kibana: giver visualisering/søgning i loggen, mulighed for at grave dybere ned i specifikke begivenheder.
- Zoom: der er et konstant fungerende "diskussionsrum" i Zoom. Dette gør det muligt for SRE-ingeniører hurtigt at diskutere begivenheder uden at spilde værdifuld tid på at oprette et rum og sende links til deltagerne.
Og meget, meget mere.
4. Overvågning af GitLab.com ved hjælp af GitLab — er et enkelt punkt for fejl
Hvis der sker en stor tjenesteudfald på GitLab.com, ville vi ikke ønskes, at det påvirker vores evne til at løse problemet. Det kan håndteres ved at køre en anden instans af GitLab til styring af GitLab.com. Faktisk fungerer dette allerede for os: .
5. Flere funktioner at overveje at tilføje til GitLab
- , som ligner Google Docs. Dette ville være nyttigt i opgaver relateret til hændelser under begivenheden samt i analysetasks. I begge tilfælde kan flere deltagere straks have brug for at tilføje noget i realtid.
- Flere webhooks til opgaver. Muligheden for at starte forskellige trin i GitLab arbejdsflowet fra indersiden vil hjælpe med at reducere afhængigheden af Slack-integrationer. For eksempel muligheden for at aktivere notifikationer i PagerDuty via en slash-kommando i GitLab-opgaven.
Konklusion
SRE-ingénører har det svært med mange kompleksiteter. Det ville være fantastisk at se flere GitLab-produkter, der adresserer disse problemer. Vi arbejder allerede på nogle tilføjelser til produktet, som vil lette de nævnte arbejdsprocesser. Oplysningerne er tilgængelige i .
I 2020 udvider vi teamet for at samle alle disse fantastiske funktioner. Hvis du er interesseret, så tjek venligst vores , og tøv ikke med at kontakte nogen fra vores team med spørgsmål.
Kilde: habr.com
