SRE — Site Reliability Engineering
Site Reliability Engineering (SRE) je disciplína, ktorú vytvoril Google na zabezpečenie spoľahlivosti veľkých produkčných systémov. SRE tím píše softvér na automatizáciu operácií — namiesto manuálnej práce riešia problémy kódom.
„SRE je to, čo sa stane, keď požiadate softvérového inžiniera, aby navrhol operačný tím." — Ben Treynor Sloss, Google
Google model SRE
Google definoval SRE ako prístup, kde:
- Softvéroví inžinieri riadia produkciu namiesto klasických ops tímov
- Automatizácia je priorita — ak sa úloha opakuje, napíšte na ňu kód
- Spoľahlivosť je najdôležitejšia vlastnosť systému (feature)
- 50/50 pravidlo — maximálne 50 % času na operatívu (toil), zvyšok na inžiniering
Kľúčové princípy:
- Prijať riziko — žiadny systém nie je 100 % spoľahlivý
- Merať všetko — SLI, SLO, error budgets
- Automatizovať toil — eliminovať manuálnu repetitívnu prácu
- Inžiniering > operatíva — riešiť príčiny, nie symptómy
SLI / SLO / SLA
Tri úrovne merania spoľahlivosti:
SLI — Service Level Indicator
Konkrétna metrika, ktorá meria kvalitu služby.
| SLI | Príklad |
|---|---|
| Dostupnosť | % úspešných requestov |
| Latencia | p99 response time < 200 ms |
| Throughput | Počet spracovaných requestov/s |
| Error rate | % requestov s chybou 5xx |
SLO — Service Level Objective
Cieľová hodnota SLI, ktorú sa tím zaväzuje dodržať.
SLO: 99.9 % dostupnosť za 30 dní
= max 43.2 minút výpadku mesačne
Príklady SLO:
| Úroveň | Dostupnosť | Povolený výpadok/mesiac |
|---|---|---|
| 99 % | "two nines" | 7.2 hodín |
| 99.9 % | "three nines" | 43.2 minút |
| 99.95 % | 21.6 minút | |
| 99.99 % | "four nines" | 4.3 minúty |
SLA — Service Level Agreement
Právna zmluva medzi poskytovateľom a zákazníkom. Ak SLO nie je dodržané, nasledujú sankcie (kredity, refund).
SLA > SLO > SLI
SLA: "Garantujeme 99.9 % dostupnosť"
SLO: Interný cieľ 99.95 % (buffer)
SLI: Skutočne nameraná dostupnosť
Error Budgets
Error budget je povolené množstvo nespoľahlivosti za dané obdobie.
Error Budget = 1 - SLO
Ak SLO = 99.9 %, Error Budget = 0.1 %
Za 30 dní = 43.2 minút výpadku
Ako funguje v praxi:
- Budget je plný → tím môže nasadzovať nové features, experimentovať
- Budget sa míňa → spomalenie deploymentov, focus na stabilitu
- Budget vyčerpaný → feature freeze, všetky zdroje na spoľahlivosť
Error budget policy:
error_budget_policy:
budget_remaining > 50%:
- normálny vývoj
- bežné deploymenty
budget_remaining 20-50%:
- spomalenie release kadence
- povinné canary deploymenty
budget_remaining < 20%:
- feature freeze
- focus na reliability
budget_remaining = 0%:
- rollback posledných zmien
- postmortem pre každý incident
Toil Reduction
Toil = manuálna, repetitívna, automatizovateľná práca bez trvalej hodnoty.
Charakteristiky toilu:
- Manuálna — vyžaduje ľudský zásah
- Repetitívna — opakuje sa znova a znova
- Automatizovateľná — dá sa nahradiť kódom
- Reaktívna — reaguje na udalosť, nie je proaktívna
- Bez trvalej hodnoty — neposúva systém vpred
Príklady toilu:
| Toil | Automatizácia |
|---|---|
| Manuálne reštarty služieb | Self-healing (liveness probes) |
| Ručné škálovanie | HPA / autoscaling |
| Manuálne deploymenty | CI/CD pipeline |
| Ručná rotácia certifikátov | cert-manager |
| Manuálna kontrola logov | Alerting pravidlá |
Cieľ: Maximálne 50 % času na toil. Ak prekročíte, musíte investovať do automatizácie.
Incident Management
Štruktúrovaný proces riešenia produkčných incidentov:
Severity levels
| Level | Popis | Reakcia |
|---|---|---|
| SEV1 | Kritický výpadok, dopad na všetkých | Okamžitá eskalácia, war room |
| SEV2 | Čiastočný výpadok, degradácia | On-call + eskalácia |
| SEV3 | Menší problém, limitovaný dopad | On-call rieši |
| SEV4 | Kozmetický problém | Backlog |
Incident lifecycle
Detekcia → Triage → Mitigation → Resolution → Postmortem
↑ ↑ ↑ ↑ ↑
Alert Severity Workaround Root fix Lessons
Incident roles
- Incident Commander (IC) — koordinuje celý incident
- Communications Lead — informuje stakeholderov
- Operations Lead — vykonáva technické zmeny
- Scribe — zaznamenáva timeline
Postmortems (Blameless)
Po každom významnom incidente sa píše blameless postmortem — analýza bez obviňovania.
Štruktúra postmortemu:
## Incident: [názov]
## Dátum: YYYY-MM-DD
## Severity: SEV1/2/3
## Trvanie: X hodín Y minút
### Súhrn
Stručný popis čo sa stalo.
### Impact
- Koľko užívateľov bolo zasiahnutých
- Aké služby boli nedostupné
- Finančný dopad
### Timeline
- HH:MM — Alert triggered
- HH:MM — IC assigned
- HH:MM — Root cause identified
- HH:MM — Mitigation applied
- HH:MM — Fully resolved
### Root Cause
Technická príčina incidentu.
### Action Items
| Akcia | Vlastník | Priorita | Deadline |
|-------|----------|----------|----------|
| Pridať monitoring | @meno | P1 | 2 týždne |
| Fixnúť race condition | @meno | P0 | 3 dni |
### Lessons Learned
- Čo fungovalo dobre
- Čo nefungovalo
- Kde sme mali šťastie
Princípy blameless kultúry:
- Ľudia robia chyby — systém ich má zachytiť
- Pýtame sa "čo zlyhalo", nie "kto zlyhal"
- Cieľ je zlepšenie systému, nie trestanie
- Transparentnosť — postmortemy sú zdieľané v celej firme
On-Call
On-call je rotácia inžinierov, ktorí sú zodpovední za produkciu.
Best practices pre on-call:
on_call_policy:
rotácia: týždenná
tím_minimum: 6 ľudí # aby bola rotácia udržateľná
max_incidentov: 2 za shift
kompenzácia: áno (peniaze alebo voľno)
alert_quality:
- každý alert musí byť actionable
- žiadne "informačné" alerty do pageru
- max 1-2 page za on-call shift
eskalácia:
- primárny on-call: 5 min
- sekundárny on-call: 15 min
- management: 30 min
handoff:
- písomný handoff pri zmene
- zdieľanie kontextu o prebiehajúcich issues
Zdravie on-call tímu:
- Sledovať počet alertov na osobu
- Pravidelné review alert kvality
- On-call nie je trest — je to zdieľaná zodpovednosť
- Ak je on-call neudržateľný → investovať do automatizácie
SRE vs DevOps
| Aspekt | DevOps | SRE |
|---|---|---|
| Pôvod | Komunita, kultúrne hnutie | Google, konkrétna implementácia |
| Prístup | Kultúra a princípy | Konkrétne praktiky a metriky |
| Meranie | Rôzne (DORA, vlastné) | SLI/SLO/Error budgets |
| Tím | Cross-functional | Špecializovaný SRE tím |
| Automatizácia | Princíp | Pravidlo (max 50 % toil) |
| Spoľahlivosť | Jedna z priorít | Hlavná priorita |
| Vzťah | Filozofia | Implementácia DevOps princípov |
SRE implementuje DevOps. DevOps hovorí "spolupracujte", SRE hovorí "tu je presne ako".
DORA Metriky
DORA (DevOps Research and Assessment) definuje 4 kľúčové metriky výkonnosti:
| Metrika | Elite | High | Medium | Low |
|---|---|---|---|---|
| Deployment Frequency | On-demand (viackrát/deň) | 1×/deň – 1×/týždeň | 1×/mesiac | menej |
| Lead Time for Changes | < 1 hodina | 1 deň – 1 týždeň | 1 mesiac | > 6 mesiacov |
| Change Failure Rate | < 5 % | 5–10 % | 10–15 % | > 15 % |
| Time to Restore | < 1 hodina | < 1 deň | < 1 týždeň | > 6 mesiacov |
Ako merať DORA:
# Deployment Frequency
git log --oneline --after="2026-02-01" --before="2026-03-01" | wc -l
# Lead Time (commit → production)
# Rozdiel medzi commit timestamp a deploy timestamp
# Change Failure Rate
# Počet rollbackov / celkový počet deploymentov
# Time to Restore (MTTR)
# Priemer času od alertu po resolution
Nástroje na DORA metriky:
- Sleuth — automatické sledovanie DORA
- LinearB — engineering metrics
- Faros AI — DORA dashboardy
- Vlastné — Prometheus + Grafana + CI/CD metadata
Best Practices
1. Začnite s SLI/SLO
1. Identifikujte kritické user journeys
2. Definujte SLI pre každý journey
3. Nastavte SLO na základe historických dát
4. Implementujte meranie a dashboardy
5. Zaveďte error budget policy
2. Automatizujte postupne
- Začnite s najväčším toil-om
- Merajte úsporu času
- Dokumentujte runbooky pred automatizáciou
3. Budujte blameless kultúru
- Postmortem po každom SEV1/SEV2
- Zdieľajte postmortemy verejne (v rámci firmy)
- Action items musia mať vlastníka a deadline
4. Investujte do observability
Tri piliere observability:
├── Metriky (Prometheus, Datadog)
├── Logy (ELK, Loki)
└── Traces (Jaeger, Zipkin, OpenTelemetry)
5. SRE tím správne
- Minimálne 6–8 ľudí pre udržateľný on-call
- 50/50 pravidlo — polovica času na projekty
- Embedded SRE model pre menšie firmy
6. Chaos Engineering
Testujte spoľahlivosť proaktívne:
# Chaos Monkey — náhodne zabíja inštancie
# Gremlin — kontrolované chaos experimenty
# Litmus — chaos engineering pre Kubernetes
# Príklad: kill náhodného podu
kubectl delete pod $(kubectl get pods -o name | shuf -n 1)
Zhrnutie
| Koncept | Účel |
|---|---|
| SRE | Softvérový prístup k operáciám |
| SLI/SLO/SLA | Meranie a ciele spoľahlivosti |
| Error Budgets | Balans medzi features a stabilitou |
| Toil | Eliminácia manuálnej práce |
| Incident Management | Štruktúrované riešenie problémov |
| Postmortems | Učenie sa z incidentov |
| On-call | Zdieľaná zodpovednosť za produkciu |
| DORA | Meranie výkonnosti tímu |
SRE nie je len o nástrojoch — je to o kultúre, meraniach a systematickom prístupe k spoľahlivosti. Začnite s SLI/SLO, merajte toil, a budujte blameless kultúru.