Domain Separation dans l’intégrité CMDB

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 8 minutes de lecture
  • Il s’agit d’une vue d’ensemble de Domain separation 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

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

    Fonctionnement de Domain separation dans Intégrité CMDB

    Pour que les tableaux de bord soient les plus efficaces possibles, les utilisateurs doivent configurer le tableau de bord en conséquence. Cela se fait en configurant les règles orphelines, de péremption et d’inclusion 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 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 de mesures 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 global. Jusqu’à la San Diego publication, des tests de mesures locales de sous-domaine étaient 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 de mesure des sous-domaines locaux peuvent avoir généré de grandes quantités de données en raison de données dupliquées.

    À compter de la Tokyo mise en production, les CI du 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 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 dans les sous-domaines, et les résultats relatifs à l’intégrité dans les sous-domaines reflètent ce nouveau comportement.

    Remarque :
    Domain separation 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 pendant la configuration :

    1. Propriétés système globales qui contrôlent 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 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, tel que l’exhaustivité. Cette tâche trouve l’intégrité des CI dans tous les domaines activés. Il n’y a qu’une seule tâche exécutée 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 comprend de domaines, 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 système » de la séparation de domaine. Les modifications sont apportées en fonction du domaine pour lequel l’utilisateur est connecté. Les valeurs système de base sont définies au niveau du domaine global. Le remplacement de la logique de domaine signifie que ces valeurs s’appliquent à tous les domaines. Si les utilisateurs souhaitent des valeurs différentes pour un domaine, ils doivent se connecter à 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 qu’il 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. Moyennes pondérées : ces paramètres peuvent affecter tout ou partie des mesures dans les champs Exhaustivité, Conformité, Exactitude et Relation. Ils peuvent être définis différemment pour différents domaines.
      2. 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 le délai des tâches est long. Il est préférable de ne sélectionner que les domaines que vous souhaitez être Active et d’afficher le reste sous la forme Active = false. Vous pouvez définir cela dans les préférences d’intégrité. Les paramètres par défaut pour le domaine global sont Active = true, mais vous pouvez modifier ou désactiver des domaines spécifiques que l’utilisateur souhaite voir dans le tableau de bord. Les utilisateurs doivent tenir compte de la hiérarchie des domaines 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 Active la valeur sur faux pour tous les domaines racines, afin de désactiver 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.
      3. 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.
      4. 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 doivent remplacer le seuil d’échec pour un domaine, le paramètre de domaine global pour le seuil est toujours appliqué.
      5. Dépannage / Détails 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 classe de CI.

    1. Exhaustivité
      1. Champs obligatoires : ils sont basés sur le schéma de classe défini dans le dictionnaire système de 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 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 d’orphelin sont séparées par domaine ; Il existe différentes règles déterminant les orphelins selon les domaines. La table utilisée est cmdb_health_orphan_rule et est 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 uniquement basés 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 des règles propres 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 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 celle-ci peut être remplacée à n’importe quel niveau de classe.

    Tableaux de bord d’intégrité (vue CMDB/vue des services/vue des groupes)

    En général, les tableaux de bord d’intégrité CMDB prennent en charge le 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 standard : à 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 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 des domaines pour le 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 signalés dans le tableau de bord. Parmi les préférences pouvant avoir un impact sur les scores figurent Moyennes pondérées, Seuil de défaillance 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é définies pour elles (règles de péremption, orphelines, recommandées, d’audit et d’inclusion), qui peuvent être définies différemment pour un domaine spécifique (dans le gestionnaire de classe 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 vues/filtres du rapport d’intégrité. L’une est basée sur les règles métier, l’autre est basée sur les groupes d’intégrité CMDB.