SRE-ingeniør - trainee
Først, la meg presentere meg selv. Jeg er , front-end-ingeniør i gruppen GitLab. Forrige uke hadde jeg privilegiet å være praksisplass hos en av våre SRE-ingeniører på vakt. Målet var å observere hvordan den på vakt reagerer på hendelser daglig og få praktisk erfaring. Vi ønsker at ingeniørene våre skal forstå brukernes behov bedre. Overvåk::Helse.
Jeg fikk i oppgave å følge SRE-ingeniøren i en uke. Dette betydde at jeg var til stede ved overleveringen, overvåket de samme varslingskanalene og reagerte på hendelser hvis og når de oppsto.
Hendelser
Det var 2 hendelser i løpet av en uke.
1. Kryptominer
GitLab.com opplevde en økning i bruken onsdag. Et sikkerhetsbrudd forårsaket av forsøk på å bruke løperminutter til kryptovalutautvinning ble rapportert. Hendelsen ble løst ved hjelp av vårt eget avbøtende verktøy, som avslutter løperoppgaver og sletter det tilknyttede prosjektet og kontoen.
Hvis denne hendelsen hadde gått ubemerket hen, ville den blitt fanget opp av et automatisert verktøy, men i dette tilfellet var det SRE-ingeniøren som la merke til bruddet først. En oppgave ble opprettet for hendelsen, men informasjonen om den ble forseglet.
2. Ytelsesforringelse av Canary- og Main-applikasjoner
Hendelsen ble utløst av nedbremsinger og økte feilrater i canary- og hovedwebapplikasjonene på Gitlab.com. Flere Apdex-verdier ble brutt.
Åpen oppgave for hendelsen:
Nøkkelfunn
Her er noen ting jeg lærte i løpet av uken min på vakt.
1. Varsler er mest nyttige når de oppdager avvik fra normen.
Varsler kan deles inn i flere typer:
- Varsler basert på en viss terskel, for eksempel «10 5xx-feil oppsto per sekund».
- Varsler der terskelen er en prosentverdi, for eksempel «frekvens på 5xx feil per 10 % av det totale forespørselsvolumet på et gitt tidspunkt».
- Varsler basert på et historisk gjennomsnitt, for eksempel «5xx feil i den 90. persentilen».
Generelt sett er type 2 og 3 mer nyttige for SRE-er på vakt fordi de avdekker avvik fra normen i prosessen.
2. Mange varsler eskalerer aldri til hendelser
SR-ingeniører håndterer en konstant strøm av varsler, hvorav mange egentlig ikke er kritiske.
Så hvorfor ikke begrense varsler til bare de som virkelig er viktige? Denne tilnærmingen kan imidlertid overse tidlige varseltegn på hva som kan bli til et reelt problem som truer med store skader.
Den vakthavende SRE-ens jobb er å avgjøre hvilke varsler som virkelig er alvorlige, og om de må eskaleres og etterforskes. Jeg mistenker at dette også skyldes varslingens rigiditet: det ville være bedre å innføre flere nivåer eller «smarte» måter å konfigurere varsler på i henhold til situasjonen beskrevet ovenfor.
Funksjonsforslag:
3. Våre SRE-er på vakt bruker mange verktøy
Innvendig:
- GitLab infraprosjekt: hjem til runbooks, skift-/ukentlige overleveringer og hendelsesresponsoppgaver.
- GitLab-problemer: undersøkelser, gjennomganger og vedlikehold spores også i oppgaver.
- GitLab-etiketter: Automatiseringsoppgaver utløses av spesifikke etiketter, som roboter bruker til å spore oppgaveaktivitet.
Utvendig:
- PagerDuty: Varsler
- Slack: Det er her PagerDuty/AlertManager-meldinger sendes. Integrasjon med skråstrekkommandoer muliggjør ulike oppgaver, som å avvise et varsel eller eskalere det til en hendelse.
- Grafana: Visualisering av metrikker med fokus på langsiktige trender.
- Kibana: Gir loggvisualisering/søk, mulighet til å grave dypere i spesifikke hendelser.
- Zoom: Zoom har et permanent aktivt «grupperom». Dette lar SRE-ingeniører raskt diskutere hendelser uten å kaste bort verdifull tid på å opprette et rom og dele lenken med deltakerne.
Og mye, mye mer.
4. Overvåking av GitLab.com med GitLab er et enkelt feilpunkt
Hvis GitLab.com opplever et større tjenestebrudd, ønsker vi ikke at det skal påvirke vår evne til å løse problemet. Dette kan reduseres ved å lansere en andre GitLab-instans for å administrere GitLab.com. Faktisk fungerer dette allerede for oss: .
5. Noen funksjoner du bør vurdere å legge til i GitLab
- , lik Google Dokumenter. Dette ville være nyttig for hendelsesbaserte oppgaver under et arrangement, samt for debriefinger. I begge tilfeller kan det hende at flere deltakere må legge til noe i sanntid.
- Flere webhooks for oppgaver. Muligheten til å utløse ulike GitLab-arbeidsflyttrinn internt vil bidra til å redusere avhengigheten av Slack-integrasjoner. For eksempel muligheten til å aktivere varsler i PagerDuty via en skråstrekkommando i en GitLab-oppgave.
Konklusjon
SRE-ingeniører står overfor en rekke utfordringer. Det hadde vært flott å se flere GitLab-produkter løse disse problemene. Vi jobber allerede med noen produkttillegg som vil forenkle arbeidsflytene nevnt ovenfor. Detaljer er tilgjengelige i .
I 2020 utvider vi teamet vårt for å samle alle disse flotte funksjonene. Hvis du er interessert, kan du sjekke ut , og ta gjerne kontakt med noen i teamet vårt hvis du har spørsmål.
Kilde: www.habr.com
