Dokumentace

Pojmy a dotazy

Slovník pojmů a odpovědi na časté otázky z provozu aplikace.

Slovník pojmů

Virtuální switch (VDS / vSwitch)
vSphere Distributed Switch spravovaný z vCenter pro celý cluster, nebo standardní vSwitch na jednom ESXi hostu. Fyzické uplinky (vmnic) vedou do dvojice leaf přepínačů – výpadek jednoho přepínače znamená jen degradaci.
Port group
Skupina portů virtuálního switche se společnou VLAN a pravidly teamingu. Síťová karta VM je připojená k port group; port group je mapovaná na VLAN ve fyzické síti. Výpadek port group odpojí všechny její VM (záložní síť jen degraduje).
FOCUS
FinOps Open Cost and Usage Specification – otevřený standard formátu nákladových dat (FinOps Foundation). Aplikace pracuje se sloupci FOCUS 1.x.
EffectiveCost
Skutečný (amortizovaný) náklad po slevách. Z něj se počítají přehledy i podklady pro billing.
ListCost / ContractedCost
Náklad podle ceníku, resp. podle smluvní ceny. Rozdíl proti EffectiveCost je úspora.
Sub-účet
Subskripce, účet, projekt nebo cluster u poskytovatele (FOCUS SubAccount). V OpenShiftu hosted cluster, v datovém centru server IBM Power.
Label zákazníka a projektu
Kubernetes / cloudové labely eywo.cz/customer a eywo.cz/project, podle kterých se náklady přiřazují. Přejmenovaný label lze napojit aliasem.
Alokované množství
U kontejnerů max(request, usage) po hodinách; u IBM Power entitled cores × hodiny. Využití = skutečná spotřeba ÷ alokace.
Entitled capacity
Garantovaný podíl procesorových jader přidělený LPAR v IBM Power; základ pro účtování výpočtu.
Capacity on Demand (CoD)
Jádra a paměť osazené v serveru, které se aktivují licenčním klíčem podle potřeby.
NPIV
N_Port ID Virtualization – virtuální FC adaptér LPAR s vlastním WWPN, který jde přes VIOS přímo do SAN.
WWPN
World Wide Port Name – jednoznačná adresa FC portu; podle ní se zónuje a mapuje.
Zóna
Pravidlo v SAN fabric, které povoluje komunikaci mezi porty hostitele a diskového pole.
Thin provisioning
Volume zabírá v poolu jen skutečně zapsaná data; účtuje se alokovaná velikost.
HyperShift (hosted control planes)
Řídicí vrstva OpenShift clusterů zákazníků běží jako pody na sdíleném management clusteru; zákazník má jen pracovní uzly.
LAG / LACP
Agregace více fyzických portů do jednoho logického (Port-channel); LACP ji vyjednává. vPC / MLAG umožní agregaci přes dva switche.
Servisní okno
Opakovaný čas (týdně nebo měsíčně), kdy smí být služba nedostupná (odstávka) nebo běžet se sníženou redundancí (degradace). Definuje ho vlastník služby nebo aplikace, včetně maximální délky odstávky.
RACI
Responsible (provádí), Accountable (odpovídá a schvaluje, právě jeden), Consulted (konzultován), Informed (informován).
Verze CI
Snímek konfigurační položky platný od–do. Nová verze vzniká při každé změně z discovery, API nebo ruční úpravy.
VLAN, SVI, VRF
VLAN odděluje L2 segmenty; SVI je L3 rozhraní VLAN na switchi (brána subnetu); VRF odděluje směrovací tabulky.
Cesta dopadu
Řetěz položek od simulovaného výpadku ke každé zasažené službě, včetně komponent (porty, rozhraní, zóny, VLAN). V mapě závislostí ji zvýrazní tlačítko Cesta dopadu v panelu impact analýzy.
Následek (alert)
Alert, který vysvětluje výpadek kořenové položky situace (podle simulace výpadku v CMDB). V situaci je vidět, nebudí notifikace, nepočítá se do ukazatelů šumu a po vyřešení příčiny se vyřeší s ní.
Odvozená příčina
Položka bez vlastního alertu (monitoring ji nevidí), jejíž simulovaný výpadek vysvětluje alerty na několika závislých položkách – např. hostitel, na kterém alertuje pět VM. Event management z nich založí jednu situaci s příčinou „odvozeno z topologie“.
Jediný bod selhání (SPOF)
Položka, jejíž samostatný výpadek vyřadí službu nebo aplikaci úplně. Karta Vysoká dostupnost je hledá simulací výpadku každé podpůrné položky; logické komponenty (aplikace, instance DB, cluster) se počítají zvlášť.
Výpadek a degradace
Výpadek = položka nefunguje. Degradace = funguje bez části funkcí nebo s horším výkonem (např. bez správcové sítě pole, bez páskové kopie záloh, nosič sám degradovaný). Ohroženo = ztráta redundance: vypadl jen jeden z redundantních prvků, položka běží dál bez zálohy; v impact analýze se ukáže u nejbližší závislé položky a u služeb nad ní („bez redundance“), dál se nešíří.
Redundantní skupina
Skupina nosičů, které se navzájem zastupují – cluster aplikace, Db2 HADR, Oracle Data Guard, PowerHA, dvojice VIOS, HyperSwap kopie svazku, uzly Veeam; bez ruční skupiny také prvky stejné třídy (síťové prvky jen stejné role – switch nekryje firewall, rozhraní jen stejného účelu – datové nekryje správcové). Závislá položka vypadne, až když vypadnou všichni členové. Plánované položky se jako člen nepočítají. Discovery skupinu posílá v attributes.redundancy_group u vztahu.
HyperSwap / policy-based HA
Svazek zrcadlený synchronně mezi dvěma diskovými poli; při výpadku jednoho pole běží I/O z druhého bez přerušení.
Db2 HADR, Oracle Data Guard, PowerHA, SQL Always On
Databázová vysoká dostupnost: primární a záložní instance na různých serverech (zde i na různých rámech a polích) se synchronní replikací a automatickým převzetím.
Dvojice VIOS
Dva Virtual I/O Servery na rámu IBM Power; LPAR má síť i disky přes oba, takže výpadek jednoho VIOS LPAR ohrozí (běží bez zálohy), ale nevyřadí.
SAN fabric A/B, core a edge switch, ISL
Dvě oddělené SAN sítě – každý server a pole je připojen do obou. Core přepínač nese pole, edge přepínač hosty; propojuje je ISL (inter-switch link).
Hardened repozitář
Linuxový server s lokálními disky pro zálohy Veeam s nezměnitelností (immutabilita) – zálohy nejde smazat ani zašifrovat ransomwarem.
Zálohuje / je zálohován
Vztah zálohovací platformy (IBM Storage Protect, Veeam) k chráněné položce. Nemá vliv na dostupnost; z něj se počítá pokrytí produkčních serverů zálohou.
Incident
Neplánované přerušení nebo zhoršení služby. Cílem je co nejrychlejší obnova, ne hledání příčiny (to řeší problem management).
Priorita a SLA
Priorita P1–P4 = dopad × naléhavost. SLA dohoda služby určuje pro každou prioritu termín reakce a vyřešení; pozastavení incidentu termíny posouvá.
SLA dohoda
Dohodnutá úroveň služby (např. Gold, Silver, Bronze): lhůty reakce a vyřešení podle priority, pracovní doba, požadované plnění a dostupnost.
Pracovní doba (kalendář SLA)
Doba, ve které běží čas SLA – např. 24×7 nebo pondělí–pátek 8:00–16:30 mimo státní svátky.
Závažný incident
Výpadek důležité služby, který koordinuje incident manažer a o kterém se průběžně informuje vedení a vlastníci služeb.
Požadavek (service request)
Standardní, předem popsaná žádost z katalogu služeb – nejde o poruchu. Má formulář, schválení, lhůtu a kroky plnění.
Model změny
Šablona pro opakovaný druh změny: typ, schvalování, nutnost servisního okna, předstih, povolené třídy položek a kroky.
Standardní, normální a nouzová změna
Standardní je předschválená a nízkorizikové (např. postupné patchování hypervisorů). Normální prochází schválením. Nouzová řeší probíhající incident nebo kritickou zranitelnost a smí mimo okna.
CAB
Change Advisory Board – schvalování rizikovějších změn change manažerem spolu s vlastníky zasažených služeb.
Tým
Skupina lidí, která vlastní konfigurační položky, služby a změny a řeší incidenty a požadavky. Rozsah role „tým“ dává oprávnění k položkám týmu.
Zdroj pravdy
Systém, jehož údaj platí. Pro umístění VM a partition je to management nástroj virtualizace (vCenter, SCVMM, HMC…), ruční zápis ho nepřepíše.
Událost, alert, situace
Událost je jedno hlášení monitoringu. Alert jsou všechny výskyty téhož problému na téže položce (deduplikace podle fingerprintu). Situace je skupina souvisejících alertů – typicky jedna příčina a její důsledky.
Pravděpodobná příčina (★)
Alert na položce, na které ostatní alerty situace podle mapy závislostí CMDB závisí – např. hypervisor pod nedostupnými VM.
Flapping
Alert, který opakovaně přechází mezi problémem a OK; místo desítek notifikací je jedna situace se stavem „kolísá“.
Workflow
Stavy záznamu a povolené přechody mezi nimi včetně toho, kdo je smí provést. Vlastní stavy se mapují na systémové stavy, na kterých stojí logika aplikace.
Notifikační pravidlo
Kdy (událost a podmínky), co (šablona s parametry), kudy (e-mail, Slack) a komu se zpráva pošle.
Servisní kontrakt a řádek kontraktu
Smlouva s dodavatelem o podpoře infrastruktury. Řádek = jedna položka CMDB, kterou smlouva kryje, s vlastní úrovní podpory a obdobím krytí.
SLA dodavatele (úroveň podpory)
Co garantuje dodavatel nám: lhůta reakce a opravy v jeho pracovní době (např. 24×7 – reakce 2 h, oprava 8 h, nebo další pracovní den). Odlišné od SLA, které garantujeme zákazníkům.
Výpovědní lhůta
Kolik dní před koncem platnosti nejpozději musíme smlouvu vypovědět nebo rozhodnout o prodloužení; přehled ukazuje poslední den.
Retence
Doba uchování záznamů. Auditní stopa 5 let a nedá se změnit; historie konfigurace podle nastavení.

Časté dotazy

Jak napojím Zabbix nebo Prometheus na Event management?

Monitoring → Zdroje událostí → u zdroje „Jak napojit“: Zabbix 6.4+ přes Connectors (streaming událostí) nebo webhook, Alertmanager přes webhook receiver, ostatní přes generické API. Potřebujete API token servisního účtu s rolí „Zdroj událostí“ (Správa → Přístupy a role) a v Cloudflare variantě service token Cloudflare Access.

Proč se z události nestal alert?

Monitoring → Situace a alerty nebo Komprese šumu: událost mohlo zahodit pravidlo filtrace (např. informační), potlačit pravidlo potlačení nebo probíhající změna na položce, nebo jde o další výskyt existujícího alertu (zvýší se jen počítadlo).

Posílá aplikace data do AI?

Jen pro zapnuté use casy AI asistenta (Správa → AI asistent) a jen to, co návrh potřebuje; e-maily, telefony, rodná čísla, čísla účtů a tajemství se předtím nahradí značkami. Data zákazníků s politikou „jen on-premise“ dostane jen model ve vlastní infrastruktuře, s politikou „bez AI“ žádný model. Každé volání je v záznamu návrhů.

Kde nastavím SLA?

Služby → SLA. V záložce SLA dohody upravíte lhůty podle priority a přiřadíte dohodu službám a zákazníkům, v Pracovní době kalendáře a svátky, v Lhůtách požadavků lhůty položek katalogu. Plnění SLA je v první záložce.

Kde nastavím workflow incidentů, požadavků, změn a konfiguračních položek?

Správa → Workflow. Vyberete záznam (Incidenty, Požadavky, Změny, Konfigurační položky), v tabulce Stavy přidáte nebo přejmenujete stav a v Matici přechodů kliknutím na buňku nastavíte přechod: popisek tlačítka, oprávnění, povinný komentář nebo pole. Změny se projeví v detailu záznamů do minuty.

Jak zapnu e-mailové a Slack notifikace?

Ve Správě → Notifikace → Kanály je postup. Krátce: u Resend (nebo SendGrid) ověřte doménu odesílatele a vytvořte API klíč, ve Slacku webhook pro kanál, pak `npx wrangler secret put RESEND_API_KEY`, `npx wrangler secret put SLACK_WEBHOOK_PROVOZ` a `npx wrangler secret put SLACK_WEBHOOK_MAJOR`. U kanálu se pak ukáže „secret nastaven“. Odesílatele nastavte na adresu ve vaší ověřené doméně.

Proč se notifikace neodeslala?

Správa → Notifikace → Odeslané ukáže důvod: chybí secret kanálu, příjemce nemá e-mail, testovací adresa (.example), demo režim (doručování při demo datech je vypnuté) nebo chyba služby (kód a text odpovědi).

Jak zjistím, kdo opravuje vadný server a do kdy?

V incidentu karta Dodavatel – podpora se hledá u položky a u hardwaru, na kterém běží (VM → host, LPAR → rám Power). Ukáže dodavatele, úroveň, hotline a eskalace; Nahlásit dodavateli spustí termíny reakce a opravy podle kontraktu. V detailu položky CMDB je karta Podpora a kontrakty.

Kde vidím hardware bez podpory a končící smlouvy?

Finance → Přehled kontraktů: končící a skončené kontrakty s posledním dnem výpovědi, pokrytí podle třídy, seznam hardwaru bez platné podpory a co končí do 90 dní. Upozornění e-mailem nastavíte ve Správě → Notifikace (záznam Kontrakt).

Jak vypnu demo data?

Správa → Nastavení → Demo data. Přepínač přepne celou aplikaci na produkční databázi; demo data zůstanou v oddělené databázi a lze je kdykoli zapnout. Přepnout může správce platformy.

Kde jsou CMDB, operační systémy a změny po úpravě menu?

Menu má skupiny podle oblastí řízení IT služeb: Služby (portfolio služeb, SLA, katalog požadavků), Monitoring (situace a alerty, komprese šumu, pravidla a zdroje událostí), Service desk (incidenty, problémy, plnění požadavků), Změny (změny, schvalování, patchování a zranitelnosti), Konfigurace (CMDB, datová centra, životní cyklus, kvalita dat, enterprise architektura), Finance a majetek (náklady, vyúčtování, majetek, nákup, dodavatelé a smlouvy) a Správa (integrace, lidé a přístupy, nastavení aplikace). Nejrychlejší je hledání klávesami Ctrl+K – najde i stránky menu.

Proč nejde změnit hostitele VM ručně nebo z jiného zdroje?

Umístění VM a partition je převzaté z management nástroje virtualizace (vCenter, SCVMM, HMC…). Jiný zdroj nebo ruční zápis by se s ním rozešel; discovery z jiného zdroje dostane chybu s názvem nástroje, který umístění spravuje.

Jak propojím změnu s více incidenty nebo problémem?

V detailu změny karta Řešené záznamy → Připojit: vyberete druh záznamu a zadáte jeho číslo. Z detailu incidentu, problému nebo požadavku připojíte existující změnu jejím číslem v kartě Změny. Vazbu, ze které změna vznikla, odpojit nejde; ostatní odpojí navrhovatel, realizátor, change manažer nebo správce záznamu.

Co se stane s problémem a incidenty, když se opravná změna dokončí?

Problém s popsanou příčinou přejde do stavu Vyřešený a nese odkaz na opravnou změnu; bez příčiny dostane zápis, ať ji doplníte. Neúspěšná změna vrátí problém do analýzy. Incidenty a požadavky dostanou zápis s dalším krokem (ověřit a vyřešit kódem „Vyřešeno změnou“) a ohlašovatelé zprávu.

Ohlášený incident je ve skutečnosti požadavek (nebo naopak). Co s ním?

V detailu incidentu Převést na požadavek (vyberete položku katalogu), v detailu požadavku Převést na incident. Nový záznam převezme popis, položku a ohlašovatele, lhůta běží od převodu a původní záznam se zruší s odkazem na nový.

Proč výpadek jednoho switche ze dvojice neukazuje výpadek ani degradaci?

Server je připojený do obou switchů, takže běží dál – jen bez zálohy. Impact analýza to ukáže jako „ohroženo“ u nejbližších závislých položek a u služeb nad nimi („bez redundance“) a dál to nešíří. Při změně na takovém switchi vlastník služby dostane informaci, ale schvalovat nemusí. Pokud by vypadl i druhý switch, jde o výpadek.

Co znamená situace s odvozenou příčinou?

Několik položek alertuje současně a mají společnou oporu (hostitel, datastore, switch), která sama alert nehlásí – monitoring ji nevidí. Aplikace podle CMDB ověří, že výpadek této opory vysvětlí všechny alerty, a založí jednu situaci s příčinou „odvozeno z topologie“. Ověřte stav opory v monitoringu; z detailu situace lze její výpadek simulovat v mapě.

Proč nejde změnu dokončit?

Model změny definuje kroky změny. Dokončit lze až po odškrtnutí všech kroků v detailu změny.

Jak se počítají termíny SLA incidentu?

Od otevření incidentu podle priority (např. P2: reakce 30 min, vyřešení 8 h). Doba pozastavení se k termínům přičte. Reakce je splněná převzetím k řešení.

Jak se do CMDB dostávají změny z discovery?

Sběrné skripty (HMC, vCenter, SCVMM, cloudová API, OpenShift, pole, SAN, síť) posílají položky na POST /api/cmdb/discovery s API tokenem servisního účtu. Každá změna atributu vytvoří novou verzi; v detailu položky je historie s porovnáním hodnot a stav k libovolnému datu. Při úplné synchronizaci se položky, které discovery nenašla, označí a po nastavené době vyřadí.

Proč nelze najít termín patchování?

Některá zasažená služba nemá servisní okno, její maximální odstávka je kratší než změna, nebo se okna služeb nepřekrývají. Zkuste delší horizont, kratší zásah, nebo postupné patchování po jednotlivých položkách s redundancí.

Proč se náklady za měsíc změnily, i když už skončil?

Poskytovatelé (zejména Azure a AWS) dopočítávají náklady ještě několik dní po konci měsíce. Podklady pro billing generujte po 5. dni následujícího měsíce a před odesláním je schvalte – schválený podklad se už nemění.

Co když zákazník nemá label?

Řádky bez labelu se zobrazí jako „(bez zákazníka)“ nebo „(bez projektu)“. Doplňte label na namespace / zdroji, nebo přidejte alias.

Mohu podklad opravit po schválení?

Vraťte ho do konceptu, opravte data nebo šablonu a přegenerujte. Odeslaný podklad lze jen stornovat a vygenerovat nový – dostane nové číslo.

Jak nahraji data z vlastního skriptu?

Pošlete FOCUS řádky na POST /api/ingest/focus s administrátorským tokenem (viz Import a API). Pro více částí jednoho souboru posílejte stejné upload_id.

Co znamená „Bez jediného bodu selhání“?

Aplikace nasimulovala výpadek každé položky, na které služba stojí (servery, rámy, VIOS, hosty, datastory, svazky, pole, SAN a síť), a žádný samostatný výpadek službu nevyřadil – nejvýš ji degraduje. Kombinace více výpadků najednou kontrola nezkoumá; tu ověříte v impact analýze výběrem více položek.

Proč je produkční server veden jako nezálohovaný?

Nemá vztah „je zálohován“ – discovery u něj nenašla agenta IBM Storage Protect ani Veeam. Cloudové VM se do pokrytí nepočítají, zálohuje je poskytovatel.

Proč výpadek správcové sítě nebo páskové knihovny službu jen degraduje?

Diskové pole obsluhuje data přes SAN; bez správcové sítě ztratí správu, monitoring a IP replikaci do DR, ale běží. Bez páskové knihovny zálohy pokračují na disk, chybí jen kopie na pásku. Takové vztahy mají příznak „jen degradace“.

Jak aplikaci používat na telefonu?

Menu otevřete tlačítkem Menu vpravo nahoře; v něm je i volba role a motivu. Široké tabulky se posouvají do strany – zeslabený okraj ukazuje, že pokračují. Mapa závislostí se otevírá jako strom; v zobrazení Graf posouváte prstem a přibližujete dvěma prsty.

Kde se ukládají hesla k cloudům?

Nikde v aplikaci. Připojení obsahuje jen odkaz do trezoru; sběrné skripty si tajemství načítají samy.