Incidens menedzsment Roskó Tibor.

Az előadások a következő témára: "Incidens menedzsment Roskó Tibor."— Előadás másolata:

1 Incidens menedzsment Roskó Tibor

2 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

3 5.2. Scope of IM

4 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.

5 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ó

6 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

7

8 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

9 5.3. Basic concepts

10 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

11 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ó

12

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

14 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ó

15 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

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

17

18 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.

19 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.

20 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.

21 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.

22 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

23 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

24 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

25 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.

26

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

28

29 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.

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

31 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

32 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

33 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

34 Köszönöm a figyelmet!