# Prozesse · CentOps-Dokumentation > Wie Events, Incidents, Problems, Requests und Changes zusammenhängen und welche Zustände jeder Datensatz durchläuft. URL: https://centops.eywo.digital/de/docs/processes/ Language: de Last updated: 2026-10-30 Dokumentation # Prozesse Wie Events, Incidents, Problems, Requests und Changes zusammenhängen und welche Zustände jeder Datensatz durchläuft. 1. [Überblick](https://centops.eywo.digital/de/docs/) 2. [Module](https://centops.eywo.digital/de/docs/modules/) 3. [Prozesse](https://centops.eywo.digital/de/docs/processes/) 4. [CMDB-Modell](https://centops.eywo.digital/de/docs/cmdb-model/) 5. [Begriffe und FAQ](https://centops.eywo.digital/de/docs/terms/) 6. [Datenblatt](https://centops.eywo.digital/de/docs/datasheet/) ## Zusammenhang der Prozesse ### Erkennen und wiederherstellen Vom Monitoring-Signal zur dauerhaften Korrektur 1. **Event** Das Monitoring (Zabbix, Prometheus, Checkmk, Grafana, Dynatrace, generische API) sendet ein Event. Die Anwendung ordnet es anhand von Hostname, IP, Seriennummer oder Entitäts-ID einem Konfigurationselement zu und ergänzt Service, Kunde und Team. Filterregeln verwerfen Rauschen. 2. **Alert** Wiederholte Events desselben Problems (gleicher Fingerprint) bilden einen Alert und erhöhen nur dessen Zähler. Eine OK-Meldung löst den Alert auf. Ein laufender Change am Element unterdrückt den Alert, damit er den Operator nicht weckt. 3. **Situationen** Alerts werden anhand einer Ausfallsimulation in der CMDB zu Situationen zusammengefasst: Ursache ist nur ein Element, dessen Ausfall die Alerts tatsächlich erklärt (Hypervisor-Ausfall → seine VMs und Anwendungen). Erklärte Alerts sind Symptome – ohne Benachrichtigungen, aufgelöst zusammen mit der Ursache. Ist der gemeinsame Träger mehrerer alarmierender Elemente still, leitet die Anwendung ihn aus der Topologie ab. Weiter wird nach Service und Zeit oder zugehörigem Change gruppiert. Der Operator bestätigt die Situation, weist sie einem Team zu, schaltet sie stumm oder legt daraus einen Incident an. 4. **Incident** Eine ungeplante Unterbrechung eines Service. Auswirkung und Team werden aus der CMDB berechnet (aus der tatsächlichen Auswirkung des Ausfalls – Verlust der Redundanz bedeutet geringe Auswirkung), die Priorität aus Auswirkung und Dringlichkeit, die Fristen aus dem SLA. Die Alerts bleiben mit dem Incident verknüpft – ihre Auflösung schlägt das Lösen des Incidents vor. Bei P1/P2 lässt sich ein War Room öffnen. 5. **Problem** 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. Ein bekannter Fehler trägt einen Workaround. 6. **Change** Die dauerhafte Korrektur erfolgt durch einen Change, der aus dem Problem angelegt oder mit ihm verknüpft wird (einen Notfall-Change legen Sie aus dem Incident an). Ein Change kann mehrere Incidents und Problems lösen. Nach erfolgreichem Abschluss geht ein Problem mit dokumentierter Ursache auf Gelöst, und die verknüpften Incidents erhalten die Aufforderung zur Prüfung; ein fehlgeschlagener Change schickt das Problem zurück in die Analyse. 7. **Prüfung nach dem Change** 24 Stunden nach Abschluss eines Change überwacht die Anwendung Alerts auf seinen Elementen. Treten welche auf, ist das Post Implementation Review Pflicht, und aus dem Change-Detail können Sie einen Incident anlegen, der den Change als Ursache erfasst – aus dem Incident kann wieder ein Problem entstehen. ### Anfordern und erfüllen Von der Benutzeranforderung zur fertigen Infrastruktur 1. **Anforderung** Der Benutzer wählt einen Katalogeintrag (neuer Server, Kapazität, Firewall, Zugriff …), füllt das Formular aus, und die Anforderung durchläuft die Genehmigung nach den Regeln des Eintrags. 2. **Umwandlung Incident ↔ Anforderung** Ein Incident, der keine Störung, sondern eine Serviceanfrage ist, wird in eine Anforderung umgewandelt (und umgekehrt). Der neue Datensatz übernimmt Beschreibung, Element und Melder, die Frist läuft ab der Umwandlung, und der ursprüngliche Datensatz wird mit Verweis storniert. 3. **Erfüllung** Das Lösungsteam übernimmt die Anforderung und hakt die Erfüllungsschritte innerhalb der vom Katalog und den Arbeitszeiten vorgegebenen Frist ab. 4. **Change** Ein Eintrag, der die Infrastruktur ändert, ist mit einem Change-Modell verknüpft. Bei einem Standardmodell legt die Anwendung den Change selbst an und plant ihn, ohne Genehmigung. Der Antragsteller wird benachrichtigt, wenn er geplant, gestartet und abgeschlossen wird; die Anforderung lässt sich erst nach Abschluss des Change erfüllen. 5. **Konfigurationselement** Ein abgeschlossener Change nimmt die Zielelemente in Betrieb (oder mustert sie aus); die Discovery bestätigt den neuen Zustand. ### Schwachstellen aus Scannern Tenable / Nessus → CMDB → Patch Management 1. **Scan** CentOps holt die Befunde aus Tenable Vulnerability Management selbst über die Export-API ab (beim ersten Lauf offene Befunde, danach nur Änderungen einschließlich behobener). Ergebnisse aus Nessus und Tenable Security Center werden als .nessus-Datei hochgeladen. Befunde mit CVE gehen ins Patch Management. 2. **Abgleich mit der CMDB** Ein gescanntes Gerät wird in dieser Reihenfolge zugeordnet: gespeicherte Entscheidung → FQDN (Hostname + Domäne des Betriebssystems) → MAC-Adresse → Kurzname + Domäne → IP, Letzteres nur bei Netzwerkgeräten. Automatisch ist nur eine eindeutige Übereinstimmung ohne Widersprüche; ein anderes Element nach einem anderen Merkmal, ein abweichendes Betriebssystem, eine andere Domäne oder ein ausgemustertes Element bedeuten Konflikt oder Prüfung. 3. **Prüfung** Ein Gerät zur Prüfung bestätigen Sie, ordnen es einem anderen Element zu oder schließen es aus; die Entscheidung gilt auch für weitere Scans. Nicht zugeordnete Geräte sieht der Scanner im Netzwerk, die CMDB kennt sie nicht. 4. **Patch Management** Befunde zugeordneter Geräte erhalten eine Behebungsfrist nach der Richtlinie (KEV, CVSS) und gehen in den Patch-Plan ein. Ein Befund, den der Scanner nicht mehr meldet, wird als behoben geschlossen. ### Konfiguration aus Quellen Wie die CMDB befüllt und gepflegt wird 1. **Discovery und Monitoring** Die Discovery aus vCenter, HMC, OpenShift, Clouds und Monitoring (Dynatrace) legt Elemente und Beziehungen an und aktualisiert sie. Manuelle Änderungen an der Platzierung von VMs und Partitionen sind nicht zulässig – die Quelle ist die Wahrheit. 2. **Element ohne Verantwortliche** Neue Elemente ohne verantwortliches Team aus demselben Lauf einer Quelle werden in einem Change gesammelt. 3. **Change „Verantwortliche ergänzen“** Ein Standard-Change ohne Genehmigung, zugewiesen an den Konfigurationsmanager: Verantwortliche ermitteln, Team und Service ergänzen, Einordnung prüfen und schließen. Sie finden ihn unter Meine Arbeit. 4. **Vollständiges Element** Ein Element mit Verantwortlichen zählt zur Auswirkung von Incidents und Changes, zu den Kosten und zur Prüfung der Datenqualität. ## Lebenszyklen der Datensätze ### Incidents Ein Incident läuft von der Meldung über Zuweisung und Bearbeitung bis zur Lösung und zum Abschluss. Das Anhalten stoppt die SLA-Uhr. Neu→Zugewiesen→In Bearbeitung→Gelöst→Geschlossen Angehalten · hält die SLA-Uhr anNebenzustand · In BearbeitungWartet auf LieferantenNebenzustand · In BearbeitungStorniertEndzustand Übergänge (16) - Neu → Zugewiesen · Zuweisen - Neu → In Bearbeitung · Übernehmen und bearbeiten - Zugewiesen → In Bearbeitung · Übernehmen und bearbeiten - Angehalten → In Bearbeitung · Fortsetzen - Wartet auf Lieferanten → In Bearbeitung · Lieferant hat reagiert - Zugewiesen → Gelöst · Lösen - In Bearbeitung → Gelöst · Lösen - Angehalten → Gelöst · Lösen - Wartet auf Lieferanten → Gelöst · Lösen - In Bearbeitung → Angehalten · Anhalten - In Bearbeitung → Wartet auf Lieferanten · Wartet auf Lieferanten - In Bearbeitung → Zugewiesen · Zurück in die Warteschlange - Gelöst → Geschlossen · Schließen - Gelöst → In Bearbeitung · Wieder öffnen - Neu → Storniert · Stornieren - Zugewiesen → Storniert · Stornieren ### Anforderungen Eine Anforderung wird eingereicht, nach dem Katalog genehmigt, erfüllt und vom Antragsteller geschlossen. Eingereicht→Wartet auf Genehmigung→In Bearbeitung→Erfüllt→Geschlossen GenehmigtNebenzustand · Wartet auf GenehmigungAbgelehntEndzustandStorniertEndzustand Übergänge (10) - Wartet auf Genehmigung → In Bearbeitung · Genehmigen - Wartet auf Genehmigung → Abgelehnt · Ablehnen - Genehmigt → In Bearbeitung · Übernehmen - In Bearbeitung → Erfüllt · Erfüllt - Erfüllt → Geschlossen · Schließen - Erfüllt → In Bearbeitung · Zurück in die Erfüllung - Wartet auf Genehmigung → Storniert · Anforderung stornieren - Eingereicht → Storniert · Anforderung stornieren - Genehmigt → Storniert · Anforderung stornieren - In Bearbeitung → Storniert · Anforderung stornieren ### Problems Das Problem wird analysiert, aus der Ursache wird ein bekannter Fehler mit Workaround, und die Korrektur erfolgt durch einen Change – nach dessen erfolgreichem Abschluss geht das Problem von selbst auf Gelöst. Neu→Ursachenanalyse→Gelöst→Geschlossen Bekannter FehlerNebenzustand · UrsachenanalyseStorniertEndzustand Übergänge (10) - Neu → Ursachenanalyse · Analyse starten - Ursachenanalyse → Bekannter Fehler · Bekannten Fehler veröffentlichen - Ursachenanalyse → Gelöst · Lösen - Bekannter Fehler → Gelöst · Lösen - Bekannter Fehler → Ursachenanalyse · Zurück in die Analyse - Gelöst → Geschlossen · Schließen - Gelöst → Ursachenanalyse · Wieder öffnen - Neu → Storniert · Stornieren - Ursachenanalyse → Storniert · Stornieren - Bekannter Fehler → Storniert · Stornieren ### Changes Ein Change wird entworfen, zur Genehmigung eingereicht, in ein Wartungsfenster geplant, umgesetzt und ausgewertet. In die Genehmigungszustände führt ihn nur die Anwendung. Entwurf→Wartet auf Genehmigung→Genehmigt→In Umsetzung→Erfüllt Nicht erfolgreichNebenzustand · In UmsetzungAbgelehntEndzustandStorniertEndzustand Übergänge (7) - Genehmigt → In Umsetzung · Arbeiten beginnen - In Umsetzung → Erfüllt · Erfüllt - In Umsetzung → Nicht erfolgreich · Nicht erfolgreich - Entwurf → Storniert · Change stornieren - Wartet auf Genehmigung → Storniert · Change stornieren - Abgelehnt → Storniert · Change stornieren - Genehmigt → Storniert · Change stornieren ### Konfigurationselemente Ein Konfigurationselement ist geplant, in Betrieb, in Wartung (während eines Change) oder ausgemustert. Bei gesteuerten Klassen ändert nur ein Change den Zustand. Geplant→In Betrieb WartungNebenzustand · In BetriebAusgemustertEndzustand Übergänge (7) - Geplant → In Betrieb · In Betrieb nehmen - In Betrieb → Wartung · Wartung - Wartung → In Betrieb · Zurück in Betrieb - Ausgemustert → Geplant · Wiederherstellen (erneut planen) - Geplant → Ausgemustert · Ausmustern - In Betrieb → Ausgemustert · Ausmustern - Wartung → Ausgemustert · Ausmustern ### Artefakte der Unternehmensarchitektur Ein Artefakt der Unternehmensarchitektur durchläuft Entwurf, Genehmigung und Gültigkeit bis zur Ausmusterung. Entwurf→Genehmigt→Im Aufbau→In Betrieb→Auslaufend AusgemustertEndzustandAbgelehntEndzustand Übergänge (10) - Entwurf → Genehmigt · Genehmigen - Genehmigt → Entwurf · Zurück zum Entwurf - Genehmigt → Im Aufbau · Aufbau beginnen - Genehmigt → In Betrieb · In Betrieb nehmen - Im Aufbau → In Betrieb · In Betrieb nehmen - In Betrieb → Auslaufend · Auslauf beginnen - Auslaufend → In Betrieb · Auslauf abbrechen - Auslaufend → Ausgemustert · Ausmustern - Abgelehnt → Entwurf · Erneut vorschlagen - Entwurf → Abgelehnt · Ablehnen Prozesslandkarte und CMDB-Modell werden aus dem aktuellen Stand der Anwendung erzeugt · aktualisiert 30\. Oktober 2026