Extraction des dépendances et de l’analyse d’impact sur CMDB l’entreprise

  • Rversion finale: Washingtondc
  • Mis à jour 1 févr. 2024
  • 3 minutes de lecture

    • Vous pouvez extraire les dépendances pour les services d’entreprise, les services enfants, les processus et les processus du service CMDB enfant dans .Operational Resilience De même, lorsque les BCM applications sont installées, la Operational Resilience tâche planifiée surveille également les changements dans les dépendances de Business Impact Analysis (BIA) et récupère les mises à jour des dépendances.

    Extraction des dépendances à partir de CMDB

    À partir de la Washington DC mise en production, l’application est prise Cadre de travail des relations entre données en charge Operational Resilience avec le cadre de travail sous-jacent afin d’extraire les dépendances à partir de CMDB. La commande Cadre de travail des relations entre données (app-grc-relationship-config) est installée avec l’application Operational Resilience par défaut. Les CMDB dépendances sont récupérées en appelant une API à partir du Cadre de travail des relations entre donnéesfichier .

    Pour obtenir les CMDB dépendances, l’administrateur Operational Resilience doit d’abord activer la configuration de nœud principal, appelée Service d’entrepriseCadre de travail des relations entre données (CMDB).

    Pour chaque dépendance récupérée, l’application recherche d’abord Operational Resilience une entité existante. S’il n’existe aucune entité, la dépendance est ignorée. S’il existe une entité et que l’entité appartient à n’importe quel type d’entité dans Operational Resilience, elle est ajoutée à l’aval de l’entité de son parent. Si l’entité n’appartient à aucun type d’entité, comme Installations/Personnes/Fournisseurs/Technologies, vous devez l’ajouter manuellement au type d’entité correspondant dans Operational Resilience.

    L’exemple suivant montre un exemple de CMDB configuration de relation pour un service d’entreprise. Lorsque le service Windows mobile met à jour ses dépendances, l’entité est OWA-SD-01 ajoutée à l’aval de son entité IronMail-SD-01 et IronMail-SD-02 est ajoutée à l’aval de l’entité Email de service enfant.

    Tableau 1. Exemple de configuration de relation pour un service d’entreprise
    Service aux entreprises Dépendance, processus de gestion et service d’entreprise associés : e-mail Processus et dépendances associés au service d’entreprise : E-mail
    Windows Mobile
    • Dépendance: OWA-SD-01
    • Processus de gestion : Inbound payment validation
    • Service aux entreprises : Email
    • Processus: Fraud_escalation
    • Dépendance 1 : IronMail-SD-01 (La table est cmdb_ci_email_server.)
    • Dépendance 2 : IronMail-SD-02 (La table est cmdb_ci_email_server.)

    Extraction des dépendances à partir de Business Impact Analysis (BIA)

    Lorsque les BCM applications sont installées, Operational Resilience récupère la mise à jour de dépendance de la BIA si le champ S’applique à de la BIA est un processus business utilisé dans Operational Resilience.

    Les conditions suivantes doivent être remplies pour extraire les dépendances BIA dans Operational Resilience:
    • Le BIA doit être à l’état Approuvé .
    • La BIA ne doit pas être à l’état Expiré .
    • Le groupe de dépendances doit être complété.
    Remarque :
    La tâche planifiée n’extrait que lorsque le champ S’applique à de l’enregistrement BIA correspond à un processus business du type d’entité Processus business , que ses dépendances sont récupérées.

    Pour chaque dépendance récupérée, l’application recherche d’abord Operational Resilience une entité valide existante. Si la dépendance a une entité valide existante et que l’entité appartient à n’importe quel type d’entité dans Operational Resilience, elle est ajoutée à l’aval de l’entité de son parent.

    Pour extraire les mises à jour des dépendances ou les CMDB mises à jour des dépendances BIA, les conditions suivantes doivent être respectées :
    • S’il n’existe aucune entité pour la dépendance, elle est ignorée. Operational Resilience ne crée pas d’entité pour la dépendance.
    • Si une entité de dépendance est inactive, elle est ignorée.
    • Si une entité de dépendance est active, mais qu’elle n’a pas de pilier, elle est ignorée.
    • Si une entité de dépendance est active et possède un pilier, mais qu’elle n’appartient à aucun Operational Resilience type d’entité, elle est ignorée.

    Ajout manuel des dépendances

    Si l’entité n’appartient à aucun type d’entité tel que Installations, Personnes, Fournisseurs, Technologie, Operational Resilience les utilisateurs doivent l’ajouter manuellement au type d’entité correspondant. Au lieu d’utiliser la tâche planifiée, Operational Resilience les administrateurs et les gestionnaires peuvent mettre à jour les dépendances manuellement. Pour en savoir plus sur la mise à jour manuelle des dépendances, reportez-vous à la section Mettre à jour manuellement les dépendances de service.

    Prise en charge de la configuration du nœud principal dans Cadre de travail des relations entre données

    Pour plus d’informations sur la Cadre de travail des relations entre données configuration du nœud principal, reportez-vous aux sections Cadre de travail des relations entre données et Créer un enregistrement de configuration de nœud principal.