SRE ingeniør - praktikant
For at begynde, lad mig præsentere mig selv. jeg - , front-end ingeniør i gruppen GitLab. I sidste uge havde jeg det privilegium at være praktikant hos en af vores vagthavende SRE-ingeniører. Målet var dagligt at observere, hvordan vagthavende reagerer på hændelser og få reel arbejdserfaring. Vi vil gerne have, at vores ingeniører bedre forstår brugernes behov Monitor::Sundhed.
Jeg var nødt til at følge SRE rundt i en uge. Det vil sige, at jeg var til stede ved tjenesteoverførslen, observerede de samme alarmkanaler og reagerede på hændelser, hvis og hvornår de opstod.
Hændelser
Der var 2 hændelser på en uge.
1. Cryptominer
GitLab.com registrerede et spring i brugen onsdag 'a, forårsaget af forsøg på at bruge runner's minutes til cryptocurrency mining. Hændelsen blev løst ved hjælp af et proprietært afhjælpningsværktøj, der stopper løberens opgaver og sletter det projekt og den konto, der er knyttet til det.
Hvis denne hændelse ikke var blevet bemærket, ville et automatiseret værktøj have fanget den, men i dette tilfælde bemærkede SRE-ingeniøren overtrædelsen først. Der blev oprettet en hændelsesopgave, men informationen om den er lukket.
2. Ydeevneforringelse af Canary- og Main-applikationer
Hændelsen blev drevet af opbremsninger og øgede fejlrater i canary og de vigtigste webapplikationer på Gitlab.com. Adskillige Apdex-værdier blev overtrådt.
Åben opgave efter hændelse:
Vigtige fund
Her er et par punkter, som jeg lærte i løbet af vagtugen.
1. Advarsler er mest nyttige, når der registreres afvigelser fra normen.
Underretninger kan opdeles i flere typer:
- Advarsler baseret på en bestemt tærskel, såsom "10 5xx-fejl opstod pr. sekund."
- Advarsler, hvor tærsklen er en procentværdi, såsom "5xx fejlrate pr. 10 % af det samlede antal anmodninger på et givet tidspunkt".
- Advarsler baseret på et historisk gennemsnit såsom "5xx-fejl i 90. percentilen".
Generelt er type 2 og 3 mere nyttige for SRE'er på vagt, da de afslører abnormiteter i processen.
2. Mange advarsler eskalerer aldrig til hændelser
SR-ingeniører håndterer en konstant strøm af advarsler, hvoraf mange ikke er rigtig kritiske.
Så hvorfor ikke begrænse advarsler til kun de virkelig vigtige? Med denne tilgang kan tidlige symptomer på, hvad der vil snebold til et reelt problem, der truer med store skader, dog blive overset.
Den vagthavende SREs opgave er at afgøre, hvilke alarmer der virkelig betyder noget alvorligt, og om de skal eskaleres og begynde at blive sorteret fra. Jeg formoder, at dette også skyldes ufleksibiliteten af advarsler: det ville være bedre, hvis de introducerede flere niveauer eller "smarte" måder at tilpasse advarsler i henhold til situationen beskrevet ovenfor.
Funktionsforslag:
3. Vores SRE'er bruger mange værktøjer
indenlandske:
- GitLab infra-projekt: Runbooks live her, vagt-/ugeoverdragelser, hændelsesreaktionsopgaver.
- GitLab-problemer: Undersøgelse, debriefing og vedligeholdelse spores også i spørgsmål.
- GitLab-etiketter: Automatiseringsopgaver udløses af specifikke etiketter, som bots bruger til at spore opgaveaktivitet.
Eksternt:
- PagerDuty Alerts
- Slack: Det er her, PagerDuty/AlertManager-meddelelsesstrømmen går. Integration med skråstreg-kommandoer til at udføre en række opgaver, såsom at lukke en alarm eller eskalere til en hændelse.
- Grafana: visualisering af metrics med fokus på langsigtede trends.
- Kibana: giver visualisering/logsøgning, muligheden for at grave dybere ned i bestemte begivenheder.
- Zoom: Der er et permanent "breakout room" i Zoom. Dette giver SRE'er mulighed for hurtigt at diskutere begivenheder uden at spilde kostbar tid på at oprette et rum og forbinde medlemmer.
Og mange mange andre.
4. Overvågning af GitLab.com med GitLab er et enkelt fejlpunkt
Hvis GitLab.com oplever en større serviceafbrydelse, ønsker vi ikke, at det skal påvirke vores evne til at løse problemet. Det kan stoppes ved at køre en anden GitLab-instans for at administrere GitLab.com. Faktisk virker dette allerede for os: .
5. Et par funktioner at overveje at tilføje til GitLab
- , svarende til Google Docs. Dette ville hjælpe i hændelsesopgaver under arrangementet, såvel som i debriefingsopgaver. I begge tilfælde kan flere deltagere have brug for at tilføje noget i realtid på én gang.
- Flere webhooks til opgaver. Evnen til at køre forskellige GitLab-workflow-trin indefra vil hjælpe med at reducere din afhængighed af Slack-integrationer. For eksempel muligheden for at aktivere en advarsel i PagerDuty via en skråstreg-kommando i et GitLab-problem.
Konklusion
SRE-ingeniører har det svært med mange kompleksiteter. Det ville være fantastisk at se flere GitLab-produkter løse disse problemer. Vi arbejder allerede på nogle tilføjelser til produktet, der vil gøre de ovennævnte arbejdsgange nemmere. Dele fås i .
I 2020 udvider vi teamet for at samle alle disse fantastiske funktioner. Hvis du er interesseret, så tjek venligst ud , og du er velkommen til at kontakte en fra vores team med spørgsmål.
Kilde: www.habr.com