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

  • Rversion finale: Yokohama
  • Mis à jour 30 janv. 2025
  • 9 minutes de lecture

    • Il s’agit d’une vue d’ensemble de Séparation de domaine en ce qui concerne 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 couverts dans des sections distinctes ci-dessous.

    Fonctionnement de Séparation de domaine dans Intégrité CMDB

    Pour que les tableaux de bord soient les plus efficaces, les utilisateurs doivent configurer le tableau de bord en conséquence. Pour ce faire, les règles d’orphelin, de péremption et d’inclusion sont configurées pour répondre à leurs besoins, ce qui affecte 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 s’ajoutent à celles qui sont 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 de mesures du domaine global se propagent vers les 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 version, les tests de mesures locales des sous-domaines étaient appliqués aux CI du sous-domaine, ainsi qu’aux CI du domaine global (qui sont visibles sur les sous-domaines). Les CI de domaine global qui ont échoué aux tests de mesures des sous-domaines locaux peuvent avoir généré 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 sont évalués uniquement par rapport aux tests de mesures spécifiés dans le domaine global. Dans les sous-domaines, les tests de mesures locales 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 d’intégrité des CI dans le domaine global apparaissent sur les sous-domaines et les résultats d’intégrité sur les sous-domaines reflètent ce nouveau comportement.

    Remarque :
    L’option Séparation de domaine est activée 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 à la section Propriétés système d’intégrité CMDB.

    2. Tâches du tableau de bord de l’intégrité CMDB : il existe une tâche de tableau de bord pour chaque KPI majeur, comme l’exhaustivité. Cette tâche permet de déterminer 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 les tâches ; Le rapport s’exécute pour tous les domaines. Plus le travail inclut de domaines, plus l’exécution du travail est longue.

    3. Mesures d’intégrité : ces sélections sont séparées par domaine et adhèrent à la logique établie de « remplacements système » de Séparation de domaine. Les changements sont effectués en fonction du domaine pour lequel l’utilisateur est connecté. Les valeurs système de base sont définies au niveau du domaine global. La logique de domaine prioritaire 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 en hérite. Pour en savoir plus, consultez Mesures d’intégrité.
      Remarque :
      En ce qui concerne les KPI Exhaustivité, Conformité et Exactitude : les utilisateurs peuvent désactiver ce KPI s’ils ne souhaitent pas le voir 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 du temps. Il est préférable de sélectionner uniquement les domaines que vous souhaitez être Active et de rendre le reste comme Active = faux. Vous pouvez définir cela dans les préférences de santé. 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 afficher dans le tableau de bord. Les utilisateurs doivent tenir compte de la hiérarchie du domaine lorsqu’ils modifient ces valeurs. S’il y a un grand nombre de domaines (>100), le travail peut prendre beaucoup de temps. Pour atténuer cela, définissez Active la valeur sur faux pour tous les domaines racines, désactivant ainsi tous les autres domaines de la hiérarchie. S’il existe 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 de défaillance n’est pas séparé par domaine. Le seuil de défaillance pour le domaine global est appliqué à tous les domaines. Par exemple, même si les utilisateurs devaient remplacer le seuil de défaillance d’un domaine, le paramètre de domaine global pour le seuil est toujours appliqué.
      4. Dépannage / Détails de l’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 classe de CI.

    1. Exhaustivité
      1. Champs obligatoires : ils sont basés sur le schéma de classe défini dans la plateforme System dictionary et sont fixes pour tous les domaines. Celles-ci ne peuvent pas être modifiées.
      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. Orphelin – Les règles orphelines sont séparées par domaine ; Il existe différentes règles déterminant les orphelins pour différents 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 système de base (60 jours) est définie pour le domaine global et est donc héritée par tous les domaines comme règle par défaut.
    3. Conformité

      Audit : les scores d’audit sont basés sur l’état souhaité ou 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 du score 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 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 règles spécifiques à 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 du 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 de l’é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 d'intégrité CMDB

    Si le module d’extension Domain Support — Domain Extensions Installer est activé, le tableau de bord Intégrité CMDB prend en charge le domaine :
    • Le tableau de bord Intégrité CMDB regroupe et signale les défaillances et les scores d’intégrité en fonction de la visibilité de domaine des CI par 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 soit dans le domaine de l’utilisateur ou dans un domaine confiné. Si un CI échoue aux tests d’intégrité de différents domaines d’utilisateur, des enregistrements d’échec 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 son domaine 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 sont sensibles au domaine et affichent les données en fonction de l’utilisateur de 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 (en fonction du 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 de visibilité de domaine régulières : à 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 directement ou indirectement contenu par ce domaine.)
    3. La vue de 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 fixe les règles de base, mais ne définit pas chaque domaine individuel. 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 qui ont un impact sur les scores indiqués dans le tableau de bord. Les préférences qui peuvent avoir un impact sur les scores comprennent Seuil de défaillance et Actif.
    5. Comme expliqué dans la section Règles d’intégrité CMDB, les scores rapportés pour les mesures sont basés sur les règles d’intégrité définies pour celles-ci (règles de péremption, orphelin, recommandées, d’audit et d’inclusion) qui peuvent être définies différemment pour un domaine spécifique (dans le Gestionnaire de classe 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érentes vues/filtres du rapport d’intégrité. L’un est basé sur les règles métier, l’autre est basé sur les groupes d’intégrité CMDB.