Szkolenie: SRE Fundamentals — niezawodność jako praktyka inżynierska
Szkolenie wprowadzające w filozofię i metodykę Site Reliability Engineering opartą na podejściu Google. Uczestnicy poznają kluczowe koncepcje: SLI (Service Level Indicators), SLO (Service Level Objectives), SLA oraz Error Budget jako narzędzie zarządzania ryzykiem. Kurs uczy jak zdefiniować i mierzyć niezawodność systemu, identyfikować toil (powtarzalną pracę manualną) i go redukować oraz budować kulturę postmortem bez szukania winnych. Po szkoleniu uczestnik wraca do swojego zespołu z gotowym zestawem pytań, metryk i narzędzi do natychmiastowego zastosowania — bez konieczności wdrażania nowych systemów
- Trenerzy praktycy
- Kameralne grupy
Czas trwania szkolenia:2 dni (16h)
Kod kursu:SRE/FND
SRE Fundamentals — niezawodność jako praktyka inżynierska
Cele szkolenia
Szkolenie przygotowuje inżynierów do wdrożenia kultury Site Reliability Engineering oraz zarządzania niezawodnością systemów jako problemu inżynierskiego w środowiskach DevOps i cloud
Szkolenie uczy definiowania, monitorowania i interpretacji SLI, SLO oraz SLA, a także zarządzania Error Budget w celu podejmowania świadomych decyzji o release frequency i ryzyku produkcyjnym
Szkolenie rozwija umiejętności identyfikacji toil, ograniczania alert fatigue oraz redukcji pracy manualnej poprzez automatyzację procesów i observability
Szkolenie uczy prowadzenia efektywnych blameless postmortem oraz analizy incydentów z wykorzystaniem root cause analysis jako elementu continuous improvement
Szkolenie pokazuje jak budować zdrową kulturę on-call, definiować metryki MTTR i MTTA oraz wdrażać praktyki reliability engineering w zespołach IT
Szkolenie wprowadza uczestników w ekosystem narzędzi SRE takich jak Prometheus, Grafana, PagerDuty, Terraform i Kubernetes oraz pokazuje ich rolę w utrzymaniu niezawodności usług
Dla kogo?
Inżynierowie DevOps chcący pogłębić wiedzę na temat niezawodności systemów
Administratorzy systemów przechodzący w rolę SRE
Tech leadowie i architekci odpowiedzialni za niezawodność systemów produkcyjnych
Liderzy technicznych planujący wprowadzenie praktyk SRE w organizacji
Efekty kształcenia
Uczestnik definiuje SLI i SLO dla swojego systemu oraz wskazuje które metryki niezawodności mają realne znaczenie dla użytkownika, a które stanowią jedynie szum monitoringowy
Uczestnik oblicza Error Budget dla swojego SLO oraz określa maksymalną dopuszczalną liczbę incydentów i czas niedostępności usług w skali miesiąca
Uczestnik identyfikuje konkretny toil w swoim zespole, analizuje jego koszt operacyjny i proponuje automatyzację wspierającą reliability engineering
Uczestnik prowadzi blameless postmortem na podstawie rzeczywistego incydentu oraz formułuje action items z właścicielami i terminami realizacji
Uczestnik rozróżnia podejście klasycznych operations od Site Reliability Engineering i uzasadnia wdrożenie praktyk SRE w swoim zespole
Uczestnik analizuje Four Golden Signals oraz wykorzystuje metryki latency, traffic, errors i saturation do oceny kondycji systemu
Uczestnik projektuje podstawowe runbooks i playbooks wspierające skuteczny on-call oraz ograniczające alert fatigue
Uczestnik mapuje wymagania biznesowe na cele SLO i potrafi komunikować wpływ niezawodności systemu na decyzje biznesowe i produktowe
Wymagania
Doświadczenie w administracji systemami Linux/Unix lub DevOps
Podstawowa wiedza o systemach produkcyjnych i wdrażaniu aplikacji
Zrozumienie koncepcji monitoring i alertingu
Znajomość podstaw infrastruktury chmurowej będzie plusem
W cenie otrzymasz:
Materiały szkoleniowe
Certyfikat ukończenia szkolenia
W przypadku szkolenia w trybie stacjonarnym zapewnimy Ci również lunch oraz sprzęt niezbędny do nauki
Program szkolenia
Filozofia i koncepcje SRE
Co to jest Site Reliability Engineering — pochodzenie z Google, ewolucja od classic ops
SRE vs DevOps vs Operations — różnice w mentalności, odpowiedzialności i narzędziach
Rola inżyniera SRE — hybrid developer-operator, co musi umieć (coding, Linux, networks, databases)
Toil — co to jest i dlaczego go redukować (manual work, repetitive tasks, no leverage)
Inżynieria vs walka z ogniami — shift na automatyzację i przejrzyste procesy
SRE w branży — Google, Netflix, Spotify, Allegro i jak adaptują podejście organizacje różnej wielkości
Ekosystem narzędzi SRE — Prometheus, Grafana, PagerDuty, Terraform, Kubernetes — co i dlaczego (przegląd, każde omawiane szczegółowo w kolejnych kursach ścieżki)
SLI, SLO, SLA — słownik niezawodności
Definiowanie Service Level Indicators (SLI) — co rzeczywiście zależy użytkownikom (nie wszystko trzeba mierzyć)
Service Level Objectives (SLO) — cele niezawodności i budżet błędów, jak wybrać realistyczne wartości
Service Level Agreements (SLA) — zobowiązania komercyjne i konsekwencje
Google's Four Golden Signals — latency, traffic, errors, saturation i jak je interpretować
Definiowanie SLO dla typowych systemów — API, bazy danych, kolejki — ćwiczenie na rzeczywistych przykładach
Mapowanie biznesowych wymagań na SLI/SLO — jak rozmawiać z product managerami
Error Budget — zarządzanie ryzykiem na produkcji
Koncepcja Error Budget — ile błędów możemy sobie pozwolić w danym okresie (SLO 99% = 0.01% błędów)
Matematyka Error Budget — od SLO do liczby 9 (99%, 99.9%, 99.99%, itd), obliczanie dostępności w sekundach/minutach
Decyzje o release frequency — jak szybko możemy wdrażać bez przekraczania budżetu
Priorytetyzacja pracy — bugs vs nowe features na podstawie budżetu, kiedy można być agresywnym
Komunikacja Error Budget w zespole i z biznesem — jak wyjaśnić wpływ incydentów na możliwości i decyzje o releasach
Ćwiczenie: oblicz Error Budget dla swojego systemu — uczestnicy liczą na podstawie własnych danych lub przygotowanego case study
On-call i kultura dyżurów
Czym jest on-call w SRE — rotacja, odpowiedzialności, eskalacje
Alert fatigue — dlaczego zbyt wiele alertów zabija on-call i jak temu zapobiec
Runbooks i playbooks — jak przygotować inżyniera na dyżur i standaryzować reakcje
Metryki zdrowego on-call — MTTA, MTTR, liczba stron na dyżur
Granica między toilem a incydentem — kiedy reagować, kiedy automatyzować
Przegląd narzędzi on-call — PagerDuty, OpsGenie, Grafana OnCall — czym się różnią i jak wybrać
Postmortem culture i blameless reviews
Kultura bezpieczeństwa psychicznego — blameless investigation jako narzędzie psychologiczne
Struktura postmortem — timeline budowy incydentu, root cause analysis, action items z właścicielami
Dokumentowanie incydentów bez szukania winnych — fokus na systemy a nie ludzi
Analiza przyczyn — pytanie "why" pięć razy, hierarchie przyczyn (immediate vs root)
Continuous improvement — wyciąganie wniosków z każdego problemu, tracking action items
Szablon postmortem — analiza przykładowego dokumentu (Google, Atlassian), przegląd struktury i typowych błędów
Wybrane opinie
Przeczytaj pozytywne opinie pochodzące z ankiet satysfakcji z naszych szkoleń wypełnianych wyłącznie przez ich uczestników po realizacji usługi
