Site Reliability Engineering - kurs 65 000 rub. från Slurm, utbildning, Datum 1 januari 2024.

instagram viewer

DAG 1: AMA kick-off session

Vi kommer att diskutera mål och mål med kursen, och även berätta vad SRE är och dela upp det i team.

Inledning av 2 teoretiska ämnen:

Ämne 1: Övervakning

• Varför behövs övervakning?
• Percentiler
• Varning
• Observerbarhet

Ämne 2: SRE-teori

• SLO, SLI, SLA
• Varaktighet
• Felbudget

DAG 2: analys av praxis och fall

Öva: Att göra en grundläggande instrumentpanel och ställa in nödvändiga varningar

Öva: Lägger till SLO/SLI +-varningar till instrumentpanelen

Öva: Första systemladdningen

Fall 1 lösning: nedströmsberoende.

I ett stort system finns det många ömsesidigt beroende tjänster, och de fungerar inte alltid lika bra. Det är särskilt irriterande när din tjänst är i sin ordning, men den intilliggande, som du är beroende av, går ner med jämna mellanrum.

Utbildningsprojektet kommer att befinna sig i just dessa förhållanden och du kommer att säkerställa att det fortfarande producerar kvalitet på högsta möjliga nivå.

DAG 3: AMA-session, frågor besvarade

Tillgång till den andra teoretiska modulen öppnas:

Lösa problem med miljö och arkitektur

Den andra modulen är uppbyggd kring att lösa två fall: uppströmsberoende och arkitektoniska problem. Föreläsare kommer att prata om incidenthantering, regler för brandkåren och arbete med obduktioner och tillhandahålla mallar som du kan använda i ditt team.

Ämne 3: Incidenthantering

• Resiliensteknik
• Hur en brandkår bildas
• Hur effektivt är ditt team i händelsen?
• 7 regler för en incidentledare
• 5 regler för en brandman
• HiPPO - högst betald persons åsikt. Kommunikationsledare

TTema 4: Varrums verktyg och varningshantering.

Bästa praxis från andra företag för att organisera incidenthantering.

DAG 4: analys av praxis och fall

Lösning på fall 2: uppströmsberoende.

Det är en sak när du är beroende av en tjänst med låg SLO. Det är en annan sak när din tjänst är densamma för andra delar av systemet. Detta händer om utvärderingskriterierna inte är konsekventa: till exempel svarar du på en förfrågan inom en sekund och anser att den är en framgång, men den beroende tjänsten väntar bara 500 Moskva-tid och lämnar med ett fel.

I fallet kommer vi att diskutera vikten av att harmonisera måtten och lära oss att se på kvalitet med kundens ögon.

Lösning på fall 3: problem med databasen.

Databasen kan också vara en källa till problem. Om du till exempel inte övervakar replikeringsreläet kommer repliken att bli inaktuell och applikationen returnerar gamla data. Dessutom är det särskilt svårt att felsöka sådana fall: nu är data inkonsekventa, men efter några sekunder är de inte längre konsekventa och det är inte klart vad orsaken till problemet är.

Genom fallet kommer du att känna all smärtan med att felsöka och lära dig hur du förhindrar sådana problem.

Öva: Vi skriver en obduktion om det tidigare fallet och diskuterar det med talarna.

DAG 5: AMA-session, frågor besvarade

AMA-session och svar på frågor om tidigare ämnen.

Tillgång till den tredje teoretiska modulen öppnas:

Trafikavskärmning och kanariefågelsläpp

I den tredje modulen kommer vi att analysera ett fall dedikerat till ett problem med miljön (det kommer att finnas en detaljerad analys av hälsa Checking), och vi kommer också steg-för-steg analysera hur man implementerar SRE i företag och lära oss erfarenheterna från företagen där talarna arbetar intensiv

Ämne 5: Hälsokontroll

• Hälsokontroll i Kubernetes
• Lever vår tjänst fortfarande?
• Exec-sonder
• InitialDelaySeconds
• Sekundär hälsohamn
• Sidecar Health Server
• Huvudlös sond
• Hårdvaruprob

Ämne 6: Implementeringsmetoder

Ämne 7: SRE-projekt onboarding

Stora företag bildar ofta ett separat SRE-team, som tar hjälp av andra avdelningar för stöd. Men inte alla tjänster är redo att accepteras för support. Vi berättar vilka krav den måste uppfylla. Talare kommer också att dela med sig av sina erfarenheter, hur de implementerade SRE och vilka misstag de gjorde.

DAG 6: analys av praxis och fall

Lösning på fall 4: det finns ett problem med miljön, det är omöjligt att köpa biljetter.

Healthchecks uppgift är att upptäcka en trasig tjänst och blockera trafik till den. Och om du tror att det för detta räcker att göra en förfrågan till tjänsten med root och få ett svar, då du du har fel: även om tjänsten svarar, garanterar detta inte dess funktion - problem kan uppstå i miljö.

Genom det här fallet kommer du att lära dig hur du konfigurerar rätt Healthcheck och inte tillåter trafik att gå dit den inte kan bearbetas.

Sammanfattande