Odpověď hned: SLA správy IT musí přesně oddělit přijetí požadavku, reakci, zahájení práce, obnovení provozu a konečné vyřešení. Současně má určit priority, provozní dobu, eskalace, výluky, odpovědnost za třetí strany, způsob měření a následky nesplnění.
SLA není slib, že se technik ozve co nejdřív
SLA je měřitelná část smlouvy o poskytování služeb. Má říkat, na které služby se vztahuje, kdy začíná běžet čas, kdo přijímá incident, jak se určuje priorita a co následuje při nesplnění sjednaného závazku.
Věta „kritické požadavky řešíme přednostně“ nestačí. Neurčuje, co je kritický požadavek, za jak dlouho jej někdo posoudí ani zda dodavatel garantuje zahájení práce, nebo jen první odpověď.
Jeden incident navíc často zasáhne několik navazujících služeb. Přihlášení uživatele může záviset na Microsoft Entra ID, pošta na Exchange Online, práce z domu na firewallu a VPN, sdílené soubory na Synology DSM nebo QNAP QTS a obnova na samostatném zálohovacím úložišti. SLA proto nemá popisovat jen rychlost technika, ale také jeho roli při závadě internetu, cloudové služby, licence nebo hardwaru.
Přijetí, reakce a vyřešení nejsou totéž
Ve smlouvě hledejte samostatné definice nejméně pěti okamžiků.
- Přijetí požadavku: helpdesk vytvořil tiket a zaznamenal čas doručení. Automatické potvrzení dokládá, že systém zprávu přijal.
- Reakce: odpovědná osoba požadavek posoudila, ověřila jeho dopad, určila prioritu a sdělila další postup. Pokud se má za reakci počítat pouze automatická zpráva, musí to být ve smlouvě napsané jednoznačně.
- Zahájení práce: technik skutečně začal diagnostiku, omezení dopadu nebo obnovu. Oznámení „víme o problému“ samo o sobě nemusí znamenat zahájení zásahu.
- Obnovení služby: uživatelé mohou znovu pracovat, případně pomocí dočasného náhradního řešení.
- Vyřešení: příčina byla odstraněna, trvalá oprava ověřena a tiket uzavřen.
Dodavatel může garantovat reakční dobu, ale pro obnovení nebo vyřešení uvádět jen cílový čas. To je pochopitelné například při čekání na opravu cloudové služby nebo dodání náhradního dílu. Nabídka však musí jasně odlišit závazek, provozní cíl a nezávazný odhad.
Prioritu určuje dopad na provoz
Samotné označení P1 až P4 nic negarantuje. Každá úroveň musí mít popsaný dopad, rozsah, bezpečnostní riziko a dostupnost náhradního postupu.
| Priorita | Praktická definice | Typický příklad |
|---|---|---|
| P1 – kritická | Klíčový provoz stojí, incident se šíří nebo není použitelná náhrada | nedostupný hlavní informační systém, výpadek konektivity celé pobočky, probíhající bezpečnostní incident |
| P2 – vysoká | Významná skupina uživatelů nemůže pracovat nebo je zásadně omezená | nefungující přihlášení do Microsoft 365 pro celé oddělení, nedostupná VPN bez náhradní cesty |
| P3 – běžná | Dopad je omezený nebo existuje použitelný náhradní postup | problém jednoho počítače, pomalá aplikace, nefunkční kancelářská tiskárna |
| P4 – požadavek | Nejde o poruchu, ale o plánovanou změnu | založení účtu, instalace aplikace, příprava zařízení pro nového zaměstnance |
Smlouva má také určit, kdo prioritu přiděluje, kdo ji může změnit a jak se řeší nesouhlas zákazníka. Nefunkční tiskárna jednoho zaměstnance obvykle nezastaví firmu. Stejná porucha na jediném pracovišti pro tisk expedičních štítků ale může přerušit expedici a vyžadovat vyšší prioritu.
Bez tohoto pravidla může zákazník označovat každý požadavek jako kritický, zatímco dodavatel může závažné incidenty svévolně přesouvat do nižší priority.
Provozní doba určuje, kdy čas běží
Formulace „reakce do dvou hodin“ je neúplná, pokud neříká, zda jde o dvě běžné hodiny, nebo dvě hodiny v provozním okně podpory.
Modelový příklad: podpora funguje v pracovní dny od 8:00 do 17:00 a zákazník nahlásí incident v pátek v 16:30. Z dvouhodinové reakční doby se půl hodiny započítá v pátek a zbývající čas začne běžet v pondělí ráno. Reakce je potom splněna do pondělí 9:30, pokud do výpočtu nevstupuje svátek nebo samostatně sjednaná pohotovost.
SLA proto musí určit:
- pracovní dny, hodiny a časové pásmo;
- zacházení se státními svátky;
- priority obsluhované mimo běžnou pracovní dobu;
- způsob aktivace pohotovosti;
- telefonní a eskalační kontakty;
- interval aktualizací během kritického incidentu.
Běžný e-mail do servisní schránky nemusí aktivovat pohotovost. Pro P1 proto bývá potřeba zvláštní telefonní číslo nebo volba v zákaznickém portálu.
Rozsah musí odpovídat skutečnému prostředí
Paušál označený pouze jako „správa IT“ se špatně kontroluje. Příloha smlouvy má vyjmenovat spravované uživatele, zařízení, lokality a služby.
U cloudového prostředí nestačí napsat Microsoft 365. Rozsah může zahrnovat například Entra ID, Exchange Online, SharePoint, OneDrive, Teams, správu licencí a vícefaktorové ověřování. U lokální infrastruktury je potřeba odlišit správu firewallu, Wi-Fi, VPN, serverů, pracovních stanic, Synology DSM či QNAP QTS a zálohovacího systému.
Stejně přesně mají být popsané zahrnuté činnosti:
- helpdesk a vzdálená podpora;
- monitoring a vyhodnocení výstrah;
- aktualizace operačních systémů a spravovaných aplikací;
- správa uživatelských účtů a oprávnění;
- kontrola zálohovacích úloh;
- testy obnovy;
- výjezdy a práce na místě;
- vedení dokumentace a evidence přístupů.
Migrace, rozsáhlé projektové změny, licence, hardware nebo forenzní řešení bezpečnostního incidentu mohou být účtované samostatně. Smlouva ale musí říct, kde končí paušál, jak se práce mimo něj schvaluje a podle jakého ceníku se účtuje.
Pokud potřebujete rozsah nastavit podle konkrétního počtu uživatelů, zařízení a poboček, správu IT vám navrhneme podle skutečného prostředí, ne podle obecného balíčku.
Výluka nezbavuje dodavatele odpovědnosti za komunikaci
SLA může obsahovat výluky pro situace, které dodavatel přímo neovládá. Patřit mezi ně může výpadek poskytovatele internetu, porucha cloudové platformy, zásah jiné servisní firmy, čekání na náhradní díl nebo chybějící přístup potřebný k diagnostice.
Riziková je obecná věta „okolnosti mimo kontrolu dodavatele“. Ta může bez dalších pravidel zahrnout téměř každý složitější incident.
U každé závislosti na třetí straně má být jasné:
- kdo založí servisní požadavek u operátora, výrobce nebo distributora;
- kdo dodá logy, sériová čísla a další technické podklady;
- zda se čas SLA pozastaví;
- od jakého zaznamenaného okamžiku se pozastavení počítá;
- co musí být splněno pro opětovné spuštění času;
- jak často zákazník dostane aktualizaci;
- zda dodavatel hledá dočasné řešení.
Správce IT nemůže opravit síť operátora ani infrastrukturu Microsoftu. Může ale ověřit, zda problém skutečně neleží ve firemní síti, otevřít případ u provozovatele, dodat diagnostické údaje a koordinovat další postup. Tato odpovědnost má ve smlouvě zůstat i tehdy, když se samotná doba opravy do SLA nezapočítává.
Praktický postup při úplném výpadku připojení popisuje také krizový checklist pro nefunkční firemní internet.
Dostupnost služby není dostupnost podpory
Podpora 24/7 popisuje, kdy lze incident nahlásit a kdy je připravený tým, který jej začne řešit. Procentní dostupnost naopak vyjadřuje, jakou část sledovaného období byla konkrétní služba funkční podle sjednaného způsobu měření.
Smlouva musí určit:
- kterou službu dostupnost pokrývá;
- odkud se funkčnost měří;
- jak dlouhé je vyhodnocované období;
- co se považuje za nedostupnost;
- zda se odečítá oznámená údržba;
- jak se řeší částečný výpadek;
- kdo může výsledek ověřit.
U záloh potřebujete vedle dostupnosti podpory také RPO a RTO. RPO určuje nejvyšší přípustné stáří dat, ke kterým se lze po incidentu vrátit. RTO stanovuje cílovou dobu obnovení služby nebo dat. Rychlá reakce helpdesku sama o sobě neříká, jak aktuální data budou obnovena ani kdy s nimi firma začne pracovat.
Sjednanou obnovu je potřeba prakticky zkoušet. Samotný zelený stav zálohovací úlohy nepotvrzuje, že lze otevřít databázi, připojit virtuální server nebo obnovit požadovanou složku. Podrobnosti najdete v návodu na test obnovy zálohy a jeho dokumentaci.
Pozastavení času musí mít pravidla
Dodavatel může potřebovat doplnění informací, přístup do systému nebo rozhodnutí zákazníka. SLA smí v takové situaci umožnit pozastavení času, ale nemělo by stačit změnit stav tiketu na „čekáme“.
U každého pozastavení má být zaznamenáno:
- co přesně chybí;
- kdo má další krok provést;
- kdy byl požadavek na součinnost odeslán;
- kdy byl zákazník upozorněn;
- kdy byla součinnost dodána;
- kdy začal čas znovu běžet.
Nejasný požadavek typu „pošlete více informací“ není dobrým podkladem pro několikadenní pozastavení. Technik má uvést, zda potřebuje například čas chyby, jméno uživatele, snímek hlášení, vzdálený přístup nebo schválení odstávky.
Eskalace musí fungovat i bez konkrétního technika
SLA nemá stát na osobním telefonním čísle jednoho správce. Musí existovat servisní kanál, zastupitelnost a jasná cesta pro eskalaci.
U kritického incidentu potřebujete vědět:
- kam incident nahlásit;
- kdo potvrzuje prioritu;
- kdy se zapojí seniorní technik nebo vedoucí podpory;
- kdo komunikuje s vedením zákazníka;
- v jakých intervalech chodí aktualizace;
- kdo rozhoduje o dočasném řešení nebo plánované odstávce.
Eskalace neznamená jen přeposlání tiketu jinému člověku. Má zvýšit úroveň řízení incidentu, přivést potřebnou odbornost a zajistit pravidelnou komunikaci.
Bez měření nelze SLA vyhodnotit
Zdrojem vyhodnocení má být tiketovací systém nebo jiný předem určený záznam, ke kterému lze zpětně dohledat časové značky.
U každého požadavku má být zaznamenáno:
- přijetí;
- první kvalifikovaná reakce;
- zahájení práce;
- obnovení provozu;
- konečné vyřešení;
- priorita a její případné změny;
- pozastavení času a jeho důvod;
- komunikace se třetí stranou;
- souhlas zákazníka s uzavřením nebo způsob automatického uzavření.
Měsíční report má ukazovat plnění samostatně podle priorit a typu závazku. Jediný celkový průměr může zakrýt opožděný kritický incident mezi desítkami rychle uzavřených drobností.
Před podpisem si vyžádejte anonymizovaný vzor reportu. Ověřte, že obsahuje údaje, které smlouva používá pro výpočet SLA, a že lze dohledat důvod každé výjimky.
Průběžné sledování infrastruktury může část incidentů zachytit ještě před hlášením uživatele. Musí však být jasné, co monitoring skutečně kontroluje a zda výstraha automaticky zakládá tiket.
Následky nesplnění patří do smlouvy
SLA má popsat postup reklamace a způsob posouzení sporného incidentu. Může stanovit servisní kredit, slevu, nápravné opatření nebo možnost ukončit spolupráci při opakovaném neplnění.
Důležité je určit:
- kdo může nesplnění reklamovat;
- do kdy musí reklamaci podat;
- z jakých záznamů se vychází;
- jak se vypočítá případná kompenzace;
- zda má kompenzace měsíční limit;
- co se považuje za opakované porušení;
- jak budou předány přístupy, dokumentace a data po ukončení služby.
Kompenzace sama neobnoví nefunkční provoz. Nutí však obě strany přesně určit, který parametr je závazný a jak se jeho splnění prokazuje.
Kontrolní tabulka pro porovnání nabídek
Do prostředních sloupců přepište přesné znění obou nabídek. Prázdné místo nebo ústní příslib označte jako nevyjasněný bod.
| Kontrolní bod | Nabídka A | Nabídka B | Co musí být výslovně uvedeno |
|---|---|---|---|
| Rozsah | ___ | ___ | zařízení, uživatelé, lokality a služby |
| Přijetí tiketu | ___ | ___ | povolené kanály a rozhodná časová značka |
| Reakce | ___ | ___ | konkrétní úkon a lhůta podle priority |
| Zahájení práce | ___ | ___ | samostatná definice a způsob měření |
| Obnovení a vyřešení | ___ | ___ | závazek, provozní cíl nebo odhad |
| Priority | ___ | ___ | dopad, rozsah, bezpečnost a náhradní postup |
| Provozní doba | ___ | ___ | dny, hodiny, svátky a časové pásmo |
| Pohotovost | ___ | ___ | způsob aktivace a zahrnuté priority |
| Eskalace | ___ | ___ | kontakty, pořadí a interval aktualizací |
| Výluky | ___ | ___ | konkrétní a srozumitelný seznam |
| Pozastavení času | ___ | ___ | důvody, začátek, konec a potřebná součinnost |
| Třetí strany | ___ | ___ | kdo komunikuje a co dál zajišťuje |
| Zálohy | ___ | ___ | rozsah, RPO, RTO a test obnovy |
| Reporting | ___ | ___ | zdroj dat, četnost a obsah |
| Následky nesplnění | ___ | ___ | reklamace, náprava a případná kompenzace |
| Ukončení spolupráce | ___ | ___ | předání přístupů, dokumentace a dat |
Co si nechat doplnit před podpisem
Dobrá SLA umožní dvěma lidem dojít nad stejným tiketem ke stejnému výsledku: určit prioritu, začátek a konec měření, dobu oprávněného pozastavení i to, zda byl závazek splněn.
Před podpisem proto zkuste podle smlouvy vyhodnotit tři vlastní situace:
- nefunguje internet v celé pobočce;
- jeden uživatel se nemůže přihlásit;
- firma potřebuje naplánovat založení účtu pro nového zaměstnance.
Pokud u některé situace nelze určit prioritu, běh času, odpovědnou osobu a způsob eskalace, SLA potřebuje doplnit. Nejasnosti patří do smlouvy nebo její přílohy, ne pouze do e-mailu obchodníka.
Časté otázky
Je reakční doba totéž co doba vyřešení?
Ne. Reakce je kvalifikované převzetí a posouzení požadavku. Zahájení práce znamená první skutečný zásah, obnovení vrací službu do použitelného stavu a vyřešení představuje trvalou ověřenou nápravu. Každý okamžik má mít vlastní definici.
Musí mít malá firma podporu 24/7?
Ne automaticky. Rozhoduje provoz firmy, důležitost systémů a dopad nočního nebo víkendového výpadku. Pro část firem je vhodná podpora v pracovní době doplněná pohotovostí pouze pro kritické incidenty.
Co když problém způsobí Microsoft 365 nebo poskytovatel internetu?
Správce nemůže slíbit dobu opravy cizí infrastruktury. SLA ale může požadovat diagnostiku, otevření případu u třetí strany, předání logů, hledání náhradního řešení a pravidelné informování zákazníka.
Patří zálohování automaticky do správy IT?
Ne. Musí být výslovně uvedeno, která data se zálohují, kam, jak často, jak dlouho se kopie uchovávají a kdo kontroluje výsledek úloh. Samostatně mají být sjednány testy obnovy, RPO a RTO.
Jak poznám kvalitní SLA před podpisem?
Podle stejného incidentu musí zákazník i dodavatel určit stejnou prioritu, rozhodný začátek měření, provozní dobu, odpovědnost a způsob eskalace. Pokud výsledek závisí na ústním vysvětlení obchodníka, text ještě není dostatečně přesný.