SRE-ingenjör - praktikant
Låt mig först presentera mig själv. jag - , front-end ingenjör i gruppen GitLab. Förra veckan hade jag äran att praktikera hos en av våra jourhavande SRE-ingenjörer. Målet var att observera hur vakthavande befäl reagerade på incidenter dagligen och få verklig erfarenhet på jobbet. Vi skulle vilja att våra ingenjörer bättre förstår användarnas behov Monitor::Hälsa.
Jag var tvungen att följa SRE-ingenjören överallt i en vecka. Det vill säga att jag var med vid överlämningen, övervakade samma larmkanaler och svarade på incidenter om och när de inträffade.
Incidenter
Det inträffade 2 incidenter inom en vecka.
1. Kryptominerare
GitLab.com såg en ökning i användning på onsdagen 'a, orsakad av försök att använda löparens minuter för att bryta kryptovaluta. Incidenten hanterades med vårt eget verktyg för neutralisering av överträdelser, som stoppar löparens uppgifter och tar bort projektet och kontot som är kopplat till det.
Om denna händelse inte hade uppmärksammats, skulle ett automatiserat verktyg ha fångat den, men i det här fallet märkte SRE-ingenjören överträdelsen först. En incidentuppgift skapades, men information om den är stängd.
2. Prestandaförsämring av Canary- och Main-applikationer
Incidenten orsakades av avmattningar och en ökad frekvens av fel i kanariefågel och huvudwebbapplikationer på Gitlab.com. Flera Apdex-värden kränktes.
Öppen incidentuppgift:
Nyckelfynd
Här är några saker jag lärde mig under min vecka i tjänst.
1. Varningar är mest användbara när man upptäcker avvikelser från normen.
Varningar kan delas in i flera typer:
- Varningar baserade på ett visst tröskelvärde, till exempel "10 5xx-fel inträffade per sekund."
- Varningar där tröskeln är ett procentuellt värde som "frekvensen av 5xx-fel per 10 % av den totala volymen av förfrågningar vid en given tidpunkt."
- Varningar baserade på historiskt genomsnitt som "5xx-fel vid 90:e percentilen".
Generellt sett är typ 2 och 3 mer användbara för SRE i tjänst, eftersom de avslöjar avvikelser från normen i processen.
2. Många varningar eskalerar aldrig till incidenter.
SR-ingenjörer hanterar en konstant ström av varningar, av vilka många faktiskt inte är kritiska.
Så varför inte begränsa dina varningar till endast de riktigt viktiga? Med detta tillvägagångssätt kanske du dock inte känner igen de tidiga symtomen på vad som kommer att snöa in i ett verkligt problem som hotar stora skador.
Jourhavande SRE:s uppgift är att avgöra vilka larm som faktiskt tyder på något allvarligt, och om de behöver eskaleras och hanteras. Jag misstänker att detta också beror på oflexibiliteten hos varningar: det skulle vara bättre om det fanns flera nivåer eller "smarta" sätt att konfigurera varningar i enlighet med situationen som beskrivs ovan.
Funktionsförslag:
3. Våra SRE i tjänst använder många verktyg.
Inre:
- GitLab infra-projekt: runbooks live här, skift-/veckouppdrag, incidentresponsuppgifter.
- GitLab-problem: Undersökningar, granskningar och underhåll spåras också i problem.
- GitLab-etiketter: Automatiseringsuppgifter lanseras med hjälp av specifika etiketter, som bots använder för att spåra aktivitetsaktivitet.
Extern:
- PagerDuty: Varningar
- Slack: PagerDuty/AlertManager meddelandeflöde går här. Integration med snedstreckkommandon för att utföra en mängd olika uppgifter, som att stänga en varning eller eskalera till en incident.
- Grafana: visualisering av mått med fokus på långsiktiga trender.
- Kibana: Ger visualisering/loggsökning, möjlighet att gräva djupare i specifika händelser.
- Zoom: Det finns ett ständigt pågående "breakout room" i Zoom. Detta gör att SRE-ingenjörer snabbt kan diskutera händelser utan att slösa bort värdefull tid på att skapa ett rum och koppla samman deltagare.
Och många många andra.
4. Att övervaka GitLab.com med GitLab är ett enda fel
Om GitLab.com upplever ett stort serviceavbrott vill vi inte att det ska påverka vår förmåga att lösa problemet. Det kan stoppas genom att starta en andra GitLab-instans för att hantera GitLab.com. Faktum är att detta redan fungerar för oss: .
5. Några funktioner att överväga att lägga till i GitLab
- , liknande Google Dokument. Detta skulle hjälpa till med uppgifter om incidenter under en händelse, samt uppgifter om debriefing. I båda fallen kan flera deltagare behöva lägga till något i realtid.
- Fler webhooks för uppgifter. Möjligheten att köra olika GitLab-arbetsflödessteg inifrån kommer att hjälpa till att minska ditt beroende av Slack-integrationer. Till exempel möjligheten att tillåta en varning i PagerDuty via ett snedstreck-kommando i ett GitLab-problem.
Slutsats
SRE-ingenjörer har svårt med mycket komplexitet. Det skulle vara fantastiskt att se fler GitLab-produkter som tar itu med dessa problem. Vi arbetar redan med några tillägg till produkten som kommer att göra de ovan nämnda arbetsflödena enklare. Detaljer finns på .
Vi utökar teamet under 2020 för att samla alla dessa fantastiska funktioner. Vid intresse, kolla in , och kontakta gärna någon i vårt team med eventuella frågor.
Källa: will.com