Séria: Ako písať dokumentáciu a manuály v IT projekte
Reálny problém z praxe
Systém bol nedostupný.
Používatelia hlásili výpadok.
Klient očakával okamžitú opravu.
Dodávateľ tvrdil, že problém je v infraštruktúre klienta.
IT admin klienta tvrdil, že aplikácia nefunguje.
Support nevedel, komu incident priradiť.
Výsledok:
- oneskorené riešenie
- frustrácia na oboch stranách
- eskalácia, ktorá sa dala predísť
Problém nebol len technický.
Bol v tom, že nikto nemal jasne definované hranice zodpovednosti.
Čo sa tu vlastne pokazilo (analýza systému)
Chýbali tri veci:
- SLA (čo garantujeme)
- Zodpovednosti (kto čo rieši)
- Prevádzkové hranice (kde končí systém a začína prostredie)
Dokumentácia sa sústredila na funkcionalitu.
Ignorovala prevádzku.
To znamená:
- systém nemal definované pravidlá fungovania v reálnej prevádzke
Skutočné náklady (čas, chaos, riziko)
Ak nie sú tieto veci zdokumentované:
- incidenty sa presúvajú medzi tímami
- nikto nevie, kto má konať
- reakčný čas je nepredvídateľný
- vznikajú konflikty medzi dodávateľom a klientom
- SLA existuje len „na papieri“
Typická veta z praxe:
„To nie je naša zodpovednosť.“
Bez toho, aby bolo jasné, koho je.
Minimálny model riešenia
Cieľ nie je napísať právny dokument.
Cieľ je jasne definovať, kto za čo zodpovedá a v akých hraniciach.
1. SLA – čo garantujeme
Admin dokumentácia má obsahovať základné parametre:
- dostupnosť systému
- reakčný čas na incident
- čas na vyriešenie
- plánované odstávky
Príklad:
| Parameter | Hodnota |
| Dostupnosť | 99,5 % |
| Reakčný čas (kritický incident) | do 1 hodiny |
| Oprava | do 8 hodín |
Bez toho klient nevie, čo môže očakávať.
2. Zodpovednosti (kto rieši čo)
Kľúčová časť, ktorá často chýba.
| Oblasť | Dodávateľ | Klient (IT admin) |
| Aplikácia | áno | nie |
| Server | nie | áno |
| Databáza | čiastočne | áno |
| Sieť | nie | áno |
Musí byť jasné:
- kto rieši aplikáciu
- kto rieši infraštruktúru
- kto rieši konfiguráciu
Bez toho vznikajú konflikty.
3. Prevádzkové hranice systému
Admin musí vedieť:
- kde končí zodpovednosť aplikácie
- kde začína zodpovednosť prostredia
Príklad:
- aplikácia neodpovedá → problém aplikácie
- server neodpovedá → problém infraštruktúry
- integrácia zlyháva → problém závislosti
Toto musí byť zdokumentované.
4. Scenáre incidentov
Dokumentácia má obsahovať:
- typické incidenty
- kto ich rieši
- aký je postup
Príklad:
„Systém je nedostupný“
- over infraštruktúru (IT admin)
- over logy aplikácie (dodávateľ)
- rozhodni, kto pokračuje
5. Prepojenie na support
Support musí vedieť:
- komu priradiť ticket
- kedy eskalovať
- čo zbierať (logy, čas, identifikátory)
Bez toho sa incidenty riešia neefektívne.
6. Prepojenie na systémové požiadavky
SLA platí len v podporovanom prostredí.
Ak klient:
- použije nepodporovanú verziu databázy
- nasadí systém na slabý hardware
SLA nemusí platiť.
Toto musí byť explicitne uvedené.
Mini checklist
- Je definovaná dostupnosť systému?
- Sú definované reakčné a riešiace časy?
- Je jasné, kto rieši aplikáciu vs infraštruktúru?
- Sú definované prevádzkové hranice?
- Vie support, komu priradiť incident?
- Je SLA prepojené so systémovými požiadavkami?
Ak nie, prevádzka systému je nepredvídateľná.
Prepojenie na kvalitu a workflow
SLA a zodpovednosti nie sú len prevádzková téma.
Sú základ:
- dôvery medzi dodávateľom a klientom
- efektívneho riešenia incidentov
- škálovania systému
Z testerského pohľadu:
Ak nie sú jasné hranice systému, tester nevie:
- čo má byť garantované
- čo je porušenie SLA
- čo je problém mimo systému
Krátke zhrnutie
SLA, zodpovednosti a hranice systému definujú:
- čo systém garantuje
- kto čo rieši
- kde končí jeho zodpovednosť
Bez toho:
- vznikajú konflikty
- incidenty sa riešia pomaly
- dôvera medzi tímami klesá
Administrátorská príručka bez tejto časti nie je kompletná.
Neopisuje systém v prevádzke.