Incidens menedzsment Roskó Tibor

5.1. Goal of incident management gyors helyreállítás minimalizálni az üzleti folyamatok sérülését szolgáltatás minőség és elérhetőség biztosítása normál működés az SLA (Service Level Agreement) –ban van deklarálva

5.2. Scope of IM

Az ITIL szerint: bármely esemény, amely nem része a normál szolgáltatásnak és megtörtént vagy jövőbeli megszakítás, visszaesés a szolgáltatás minőségében egy incidens.

szolgáltatás igénylés alkalmazás nem elérhető hiba: a felhasználó nem tud dolgozni lemez használati limit túllépés hardver rendszer leállás automata riasztás a nyomtató nem nyomtat a config nem elérhető szolgáltatás igénylés infó, tanács, dokumentáció kérés elfelejtett jelszó

szolgáltatás igénylés RFC-nek tekinthető a valóságban egy rendszerben van kezelve, ezért minden incidens cégen belül létrehozható külön RFC menedzsment technikai orientáltságú rendszer-felügyeleti eszköz az automatikusan regisztrált eseményeket a normál működés szintjén tartja nyílván az incidens leírásánál jelenik meg, mivel nem érinti a felhasználói szolgáltatásokat

bemenetek incidens részletei a Service Desktől config részletek a CMDB-ből válasz, van-e egyező probléma, ismert hiba? megoldás részletei RFC válasz a megoldásra

5.3. Basic concepts

5.3.1. Incidens kezelés a problémák megoldásában nem csak IT részleg vesz részt Service Desk monitorozza és kezeli az összes regisztrált incidenst a hatékonyság, eredményesség érdekében előre meghatározott rend szerint járnak el, ami szoftveresen támogatott

SD által azonnal nem megoldható incidens átkerül egy speciális csapathoz megoldani a lehető leggyorsabban, a felhasználót legkevésbé zavarva az ok megszüntetése és ennek elfogadása esetén az incidens lezárható

státuszok új elfogadott ütemezett átadva spec-nek WIP: work in progress megoldva lezárva

pl: hálózati hiba miatt nem működik a nyomtató Fontos, hogy minden esemény teljes életciklusa naplózva legyen, hogy az ügyfeleknek naprakész információt lehessen szolgáltatni. update history modify status modify priority monitor costs Az eredeti bejelentés a megoldás folyamán módosulhat, de meg kell őrizni az eredeti leírást! pl: hálózati hiba miatt nem működik a nyomtató

incidens kezelés része változtató neve változás dátuma, ideje mi változott (prioritás, státusz) miért mennyi időbe telt

hozzáférési jogok 3. fél részvétele a megoldási folyamatban egyes állomásokon más nevében frissítenek

5.3.3. Funkcionális vs Hierarchikus escalation Escalation: olyan mechanizmus, amely időben segíti az incidens megoldását a teljes megoldási folyamat során.

Funkcionális Átvinni egy incidenst 1. szintről 2. szintre tudás vagy hozzáértés hiánya miatt. Előre meghatározott intervallumokban történik az ellenőrzés. Az automatikus lefutáshoz körültekintően kell megadni az intervallumokat, hogy azok ne lépjék túl a SLA-ban megadottakat.

Hierarchikus Előre látható, hogy az incidens megoldása nem fér bele a megadott időbe vagy nem lesz elfogadható. Manuálisan a SD által avatkozik be, ha nincs megfelelő ismeret a megoldáshoz. Automatikusan csak akkor ha nagy intervallum után sem lesz elfogadható megoldás.

5.3.4. Prioritás Előre meghatározott incidens prioritások, az okozott fennakadás szerint. A megoldás általánosan meg van fogalmazva a SLA-ban, rendszerint kategorizálva.

SD szerepe az IM minden incidens a SD-nek van bejelentve általa van regisztrálva, auto generált id-vel az automatikusan létrejött incidenseket csak regisztrálni kell az incidensek ~85% itt van megoldva minden incidenst monitoroz

példa incidens rögzítésére alap adatok rögzítése (idő, probléma) a service request a céges standard szerint lesz megadva CMDB-beli CI-k, amelyek a hibához kapcsolódnak ki vannak szelektálva prioritás, auto id megadása incidens értékelés, ha már van ismert megoldás, azonnali tanács adása lezárás: megoldás leírása, kategorizálás ha nincs megoldás átkerül a 2. szintre

5.3.5. Kapcsolat incidens, probléma, ismert error, RFC között incidens: IT infrastruktúrában bekövetkező hibák, ezek következményei, tervezett munkák során bekövetkező hibák A hibaelhárítás sok esetben kis energiával javítható, akár az ügyfél által pc, network router reset

Ha nem ismert az incidens oka, akkor a hiba az infrastruktúrában van Létre kell hozni egy hiba rekordot A megoldás gyakran más hibákon keresztül nyerhet megoldást azáltal, hogy a korábbi hibák megoldásait használjuk fel.

Egyezés esetén a hiba átvihető egy már ismert hibára, ezáltal megoldhatóvá válik RFC infrastruktúra hiba megoldva

A vizsgálat közben a Problem Management megoldást találhat az incidensre (ismeretlen hiba) és jelzi az IM-nek, hogy az incidens ismert hiba vagy lezárt státuszba kerül.

5.4. Benefits of IM Elsődleges, hogy az alábbiak szerinti folyamatmodellt követi

az üzlet szempontjából csökkenti a hibák időbeli megoldását, nő a hatékonyság proaktív fejlesztések az elérhető üzletközpontú menedzsment információk SLA-ba integrálása

IT szervezet számára fejlettebb monitorozás, SLA betartása fejlettebb menedzsment információ a szolgáltatás minőségéről jobb munkaerő-kihasználtság, nagyobb hatékonyság megszűnnek az elveszett, rosszul javított incidensek pontosabb CMDB információk, folyamatos incidens követés

Ha nincs vagy rossz az IM senki nem kezeli az incidenseket, ezek súlyosbodnak, romlik a szolgáltatás minősége a szakértő kisegítő személyzet az állandó megszakítások miatt kevésbé hatékony az üzleti személyzet összezavarodik mert mindenki mástól kér segítséget incidensek gyakori újraértékelése, már meglévő megoldások hozzákapcsolása helyett koordinált menedzsment információ hiánya elveszett, rosszul megoldott incidensek

Köszönöm a figyelmet!