Blog

Les 4 indicateurs opérationnels que vous devriez suivre

par David Shackelford 20 août 2014 | 5 minutes de lecture

Vivre dans un monde riche en données est à la fois une bénédiction et une malédiction. Des systèmes de surveillance flexibles, des API ouvertes et des ressources de visualisation de données simples permettent de représenter graphiquement tout ce que vous souhaitez, mais trop de données deviennent rapidement bruyantes et impossibles à exploiter.

Nous avons blogué , parlé , et j'ai longuement réfléchi à ce que vous devriez surveiller et pourquoi du point de vue des systèmes, mais qu'en est-il de la surveillance des données sur les performances de vos opérations ? Nous avons travaillé avec un grand nombre de clients PagerDuty alors que nous construisions notre nouveau Rapports avancés fonctionnalité, y compris certaines des équipes d'exploitation les plus sophistiquées. Nous aimerions partager certaines mesures et directives spécifiques qui aident les équipes à mesurer et à améliorer leurs performances opérationnelles.

Principaux indicateurs à suivre

1. Nombre brut d'incidents

Un pic ou une tendance continue à la hausse du nombre d'incidents reçus par une équipe vous indique deux choses : soit l'infrastructure de cette équipe a un problème grave, soit ses outils de surveillance sont mal configurés et doivent être ajustés.

Le nombre d’incidents peut augmenter à mesure qu’une organisation se développe, mais les incidents réels par répondant devrait rester constant ou diminuer à mesure que l'organisation identifie et corrige les alertes de mauvaise qualité, crée des runbooks, automatise les correctifs courants et devient plus mature sur le plan opérationnel.

« Nous passions beaucoup de temps à supprimer les alertes redondantes. » – Kit Reynolds, chef de produit SI, thetrainline.com

Lors de l'analyse des incidents, il est important de les décomposer par équipe ou par service, puis d'analyser les incidents sous-jacents pour comprendre ce qui cause les problèmes. Ce pic de mercredi était-il dû à un déploiement raté qui a causé des problèmes dans plusieurs équipes, ou simplement à un système de surveillance instable sur un service de faible gravité ? La comparaison du nombre d'incidents entre les services et les équipes permet également de mettre vos chiffres en contexte, afin de comprendre si une charge d'incidents particulière est meilleure ou pire que la moyenne de l'organisation.

2. Temps moyen de résolution (MTTR)

Le temps de résolution est la référence absolue en matière de préparation opérationnelle. Lorsqu'un incident se produit, combien de temps faut-il à votre équipe pour le résoudre ?

Les temps d'arrêt nuisent non seulement à vos revenus, mais aussi à la fidélité de vos clients. Il est donc essentiel de veiller à ce que votre équipe puisse réagir rapidement à tous les incidents. Pour la Major League Soccer, les fans s'attendent à ce que leurs 20 sites Web soient opérationnels pendant les matchs en direct. Justin Slattery, directeur de l'ingénierie, et son équipe travaillent constamment à améliorer leurs délais de résolution, car « le coût d'une panne en plein milieu d'un match est incalculable ».

Bien que le temps de résolution soit important à suivre, il est souvent difficile à normaliser et les entreprises constateront des variations dans le TTR en fonction de la complexité de leur environnement, de la manière dont les équipes et la responsabilité de l'infrastructure sont organisées, du secteur d'activité et d'autres facteurs. Cependant, des manuels d'exploitation standardisés, une automatisation de l'infrastructure, des alertes fiables et des politiques d'escalade contribueront à réduire ce chiffre.

3. Délai de reconnaissance / Délai de réponse

Il s’agit de la mesure que la plupart des équipes oublient : le temps qu’il faut à une équipe pour reconnaître un incident et commencer à travailler dessus.

« Le temps de réponse est important car il vous aidera à identifier les équipes et les individus qui sont prêts à être de garde. Un temps de réponse rapide est un indicateur d'une culture de préparation opérationnelle, et les équipes ayant l'attitude et les outils nécessaires pour réagir plus rapidement ont tendance à avoir l'attitude et les outils nécessaires pour récupérer plus rapidement. '- Arup Chakrabarti, responsable des opérations, PagerDuty

Même si un intervenant en cas d'incident ne maîtrise pas toujours la cause profonde d'un incident particulier, il est responsable à 100 % du temps nécessaire à sa reconnaissance et à sa réponse. Les équipes opérationnellement matures ont des attentes élevées quant au temps de réponse de leurs membres et se tiennent responsables des objectifs internes en matière de temps de réponse.

Si vous utilisez un système de gestion des incidents comme PagerDuty, un délai d'escalade est un excellent moyen de faire respecter un délai de réponse. Par exemple, si vous décidez que tous les incidents doivent être traités dans un délai de 5 minutes, définissez votre délai d'attente sur 5 minutes pour vous assurer que la personne suivante dans la file d'attente est alertée. Pour évaluer les performances de l'équipe et déterminer si votre objectif doit être ajusté, vous pouvez suivre le nombre d'incidents qui sont remontés.

4. Escalades

Pour la plupart des organisations qui utilisent un outil de gestion des incidents, une escalade est une exception : un signe qu'un intervenant n'a pas pu intervenir à temps sur un incident ou qu'il n'avait pas les outils ou les compétences nécessaires pour y remédier. Bien que les politiques d'escalade soient un élément nécessaire et précieux de la gestion des incidents, les équipes doivent généralement essayer de réduire le nombre d'escalades au fil du temps.

Dans certaines situations, une escalade fera partie des pratiques opérationnelles standard. Par exemple, vous pouvez disposer d'un centre d'opérations réseau (NOC), d'une équipe d'assistance de premier niveau ou même d'un outil de correction automatique qui trie ou escalade les incidents entrants en fonction de leur contenu. Dans ce cas, vous souhaiterez suivre les types d'alertes qui doivent être escaladées et les nombres normaux qui doivent être observés pour ces alertes.

Suivez les performances de vos opérations avec PagerDuty

« Avant PagerDuty, cela pouvait prendre une journée pour répondre aux incidents. Maintenant, ce ne sont que quelques secondes. – Aashay Desai, DevOps, Inkling.

PagerDuty a toujours pris en charge l'extraction de données riches sur les incidents via notre API à couverture complète, et nous avons également proposé des rapports limités dans l'application à tous les clients.

Monitoring_Ebook_728_90