SLA u podpory aplikace: co skutečně garantuje a na co si dát pozor

SLA má převést očekávání od podpory aplikace do konkrétních a měřitelných závazků. Reakce do čtyř hodin ale není totéž jako oprava do čtyř hodin a nepřetržitý monitoring nemusí znamenat lidskou podporu 24/7. O skutečné hodnotě SLA rozhoduje především rozsah služby, provozní doba, priority incidentů, způsob měření a postup při nesplnění.

Dokud je aplikace jen pomocným nástrojem, může firmě stačit neformální domluva s vývojářem. Jakmile však ovlivňuje objednávky, výrobu, práci zaměstnanců nebo zákaznickou péči, potřebuje firma vědět, kdo incident převezme, kdy se jím začne zabývat a jak bude probíhat eskalace. Právě to má kvalitní SLA vyjasnit ještě před prvním vážným problémem.

Co je SLA a co skutečně garantuje

SLA (Service Level Agreement) je dohoda o úrovni poskytovaných služeb, obvykle jako součást smlouvy o podpoře nebo její příloha. Popisuje měřitelné podmínky spolupráce: například reakční dobu, dostupnost služby, provozní hodiny, způsob řešení incidentů a pravidla eskalace.

SLA negarantuje automaticky nepřetržitý provoz ani okamžité odstranění každé chyby. Platí pouze závazky, které jsou v něm jednoznačně definované. Pokud dohoda uvádí reakci do čtyř hodin, ale neobsahuje cílový čas obnovení nebo vyřešení, nelze ji vykládat jako opravu do čtyř hodin.

Pro správné čtení SLA pomáhá rozlišovat tři související pojmy:

• SLI (Service Level Indicator) je měřený ukazatel, například dostupnost, podíl úspěšných požadavků nebo rychlost odezvy.
• SLO (Service Level Objective) je cílová hodnota ukazatele, například dostupnost 99,9 % za kalendářní měsíc.
• SLA (Service Level Agreement) převádí vybrané cíle do dohody mezi klientem a dodavatelem a může stanovit následky jejich nesplnění.

Takto pojmy vymezuje také Google Site Reliability Engineering. Pro klienta z toho plyne jednoduché pravidlo: každý slib ve smlouvě musí mít ukazatel, cílovou hodnotu, období měření a jasně popsaný postup, pokud se cíl nepodaří splnit.

Reakce, obnovení provozu a vyřešení jsou tři různé časy

Nejčastější nedorozumění v aplikační podpoře vzniká záměnou tří milníků:

Příklad: po nové verzi přestane fungovat platba kartou. Podpora incident do 30 minut potvrdí, za další hodinu vrátí předchozí verzi a obnoví platby. Trvalou opravu nové verze nasadí následující pracovní den po analýze a testování. Reakční doba je 30 minut, obnovení trvá 90 minut a definitivní vyřešení přichází později. Každý čas popisuje jiný výsledek.

Pevnou dobu vyřešení navíc nelze vždy rozumně garantovat. Incident může vzniknout v externí platební bráně, cloudové službě nebo integraci, kterou tým podpory neovládá. Praktické SLA proto často garantuje rychlou reakci, způsob průběžné komunikace a odhad dalšího postupu po úvodní diagnostice. Pro kritické systémy je vhodné sjednat také cílový čas obnovení provozu.

Monitoring 24/7 není automaticky podpora 24/7

Monitoring může aplikaci kontrolovat nepřetržitě, zatímco lidé reagují pouze v definované pracovní době. Systém tedy může zachytit výpadek v sobotu ve dvě ráno, ale smluvní reakční doba začne běžet až v nejbližším servisním okně. Nepřetržitá technická kontrola a nepřetržitá pohotovost týmu jsou dvě různé služby.

Ve smlouvě proto ověřte:

• ve kterých dnech a hodinách podpora funguje;
• zda se reakční doba počítá jen v těchto hodinách;
• jakým kanálem se incident musí nahlásit;
• kdo dostává upozornění z monitoringu a co po něm následuje;
• zda existuje pohotovost pro kritické incidenty mimo běžnou dobu.

Pokud aplikace vydělává peníze večer, o víkendech nebo během státních svátků, musí tomu odpovídat i podpora. Samotné tvrzení „monitorujeme 24/7“ tento požadavek neřeší.

Sedm parametrů, podle kterých SLA porovnávat

1. Rozsah služby a odpovědnosti

SLA má určit, které aplikace, prostředí a komponenty zahrnuje. Patří sem produkce, testovací prostředí, databáze, integrace, domény, DNS, certifikáty nebo infrastruktura? Stejně důležité jsou výluky a rozhraní odpovědností. Bez nich se při incidentu může ukázat, že problém leží mezi několika dodavateli a nikdo nemá povinnost převzít koordinaci.

2. Priority podle dopadu

Kritický incident by neměl být definován pocitem naléhavosti, ale konkrétním dopadem: aplikace je nedostupná všem, nelze přijímat objednávky nebo hrozí ztráta dat. Nižší prioritu může mít omezená funkce s náhradním postupem. SLA má také určit, kdo prioritu přiděluje a kdy ji může změnit.

3. Čas a servisní okno

U každé priority musí být jasné, zda uvedený čas znamená reakci, obnovení, nebo vyřešení. Důležitý je i začátek měření. Požadavek odeslaný mimo pracovní dobu může začít běžet okamžitě, nebo až při otevření podpory – obě varianty jsou možné, ale smlouva musí vybrat jednu.

4. Komunikace a eskalace

Definujte kontaktní kanály, oprávněné osoby, povinné údaje v hlášení a četnost aktualizací během kritického incidentu. Užitečná eskalace neznamená jen další telefonní číslo. Určuje, kdo přijímá rozhodnutí, pokud je potřeba vrátit verzi, odstavit část funkcí nebo zapojit provozovatele infrastruktury.

5. Měření dostupnosti

Dostupnost musí být měřena z pohledu, který odpovídá zkušenosti uživatele. Funkční server ještě neznamená, že lze dokončit objednávku. SLA proto musí uvést zdroj dat, sledované části služby, interval a vyhodnocované období. AWS Well-Architected Framework zároveň upozorňuje, že výsledek ovlivňují plánované odstávky a závislosti na dalších systémech.

Při nepřetržitém provozu po dobu 30 dní znamenají běžné cíle přibližně tuto maximální nedostupnost:

Každá další „devítka“ vyžaduje odolnější architekturu, redundanci, automatizaci obnovy a testování. Vyšší procento proto není zdarma a nemusí být ekonomicky správnou volbou.

6. Zálohy, RTO a RPO

Informace „data zálohujeme“ nestačí. U kritické aplikace potřebujete znát frekvenci záloh, dobu uchování a výsledky testů obnovy. RTO (Recovery Time Objective) určuje cílový čas obnovení služby. RPO (Recovery Point Objective) vyjadřuje, o jak stará data může firma při obnově přijít. Tyto hodnoty musí odpovídat tomu, kolik hodin provozu a dat si firma může dovolit ztratit.

7. Výjimky, reporting a následky

SLA má konkrétně vyjmenovat, které události se do plnění nezapočítávají, například plánovaná údržba nebo výpadek systému třetí strany. Má také určit, jak klient dostane report a co následuje při nedodržení závazku. Vedle finanční kompenzace může jít o povinnou analýzu příčiny, nápravný plán nebo změnu provozního postupu.

Jak je nastavená základní podpora aplikace v 1. Web IT

U základní podpory aplikace v 1. Web IT garantujeme reakci do čtyř hodin na požadavky zaslané na podpora@1webit.cz nebo nahlášené na čísle +420 773 337 303 v pracovní době 9:00–17:00. Jde o reakční dobu, nikoli o garanci definitivního vyřešení každého požadavku do čtyř hodin.

Základní podpora zahrnuje kontinuální monitoring dostupnosti, pravidelné bezpečnostní kontroly, testovací server, provoz zálohovaného repozitáře GitLab až pro deset uživatelů, správce hesel Bitwarden pro organizaci a deset uživatelů a administraci projektu včetně souvisejících domén, DNS a serverů. Podpora tak vytváří provozní zázemí aplikace a neomezuje se jen na příjem hlášených chyb.

Je však potřeba odlišit aplikační podporu od monitoringu a správy serverové infrastruktury. Automatický dohled může běžet nepřetržitě, ale reakce lidí se řídí podmínkami sjednané služby. Pohotovost mimo pracovní dobu, různé časy podle priority nebo další garance se řeší individuálně v rámci rozšířené podpory.

Jak zvolit správnou úroveň SLA

Nezačínejte otázkou „Jak rychlou podporu chceme?“, ale otázkou „Co se stane, když aplikace hodinu nefunguje?“ Vyčíslete ztracené objednávky, neproduktivní čas lidí, smluvní rizika a dopad na zákazníky. Potom určete, které funkce jsou skutečně kritické a zda potřebují rychlou reakci, rychlé obnovení, nebo obojí.

Pro rozhodnutí pomůže jednoduché rozdělení:

• Nízký dopad: výpadek lze překlenout ručním postupem a neblokuje zákazníky. Obvykle stačí podpora v pracovní době a garantovaná reakce.
• Střední dopad: výpadek omezuje tým nebo část zákazníků a s každou hodinou roste ztráta. Dává smysl více priorit, kratší reakce na kritické případy a pravidelné aktualizace.
• Vysoký dopad: aplikace přímo řídí prodej, výrobu nebo práci s citlivými daty. Potřebujete cíle obnovy, pohotovost mimo pracovní dobu, otestované zálohy a architekturu schopnou sjednané cíle splnit.

Před podpisem ověřte i předání přístupů, dokumentace a zdrojového kódu při ukončení spolupráce. Podpora nemá vytvářet nechtěnou závislost na jediném dodavateli. Praktické kroky shrnujeme v článku o převzetí aplikace po jiném dodavateli.

Dobré SLA je realistické, měřitelné a srozumitelné

Smyslem SLA není získat nejkratší číslo v tabulce. Má nastavit úroveň služby, která odpovídá obchodnímu dopadu výpadku a kterou lze technicky i finančně splnit. Nejdůležitější je rozlišit reakci od obnovy a vyřešení, znát skutečné servisní hodiny a nepřijímat procento dostupnosti bez popisu měření.

Pokud vybíráte podporu pro stávající aplikaci, nejprve posoudíme její technický stav, závislosti a provozní rizika. Na jejich základě lze navrhnout rozsah podpory odpovídající vašemu projektu místo univerzálního SLA, které je buď zbytečně drahé, nebo nedostatečné.

Nejčastější otázky k SLA

Znamená reakce do čtyř hodin také opravu do čtyř hodin?

Ne. Reakční doba určuje, dokdy podpora požadavek převezme a začne řešit. Čas obnovení provozu nebo definitivního vyřešení musí být definován samostatně, pokud má být garantovaný.

Zaručuje monitoring 24/7 také zásah technika v noci?

Pouze pokud to smlouva výslovně uvádí. Monitoring může problém nepřetržitě zaznamenávat, zatímco lidská podpora funguje jen v určeném servisním okně.

Potřebuje SLA i menší firma?

Rozhodující není velikost firmy, ale dopad výpadku. SLA dává smysl vždy, když pomalá reakce nebo delší nedostupnost způsobí významnou finanční, provozní, smluvní nebo reputační škodu.