Analyses DevOps tableau de bord : espace de travail

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 16 minutes de lecture
  • Le Analyses DevOps tableau de bord offre une vue graphique flexible des rapports opérationnels et commerciaux. Utilisez le tableau de bord pour évaluer les résultats de votre processus global DevOps .

    Tableau de bord récapitulatif

    Le Analyses DevOps tableau de bord récapitulatif fournit une vue d’ensemble des mesures clés dans différentes catégories, de l’accélération aux mesures de qualité, ainsi qu’un aperçu rapide des applications les plus actives.

    Rapports de résumé

    Analyses DevOps Tableau de bord récapitulatif.

    Rapport Description Source
    Délai moyen du cycle WIP Délai moyen, en jours, pendant lequel un élément de travail est à l’état WIP avant l’achèvement.

    Calcul : délai d’achèvement des éléments WIP divisé par le nombre d’éléments de travail terminés

    Délai d'exécution moyen Délai d’exécution moyen quotidien pour les exécutions de pipelines de déploiement produit.

    Calcul : somme des délais de déploiement produit réussis divisé par le nombre d’exécutions de pipelines de production réussies.

    Fréquence moyenne de déploiement

    Nombre moyen de déploiements en production réussis.

    S’applique aux étapes de pipeline de type Déploiement du produit qui sont à l’état Terminé.

    Exécution d'étape
    % moyen de réussite aux tests Pourcentage moyen quotidien de réussite aux tests pour les exécutions de pipelines.

    Vue de base de données reliée par le résumé du test, les relations de résumé des tests, l’exécution de l’étape, les détails du référentiel de demande de changement, l’étape, le pipeline, l’application et les détails du produit de l’application.

    Éléments de travail terminés Éléments de travail, regroupés par type d’élément de travail, qui ont été définis sur l’état Terminé au cours des 30 derniers jours.

    Vue de base de données jointe par élément de travail, instance de mesure, élément de travail de validation, validation, exécution de validation, exécution d’étape, étape, pipeline, application et détail du produit de l’application.

    Activité : 30 derniers jours Pour chaque application, le résumé de l’activité au cours des 30 derniers jours.

    Vue de base de données reliée par validation, élément de travail de validation, référentiel, exécution de validation, application, relations de résumé de test, exécution d’étape, résumé de test.

    Tableau de bord des mesures de flux

    Les Analyses DevOps rapports de mesures de flux vous aident à visualiser l’évolution du travail dans votre processus de développement. Identifiez les goulots d’étranglement en déterminant quels types de travail (tels que les stories ou les bogues) prennent le plus de temps.

    Rapports sur les mesures de flux

    Analyses DevOps Tableau de bord des mesures de flux

    Tableau 1. Rapports sur les mesures de flux
    Rapport Description Source
    Délai moyen du flux Délai moyen, en jours, pendant lequel un élément de travail est passé de l’état Créé à l’heure de fin d’exécution de l’étape d’un déploiement réussi du pipeline de produit. Vue de base de données jointe par élément de travail, instance de mesure, élément de travail de validation, validation, exécution de validation, exécution d’étape, étape, pipeline, application et détail du produit de l’application.
    Délai moyen du cycle WIP Délai moyen, en jours, pendant lequel un élément de travail se trouve dans un état spécifique. Vue de base de données reliée par des listes d’éléments de travail, d’instances de mesures, de validations, d’exécutions d’étapes, d’exécutions de validation et d’éléments de travail de validation.
    Nombre moyen de WIP Nombre moyen d’éléments de travail à l’état WIP au cours des 30 derniers jours. Nombre moyen d’éléments de travail dont l’état est défini sur Travail en cours.
    Éléments de travail terminés Nombre d’éléments de travail à l’état Terminé, qui sont associés à des validations via un déploiement réussi du pipeline de production au cours des 30 derniers jours.
    Remarque :
    Les filtres ne s’appliquent pas à ce graphique.
    Nombre moyen d’éléments de travail associés au type d’exécution de l’étape défini sur Déploiement produit. Cela nécessite une validation dans l’association d’éléments de travail, car seuls les éléments de travail déployés via un pipeline sont en production.
    Durée de cycle moyen de l'élément de travail Délai moyen, en jours, pendant lequel un élément de travail se trouve dans un état spécifique. Vue de base de données reliée par des listes d’éléments de travail, d’instances de mesures, de validations, d’exécutions d’étapes, d’exécutions de validation et d’éléments de travail de validation.
    Débit et distribution Nombre d’éléments de travail, par type, qui sont associés à des validations via un déploiement réussi du pipeline de production. Vue de base de données reliée par des listes d’éléments de travail, d’instances de mesures, de validations, d’exécutions d’étapes, d’exécutions de validation et d’éléments de travail de validation.
    Délai moyen planifié jusqu'au délai du flux de déploiement Durée moyenne entre le moment où un élément de travail associé à une validation a été créé et le moment où l’élément a été déployé avec succès vers la production via des pipelines. Vue de base de données reliée par des listes d’éléments de travail, d’instances de mesures, de validations, d’exécutions d’étapes, d’exécutions de validation et d’éléments de travail de validation.
    En cours de résolution Nombre d’éléments de travail actuellement à l’état Travail en cours. Vue de base de données reliée par des listes d’éléments de travail, d’instances de mesures, de validations, d’exécutions d’étapes, d’exécutions de validation et d’éléments de travail de validation.

    Tableau de bord d’accélération des changements

    L’onglet Analyses DevOps Accélération du changement affiche des mesures d’accélération du changement qui se concentrent sur votre chemin vers l’automatisation, en comparant les changements automatisés aux changements manuels, aux décisions de politique de changement et au retour sur investissement. Vous pouvez utiliser ces informations pour vérifier que les demandes de changement automatisées sont résolues plus rapidement que les demandes de changement approuvées manuellement.

    Rapports sur l’accélération du changement

    Analyses DevOps Tableau de bord d’accélération des changements

    Les demandes de changement qui font partie des exécutions d’étapes sont considérées comme des demandes de DevOps changement.

    Tableau 2. Rapports sur l’accélération du changement
    Rapport Description Source
    DevOps Volume des changements Nombre de demandes de DevOps changement créées. Vue de base de données reliée par l’exécution de l’étape, la demande de changement et le référentiel de demandes de changement.
    Délai des changements fermés Délai moyen, en heures, pour fermer DevOps les changements par application.

    Pour chaque mois, il s’agit de la moyenne pour (Heure à laquelle la demande de changement a été fermée) moins (Heure à laquelle la demande de changement a été ouverte).

    Vue de base de données reliée par l’exécution de l’étape, la demande de changement et le référentiel de demandes de changement.
    Changements automatisés par rapport aux changements manuels

    Comparaison entre le nombre de demandes de changement utilisant des politiques d’approbation de changement et DevOps les demandes de DevOps changement nécessitant une approbation manuelle.

    • Une demande de changement est considérée comme automatisée lorsqu’une politique de changement effectue l’action d’approbation/de rejet.
    • Un changement manuel est une demande de changement qui est affectée à un utilisateur ou à un groupe pour l’action d’approbation/de rejet et qui n’est pas mise en œuvre par une politique de changement.
    Vue de base de données reliée par l’exécution de l’étape, la demande de changement et le référentiel de demandes de changement.
    Changements en attente d'approbation

    Nombre de changements en attente d’approbation par plage de DevOps dates.

    Par défaut, les demandes de changement dont l’état est Nouveau ou Évaluation sont considérées comme en attente d’approbation.

    Pour spécifier les états considérés comme en attente d’approbation, mettez à jour le paramètre de Change Request Awaiting States propriété. Pour plus de détails, voir Propriétés du Analyses DevOps.

    Vue de base de données reliée par les listes de détails Exécution des étapes, Demande de changement, Propriétés système et Référentiel de demande de changement.
    Décisions de politique de changement : acceptées automatiquement

    Le nombre de décisions de politique de changement par type de décision qui acceptent automatiquement les demandes de changement.

    Pointez sur une valeur sur le graphique pour afficher la liste des décisions de politique qui ont été utilisées pour l’approbation automatique et le nombre de fois qu’une décision a été utilisée pour l’approbation automatique.

    Vue de base de données reliée par les listes de détails Exécution des étapes, Demande de changement, Propriétés système et Référentiel de demande de changement.
    Décisions de politique de changement : rejetées automatiquement

    Nombre de décisions de politique de changement, par type de décision, qui rejettent automatiquement les demandes de changement.

    Pointez sur une valeur sur le graphique pour afficher la liste des décisions de politique qui ont été utilisées pour le rejet automatique et le nombre de fois qu’une décision a été utilisée pour le rejet automatique.

    Vue de base de données reliée par les listes de détails Exécution des étapes, Demande de changement, Politique appliquée, Action de rejet d’approbation automatique, Définition de l’approbation de changement et Référentiel de demande de changement.
    Économies sur l'accélération du changement

    Montant net économisé par mois grâce à l’automatisation des DevOps changements.

    Lorsqu’un changement est automatisé, un développeur n’a pas besoin de remplir manuellement la demande de changement et d’associer chaque élément de travail, validations de code, résultats des tests et autres preuves et artefacts au changement. Une fois cette activité automatisée, les heures qui auraient été consacrées à remplir le changement, à rechercher, à rechercher et à joindre des éléments à partir d’autres outils à un changement seront désormais enregistrées. Un plus grand nombre d’éléments de travail nécessite un nombre relativement croissant d’heures pour les associer manuellement. Par conséquent, un nombre plus élevé d’éléments de travail devrait entraîner davantage d’heures économisées une fois le changement automatisé. Les économies réalisées sur l’accélération du changement sont calculées en multipliant les heures économisées par le coût horaire moyen du développeur.

    Pour modifier la valeur par défaut du coût horaire moyen du développeur, mettez à jour le paramètre de propriété Average Hourly developer Cost . Pour plus de détails, voir Propriétés du Analyses DevOps.

    Calcul : coût horaire moyen du développeur multiplié par les heures de développeur économisées.
    Heures de développeur enregistrées Nombre d’heures de développeur économisées par mois grâce à l’automatisation des DevOps changements.

    Pour modifier la valeur par défaut de 1 (une) heure par développeur, mettez à jour le paramètre de la X hours per Developer time propriété. Pour plus de détails, voir Propriétés du Analyses DevOps.

    Calcul : nombre d’éléments de travail dans une demande de changement multiplié par 1 heure par développeur.

    Tableau de bord des mesures d’accélération

    Les mesures d’accélération Analyses DevOps sont quatre mesures clés DevOps qui mesurent les performances de livraison de logiciels. La fréquence et le délai de déploiement mesurent DevOps la vitesse, tandis que le taux d’échec des changements et le temps moyen de récupération sont utilisés pour mesurer la stabilité.

    Rapports sur les mesures d’accélération

    Analyses DevOps Tableau de bord des mesures d’accélération

    Tableau 3. Rapports sur les mesures d’accélération
    Rapport Description Source
    Délai d'exécution moyen

    Moyenne de :

    ([Temps auquel le code est poussé avec succès à la production] moins [Temps de validation le plus tôt])

    S’applique aux étapes de pipeline de type Déploiement du produit qui sont à l’état Terminé.

    Remarque :
    Ce widget utilise l’agrégation moyenne et ne prend pas en charge la sélection de plusieurs éléments.
    Exécution de pipeline
    Fréquence moyenne de déploiement

    Nombre moyen de déploiements en production réussis.

    S’applique aux étapes de pipeline de type Déploiement du produit qui sont à l’état Terminé.

    Exécution d'étape
    MTTR moyen

    Délai moyen de résolution d’un incident causé par un DevOps changement.

    Remarque :
    Ce widget utilise l’agrégation moyenne et ne prend pas en charge la sélection de plusieurs éléments.
    Vue de base de données reliée par des listes d’incidents, de demandes de changement, d’exécutions d’étapes, d’étapes, de pipelines et d’applications.
    Taux moyen DevOps d’échec de changement

    Taux moyen quotidien de demandes de DevOps changement associées à un incident, divisé par toutes les DevOps demandes de changement.

    Remarque :
    Ce widget utilise une formule et ne prend pas en charge la sélection de plusieurs éléments.
    Demande de changement
    Délai entre validation et déploiement

    Durée du délai de validation le plus précoce jusqu’au déploiement de production pour une exécution de pipeline réussie.

    La valeur inclut uniquement les étapes de type Déploiement du produit qui sont à l’état Terminé.

    Vous pouvez étudier les délais élevés en identifiant les étapes de pipeline les plus lentes. Par exemple, un processus manuel d’approbation des changements peut augmenter les délais.

    Calcul : somme des délais de déploiement produit réussis divisée par le nombre d’exécutions de pipelines de production réussies.

    Nécessite l’association « Validations de l’exécution de la tâche ». Le référentiel et le pipeline doivent être suivis et associés à la même application.

    Le type d’étape nécessaire doit être un déploiement produit.

    Nécessite que le résultat de l’exécution de la tâche réussisse.

    Délai moyen de restauration à partir d’incidents causés par DevOps des changements Délai moyen quotidien de résolution d’un incident causé par un DevOps changement.

    Vue de base de données associée par exécution des étapes, demande de changement, détail du référentiel de demande de changement et listes d’incidents.

    Calculé uniquement pour les DevOps incidents en tenant compte de l’heure d’ouverture et de fermeture de l’incident.

    Fréquence de déploiement de la production Nombre de déploiements en production réussis.

    La valeur inclut uniquement les étapes du pipeline de type Déploiement du produit qui sont à l’état terminé.

    Pour modifier la valeur par défaut de 30 jours, mettez à jour le paramètre Plage de dates .

    Vue de base de données reliée par la demande de changement, l’exécution de l’étape, le détail du référentiel de la demande de changement.

    Nécessite que l’état d’exécution de l’étape soit terminé.

    Le type d’étape nécessaire doit être un déploiement produit.

    DevOps Taux d’échec de changement des incidents

    Pourcentage de changements ayant causé des DevOps incidents divisé par tous les DevOps changements déployés vers la production.

    Si une demande de changement a causé plusieurs incidents, seul le changement qui a causé ou déclenché l’incident est pris en compte. Le nombre d’incidents causés par le changement n’est pas pris en compte.

    Demande DevOps de changement requise (changement associé à l’exécution d’une étape).

    Nécessite que l’état d’exécution de l’étape soit terminé.

    Le type d’étape nécessaire doit être un déploiement produit.

    Nécessite que l’incident causé par soit DevOps une demande de changement.

    Taux de réussite du déploiement

    Taux de réussite des déploiements au cours des 30 derniers jours.

    Taux de réussite des déploiements = (nombre de déploiements réussis au cours des 30 derniers jours / nombre total de déploiements au cours des 30 derniers jours) * 100

    S’applique aux étapes de type Déploiement du produit à l’état Terminé.

    Remarque :
    Ce widget utilise une formule et ne prend pas en charge la sélection de plusieurs éléments.
    Exécution d'étape
    Fréquence de déploiement

    Nombre de déploiements de production réussis au cours des 30 derniers jours.

    S’applique aux étapes de type Déploiement du produit qui sont à l’état Terminé.

    Exécution d'étape
    Échec des déploiements

    Nombre de déploiements de production réussis au cours des 30 derniers jours.

    S’applique aux étapes de type Déploiement du produit qui sont à l’état Échoué ou Annulé par l’utilisateur.

    Exécution d'étape

    Tableau de bord des mesures de qualité

    Le Analyses DevOps tableau de bord Mesures de qualité permet d’obtenir un aperçu rapide des données provenant d’outils tels que SonarQube la couverture du code, le pourcentage de réussite aux tests de vos outils d’orchestration, les vulnérabilités des outils de Security et même le nombre global de bogues.

    Rapports sur les mesures de qualité

    Analyses DevOps Tableau de bord des mesures de qualité

    Tableau 4. Rapports sur les mesures de qualité
    Rapport Description Source
    % de la couverture du code Pourcentage de code couvert par les tests.

    Nécessite des détails de l’analyse de la qualité logicielle avec catégorie = couverture (%)

    A besoin d’un résumé de l’analyse de la qualité logicielle Relations associées à l’exécution des tâches

    % de réussite aux tests Pourcentage de réussite aux tests.

    Nécessite un résumé de test lié à l’exécution de la tâche

    Vulnérabilités de sécurité Nombre de vulnérabilités de sécurité au fil du temps.

    Nécessite des détails de l’analyse de la qualité logicielle avec la catégorie = vulnérabilités

    Nécessite des relations de résumé de l’analyse de la qualité logicielle liées à l’exécution des tâches.

    Nombres de bogues Nombre d’éléments de travail de type bogue.

    A besoin d’association Commits to Work Items . Le référentiel et le plan doivent être suivis et associés à la même application.

    A besoin d’association Commits to Task Execution . Le référentiel et le pipeline doivent être suivis et associés à la même application

    L’élément de travail nécessite d’être de type Bogue.

    Analyses DevOps Tableau de bord de développement

    Les mesures de développement se concentrent sur les données de validation qui fournissent un aperçu du niveau d’activité et d’agilité de vos équipes. Grâce à ces informations, vous pouvez obtenir une traçabilité complète du travail en vous assurant que les validations sont balisées avec les éléments de travail appropriés.

    Rapports de développement

    Analyses DevOps Tableau de bord de développement

    Tableau 5. Rapports de développement
    Rapport Description
    Fréquence de validation Nombre de validations associées aux exécutions de pipelines.

    Les commits plus petits et plus fréquents sont préférés aux commits plus grands et moins fréquents.

    Validateurs actifs Nombre de validateurs qui ont soumis des validations.

    Étant donné que ce rapport utilise l’agrégation de mesures, il ne prend pas en charge la sélection de plusieurs éléments.

    Principaux validateurs (somme cumulée sur 30 jours)

    Validateurs avec le nombre de validations le plus élevé.

    Principaux rétablisseurs (somme cumulée sur 30 jours)

    Validateurs avec le nombre d’annulations le plus élevé.

    Nombre moyen de validations par validateur

    Moyenne calculée comme suit : (nombre total de validations)/(validateurs actifs). Une valeur plus élevée est plus favorable.

    Étant donné que ce rapport utilise l’agrégation de mesures, il ne prend pas en charge la sélection de plusieurs éléments.

    Validations moyennes par exécution de pipeline

    Validations moyennes par pipeline, calculées comme suit : (Nombre total de validations)/(Nombre d’exécutions de pipelines).

    Un nombre faible est préférable, ce qui indique un effort concentré, plutôt que de passer d’une tâche à l’autre sans l’achever.

    Étant donné que ce rapport utilise l’agrégation de mesures, il ne prend pas en charge la sélection de plusieurs éléments.

    Validations sans élément de travail

    Validations effectuées qui ne sont pas associées à un élément de travail, regroupées par validateur.

    Ce rapport est utile pour examiner et résoudre les raisons pour lesquelles une validation n’est pas liée à un élément de travail, car toutes les validations doivent être liées à un élément de travail.

    Pourcentage de réussite de pipeline Taux d’exécutions de pipeline réussies divisé par le nombre total d’exécutions de pipeline.

    Analyses DevOps Tableau de bord de stabilité opérationnelle

    Les mesures opérationnelles reflètent la stabilité de vos applications pour vous permettre de vous assurer que vos équipes avancent rapidement sans compromettre la qualité des versions.

    Rapports de stabilité opérationnelle

    Analyses DevOps Tableau de bord de stabilité opérationnelle

    Tableau 6. Rapports de stabilité des opérations
    Rapport Description Source
    Incidents Nombre d’incidents pour les étapes du pipeline de type Déploiement du produit qui sont liées à un service dans le CMDB.

    Le type d’étape nécessaire doit être un déploiement produit.

    Nécessite que l’incident soit associé à un service qui correspond à celui de l’étape de déploiement produit.

    Pannes Nombre de pannes pour les étapes du pipeline de type Déploiement du produit qui sont liées à un service dans le CMDB.

    Le type d’étape nécessaire doit être un déploiement produit.

    Nécessite une panne (cmdb_ci_outage) associée à un service qui correspond à celui de l’étape de déploiement produit.

    Disponibilité du service Disponibilité moyenne du service pour les étapes du pipeline de type Déploiement du produit qui sont liées à un service dans le CMDB.

    Le type d’étape nécessaire doit être un déploiement produit.

    Nécessite une offre de service parente associée à un service qui correspond à celui de l’étape de déploiement produit.

    Budget d'erreur restant

    Pourcentage de budget d’erreur restant à dépenser au cours d’un mois, pour les étapes de pipeline de type Déploiement du produit qui sont liées à un service dans la CMDB. Ces données proviennent de l’application Site Reliability operations (Opérations pour la fiabilité des sites).

    Un budget d’erreur est le montant de l’objectif de niveau de service (SLO) que vous pouvez utiliser sur une période spécifiée. Il peut être utilisé pour gérer la vélocité de la mise en production. Il est généralement basé sur la disponibilité, la latence, etc.

    Remarque :
    Vous devez installer l’application Opérations pour la fiabilité des sites à partir de pour ServiceNow Store activer le rapport Budget d’erreur restant. Pour plus d’informations, consultez Installer l’application Opérations pour la fiabilité des sites.

    Le type d’étape nécessaire doit être un déploiement produit.

    Nécessite une offre de service parente associée à un service qui correspond à celui de l’étape de déploiement produit.

    Requiert une application SRO. Reportez-vous à la section Installer l’application Opérations pour la fiabilité des sites.