Séparation de domaine dans l’intégrité CMDB

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 9 minutes de lecture

    • Il s’agit d’une vue d’ensemble de Séparation de domaine telle qu’elle se rapporte à l’intégrité CMDB. Séparation de domaine vous permet de séparer les données, les processus et les tâches administratives en groupes logiques appelés domaines. Vous pouvez contrôler plusieurs aspects de cette séparation, notamment les utilisateurs qui peuvent voir les données et y accéder.

    Vue d'ensemble

    CMDB Les tableaux de bord doivent être configurés avec leur propre ensemble de règles pour s’adapter au mieux aux besoins de l’utilisateur. CMDB Les tâches de tableau de bord respectent ces règles pour produire des rapports. Ceux-ci sont traités dans des sections distinctes ci-dessous.

    Fonctionnement de Séparation de domaine dans l’intégrité CMDB

    Pour que les tableaux de bord soient les plus efficaces, les utilisateurs doivent configurer le tableau de bord en conséquence. Cela se fait en configurant les règles d’orphelin, de péremption et d’inclusion pour répondre à leurs besoins, qui affectent ensuite les rapports affichés sur le tableau de bord.

    Les paramètres et les mesures définissent différents aspects de chaque application, car chaque domaine peut être configuré différemment. Ces règles sont configurées en plus de celles incluses dans le système de base. Il existe différents types de propriétaires pour différents CI ; Chaque domaine a son propre ensemble de règles.

    Les tests métriques du domaine global se propagent aux sous-domaines. Toutefois, les sous-domaines peuvent avoir leurs propres tests de mesures locaux qui remplacent les tests de domaine globaux. Jusqu’à la San Diego publication, des tests de métriques locales de sous-domaine ont été appliqués aux CI de sous-domaine, ainsi qu’aux CI de domaine globaux (qui sont visibles sur les sous-domaines). Les CI de domaine global qui ont échoué aux tests métriques des sous-domaines locaux auraient pu générer de grandes quantités de données en raison de données dupliquées.

    À partir de la Tokyo mise en production, les CI dans le domaine global ne sont évalués que par rapport aux tests de mesures spécifiés dans le domaine global. Dans les sous-domaines, les tests de mesures locaux ne sont appliqués qu’aux CI de ce sous-domaine et ne sont pas appliqués aux CI du domaine global (même si les CI du domaine global sont visibles dans le sous-domaine). Les résultats relatifs à l’intégrité des CI dans le domaine global s’affichent sur les sous-domaines et les résultats relatifs à l’intégrité sur les sous-domaines reflètent ce nouveau comportement.

    Remarque :
    Séparation de domaine est activé par défaut, mais chaque domaine peut être configuré selon les besoins.

    Préférences d’intégrité

    Configurez ces préférences lors de la configuration :

    1. Propriétés système globales qui contrôlent l’intégrité CMDB : les propriétés système ne sont pas séparées par domaine. Pour en savoir plus, reportez-vous Propriétés système de l’intégrité CMDBà .

    2. Tâches du tableau de bord Intégrité CMDB : il existe une tâche de tableau de bord pour chaque KPI majeur, tel que l’exhaustivité. Cette tâche détecte l’intégrité des CI dans tous les domaines activés. Il n’existe qu’une seule exécution de tâche pour tous les domaines et les tâches elles-mêmes ne sont pas séparées par domaine.

      Les utilisateurs peuvent définir la fréquence à laquelle ils souhaitent exécuter des tâches ; Le rapport s’exécute pour tous les domaines. Plus la tâche comporte de domaines inclus, plus l’exécution de la tâche est longue.

    3. Mesures d’intégrité : ces sélections sont séparées par domaine et respectent la logique établie de « remplacements du système » de séparation de domaine. Les modifications sont effectuées en fonction du domaine pour lequel l’utilisateur est connecté. Les valeurs du système de base sont définies au niveau du domaine global. La logique de domaine de remplacement signifie que ces valeurs s’appliquent à tous les domaines. Si les utilisateurs veulent des valeurs différentes pour un domaine, ils doivent être connectés à un domaine spécifique et modifier la propriété à partir de là. Le nouveau paramètre de propriété s’applique uniquement à ce domaine et à tout domaine qui hérite de ce domaine. Pour en savoir plus, consultez Mesures d’intégrité.
      Remarque :
      En ce qui concerne les KPI d’exhaustivité, de conformité et d’exactitude : les utilisateurs peuvent désactiver ce KPI s’ils ne souhaitent pas que cela apparaisse dans le score du tableau de bord. Tous ces paramètres sont séparés par domaine et l’utilisateur peut définir des propriétés spécifiques pour le domaine.
      1. Actif : ce paramètre est le plus important, car il affecte la durée d’exécution des tâches. Plus il y a de domaines avec des marqueurs définis sur Active, plus les tâches prennent de temps. Il est préférable de sélectionner uniquement les domaines que vous souhaitez être Active et de rendre le reste sous la forme Active = faux. Vous pouvez le définir dans les préférences d’intégrité. Les paramètres par défaut pour le domaine global sont Active = vrai, mais vous pouvez modifier ou désactiver des domaines spécifiques que l’utilisateur souhaite voir apparaître dans le tableau de bord. Les utilisateurs doivent tenir compte de la hiérarchie de domaine lors de la modification de ces valeurs. S’il y a un grand nombre de domaines (>100), le travail peut prendre beaucoup de temps. Pour atténuer ce problème, définissez la valeur Activesur faux pour tous les domaines racines, désactivant ainsi tous les autres domaines de la hiérarchie. S’il y a une règle en haut, tous les domaines enfants héritent de cette règle.
      2. Failure Threshold, Create Task, Task Assignee Group – Tous ces paramètres peuvent être définis différemment pour différents domaines en fonction de ce qui est nécessaire dans chaque domaine.
      3. Exceptions : pour les mesures de relation (relation, relations en double, relations orphelines, relations périmées), le paramètre de seuil d’échec n’est pas séparé par domaine. Le seuil d’échec pour le domaine global est appliqué à tous les domaines. Par exemple, même si les utilisateurs devaient remplacer le seuil de défaillance pour un domaine, le paramètre de domaine global pour le seuil est toujours appliqué.
      4. Dépannage / Détail d’implémentation : ces paramètres sont stockés dans la cmdb_health_metric_pref table, qui est séparée par domaine.

    Règles liées à l’intégrité CMDB

    Consultez les paramètres des règles liées à l’intégrité CMDB à l’adresse suivante :

    La plupart des règles liées à l’intégrité CMDB sont séparées par domaine et fournies par les utilisateurs. Les utilisateurs peuvent définir différentes règles pour différents domaines en se connectant à chaque domaine et en ajoutant/remplaçant des règles dans le Gestionnaire de classes CI.

    1. Exhaustivité
      1. Champs obligatoires System dictionary : ils sont basés sur le schéma de classe défini dans la plateforme et sont fixes pour tous les domaines. Ceux-ci ne peuvent pas être modifiés.
      2. Champs recommandés : ils sont séparés par domaine. La table utilisée est Champs recommandés CMDB [cmdb_recommended_fields], qui est séparée par domaine. L’utilisateur peut les configurer pour différents domaines.
    2. Exactitude
      1. Doublons : les doublons sont basés sur des règles d’identification, qui ne sont pas séparées par domaine, de sorte que les mêmes règles s’appliquent à tous les domaines.
      2. Orpheline : les règles orphelines sont séparées par domaine. Il existe différentes règles déterminant les orphelins selon les domaines. Table utilisée dans la table Règle déterminant les orphelins de l’intégrité CMDB [cmdb_health_orphan_rule] et séparée par domaine.
      3. Péremption : les règles de péremption sont séparées par domaine. La table utilisée est cmdb_health_staleness_rule. La règle du système de base (60 jours) est définie pour le domaine global et est donc héritée par tous les domaines en tant que règle par défaut.
    3. Conformité

      Audit : les scores d’audit sont basés sur l’état souhaité ou sur les audits scriptés définis dans le module de conformité par l’utilisateur. Les audits eux-mêmes sont séparés par domaine. Lorsque l’évaluation des scores d’audit est activée pour un domaine, les scores sont basés uniquement sur les audits visibles dans ce domaine.

    Règles d’inclusion en matière d’intégrité :
    • Les règles d’inclusion d’intégrité sont séparées par domaine. Les règles sont stockées dans la table cmdb_health_config qui est séparée par domaine.
    • Chaque domaine peut avoir ses propres règles d’inclusion d’intégrité et des règles spécifiques au domaine pour chaque sous-mesure.
    • Lorsqu’une règle d’inclusion d’intégrité est définie globalement, tous les sous-domaines héritent de la règle en fonction de la structure de domaine et la règle peut être remplacée dans n’importe quel domaine.
    • Lorsqu’une règle d’inclusion d’intégrité est définie au niveau de la classe Élément de configuration [cmdb_ci], toutes les classes descendantes héritent de la règle et la règle peut être remplacée à n’importe quel niveau de classe.

    Tableau de bord Intégrité CMDB

    Si le module d’extension Domain Support — Domain Extensions Installer est activé, le tableau de bord d’intégrité CMDB prend en charge le domaine :
    • Le tableau de bord Intégrité CMDB agrège et signale les défaillances et scores d’intégrité en fonction de la visibilité des CI dans le domaine de l’utilisateur. Si la visibilité de domaine permet à un utilisateur de voir un CI, alors la règle d’audit dans le domaine de cet utilisateur s’applique à ce CI, que le CI se trouve dans le domaine de l’utilisateur ou dans un domaine contenu. Si un CI échoue aux tests d’intégrité de différents domaines d’utilisateurs, des enregistrements de défaillance distincts sont créés.
    • Les utilisateurs peuvent configurer des paramètres de KPI et de mesures spécifiques aux besoins de leur domaine. Ainsi, différents domaines peuvent avoir des paramètres différents tels que actif/inactif et seuils.
    • Un domaine enfant dérive les configurations d’intégrité de domaine de son parent immédiat si le domaine enfant ne configure pas les siennes. Un domaine enfant peut remplacer les configurations du parent en les modifiant.

    Tableaux de bord d’intégrité (vue de classe/vue de service/vue de groupe d’intégrité)

    En général, les tableaux de bord Intégrité CMDB prennent en charge le domaine et affichent les données en fonction de l’utilisateur du domaine connecté. Si un utilisateur est connecté à un domaine et affiche un tableau de bord d’intégrité :

    1. Seuls les scores des mesures activées dans ce domaine s’affichent (basés sur le marqueur Préférences Active d’intégrité, comme indiqué ci-dessus).
    2. Tous les scores sont basés sur les CI visibles à partir du domaine spécifique. (Il s’agit de règles normales de visibilité de domaine : à partir de ce domaine, vous pouvez voir les CI dans le domaine global, le domaine spécifique, tout domaine enfant de ce domaine ou tout domaine qui est contenu directement ou indirectement par ce domaine.)
    3. La vue du tableau de bord est basée sur les règles de domaine définies dans le mappage de domaine, par opposition à celles fournies par l’utilisateur connecté. Cette vue remplace toutes les règles de visibilité de domaine supplémentaires qu’un utilisateur connecté peut avoir. L’administrateur définit les règles de base, mais ne définit pas chaque domaine individuellement. L’administrateur peut donner à des utilisateurs ou à des groupes d’utilisateurs spécifiques une visibilité supplémentaire sur d’autres domaines, et le tableau de bord ne change toujours pas. Le tableau de bord suit strictement les règles de domaine mentionnées ci-dessus, en fonction de la hiérarchie de domaine du domaine dans lequel l’utilisateur est connecté.
    4. Comme expliqué dans la section Préférences d’intégrité, les utilisateurs peuvent définir différentes valeurs de préférence pour n’importe quel domaine, ce qui a un impact sur les scores signalés dans le tableau de bord. Les préférences qui peuvent avoir un impact sur les scores comprennent Échec, Seuil et Actif.
    5. Comme expliqué dans la section Règles d’intégrité CMDB, les scores signalés pour les mesures sont basés sur les règles d’intégrité qui leur ont été définies (périmation, orpheline, recommandée, d’audit et règles d’inclusion), qui peuvent être définies différemment pour un domaine spécifique (dans le Gestionnaire de classes de CI). Seules la mesure requise et la mesure en double sont basées sur des règles qui s’appliquent dans tous les domaines.
    6. Vue du service/vue du groupe – Ces rapports suivent également en grande partie les points ci-dessus. En règle générale, ces vues diffèrent des différents vues/filtres du rapport d’intégrité. L’une est basée sur les règles métier, l’autre sur les groupes d’intégrité CMDB.