Utilisation du modèle de données flexible
Résilience opérationnelleÀ partir de la version 21.0.x, le modèle de données flexible améliore les mesures de résilience opérationnelle en améliorant la visualisation des données et le flux des services dépendants. Il prend également en charge plusieurs tableaux de bord avec des informations sur les indicateurs rouges, l’importance du service d’entreprise et la tolérance d’impact.
Résilience opérationnelleÀ partir de la version 20.1.x, les configurations de nœuds principales, prises en charge par le Cadre de travail des relations entre données, ont été introduites pour Résilience opérationnelle définir des chaînes de déploiement de dépendances. Les configurations de nœuds principales, la source étant la CMDB OpRes, sont fournies avec le système de base. Pour plus d’informations sur les configurations de nœud principales, la création d’une nouvelle configuration de nœud principale ou la mise à jour d’une configuration de nœud principale existante, reportez-vous à la section Configurations de nœuds principales : un composant du Cadre de travail des relations entre données.
Dans le modèle de données précédent, la table d’objets CSDM [sn_oper_res_profile] stockait l’ensemble de la chaîne de dépendance, y compris toutes les combinaisons possibles, ce qui rendait la récupération des données fastidieuse et la maintenance difficile. Cette approche a été dépréciée au profit d’un modèle plus efficace.
Principales fonctionnalités du modèle de données flexible
Le modèle de données flexible offre plusieurs fonctionnalités clés qui améliorent les mesures de résilience opérationnelle.
- Visualisation améliorée des données : les modules Services, Services d’entreprise, Offres, Processus d’entreprise et Services d’application présentent désormais une mise en page verticale, remplaçant les onglets horizontaux traditionnels et améliorant la navigation dans le Espace de travail de résilience opérationnelle. Vous pouvez afficher l’ensemble des mesures de résilience d’un objet, tel qu’un processus d’entreprise ou un service d’entreprise, à partir de l’onglet Vue d’ensemble de la disposition verticale.
Vous pouvez ensuite afficher les données en aval et divers tableaux de bord en fonction de la classe supérieure sélectionnée. L’exemple suivant montre les contrôles principaux à renforcer pour le service d’entreprise.
La sélection du graphique affiche des informations détaillées sur les enregistrements de dépendance, les contrôles connexes et les objectifs de contrôle.
- Navigation simplifiée : vous pouvez accéder directement aux listes et mesures connexes d’un service d’entreprise spécifique, telles que ses offres de service, ses processus de gestion, ses services d’application, ses dépendances, ses incidents et ses mesures, à partir de la mise en page verticale.
Mise en œuvre technique
Résilience opérationnelle Depuis la version 21.0.x, le modèle de données pour les configurations d’Operational Resilience a été optimisé. Désormais, chaque nœud d’une chaîne hiérarchique, comme un service d’entreprise ou une offre aux processus, est stocké séparément dans la table d’objets CSDM [sn_oper_res_profile] avec ses nœuds de classe et parents. Cela signifie que seuls les objets pertinents (par exemple, 500 entités sur 1 000) qui font partie des configurations de nœuds principales sont stockés, ce qui améliore l’efficacité de la gestion des données.
Le modèle de données flexible introduit avec Résilience opérationnelle la version 21.0.x fournit une base pour les tableaux de bord et suit le flux des services dépendants. Les données, y compris les indicateurs rouges par type, tels que les contrôles ayant échoué, les incidents et les pannes, et les mesures de service d’entreprise telles que le nombre d’indicateurs, l’importance et la tolérance d’impact, sont mises à jour dans le tableau de bord via les modifications apportées au modèle de données flexible.
Les données affichées dans l’exemple concernent des services d’entreprise tels que le service d’entreprise par nombre d’indicateurs rouges, le service d’entreprise par importance, le service d’entreprise par tolérance d’impact. Vous pouvez configurer la propriété pour désigner n’importe sn_oper_res.top_class_name quelle classe comme classe supérieure.
Configuration de la propriété sn_oper_res.top_class_name
Vous pouvez configurer la propriété de manière à désigner n’importe sn_oper_res.top_class_name quelle classe comme classe supérieure dans la vue de tableau de bord afin que n’importe quel nœud, tel qu’un service d’entreprise, un processus de gestion ou un service d’application, puisse être le nœud supérieur. Vous pouvez ensuite afficher les données en aval et divers tableaux de bord en fonction de la classe supérieure sélectionnée, comme le nombre de services d’application qui se trouvent sous un service d’entreprise. Cela vous permet de basculer entre différentes vues, telles que les services d’entreprise, les offres de service, les processus business ou les applications, sur le tableau de bord et d’afficher les données pertinentes en conséquence.
Par exemple, si les données sont affichées pour un service d’entreprise, vous pouvez modifier la classe principale en offres de service, processus business ou services d’application en configurant la sn_oper_res.top_class_name propriété. Vous pouvez ensuite remplacer la classe supérieure par un autre objet et le système affiche les données relatives à cette classe supérieure spécifique. Cette propriété ne s’applique qu’aux tableaux de bord et non aux formulaires de l’espace de travail. Pour en savoir plus sur les propriétés, consultez Configurer les Résilience opérationnelle propriétés.
L’exemple suivant montre que le nom de classe TOP est défini sur cmdb_ci_service_business.
Vous pouvez modifier la valeur de la propriété pour qu’elle représente une offre de service ou une application, le tableau de bord se remplit avec les données correspondantes. L’exemple suivant montre comment mettre à jour le nom de classe principale en « offre de service ».
En fonction du nom de la propriété mise à jour, les données relatives à l’offre de service s’affichent dans le tableau de Résilience opérationnelle bord, comme indiqué dans l’exemple.
Calcul et déploiement des indicateurs rouges
Lorsque la Calculate red flags for CSDM and dependencies tâche planifiée est exécutée, les données d’indicateur rouge sont renseignées dans le tableau de bord. Dans l’exemple suivant, le tableau de bord affiche une plage de 1 à 30 indicateurs rouges dans la section « Service d’entreprise par nombre d’indicateurs rouges ».
La sélection de la carte affiche une répartition détaillée pour le service d’entreprise. Il montre un total de 24 indicateurs rouges, dont 3 spécifiquement attribués au service « Cartes et paiements ». L’illustration suivante montre la fonctionnalité de déploiement, qui regroupe les indicateurs rouges pour les entités associées au service d’entreprise « Cartes et paiements » sélectionné, fournissant ainsi une vue hiérarchique des données.
La valeur « 24 » affichée dans la colonne Nombre total d’indicateurs rouges est la valeur cumulée des indicateurs rouges pour toutes les entités sous le service d’entreprise « Cartes et paiements ».
Table d’objets CSDM
- La colonne Objets impactés affiche les objets parents.
- La colonne Classes d’objets impactés affiche les classes.
- La colonne Nombre d’indicateurs rouges indique le nombre d’indicateurs rouges qui sont directement affectés à un nœud.
- La colonne Nombre total d’indicateurs rouges affiche le nombre total d’indicateurs rouges directement affectés à un nœud et à ses enfants, comme indiqué dans la table.
Les classes d’objets affichées dans la colonne Classe d’objet de l’exemple fournissent une représentation claire de diverses entités, y compris les applications et les processus d’entreprise. Ces données sont ensuite introduites dans le système à l’aide de scripts correctifs, ce qui garantit que les informations sont renseignées avec précision et à jour. En utilisant ces scripts, le système peut afficher et gérer efficacement les relations complexes entre les différentes classes d’objets.
Vous pouvez regrouper les objets en fonction de leurs classes d’objets. Ensuite, vous pouvez utiliser les classes d’objet pour les offres de service, la société principale, les processus business, etc.
Les objets impactés en amont d’une classe d’objets spécifique sont ajoutés à la colonne Objets impactés. Par exemple, le serveur d’applications Java FLX contient des objets impactés en amont tels que le processus bancaire numérique et le paiement entrant, qui sont ajoutés et affichés dans la colonne Objets impactés.
Ce processus commence par l’objet de niveau le plus bas et inclut le niveau au-dessus, remplissant les objets impactés. Les données sont ensuite directement intégrées dans les configurations de nœuds principales.
Configurations de nœuds principales
- Processus business pour les dépendances
- Service d’entreprise pour les dépendances
- OpRes avec en-tête CSDM
- Service (CMDB)
- Offre de service pour les dépendances
L’ensemble du flux, qui va d’un service d’entreprise à une offre de service, à un processus de gestion, puis à une application, est créé dans les configurations de nœud principales, puis les configurations sont mappées aux objets impactés.
Pour plus d’informations sur la configuration des configurations de nœud principales, reportez-vous à la section Configurer les configurations de nœuds principales.
Exécution des travaux planifiés
Deux travaux Update CSDM and other dependencies planifiés et Calculate red flags for CSDM and dependencies exécutés à intervalles réguliers renseignent les données dans la table d’objets CSDM [sn_oper_res_profile.list] et les indicateurs rouges. Pour plus d'informations, consultez Exécuter les travaux planifiés.
Toutes les configurations de nœud principales sont traitées en parallèle. Un événement distinct est déclenché pour chaque configuration de nœud principale, permettant un traitement parallèle. La configuration améliorée élimine le besoin de traitement séquentiel, ce qui améliore considérablement l’efficacité.
Une fois la Update CSDM and other dependencies tâche planifiée exécutée, les données sont extraites dans la table Objets CSDM. Les dépendances sont mises à jour pour les objets et sont affichées dans les modules.
Auparavant, parcourir des tables plusieurs-à-plusieurs pour trouver des enregistrements connexes prenait beaucoup de temps. Désormais, en stockant les objets impactés dans la table elle-même, vous pouvez récupérer directement les enregistrements connexes à partir d’une seule colonne, éliminant ainsi la nécessité de créer une hiérarchie récursive, améliorant ainsi considérablement l’efficacité.
Les dépendances sont d’abord extraites de la table Entité [sn_grc_profile] (plusieurs-à-plusieurs). Lorsque vous exécutez la Calculate red flags for CSDM and other dependencies tâche planifiée, les données d’indicateur rouge sont extraites et déployées en fonction des paramètres configurés.
Une fois la tâche planifiée terminée, les configurations de nœud principales ne sont plus nécessaires. Le tableau de bord utilise la propriété de première classe pour parcourir la table intermédiaire des indicateurs rouges et récupérer les indicateurs rouges en aval qui correspondent au type d’enregistrement spécifié, tel que service d’entreprise ou offre de service, et ainsi de suite.
L’exemple suivant montre que l’incident SO1 - VM est déployé à partir de SO1.
Les contrôles ayant échoué des processus business et des offres de services sont repris et affichés dans les modules.