SRE-ingenjör - praktikant
Först, låt mig få presentera mig. Jag är , frontend-ingenjör i gruppen från GitLab. Förra veckan fick jag äran att vara praktikant hos en av våra jour-SRE-ingenjörer. Målet var daglig observation av hur jour-ingenjören reagerar på incidenter och att få verklig arbetslivserfarenhet. Vi vill att våra ingenjörer ska förstå användarnas behov bättre. Monitor::Health.
Jag skulle under en vecka följa SRE-ingenjören överallt. Det innebar att jag var med vid överlämnandet av jouren, observerade samma varningskanaler och reagerade på incidenter, om och när de inträffade.
Incidenter
Under veckan inträffade 2 incidenter.
1. Kryptovaluta-gruvdrift
På onsdag registrerade vi ett hopp i användningen på GitLab.com orsakat av försök att använda minutrar från runnern för kryptovaluta-gruvdrift. Incidenten hanterades med hjälp av vårt eget överträdelse-neutraliseringsverktyg som stoppar runner-uppgifter och tar bort relaterade projekt och konton.
Om detta händelse inte hade uppmärksammats, skulle en automatiserad lösning ha fångat det, men i detta fall var det SRE-ingenjören som först upptäckte överträdelsen. En incidentuppgift skapades, men informationen om den är stängd.
2. Prestandanedgång i applikationerna Canary och Main
Incidenten orsakades av förseningar och en ökad frekvens av fel i canary och main webbapplikationerna på GitLab.com. Flera Apdex-värden påverkades.
Öppen incidentuppgift:
Nyckelinsikter
Här är några punkter som jag har lärt mig under veckan på jour.
1. Varningar är mest användbara när de fångar avvikelser från normen.
Varningar kan delas in i flera typer:
- Varningar baserade på ett visst tröskelvärde, som "10 5xx-fel inträffade per sekund".
- Varningar där tröskeln är en procentandel, som "frekvensen av 5xx-fel på 10% av den totala begäran under en angiven tidsperiod".
- Varningar baserade på historiskt genomsnitt, som "5xx-fel i 90:e percentilen".
Generellt sett är typ 2 och 3 mer användbara för jour-SRE:er eftersom de avtäcker avvikelser från det normala i processen.
2. Många varningar eskaleras aldrig till incidenter
SRE-ingenjörer hanterar ett konstant flöde av varningar, varav många faktiskt inte är kritiska.
Så varför inte begränsa aviseringar till endast de som verkligen är viktiga? Med en sådan strategi riskerar man dock att inte känna igen tidiga symptom som kan eskalera till ett verkligt problem som hotar att orsaka stora skador.
Uppgiften för on-call SRE är att avgöra vilka aviseringar som verkligen indikerar något allvarligt och om de måste eskaleras och börja utredas. Jag misstänker att detta också beror på rigiditeten i aviseringarna: det skulle vara bättre om det fanns flera nivåer eller "intelligenta" sätt att konfigurera aviseringar baserat på den situation som beskrivits ovan.
Förslag på funktion:
3. Våra on-call SRE använder många verktyg
Interna:
- GitLab infra-projekt: här bor Runbooks, överlämningar för skift/vecka, och uppgifter för incidenthantering.
- GitLab-ärenden: utredningar, genomgångar och underhåll spåras också i ärendena.
- GitLab-etiketter: automatiseringsuppgifter startar baserat på vissa etiketter, vilket bots spårar aktiviteten för.
Externa:
- PagerDuty: aviseringar
- Slack: här dirigeras flödet av meddelanden från PagerDuty/AlertManager. Integration med slash-kommandon för olika uppgifter, som att stänga en avisering eller eskalera till en incident.
- Grafana: visualisering av metrik med fokus på långsiktiga trender.
- Kibana: ger visualisering/sökning i loggar, möjlighet att gräva djupare i vissa händelser.
- Zoom: det finns ett ständigt aktivt "diskussionsrum" i Zoom. Detta gör att SRE-ingenjörer snabbt kan diskutera händelser utan att förlora värdefull tid på att skapa ett rum och länka deltagarna.
Och mycket, mycket mer.
4. Övervakning av GitLab.com med hjälp av GitLab är en enda punkt av fel
Om en stor tjänstefel skulle inträffa på GitLab.com skulle vi inte vilja att det påverkar vår förmåga att lösa problemet. Det kan avbrytas genom att starta en andra instans av GitLab för att hantera GitLab.com. Faktum är att det redan fungerar för oss: .
5. Flera funktioner att överväga att lägga till i GitLab
- , liknande Google Docs. Det skulle hjälpa till med uppgifter relaterade till incidenter under händelsen, samt i genomgångsuppgifter. I båda fallen kan flera deltagare behöva lägga till något i realtid.
- Flera webhooks för uppgifter. Möjligheten att starta olika steg i GitLab-arbetsflödet inifrån kommer att minska beroendet av Slack-integrationer. Till exempel möjligheten att skicka aviseringar till PagerDuty via en slash-kommando i en GitLab-uppgift.
Slutsats
SRE-injenjörer har det tufft med många komplexiteter. Det skulle vara bra att se fler GitLab-produkter som löser dessa problem. Vi arbetar redan på vissa tillägg till produkten som kommer att underlätta de arbetsflöden som nämns ovan. Mer information finns i .
År 2020 utökar vi teamet för att samla alla dessa fantastiska funktioner. Om du är intresserad, vänligen kolla in , och tveka inte att kontakta någon i vårt team med eventuella frågor.
Källa: habr.com
