Provoz služeb. Marek Rychlý. Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů

Transkript

1 Marek Rychlý Vysoké učení technické v Brně Fakulta informačních technologií Ústav informačních systémů Přednáška pro INI 19. listopadu 2014 Marek Rychlý Přednáška pro INI, 19. listopadu / 26

2 Obsah 1 Úvod Opakování Cíle přednášky 2 Service Desk, Technická správa, Správa aplikací, Operační správa IT 3 Marek Rychlý Přednáška pro INI, 19. listopadu / 26

3 Opakování Cíle přednášky (Service Operation) Popisuje dodávku služeb zákazníkovi a jejich řízení během spotřeby. Obsahuje doporučení pro denní provoz a údržbu služeb s cílem zachovat stabilitu dodávky v souladu s požadavky. Procesy: Správa událostí (Event Management) Správa incidentů (Incident Management) Provádění požadavků (Request Fulfilment) Správa přístupů (Access Management) Správa problémů (Problem Management) Funkce: Service Desk Technická správa (Technical Management) Správa aplikací (Application Management) Operační správa IT (IT Operations Management) (Operační řízení, Správa vybavení; IT Operations Control, Facilities Management) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

4 Proč? Úvod Opakování Cíle přednášky během poskytování služby zákazníkovi, je potřeba službu řídit (sledovat výkonost, koordinovat provoz služby s ostatními službami, řešit chybová hlášení, dodatečné požadaky uživatelů, atp.) během provozu služby se snažíme udržet její stabilitu (při umožnění případných změn návrhu, rozsahu nebo úrovně služeb) řízení služeb zahrnuje řízení provádění služby samotné (jako celku i jakékoliv její části vakonávané poskytovatelem, uživatelem i externím dodavatelem) provoz souvisejícího SW, HW, IT infrastruktury a procesů (tj. údržba a provoz podpůrných technologií a procesů) operační řízení zdrojů (řízení lidé, správa inventáře, atp.) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

5 Cíle přednášky Úvod Opakování Cíle přednášky Vysvětlit roli funkcí v ITILu a jejich zodpovědnosti v jednotlivých mgmtech. Popsat průběhy správy incidentů a problémů a správu požadavků. Objasnit význam správy událostí a správy přístupů. Marek Rychlý Přednáška pro INI, 19. listopadu / 26

6 Konfliktní aspekty provozu služeb pohled ze strany business služeb ze strany IT komponent (průběžně analyzovat business/trh i kapacitní/výkonnostní indik. IT komponent) 1 orien. na zákazníky vede k podcenění/nedostatečným IT zdrojům (v SLA se zavážeme k něčemu, co naše IT nedokáže splnit) 2 orien. na IT zdroje/technologie vede k službám neodpovídajícím trhu (investice/inovace v IT komponentách způsobí předražené/rizikové služby) stabilita poskytovaných služeb flexibilita při provádění změn (investovat do škálovatelných a flexibilních ITSM procesů a IT komponent, SLM) 1 orien. na stabilitu vede k ignorování měnícího se businessu/trhu (neschopnost zpracovat emergency RFCs, nižší konkurenceschopnost) 2 orien. na flexibilitu vede k častým/drahým a rizikovým změnám (přílišné náklady na Change a Release Mgmts., nestabilní rozhraní služeb) požadavek vyšší kvality služeb požadavek snižování nákladů (kvalitu služeb zvyšovat dokud náklady rostou mírně či stagnují, jinak přepočítat) reaktivní přístup k řízení služeb proaktivní řízení služeb (reaktivní nepodporuje strategii; proaktivní lepší, ale drahý a zbytečné změny) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

7 Funkce: Service Desk Úvod funkce/tým poskytovatele zajišt ující kontakt se zákazníkem (telefonicky, em, via instant messaging, web, a to osobně i automatizovaně) vstupní bod událostí, začíná procesy specializovaných mgmts. (přijímá hlášení incidentů, požadavky na služby, vytváří zprávy o problémech, atd.) samostatně dokáže vyřešit některé (méně významné) incidenty (např. jednoduchá nebo dobře známá řešení, jako tzv. first-time fix ) domlouvá součinnost poskytovatele a zákazníka či uživatele ( change windows, release packages, předává smluvní reporty, atp.) local vs. centralised vs. virtual service desks (pracovníci nemusí být v lokalitě zákazníka, nemusí být seskupeni; více úrovní) ale vždy tzv. Single Point of Contact (SPOC) (výrazně usnadňuje komunikaci a urychluje řešení případných problémů) výrazně ovlivňuje kvalitu všech služeb. dobře provedený kompenzuje případné nedostatky ostatních služeb, špatně provedený lehce pokazí dojem zákazníka na jinak perfektní služby. Marek Rychlý Přednáška pro INI, 19. listopadu / 26

8 Service Desk v kontextu ITILv3 (diagram převzat z IT frameworks ) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

9 Funkce: Technická správa, Správa aplikací, Operační správa IT Technical, Application, and IT Operations Mgmts. Technical správa IT infrastruktury/komponent, garantuje zdroje služeb Application správa SW komponent, garantuje nástroje podpory služeb IT Operations správa denního provozu služeb, SW a IT infrastruktury Facilities správa fyzického IT prostředí, server/data-houses, atp. výše uvedené funkce mají za úkol udržovat spravovaná aktiva stabilní (zdroje v dostatečné dostupnosti, kapacitě a kvalitě, reagovat na výkyvy) asistují při všech procesech, které nějak manipulují s danými aktivy (technické/operativní znalosti při návrhu, testování, řízení a zlepšování služeb) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

10 Technická správa v kontextu ITILv3 (diagram převzat z IT frameworks ) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

11 Správa aplikací v kontextu ITILv3 (diagram převzat z IT frameworks ) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

12 Operační správa IT v kontextu ITILv3 (diagram převzat z IT frameworks ) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

13 Proces: Správa incidentů Incident Management přijímá, kategorizuje, třídí a opravuje nahlášené incidenty (nahlášení přes Service Desk od uživatelů zákazníka) snaží se co nejrychleji obnovit běžný provoz, minimalizovat ztráty (běžný provoz podle SLA, incident je hlášení/narušení v rámci SLA) nesnaží se analyzovat příčiny, jen co nejrychleji vyřešit incident (pokud nutná analýza příčin nebo riziko opakování, předáno Problem Mgmt.) řešení v přímém kontaktu s hlásícím uživatelem, hned i průběžně (vyřeší se to hned na telefonu, nebo má uživatel možnost sledovat průběh) Service Desk sám řeší lehké/běžné incidenty, zbytek postoupí pro běžné, správě určené incidenty dostupné modely jejich řešení (chronologický postup, zodpovědnosti, časové limity, eskalační procedury) nelze-li vyřešit, eskalováno na 2. úroveň SD či přímo specialistům (tzv. funkční eskalace: běžný operátor zkušený operátor specialista) vážný incident, nejasná eskalace, či dlouhé řešení, předáno výše (tzv. hierarchická eskalace: operátor vedoucí operátorů... ) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

14 Postup zpracování incidentu 1 identifikace incidentu, ideálně včas před uživateli (event mgmt., issue tracking sys., zprávou uživatele/techniků; pro- vs. re-aktivní) 2 zaznamenání a kategorizace incidentu (čas. razítko; urgentnost/dopad; kanál/kontakt ohlašovatele; příznaky; kateg. CIs) 3 filtrace incidentů, které jsou požadavky na služby (eskalace směrem na provádění požadavků/request Fulfilment; např. reset hesla) 4 prioritizace incidentů a eskalace závažných do zrychleného řízení (priorita = urgentnost dopad; např. počet ovlivněných uživ. a služeb, ztráty, atd.) 5 úvodní diagnóza a řešení v první úrovni (tzv. first-time fix ) (nejlépe diagnóza/řešení s uživatelem na telefonu, či odkaz na pozdější kontakt) 6 případná funkční či hierarchická eskalace incidentu (nelze vyřešit, neví komu předat, či vyprší čas na libovolné úrovni nutno sledovat!) 7 vyřešení a zotavení z incidentu (požádání uživatele o aktivitu či příprava RfC pro Change/Release Mgmt.) 8 uzavření incidentu po potvrzení ohlašovatelem (časový limit dokdy potvrdit/odmítnout, jinak uzavřeno automaticky; je-li potřeba hlubší analýza příčin či hrozí-li opakování incidentu, vstup do Problem Mgmt.) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

15 Role ve správě incidentů, záznam incidentu Incident Manager hlavní role (zodpovědný za proces, řídí práci úrovní SD, řeší hierarchicky eskalované a vážné incidenty, provádí monitoring KPIs a zlepšování procesu) pracovníci 1. úrovně Service Desk (přijímají hlášení o incidentech, kategorizují, eskalují, analyzují a řeší) pracovníci 2. úrovně Service Desk (zkušenější/techničtější, podpora dané business domény či daných zákazníků,... ) pracovníci 3. úrovně Service Desk (specializované technické skupiny či service desk subdodavatelů, zajištěno UCs) Pracovníky úrovní SD možno dislokovat, sdílet vyššími úrovněmi, atp. (např. follow-the-sun ; vizte popis SD na straně 9) Pro strukturu záznamu o incidentu vizte příslušný ITIL-Checklist. Marek Rychlý Přednáška pro INI, 19. listopadu / 26

16 Proces: Správa problémů Problem Management problém je neznámá příčina jednoho nebo více incidentů (jednoho závažného incidentu, nebo opakujícího se či eskalujícího incidentu) snažíme se bránit budoucím incidentům, zjistit příčinu a navrhnout řešení (vlastní provedení řešení dle návrhu je úkolem Change & Release Mgmts.) (vy)řešené problémy zaznamenány 1 v Known Errors vč. Workarounds (slouží Service Desk pro rychlé řešení incidentů, tj. first-time fix, brání duplicitám) pro známé/akceptované problémy se zavádějí modely problémů (např. pro problémy, jejichž řešení by bylo velmi nákladné či nemožné) na rozdíl od incidentů, problémy neřeší pracovníci Service Desk (jinak informace podobné incidentům, tj. postup, zodpovědnosti, limity, eskalace) 1 dokument incidentu či problému označován často stejně, jako Problem Ticket Marek Rychlý Přednáška pro INI, 19. listopadu / 26

17 Postup zpracování problému 1 detekce problému ze zaznamenaného incidentu (service desk/incident mgmt., event mgmt., proaktivní monitor, hlášení dodavatele) 2 zaznamenání a kategorizace problému (podobně, jako u incidentů, ale vč. sběru dat pro analýzu, např. snapshots) 3 prioritizace problémů (z priorit incidentů; počet CIs a incidentů, cena a čas odstranění incidentů, atp.) 4 analýza incidentů a diagnóza problémů (Ishikawa diagramy pro závislosti příčin a následků, Pareto analýza pro identifikaci 20 % příčin způsobujících 80 % problémů, komplexní Kepner&Tregoe, atd.) 5 nalezení workaround a záznam problému jako known error (záznam podrobné diagnózy a popisu způsobu obejití incidentů/problému) 6 vyřešení problému navržením změny (příprava RfC a jeho odeslání do Change Mgmt.) 7 uzavření problému, případné přezkoumání závažných problémů (uzavře se jen problém, incidenty stále otevřené až do konce Incident Mgmt.) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

18 Role ve správě problémů, záznam problému Problem Manager hlavní role zodpovědný za proces, monitoruje KPIs a zlepšuje proces koordinuje aktivity procesu a řídí spolupráci řešících skupin (vč. řízení případných subdodavatelů pokud mají řešit problémy podle UCs) vlastnictví záznamů o problémech, řízení known error db. dohled nad uzavíráním problémů a případným přezkoumáním skupiny řešení problémů (Problem-solving Groups) (vlastní technické skupiny či technické skupiny subdodavatelů podle UCs) Pro strukturu záznamu o problému vizte příslušný ITIL-Checklist. Marek Rychlý Přednáška pro INI, 19. listopadu / 26

19 Proces: Provádění požadavků Request Fulfilment přijímá a řeší požadavky na služby (Service Requests) od SD (triviální/předem definované modely požadavků, např. reset hesla uživatele) odlehčuje správě incidentů a správě změn od triviálních požadavků (bylo by zbytečné/nákladné je řešit jako incidenty a RfCs; nízké riziko, náklady) poskytuje uživatelům komunikační kanál pro příjem těchto požadavků (např. specializovaný webový formulář, speciální typ incidentů, atp.) poskytuje uživatelům kanál pro distribuci obecných informací/odpovědí (např. dostupnost služeb a způsob jejich aktivace, informace o licencích, distribuci SW, způsobu reklamací, frequently asked questions, pull releasing změn, atp.) většinou řešitelné jako End User Self-Enablement, bez účasti operátora (požadavky autorizovaného uživatele vyřídí systém automaticky) vlastnictví požadavku má Service Desk, vzešel od uživatele zákazníka (řešení požadavku pak v rámci SD, spec. oddělení, či subdodavatelem) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

20 Proces: Správa událostí Event Management poskytuje schopnost detekce události a její klasifikace a eskalace (detekce spouští či manuálně, klasifikace filtrací, eskalace do příslušného mgmt.) jako vstupní bod začíná procesy mnoha managementů a funkcí (incident mgmt., operations mgmt., service availability & capacity mgmts., atd.) spoléhá na aktivní a pasivní monitorovací nástroje (proaktivní a reaktivní sledování eventuálního výskytu událostí) událost je cokoliv, co je potřeba někde nahlásit/zpracovat; typy info o běžných aktivitách služeb/aplikací, zákazníka i poskytovatele (např. vystavení faktury v účetním programu, ale i uzavření incidentu) signalizace výjimečných stavů služeb/aplikací, zák. i poskytovatele (např. neúspěšný pokus o přihlášení už., ale i žlutý stav dle metrik služeb) upozornění na neobvyklé a vážné stavy služeb/aplikací, zák. i posk. (např. špička už. transakcí, dlouhodobý nedostatek kapacity služeb, atp.) většinou zabudován do jiných procesů/mgmts., ale nutno koordinovat (žádná role Event Manager, o správný průběh/nástroje se starají všechny fce.) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

21 Proces: Správa přístupu Access Management spravuje identity uživatelů/systémů, jejich autentizaci a autorizaci (řídí bezpečnost služeb dle návrhu Information Security Mgmt. v Service Design) přístup (Access) identita (Identity) oprávnění (Rights) opravňuje uživatele k užívání služeb, jejich dat a jiných aktiv (řídí dostupnost služeb vč. účtování dle návrhu Availability Mgmt. v Service Design) udržuje důvěrnost, integritu a dostupnost aktiv, nepopiratelnost, atp. (řídí bezpečné prostředí pro poskytování a spotřebu služeb, dodržuje politiky) SD přijímá žádosti změny přístupu, schvaluje a eskaluje na tech. skupiny (např. ověří oprávnění uživatele zákazníkem pro aktivaci přístupu k danému aktivu) proces obecně udržují a po SD přebírají ostatní fce. (tj. technická správa a správa aplikací, případě operační správa IT pro přístupy) Marek Rychlý Přednáška pro INI, 19. listopadu / 26

22 Úvod fce přestavují technické a operační týmy a týmy kontaktu s uživateli (SD) (podporují procesy provozu služeb, ale ovlivňují také návrh/přechod služeb) SD přijímá/řeší/eskaluje incidenty, deleguje požadavky, zakládá problémy řízení služeb a provoz aplikací vyžaduje generování a řízení toku událostí správu identit, přístupů a oprávnění Příště? zdokonalování služeb (proč zdokonalování služeb, jak identifikovat příležitosti,... ) upřesnění zadání 5. části projektu prezentace řešení 4. části projektu Marek Rychlý Přednáška pro INI, 19. listopadu / 26

23 Poděkování Tento předmět byl podpořen projektem MŠMT CZ.1.07/2.2.00/ Vzdělávání v IT pro praxi. Marek Rychlý Přednáška pro INI, 19. listopadu / 26