65. Co je Site Reliability Engineering a jak souvisí s DevOps

Úvod a kontext

Doteď jsme probírali nástroje a praktiky, které spadají pod obecný
deštník "DevOps" — automatizace, CI/CD, kontejnery, observabilita.
Site Reliability Engineering (SRE) je konkrétní, dobře zdokumentovaný
přístup k provozu, který vznikl v Google kolem roku 2003 a od té doby
ho převzaly stovky firem. Pochopení SRE je důležité, protože
formalizuje mnoho věcí, které jsme dosud probírali intuitivně —
zejména jak se rozhoduje mezi rychlostí vývoje nových funkcí a
stabilitou provozu.

Teorie

Odkud SRE vzniklo

Ben Treynor Sloss, který v Google v roce 2003 založil první SRE tým,
to popsal jako "co se stane, když požádáte softwarového inženýra,
aby navrhl provozní funkci" — tedy přístup k provozu jako
k softwarovému inženýrskému problému, ne jako k ruční administrátorské
práci. Místo tradičního modelu, kde vývojáři "přehodí kód přes zeď"
provoznímu týmu, SRE tým aplikuje programátorské nástroje a myšlení
(automatizace, testování, měřitelnost) přímo na provozní problémy.

SRE vs. DevOps — vztah, ne konkurence

Časté nedorozumění je vnímat SRE a DevOps jako dvě soupeřící
metodiky. Přesnější pohled, který popularizovala i samotná Google
kniha "Site Reliability Engineering": DevOps je sada principů
(kulturní hodnoty: spolupráce vývoje a provozu, automatizace, rychlá
zpětná vazba, postupné zlepšování), zatímco SRE je jedna konkrétní,
podrobně specifikovaná implementace těchto principů, doplněná
o vlastní sadu měřitelných nástrojů. Jinými slovy — pokud si DevOps
principy nakreslíte jako abstraktní recept, SRE je jeden konkrétní,
velmi propracovaný recept, jak přesně vařit.

Klíčové rysy SRE přístupu

• Spolehlivost je měřitelná vlastnost, ne pocit. SRE zavádí
  přesnou terminologii (SLI, SLO, SLA — podrobně příští lekce), jak
  spolehlivost kvantifikovat, místo subjektivního "aplikace běží
  docela dobře".
• Error budget místo "nikdy žádný výpadek". SRE nepožaduje
  100% spolehlivost (což je navíc nesmyslně drahé a zpomaluje vývoj
  nových funkcí) — místo toho definuje přijatelnou míru selhání
  (error budget) a dokud se v jejím rámci zůstává, tým může
  bezpečně nasazovat nové funkce rychleji.
• Automatizace opakující se práce (toil). SRE explicitně
  pojmenovává a omezuje tzv. "toil" — manuální, opakující se práci
  bez trvalé hodnoty (ruční restarty, ruční škálování) — má se
  automatizovat, jinak roste lineárně s velikostí systému a
  spotřebovává kapacitu týmu.
• Postmortemy bez obviňování (blameless). Když dojde k incidentu,
  SRE tým píše rozbor příčin zaměřený na zlepšení systému, ne na
  hledání viníka — podrobně v lekci o incident managementu.
• Omezený podíl operační práce. Typické doporučení Google je, že
  SRE inženýr netráví víc než ~50 % času "provozní" prací (pagery,
  ruční zásahy) — zbytek má jít do inženýrské práce, která provoz
  dlouhodobě zlepšuje (automatizace, nástroje). Pokud operační zátěž
  trvale přesahuje tuto hranici, přebytečná práce se má vrátit
  vývojovému týmu, dokud spolehlivost nezlepší.

Kdo je SRE inženýr

V praxi je SRE inženýr často někdo se softwarovým vývojářským
backgroundem, kdo umí psát kód (automatizační skripty, nástroje pro
monitoring, opravy v samotné aplikaci), ne jen konfigurovat servery.
Typický požadavek u náborů do SRE týmu je znalost programování na
úrovni srovnatelné s běžným vývojářem, doplněná o hluboké porozumění
provozu, sítím a distribuovaným systémům.

Praktický příklad

Konkrétní ilustrace principu "error budget řídí rozhodování", který
je jádrem SRE přístupu (podrobný výpočet error budgetu je v příští
lekci):

Tým má SLO 99,9 % dostupnosti za kalendářní měsíc. To znamená error
budget přibližně 43 minut nedostupnosti za měsíc. Pokud tým za první
tři týdny měsíce vyčerpal jen 5 minut z budgetu, má prostor
riskovat — může nasadit větší, rizikovější změnu (např. migraci na
novou verzi databáze) bez čekání na "klidnější" období. Pokud ale
tým už vyčerpal 40 z 43 minut kvůli sérii menších incidentů, error
budget diktuje jasné pravidlo: žádné rizikové nasazení do konce
měsíce, jen opravy stability, dokud se budget neobnoví v dalším
měsíci. Toto pravidlo je předem dohodnuté mezi vývojovým a provozním
týmem, takže se v krizové chvíli nemusí vyjednávat znovu — je to
mechanický, ne politický proces.

Jednoduchý skript, který z metrik Promethea (viz modul 12) spočítá,
kolik error budgetu zbývá do konce měsíce:

from datetime import datetime

SLO = 0.999  # 99.9 % dostupnosti
minuty_v_mesici = 30 * 24 * 60
error_budget_minuty = minuty_v_mesici * (1 - SLO)

vycerpano_minuty = 38  # z metrik: součet minut, kdy SLI byl pod prahem

zbyva = error_budget_minuty - vycerpano_minuty
print(f"Error budget: {error_budget_minuty:.1f} min, "
      f"vyčerpáno: {vycerpano_minuty} min, zbývá: {zbyva:.1f} min")

Shrnutí

SRE je konkrétní implementace obecných principů DevOps, vzniklá
v Google, která spolehlivost systému měří číselně (SLI/SLO/SLA) a
řídí rozhodování o rychlosti nasazování nových funkcí přes error
budget místo subjektivního pocitu. Klíčové rysy jsou automatizace
opakující se práce (omezení "toilu"), blameless postmortemy a
požadavek, aby SRE inženýr netrávil většinu času ruční provozní
prací. SRE tak dává DevOps principům konkrétní, měřitelný rámec.

Kontrolní otázky

1. Jaký je vztah mezi DevOps a SRE podle popisu v této lekci —
   je to konkurence, nebo je jeden konkrétní implementací druhého?
2. Co je "toil" v SRE terminologii a proč je jeho omezování důležité
   pro dlouhodobou udržitelnost provozního týmu?
3. Jak error budget umožňuje týmu rozhodnout, zda je bezpečné nasadit
   rizikovou změnu, aniž by se muselo vyjednávat ad hoc?
4. Mini cvičení: pokud má služba SLO 99,95 % dostupnosti za měsíc
   (30 dní), kolik minut nedostupnosti si měsíčně může "dovolit"
   podle výpočtu z praktického příkladu?