Analyses DevOps tableau de bord : espace de travail

Le Analyses DevOps tableau de bord fournit une vue graphique flexible des rapports opérationnels et business. 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ésumé 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é

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ée 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 du 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 associée au résumé du test, aux relations du résumé du test, à l’exécution de l’étape, au détail du référentiel de demande de changement, à l’étape, au pipeline, à l’application et au détail 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 un élément de travail, une instance de mesure, un élément de travail de validation, une validation, une exécution de validation, une exécution d’étape, une étape, un pipeline, une application et des détails 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 jointe par une validation, un élément de travail de validation, un référentiel, une exécution de validation, une application, des relations de résumé de test, une exécution d’étape, un 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. Découvrez les goulots d’étranglement en déterminant quels types de travail (tels que les stories ou les bugs) prennent le plus de temps.

Rapports de mesures de flux

Tableau 1. Rapports de 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 un élément de travail, une instance de mesure, un élément de travail de validation, une validation, une exécution de validation, une exécution d’étape, une étape, un pipeline, une application et des détails 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 jointe par les listes Élément de travail, Instance de mesure, Validation, Exécution d’étape, Exécution de validation et Élément de travail de validation.
Nombre moyen de WIP	Nombre moyen d’éléments de travail en cours 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 la validation à 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 jointe par les listes Élément de travail, Instance de mesure, Validation, Exécution d’étape, Exécution de validation et Élément 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 jointe par les listes Élément de travail, Instance de mesure, Validation, Exécution d’étape, Exécution de validation et Élément 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 jointe par les listes Élément de travail, Instance de mesure, Validation, Exécution d’étape, Exécution de validation et Élément de travail de validation.
Travail en cours	Nombre d’éléments de travail actuellement à l’état Travail en cours.	Vue de base de données jointe par les listes Élément de travail, Instance de mesure, Validation, Exécution d’étape, Exécution de validation et Élément 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

Les demandes de changement qui font partie des exécutions d’étapes sont qualifiées de 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 demande de changement.
Délai des changements fermés	Délai moyen, en heures, pour fermer les DevOps 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 demande 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 affectée à un utilisateur ou à un groupe pour l’action d’approbation/de rejet et qui n’est pas prise en compte 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 demande 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 à l’état Nouveau ou Évaluer 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 rejointe par les listes Exécution d’étape, Demande de changement, Propriétés système et Détails du référentiel de demande de changement.
Décisions de politique de changement : acceptées automatiquement	Nombre de décisions de politique de changement par type de décision qui acceptent automatiquement les demandes de changement. Pointez sur une valeur du graphique pour afficher la liste des décisions de politique qui ont été utilisées pour l’approbation automatique et le nombre de fois où une décision a été utilisée pour l’approbation automatique.	Vue de base de données rejointe par les listes Exécution d’étape, Demande de changement, Propriétés système et Détails du 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 où une décision a été utilisée pour le rejet automatique.	Vue de base de données associée aux listes Exécution d’étape, Demande de changement, Politique appliquée, Action de rejet d’approbation automatique, Définition d’approbation de changement et Détails du 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 de tests et autres preuves et artefacts au changement. Une fois cette activité automatisée, les heures qui auraient été consacrées au remplissage du changement, à la recherche, au suivi et à l’attachement d’éléments provenant d’autres outils à un changement seront maintenant enregistrées. Un plus grand nombre d’éléments de travail nécessitent un nombre d’heures relativement croissant pour les associer manuellement. Par conséquent, un nombre plus élevé d’éléments de travail devrait entraîner plus 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 promoteur, mettez à jour le paramètre de Average Hourly developer Cost propriété. 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 en automatisant les DevOps changements. Pour modifier la valeur par défaut de 1 (une) heure par développeur, mettez à jour le paramètre de propriété X hours per Developer time . 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 Analyses DevOps mesures d’accélération 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 délai moyen de récupération sont utilisés pour mesurer la stabilité.

Rapports de mesures d’accélération

Tableau 3. Rapports de 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 [délai de validation le plus tôt]) S’applique aux étapes du 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 du pipeline de type Déploiement du produit qui sont à l’état Terminé.	Exécution d'étape
MTTR moyen	Délai moyen quotidien 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 rejointe par les listes Incident, Demande de changement, Exécution d’étape, Étape, Pipeline et Application.
Taux moyen DevOps d’échec de changement	Taux moyen quotidien de demandes de changement associées à un incident, divisé par toutes les DevOps demandes de DevOps 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 examiner 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é par le nombre d’exécutions de pipelines de production réussies. Nécessite l’association « Validations pour l’exécution de la tâche ». Le référentiel et le pipeline doivent être suivis et associés à la même application. Nécessite que le type d’étape soit Déploiement produit. A besoin 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 des DevOps changements	Délai moyen quotidien de résolution d’un incident causé par un DevOps changement.	Vue de base de données jointe par l’exécution de l’étape, la demande de changement, le détail du référentiel de la demande de changement et les listes d’incidents. Calculé uniquement pour DevOps les 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 de 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 associée à la demande de changement, à l’exécution d’étape, au détail du référentiel de demande de changement. L’état d’exécution de l’étape doit être terminé. Nécessite que le type d’étape soit Déploiement produit.
DevOps Taux d’échec du 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 de changement nécessaire DevOps (changement associé à l’exécution d’une étape). L’état d’exécution de l’étape doit être terminé. Nécessite que le type d’étape soit Déploiement produit. A besoin d’un incident causé par une demande de DevOps 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 en 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 en production échoués 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 des mesures de qualité permet d’examiner rapidement les 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 total de bogues.

Rapports sur les 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.	A besoin du détail 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 liées à l’exécution des tâches
% de réussite aux tests	Pourcentage de réussite aux tests.	Nécessite un résumé des tests liés à 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.	A besoin du détail de l’analyse de la qualité logicielle avec Catégorie = Vulnérabilités A besoin d’un résumé de l’analyse de la qualité logicielle Relations liées à l’exécution des tâches.
Nombres de bogues	Nombre d’éléments de travail de type bogue.	Besoin d’association Commits to Work Items . Le référentiel et le plan doivent être suivis et associés à la même application. Besoin d’association Commits to Task Execution . Le référentiel et le pipeline doivent être suivis et associés à la même application A besoin que l’élément de travail soit 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 de l’activité et de l’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 étiquetées avec les éléments de travail appropriés.

Rapports 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 validations plus petites et plus fréquentes sont préférées aux validations plus grandes et moins fréquentes.
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 terminer. É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 pourquoi 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 agissent rapidement sans compromettre la qualité des versions.

Rapports sur la stabilité opérationnelle

Tableau 6. Rapports sur la 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.	Nécessite que le type d’étape soit Déploiement produit. A besoin d’un incident associé à un service qui correspond à celui de l’étape de déploiement produit.
Pannes	Nombre de pannes pour les étapes de pipeline de type Déploiement du produit qui sont liées à un service dans le CMDB.	Nécessite que le type d’étape soit Déploiement produit. Une panne requise (cmdb_ci_outage) est associée à un service qui correspond à celui de l’étape de déploiement produit.
Disponibilité du service	Disponibilité moyenne du service pour les étapes de pipeline de type Déploiement du produit qui sont liées à un service dans le CMDB.	Nécessite que le type d’étape soit Déploiement produit. A besoin d’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. Elle est généralement basée sur la disponibilité, la latence, etc.	Nécessite que le type d’étape soit Déploiement produit. A besoin d’une offre de service parente associée à un service qui correspond à celui de l’étape de déploiement produit. Nécessite une application SRO.