SRE

SLI opisują mierzalne wskaźniki jakości usługi, a SLO określają docelowy poziom niezawodności, który zespół chce utrzymać w zadanym okresie. Najpierw warto sprawdzić, które operacje mają znaczenie dla użytkownika, jak mierzyć dostępność lub opóźnienia oraz czy metryki nie są jedynie szumem monitoringowym. Przykładowo dla API można mierzyć odsetek poprawnych odpowiedzi poniżej ustalonego progu latency i na tej podstawie ustalić miesięczne SLO. Ten temat przerabiamy praktycznie na szkoleniu: SRE Fundamentals — niezawodność jako praktyka inżynierska (SRE/FND).

Error Budget to dopuszczalny poziom błędów lub niedostępności wynikający bezpośrednio z przyjętego SLO. W praktyce trzeba przeliczyć cel niezawodności na czas lub liczbę błędnych żądań, a następnie sprawdzić, czy tempo zmian, release frequency i liczba incydentów nie zużywają budżetu zbyt szybko. Dla SLO 99,9% miesięczny budżet oznacza tylko ograniczoną liczbę minut niedostępności, więc zespół może czasowo ograniczyć releasy po serii awarii. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: SRE Fundamentals — niezawodność jako praktyka inżynierska (SRE/FND).

SRE traktuje niezawodność jako problem inżynierski oparty na miernikach, automatyzacji i świadomym zarządzaniu ryzykiem, podczas gdy DevOps skupia się szerzej na współpracy i przepływie dostarczania, a klasyczne operations częściej koncentrują się na utrzymaniu i reakcji operacyjnej. Przy porównaniu warto sprawdzić zakres odpowiedzialności, sposób podejmowania decyzji o zmianach oraz to, czy zespół pracuje na SLI, SLO i Error Budget. Przykładem różnicy jest sytuacja, w której zespoły SRE ograniczają wdrożenia po przekroczeniu budżetu błędów, zamiast oceniać ryzyko wyłącznie intuicyjnie. To jedno z zagadnień omawianych podczas szkolenia: SRE Fundamentals — niezawodność jako praktyka inżynierska (SRE/FND).

Alert fatigue pojawia się wtedy, gdy zespoły dostają zbyt wiele powiadomień o niskiej wartości operacyjnej, przez co trudniej wychwycić zdarzenia istotne dla niezawodności. Należy przejrzeć reguły alertowania, powiązać alarmy z SLO i wpływem na użytkownika oraz przygotować runbooks i playbooks dla najczęstszych incydentów. Dobrym przykładem jest usunięcie alertów informacyjnych z nocnej rotacji i pozostawienie tylko tych, które wymagają realnej reakcji dyżurnych. Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: SRE Fundamentals — niezawodność jako praktyka inżynierska (SRE/FND).

Blameless postmortem to analiza incydentu skupiona na mechanizmach systemowych, przebiegu zdarzeń i działaniach naprawczych, a nie na szukaniu winnych. Warto odtworzyć timeline, przeprowadzić root cause analysis, zadać pytanie „dlaczego” na kilku poziomach i przypisać action items z właścicielami oraz terminami. Przykładowo po awarii kolejki można wskazać brak limitów, niepełny monitoring i nieaktualny runbook jako przyczyny wymagające trwałej korekty. Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: SRE Fundamentals — niezawodność jako praktyka inżynierska (SRE/FND).

Na początek warto rozumieć role narzędzi do metryk, wizualizacji, dyżurów i automatyzacji, bo SRE opiera się na spójnym przepływie danych operacyjnych. Dobrze sprawdzić, jak Prometheus zbiera metryki, jak Grafana wspiera analizę, jak PagerDuty lub OpsGenie obsługują eskalacje oraz gdzie Terraform i Kubernetes pomagają ograniczać pracę manualną. Typowy przykład to zestaw, w którym metryki z klastra trafiają do Prometheusa, dashboardy powstają w Grafanie, a incydenty uruchamiają rotację on-call. Ten temat przerabiamy praktycznie na szkoleniu: SRE Fundamentals — niezawodność jako praktyka inżynierska (SRE/FND).