Services
Serviceportfolio, Service-Levels und Anforderungskatalog
Konfigurationsdatenbank
Allgemeines Infrastrukturmodell: IBM Power (LPAR, VIOS, HMC), Virtualisierung mit VMware, Hyper-V und Azure Stack Hub, virtuelle Server in Public Clouds (Azure, AWS, GCP), Container-Cluster überall (OpenShift und HyperShift, AKS, EKS, GKE), Anwendungen, Anwendungsplattformen und Datenbanken, Disk-Arrays, SAN und Netzwerk (Router, L3/L2-Switches, Port-Aggregation LACP und vPC, VLANs, Subnetze, Routing). Bei LPARs sehen Sie den Datenpfad über NPIV, SAN und Zone bis zum Disk-Array. Die Kosten der On-Prem-Infrastruktur werden direkt aus der CMDB berechnet. Die Abhängigkeitskarte zeigt die Elemente vom Business-Service abwärts als Graph oder Baum, mit Filter nach Kunde und Umgebung. Die Auswirkungsanalyse simuliert den Ausfall eines gewählten Elements und zeigt betroffene Services, Anwendungen und Kunden; bei redundanten Elementen (Switch-Paare, Cluster-Knoten, SAN-Fabrics A/B) unterscheidet sie zwischen Ausfall und Beeinträchtigung. Für Business-Services, Anwendungen, Plattformen und Datenbanken simuliert die Karte Hochverfügbarkeit den Ausfall jedes unterstützenden Elements, listet Single Points of Failure auf und zeigt redundante Gruppen (Anwendungscluster, Db2 HADR, Oracle Data Guard, PowerHA, VIOS-Paare, HyperSwap-Volumes). Jedes Element hat ein Symbol nach Typ (physischer Server, VM, LPAR, Anwendung, Datenbank, Disk-Array, Bandbibliothek, SAN-Switch, Router, Firewall, L2/L3-Switch …), die Farbe des Symbols entspricht der Kategorie. Für Hypervisoren, VIOS und LPARs gibt es die Karte Speicherpfad über beide SAN-Fabrics. Die Beziehungen zeigen redundante Gruppen und Beziehungen, deren Ausfall nur eine Beeinträchtigung bedeutet (z. B. Managementnetz des Arrays, Bandbibliothek). Die Beziehung „wird gesichert durch“ zeigt, welche Backup-Plattform das Element schützt. Auf dem Telefon öffnet sich die Karte als Baum; der Graph lässt sich mit einem Finger verschieben und mit zwei Fingern zoomen. Jedes Element hat ein verantwortliches Team; bei Hardware sehen Sie Installationsdatum, Garantieende und Ende des Herstellersupports. Den Standort von VMs und Partitionen (Host, Cluster, Power-Server) ändert nur die Discovery aus dem Verwaltungswerkzeug der jeweiligen Virtualisierung (vCenter, SCVMM, Azure Stack Hub, Cloud-API, HMC). Aus dem Detail eines Elements können Sie direkt einen Incident melden oder einen Change planen.
SLA
Service Level Management (Services → SLA). SLA-Erfüllung: Anteil der Incidents mit Reaktion und Lösung innerhalb der Frist nach Monaten und nach SLA-Vereinbarung, Prioritäten, Services, Kunden oder Teams, Vergleich mit dem Ziel, Liste der Verletzungen und Einhaltung der Anforderungsfristen. SLA-Vereinbarungen (standardmäßig Gold, Silver, Bronze, Standard): Reaktions- und Lösungsziele für P1–P4, Arbeitszeiten (für eine Priorität überschreibbar, z. B. P1 24/7), geforderte Erfüllung in %, Zielverfügbarkeit und Zeitpunkt der Benachrichtigung (nach Ablauf von % der Frist). Eine Vereinbarung weisen Sie einem Business-Service oder Kunden zu; es gilt das SLA des Service → das SLA des Kunden → das Standard-SLA. Arbeitszeiten: wöchentliche Fenster nach Tagen, tschechische Feiertage (einschließlich Karfreitag und Ostermontag) und weitere freie Tage, Vorschau auf 14 Tage. Die SLA-Zeit läuft nur in der Arbeitszeit und wird nicht verbraucht, solange ein Incident angehalten ist. Anforderungsfristen: Frist für die Erfüllung jedes Katalogeintrags in Stunden und Arbeitszeit. Änderungen gelten für neue Incidents und Anforderungen; offene Incidents lassen sich per Schaltfläche neu berechnen. Bearbeitet von Incident Manager und Plattformadministrator (sla.manage).
Request Management
Der Servicekatalog enthält Standardanforderungen (neuer Server, Kapazitätserweiterung, Firewall-Regel, Zugriff, Wiederherstellung aus dem Backup, Namespace in OpenShift). Jeder Eintrag hat ein Formular, eine Genehmigungsart (ohne Genehmigung, Service-Verantwortlicher des Kunden, Teamleiter des Lösungsteams, Change Manager), eine Frist, ein Lösungsteam und Erfüllungsschritte. Eine Anforderung ohne Genehmigung geht direkt in die Erfüllung. Der Bearbeiter übernimmt die Anforderung, hakt die Schritte ab und markiert sie als erfüllt; der Antragsteller schließt sie. Ein Eintrag, dessen Erfüllung die Infrastruktur ändert, ist mit einem Change-Modell verknüpft – aus der Anforderung entsteht ein Change, und die Anforderung lässt sich erst nach Abschluss des Change erfüllen. Den Katalog verwaltet der Konfigurationsmanager im Reiter Katalogverwaltung. Bei einem Eintrag mit Standard-Change-Modell legt die Anwendung den Change selbst an und plant ihn ohne weitere Genehmigung in den ersten freien Termin. Die Karte Changes im Detail zeigt die verknüpften Changes, und der Antragsteller wird benachrichtigt, wenn sie geplant, gestartet und abgeschlossen werden. Eine Anforderung, die eigentlich eine Störung ist, wandelt der Bearbeiter mit In Incident umwandeln um.
Monitoring
Monitoring-Events, ihre Korrelation und Regeln
Event Management
Empfang von Events aus dem Monitoring (Zabbix, Prometheus/Alertmanager, Checkmk, Grafana, Dynatrace, generische API) und ihre Reduktion auf das, worauf der Operator reagieren muss. Jedes Event wird einem Konfigurationselement zugeordnet (Hostname, FQDN, IP, Seriennummer oder ci_id-Tag), und betroffener Business-Service, Kunde und verantwortliches Team werden aus der CMDB ergänzt. Filterregeln verwerfen Rauschen, Unterdrückungsregeln und laufende Changes am Element unterdrücken den Alert (wecken den Operator nicht). Wiederholte Events desselben Problems (gleicher Fingerprint) erhöhen nur den Zähler des Alerts; eine OK-Meldung löst den Alert auf, ohne sie wird er nach einer Ruhephase aufgelöst. Ein schwankender Alert (mehrere Zustandswechsel pro Fenster) wird als Flapping markiert. Alerts werden zu Situationen zusammengefasst: topologisch anhand einer Ausfallsimulation in der CMDB – Ursache kann nur ein Element sein, dessen Ausfall den Alert tatsächlich erklärt (ein Switch aus einem Paar ist also nicht die Ursache eines Serverausfalls), und unter mehreren Kandidaten gewinnt der, der die meisten Alerts erklärt (★). Von der Ursache erklärte Alerts sind Symptome: in der Situation sichtbar, ohne Benachrichtigungen, aus den Rauschkennzahlen ausgenommen und zusammen mit der Ursache aufgelöst. Melden mehrere Elemente Alerts und teilen sie einen stillen gemeinsamen Träger (z. B. VMs auf einem Host), entsteht eine Situation mit abgeleiteter Ursache. Weiter wird nach Service und Zeit sowie nach zugehörigem Change gruppiert. Die Konsole ordnet Situationen nach Kritikalität des betroffenen Service und Schweregrad und aktualisiert sich live; der Operator bestätigt Situationen, weist sie einem Team zu, schaltet sie mit Begründung zeitweise stumm, führt sie zusammen und teilt sie. Ein Incident aus einer Situation ist vorausgefüllt (Element, Service, Auswirkung aus der tatsächlichen Auswirkung auf den Service – Ausfall, Beeinträchtigung oder nur Verlust der Redundanz – und deren Kritikalität, Dringlichkeit aus dem Schweregrad, Team, Alert-Zeitachse, Verknüpfung zum Change), und die Alerts bleiben mit dem Incident verknüpft – neue Alerts der Situation kommen hinzu, das Auflösen aller Alerts schlägt das Lösen des Incidents vor, und ein wiederkehrendes Problem öffnet den Incident erneut. Eine Regel für automatische Incidents legt einen Incident ohne Operator an. Die Rauschunterdrückung zeigt den Trichter Events → Alerts → Situationen → Incidents, Prüfungen, die nie zu einem Incident geführt haben (Vorschläge zur Trigger-Feinabstimmung), und Hosts ohne Element in der CMDB. Mit Demodaten lassen sich Events simulieren (Hypervisor-Ausfall, langsame Datenbank, Flapping, Rauschen). Die Pilotvariante verarbeitet Events direkt in der Anwendung; bei großen Mengen wird die Verarbeitung in Kafka und Flink verlagert (siehe README).
Service Desk
Incidents, Problems und Anforderungserfüllung
Incident Management
Ein Incident ist eine ungeplante Unterbrechung oder Beeinträchtigung eines Service. Beim Anlegen wählen Sie das Konfigurationselement, an dem das Problem auftritt – die Anwendung berechnet, welche Services betroffen sind, und schlägt den betroffenen Service, die Auswirkung und das Lösungsteam (verantwortliches Team des Elements) vor. Die Priorität P1–P4 ergibt sich aus Auswirkung und Dringlichkeit; Reaktions- und Lösungsfristen bestimmt das SLA des betroffenen Service (oder des Kunden oder das Standard-SLA) innerhalb seiner Arbeitszeiten – das Formular zeigt das gültige SLA und die Frist im Voraus. Zustände und Übergänge legt der Workflow fest (Verwaltung → Workflow), standardmäßig: neu → zugewiesen → in Bearbeitung → (angehalten, wartet auf Lieferanten) → gelöst → geschlossen. Die Schaltflächen im Detail entsprechen den Übergängen, die Sie ausführen dürfen; manche erfordern einen Kommentar. Das Anhalten verschiebt die SLA-Fristen. Die Lösung erfordert einen Code und eine Beschreibung; der Melder kann den Incident wieder öffnen. Der Incident Manager erklärt einen schweren Incident. Im Detail sehen Sie die Auswirkung aus der CMDB, Changes rund um die Eröffnung des Incidents (ein Change lässt sich als Ursache markieren) sowie die Schaltflächen Change vorschlagen und Notfall-Change. Incidents eines Elements sind in dessen Detail sichtbar; das Monitoring kann sie per API anlegen. Die Karte Changes zeigt die Changes, die den Incident lösen – ein Change kann mit mehreren Incidents verknüpft werden, und ein bestehender Change lässt sich mit dem Incident verknüpfen; der Melder wird benachrichtigt, wenn der Change geplant, gestartet und abgeschlossen wird. Handelt es sich nicht um eine Störung, sondern um eine Serviceanfrage, wandeln Sie den Incident mit In Anforderung umwandeln um: Katalogeintrag wählen, der Melder wird zum Antragsteller und der Incident wird mit Verweis auf die neue Anforderung storniert.
War Room
Koordination eines schweren Incidents (P1/P2). Den War Room öffnen Sie aus dem Incident-Detail. Die Anwendung schlägt die Teamaufstellung aus den Daten vor – Kern und Reserve anhand der Alerts, der Kandidaten-Changes, der unterstützenden Kette in der CMDB und ähnlicher Incidents – und vergleicht sie mit einer „breiten Bridge“. Sie erfasst Anwesenheit und Kosten nach Stundensätzen der Teams sowie Hypothesen (ausgeschlossener Bereich → Vorschlag, ein Team freizugeben) und schreibt beim Schließen eine Zusammenfassung in das Arbeitsprotokoll des Incidents.
Problem Management
Ein Problem ist die Ursache wiederkehrender oder schwerer Incidents. Es entsteht aus einem Incident, aus der Auswertung eines schweren Incidents, aus einem Review nach einem Change oder aus der täglichen Prüfung auf wiederkehrende Incidents (Anzahl und Zeitraum werden in den Prozessparametern festgelegt). Aus der Ursache wird ein bekannter Fehler mit Workaround, den die Bearbeiter bei weiteren Incidents sehen. Die dauerhafte Korrektur erfolgt durch einen Change, der direkt aus dem Problem angelegt oder mit ihm verknüpft wird (Karte Changes). Nach erfolgreichem Abschluss des Change geht ein Problem mit dokumentierter Ursache von selbst auf Gelöst; ein fehlgeschlagener Change schickt es zurück in die Analyse; schließen Sie das Problem, sobald die Korrektur überprüft ist. Ein aus einem übergeordneten Incident angelegtes Problem übernimmt auch dessen untergeordnete Incidents.
Changes
Changes, Genehmigungen und Patching
Change Management
Changes werden anhand von Change-Modellen angelegt. Das Modell bestimmt den Change-Typ (vorab genehmigter Standard-, normaler oder Notfall-Change), wer genehmigt (Verantwortlicher des betroffenen Service, Change Manager, CAB oder bei einem Standard-Change niemand), ob der Termin in Wartungsfenster fallen muss, die nötige Vorlaufzeit in Tagen, ob der Change schrittweise Element für Element umgesetzt werden kann, ob er während eines Change Freeze laufen darf, für welche Elementklassen er bestimmt ist und welche Schritte er hat. Ablauf: Modell wählen, dann einen Business-Service und die Elemente in seinem Baum (oder direkt die Elemente). Die Anwendung berechnet aus der CMDB, welche Services und Anwendungen ausfallen und welche nur beeinträchtigt sind, findet Termine nach den Regeln des Modells (Wartungsfenster, Freezes, Kollisionen mit anderen Changes, Vorlaufzeit) und legt nach dem Absenden die Genehmigungen an. Bei einer Ausfallzeit genehmigt der Verantwortliche des Business-Service (A) und die Anwendungsverantwortlichen werden konsultiert (C). Der Umsetzende startet den genehmigten Change, hakt die Schritte ab und schließt ihn ab – abschließen lässt er sich erst, wenn alle Schritte erledigt sind. Ein Change zu einem Incident (auch ein Notfall-Change) wird direkt aus dem Incident-Detail angelegt, ein Korrektur-Change aus dem Problem-Detail; einen Standard-Change für eine Katalog-Anforderung legt die Anwendung selbst an. Change-Modelle verwaltet der Change Manager im Reiter Change-Modelle, Wartungsfenster die Service-Verantwortlichen im Reiter Wartungsfenster. Die Karte Gelöste Datensätze zeigt die Incidents, Problems und Anforderungen, die der Change löst; weitere verknüpfen Sie über die Datensatznummer (die Verknüpfung, aus der der Change entstand, lässt sich nicht entfernen). Wenn der Change geplant, gestartet und beendet wird, werden die Melder verknüpfter Incidents und die Antragsteller verknüpfter Anforderungen benachrichtigt. Das Ergebnis überträgt sich auf die verknüpften Datensätze: Ein Problem mit dokumentierter Ursache geht auf Gelöst, ein fehlgeschlagener Change schickt es zurück in die Analyse, Incidents und Anforderungen erhalten einen Eintrag mit dem nächsten Schritt. 24 Stunden nach Abschluss überwacht die Anwendung Alerts auf den Elementen des Change – treten welche auf, ist das Post Implementation Review Pflicht. Aus einem laufenden oder fehlgeschlagenen Change, einem mit Problemen oder mit Alerts nach Abschluss beendeten Change öffnet die Schaltfläche Incident anlegen einen Incident, der den Change als Ursache erfasst.
Patch Management
Schwachstellen der Server, Patch-Vereinbarungen mit den Service-Verantwortlichen und ein Assistent des Change-Koordinators für den Patch-Plan: Er berechnet die betroffenen Services aus der CMDB und schlägt Termine in deren Wartungsfenstern vor, außerhalb von Freezes und Kollisionen mit anderen Changes; die Service-Verantwortlichen genehmigen den Ausfall. Die Schwachstellen eines Elements werden auch auf seiner CMDB-Karte angezeigt.
Konfiguration
CMDB, Rechenzentren und Unternehmensarchitektur
Rechenzentren
Übersicht der Rechenzentren (Kennzahlen, Räume, was Aufmerksamkeit erfordert), Raumgrundriss und Rack mit der Platzierung der Hardware aus der CMDB. Das Einsetzen oder Verschieben eines physischen Geräts erzeugt einen Change oder eine Anforderung; geplante Positionen werden im Rack als Umriss dargestellt.
Einstellungen
Datenbank: Produktivdaten oder getrennte Demodaten (gilt für die gesamte Anwendung, wird im Audit-Trail erfasst); im Demomodus sehen Benutzer mit Tschechisch die tschechische und Benutzer mit Englisch die englische Demo. Aufbewahrung: Der Audit-Trail wird 5 Jahre aufbewahrt, und die Datenbank lässt einen Datensatz weder früher löschen noch ändern; Historie der Elemente und Beziehungen nach Einstellung (standardmäßig 5 Jahre), Läufe von Discovery und Verbindungen 13 Monate. Teams: Verantwortliche für Elemente, Services und Changes sowie Bearbeiter von Incidents und Anforderungen, mit Mitgliedern und Leitung. Datenqualität der CMDB: Inkonsistenzen (Standort von VMs, fehlendes verantwortliches Team, Klassendetail, Kosten) und führende Quellen für den Standort. Hardware-Lebenszyklus: Vertriebs- und Supportende der Modelle. Wechselkurse der Tschechischen Nationalbank für die Umrechnung von Kosten in Fremdwährung.
Unternehmensarchitektur
Ein ArchiMate-Modell: Fähigkeiten, Akteure, Prozesse, Anwendungen und Anwendungsservices, Datenobjekte und mit der CMDB verknüpfte Technologie. Anwendungen werden nach TIME (Tolerate, Invest, Migrate, Eliminate) und Lebenszyklusphase bewertet; der Zielzustand wird durch Plateaus und mit Changes verknüpfte Arbeitspakete beschrieben. Das Artefakt-Detail zeigt Kosten, Verfügbarkeit, Incidents, Changes und die Kette bis zur Infrastruktur. Export im Format Open Exchange.
Finanzen und Assets
Kosten, Abrechnung, Assets, Einkauf und Verträge
Kostenübersicht
Monatliche Kosten aller Kunden oder eines ausgewählten Kunden. Die Kacheln zeigen Kosten, zugewiesene Rechenleistung, deren Auslastung, Arbeitsspeicher und Speicher. Das Diagramm umfasst die letzten 12 Monate; ein Klick auf eine Säule wechselt den Monat. Ein Klick auf eine Kundenzeile grenzt die ganze Seite auf diesen Kunden ein. Die Schaltfläche FOCUS-CSV herunterladen gibt die Zeilen im FOCUS-Standard aus.
Kostenanalyse
Eigene Datenansichten: Für die Zeilen wählen Sie bis zu 4 Dimensionen (Kunde, Projekt, Cluster, Position …), für die Spalten eine (meist den Monat) sowie Kennzahlen und Filter. Die Tabelle wird sofort neu berechnet. Eine gespeicherte Tabelle steht allen Benutzern zur Verfügung; CSV-Export öffnet sich in Excel (Semikolon als Trennzeichen).
Abrechnung
Monatliche Vorlagen für die Rechnungsstellung. Im Reiter Vorlagen legen Sie Zeilengruppierung, Aufschlag, Rabatt und MwSt. fest, unter Rechnungsdaten die Firmennummer (IČO), Adresse und den Vertrag des Kunden. Die Vorlagen erzeugen Sie für den ganzen Monat auf einmal; ein Entwurf kann neu erzeugt werden, eine genehmigte Vorlage ist eingefroren. Status: Entwurf → genehmigt → versendet, eine Stornierung ist jederzeit möglich.
Preisliste
Finanzen → Service-Preisliste. Versionen der Preisliste (Entwurf, gültig, Archiv) mit Einheitspreisen nach Abschnitten: Infrastruktur, virtuelle Maschinen nach Plattform (VMware vSphere, Azure Stack Hub, OpenShift Virtualization – vCPU, Arbeitsspeicher, Disk), Betriebssysteme (Windows Server, RHEL, SUSE, Ubuntu), Standardserver Windows und Linux, Supportstufen und Betriebsservices, Anforderungserfüllung (Verknüpfung zum Katalog) und Umsetzung von Changes (Change-Typ, Change-Modell). Preise bearbeitet eine Rolle mit der Berechtigung rate.manage; der Rechner für virtuelle Server vergleicht Plattformen. Jede Kostenzeile trägt einen Verweis auf die Version der Preisliste, sodass immer nachvollziehbar ist, zu welchem Preis sie bewertet wurde.
Asset-Register
Asset-Datensätze, verknüpft mit Konfigurationselementen: Kauf, Wareneingang, Rechnungen, Inbetriebnahme, Abschreibungen, Kostenstellen, Ersatzteillager und Übergabeprotokolle. Ein abgeschlossener Change zur Hardware-Installation nimmt den Datensatz in Betrieb; die Ausmusterung berücksichtigt gebuchte Abschreibungen.
Softwarelizenzen
Berechtigungen aus Lizenzverträgen nach Hersteller und Produkt, Zuweisung von Lizenzen zu Servern, Datenbanken und Benutzern sowie Abgleich mit den in der CMDB gefundenen Installationen. Der Verbrauch ist der höhere Wert aus zugewiesenen Lizenzen und gefundenen Installationen; ein Verbrauch über der Berechtigung wird hervorgehoben.
Lieferanten und Serviceverträge
Finanzen → Lieferanten und Verträge (Serviceverträge und Lieferanten). Ein Lieferant hat Hotline, Support-Portal, Kundennummer und Kontakte mit Eskalationsstufe (Hotline, 1. und 2. Eskalation, Leitung). Ein Vertrag (Support-, Wartungs-, Abonnement- oder erweiterter Garantievertrag) hat Laufzeit, Kündigungsfrist, automatische Verlängerung, Vorwarntage, Preis und Abrechnung, Kunde und Vertragsverantwortlichen. Supportstufen sind die SLAs des Lieferanten: Arbeitszeiten des Lieferanten, Reaktions- und Reparaturfrist, Techniker vor Ort. Abgedeckte Geräte sind Vertragszeilen – Elemente aus der CMDB mit eigener Stufe, Seriennummer, Zeitraum und gegebenenfalls Preis (sonst wird der Vertragspreis aufgeteilt). Dokumente (Verträge, Nachträge, Bedingungen, max. 10 MB) werden in der Datenbank gespeichert. Täglich wird das Laufzeitende überwacht: Hinweis an den Vertragsverantwortlichen, das Team und die Rolle Vertragsadministrator beim ersten überschrittenen Schwellenwert, nach Ablauf die Meldung „beendet“, automatisch verlängerte Verträge werden verlängert. Im Incident findet die Karte Lieferant den gültigen Support des Elements oder der Hardware, auf der es läuft; An Lieferanten melden (oder der Übergang in den Zustand Wartet auf Lieferanten) startet die Fristen des Lieferanten, Lieferant hat reagiert / Behoben schließt sie. Die Vertragsübersicht zeigt auslaufende Verträge mit dem letzten Kündigungstag, die Supportabdeckung der Hardware, Hardware ohne Support, Jahreskosten nach Lieferant und Kunde und die SLA-Erfüllung der Lieferanten. Verwaltet vom Vertragsadministrator (contract.manage); lesen können auch Incident Manager und Configuration Manager (contract.read).
Verwaltung
Integrationen, Personen und Zugriffe, Anwendungseinstellungen
Verbindungen
Mandanten und Konten, aus denen Daten erfasst werden: Azure, Azure Stack Hub, AWS, Google Cloud, Oracle Cloud, OpenShift und Rechenzentrum. Gespeichert werden nur Kennungen und Verweise auf den Tresor (kv://, vault:// …), nie Passwörter oder Schlüssel – die Anwendung lehnt deren Speicherung ab.
Import und API
Hochladen von FOCUS-Dateien (CSV/JSON) und REST-API-Dokumentation für Sammelskripte, Monitoring (Incidents) und Integrationen. Ein wiederholter Import derselben Quelle für denselben Monat ersetzt die vorherigen Daten und dupliziert sie nicht. Zeilen in Fremdwährung werden mit dem Kurs der Tschechischen Nationalbank vom ersten Tag des Zeitraums in CZK umgerechnet. Einträge erfordern einen Administrator oder ein API-Token.
Benachrichtigungen
Nachrichten per E-Mail (Resend oder SendGrid) und in Slack (Incoming Webhook in einen Kanal). Regel = Datensatz (Incident, Anforderung, Change, Konfigurationselement) + Ereignis (Anlage, Zustandswechsel, Zuweisung, Kommentar, Genehmigungsanfrage, Entscheidung, drohende und verletzte SLAs) + Bedingungen (Priorität, schwerer Incident, Zielzustand) + Vorlage + Kanäle + Empfänger (Bearbeiter, Lösungsteam, Melder, Antragsteller, Genehmigende, verantwortliches Team, Rolleninhaber, Team, Benutzer, beliebige Adresse). Die Vorlage hat einen Betreff und einen Text in einem Rich-Text-Editor (fett, Überschriften, Listen, Zitate, Links, HTML-Quelltext) und Parameter {{incident.id}}, {{incident.priority_name}}, {{transition.to}} …, die per Schaltfläche aus dem rechten Bereich eingefügt werden; die Werte werden aus dem Datensatz befüllt und maskiert. Die Vorschau zeigt E-Mail und Slack mit Beispieldaten oder einem gewählten Datensatz; ein Testversand prüft den Kanal. Ein Kanal enthält nur einen Verweis auf ein Worker-Secret (env:RESEND_API_KEY, env:SLACK_WEBHOOK_PROVOZ …), die Anwendung speichert keine Schlüssel oder Webhooks. SLAs werden alle 5 Minuten geprüft (Benachrichtigungen 30 Minuten vor Fristablauf und nach der Verletzung, jeweils nur einmal). Mit Demodaten werden Nachrichten im Standardzustand nur protokolliert, Adressen in Testdomänen (.example) werden nie zugestellt. Der Reiter Gesendet zeigt ein Zustellprotokoll einschließlich Fehlern und übersprungener Nachrichten.
Zugriffe und Verantwortlichkeiten
Rollen des IT-Personals (Plattformadministrator, Konfigurationsmanager, Service-Verantwortlicher, Anwendungsverantwortlicher, Infrastrukturspezialist, Change Manager, Incident Manager, Service Desk, Auditor, Servicekonto für Discovery) mit Geltungsbereich für einen Kunden, ein Team (aus der Teamverwaltung) oder ein bestimmtes Element. Die RACI-Matrix legt fest, wer bei Konfigurationsdaten und Changes ausführt, genehmigt, konsultiert und informiert wird; die Anwendung stellt sicher, dass die Rollen R und A die entsprechenden Berechtigungen haben. Servicekonten erhalten API-Tokens; der Audit-Trail erfasst jeden Eintrag.
Workflow
Zustände und Übergänge für Incidents, Anforderungen, Changes und Konfigurationselemente. Jeder Zustand gehört zu einem Systemzustand, auf dem die Logik der Anwendung beruht (SLA, Genehmigungen, Change-Schritte, Ausmusterung von Elementen) – ein eigener Zustand wie „Wartet auf Lieferanten“ verhält sich wie Angehalten, und die SLA-Zeit steht still. Übergangsmatrix: Zeile = Ausgangszustand, Spalte = Zielzustand; ein Klick auf eine Zelle fügt einen Übergang hinzu oder bearbeitet ihn. Für einen Übergang legen Sie die Beschriftung der Schaltfläche fest, die Berechtigungen (ausgewertet im Bereich Team, Kunde oder Service), ob Melder / Antragsteller / Antragsteller des Change ihn nutzen dürfen, ob es ein Genehmigungsschritt ist (Anforderungen), Pflichtkommentar und Pflichtfelder (Lösung, Bearbeiter) sowie das Aussehen der Schaltfläche. In die Zustände Genehmigung ausstehend, genehmigt und abgelehnt bei Changes führt nur die Anwendung (durch Absenden und Entscheidungen der Genehmigenden). Systemzustände lassen sich nicht löschen, nur umbenennen; einen eigenen Zustand, den ein Datensatz verwendet, deaktivieren Sie. Die Konfiguration gilt gemeinsam für Produktiv- und Demodaten. Bearbeitet von Plattformadministrator und Konfigurationsmanager (workflow.manage).
KI-Assistent
Ein Sprachmodell hilft überall dort, wo mit Text gearbeitet wird – es schlägt immer nur vor, entscheiden tut ein Mensch. Zusammenfassung einer Situation (Event Management): was passiert, wahrscheinliche Ursache mit dem CMDB-Element, empfohlene Schritte und Konfidenz; entsteht automatisch für Situationen ab einem eingestellten Schweregrad, sonst per Schaltfläche. Vorausfüllen eines Incidents: beim Anlegen eines Incidents aus einer Situation die Schaltfläche „Mit KI vorschlagen“, in Incident melden das Feld „Beschreiben Sie das Problem in eigenen Worten“ – Element, Service und Team werden nur aus der CMDB gewählt, und die Priorität berechnet immer die Anwendung aus Auswirkung und Dringlichkeit. Was beim letzten Mal geholfen hat: ähnliche gelöste Incidents nach Bedeutung des Textes und Rat aus ihrer Lösung. Kommunikation: Entwurf einer Zwischeninformation für Kunden und eines Abschlussberichts – bearbeiten, kopieren oder als Kommentar speichern, nichts wird automatisch versendet. Change-Prüfung: regelbasierte Prüfungen (Beschreibung, Rollback, Risiko vs. Ausfall eines kritischen Service, Verifikation nach dem Change, Kommunikation) und eine Zusammenfassung für Genehmigende. Personenbezogene Daten und Geheimnisse werden vor dem Senden maskiert, jeder Vorschlag wird protokolliert (Verwaltung → KI-Assistent → Letzte Vorschläge), und die Bewertung „Hat das geholfen?“ misst die Qualität. Bei Kunden mit der Richtlinie „nur On-Premises“ oder „ohne KI“ werden keine Daten an das Cloud-Modell gesendet. Ohne Modell oder nach Ausschöpfen des Tageslimits wird ein deterministischer Vorschlag angezeigt. Verwaltet vom Plattformadministrator (ai.manage): Schalter, Limit, versionierte Prompts, Kundenrichtlinie.
Mehr
Betriebsübersicht
Startbildschirm für das Management. Kacheln: Business-Services im Betrieb, Services ohne Single Point of Failure, Anzahl der Server, Server mit nicht unterstütztem Betriebssystem, Changes zur Genehmigung und Kosten des letzten Monats – jede führt zum Detail. Darunter der Status der Business-Services (Kritikalität, SLA, Status, Ausfallsicherheit, nächste Ausfallzeit), Infrastruktur (Power, Virtualisierung, Cloud, Container, Anwendungen, Netzwerk, SAN, Backup sowie jedes Disk-Array mit Belegung, Anzahl der Volumes, HA- und DR-Replikation und FC-Ports), Redundanz (Server an zwei Netzwerkelementen, SAN in beiden Fabrics, LPAR auf einem VIOS-Paar, produktive Datastores auf gespiegelten Volumes, produktive Server mit Backup, Services ohne SPOF), Lebenszyklus und Patching, Changes und Ausfallzeiten (einschließlich überfälliger Changes und Change Freeze), Discovery und Datenqualität sowie Kosten. Auf dem Telefon werden Services als Karten angezeigt.