Site Reliability Engineering - kurs 65 000 rub. fra Slurm, trening, Dato 1. januar 2024.

instagram viewer

DAG 1: AMA kick-off økt

Vi vil diskutere mål og mål for kurset, og også fortelle deg hva SRE er og dele det inn i team.

Åpning av 2 teoretiske emner:

Emne 1: Overvåking

• Hvorfor er overvåking nødvendig?
• Persentiler
• Varsler
• Observerbarhet

Emne 2: SRE-teori

• SLO, SLI, SLA
• Varighet
• Feilbudsjett

DAG 2: analyse av praksis og case

Øve på: Lage et grunnleggende dashbord og sette opp nødvendige varsler

Øve på: Legger til SLO/SLI + varsler til dashbordet

Øve på: Første systembelastning

Case 1 løsning: nedstrøms avhengighet.

I et stort system er det mange gjensidig avhengige tjenester, og de fungerer ikke alltid like godt. Det er spesielt irriterende når tjenesten din er i orden, men naboen, som du er avhengig av, går ned med jevne mellomrom.

Utdanningsprosjektet vil befinne seg i akkurat disse forholdene, og du vil sørge for at det fortsatt produserer kvalitet på høyest mulig nivå.

DAG 3: AMA økt, spørsmål besvart

Tilgang til den andre teoretiske modulen åpnes:

Løse problemer med miljø og arkitektur

Den andre modulen er bygget rundt å løse to tilfeller: oppstrømsavhengighet og arkitektoniske problemer. Foredragsholdere vil snakke om hendelseshåndtering, regler for brannvesenet og arbeid med post mortem og gi maler som du kan bruke i teamet ditt.

Tema 3: Hendelseshåndtering

• Resiliensteknikk
• Hvordan et brannvesen er dannet
• Hvor effektivt er teamet ditt i hendelsen?
• 7 regler for en hendelsesleder
• 5 regler for en brannmann
• HiPPO - høyest betalt persons mening. Kommunikasjonsleder

TTema 4: Varrum-verktøy og varslingshåndtering.

Beste praksis fra andre selskaper for å organisere hendelseshåndtering.

DAG 4: analyse av praksis og case

Løsning på tilfelle 2: oppstrømsavhengighet.

Det er én ting når du er avhengig av en tjeneste med lav SLO. Det er en annen sak når tjenesten din er den samme for andre deler av systemet. Dette skjer hvis evalueringskriteriene ikke er konsistente: for eksempel svarer du på en forespørsel i løpet av et sekund og anser den som en suksess, men den avhengige tjenesten venter bare 500 Moskva-tid og går med en feil.

I caset vil vi diskutere viktigheten av å harmonisere beregninger og lære å se på kvalitet gjennom kundens øyne.

Løsning på tilfelle 3: problemer med databasen.

Databasen kan også være en kilde til problemer. Hvis du for eksempel ikke overvåker replikeringsreléet, vil replikaen bli utdatert og applikasjonen vil returnere gamle data. Dessuten er det spesielt vanskelig å feilsøke slike tilfeller: nå er dataene inkonsekvente, men etter noen sekunder er de ikke lenger konsistente, og det er ikke klart hva årsaken til problemet er.

Gjennom saken vil du føle all smerten ved feilsøking og lære hvordan du kan forhindre slike problemer.

Øve på: Vi skriver en postmortem på forrige sak og diskuterer den med foredragsholderne.

DAG 5: AMA-økt, spørsmål besvart

AMA-økt og svar på spørsmål om tidligere emner.

Tilgang til den tredje teoretiske modulen åpnes:

Trafikkskjerming og kanarifrigjøring

I den tredje modulen vil vi analysere en sak dedikert til et problem med miljøet (det vil være en detaljert analyse av helse Sjekker), og vi vil også steg-for-steg analysere hvordan man implementerer SRE i bedrifter og lære erfaringene til bedriftene der foredragsholderne jobber intensiv

Emne 5: Helsesjekking

• Helsesjekk i Kubernetes
• Lever tjenesten vår fortsatt?
• Exec-sonder
• InitialDelaySeconds
• Sekundær helsehavn
• Sidecar Health Server
• Hodeløs sonde
• Maskinvaresonde

Emne 6: Implementeringsmetoder

Emne 7: SRE-prosjektet onboarding

Store bedrifter danner ofte et eget SRE-team, som tar på seg tjenester fra andre avdelinger for støtte. Men ikke alle tjenester er klare til å bli akseptert for støtte. Vi forteller deg hvilke krav den må oppfylle. Foredragsholdere vil også dele sine erfaringer, hvordan de implementerte SRE og hvilke feil de gjorde.

DAG 6: analyse av praksis og case

Løsning på sak 4: det er et problem med miljøet, det er umulig å kjøpe billetter.

Healthchecks oppgave er å oppdage en ødelagt tjeneste og blokkere trafikk til den. Og hvis du tror at for dette er det nok å sende en forespørsel til tjenesten med root og motta et svar, så du du tar feil: selv om tjenesten svarer, garanterer ikke dette driften - det kan oppstå problemer i omgivelser.

Gjennom denne saken vil du lære hvordan du konfigurerer riktig Healthcheck og ikke lar trafikk gå der den ikke kan behandles.

Oppsummering