Engineering

Site Reliability Engineering

Google wynalazło SRE jako odpowiedź na pytanie: jak skalować operacje bez proporcjonalnego wzrostu ops-teamów? Automatyzacja, error budgets i blameless culture.

50%

Max toil

43min/mies.

SLO 99.9%

Google

Stworzono przez

Error Budget

Kluczowa zasada

Przykłady SLO dla różnych serwisów

Nie każdy serwis potrzebuje 99.99% SLO. Właściwy poziom SLO zależy od krytyczności serwisu i kosztu jego utrzymania.

API Płatności

SLI: Availability (HTTP 2xx / wszystkie requesty)

SLO: 99.95%

Error Budget: 21.6 min/miesiąc

Search Endpoint

SLI: Latency P99 poniżej 500ms

SLO: 99.5%

Error Budget: 3.6h/miesiąc

Dashboard (read-only)

SLI: Availability

SLO: 99.0%

Error Budget: 7.2h/miesiąc

Background Jobs

SLI: Job Success Rate

SLO: 99.5%

Error Budget: Poza krytyczną ścieżką — luźniejszy

6 kluczowych praktyk SRE

SRE to nie tylko monitoring — to zestaw praktyk inżynierskich budujących kulturę reliability w organizacji.

Toil Reduction

Automatyzacja manualnych, powtarzalnych zadań operacyjnych. Max 50% czasu SRE na toil.

Przykład

Auto-scaling, auto-remediation, self-healing infrastructure.

Error Budget Policy

Formalna polityka co się dzieje gdy error budget jest wyczerpany (freeze na releases).

Przykład

Gdy zostało 10% error budget → tylko P0 fixes mogą być wdrożone.

Blameless Postmortem

Po każdym incydencie — analiza bez obwiniania ludzi. Fokus na systemy i procesy.

Przykład

Google template: timeline, impact, root cause, action items, lessons learned.

Production Readiness Review

Checklist przed wdrożeniem nowego serwisu: monitoring, alerts, runbooks, on-call, rollback plan.

Przykład

SRE zatwierdzają nowy serwis który spełnia PRR checklist zanim trafi na produkcję.

Chaos Engineering

Celowe wprowadzanie awarii w kontrolowanych warunkach aby przetestować odporność systemu.

Przykład

Netflix Chaos Monkey losowo wyłącza instancje produkcyjne. GameDay ćwiczenia failover.

Capacity Planning

Prognozowanie zapotrzebowania na zasoby (CPU, memory, storage, bandwidth) w horyzoncie 6-12 miesięcy.

Przykład

Load testing przed Black Friday, auto-scaling policies, database sharding plan.

Często zadawane pytania

Co to jest SRE (Site Reliability Engineering)?

SRE (Site Reliability Engineering) to podejście do zarządzania operacjami IT i infrastrukturą stworzone przez Google. SRE łączy kompetencje inżynierskie z operacyjnymi — zamiast tradycyjnych 'opsów' którzy ręcznie zarządzają systemami, SRE to inżynierowie którzy automatyzują operacje kodem. Kluczowa filozofia: Toil Reduction — każda powtarzalna, manualna praca operacyjna (toil) powinna być zautomatyzowana. SRE powinni poświęcać max 50% czasu na toil, resztę na inżynierię i automatyzację. Error Budget — każdy serwis ma budżet błędów (np. 0.1% niedostępności/miesiąc przy SLO 99.9%). Jeśli error budget jest wyczerpany, nowe wdrożenia są wstrzymywane aż reliability wzrośnie.

Czym są SLI, SLO i SLA?

SLI (Service Level Indicator) — konkretna metryka mierząca reliability serwisu. Przykłady: availability (% czasu gdy serwis odpowiada), latency (czas odpowiedzi P99), error rate (% requestów zakończonych błędem), throughput (liczba requestów per sekundę). SLO (Service Level Objective) — cel który chcemy osiągnąć dla SLI. Wewnętrzna wartość docelowa. Przykład: SLO availability = 99.9% (max 43.8 min niedostępności/miesiąc). SLO latency P99 = 500ms. SLA (Service Level Agreement) — formalna umowa z klientem określająca gwarantowany poziom SLI. Zazwyczaj jest niższy niż SLO (bo firma chce buffer). Przykład: SLA 99.5% (SLO to 99.9% — 0.4% buforu). Naruszenie SLA = financial penalties, kredyty dla klienta. Hierarchia: SLA jest zewnętrzna, SLO wewnętrzna, SLI metryka.

Co to jest Error Budget i jak go używać?

Error Budget to ilość 'błędów' jaką serwis może sobie pozwolić w danym oknie czasowym przy utrzymaniu SLO. Przykład: SLO = 99.9% availability/miesiąc. Miesiąc = 30 dni x 24h x 60min = 43,200 minut. Error budget = 0.1% x 43,200 = 43.2 minut niedostępności/miesiąc. Jak używać error budget: Gdy error budget jest duży (dużo dostępnego) — bezpieczny czas na szybsze wdrożenia i eksperymenty. Akceptujemy wyższe ryzyko. Gdy error budget jest mały (prawie wyczerpany) — spowalniamy wdrożenia, skupiamy się na reliability. Gdy error budget = 0 (SLO naruszone) — freeze na nowe features, focus wyłącznie na stabilizację. Error budget jest mechanizmem który automatycznie balansuje prędkość vs. stability — bez ręcznego arbitrażu.

Jak wygląda on-call w SRE?

On-call (dyżur) w SRE: rotacja inżynierów którzy są dostępni poza godzinami pracy do obsługi incydentów. Best practices: Reasonable on-call burden — inżynier nie powinien być budzony więcej niż 2 razy na noc w tygodniu dyżuru. Więcej = alert fatigue, burnout. Runbooks — dokumentacja krok po kroku jak reagować na konkretny alert. Inżynier on-call może być junior jeśli ma dobry runbook. Blameless postmortems — po każdym poważnym incydencie przeprowadź postmortem bez obwiniania osób. Fokus na systemowe przyczyny i naprawy. PagerDuty/OpsGenie — narzędzia do zarządzania alertami i rotacjami. Severity levels — P0/P1/P2/P3 określają jak szybko trzeba reagować (P0: natychmiast, P1: 15 min, P2: 4h, P3: następny dzień). Compensation — on-call powinna być wynagrodzona (przez additional pay lub time off).

Jakie narzędzia używają SRE teams?

Narzędzia SRE: Monitoring i Observability — Prometheus + Grafana (open-source stack), Datadog, New Relic, Honeycomb (distributed tracing). Alerting — PagerDuty, OpsGenie, VictorOps. Incident Management — PagerDuty, Incident.io, FireHydrant. Logging — Elasticsearch + Kibana (ELK), Splunk, Datadog Logs, Loki. Distributed Tracing — Jaeger, Zipkin, Honeycomb, Datadog APM. Chaos Engineering — Chaos Monkey (Netflix OSS), Gremlin, Steadybit. Infrastructure as Code — Terraform, Pulumi, AWS CloudFormation. Service Mesh — Istio, Linkerd (dla Kubernetes). Kluczowy trend: Observability vs. Monitoring — monitoring sprawdza 'czy działa' (binary), observability pozwala odpowiadać na pytanie 'dlaczego nie działa' przez rich telemetry (metrics, logs, traces).

Czytaj dalej