Site Reliability Engineering - kursus 65.000 rub. fra Slurm, træning, Dato 1. januar 2024.
Miscellanea / / November 29, 2023
TIL MENNESKER
En SRE-ingeniør kan enten være en driftsingeniør eller en udvikler. I løbet af det intensive forløb vil du øve dig meget, og de færdigheder og viden, du får, kan tilpasses og implementeres inden for ethvert felt.
FORRETNING
SRE løser de samme problemer som DevOps: det øger hastigheden for at frigive nye funktioner og forbedrer processer i teamet. Men hovedopgaven for SRE er at sikre stabiliteten og pålideligheden af tjenester, undtagen situationer, hvor brugere klager over fejl, og ingeniører har grønne tidsplaner.
Vi bygger:
Vores træningssite består af flere mikrotjenester. Den samler data om shows, priser og ledige pladser fra alle biografer, viser filmannonceringer, giver dig mulighed for at vælge en biograf, show, sal og sted, bestille og betale for billetter.
Vi vil formulere SLO, SLI, SLA indikatorer for dette websted, udvikle en arkitektur og infrastruktur, der vil understøtte dem, opsætte overvågning og alarmering.
Udviklerfejl, infrastrukturfejl, en tilstrømning af besøgende og DoS-angreb fører til forværrede SLO'er.
Vi analyserer stabilitet, fejlbudget, testpraksis, styring af afbrydelser og driftsbelastning.
Der skete en ulykke. Betalingsbehandlingstjenesten er nede. Hvordan handler man for at genoprette funktionaliteten på kortest mulig tid?
Vi organiserer beredskabsteamets arbejde: involvering af kolleger, underretning af interessenter, prioritering. Vi træner til at arbejde under pres under ekstremt begrænsede tidsforhold.
Lad os se på tilgangen til webstedet fra et SRE-synspunkt. Vi analyserer hændelser (årsager til hændelse, fremskridt med eliminering). Vi træffer beslutninger for at forhindre dem yderligere: vi forbedrer overvågningen, ændrer arkitekturen, tilgangen til udvikling og drift og regler. Vi automatiserer processer.
— Vi har snesevis af indbyggede infrastrukturer og hundredvis af skrevne CI/CD-pipelines,
— Certificeret Kubernetes-administrator,
— Forfatter til flere kurser om Kubernetes og DevOps,
— Fast taler ved russiske og internationale IT-konferencer.
DAG 1: AMA kick-off session
Vi vil diskutere kursets mål og formål, og også fortælle dig, hvad SRE er og dele det op i teams.
Åbning af 2 teoretiske emner:
Emne 1: Overvågning
- Hvorfor er der behov for overvågning?
- Percentiler
- Alarmer
- Observerbarhed
Emne 2: SRE-teori
- SLO, SLI, SLA
- Holdbarhed
- Fejlbudget
DAG 2: analyse af praksis og cases
Øve sig: Oprettelse af et grundlæggende dashboard og opsætning af de nødvendige advarsler
Øve sig: Tilføjelse af SLO/SLI + advarsler til dashboardet
Øve sig: Første systemindlæsning
Case 1 løsning: downstream afhængighed.
I et stort system er der mange indbyrdes afhængige tjenester, og de fungerer ikke altid lige godt. Det er især irriterende, når din service er i orden, men den nabo, som du er afhængig af, går med jævne mellemrum ned.
Uddannelsesprojektet vil befinde sig i netop disse forhold, og du sikrer, at det stadig producerer kvalitet på højest mulige niveau.
DAG 3: AMA session, spørgsmål besvaret
Adgang til 2. teoretiske modul åbner:
Løsning af problemer med miljø og arkitektur
Det andet modul er bygget op omkring løsning af to cases: opstrømsafhængighed og arkitektoniske problemer. Oplægsholdere vil fortælle om hændelseshåndtering, regler for brandvæsenet og arbejdet med obduktioner og give skabeloner, som du kan bruge i dit team.
Emne 3: Incident Management
- Resilience Engineering
- Hvordan et brandvæsen er dannet
- Hvor effektivt er dit team i hændelsen?
- 7 regler for en hændelsesleder
- 5 regler for en brandmand
- HiPPO - højest betalt persons mening. Kommunikationsleder
TTema 4: Varrum-værktøjer og varslingsstyring.
Bedste praksis fra andre virksomheder i at organisere hændelseshåndtering.
DAG 4: analyse af praksis og cases
Løsning på tilfælde 2: opstrømsafhængighed.
Det er én ting, når du er afhængig af en tjeneste med en lav SLO. Det er en anden sag, når din service er den samme for andre dele af systemet. Dette sker, hvis evalueringskriterierne ikke er konsekvente: For eksempel svarer du på en anmodning inden for et sekund og betragter den som en succes, men den afhængige tjeneste venter kun 500 Moskva-tid og går derfra med en fejl.
I casen vil vi diskutere vigtigheden af at harmonisere målinger og lære at se på kvalitet gennem kundens øjne.
Løsning på case 3: problemer med databasen.
Databasen kan også være en kilde til problemer. Hvis du f.eks. ikke overvåger replikeringsrelæet, bliver replikaen forældet, og applikationen returnerer gamle data. Desuden er debugging af sådanne tilfælde særligt vanskeligt: nu er dataene inkonsekvente, men efter et par sekunder er de ikke længere konsistente, og det er ikke klart, hvad årsagen til problemet er.
Gennem sagen vil du føle al smerten ved at fejlfinde og lære, hvordan du forhindrer sådanne problemer.
Øve sig: Vi skriver en postmortem om den tidligere sag og diskuterer den med talerne.
DAG 5: AMA session, spørgsmål besvaret
AMA session og svar på spørgsmål om tidligere emner.
Adgang til det 3. teoretiske modul åbner:
Trafikafskærmning og kanarieudsætninger
I det tredje modul vil vi analysere en case dedikeret til et problem med miljøet (der vil være en detaljeret analyse af sundhed Tjek), og vi vil også trin-for-trin analysere, hvordan man implementerer SRE i virksomheder og lærer erfaringerne fra de virksomheder, hvor oplægsholderne arbejder intensiv
Emne 5: Sundhedstjek
- Sundhedstjek i Kubernetes
- Er vores service stadig i live?
- Exec sonder
- InitialDelaySeconds
- Sekundær Sundhedshavn
- Sidecar Health Server
- Hovedløs sonde
- Hardware sonde
Emne 6: Implementeringsmetoder
Emne 7: SRE projekt onboarding
Store virksomheder danner ofte et separat SRE-team, som tager sig af andre afdelingers ydelser til støtte. Men ikke alle tjenester er klar til at blive accepteret for support. Vi fortæller dig, hvilke krav den skal opfylde. Talere vil også dele deres erfaringer, hvordan de implementerede SRE, og hvilke fejl de begik.
DAG 6: analyse af praksis og cases
Løsning på case 4: der er et problem med miljøet, det er umuligt at købe billetter.
Healthchecks opgave er at opdage en ødelagt tjeneste og blokere trafik til den. Og hvis du tror, at for dette er det nok at lave en anmodning til tjenesten med root og modtage et svar, så du du tager fejl: selvom tjenesten reagerer, garanterer dette ikke dens drift - der kan opstå problemer i omgivelser.
Gennem denne sag vil du lære, hvordan du konfigurerer det korrekte Healthcheck og ikke tillader trafik at gå, hvor det ikke kan behandles.
Opsummerende