Processus

La supervision (Zabbix, Prometheus, Checkmk, Grafana, Dynatrace, API générique) envoie un événement. L’application l’associe à un élément de configuration par nom d’hôte, IP, numéro de série ou ID d’entité et ajoute le service, le client et l’équipe. Les règles de filtrage écartent le bruit.

Les événements répétés d’un même problème (même empreinte) forment une alerte et n’augmentent que son compteur. Un message OK résout l’alerte. Un changement en cours sur l’élément supprime l’alerte pour qu’elle ne réveille pas l’opérateur.

Les alertes sont regroupées en situations selon une simulation de panne dans la CMDB : la cause n’est qu’un élément dont la panne explique réellement les alertes (panne d’hyperviseur → ses VM et applications). Les alertes expliquées sont des symptômes – sans notification, résolues avec la cause. Si le support commun de plusieurs éléments en alerte est silencieux, l’application le déduit de la topologie. Le regroupement se fait ensuite par service et période ou par changement associé. L’opérateur confirme la situation, l’attribue à une équipe, la met en sourdine ou en crée un incident.

Une interruption non planifiée d’un service. L’impact et l’équipe sont calculés à partir de la CMDB (selon l’impact réel de la panne – une perte de redondance signifie un impact faible), la priorité à partir de l’impact et de l’urgence, les échéances à partir du SLA. Les alertes restent liées à l’incident – leur résolution propose de résoudre l’incident. Pour P1/P2, une war room peut être ouverte.

La cause d’incidents récurrents ou majeurs. Il naît d’un incident, de l’analyse d’un incident majeur, d’une revue après changement ou du contrôle quotidien des incidents récurrents. Une erreur connue comporte un contournement.

La correction définitive est réalisée par un changement créé depuis le problème ou lié à celui-ci (un changement urgent se crée depuis l’incident). Un changement peut résoudre plusieurs incidents et problèmes. Après une réussite, un problème dont la cause est documentée passe à Résolu et les incidents liés sont invités à vérifier ; un changement en échec renvoie le problème en analyse.

Pendant 24 h après la fin d’un changement, l’application surveille les alertes sur ses éléments. S’il en apparaît, la revue post-implémentation est obligatoire et vous pouvez créer depuis la fiche du changement un incident qui l’enregistre comme cause – et cet incident peut mener à un nouveau problème.

L’utilisateur choisit un élément du catalogue (nouveau serveur, capacité, pare-feu, accès…), remplit le formulaire et la demande passe par l’approbation selon les règles de l’élément.

Un incident qui n’est pas une panne mais une demande de service est converti en demande (et inversement). Le nouvel enregistrement reprend la description, l’élément et le déclarant, le délai court à partir de la conversion et l’enregistrement d’origine est annulé avec un lien.

L’équipe de résolution prend en charge la demande et coche les étapes de traitement dans le délai fixé par le catalogue et les heures ouvrées.

Un élément qui modifie l’infrastructure est lié à un modèle de changement. Pour un modèle standard, l’application crée et planifie elle-même le changement, sans approbation. Le demandeur est informé quand il est planifié, démarré et terminé ; la demande ne peut être traitée qu’une fois le changement terminé.

Un changement terminé met les éléments cibles en service (ou les retire) ; la découverte confirme le nouvel état.

CentOps récupère lui-même les vulnérabilités de Tenable Vulnerability Management via l’API d’export (au premier passage les vulnérabilités ouvertes, ensuite seulement les changements, y compris les corrigées). Les résultats de Nessus et Tenable Security Center sont chargés sous forme de fichier .nessus. Les vulnérabilités avec CVE passent dans la gestion des correctifs.

Un équipement scanné est associé dans cet ordre : décision enregistrée → FQDN (nom d’hôte + domaine de l’OS) → adresse MAC → nom court + domaine → IP, cette dernière uniquement pour les équipements réseau. Seule une correspondance univoque sans contradiction est automatique ; un autre élément selon un autre attribut, un OS différent, un autre domaine ou un élément retiré signifient un conflit ou une revue.

Vous confirmez un équipement en revue, l’associez à un autre élément ou l’excluez ; la décision s’applique aussi aux scans suivants. Les équipements non associés sont vus par le scanner sur le réseau mais inconnus de la CMDB.

Les vulnérabilités des équipements associés reçoivent une échéance de remédiation selon la politique (KEV, CVSS) et entrent dans le plan de correctifs. Une vulnérabilité que le scanner ne signale plus est clôturée comme corrigée.

La découverte depuis vCenter, HMC, OpenShift, les clouds et la supervision (Dynatrace) crée et met à jour les éléments et les relations. Les modifications manuelles de l’emplacement des VM et des partitions ne sont pas autorisées – la source fait foi.

Les nouveaux éléments sans équipe responsable issus d’une même exécution d’une source sont regroupés dans un seul changement.

Un changement standard sans approbation attribué au gestionnaire de configuration : trouver le responsable, ajouter l’équipe et le service, vérifier le classement et clôturer. Vous le trouverez dans Mon travail.

Un élément avec un responsable est pris en compte dans l’impact des incidents et des changements, dans les coûts et dans le contrôle de la qualité des données.