Vues de la page de destination et du tableau de bord

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 modifier les offres de service informatique, les processus business ou les 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.

Calcul et déploiement des indicateurs rouges

Le tableau de bord illustré dans l’exemple précédent affiche une plage de 1 à 30 indicateurs rouges. Lors de la sélection, il affiche une répartition détaillée, montrant un total de 20 indicateurs rouges, dont 3 spécifiquement attribués au niveau « cartes et paiements ». Cela illustre la fonctionnalité de déploiement, qui regroupe les indicateurs rouges sous le 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 ».

La Calculate red flags for CSDM and dependencies tâche planifiée ne crée pas de nouveaux enregistrements dans la table [sn_oper_res_profile]. Au lieu de cela, il recalcule les objets impactés pour les enregistrements de sn_oper_res_profile existants à l’aide des données de la table [sn_grc_m2m_profile_profile].

La Calculate red flags for CSDM and dependencies tâche planifiée récupère les indicateurs rouges pour les profils de la table [sn_oper_res_profile] uniquement lorsque les conditions suivantes sont remplies :

Le n’est sn_oper_res_profile.pillar pas vide.
Le sn_oper_res_profile.applieschamp _to n’est pas vide.

Le mécanisme d’extraction des indicateurs rouges peut utiliser la sn_oper_res_profile.profile condition, la sn_oper_res_profile.applies_to condition ou une combinaison des deux.

Les indicateurs rouges héritent également des objets impactés et des classes d’objets impactés de l’enregistrement [sn_oper_res_profile]. Par exemple, si le profil Operational Resilience d’un service d’application répertorie le service d’entreprise, l’offre et le processus business en tant qu’objets impactés (affichés dans la colonne Objets impactés), ces objets sont copiés dans tous les indicateurs rouges associés pour le service d’application et ses entités connexes.

Remarque :

À partir de Résilience opérationnelle la version 22.x.x, les travaux planifiés et Update CSDM and other dependencies les Calculate red flags for CSDM and dependencies travaux planifiés sont désactivés par défaut pour les nouvelles installations. Pour les installations existantes, ces travaux conservent leur état actuel (actif ou inactif).

Conditions de calcul des indicateurs rouges

Cette section utilise les sn_oper_res_profile.profile conditions et sn_oper_res_profile.applies_to comme référence. Les critères de calcul des indicateurs rouges et les tables pertinentes sont détaillés dans le tableau de calcul des indicateurs rouges.

Tableau 1. Calcul des indicateurs rouges
Indicateurs rouges	Table	Conditions	Notes
Risques élevés - Risque avancé	[sn_risk_advanced_risk_assessment_instance]	Conditions : entity_1=profil état = 30 summary_residual_risk_score doit être supérieure au critère supérieur au critère maximal défini dans risk_assessment_methodology Ne doit pas avoir d’évaluations ouvertes liées à sn_risk_advanced_risk_assessment_instance	Pour tous ces risques, les enregistrements intermédiaires sont créés dans la table [sn_oper_res_risk].
Contrôles ayant échoué : étape 1 (facultatif)	[sn_compliance_m2m_control_entity] (sn_compliance_control ← → sn_grc_profile)	Conditions : entité=profil control.status=non_compliant contrôle.exempt=faux contrôle.état=moniteur contrôle.actif = vrai	Une liste de contrôles est extraite et constitue des indicateurs rouges valides.
Contrôles ayant échoué : étape 2	[sn_compliance_control]	Conditions : entité=profil ou sys_id dans la liste des contrôles control.status=non_compliant contrôle.exempt=faux contrôle.état=moniteur contrôle.actif = vrai	Pour tous ces contrôles, des enregistrements intermédiaires sont créés dans la table [sn_oper_res_failed_control].
Problèmes : étape 1 (facultative)	[sn_grc_m2m_issue_to_entity] (sn_grc_issue ←→ sn_grc_profile)	Conditions : entité=profil sn_grc_issue.active=vrai	Une liste de problèmes est extraite et constituent des indicateurs rouges valides.
Problèmes : étape 2 (facultative) Si l’un des piliers suivants est utilisé, cette étape est considérée comme : Service Service d'entreprise de business	[sn_oper_res_m2m_scenario_event_issue] (scenario_event ←→ sn_grc_issue) [sn_oper_res_m2m_scenario_event_service] (service scenario_event ←→)	Une requête conjointe est effectuée à l’aide des deux tables et [sn_grc_issue] est récupéré pour le service, le service d’entreprise et l’offre.	Ceux-ci sont annexés à la liste des problèmes de l’étape 1.
Problèmes : Étape 3	[sn_grc_issue]	Conditions : entité=profil ou sys_id dans la liste des contrôles actif = vrai De plus, les problèmes ne devraient pas avoir de politique d’exception. La politique d’exception peut être vérifiée dans la table [sn_compliance_policy_exception] avec deux conditions : validity>now état=8	Pour tous ces problèmes, les enregistrements intermédiaires sont créés dans la table [sn_oper_res_issue].
Incident : étape 1	incident	Conditions : cmdb_ci=profile.applies_to état IN [1,2]	Pour tous ces incidents, les enregistrements intermédiaires sont créés dans la table [sn_oper_res_incident].
Incident : étape 2 (facultatif)	[task_ci]	Conditions : ci_item=profile.applies_to task.sys_nom_classe=incident task.state IN [1,2]
Incident : étape 3	[task_cmdb_ci_service]	Conditions : cmdb_ci_service=profile.applies_to task.sys_nom_classe=incident task.state IN [1,2]
Demande de changement : étape 1	[change_request]	Conditions : cmdb_ci=profile.applies_to actif = vrai	Pour toutes ces demandes de changement, les enregistrements intermédiaires sont créés dans la table [sn_oper_res_change_request].
Demande de changement : étape 2 (facultatif)	[task_ci]	Conditions : ci_item=profile.applies_to task.sys_nom_classe=change_request tâche.active=vrai
Demande de changement : étape 3	[task_cmdb_ci_service]	Conditions : cmdb_ci_service=profile.applies_to task.sys_nom_classe=change_request task.state IN [1,2]
Panne	[cmdb_outage_ci_mtom] (cmdb_ci ←→ cmdb_ci_outage) [cmdb_ci_outage] (cmdb_ci) Pour chaque enregistrement dans [cmdb_ci_outage], un enregistrement est créé dans la table [cmdb_ci_outage_ci_mtom]. Dans [cmdb_ci_outage], pour chaque CI affectés, un enregistrement est inséré dans la table [cmdb_ci_outage_ci_mtom].	Conditions : ci_item=profile.applies_to outage.type IN [dégradation, panne] outage.end EST vide OU outage.end > maintenant	Pour toutes ces pannes, les enregistrements intermédiaires sont créés dans la table [sn_oper_res_outage].
Tâche	[tâche]	Conditions : cmdb_ci=profile.applies_to actif = vrai sys_class_name DANS <liste des classes extraites de la propriété sn_oper_res.allowed_task_tables Dans le cadre du système de base, il ne prend en compte que les enregistrements de problèmes.	Pour toutes ces tâches, des enregistrements intermédiaires sont créés dans la table [sn_oper_res_task].
Vulnérabilités opérationnelles : étape 1 (facultative)	[sn_grc_case_mgmt_related_area]	Conditions : related_area=profil OU related_area=profile.applies_to core_case.sys_nom_classe=sn_oper_res_vulnerability core_case.active=vrai	Pour toutes ces vulnérabilités, des enregistrements intermédiaires sont créés dans la table [sn_oper_res_vulnerability_profile].
Vulnérabilités opérationnelles : étape 2 (facultative)	[sn_grc_case_mgmt_impacted_area]	Conditions : impacted_area=profil OU impacted_area=profile.applies_to core_case.sys_nom_classe=sn_oper_res_vulnerability core_case.active=vrai
Évaluations des risques de tiers	[sn_vdr_risk_asmt_assessment]	Conditions : applies_to DANS [core_company, sn_vdr_risk_asmt_vendor_engagement] état IN [5, 8, 9] risk_rating_valid_to > maintenant risk_rating = highestRiskRating fournisseur = profile.applies_to (Remarque : cette condition est différente du champ applies_to dans la table [sn_vdr_risk_asmt_assessment].) engagement = profile.applies_to (Remarque : cette condition est différente du champ applies_to dans la table [sn_vdr_risk_asmt_assessment].)	Pour toutes ces évaluations, les enregistrements intermédiaires sont créés dans la table [sn_oper_res_tprm].