Deux des indicateurs les plus importants pour toute équipe d'astreinte sont Volume d'incidents et Délai moyen de réparation ( Temps moyen de réaction ). Le suivi du nombre d'incidents qui surviennent dans votre système (et de quels services ils proviennent) vous aide à identifier à la fois les problèmes d'infrastructure systémique et les outils de surveillance mal configurés. Qu'il s'agisse d'un problème avec le système central ou simplement d'un seuil de surveillance à ajuster, si vous constatez des dizaines d'incidents par jour, il y a quelque chose à régler !

Le suivi du MTTR vous permet de montrer à quelle vitesse votre équipe résout les problèmes. Même si la complexité des incidents varie toujours, en examinant les tendances générales du MTTR au fil du temps et à travers différentes politiques ou services de remontée d'informations, vous pouvez commencer à identifier les opportunités d'améliorer la façon dont votre équipe résout les problèmes. Une politique d’escalade résout-elle systématiquement les problèmes plus rapidement que d’autres ? Peut-être qu'ils ont intégré plus de fiabilité à leur système, ou peut-être qu'ils collaborent via HipChat ou stockent des runbooks d'incidents dans le champ « notes » pour chaque incident PagerDuty . Le suivi des valeurs aberrantes du MTTR peut aider les managers à identifier les meilleures pratiques ainsi que les endroits où aider les équipes en difficulté.

Vous pouvez actuellement voir certaines données d'incident dans l'onglet « Rapports » de PagerDuty , mais je souhaitais créer des fonctionnalités de reporting supplémentaires pour nous aider à identifier les services et les politiques d'escalade ayant des volumes d'incidents et un MTTR inhabituellement élevés (ou faibles).

J'ai reçu un conseil sur une façon cool de faire cela de la part de nos amis de Outbrain - ils utilisent Rapports Zoho pour interroger notre API une fois par heure, puis créer des tableaux de bord à partir de ces données. Après quelques heures de travail avec Zoho, voici notre rapport :

Vous pouvez filtrer par date, politique d'escalade, responsable et service. Vous pouvez également cliquer sur n'importe quel point de données pour voir les détails des incidents associés !

Pour commencer à créer vos propres rapports, nous avons élaboré un guide rapide pour vous aider tout au long du processus. Tout d'abord, créez un compte dans Rapports Zoho . Vous pouvez obtenir des rapports de base avec un compte gratuit. Des versions payantes sont disponibles, qui ajoutent des allocations de données supplémentaires ainsi que des tableaux de bord privés et partageables.

Configuration de base

Créez un nouveau tableau et choisissez « Importer Excel, CSV, HTML, Google Drive… ».

Choisissez « JSON » comme type, « Web » comme source et saisissez la chaîne « https://<your_subdomain> .pagerduty.com/api/v1/incidents » dans le champ URL. Cela appelle l'API PagerDuty pour une liste d'incidents ( Plus d'information ).

Ensuite, vous verrez une liste des colonnes disponibles. N'hésitez pas à en supprimer certaines de l'importation et, si vous le souhaitez, double-cliquez sur les en-têtes pour les renommer de manière plus lisible. Cliquez ensuite sur « Suivant ».

Vous devriez alors voir quelque chose comme ceci : un tableau de tous vos incidents. Si vous souhaitez le nettoyer un peu (et n'avez pas sélectionné de colonnes lors de l'importation), cliquez sur le bouton à droite pour ajuster les colonnes à afficher et dans quel ordre.

Remplir le tableau des incidents

Maintenant, remplissons ce tableau. L'API PagerDuty a une limite de 100 lignes, ce qui signifie que nous ne pouvons obtenir que 100 lignes de données à chaque appel. Cependant, nous pouvons ajouter un paramètre « offset » à notre appel API pour contrôler à quelle ligne commence 100. Pour commencer à remplir notre tableau, cliquez d’abord sur « Importer dans ce tableau ».

Sélectionnez « incidents.id » comme colonne à laquelle appliquer la correspondance, pour vous assurer que nous n'importons pas de doublons. Ajoutez ensuite « &offset=100 » à l'URL (vous ne devriez pas avoir à modifier quoi que ce soit d'autre).

Vous suivrez le même processus de sélection des colonnes à importer, mais vous ne devriez pas avoir à modifier quoi que ce soit :

Cliquez sur « Créer » et vous devriez avoir 100 lignes supplémentaires dans votre tableau !

Si vous souhaitez importer une grande quantité de données historiques, vous devrez exécuter ce processus une fois tous les cent enregistrements, en définissant le décalage sur 200 la fois suivante, puis sur 300, et ainsi de suite. Si vous avez une grande quantité de données à importer, vous souhaiterez peut-être appeler l'API directement depuis la ligne de commande et utiliser un script pour transférer les informations vers un fichier CSV.

Enfin, configurons Zoho pour qu'il récupère automatiquement les nouveaux incidents au fur et à mesure qu'ils arrivent. Cliquez sur « Importer », puis sur « Récupérer/Planifier l'importation ».

Vous pouvez voir certaines informations pré-remplies ici. Sinon, remplissez le reste. Pour l'URL, assurez-vous d'utiliser l'URL sans paramètre de décalage (c'est-à-dire « https://<subdomain> .pagerduty.com/api/v1/incidents »).

Configurer Zoho pour extraire les données toutes les heures :

Masser nos données

Vous disposez désormais d'un tableau d'incidents dans Zoho. Si vous souhaitez uniquement générer un rapport sur le nombre d'incidents, vous êtes prêt. Cependant, si vous souhaitez également générer un rapport sur le temps de résolution, nous devrons faire un peu plus de travail. Sélectionnez « Nouveau », puis « Nouvelle table de requête ».

Les tables de requête vous permettent d'exécuter des commandes SQL sur votre table d'incidents de base, ce qui nous aidera à obtenir les données souhaitées sous forme graphique. Si vous connaissez SQL, vous êtes probablement bon à ce stade. Sinon, voici un exemple de requête pour vous aider à démarrer :

SÉLECTIONNEZ distinct « incidents.id » comme incident_id, timestamp(« incidents.created_on ») comme created_date, incidents.« incidents.html_url » comme lien, « incidents.escalation_policy.name » comme escalation_policy, « incidents.service.name » comme service, « incidents.resolved_by_user.name » comme résolveur, sec_to_time((unix_timestamp(« incidents.last_status_change_on ») – unix_timestamp(« incidents.created_on »))) comme resolvetime, timestamp(« incidents.last_status_change_on ») comme solved_date, round((unix_timestamp(« incidents.last_status_change_on ») – unix_timestamp(« incidents.created_on »))/60) comme resolvemins, concat_ws(':','incidents.trigger_summary_data.subject','incidents.trigger_summary_data.description') comme détails

DES incidents

OÙ « incidents.status » = « résolu »

Cliquez sur « Exécuter » et vous devriez voir un nouveau tableau apparaître ci-dessous. C'est à partir de ce tableau que nous allons réaliser notre graphique.

NOTE :Vous pourriez être tenté de représenter graphiquement certaines mesures de votre table d'origine et d'autres de la table de requête. Cela fonctionnera, mais tout faire à partir de la table de requête active certaines fonctionnalités supplémentaires que j'expliquerai plus tard.

Graphique du temps

Créons maintenant notre premier graphique. Dans votre table de requête, sélectionnez « Nouveau », puis « Nouvelle vue graphique ».

Créons un graphique qui montre le nombre d'incidents par service au fil du temps. Qu'il s'agisse d'un problème d'infrastructure ou simplement de seuils de surveillance mal configurés, un volume élevé d'incidents est le signe qu'il y a quelque chose à régler.

Faites glisser « created_date » sur l'axe des x et définissez-le sur « Full Date ». Faites glisser « incident_id » sur l'axe des y et définissez-le sur « count ». Faites ensuite glisser « service » dans le champ « color » (la « couleur » peut être considérée comme la variable qui divise une colonne en plusieurs séries). Cliquez sur « Generate Graph » (générer un graphique) et vous verrez quelque chose comme ceci :

En cliquant sur les différents services à droite, vous pouvez contrôler les services qui s'affichent. Vous pouvez également utiliser l'onglet « Filtres » pour inclure ou exclure certains services (tels que les services de faible gravité ou de test).

Ajoutons maintenant un filtre de politique d'escalade, afin que vous puissiez voir les services répartis par équipe. Cliquez sur l'onglet « Filtres utilisateur », puis faites glisser « escalation_policy ». Cliquez ensuite sur « Mode d'affichage ».

Vous pouvez désormais filtrer la liste des services représentés graphiquement par politique d'escalade ! Cela constitue une aide précieuse pour les chefs d'équipe qui souhaitent uniquement voir les services dont ils sont responsables.

Allez-y, enregistrez votre rapport et donnez-lui un nom descriptif.

Maintenant, nous allons représenter graphiquement le temps de résolution des problèmes, pour montrer la rapidité avec laquelle notre équipe résout les problèmes. Créez un nouveau graphique et placez la date de création sur l'axe des x, les minutes de résolution sur l'axe des y et la politique d'escalade comme « couleur ». J'aime aussi ajouter incident_id(count) à la boîte d'info-bulle, de sorte que le passage de la souris sur un certain jour me montre également le nombre d'incidents qui se sont produits.

Dans « Filtres utilisateur », vous pouvez ajouter ce que vous voulez, mais je suggère d'ajouter un filtre pour « résolutions ». Cela nous donnera un moyen maladroit d'exclure les incidents de longue durée et d'obtenir un graphique moins bruyant. Remarque pour les nerds en mathématiques : la médiane ou le centile seraient une bien meilleure mesure du temps de résolution. Je vous laisse cet exercice 🙂

Cliquez sur « Générer un graphique », testez les différents filtres et assurez-vous que vous êtes satisfait. Enregistrez ensuite ce rapport.

Mettre tous ensemble

Enfin, créons un tableau de bord d'entreprise. Sélectionnez « Nouveau tableau de bord » :

Depuis la barre latérale gauche, faites glisser vos deux rapports. Vous verrez que les filtres utilisateur des deux rapports sont automatiquement ajoutés en haut ! Vous pouvez également ajouter d'autres filtres utilisateur de votre choix, et ils affecteront les deux rapports sur le tableau de bord.

Lorsque vous êtes satisfait de votre tableau de bord, enregistrez-le. Vous pouvez ajouter des vues graphiques, tabulaires et récapitulatives supplémentaires à votre tableau de bord. Mon tableau de bord final ressemble à ceci :

Partager votre rapport

Enfin, nous allons montrer nos excellents rapports aux autres membres de l'entreprise. Pour partager un rapport ou un tableau de bord, cliquez simplement sur le menu « Publier » dans la barre d'outils :

Vous recevrez des liens ou un code d'intégration que vous pourrez utiliser pour partager votre graphique au sein de votre organisation (nous intégrons le nôtre dans notre wiki Confluence). Notez que sur le plan Zoho gratuit, vous devrez être connecté pour afficher le tableau de bord, mais les plans payants proposent également des intégrations publiques.

Nous espérons que vous apprécierez ! Merci encore à Outbrain pour le pourboire.