Az SLA nem azt jelenti, hogy minden hiba nyolc órán belül megszűnik

Az SLA - Service Level Agreement, vagyis szolgáltatási szint megállapodás - azt írja le, milyen keretek között történik egy rendszer támogatása és üzemeltetése. Meghatározhatja a support időablakát, a hibák prioritását, az első reakciót, a kommunikációt, a rendelkezésre állás mérését és az incidenskezelés folyamatát.

Gyakori félreértés, hogy a „8 órás válaszidő” azt jelenti: nyolc órán belül kész a javítás. A valóságban ez általában azt jelenti, hogy a szolgáltató ennyi időn belül visszajelez, rögzíti és megkezdi a probléma kezelését az adott feltételek szerint.

A legfontosabb fogalmak

Első válaszidő

A hibabejelentés és az első érdemi visszajelzés közötti idő. Az érdemi válasz nem automatikus „megkaptuk” üzenet, hanem annak jelzése, hogy a bejelentést értelmezték, prioritást kapott, és megkezdődik a kivizsgálás.

Diagnosztikai idő

Az az idő, amely alatt meghatározható a hiba oka vagy legalább a problémás terület. Egy incidens eredhet alkalmazáskódból, adatbázisból, infrastruktúrából, hálózatból, külső API-ból, hibás adatból vagy felhasználói jogosultságból.

Helyreállítási idő

Mennyi idő alatt áll vissza az üzletileg szükséges működés. Ez történhet ideiglenes kerülőúttal is. Például egy hibás új funkció kikapcsolható, amíg a végleges javítás elkészül.

Megoldási idő

A probléma végleges javításáig eltelt idő. Ez függ a hiba reprodukálhatóságától, összetettségétől, külső szereplőktől, hozzáférésektől és a szükséges teszteléstől.

Rendelkezésre állás

A mérési időszak azon aránya, amikor a szolgáltatás a meghatározott feltételek szerint használható volt. Fontos, hogy az SLA pontosan meghatározza:

  • mit mérünk;
  • honnan mérjük;
  • mi számít kiesésnek;
  • milyen karbantartási ablakok kivételek;
  • külső szolgáltató hibája beleszámít-e;
  • hogyan történik a kerekítés és riporting.

Mit jelentenek a „kilencesek”?

Egy 30 napos, 43 200 perces hónapban az elméleti maximális kiesés körülbelül:

Cél rendelkezésre állás Maximális kiesés / 30 nap
99% 7 óra 12 perc
99,5% 3 óra 36 perc
99,9% 43 perc 12 másodperc
99,95% 21 perc 36 másodperc
99,99% 4 perc 19 másodperc

Minél több „kilencet” vállalunk, annál komolyabb redundancia, monitoring, automatizáció, ügyelet és infrastruktúra szükséges. A magasabb rendelkezésre állás nem pusztán egy mondat a szerződésben, hanem költséges műszaki és szervezési képesség.

Prioritási szintek

P1 - Kritikus

A teljes rendszer vagy kulcsfontosságú üzleti funkció nem érhető el, nincs elfogadható kerülőút, és jelentős üzleti kár keletkezik.

Példa: a rendelési rendszer minden felhasználónál leállt.

P2 - Magas

Fontos funkció hibás, de a rendszer részben működik, vagy van korlátozott kerülőút.

Példa: az automatikus számlázás nem működik, de a rendelés rögzíthető.

P3 - Normál

Korlátozott hatású hiba, amely nem állítja le az alapfolyamatot.

Példa: egy export formázása hibás, de az adat elérhető.

P4 - Alacsony vagy fejlesztési igény

Kényelmi módosítás, designfinomítás, új riport vagy új funkció. Ez általában nem incidens, hanem backlogelem.

A prioritás nem csak az ügyfél által választott címke

A bejelentő természetesen jelezheti az üzleti hatást, de a végleges prioritást közös szabályrendszer alapján érdemes meghatározni. Ha minden hiba P1, valójában semmi sem kap valódi prioritást.

Hasznos kérdések:

  • hány felhasználót érint;
  • áll-e a bevételi vagy működési folyamat;
  • van-e kerülőút;
  • fennáll-e adatvesztés vagy biztonsági kockázat;
  • növekszik-e a hatás idővel;
  • külső szolgáltatás okozza-e.

Üzleti idő vagy 7x24?

A 24 órás első válaszidő jelenthet 24 munkaórát, következő munkanapot vagy 24 naptári órát. Ezek nem azonosak.

Az SLA-ban pontosan rögzíteni kell:

  • supportnapok és időzóna;
  • munkaszüneti napok;
  • bejelentési csatorna;
  • mikor indul az időmérés;
  • van-e éjszakai és hétvégi ügyelet;
  • mely prioritásokra vonatkozik a 7x24 kezelés.

A valódi 7x24 ügyelethez nem elég egy telefonszám. Szükséges rotáció, riasztás, dokumentáció, hozzáférés és döntési jogkör.

Mi lassíthatja a javítást?

  • a hiba nem reprodukálható;
  • hiányzik a pontos időpont, képernyőkép vagy felhasználói azonosító;
  • nincs megfelelő hozzáférés;
  • külső szolgáltató hibája áll fenn;
  • adatvesztés veszélye miatt óvatos migráció kell;
  • javítás után regressziós teszt szükséges;
  • ügyféloldali döntés vagy jóváhagyás hiányzik.

Ezért a megoldási időt sok rendszerben célértékként, nem feltétlenül abszolút garanciaként kezelik.

Mit tartalmazzon egy jó SLA?

  1. A támogatott rendszerek és környezetek listája.
  2. A bejelentési csatorna.
  3. Supportidő és időzóna.
  4. Prioritási definíciók.
  5. Első válaszidők.
  6. Kommunikációs gyakoriság kritikus incidensnél.
  7. Monitoring és riasztási felelősség.
  8. Tervezett karbantartás szabályai.
  9. Kizárások és külső függőségek.
  10. Riporting és felülvizsgálat.
  11. Mi tartozik hibajavításba és mi új fejlesztés.
  12. Eszkalációs útvonal.

A BT Digital megközelítése

A supportot úgy érdemes kialakítani, hogy az arányban álljon a rendszer üzleti kritikusságával. Egy bemutatkozó oldalhoz felesleges drága 7x24 ügyelet. Egy folyamatosan rendelést fogadó rendszerhez viszont nem elegendő az alkalmi e-mailes segítség.

A cél nem a hangzatos szám, hanem a működő incidenskezelési folyamat. Ezért külön kezeljük az első választ, a diagnózist, a helyreállítást és a végleges javítást.

Az SLA akkor értékes, ha minden fél ugyanazt érti a vállalások alatt, és a technikai háttér valóban képes teljesíteni azokat.