SRE-ingeniør - trainee
Først, la meg presentere meg selv. JEG - , front-end ingeniør i gruppen GitLab. Forrige uke hadde jeg æren av å jobbe hos en av våre tilkallende SRE-ingeniører. Målet var å observere hvordan vakthavende offiser reagerte på hendelser på daglig basis og få virkelige erfaringer på jobben. Vi ønsker at ingeniørene våre skal forstå brukernes behov bedre Monitor::Helse.
Jeg måtte følge SRE-ingeniøren overalt i en uke. Det vil si at jeg var til stede ved overleveringen, overvåket de samme varslingskanalene og reagerte på hendelser hvis og når de inntraff.
Hendelser
Det var 2 hendelser i løpet av en uke.
1. Krypto gruvearbeider
GitLab.com så et hopp i bruk på onsdag 'a, forårsaket av forsøk på å bruke løperens minutter til å utvinne kryptovaluta. Hendelsen ble håndtert ved hjelp av vårt eget bruddnøytraliseringsverktøy, som stopper løperens oppgaver og sletter prosjektet og kontoen knyttet til det.
Hvis denne hendelsen ikke hadde blitt lagt merke til, ville et automatisert verktøy ha fanget den, men i dette tilfellet la SRE-ingeniøren merke til bruddet først. En hendelsesoppgave ble opprettet, men informasjon om den er stengt.
2. Ytelsesdegradering av Canary og Main-applikasjoner
Hendelsen var forårsaket av bremser og en økt frekvens av feil i kanarifuglen og hovedwebapplikasjonene på Gitlab.com. Flere Apdex-verdier ble brutt.
Åpen hendelsesoppgave:
Nøkkelfunn
Her er noen ting jeg lærte i løpet av uken på vakt.
1. Varsler er mest nyttige når du oppdager avvik fra normen.
Varsler kan deles inn i flere typer:
- Varsler basert på en viss terskelverdi, for eksempel "10 5xx-feil oppstod per sekund."
- Varsler der terskelen er en prosentverdi, for eksempel "frekvens på 5xx feil per 10 % av det totale volumet av forespørsler på et gitt tidspunkt."
- Varsler basert på historisk gjennomsnitt som "5xx feil ved 90. persentil".
Generelt sett er type 2 og 3 mer nyttige for SRE på vakt, siden de avslører 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 faktisk ikke er kritiske.
Så hvorfor ikke begrense varslene dine til bare de virkelig viktige? Med denne tilnærmingen vil du imidlertid kanskje ikke gjenkjenne de tidlige symptomene på hva som vil snøballe til et reelt problem som truer med stor skade.
Vakthavende SREs jobb er å finne ut hvilke varsler som faktisk indikerer noe alvorlig, og om de må eskaleres og håndteres. Jeg mistenker at dette også skyldes ufleksibiliteten til varsler: det ville være bedre om det var flere nivåer eller "smarte" måter å konfigurere varsler i samsvar med situasjonen beskrevet ovenfor.
Funksjonsforslag:
3. Våre SRE-er på vakt bruker mye verktøy.
Innvendig:
- GitLab infra-prosjekt: runbooks live her, skift-/ukeoppdrag, hendelsesresponsoppgaver.
- GitLab-problemer: Undersøkelser, anmeldelser og vedlikehold spores også i problemer.
- GitLab-etiketter: Automatiseringsoppgaver lanseres ved hjelp av spesifikke etiketter, som roboter bruker for å spore aktivitetsaktivitet.
Utvendig:
- PagerDuty: Varsler
- Slack: PagerDuty/AlertManager meldingsflyt går her. Integrasjon med skråstrekkommandoer for å utføre en rekke oppgaver, for eksempel å lukke et varsel eller eskalere til en hendelse.
- Grafana: visualisering av beregninger med fokus på langsiktige trender.
- Kibana: Gir visualisering/loggsøk, mulighet til å grave dypere inn i spesifikke hendelser.
- Zoom: Det er et konstant kjørende "breakout room" i Zoom. Dette gjør at SRE-ingeniører raskt kan diskutere hendelser uten å kaste bort verdifull tid på å lage et rom og knytte sammen deltakere.
Og mange mange andre.
4. Overvåking av GitLab.com med GitLab er et enkelt feilpunkt
Hvis GitLab.com opplever et stort tjenestebrudd, vil vi ikke at det skal påvirke vår evne til å løse problemet. Det kan stoppes ved å starte 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 vil hjelpe med oppgaver på hendelser under en hendelse, samt oppgaver på debriefing. I begge tilfeller kan flere deltakere ha behov for å legge til noe i sanntid.
- Flere webhooks for oppgaver. Muligheten til å kjøre forskjellige GitLab arbeidsflyttrinn innenfra vil bidra til å redusere avhengigheten av Slack-integrasjoner. For eksempel muligheten til å tillate et varsel i PagerDuty via en skråstrek-kommando i et GitLab-problem.
Konklusjon
SRE-ingeniører har det vanskelig med mye kompleksitet. Det ville vært flott å se flere GitLab-produkter som adresserer disse problemene. Vi jobber allerede med noen tillegg til produktet som vil gjøre arbeidsflytene nevnt ovenfor enklere. Detaljer tilgjengelig på .
Vi utvider teamet i 2020 for å samle alle disse flotte funksjonene. Hvis du er interessert, sjekk ut , og kontakt gjerne hvem som helst i teamet vårt med spørsmål.
Kilde: www.habr.com