35
Martin Sarnovský Katedra kybernetiky a umelej inteligencie Fakulta elektrotechniky a informatiky Technická univerzita v Košiciach Prev Prev ádzka služieb ádzka služieb (Service Operation) (Service Operation)

Martin Sarnovský Katedra kybernetiky a umelej inteligencie Fakulta elektrotechniky a informatiky

  • Upload
    garry

  • View
    54

  • Download
    0

Embed Size (px)

DESCRIPTION

Prev ádzka služieb (Service Operation). Martin Sarnovský Katedra kybernetiky a umelej inteligencie Fakulta elektrotechniky a informatiky Technická univerzita v Košiciach. Obsah. Úvod / ITIL v.3 Základné koncepty a procesy prevádzky služieb Event management Incident management - PowerPoint PPT Presentation

Citation preview

Page 1: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Martin Sarnovský

Katedra kybernetiky a umelej inteligencie Fakulta elektrotechniky a informatiky

Technická univerzita v Košiciach

PrevPrevádzka služiebádzka služieb(Service Operation)(Service Operation)

Page 2: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

ObsahObsah

Úvod / ITIL v.3

Základné koncepty a procesy prevádzky služieb

Event management

Incident management

Problem management

Request fullfillment

Change management

Page 3: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky
Page 4: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

PrevPreváádzkadzka služieb (Service služieb (Service operationoperation))

Dodávka dohodnutých úrovní služieb – užívateľom/zákazníkom Správa aplikácií Správa technológií Správa infraštruktúry

V tejto fáze životného cyklu – služby produkujú „hodnotu“ pre používateľa

Page 5: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

PrevPreváádzkadzka služieb (Service služieb (Service operationoperation) II.) II.

Cieľ – zabezpečiť rovnováhu medzi

Vnútorný pohľad IT vs. Biznis pohľad Stabilita vs. Odozva (Vnímavosť/Responsiveness) Kvalita služby vs. Náklady na službu Reaktívnosť vs. Proaktívnosť

Identifikácia podstatných príznakov pre „zdravie prevádzky“

Page 6: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Manažment udalostíManažment udalostí(Event management)(Event management)

Page 7: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Základné pojmyZákladné pojmy

Udalosť (Event) – zmena stavu, ktorá nejakým spôsobom ovplyvňuje konfiguračné položky, alebo priamo IT služby

Môže indikovať, že niečo nepracuje korektne => zaznamenanie incidentu (výpadok pripojenia k internetu)

Môže indikovať normálnu aktivitu, či potrebu vykonania rutinnej činnosti (normálna aktivita – log o prihlásení sa užívateľa do systému, rutinná činnosť – výmena náplne v tlačiarni)

Proces manažmentu udalostí – úzko prepojený s monitorovaním Na rozdiel od monitorovania nekontroluje stav komponentov, aj

keď k ničomu nedochádza

Page 8: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Udalosť nastane• Nie všetky detekované a registrované

•Notifikácia udalosti• CI vygeneruje notifikáciu (schopnosť ich generovania musí byť v návrhu)• Štandardná množina udalostí

• Detekovanie udalosti• Akonáhle je vygenerovaná notifikácia, detekuje sa udalosť

• Filtrovanie udalostí• Cieľ – rozhodnúť či udalosť zaradiť na spracovanie management toolom, alebo ignorovať

• Dôležitosť udalosti•Informatívna (user sa prihlásil)•Varovanie (zaťaženie pamäte 65%, ak bude 75%, kritický stav)•Výnimka (Server spadol)

Page 9: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Porovnanie udalosti•Ak je udalosť významná, treba rozhodnúť ako veľmi a aké akcie treba uplatniť• Correlation engine

•Porovnávanie s existujúcimi udalosťami

• Trigger - rozhoduje, aký typ odpovede bude vykonaný

• Zalogovať udalosť (logy)• Autoresponse (reštart zariadenia)• Zásah osoby – ak je vyžadovaný – možnosť eskalácie (vymeň náplň)• Incident/Problém/Zmena

• Review• Uzavretie udalosti

Page 10: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Manažment IncidentovManažment Incidentov(Incident Management)(Incident Management)

Page 11: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Základné pojmyZákladné pojmy

Incident – akákoľvek udalosť, ktorá nie je súčasťou štandardnej činnosti služby a ktorá spôsobí alebo môže spôsobiť prerušenie alebo zníženie kvality služby

Manažment incidentov - zaistiť čo najrýchlejšie obnovenie dodávky služby a minimalizovať dôsledky výpadku služby na obchodnú činnosť

Často ide len o implementáciu dočasného náhradného riešenia (workaround), ktoré ma za úlohu čo najrýchlejšie aspoň čiastočne sprístupniť dotknutú službu

Analýza dôvodov vzniku incidentu/prevencia nie je úlohou IM, ale PM

Page 12: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Manažment IncidentovManažment Incidentov

Jedna z najdoležitejších častí ITSM – „highly visible“ pre business – veľmi ľahko je možné demonštrovať jej hodnotu

Častokrát práve IM sa implementuje ako prvý pri zavádzaní ITSM

Dôsledky implementácie pre organizáciu: Schopnosť detekovať a riešiť incidenty vedie k zvýšeniu

dostupnosti služieb (nižší čas potrebný na reakciu, keď k incidentu dôjde)

Možnosť nachádzať spôsoby vylepšenia služieb (pochopením príčin, prečo incidenty vznikajú)

Page 13: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Modely IncidentovModely Incidentov

Mnohé z incidentov – Pramenia z niečoho, čo sa už udialo Pravdepodobne sa budú opakovať aj v budúcnosti

Dôležitosť modelovania incidentov – definícia štandardných krokov, ako sa správať ak sa vyskytnú

Model by mal obsahovať Kroky nutné k spracovaniu incidentu Chronologické poradie vykonávania týchto krokov Určenie zodpovedností Časové rámce Procedúry eskalácie

Page 14: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Identifikácia incidentu• Neakceptovateľné čakať na kontakt zákazníka

• Zalogovanie incidentu• Všetky musia byť zalogované• id, kategóriu, čas, dátum, CI, príbuzný problém, používateľa, riešiteľa, zaznamenané, notifikáciu...

• Kategorizácia incidentu

Page 15: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Stanovenie priority• urgencia incidentu/dopad, ktorý spôsobuje

• Počiatočná diagnostika• či je schopný byť vyriešený na súčasnej úrovni (napr. Service Desk)

• Eskalácia• Funkčná (SD presunie na IT)• Hierarchická (potreba notifikovať manažéra)

• Vyšetrovanie príčin/diagnóza• identifikácia udalostí, ktoré spôsobili incident• pochopenie následností

Page 16: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Vyriešenie a obnova funkcie• po nájdení riešenia obnovy dodávky služby, je tento prístup nasadený

• Uzavretie incidentu• Dotazník pre používateľa• Dokumentácia incidentu• Typ uzavretia (correct/incorrect)• Opakujúci sa incident?• Formálne uzavretie

Page 17: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

RolyRoly

Eskalácia -

Prvá línia podpory („First-line support“) - agenti zákazníckeho centra

zodpovedný za záznam, klasifikáciu, porovnávanie, vedenie, vyriešenie (okrem prípadu eskalácie incidentu inej skupine podpory) a uzatvorenie incidentu

Druhá línia podpory („Second-line support“) – špecialisti členený podľa oblastí ich znalostí

Tretia línia podpory („Third-line support“) – externí špecialisti tretích strán

Incident manažér („Incident Manager“) – Service Desk Manager

Page 18: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

ProblémyProblémy

Používatelia a aj zamestnanci obchádzajú procedúry – riešia problémy sami, sami kontaktujú špecialistov

Následok – stráca sa informácia o incidente, ktorá môže byť vhodná pre PM, CM a pod.

Priveľa incidentov, preťaženie a oneskorovanie – nedostatok času na ich zaznamenanie, nepresná evidencia => nejasný popis => nevhodné riešenie

Eskalácia – ak sa incidenty nevyriešia na prvej línii sú posúvané ďalej smerom na špecialistov, príliš veľa takýchto presunov => problémy

Nejasné definície a zmluvy – problémy s riešením incidentov, ak sú v katalógu služieb nejasne definované SLA, OLA

Nedostatok nadšenia

Page 19: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Manažment ProblémovManažment Problémov(Problem Management)(Problem Management)

Page 20: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Základné pojmyZákladné pojmy

Problém – neznáma základná príčina jedného alebo viacerých incidentov

Známa chyba (Known Error) – incident alebo problém, pre ktorý je známa hlavná príčina a pre ktorý existuje dočasné náhradné riešenie, alebo bola zaistená trvalá náhrada

Rozdiel medzi manažmentom incidentov a problémov IM - najrýchlejšie obnoviť poskytovanie služby a minimalizovať

dopady incidentu na obchodnú činnosť Nie vždy je incident vyriešený a môže sa v budúcnosti zopakovať PM – analýza a odhaľovanie príčin incidentov

Page 21: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

RolyRoly

Problem manažér – zodpovednosť za všetky činnosti procesu riadenia problémov

Riešiteľské skupiny („Problem Support“) Reaktívne činnosti:

identifikovanie a zaznamenanie problémov analýzou detailov incidentov skúmanie a riešenie problémov podľa ich priority monitorovanie pokroku na vyriešení známych chýb poskytovanie odporúčaní a poradenstva IM s náhradnými dočasnými riešeniami incidentov a známych chýb tvorba výkazov o problémoch

Preventívne činnosti: identifikovanie trendov a potenciálnych zdrojov problémov iniciovanie žiadostí o zmenu návrh preventívnych opatrení, rozšírenie alebo aktualizácia systémov a

podobne

Page 22: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Detekcia problému• Príčina incidentu (neznáma)• Analýza incidentu• Detekcia chyby v infraštruktúre• Notifikácia od zákazníka

• Zalogovanie problému (User, služba, čas, incidenty, priority)• Kategorizácia problému• Prioritizácia problému – ako incidenty

• koľko to bude stáť• recovery vs. Replacement• personál potrebný na vyriešenie problému• čas, ktorý to zaberie

• Vyšetrenie a diagnóza• Množstvo všeobecných techník

• Brainstorming• Chronologické analýzy• Pareto analýza

• Workarounds• dočasné riešenia

Page 23: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

• Záznam o chybe – DB• známe chyby musia byť uložené v DB

• Riešenie problému• Uzatvorenie problému• Review

• čo sa urobilo správne• čo nesprávne• ako by mohol byť problém vyriešený lepšie • prevencia zopakovania

Page 24: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

ProblémyProblémy

Slabé prepojenie medzi PM a IM Chýbajúca väzba medzi záznamami o incidentoch a informáciami o

problémoch

Slabá informovanosť o známych chybách medzi vývojárskym a produkčným

prostredím softvér a technickú infraštruktúru prechádzajúcu do produkčného

prostredia by mala sprevádzať informácia o známych chybách – táto informácia v budúcnosti ušetrí čas strávený nad hľadaním príčin chyby, ktorá je už vlastne známa

Nedostatok nadšenia – nechuť púšťať sa do formalizácie postupov

Page 25: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Vykonávanie požiadaviekVykonávanie požiadaviek(Request Fulfilment)(Request Fulfilment)

Page 26: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Základné konceptyZákladné koncepty

Servisná požiadavka (Service Request) – požiadavka používateľa na informáciu, radu, štandardnú zmenu, alebo prístup k IT službe

Účelom tohto procesu je Umožniť používateľom vyžiadať si použitie služby Príjmať štandardné služby Poskytovať informácie pre užívateľov o službách a postupoch na ich získanie

Požiadavky sú archivované a sledované

Proces efektívne redukuje byrokraciu v organizácii, čo sa týka poskytovania služieb

Request Models – definícia často sa vyskytujúcich požiadaviek a spôsob ich jednotného konzistentného spracovávania

Page 27: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

ProcesProces

Užívateľ generuje požiadavku – v management tooloch, častokrát interface umožňujúci voliť typ požiadavku z menu poskytovaných typov požiadavok

Vstupom je rovnako zoznam splnených očakávaní

Pred samotným vykonaním procesu vykonania požiadavok – nutné ich schváliť

Finančné schvaľovanie Typ schvaľovania potrebný pri každom type schvaľovaní Požiadavky majú finančný dopad na organizáciu

Iné typy schvaľovania Musia byť zadefinované v procese

Vykonanie Závisí na povahe požiadavky – jednoduché je možné vyriešit priamo na Service

Desku (1st line support), iné vyžadujú aktivitu/personál

Page 28: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Správa PrístupovSpráva Prístupov(Access Management)(Access Management)

Page 29: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Základné pojmyZákladné pojmy

Účel – poskytnúť práva užívateľom, aby boli schopní pristupovať k službe, alebo skupine služieb , ale zároveň aby prístup nebol umožnený neautorizovaným používateľom

Trust/security

Celý proces definuje Identita indivíduí Práva prístupu Overovanie identity a práv prístupu

Cieľ – zefektívniť využívanie služieb zabezpečením prístupu a autorizácie, minimalizovať s tým spojené chyby a schopnosť jednoducho odhaliť nekorektné použitie služby

Page 30: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

ProcesProces

Vyžiadanie prístupu Generovaný používateľom Požiadavok na zmenu Požiadavok na službu

Verifikácia Či je používateľ ten, za ktorého sa vydáva (username/password) Či vlastní legitímne oprávnenie na používanie služby

Niekoľko rôznych typov verifikácie podľa typu požiadavky Autorizácia určitého stupňa Existencia politík (policies), ktoré oprávňujú užívateľa k ...

Poskytovanie práv Nerozhoduje o udeľovaní práv, vykonáva policies

Monitoring stavu identity Zmena stavu služieb, povýšenia/degradácie, odchod do dôchodku, disciplinárne

akcie ... Logovanie a sledovanie prístupov Odstránenie/obmedzenie prístupov

Page 31: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Ostatné činnostiOstatné činnosti

Činnosti, ktoré nie sú súčasťou procesu: Monitorovanie a kontrola

Detekcia stavov služieb a konfiguračných položiek Správa infraštruktúry

Pamäte, databáz, middleware, dátové centrá ... Aspekty služieb z iných fáz životného cyklu služby, ktoré sa týkajú prevádzky

Manažment zmien Manažment konfigurácií Manažment vydaní Manažment dostupnosti Manažment kapacity...

Page 32: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Kľúčové funkcieKľúčové funkcie

Service Desk

Poskytuje primárny centrálny bod kontaktu pre všetkých používateľov IT Zaznamenáva a spravuje všetky incidenty, servisné požiadavky, požiadavky na

prístupy Je rozhraním pre všetky ostatné procesy a aktivity Prevádzky služieb

Špecifické zodpovednosti Záznam všetkých incidentov a požiadaviek, kategorizácia a prioritizácia Vyšetrenie a diagnóza na prvej línii supportu Správa životného cyklu incidentov a požiadaviek, zodpovedajúca eskalácia na

ďalšie stupne, uzatváranie Priebežné informovanie o stave služieb, incidentov a požiadaviek

Page 33: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Typy Service Desk-uTypy Service Desk-u

Lokálny SD Fyzicky v blízkosti používateľov

Centralizovaný SD Výhoda – menší team zvládne viac volaní

Virtuálny SD Team SD rozmiestnený fyzicky na viacerých stanovištiach, pre používateľa sa javí

ako jednotný celok

Nepretržitá prevádzka (Follow the sun) SD v rôznych časových zónach, nepretržitý čas behu, presmerovávanie na

stanovisko, ktoré je aktívne

Page 34: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Ostatné funkcieOstatné funkcie

Technická správa (Technical Management) Zodpovednosť za správu infraštruktúry IT

Správa aplikácií (Applications Management) Zameranie podobné ako technická správa, ale nie HW, ale SW

Správa prevádzky IT (IT Operations Management)

Page 35: Martin Sarnovský Katedra kybernetiky a umelej inteligencie  Fakulta elektrotechniky a informatiky

Otázky?Otázky?