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

Provoz služeb Marek Rychlý Vysoké uˇcení technické v Brneˇ Fakulta informaˇcních technologií Ústav informaˇcních systému˚

Pˇrednáška pro INI 19. listopadu 2014

Marek Rychlý

Provoz služeb — Pˇrednáška pro INI, 19. listopadu 2014

1 / 26

Obsah

1

Úvod Opakování Cíle pˇrednášky

2

Provoz služeb Service Desk, Technická správa, Správa aplikací, Operaˇcní správa IT ˇ požadavku˚ Správy incidentu˚ a problému, ˚ Provádení Správa událostí a správa pˇrístupu˚

3

ˇ Shrnutí a záver

Marek Rychlý


2 / 26

Úvod Provoz služeb ˇ Shrnutí a záver

Opakování Cíle pˇrednášky

Provoz služeb (Service Operation) Popisuje dodávku služeb zákazníkovi a jejich ˇrízení ˇ behem spotˇreby. Obsahuje doporuˇcení 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 incidentu˚ (Incident Management) ˇ požadavku˚ (Request Fulfilment) Provádení Správa pˇrístupu˚ (Access Management) Správa problému˚ (Problem Management)

Funkce: Service Desk Technická správa (Technical Management) Správa aplikací (Application Management) Operaˇcní správa IT (IT Operations Management) (Operaˇcní ˇrízení, Správa vybavení; IT Operations Control, Facilities Management) Marek Rychlý


4 / 26



Proˇc Provoz služeb? ˇ behem poskytování služby zákazníkovi, je potˇreba službu ˇrídit (sledovat výkonost, koordinovat provoz služby s ostatními službami, ˇrešit chybová hlášení, dodateˇcné požadaky uživatelu, ˚ atp.)

ˇ behem provozu služby se snažíme udržet její stabilitu ˇ pˇrípadných zmen ˇ návrhu, rozsahu nebo úrovneˇ služeb) (pˇri umožnení

ˇrízení služeb zahrnuje ˇrízení provádení ˇ služby samotné (jako celku i jakékoliv její cˇ ásti vakonávané poskytovatelem, uživatelem i externím dodavatelem)

provoz souvisejícího SW, HW, IT infrastruktury a procesu˚ (tj. údržba a provoz podpurných ˚ technologií a procesu) ˚

operaˇcní ˇrízení zdroju˚ (ˇrízení lidé, správa inventáˇre, atp.)

Marek Rychlý


5 / 26



Cíle pˇrednášky

ˇ roli funkcí v ITILu a jejich zodpovednosti ˇ Vysvetlit v jednotlivých mgmtech. ˇ správy incidentu˚ a problému˚ a správu požadavku. Popsat prub ˚ ehy ˚ Objasnit význam správy událostí a správy pˇrístupu. ˚

Marek Rychlý


6 / 26


Service Desk, Technická správa, Správa aplikací, Operaˇcní správa IT ˇ požadavku˚ Správy incidentu˚ a problému, ˚ Provádení Správa událostí a správa pˇrístupu˚

Konfliktní aspekty provozu služeb pohled ze strany business služeb × ze strany IT komponent ˇ eˇ analyzovat business/trh i kapacitní/výkonnostní indik. IT komponent) (prub ˚ ežn 1

ˇ orien. na zákazníky vede k podcenení/nedostateˇ cným IT zdrojum ˚ ˇ cemu, co naše IT nedokáže splnit) (v SLA se zavážeme k neˇ

2

orien. na IT zdroje/technologie vede k službám neodpovídajícím trhu (investice/inovace v IT komponentách zpusobí ˚ pˇredražené/rizikové služby)

ˇ zmen ˇ stabilita poskytovaných služeb × flexibilita pˇri provádení (investovat do škálovatelných a flexibilních ITSM procesu˚ a IT komponent, SLM) 1

ˇ orien. na stabilitu vede k ignorování menícího se businessu/trhu (neschopnost zpracovat emergency RFCs, nižší konkurenceschopnost)

2

ˇ orien. na flexibilitu vede k cˇ astým/drahým a rizikovým zmenám (pˇrí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ákladu˚ (kvalitu služeb zvyšovat dokud náklady rostou mírneˇ cˇ i stagnují, jinak pˇrepoˇcítat)

reaktivní pˇrístup k ˇrízení služeb × proaktivní ˇrízení služeb ˇ (reaktivní nepodporuje strategii; proaktivní lepší, ale drahý a zbyteˇcné zmeny) Marek Rychlý


8 / 26



Funkce: Service Desk funkce/tým poskytovatele zajišt’ující kontakt se zákazníkem ˇ (telefonicky, emailem, via instant messaging, web, a to osobneˇ i automatizovane)

vstupní bod událostí, zaˇcíná procesy specializovaných mgmts. (pˇrijímá hlášení incidentu, ˚ požadavky na služby, vytváˇrí zprávy o problémech, atd.)

ˇ samostatneˇ dokáže vyˇrešit nekteré (méneˇ významné) incidenty (napˇr. jednoduchá nebo dobˇre známá ˇrešení, jako tzv. „first-time fix“)

domlouvá souˇcinnost poskytovatele a zákazníka cˇ i uživatele ( „change windows“, „release packages“, pˇredává smluvní reporty, atp.)

„local“ vs. „centralised“ vs. „virtual“ service desks (pracovníci nemusí být v lokaliteˇ zákazníka, nemusí být seskupeni; více úrovní)

ale vždy tzv. „Single Point of Contact“ (SPOC) ˇ (výrazneˇ usnadnuje komunikaci a urychluje ˇrešení pˇrípadných problému) ˚

ˇ výrazneˇ ovlivnuje kvalitu všech služeb. dobˇre provedený kompenzuje pˇrípadné nedostatky ostatních služeb, špatneˇ provedený lehce pokazí dojem zákazníka na jinak perfektní služby. Marek Rychlý


9 / 26



Service Desk v kontextu ITILv3

(diagram pˇrevzat z „IT frameworks“) Marek Rychlý


10 / 26



Funkce: Technická správa, Správa aplikací, Operaˇcní 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ˇredí, server/data-houses, atp.

výše uvedené funkce mají za úkol udržovat spravovaná aktiva stabilní ˇ reagovat na výkyvy) (zdroje v dostateˇcné dostupnosti, kapaciteˇ a kvalite,

ˇ asistují pˇri všech procesech, které nejak manipulují s danými aktivy (technické/operativní znalosti pˇri návrhu, testování, ˇrízení a zlepšování služeb)

Marek Rychlý


11 / 26



Technická správa v kontextu ITILv3



12 / 26



Správa aplikací v kontextu ITILv3



13 / 26



Operaˇcní správa IT v kontextu ITILv3



14 / 26



Proces: Správa incidentu˚ Incident Management

pˇrijímá, kategorizuje, tˇrídí a opravuje nahlášené incidenty (nahlášení pˇres Service Desk od uživatelu˚ zákazníka)

ˇ snaží se co nejrychleji obnovit bežný provoz, minimalizovat ztráty ˇ (bežný provoz podle SLA, incident je hlášení/narušení v rámci SLA)

nesnaží se analyzovat pˇríˇciny, jen co nejrychleji vyˇrešit incident (pokud nutná analýza pˇríˇcin nebo riziko opakování, pˇredáno Problem Mgmt.)

ˇrešení v pˇrímém kontaktu s hlásícím uživatelem, hned i prub ˇ eˇ ˚ ežn ˇ (vyˇreší se to hned „na telefonu“, nebo má uživatel možnost sledovat prub ˚ eh)

ˇ Service Desk sám ˇreší lehké/bežné incidenty, zbytek postoupí ˇ pro bežné, správeˇ urˇcené incidenty dostupné modely jejich ˇrešení ˇ (chronologický postup, zodpovednosti, cˇ asové limity, eskalaˇcní procedury)

nelze-li vyˇrešit, eskalováno na 2. úrovenˇ SD cˇ i pˇrímo specialistum ˚ ˇ (tzv. „funkˇcní“ eskalace: bežný operátor → zkušený operátor → specialista)

vážný incident, nejasná eskalace, cˇ i dlouhé ˇrešení, pˇredáno výše (tzv. „hierarchická“ eskalace: operátor → vedoucí operátoru˚ → . . . ) Marek Rychlý


15 / 26



Postup zpracování incidentu 1

identifikace incidentu, ideálneˇ vˇcas pˇred uživateli (event mgmt., issue tracking sys., zprávou uživatele/techniku; ˚ pro- vs. re-aktivní)

2

zaznamenání a kategorizace incidentu (ˇcas. razítko; urgentnost/dopad; kanál/kontakt ohlašovatele; pˇríznaky; kateg. CIs)

3

filtrace incidentu, ˚ které jsou požadavky na služby ˇ ˇ požadavku/Request (eskalace smerem na provádení ˚ Fulfilment; napˇr. reset hesla)

4

prioritizace incidentu˚ a eskalace závažných do zrychleného ˇrízení ˇ (priorita = urgentnost ∗ dopad; napˇr. poˇcet ovlivnených uživ. a služeb, ztráty, atd.)

5

úvodní diagnóza a ˇrešení v první úrovni (tzv. „first-time fix“) ˇ kontakt) (nejlépe diagnóza/ˇrešení s uživatelem „na telefonu“, cˇ i odkaz na pozdejší

6

pˇrípadná funkˇcní cˇ i hierarchická eskalace incidentu (nelze vyˇrešit, neví komu pˇredat, cˇ i vyprší cˇ as na libovolné úrovni – nutno sledovat!)

7

vyˇrešení a zotavení z incidentu (požádání uživatele o aktivitu cˇ i pˇríprava RfC pro Change/Release Mgmt.)

8

uzavˇrení incidentu po potvrzení ohlašovatelem (ˇcasový limit dokdy potvrdit/odmítnout, jinak uzavˇreno automaticky; je-li potˇreba hlubší analýza pˇríˇcin cˇ i hrozí-li opakování incidentu, vstup do Problem Mgmt.)

Marek Rychlý


16 / 26



Role ve správeˇ incidentu, ˚ záznam incidentu Incident Manager – hlavní role ˇ (zodpovedný za proces, ˇrídí práci úrovní SD, ˇreší hierarchicky eskalované a vážné incidenty, provádí monitoring KPIs a zlepšování procesu)

pracovníci 1. úrovneˇ Service Desk (pˇrijímají hlášení o incidentech, kategorizují, eskalují, analyzují a ˇreší)

pracovníci 2. úrovneˇ Service Desk ˇ ˇ (zkušenejší/techniˇ ctejší, podpora dané business domény cˇ i daných zákazníku, ˚ ...)

pracovníci 3. úrovneˇ Service Desk ˇ (specializované technické skupiny cˇ i service desk subdodavatelu, ˚ zajišteno UCs)

ˇ Pracovníky úrovní SD možno dislokovat, sdílet vyššími úrovnemi, atp. (napˇr. „follow-the-sun“; vizte popis SD na straneˇ 9)

Pro strukturu záznamu o incidentu vizte pˇríslušný ITIL-Checklist. Marek Rychlý


17 / 26



Proces: Správa problému˚ Problem Management

problém je neznámá pˇríˇcina jednoho nebo více incidentu˚ (jednoho závažného incidentu, nebo opakujícího se cˇ i eskalujícího incidentu)

snažíme se bránit budoucím incidentum, ˚ zjistit pˇríˇcinu a navrhnout ˇrešení (vlastní provedení ˇrešení dle návrhu je úkolem Change & Release Mgmts.)

(vy)ˇrešené problémy zaznamenány1 v „Known Errors“ vˇc. „Workarounds“ (slouží Service Desk pro rychlé ˇrešení incidentu, ˚ tj. „first-time fix“, brání duplicitám)

ˇ modely problému˚ pro známé/akceptované problémy se zavádejí (napˇr. pro problémy, jejichž ˇrešení by bylo velmi nákladné cˇ i nemožné)

na rozdíl od incidentu, ˚ problémy neˇreší pracovníci Service Desk ˇ (jinak informace podobné incidentum, ˚ tj. postup, zodpovednosti, limity, eskalace)

1 dokument Marek Rychlý

ˇ jako „Problem Ticket“ incidentu cˇ i problému oznaˇcován cˇ asto stejne, Provoz služeb — Pˇrednáška pro INI, 19. listopadu 2014

18 / 26



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 ˇ jako u incidentu, ˇ dat pro analýzu, napˇr. snapshots) (podobne, ˚ ale vˇc. sberu

3

prioritizace problému˚ ˇ incidentu, (z priorit incidentu; ˚ poˇcet CIs a incidentu, ˚ cena a cˇ as odstranení ˚ atp.)

4

analýza incidentu˚ a diagnóza problému˚ (Ishikawa diagramy pro závislosti pˇríˇcin a následku, ˚ Pareto analýza pro identifikaci 20 % pˇríˇcin zpusobujících ˚ 80 % problému, ˚ komplexní Kepner&Tregoe, atd.)

5

nalezení „workaround“ a záznam problému jako „known error“ (záznam podrobné diagnózy a popisu zpusobu ˚ obejití incidentu/problému) ˚

6

ˇ vyˇrešení problému navržením zmeny (pˇríprava RfC a jeho odeslání do Change Mgmt.)

7

uzavˇrení problému, pˇrípadné pˇrezkoumání závažných problému˚ (uzavˇre se jen problém, incidenty stále otevˇrené až do konce Incident Mgmt.)

Marek Rychlý


19 / 26



Role ve správeˇ problému, ˚ záznam problému

Problem Manager – hlavní role ˇ zodpovedný za proces, monitoruje KPIs a zlepšuje proces koordinuje aktivity procesu a ˇrídí spolupráci ˇrešících skupin (vˇc. ˇrízení pˇrípadných subdodavatelu˚ pokud mají ˇrešit problémy podle UCs)

vlastnictví záznamu˚ o problémech, ˇrízení „known error“ db. dohled nad uzavíráním problému˚ a pˇrípadným pˇrezkoumáním skupiny ˇrešení problému˚ (Problem-solving Groups) (vlastní technické skupiny cˇ i technické skupiny subdodavatelu˚ podle UCs)

Pro strukturu záznamu o problému vizte pˇríslušný ITIL-Checklist.

Marek Rychlý


20 / 26



ˇ požadavku˚ Proces: Provádení Request Fulfilment

pˇrijímá a ˇreší požadavky na služby (Service Requests) od SD (triviální/pˇredem definované modely požadavku, ˚ napˇr. reset hesla uživatele)

ˇ od triviálních požadavku˚ odlehˇcuje správeˇ incidentu˚ a správeˇ zmen (bylo by zbyteˇcné/nákladné je ˇrešit jako incidenty a RfCs; nízké riziko, náklady)

ˇ poskytuje uživatelum ˚ komunikaˇcní kanál pro pˇríjem techto požadavku˚ (napˇr. specializovaný webový formuláˇr, speciální typ incidentu, ˚ atp.)

ˇ poskytuje uživatelum ˚ kanál pro distribuci obecných informací/odpovedí (napˇr. dostupnost služeb a zpusob ˚ jejich aktivace, informace o licencích, distribuci ˇ atp.) SW, zpusobu ˚ reklamací, frequently asked questions, „pull“ releasing zmen,

ˇ ˇrešitelné jako „End User Self-Enablement“, bez úˇcasti operátora vetšinou (požadavky autorizovaného uživatele vyˇrídí systém automaticky)

vlastnictví požadavku má Service Desk, vzešel od uživatele zákazníka ˇ (ˇrešení požadavku pak v rámci SD, spec. oddelení, cˇ i subdodavatelem) Marek Rychlý


21 / 26



Proces: Správa událostí Event Management

poskytuje schopnost detekce události a její klasifikace a eskalace ˇ klasifikace filtrací, eskalace do pˇríslušného mgmt.) (detekce spouští cˇ i manuálne,

jako vstupní bod zaˇcíná procesy mnoha managementu˚ 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ˇreba nekde nahlásit/zpracovat; typy ˇ info o bežných aktivitách služeb/aplikací, zákazníka i poskytovatele (napˇr. vystavení faktury v úˇcetním programu, ale i uzavˇrení incidentu)

signalizace výjimeˇcných stavu˚ služeb/aplikací, zák. i poskytovatele ˇ (napˇr. neúspešný pokus o pˇrihlášení už., ale i „žlutý“ stav dle metrik služeb)

ˇ na neobvyklé a vážné stavy služeb/aplikací, zák. i posk. upozornení (napˇr. špiˇcka už. transakcí, dlouhodobý nedostatek kapacity služeb, atp.)

ˇ vetšinou zabudován do jiných procesu/mgmts., ˚ ale nutno koordinovat ˇ (žádná role „Event Manager“, o správný prub ˚ eh/nástroje se starají všechny fce.) Marek Rychlý


22 / 26



Proces: Správa pˇrístupu Access Management

spravuje identity uživatelu/systém ˚ u, ˚ jejich autentizaci a autorizaci (ˇrídí bezpeˇcnost služeb dle návrhu Information Security Mgmt. v Service Design)

pˇrístup (Access) identita (Identity) ˇ (Rights) oprávnení ˇ opravnuje uživatele k užívání služeb, jejich dat a jiných aktiv (ˇrídí dostupnost služeb vˇc. úˇctování dle návrhu Availability Mgmt. v Service Design)

ˇ udržuje duv ˚ ernost, integritu a dostupnost aktiv, nepopiratelnost, atp. (ˇrídí bezpeˇcné prostˇredí pro poskytování a spotˇrebu služeb, dodržuje politiky)

ˇ pˇrístupu, schvaluje a eskaluje na tech. skupiny SD pˇrijímá žádosti zmeny ˇ rí oprávnení ˇ uživatele zákazníkem pro aktivaci pˇrístupu k danému aktivu) (napˇr. oveˇ

proces obecneˇ udržují a po SD pˇrebírají ostatní fce. (tj. technická správa a správa aplikací, pˇrípadeˇ operaˇcní správa IT pro pˇrístupy)

Marek Rychlý


23 / 26


ˇ Shrnutí a záver fce pˇrestavují technické a operaˇcní týmy a týmy kontaktu s uživateli (SD) ˇ také návrh/pˇrechod služeb) (podporují procesy provozu služeb, ale ovlivnují

SD pˇrijímá/ˇreší/eskaluje incidenty, deleguje požadavky, zakládá problémy ˇrízení služeb a provoz aplikací vyžaduje generování a ˇrízení toku událostí ˇ správu identit, pˇrístupu˚ a oprávnení

ˇ Pˇríšte? zdokonalování služeb (proˇc zdokonalování služeb, jak identifikovat pˇríležitosti, . . . )

ˇ zadání 5. cˇ ásti projektu upˇresnení prezentace ˇrešení 4. cˇ ásti projektu

Marek Rychlý


25 / 26

ˇ Podekování

ˇ byl podpoˇren projektem MŠMT Tento pˇredmet ˇ CZ.1.07/2.2.00/15.0163 „Vzdelávání v IT pro praxi“.

Marek Rychlý


26 / 26

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

Recommend Documents