Co má SLA kontrakt obsahovat a podle čeho ho vyhodnotit.

V naší praxi pracujeme se čtyřmi tiery SLA. Není to dogma — některé firmy mají hybrid mezi nimi — ale dává to dobrou strukturu pro rozhodování, co reálně potřebujete.

Tier nejnižší — best-effort. Reakce v pracovní době do několika dní, žádné tvrdé garance, žádné penalizace. Vhodný pro interní nástroje, vývojářské utility nebo systémy, jejichž výpadek nezpůsobuje měřitelnou škodu. Cena typicky 5 až 15 tisíc Kč měsíčně podle velikosti aplikace.

Tier business-hours — reakce do 4 hodin v pracovní době, řešení do 1 nebo 2 pracovních dnů, garantovaný uptime 98 až 99 procent. Vhodný pro CRM, interní portály, e-commerce s nižším obratem. Většina české SMB sedí přesně sem. Cena 18 až 45 tisíc Kč měsíčně.

Tier 24/7 — reakce do 1 hodiny kdykoliv, řešení do 4 až 8 hodin, garantovaný uptime 99,5 procenta. Vhodný pro produkční B2C aplikace, e-shopy s vyšším obratem, kritické integrace s partnery. U projektu pro NemovitostiČesko (CollSunLight s.r.o.) jsme po stabilizaci nastavili 98,5 procenta SLA s automated backups, DDoS protection a uptime monitoringem — to je klasický 24/7 setup pro real-estate portál. Cena 50 až 120 tisíc Kč měsíčně.

Tier mission-critical — reakce do 30 minut, řešení do 2 hodin, uptime 99,9 procenta a víc. Tady už mluvíme o on-call režimu, redundanci v aplikační vrstvě a obvykle i geografické redundanci dat. Cena typicky od 150 tisíc Kč měsíčně nahoru. Tento tier většina české SMB nepotřebuje a nemá smysl ho předplácet — výjimkou jsou platby, zdravotnictví a integrace na státní systémy.

Procentuální uptime zní triviálně, dokud nezjistíte, kolik konkrétních minut to znamená. 99 procent uptime je 87 hodin výpadku ročně. 99,5 procenta je 43 hodin. 99,9 procenta je 8,7 hodiny. 99,99 procenta je 53 minut. Skok mezi každým „nine" znamená řádově desetinásobnou investici do redundance, monitoringu a personálního zajištění.

U projektu pro projekční firmu z Plzeňského kraje (50 zaměstnanců) jsme po cloud migraci do Azure měřili 99,2 procenta uptime — to je v praxi zhruba 70 hodin výpadku za rok, ale rozprostřených do drobných incidentů a plánované údržby. Pro projekční práci, která probíhá v pracovní době, to znamenalo prakticky nulový dopad na business — protože většina drobných incidentů byla mimo pracovní dobu.

99,9 procenta dává smysl jen tehdy, když máte tvrdý dopad výpadku — typicky e-commerce s denním obratem víc než 200 tisíc Kč, B2B integrace s SLA penalizacemi nebo aplikace, jejíž výpadek paralyzuje provoz fyzické pobočky. Pokud váš business funguje i během dvouhodinového výpadku, neplaťte za 99,9 procenta — neuvidíte návratnost.

Pozor na detail definice uptime. 99,9 procenta měřené z venku přes synthetic monitoring je něco jiného než 99,9 procenta měřené v interní prometheus instanci, která neumí detekovat výpadek databáze, dokud neumře aplikace. Vždy se ptejte, jak konkrétně se uptime počítá.

SLA má dvě klíčové metriky — reakční dobu (kdy někdo začne pracovat na problému) a dobu řešení (kdy je problém vyřešen). V praxi se ve smlouvách nejčastěji prohrává v tom, co tyto metriky neměří.

Past první — vyloučení vyšší moci. Standardní formulace „SLA neplatí v případě selhání třetí strany" je v cloudovém světě prakticky volná karta — pokud Azure má výpadek, dodavatel SLA neplní a vy nemáte nárok na nic. Rozumná formulace je „SLA neplatí v případě selhání třetí strany, pokud dodavatel pro danou službu nezajistil multi-region redundanci, která je v ceně paušálu uvedena". Bez druhé části je první část past.

Past druhá — neexistující penalizace. „V případě nesplnění SLA má klient nárok na slevu 10 procent z měsíčního paušálu" zní hezky, ale 10 procent z 30 tisíc je 3 tisíce — tolik vás stojí jediná hodina práce vašeho IT člověka, který výpadek řeší. Penalizace musí být úměrná dopadu, ne paušálu.

Past třetí — výjimky pro plánovanou údržbu, která není definovaná. Pokud smlouva říká „SLA neplatí během plánované údržby" bez upřesnění, jak často a v jakou dobu, máte ve smlouvě díru velikou jako kostel. Rozumná formulace specifikuje maintenance windows (např. úterý 02:00 až 04:00) a stanoví minimální oznámení (typicky 7 dní předem).

U projektu pro projekční firmu jsme nastavili reakci na incident pod 45 minut s monitoringem, který volá hlavního admina automaticky přes systém alerting. To je realistický cíl pro firmu, která nepotřebuje 24/7 on-call tým, ale chce mít jistotu, že incident neleží v inboxu přes víkend.

Past čtvrtá — chybějící kapacitní limit. „Reakce do 1 hodiny" platí, dokud máte jeden incident měsíčně. Pokud jich máte deset současně, žádné SLA bez kapacitního závazku (počet souběžných incidentů, počet vývojářských hodin v ceně paušálu) není reálně vymahatelné.

V české SMB se měsíční SLA paušál typicky pohybuje mezi 18 a 120 tisíci Kč podle tieru a velikosti aplikace. Co za tu cenu kupujete, ale není jen reakce na incident — kupujete obvykle balíček.

Typický rozsah business-hours SLA v ceně 35 tisíc Kč měsíčně obsahuje monitoring a alerting, security patche operačního systému a knihoven, dohled nad cloudovým účtem, drobné změny do 4 MD měsíčně, eskalační proces s konkrétním tech leadem a měsíční reporting o SLA metrikách. To, co v ceně typicky není — větší featury, které spadají do samostatného T&M nebo fixed-price kontraktu.

U projektu pro Sportybe Europe GmbH provozujeme kontinuální vývoj a podporu od roku 2020 — to je jiný režim než klasické SLA, je to spíš dlouhodobé partnerství s flexibilním objemem. Pro startupy a scale-upy s aktivním vývojem je tento hybrid (SLA + dev kapacita) často výhodnější než striktní oddělení supportu od vývoje.

Pozor na cenovou pást — nabídky pod 10 tisíc Kč měsíčně pro netriviální produkční aplikaci jsou téměř vždy nabídky bez monitoringu a bez reálné kapacity. Dodavatel počítá, že se nic nestane, a když se stane, fakturuje extra. To je hazard, ne SLA.

První tři měsíce po hand-offu do SLA režimu jsou nejdůležitější. Většina chyb se neukáže na den jedna, ale po prvním měsíčním cyklu (uzávěrka, dávkové reporty), prvním sezónním špičkovém zatížení nebo prvním automatickém update knihoven.

U integrace s GFŘ přes O2 IT Services jsme zvládali komplexitu WSO2 a snížili počet deployment chyb díky automatizovanému packagingu — to je typický příklad, kdy se hand-off nepovedl na první pokus a museli jsme procesy iterovat.

Praktická doporučení pro první kvartál — týdenní status meeting s tech leadem, ne měsíční. Definovaný eskalační kontakt na obou stranách (jméno, telefon, ne jen ticketing systém). Po prvním měsíci formální revize SLA metrik a úprava prahových hodnot — často se ukáže, že nastavené hodnoty jsou buď příliš přísné (zbytečně budí lidi) nebo příliš volné (incident proklouzne).

Pokud zvažujete přechod aplikace do SLA režimu nebo přepracování stávajícího kontraktu, ozvěte se — úvodní revizi SLA dokumentu a infrastruktury v rozsahu do 5 MD děláme zdarma a do týdne dostanete konkrétní seznam rizik a doporučení, co ve smlouvě upravit.