Prozesse

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.

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.

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.

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.

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.

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.

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.

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.

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.

Das Lösungsteam übernimmt die Anforderung und hakt die Erfüllungsschritte innerhalb der vom Katalog und den Arbeitszeiten vorgegebenen Frist ab.

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.

Ein abgeschlossener Change nimmt die Zielelemente in Betrieb (oder mustert sie aus); die Discovery bestätigt den neuen Zustand.

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.

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.

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.

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.

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.

Neue Elemente ohne verantwortliches Team aus demselben Lauf einer Quelle werden in einem Change gesammelt.

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.

Ein Element mit Verantwortlichen zählt zur Auswirkung von Incidents und Changes, zu den Kosten und zur Prüfung der Datenqualität.