Processes

Monitoring (Zabbix, Prometheus, Checkmk, Grafana, Dynatrace, generic API) sends an event. The application pairs it with a configuration item by host name, IP, serial number or entity ID and adds the service, customer and team. Filtering rules discard noise.

Repeated events of the same problem (same fingerprint) form one alert and only increase its counter. An OK message resolves the alert. An ongoing change on the item suppresses the alert so it does not wake the operator.

Alerts are merged into situations by an outage simulation in the CMDB: the cause is only an item whose outage really explains the alerts (hypervisor failure → its VMs and applications). Explained alerts are symptoms – no notifications, resolved with the cause. If the common carrier of several alerting items is silent, the application infers it from the topology. Further grouping is by service and time or related change. The operator acknowledges the situation, assigns it to a team, silences it or creates an incident from it.

An unplanned interruption of a service. Impact and team are calculated from the CMDB (from the real impact of the outage – loss of redundancy means low impact), priority from impact and urgency, deadlines from the SLA. Alerts stay linked to the incident – resolving them suggests resolving the incident. For P1/P2 a war room can be opened.

The cause of recurring or major incidents. It is raised from an incident, a major incident review, a post-change review or the daily check for recurring incidents. A known error carries a workaround.

The permanent fix is made by a change raised from the problem or linked to it (an emergency change is raised from the incident). One change can resolve several incidents and problems. After successful completion a problem with a documented root cause moves to Resolved and linked incidents are asked to verify; a failed change returns the problem to analysis.

For 24 h after a change completes the application watches alerts on its items. If any appear, the post-implementation review is required and you can create an incident from the change detail that records the change as its cause – and the incident can lead to another problem.

The user picks a catalogue item (new server, capacity, firewall, access…), fills in the form and the request goes through approval according to the item rules.

An incident that is not a fault but a service request is converted to a request (and vice versa). The new record takes over the description, item and reporter, the deadline runs from the conversion and the original record is cancelled with a link.

The resolver team takes the request and ticks off the fulfilment steps within the deadline set by the catalogue and business hours.

An item that changes infrastructure is linked to a change model. For a standard model the application creates and schedules the change itself, without approval. The requester is notified when it is scheduled, started and completed; the request can be fulfilled only after the change is completed.

A completed change puts the target items into service (or retires them); discovery confirms the new state.

CentOps pulls findings from Tenable Vulnerability Management itself via the export API (first run open findings, later only changes including fixed ones). Results from Nessus and Tenable Security Center are uploaded as a .nessus file. Findings with a CVE go to patch management.

A scanned device is matched in this order: saved decision → FQDN (OS hostname + domain) → MAC address → short name + domain → IP, but only for network devices. Only an unambiguous match without contradictions is automatic; a different item by another attribute, a mismatching OS, a different domain or a retired item mean conflict or review.

Confirm a device under review, assign it to another item or exclude it; the decision also applies to later scans. Unmatched devices are seen by the scanner in the network but unknown to the CMDB.

Findings of matched devices get a remediation due date according to the policy (KEV, CVSS) and enter the patching plan. A finding the scanner no longer reports is closed as fixed.

Discovery from vCenter, HMC, OpenShift, clouds and monitoring (Dynatrace) creates and updates items and relationships. Manual changes to VM and partition placement are not allowed – the source is the truth.

New items without an ownership team from the same source run are collected into one change.

A standard change without approval assigned to the configuration manager: find the owner, add the team and service, verify the classification and close. You will find it in My work.

An item with an owner counts towards incident and change impact, costs and data quality checks.