Služby
portfolio služeb, úrovně služeb a katalog požadavků
Konfigurační databáze
Obecný model infrastruktury: IBM Power (LPAR, VIOS, HMC), virtualizace VMware, Hyper-V a Azure Stack Hub, virtuální servery ve veřejných cloudech (Azure, AWS, GCP), kontejnerové clustery kdekoli (OpenShift a HyperShift, AKS, EKS, GKE), aplikace, aplikační platformy a databáze, disková pole, SAN a síť (routery, L3/L2 switche, agregace portů LACP a vPC, VLAN, subnety, směrování). U LPAR uvidíte cestu k datům přes NPIV, SAN a zónu až k diskovému poli. Náklady on-prem infrastruktury se počítají přímo z CMDB. Mapa závislostí zobrazí položky od business služby dolů jako graf nebo strom, s filtrem podle zákazníka a prostředí. Impact analýza nasimuluje výpadek vybrané položky a ukáže zasažené služby, aplikace a zákazníky; u redundantních prvků (dvojice switchů, uzly clusteru, SAN fabric A/B) rozliší výpadek a degradaci. U business služeb, aplikací, platforem a databází karta Vysoká dostupnost nasimuluje výpadek každé podpůrné položky, vypíše jediné body selhání a ukáže redundantní skupiny (cluster aplikace, Db2 HADR, Oracle Data Guard, PowerHA, dvojice VIOS, HyperSwap svazky). Každá položka má ikonu podle druhu (fyzický server, VM, LPAR, aplikace, databáze, diskové pole, pásková knihovna, SAN switch, router, firewall, L2/L3 switch…), barva ikony odpovídá kategorii; přehled ikon je níže v nápovědě. U hypervisorů, VIOS a LPAR je karta Cesta k úložišti přes obě SAN fabric. Ve vztazích jsou vyznačené redundantní skupiny a vztahy, jejichž výpadek znamená jen degradaci (např. správcová síť pole, pásková knihovna). Vztah „je zálohován“ ukazuje, která zálohovací platforma položku chrání. Na telefonu se mapa otevírá jako strom; graf jde posouvat prstem a přibližovat dvěma prsty. Každá položka má vlastnický tým; u hardwaru je vidět datum uvedení do provozu, konec záruky a konec podpory výrobce. Umístění VM a partition (hostitel, cluster, server Power) mění jen discovery z management nástroje dané virtualizace (vCenter, SCVMM, Azure Stack Hub, cloudová API, HMC). Z detailu položky lze rovnou nahlásit incident nebo naplánovat změnu.
SLA
Service Level Management (Služby → SLA). Plnění SLA: podíl incidentů s reakcí a vyřešením v termínu po měsících a podle SLA dohody, priority, služby, zákazníka nebo týmu, porovnání s cílem, seznam porušení a plnění lhůt požadavků. SLA dohody (výchozí Gold, Silver, Bronze, Standard): cíle reakce a vyřešení pro P1–P4, pracovní doba (u priority lze přepsat, např. P1 nepřetržitě), požadované plnění v %, cílová dostupnost a kdy upozornit (po uplynutí % lhůty). Dohodu přiřadíte business službě nebo zákazníkovi; platí SLA služby → SLA zákazníka → výchozí SLA. Pracovní doba: týdenní okna po dnech, české státní svátky (včetně Velkého pátku a Velikonočního pondělí) a další volné dny, náhled na 14 dní. Čas SLA běží jen v pracovní době a nečerpá se při pozastavení incidentu. Lhůty požadavků: lhůta vyřízení každé položky katalogu v hodinách a pracovní doba. Změny platí pro nové incidenty a požadavky; otevřené incidenty lze přepočítat tlačítkem. Upravuje incident manažer a správce platformy (sla.manage).
Request management
Katalog služeb obsahuje standardní požadavky (nový server, rozšíření kapacity, pravidlo firewallu, přístup, obnova ze zálohy, namespace v OpenShiftu). Každá položka má formulář, způsob schválení (bez schválení, vlastník služby zákazníka, vedoucí řešitelského týmu, change manažer), lhůtu, řešitelský tým a kroky plnění. Požadavek bez schválení jde rovnou k plnění. Řešitel převezme požadavek, odškrtá kroky a označí ho jako splněný; žadatel ho uzavře. Položka, jejíž splnění mění infrastrukturu, navazuje na model změny – z požadavku se založí změna a požadavek lze splnit až po jejím dokončení. Katalog spravuje konfigurační manažer v záložce Správa katalogu. U položky navázané na standardní model změny založí aplikace změnu sama a naplánuje ji na první volný termín bez dalšího schvalování. Karta Změny v detailu ukazuje navázané změny a žadatel dostane zprávu o jejich naplánování, zahájení a dokončení. Požadavek, který je ve skutečnosti porucha, převede řešitel tlačítkem Převést na incident.
Monitoring
události z dohledu, jejich korelace a pravidla
Event management
Příjem událostí z monitoringu (Zabbix, Prometheus/Alertmanager, Checkmk, Grafana, Dynatrace, generické API) a jejich zkrácení na to, na co má operátor reagovat. Každá událost se spáruje s konfigurační položkou (název hostu, FQDN, IP, sériové číslo nebo tag ci_id) a z CMDB se doplní zasažená business služba, zákazník a vlastnický tým. Pravidla filtrace zahodí šum, pravidla potlačení a probíhající změny na položce alert potlačí (nebudí operátora). Opakované události téhož problému (stejný fingerprint) jen zvyšují počítadlo alertu; zpráva OK alert vyřeší, bez ní se vyřeší po tichu. Kolísající alert (víc změn stavu za okno) je označen jako flapping. Alerty se slučují do situací: topologicky podle simulace výpadku v CMDB – příčinou může být jen položka, jejíž výpadek alert skutečně vysvětluje (jeden z dvojice switchů tedy příčinou výpadku serveru není), a z více kandidátů vyhrává ten, kdo vysvětlí nejvíc alertů (★). Alerty vysvětlené příčinou jsou následky: v situaci viditelné, bez notifikací, mimo ukazatele šumu a vyřeší se s příčinou. Když alertuje několik položek se společnou oporou, která sama mlčí (např. VM na jednom hostiteli), vznikne jedna situace s odvozenou příčinou. Dál se slučuje podle služby a času a podle související změny. Konzole řadí situace podle kritičnosti zasažené služby a severity a aktualizuje se živě; operátor situace potvrzuje, přiřazuje týmu, umlčuje na čas s důvodem, slučuje a rozděluje. Incident ze situace se předvyplní (položka, služba, dopad podle skutečného dopadu na službu – výpadek, degradace, nebo jen ztráta redundance – a její kritičnosti, naléhavost ze severity, tým, časová osa alertů, vazba na změnu) a alerty zůstanou s incidentem provázané – nové alerty situace se připojují, vyřešení všech alertů navrhne vyřešení incidentu a návrat problému incident znovu otevře. Pravidlo automatického incidentu založí incident bez operátora. Komprese šumu ukazuje trychtýř události → alerty → situace → incidenty, kontroly, které nikdy nevedly k incidentu (návrhy ladění triggerů), a hosty bez položky v CMDB. S demo daty lze události simulovat (výpadek hypervisoru, pomalá databáze, flapping, šum). Pilotní varianta zpracovává události přímo v aplikaci; pro velké objemy se zpracování přesune do Kafky a Flinku (viz README).
Service desk
incidenty, problémy a plnění požadavků
Incident management
Incident je neplánované přerušení nebo zhoršení služby. Při založení vyberete položku, kde se problém projevuje – aplikace z CMDB spočte, které služby výpadek zasáhne, navrhne zasaženou službu, dopad a řešitelský tým (vlastnický tým položky). Priorita P1–P4 vychází z dopadu a naléhavosti; termíny reakce a vyřešení určuje SLA zasažené služby (jinak zákazníka, jinak výchozí) v jeho pracovní době – formulář platné SLA a termín ukáže předem. Stavy a přechody určuje workflow (Správa → Workflow), výchozí: nový → přiřazený → řeší se → (pozastavený, čeká na dodavatele) → vyřešený → uzavřený. Tlačítka v detailu odpovídají přechodům, které smíte provést; některé vyžadují komentář. Pozastavení posouvá termíny SLA. Vyřešení vyžaduje kód a popis řešení; ohlašovatel může incident znovu otevřít. Incident manažer vyhlašuje závažný incident. V detailu je dopad z CMDB, změny kolem otevření incidentu (lze označit změnu jako příčinu) a tlačítka Navrhnout změnu a Nouzová změna. Incidenty u položky vidíte i v detailu konfigurační položky; monitoring je může zakládat přes API. Karta Změny ukazuje změny, které incident řeší – jednu změnu lze navázat na více incidentů a k incidentu připojit i existující změnu; o naplánování, zahájení a dokončení změny dostane ohlašovatel zprávu. Když nejde o poruchu, ale o požadavek ze služby, převeďte incident tlačítkem Převést na požadavek: vyberete položku katalogu, žadatelem bude ohlašovatel a incident se zruší s odkazem na nový požadavek.
War room
Koordinace závažného incidentu (P1/P2). War room otevřete z detailu incidentu. Aplikace navrhne sestavu týmů podle dat – jádro a zálohu podle alertů, kandidátních změn, podpůrného řetězce v CMDB a podobných incidentů – a porovná ji se „širokým bridge“. Sleduje přítomnost a náklady podle hodinových sazeb týmů, hypotézy (vyloučená oblast → návrh uvolnit tým) a při uzavření zapíše shrnutí do záznamu práce incidentu.
Problem management
Problém je příčina opakovaných nebo závažných incidentů. Vzniká z incidentu, z vyhodnocení závažného incidentu, z review po změně nebo z denní kontroly opakovaných incidentů (počet a období nastavíte v Parametrech procesů). Z příčiny vznikne známá chyba s náhradním řešením, které řešitelé uvidí u dalších incidentů. Trvalou opravu provede změna založená přímo z problému nebo k němu připojená (karta Změny). Po úspěšném dokončení změny přejde problém s popsanou příčinou sám do stavu Vyřešený, neúspěšná změna ho vrátí do analýzy; po ověření opravy problém uzavřete. Problém založený z hlavního incidentu převezme i jeho podřízené incidenty.
Změny
změny, schvalování a patchování
Change management
Změny se zakládají podle modelů změn. Model určuje typ změny (standardní předschválená, normální, nouzová), kdo schvaluje (vlastník zasažené služby, change manažer, CAB, nebo nikdo u standardní změny), zda musí termín ležet v servisních oknech, potřebný předstih ve dnech, zda lze změnu provádět postupně po položkách, zda smí do změnového zmrazení, pro které třídy položek je určen a jaké kroky změna má. Postup: vyberete model, pak business službu a v jejím stromu položky (nebo položky přímo). Aplikace z CMDB spočte, které služby a aplikace budou mimo provoz a které jen degradované, najde termíny podle pravidel modelu (servisní okna, zmrazení, kolize s jinými změnami, předstih) a po odeslání založí schválení. U odstávky schvaluje vlastník business služby (A), vlastníci aplikací se vyjadřují (C). Schválenou změnu realizátor zahájí, odškrtá kroky a dokončí – dokončit lze až po splnění všech kroků. Změnu k incidentu (i nouzovou) založíte přímo z detailu incidentu, opravnou změnu z detailu problému, standardní změnu z požadavku katalogu založí aplikace sama. Modely změn spravuje change manažer v záložce Modely změn, servisní okna vlastníci služeb v záložce Servisní okna. Karta Řešené záznamy ukazuje incidenty, problémy a požadavky, které změna řeší; další připojíte číslem záznamu (vazbu, ze které změna vznikla, odpojit nejde). Když se změna naplánuje, zahájí a skončí, dozví se to ohlašovatelé navázaných incidentů a žadatelé požadavků. Výsledek se propíše do navázaných záznamů: problém s popsanou příčinou přejde do stavu Vyřešený, neúspěšná změna ho vrátí do analýzy, incidenty a požadavky dostanou zápis s dalším krokem. Do 24 h po dokončení aplikace hlídá alerty na položkách změny – když přibudou, review po změně je povinné. Z probíhající nebo neúspěšné změny, změny s problémy nebo s alerty po dokončení založíte tlačítkem Založit incident incident, který změnu vede jako příčinu.
Patch management
Zranitelnosti serverů, patch dohody s vlastníky služeb a asistent change koordinátora pro plán patchování: z CMDB spočte zasažené služby a navrhne termíny v jejich servisních oknech, mimo zmrazení a kolize s jinými změnami; odstávku schválí vlastníci služeb. Zranitelnosti položky jsou i na její kartě v CMDB.
Konfigurace
CMDB, datová centra a enterprise architektura
Datová centra
Přehled datových center (ukazatele, sály, co vyžaduje pozornost), půdorys sálu a rack s umístěním hardwaru z CMDB. Vložení nebo přesun fyzického zařízení vytvoří změnu nebo požadavek; plánované pozice se v racku ukazují jako obrys.
Nastavení
Databáze: produkční data nebo oddělená demo data (platí pro celou aplikaci, zapisuje se do auditní stopy); v demu vidí uživatel s češtinou české demo a uživatel s angličtinou anglické. Retence: auditní stopa se uchovává 5 let a databáze nedovolí záznam smazat dřív ani ho změnit; historie konfiguračních položek a vztahů podle nastavení (výchozí 5 let), běhy discovery a připojení 13 měsíců. Týmy: vlastníci položek, služeb a změn a řešitelé incidentů a požadavků, s členy a vedoucím. Kvalita dat CMDB: nekonzistence (umístění VM, chybějící vlastnický tým, detail třídy, náklady) a zdroje pravdy o umístění. Životní cyklus HW: konec prodeje a podpory modelů. Kurzy ČNB pro přepočet nákladů v cizí měně.
Enterprise architektura
Model podle ArchiMate: schopnosti, aktéři, procesy, aplikace a aplikační služby, datové objekty a technologie navázaná na CMDB. Aplikace se hodnotí podle TIME (Tolerate, Invest, Migrate, Eliminate) a fází životního cyklu; cílový stav popisují plató a pracovní balíčky navázané na změny. Detail artefaktu ukazuje náklady, dostupnost, incidenty, změny a řetězec k infrastruktuře. Export ve formátu Open Exchange.
Finance a majetek
náklady, vyúčtování, majetek, nákup a smlouvy
Přehled nákladů
Měsíční náklady všech zákazníků nebo jednoho vybraného. Dlaždice ukazují náklady, alokovaný výpočet, jeho využití, paměť a storage. Graf je za posledních 12 měsíců; kliknutím na sloupec změníte měsíc. Kliknutím na řádek zákazníka zúžíte celou stránku na něj. Tlačítko Stáhnout FOCUS CSV vydá řádky ve standardu FOCUS.
Analýza nákladů
Vlastní pohledy na data: do řádků vyberete až 4 dimenze (zákazník, projekt, cluster, položka…), do sloupců jednu (typicky měsíc), zvolíte míry a filtry. Tabulka se přepočítá okamžitě. Uložená tabulka je dostupná všem uživatelům; Export CSV otevřete v Excelu (oddělovač středník).
Billing
Měsíční podklady pro vyúčtování. V záložce Šablony nastavíte seskupení řádků, přirážku, slevu a DPH, ve Fakturačních údajích IČO, adresu a smlouvu zákazníka. Podklady vygenerujete pro celý měsíc najednou; koncept se dá přegenerovat, schválený podklad je zmrazený. Stav: koncept → schváleno → odesláno, storno je možné kdykoli.
Ceník
Finance → Ceník služeb. Verze ceníků (koncept, platný, archiv) s jednotkovými cenami po sekcích: infrastruktura, virtuální stroje podle platformy (VMware vSphere, Azure Stack Hub, OpenShift Virtualization – vCPU, paměť, disk), operační systémy (Windows Server, RHEL, SUSE, Ubuntu), typové servery Windows a Linux, úrovně podpory a provozní služby, odbavení požadavků (vazba na katalog) a provedení změn (typ změny, model změny). Ceny upravuje role s oprávněním rate.manage; kalkulace virtuálního serveru porovná platformy. Každý nákladový řádek nese odkaz na verzi ceníku, takže je zpětně dohledatelné, jakou cenou byl oceněn.
Evidence majetku
Karty majetku navázané na konfigurační položky: nákup, příjem, faktury, uvedení do užívání, odpisy, nákladová střediska, sklady náhradních dílů a předávací protokoly. Uzavřená změna instalace hardwaru uvede kartu do užívání; vyřazení respektuje zaúčtované odpisy.
Licence softwaru
Nároky z licenčních smluv podle výrobce a produktu, přiřazení licencí k serverům, databázím a uživatelům a soulad s instalacemi nalezenými v CMDB. Spotřeba je větší z počtu přiřazených licencí a nalezených instalací; spotřeba nad nárok je vyznačená.
Dodavatelé a servisní kontrakty
Finance → Dodavatelé a smlouvy (servisní kontrakty a dodavatelé). Dodavatel nese hotline, portál podpory, zákaznické číslo a kontakty se stupněm eskalace (hotline, 1. a 2. eskalace, vedení). Kontrakt (smlouva o podpoře, údržbě, předplatném nebo rozšířené záruce) má platnost, výpovědní lhůtu, automatické prodloužení, dny upozornění předem, cenu a fakturaci, zákazník a správce smlouvy. Úrovně podpory jsou SLA dodavatele: pracovní doba dodavatele, lhůta reakce a opravy, technik na místě. Krytá zařízení jsou řádky kontraktu – položky z CMDB s vlastní úrovní, sériovým číslem, obdobím a případně cenou (jinak se cena kontraktu rozpočítá). Dokumenty (smlouvy, dodatky, podmínky, max. 10 MB) jsou uložené v databázi. Denně se hlídá konec platnosti: upozornění správci smlouvy, týmu a roli Správce smluv při prvním překročeném prahu, po konci zpráva „skončil“, automaticky prodlužované kontrakty se prodlouží. V incidentu karta Dodavatel najde platnou podporu položky nebo hardwaru, na kterém běží; Nahlásit dodavateli (nebo přechod do stavu Čeká na dodavatele) spustí termíny dodavatele, Dodavatel reagoval / Opraveno je uzavře. Přehled kontraktů ukazuje končící smlouvy s posledním dnem výpovědi, pokrytí hardwaru podporou, hardware bez podpory, roční náklady podle dodavatele a zákazníka a plnění SLA dodavatelů. Spravuje Správce smluv (contract.manage), číst může i incident manažer a configuration manager (contract.read).
Správa
integrace, lidé a přístupy, nastavení aplikace
Připojení
Tenanti a účty, ze kterých se sbírají data: Azure, Azure Stack Hub, AWS, Google Cloud, Oracle Cloud, OpenShift a datové centrum. Ukládají se jen identifikátory a odkazy na trezor (kv://, vault://…), nikdy hesla ani klíče – aplikace je odmítne uložit.
Import a API
Nahrání FOCUS souborů (CSV/JSON) a dokumentace REST API pro sběrné skripty, monitoring (incidenty) a integrace. Opakovaný import stejného zdroje za stejný měsíc předchozí data nahradí, nezdvojí je. Řádky v cizí měně se přepočtou do CZK kurzem ČNB k prvnímu dni období. Zápisy vyžadují administrátorský nebo API token.
Notifikace
Zprávy e-mailem (Resend nebo SendGrid) a do Slacku (incoming webhook na kanál). Pravidlo = záznam (incident, požadavek, změna, konfigurační položka) + událost (založení, změna stavu, přiřazení, komentář, žádost o schválení, rozhodnutí, hrozící a překročené SLA) + podmínky (priorita, závažný incident, cílový stav) + šablona + kanály + příjemci (řešitel, řešitelský tým, ohlašovatel, žadatel, schvalovatelé, vlastnický tým, držitelé role, tým, uživatel, libovolná adresa). Šablona má předmět a text v rich text editoru (tučně, nadpisy, seznamy, citace, odkazy, HTML zdroj) a parametry {{incident.id}}, {{incident.priority_name}}, {{transition.to}}… vložíte tlačítkem z pravého panelu; hodnoty se doplní ze záznamu a escapují. Náhled ukazuje e-mail i Slack na ukázkových datech nebo na zvoleném záznamu, zkušební odeslání ověří kanál. Kanál nese jen odkaz na secret Workeru (env:RESEND_API_KEY, env:SLACK_WEBHOOK_PROVOZ…), aplikace klíče ani webhooky neukládá. SLA se kontroluje každých 5 minut (upozornění 30 minut před termínem a po jeho překročení, každé jen jednou). Při demo datech se zprávy ve výchozím stavu jen zapisují do logu, adresy v testovacích doménách (.example) se nedoručují nikdy. Záložka Odeslané ukazuje log doručení včetně chyb a přeskočených zpráv.
Přístupy a odpovědnosti
Role IT person (správce platformy, konfigurační manažer, vlastník služby, vlastník aplikace, infrastrukturní specialista, change manažer, incident manažer, service desk, auditor, servisní účet discovery) s rozsahem na zákazníka, tým (z evidence týmů) nebo konkrétní položku. RACI matice určuje, kdo konfigurační data a změny provádí, schvaluje, konzultuje a je informován; aplikace hlídá, aby role R a A měly odpovídající oprávnění. Servisní účty dostávají API tokeny, auditní stopa zaznamenává každý zápis.
Workflow
Stavy a přechody pro incidenty, požadavky, změny a konfigurační položky. Každý stav patří k systémovému stavu, na kterém stojí logika aplikace (SLA, schvalování, kroky změny, vyřazení položky) – vlastní stav jako „Čeká na dodavatele“ se chová jako Pozastavený a čas SLA stojí. Matice přechodů: řádek = výchozí stav, sloupec = cílový stav, kliknutím na buňku přechod přidáte nebo upravíte. U přechodu nastavíte popisek tlačítka, oprávnění (vyhodnocuje se v rozsahu týmu, zákazníka nebo služby), zda ho smí i ohlašovatel / žadatel / navrhovatel, zda jde o schvalovací krok (požadavky), povinný komentář a povinná pole (řešení, řešitel) a vzhled tlačítka. Do stavů čekání na schválení, schváleno a zamítnuto u změn vede jen aplikace (odeslání termínu a rozhodnutí schvalovatelů). Systémové stavy nelze smazat, jen přejmenovat; vlastní stav, který některý záznam používá, deaktivujte. Konfigurace je společná pro produkční i demo data. Upravuje správce platformy a configuration manažer (workflow.manage).
AI asistent
Jazykový model pomáhá tam, kde se pracuje s textem – vždy jen navrhuje a rozhoduje člověk. Shrnutí situace (Event management): co se děje, pravděpodobná příčina s položkou z CMDB, doporučené kroky a míra jistoty; vzniká automaticky pro situace od nastavené severity, jinak tlačítkem. Předvyplnění incidentu: v založení incidentu ze situace tlačítko „Navrhnout pomocí AI“, v Nahlásit incident pole „Popište problém vlastními slovy“ – položku, službu a tým vybírá jen z CMDB, prioritu vždy spočte aplikace z dopadu a naléhavosti. Co pomohlo minule: podobné vyřešené incidenty podle významu textu a rada z jejich řešení. Komunikace: koncept průběžné informace pro zákazníky a závěrečné zprávy – upravíte, zkopírujete nebo uložíte jako komentář, nic se neodesílá samo. Kontrola změny: pravidlové kontroly (popis, rollback, riziko vs. odstávka kritické služby, ověření po změně, komunikace) a shrnutí pro schvalovatele. Osobní údaje a tajemství se před odesláním maskují, každý návrh se zapisuje (Správa → AI asistent → Poslední návrhy) a hodnocením „Pomohlo to?“ měříte kvalitu. U zákazníků s politikou „jen on-premise“ nebo „bez AI“ se data cloudovému modelu neposílají. Bez modelu nebo po vyčerpání denního limitu se zobrazí deterministický návrh. Spravuje správce platformy (ai.manage): přepínače, limit, prompty s verzemi, politika zákazníků.
Další informace
Provozní přehled
Úvodní obrazovka pro management. Dlaždice: business služby v provozu, služby bez jediného bodu selhání, počet serverů, servery s nepodporovaným OS, změny ke schválení a náklady za poslední měsíc – každá vede do detailu. Pod nimi stav business služeb (kritičnost, SLA, stav, odolnost, nejbližší odstávka), Infrastruktura (Power, virtualizace, cloud, kontejnery, aplikace, síť, SAN, zálohování a každé diskové pole s obsazeností, počtem svazků, HA a DR replikací a FC porty), Redundance (servery na dvou síťových prvcích, SAN v obou fabric, LPAR na dvojici VIOS, produkční datastory na zrcadlených svazcích, produkční servery se zálohou, služby bez SPOF), Životní cyklus a patchování, Změny a odstávky (včetně změn po termínu a zmrazení), Discovery a kvalita dat a Náklady. Na telefonu se služby zobrazují jako karty.